要約

  • RFC 9814 では、署名属性がなければ Pure SLH-DSA はコンテンツを署名し、署名属性があればその DER 符号化を署名する。両者は異なる証拠経路である。
  • 後者でコンテンツを結ぶのは必須の message-digest、意味上の型を結ぶのは必須の content-type であり、HSM の成功記録だけでは上流の結合を証明できない。
  • 大きなコンテンツを HSM に渡さず、ストリーム処理できる利点はあるが、これは HashSLH-DSA ではない。CMS による要約と SLH-DSA のモードを区別しなければならない。

表示値ではなく、どのバイトを署名したか

あるアーカイブシステムが、属性を JSON として保存し、必要な時に CMS を再生成するとする。画面には以前と同じコンテンツ型、ダイジェスト、時刻が並ぶ。しかし、ライブラリ更新後の再生成で属性の型や符号化が変われば、DER バイト列は一致しない。元の署名は再検証できても、「承認時に何を HSM へ送ったか」を新しい JSON から証明できるとは限らない。

RFC 9814 は 2025 年 7 月に標準化され、CMS SignedData で空のコンテキストを用いる Pure SLH-DSA を規定した。ここで重要なのは、署名属性の有無によって Pure SLH-DSA に渡るメッセージが変わる点である。ポスト量子アルゴリズムの導入数だけを追っても、この違いは見えない。

署名属性がない経路

SignerInfo.signedAttrs がなければ、署名入力はコンテンツである。Pure SLH-DSA はそのメッセージに対して動作し、コンテキストは仕様どおり空になる。

CMS には digestAlgorithm フィールドがあるが、この経路でコンテンツを事前にハッシュして SLH-DSA に渡す指示ではない。RFC 9814 は、署名属性がない場合、このフィールドが署名計算に意味を持たないことを説明している。互換性上の値が存在しても、「SHA-256 の結果を署名した」という意味にはならない。

したがって、ダイジェストだけを受け取るリモート署名 API は、この経路をそのまま実現できない。外部ダイジェストをコンテンツの代わりに渡せば別の操作になる。大容量データでは、実際のメッセージを署名・検証経路へどう供給するかを設計しなければならない。

受信側も同様である。ストリーム受信中に CMS 用ダイジェストだけを保存しても、後から Pure SLH-DSA をその値だけで検証できるわけではない。コンテンツの保持、再取得、または検証実装のデータ経路が必要になる。

署名属性がある経路

signedAttrs がある場合、CMS はコンテンツを指定されたハッシュで処理し、結果を必須の message-digest 属性へ入れる。必須の content-type は、カプセル化された、または外部参照されたコンテンツの型を示す。これらを含む属性集合全体を DER で符号化し、そのバイト列を Pure SLH-DSA が署名する。

この経路は一つの署名検証ではなく、次の結合を検証する作業である。

  • 不変なコンテンツ識別子と実際に読み取った全バイトの結合
  • 読み取ったバイトとハッシュアルゴリズム、ダイジェスト値の結合
  • コンテンツと署名された content-type の結合
  • 全属性の論理値と正確な DER バイト列の結合
  • DER と Pure SLH-DSA 署名、公開鍵の結合
  • 証明書パスと業務ポリシー、最終判断の結合

HSM が直接証明するのは通常、指定された鍵が指定された入力を署名したという一部分である。オブジェクトストアからどの版を読んだか、ハッシュが途中で再開されたか、表示された型が属性と同じかまでは証明しない。

検証者は受信コンテンツからダイジェストを再計算し、message-digest と比較する。同時に、署名された content-type と encapContentInfo.eContentType の一致を確かめる必要がある。型は単なるラベルではない。どのパーサを起動し、どの保存規則を適用し、どの自動処理を許すかを左右するからである。

DER を監査可能な資産として扱う

ASN.1 の属性集合は論理構造であり、署名はバイトに対して行われる。DER はタグ、長さ、値の型、集合の正規順序を決定する。同じように見えるテキスト表でも、実際の型や未知属性が異なれば署名入力は違う。

原本 CMS オブジェクトを保存することが最低条件になる。重要取引では、署名器へ渡した DER バイト列、その監査用ハッシュ、生成ライブラリと版、独立実装による再生成結果も残すべきである。未知属性を表示層が落としても、証拠から消してはならない。

