Summary

  • RFC 9909 分别为 Pure SLH-DSA 与 HashSLH-DSA 配置 OID；公钥标识属于哪种模式，签名就不能跨到另一种模式，即使数学上可以拼出相应运算。
  • 合格收据必须保存原始 DER、参数是否真正缺席、裸密钥字节、keyUsage，以及签名验证、路径验证和业务授权三个不同结果。

实验室里的证书没有未知算法。解析器能把 OID 显示成 SLH-DSA，密码库也列出了相应实现。它仍然被拒绝，因为 AlgorithmIdentifier 中多了两个字节：DER 编码的 NULL。

这不是产品事故，而是依据 RFC 9909 构造的边界测试。规范写的不是“参数为空”，而是 parameters 必须缺席。NULL 是一个存在的值。把“没有内容”与“没有字段”合并，正是跨实现兼容性最容易失真的地方。

RFC 9909 于 2025 年 12 月作为 IETF Standards Track 文档发布，由 LAMPS 工作组制定。它把 NIST 在 FIPS 205 中标准化的无状态哈希签名算法放入 X.509 证书、证书吊销列表、公钥与私钥格式。SPHINCS+ 是标准化前的名称，但文档明确说二者不兼容。资产表里换一个名字，不能把旧对象变成新对象。

规范列出 12 个 Pure SLH-DSA OID 和 12 个 HashSLH-DSA OID。标识同时表达 128、192 或 256 位安全级别，small 或 fast 参数组，以及 SHA-2 或 SHAKE 内部函数；Hash 模式还把预哈希函数写入名称。NIST CSOR 登记了同一组分支。

OID 在这里不是界面标签。相同 OID 同时标识公钥、私钥和签名算法。RFC 9909 因此明确禁止：带 Pure OID 的密钥不得生成或验证 HashSLH-DSA OID 的签名，反过来也一样。文本甚至承认跨模式运算在数学上可能实现，但互操作合同不允许实现者临时搭桥。

这条规则让“支持 SLH-DSA”暴露出信息不足。若一个验证器通过、另一个拒绝，审计需要看到公钥 OID 和签名 OID 的完整值，而不是家族名。还要看到 parameters 的原始编码。有些旧算法配置习惯携带 NULL，有些实现又会宽松接受。局部容忍并不会修改公共规范，只会制造一个无法携带到下一套系统的私有方言。

密钥字节也有固定形状。公钥是 PK.seed || PK.root，长度为 2*n，其中 n 是 16、24 或 32 字节。SubjectPublicKeyInfo 的 BIT STRING 直接承载这段裸字节，不再套一层 ASN.1。私钥则是 SK.seed || SK.prf || PK.seed || PK.root，总长 4*n，放入 OneAsymmetricKey 的 privateKey OCTET STRING。

OneAsymmetricKey 还可以附带公钥，从而检查公私钥是否一致。但 RFC 9909 同时提醒，一些导入函数尚不接受包含 publicKey 字段的结构。是否保留这个一致性证据，会与最广泛的导入兼容发生张力。答案不在抽象标准里，而在真实的生成、导出、备份、恢复和签名路径里。

keyUsage 继续限制职责。如果该扩展存在，至少要包含 digitalSignature、nonRepudiation、keyCertSign 或 cRLSign 之一；不得包含 keyEncipherment、dataEncipherment、keyAgreement、encipherOnly 或 decipherOnly。SLH-DSA 是签名算法，不是密钥协商工具。即使用途合格，RFC 5280 的链路、名称、期限、吊销与路径规则仍未完成。

Pure 与 Hash 的差别还会在签发前转化为容量决策。Pure 模式处理准备后的完整消息；HashSLH-DSA 使用规定的预哈希，减少进入外部签名模块的数据。RFC 9909 指出，SLH-DSA 会对内部消息处理两遍，因此必须将其保存在内存。大型 CRL 或包含大量 SAN 的证书，可能越过 HSM 的传输或内存上限。

验证方也不能自然地单遍流式处理证书或 CRL。签名中提取的随机量要先进入摘要，而 X.509 编码把签名放在被签内容之后，因此验证器需要持有整个对象。Hash 模式缩小内部 M'，却不能证明某个 HSM、CA、解析器或依赖方已经兼容。

RFC 9814 是重要的邻接规范，也说明不能只按算法名归类。它面向 CMS SignedData，只规定 Pure 模式，并可借助 signed attributes 缩小送入签名设备的材料。这个应用合同不能被搬来证明证书和 CRL 具有同样的处理路径。

无状态也不等于无需计数。RFC 9909 规定一个 SLH-DSA 树不得用于超过 2^64 次签名；若运营规模可能接近上限，应计数、提前销毁密钥或用证书到期时间限制使用。各密钥对必须独立生成，随机数、私钥保护、故障攻击与侧信道防护仍是运行责任。

连勘误也有状态边界。证据冻结时，RFC Editor 的 RFC 9909 勘误页 有两条记录，状态都是 Reported，不是 Verified。被报告、被核验、规范文本更新和实现更新，是四个不同事件。文章不能把第一步写成最后一步。

一份可复核的证书收据应保存：原始 DER 与哈希、公钥和签名 OID、parameters 是否缺席、裸密钥和签名长度、包装结构、keyUsage、空 context、颁发者与主体、信任锚、吊销输入、验证器与密码提供方版本。其后分别记录格式合规、签名结果、路径结果和应用策略决定。若发生传统算法回退，那是另一条路径，不是 SLH-DSA 成功。

Heng Lu 的运行代码优先要求把规范名称落到真实执行结果；最小初始规范把共同层限制在可验证的互操作边界；现实层与符号层则阻止登记行为冒充信任结果。

RFC 9909 的价值不是替系统宣布“已经抗量子”。它把说法拆成可以证伪的步骤：OID 协调语义，字节构成制品，解析器识别结构，配置检查模式与用途，密码运算验证签名，路径建立有限信任，应用决定是否行动。第一盏绿灯亮起时，后六项仍然没有答案。

Sources