01 · CRL 与 Manifest 机制回顾
RPKI 基于 RFC 5280 的 X.509 框架并嵌入 RFC 3779 资源扩展。在信任树中，每个 CA 周期性地发布两类关键签名对象：
- CRL（证书撤销列表，RFC 5280/6487）：由 CA 签发，列出已被撤销的证书序列号。RP 校验某证书时，必须确认它未出现在对应 CA 的 CRL 中。CRL 自身有
thisUpdate / nextUpdate字段，超过 nextUpdate 即视为过期。 - Manifest（清单，RFC 6486 → RFC 9286）：由 EE 证书签名的对象，枚举该发布点内所有对象的文件名与哈希。RP 用它检测对象被抑制或替换。Manifest 同样有有效期；现行规范为 RFC 9286（2022 年 6 月发布，取代 RFC 6486）。
核心机制：RP 验证一个 ROA 时，必须同时确认——(a) ROA 的 EE 证书签名有效；(b) 该 EE 证书未被父 CA 的 CRL 撤销；(c) 父 CA 的 Manifest 仍然有效且列举了该对象。任何一个环节过期，ROA 都将无法被纳入 VRP。因此，CRL/Manifest 的"持续有效"是整棵子树可用性的总开关。
02 · Manifest 有效期与"过期即失效"语义
Manifest 与 CRL 都依赖 CA 的周期性重签。以 RIPE NCC 公开的运维参数为例（来自 2021-02 邮件列表披露），常见有效期大致为：
| 对象类型 | 典型有效期（RIPE 托管环境示意） | 过期后果 |
|---|---|---|
| CRL | 约 24 小时 | 超过 nextUpdate 后，依赖该 CRL 的证书验证链断裂 |
| Manifest eContent | 约 24 小时 | Manifest 过期 → 其列举的对象可信度下降/被判失效 |
| Manifest EE 证书 | 约 7 天 | EE 证书过期 → Manifest 整体不可验证 |
| ROA EE 证书 | 约 18 个月 | ROA 对象本身长期有效（前提是父链健康） |
| CA 证书 | 约 18 个月 | CA 过期影响整棵子树（需密钥轮换 RFC 6489） |
设计意图：短有效期（CRL/Manifest 24h）是为了让"撤销/更新"能较快传播——若某对象需被撤销，最多约一天内通过 CRL 刷新生效。但这把"CA 必须每天重签"变成了硬性运维约束：一旦重签流水线在 24 小时内失败，可用性风险立即出现。这是一种"安全 vs 可用性"的经典权衡。
上述有效期参数亦见于各 RIR 的证书策略与认证实践声明（CP/CPS），例如 RIPE NCC CPS（RIPE-851）对各签名对象有效期的约定，可作为比邮件列表更稳定的一手引用。
03 · Stale Manifest 问题
当 CA 未能在 Manifest 到期前成功重签并发布新 Manifest 时，旧 Manifest 变为 stale（陈旧）。RFC 6486 / RFC 9286 第 6 节专门讨论 stale manifest 的处理：
- 定义：Manifest 的
nextUpdate已过，但 RP 仍只有旧版本（无法获取更新），即为 stale。 - RP 行为（RFC 8897 建议）：若 Manifest stale 或无效、且 RP 无法获取更新的有效版本，应通过 Ghostbusters 记录（RFC 6493）联系该发布点维护者，并按本地策略决策——不同实现的宽松度差异很大。
- 严重后果：RFC 8211（Adverse Actions，Kent & Ma）指出，若 Manifest 的 EE 证书恰好在换新时过期，Manifest 会直接变为"无效"而非"陈旧"，这是更严重的结果——可能导致整棵子树（含下属全部对象）被判失效。
- 工程建议（RFC 8211）：应将 Manifest 的 EE 证书
notAfter设为与签发它的 CA 证书notAfter相同，以避免"EE 先过期"导致的硬失效。
为什么这是弹性而非安全议题：绝大多数 stale manifest 事件并非遭受攻击，而是 CA 软件缺陷、磁盘满、密钥轮换卡死、DNS 误配等运维事故（第4页案例库已列）。它暴露的是"重签流水线的可靠性"，属于典型的基础设施弹性问题。
04 · CRL 过期与撤销失效
CRL 的可靠性有两个相反的失败方向：
| 失败方向 | 后果 | 风险 |
|---|---|---|
| CRL 未及时重签（过期） | 依赖该 CRL 的证书验证链断裂，整棵子树对象失效 | 合法 ROA 被错误降级（可用性风险） |
| CRL 未包含应撤销项 | 已被泄露的证书仍被视为有效 | 恶意/错误证书持续被信任（安全/完整性风险） |
| CRL 发布点与 Manifest 不一致 | RP 在更新窗口抓到中间态，对象判为缺失 | 非原子发布引发的批量失效 |
因此 CRL 重签既要"及时"（避免过期导致误伤），又要"准确"（确保应撤销项被纳入）。这要求 CA 的 CRL 生成流水线具备高可用与强监控——任何一次静默失败都会在 24 小时内转化为可用性事故。
05 · RP 软件对 stale 的处理差异
不同验证器（RP）在 Manifest/CRL stale 时的默认行为并不一致，这直接决定了"同一场事故对不同网络的影响不同"——这也是 RPKI 弹性难以统一评估的重要原因：
| 行为维度 | 严格实现 | 宽松实现 |
|---|---|---|
| Manifest 缺失/无效 | 忽略发布点内未被有效 Manifest 列举的对象，甚至拒绝整棵子树 | 在无 Manifest 时接受发布点内所有有效签名对象（RFC 6486 §6.2 允许） |
| Stale Manifest | 倾向于判失效并告警 | 倾向于保留上一版、按本地策略继续 |
| 真实差异后果 | RIPE 2021-03-18 事件中，Manifest 引用了仓库中不存在的证书，严格实现将该发布点对象判为缺失/失效，宽松实现则可能保留上一版视图（packetvis 记录） | 宽松实现可能"侥幸"保留旧视图，但也可能放过不一致 |
研究启示：RP 行为差异意味着"基础设施故障的影响"是异质的——无法用单一数字刻画。弹性评估必须区分"存储库/CA 侧可用性"与"RP 侧容忍度"两个维度，并建议在关键网络部署多个不同实现的验证器（Routinator + rpki-client + OctoRPKI 等）以对冲单实现偏差。
06 · AFRINIC 案例的撤销机制视角
回到第3、4页的 AFRINIC 案例，从"撤销机制可靠性"视角可更精确地归因：
- 2022-11-20（顶级 Manifest 过期）：属于典型的"Manifest 重签失败/未被及时发布"，导致该区域约 73.95% ROA 在约 7 小时内不可见。根因是 Manifest 这一"总开关"未能按时刷新。
- 2023-01-01（Manifest 引用不存在文件）：Manifest 与其引用文件出现不一致（非原子发布），部分验证器将整张 Manifest 判为损坏并丢弃，77.33% ROA 消失。这同时是"存储库一致性"与"Manifest 语义"的双重问题。
- 2023 多次 22%—26% 事件：随 ROA 增删频率上升，非原子操作窗口被更频繁触发，Manifest 与文件短暂不一致即被部分 RP 抓取，造成中等规模 ROA 消失。
这些事件共同印证：RPKI 弹性高度依赖"Manifest/CRL 重签流水线"与"原子发布"两项能力。密码学再强，若这两项运维能力脆弱，整片防御仍会塌方。
07 · 可靠性边界与重签调度最佳实践
为把"撤销机制"从脆弱环节变为可信基础设施，本课题提出以下可靠性边界与调度建议：
| 实践 | 要点 |
|---|---|
| 高频且冗余的重签 | CRL/Manifest 应在有效期过半前完成重签；重签流水线应有多重触发（定时 + 看门狗），失败即告警 |
| 原子发布 | Manifest 与其引用文件必须"同刻一致"地对外可见；采用"先写新对象、再换 Manifest 指针"的原子切换，杜绝中间态 |
| EE 证书 notAfter 对齐 | Manifest/EE 的 notAfter 应≤签发 CA 的 notAfter（RFC 8211 建议），避免 EE 先过期导致硬失效 |
| 发布点健康监控 | 对外暴露 Manifest/CRL 新鲜度指标；维护 Ghostbusters（RFC 6493）紧急联系人，stale 时可供 RP 及时通报 |
| 多验证器对冲 | 关键网络部署多实现 RP，避免单实现 stale 策略偏差导致一致误判 |
| 演练与回滚 | 定期演练"重签失败/密钥轮换"场景，验证自动恢复与人工干预路径（RIPE 2020-02 曾需完整 CA 密钥轮换才恢复 CRL 问题，成本高） |
7.1 验证算法演进（与重签可靠性并行的战线）
"撤销机制可靠性"之外，RPKI 验证算法本身也在演进：RFC 8360（2018）曾提出改进的验证算法以处理资源重叠等边界情形，但因各实现未能协调切换而未获广泛部署；现行工作组草案 draft-ietf-sidrops-rpki-validation-update 正推动更新的验证算法进入标准。对运营者而言，这意味着不同 RP 在边界情形下的判定可能继续存在差异——多实现混部与跨实现一致性测试在算法切换期尤为重要。
同时，IETF 正在制定 draft-ietf-sidrops-publication-server-bcp《Best Practices for Operating RPKI Publication Services》（2026-03 为 -06 版），把原子发布、重签调度、监控告警等运维要求系统化——这是对本页"重签调度最佳实践"的标准化跟进，CA/发布服务运营者应跟踪其落地。
结论：CRL/Manifest 撤销机制的可靠性，本质上是一个"运维 SLA"问题。把重签周期、原子发布、监控告警、应急演练纳入 RIR/委托 CA 的可用性承诺（CPS）并对外度量，是提升 RPKI 弹性的最低成本、最高收益抓手。
本节参考来源（第5页）
以下来源支撑本页的撤销机制语义、stale 处理与案例归因。
IETF RFC 9286《Manifests for the Resource Public Key Infrastructure (RPKI)》(2022-06，取代 RFC 6486)：rfc-editor.org/rfc/rfc9286。第 6 节讨论 stale manifest。
IETF RFC 5280《Internet X.509 PKI Certificate and CRL Profile》(2008)；RFC 6487《X.509 Resource Certificates》(2012)。
IETF RFC 8897《Requirements for RPKI Relying Parties》(2021)：stale manifest/CRL 时通过 Ghostbusters 联系维护者、按本地策略决策：rfc-editor.org/rfc/rfc8897。
IETF RFC 8211《Adverse Actions by a CA or Repository Manager in the RPKI》(2017，Kent & Ma)：Manifest 失效的级联影响与 EE notAfter 对齐建议：rfc-editor.org/rfc/rfc8211。
RIPE NCC routing-wg 邮件列表（2021-02 披露各对象有效期参数与 CPS 合规讨论）：ripe.net routing-wg。
packetvis.com《RPKI Trust Anchor Malfunctions: A Review of the Last 3.5 Years》（AFRINIC 2022—2024 Manifest 失效统计与归因）：packetvis.com。
IETF RFC 6493《The RPKI Ghostbusters Record》(2012)：紧急联系人对象：rfc-editor.org/rfc/rfc6493。
RIPE NCC Certificate Practice Statement（RIPE-851）：托管 RPKI 各对象有效期的一手约定：ripe.net/publications/docs/ripe-851。
IETF draft-ietf-sidrops-publication-server-bcp《Best Practices for Operating RPKI Publication Services》：datatracker.ietf.org。