Summary

  • RFC 9909 では Pure SLH-DSA と HashSLH-DSA に別々の OID が与えられ、Pure の OID を持つ鍵で Hash の署名を生成・検証することも、その逆も認められない。
  • 運用上の証拠には、parameters が本当に存在しないこと、裸の鍵バイト列、keyUsage、署名結果、証明パス、依存側ポリシーを別々に残す必要がある。

CA の設計会議で「Pure か pre-hash かは HSM 導入後に決める」という欄が残った。ところが、その判断は CA 証明書の発行後には自由に動かせない。RFC 9909 が、公鍵と署名の識別子に同じモードを刻み込むからだ。

これは架空の設計レビューであり、実在製品の障害報告ではない。だが境界は実在する。SubjectPublicKeyInfo が Pure の OID を持つ一方、証明書署名が対応する HashSLH-DSA を名乗れば、数学的に処理を組めたとしてもプロファイル上は使えない。OID が揃っていても AlgorithmIdentifier に NULL が入れば、parameters は「不在」ではない。

RFC 9909 は 2025 年 12 月に IETF Standards Track として発行され、LAMPS ワーキンググループが策定した。対象は X.509 証明書、CRL、公開鍵、秘密鍵である。基礎となる SLH-DSA は NIST の FIPS 205 で標準化された。以前の呼称 SPHINCS+ と SLH-DSA は互換ではないと RFC 自身が明記している。

識別子は Pure 用 12 個、HashSLH-DSA 用 12 個に分かれる。128・192・256 ビットのセキュリティ水準、small/fast、SHA-2/SHAKE をそれぞれ区別し、Hash 側では pre-hash 関数も名称に含む。NIST CSOR は同じ割当てを公開している。

重要なのは、OID が単なる表示名ではない点だ。同じ OID が公開鍵、秘密鍵、署名アルゴリズムを識別する。したがって Pure の鍵を Hash の署名に流用する「親切な互換モード」は、共通仕様を広げる私的方言になる。あるライブラリが受理しても、別の検証器が拒否する根拠は残る。

parameters にも曖昧さはない。すべての対象識別子でフィールドは存在してはならない。DER の 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 フィールドを含む形式を受け付けないインポート関数があると注意する。確認可能性と既存ツールへの移植性は同じ指標ではない。実際の生成、バックアップ、復元、HSM 取込みまで試す必要がある。

keyUsage が存在する場合、digitalSignature、nonRepudiation、keyCertSign、cRLSign の少なくとも一つが必要である。一方、keyEncipherment、dataEncipherment、keyAgreement、encipherOnly、decipherOnly は許されない。署名アルゴリズムを鍵共有の印として扱ってはならない。RFC 5280 の証明パス、名前、期限、失効に関する規則はその先に残る。

Pure/Hash の選択は性能ラベルでもない。Pure は準備されたメッセージ全体を扱い、HashSLH-DSA は規定の pre-hash によって署名モジュールへ渡す量を減らせる。SLH-DSA は内部メッセージを二度処理するためメモリに保持する必要があり、大きな CRL や SAN の多い証明書は Pure で HSM の境界を超え得る。

検証側も証明書や CRL 全体を保持する。署名から取り出すランダマイザーをメッセージより先に処理する必要があるのに、X.509 の並びでは署名が後ろに来るからだ。Hash は内部 M' を小さくするが、特定の CA、HSM、OS、ブラウザーの対応を証明しない。

RFC 9814 は CMS SignedData 向けで、Pure モードのみを定め、signed attributes により署名デバイスへ渡す値を小さくできる。隣接仕様だからこそ混同してはならない。同じアルゴリズムでも、アプリケーションの符号化と処理契約は異なる。

stateless は無制限という意味でもない。一つの木で 2^64 回以上署名してはならず、必要なら利用回数を追跡し、適切な時点で鍵を破棄するか、有効期限で上限を封じる。鍵ペアの独立生成、良質な乱数、秘密鍵保護、故障・サイドチャネル対策も別の責任として残る。

文書修正にも段階がある。証拠凍結時、RFC Editor の RFC 9909 errata には 2 件あったが、どちらも Reported で Verified ではなかった。報告された記述を、検証済みの規範として実装へ取り込むことはできない。

受理証跡には、元の DER とハッシュ、公開鍵/署名 OID、parameters の有無、生の長さとラップ、keyUsage、空 context、発行者、主体、信頼アンカー、失効入力、検証器と暗号プロバイダーの版を保存する。そのうえで形式、署名、パス、アプリケーション判断を別欄にする。

Heng Lu の Running-Code Primacy は、文書の存在より実装された遷移を優先して観察する。Minimum Initial Specification は共通層を検証可能な最小範囲にとどめ、Reality Layers は登録名が実行結果を代弁することを防ぐ。

RFC 9909 が与えるのは「耐量子対応済み」という結論ではない。OID、バイト列、パース、プロファイル、署名、証明パス、ポリシーを切り分ける座標である。CA は最初にモードを決める。依存側は最後に行動を決める。その間の証拠を一語のバッジで消してはならない。

Sources