📚 课程目录第4章后量子证书标准演进

4. 后量子证书标准演进

后量子证书的落地，首先不是算法问题，而是“格式与互操作”问题。当前 PKI 生态中，证书的编码、扩展、签名算法标识、密钥用法约束都已被 X.509 与相关 RFC 严格定义；后量子算法（ML-KEM、ML-DSA、SLH-DSA 等）引入后，证书结构必须回答三个问题：算法标识如何注册、公钥与签名如何编码、以及新旧系统如何共存。IETF 的 LAMPS 工作组正是围绕这些内容推进标准化。

一、LAMPS 工作组在做什么

LAMPS（Limited Additional Mechanisms for PKIX and SMIME）负责 X.509 与 S/MIME 相关的增量机制。针对后量子迁移，其工作重点包括：为 ML-DSA、SLH-DSA 等签名算法分配对象标识符（OID）并定义其在 AlgorithmIdentifier 中的参数编码；为 ML-KEM 定义在证书与 CMS 中的使用方式；以及最关键的——定义“复合（composite）”与“混合（hybrid）”证书的公钥与签名结构。需要区分的是：PQ/T 混合通常指传统算法与后量子算法组合使用（如 ECDSA + ML-DSA），而复合证书是把多个公钥/签名封装进单一结构、由单一 OID 标识的证书形态。二者目标一致——在过渡期同时获得经典安全性与后量子安全性——但编码与验证语义不同。

记忆要点：混合强调“两种算法并行、结果都要验证”；复合强调“一个容器、一个标识、内部多组件”。标准文本中两者边界仍在收敛，工程实现应以具体草案/RFC 的 ASN.1 定义为准。

二、三种证书形态的格式差异

纯后量子证书最直接：SubjectPublicKeyInfo 中放 ML-DSA 公钥，signatureAlgorithm 为对应 OID，签名值为 ML-DSA 签名。它的优点是结构简单、验证路径短；缺点是过渡期依赖方（RP）可能完全不认识该 OID，导致解析失败或策略拒绝。

PQ/T 混合证书的典型做法是：在 SubjectPublicKeyInfo 内放置一个复合公钥结构（例如 SEQUENCE 包含传统公钥与 PQ 公钥），签名算法 OID 指向“混合签名”定义，签名值同样由两部分拼接或按结构封装。验证方必须两段都验证通过才接受，任一失败即拒绝。这种“与逻辑”是安全性的核心，但也意味着验证成本和失败面扩大。

复合证书则更强调“单一算法标识 + 内部组件列表”，其 ASN.1 往往定义 CompositePublicKey、CompositeSignatureValue，并通过算法参数指明组件算法集合与顺序。它与混合证书的差别主要在语义约定与互操作规范上：复合更倾向于把多算法视为一个整体算法，混合更强调“传统 + PQ”的过渡组合。

三、兼容性设计的关键工程决策

过渡期最稳妥的做法是“双轨发布”：同一主体同时签发经典证书与后量子（或混合）证书，通过能力探测或策略配置选择链路。具体实现上，CA 侧需要扩展证书模板，把签名算法从固定值改为可配置项；RP 侧需要在信任库中显式加入新 OID 的白名单，否则即使证书链完整也会被策略拒绝。一个常见的教学示例配置如下（示例参数，非实测）：

# 示例：签发端按依赖方能力选择证书模板（示意）
cert_profiles:
  classic_only:
    sig_alg: ecdsa-with-SHA256
    key: P-256
  hybrid_pq:
    sig_alg: id-MLDSA65-ECDSA-P256-SHA512   # 混合签名 OID（以草案为准）
    pubkey: composite(ecdsa-P256, ML-DSA-65)
    verify_policy: require_both
  pure_pq:
    sig_alg: id-ML-DSA-65
    pubkey: ML-DSA-65
    verify_policy: single

rp_policy:
  accept_oids: [ecdsa-with-SHA256, id-MLDSA65-ECDSA-P256-SHA512]
  reject_unknown_oid: true
  max_chain_bytes: 16384   # 防止混合链过大导致传输失败

验证时不能只看“证书能解析”，还要检查三件事：签名算法 OID 是否在 RP 白名单内；混合/复合证书的两段签名是否都通过；证书链总长度是否超过协议或设备限制。若任一不满足，应回退到经典链，而不是静默接受。

四、演进节奏与落地建议

标准仍在演进，工程上不宜“等标准完全定稿再动”。可行路径是：先在测试环境用草案 OID 跑通签发、解析、验签全链路，记录解析器对未知 OID 的行为；再在受控业务中启用混合证书，观察握手时延与链体积变化；最后根据 LAMPS 正式 RFC 调整 OID 与 ASN.1 结构。需要强调的是，混合证书的“与逻辑”必须写进验证策略，任何“只验一段就放行”的实现都会让后量子部分形同虚设。兼容性设计的本质，是在标准收敛过程中用可回退的双轨机制换取迁移时间，而不是一次性替换整条信任链。