属性構築サービスは鍵管理と同等に可視化されるべき統制点である。秘密鍵が高保証 HSM 内にあっても、通常のアプリケーションが誤ったオブジェクトを選び、content-type を置換し、承認後に属性を追加すれば、署名の意味は変わる。鍵を守ることと、署名メッセージを正しく作ることは別の責任である。

アルゴリズム識別子を一つの物語に固定する

署名属性がある時、SignerInfo.digestAlgorithm は message-digest に使うハッシュを示し、SignedData.digestAlgorithms には各署名者が使うアルゴリズムが反映される。RFC 9814 は、選択した SLH-DSA パラメータセットに対する衝突耐性を満たす十分な出力長も要求する。単に「許可されたハッシュのリスト」に載っているだけでは足りない。

Pure SLH-DSA の署名アルゴリズムには十二の識別子があり、パラメータは存在してはならない。検証者は署名識別子と公開鍵アルゴリズムの整合性を確認する。RFC 9909 が扱う X.509 層は不可欠だが、正しい証明書パスが誤ったコンテンツダイジェストを救済することはない。

RFC 6211 の CMSAlgorithmProtection は、ダイジェストと署名アルゴリズムの識別子を署名属性の内部に置き、外側の識別子が差し替えられる攻撃を抑える。RFC 9814 はこの属性を含めるべきだとしている。欠落を許す互換方針が必要なら、対象、期限、計測を明示するべきで、無言の受理を標準運用にしてはならない。

CMS のハッシュは SLH-DSA の prehash ではない

大きなファイルを外部でハッシュし、小さな DER だけを HSM に渡す図は、prehash API に似ている。しかし Pure SLH-DSA が署名するのは、外部ダイジェスト単体ではない。ダイジェスト、コンテンツ型、その他の属性を含む DER 全体である。

FIPS 205 には Pure と prehash の異なる操作があり、HashSLH-DSA には別の意味と識別子がある。RFC 9814 の CMS プロファイルは Pure を選ぶ。「SLH-DSA prehash」とだけ記録すれば、実装者は誤った OID を使い、検証者は誤った入力を再構成し、監査人は DER を保存対象から外しかねない。

台帳には「Pure SLH-DSA over DER(SignedAttributes)、コンテンツは message-digest で結合」と記すべきである。長いが、将来の移行と再検証に耐える。

ストリーム処理で増える運用上の状態

署名属性を使えば、受信者はデータ到着中にハッシュを計算し、全体を SLH-DSA 呼び出し用に保持せずに済む。送信側も大量データを HSM へ流さずに済む。しかし、ハッシュサービスの入力選択、再試行、供給網、障害処理が新しい信頼境界になる。

中断再開の試験が重要である。再開位置は認証されているか。同じオブジェクト名が別版を指していないか。二つのアップロードの断片が混ざらないか。記録されたバイト長は実読量と一致するか。コンテンツ型は署名対象から取得したか、それとも可変な HTTP ヘッダーか。

一取引の証拠として、不変コンテンツ ID と版、長さ、ハッシュアルゴリズムと値、CMS 型、全属性、正確な DER、SLH-DSA パラメータセット、鍵と証明書 ID、署名、ポリシー版、時刻、各段階の結果を保存する。内容、ダイジェスト、型、追加属性、DER、アルゴリズム、鍵、証明書を一つずつ変え、どの段階で拒否されるかを確認する。

RFC 9814 はベンダー採用率、HSM 性能、移行速度を保証しない。CMS の暗号化や証明書チェーン全体が自動的に耐量子になるわけでもない。乱数、サイドチャネル、故障、鍵生成と保管、鍵ごとの署名回数を 2^64 未満に保つライフサイクル管理は別途必要である。

Lu Heng の最小初期仕様という考え方を適用すれば、最初に整えるべきものは巨大な認証制度ではなく、複数の当事者が同じ事実を再現できる小さな契約である。現実の層は「RFC 9814 対応」という表示ではない。コンテンツからダイジェスト、属性から DER、DER から署名判断までを別の実装で再実行できることである。

出典