要約

  • RFC 9802はHSS、XMSS、XMSSMTの公開鍵と署名をX.509証明書およびCRLに収める識別子と符号化を定めるが、消費済みワンタイム索引の履歴は証明書に入らない。
  • 署名が検証できても、秘密鍵の状態が古いスナップショットへ戻ったり、複数装置へ分岐したりしていないことは証明できない。状態継続には別の単調な証跡が要る。

同じ41,200を二度使う

認証局が月曜、次の利用可能索引を41,200として復旧用イメージを保存したとする。主装置はその後、証明書やCRLを署名し、41,259まで進む。金曜の障害で月曜のイメージを復元すると、復旧装置は別の対象に41,200を再利用する。

公開鍵は同じで、OIDもASN.1も正しい。二つの署名を別々に調べれば、どちらも有効になり得る。危険な事実は一方のファイルの中ではなく、異なるメッセージが同じOTS鍵を共有したという関係にある。

RFC 9802は、同じOTS鍵で異なるメッセージに署名した二つの署名を攻撃者が得ると、偽造が計算上可能になり得ると警告する。2025年6月にIETF Standards Trackとして公開された同文書は、HSS、XMSS、XMSSMTのOID、ASN.1表現、公開鍵、署名、Key Usageを定義し、X.509証明書とCRLで相互運用できるようにした。公式記録とIETFの履歴もその範囲を示す。

ただしOIDが答えるのは「このバイト列をどのアルゴリズムで扱うか」であり、「署名者の状態が何本存在したか」ではない。

秘密鍵には戻せない時間が含まれる

ステートレス署名のバックアップでは、秘密材料を守る発想が中心になる。ステートフル・ハッシュ署名では、ワンタイム要素をどこまで使ったかという履歴も同じ重さの資産になる。

RFC 8554は、LM-OTS秘密鍵を高々一つのメッセージに使うよう求める。HSSは多数の鍵を階層化する。RFC 8391はWOTS+、Merkle木、アドレス付き構造でXMSSとXMSSMTを定義する。署名可能数は非常に大きくできても有限であり、各位置の一回限りの消費が安全性に組み込まれている。

復旧対象は「秘密鍵のバイト列」だけではない。確定済みの次索引、予約範囲、公開済み署名、意図的に捨てた状態、復旧世代を一体で扱う必要がある。秘密を失えば署名できない。履歴を失えば、安全でないまま署名できてしまう。

NIST SP 800-208はLMS/HSSとXMSS/XMSSMTの利用条件を定め、鍵生成と署名をハードウェア暗号モジュール内に置く。RFC 9802はその要件を参照し、署名またはOTS索引の記録、公開前の照合、将来状態の事前予約、監査可能な規模を挙げる。再利用が見つかれば、新規署名を止め、過去の出力を再監査し、必要なら失効を検討する。

これらは証明書の属性ではなく、運用者が実行する統制である。

冗長化は複製と同義ではない

ステートレスな鍵なら、保護された二台への複製が可用性策になることがある。ステートフル鍵では、同じ開始点の二台が同じ未来を所有してしまう。RFC 9802は、通常の複製や復旧をそのまま適用すれば、状態整合を保証できず、高い確率でOTS再利用に至ると述べる。

古い復旧点は使用済み索引を再び開く。並列運転は二台を同時に進ませる。応答喪失も危険だ。装置が状態を永続化して署名を生成した後、制御側が返答を受け取れず別装置で再試行しても、最初の索引は未使用には戻らない。

安全な可用性には、単一の状態権威、取消不能な非重複範囲、フェンシング付きリース、ハードウェアの単調カウンタ、あるいは復旧後の最初の索引が過去の全予約を超えると証明する手続が必要になる。方式はローカルに選べるが、過去へ戻らないという条件は共通である。

X.509検証の外側

RFC 5280は証明パス、制約、用途、CRLを定める。RFC 9802により、検証者は新しいアルゴリズムをその枠内で扱える。有効な署名は、提示された鍵とアルゴリズムに対して数学的に成立することを示す。

しかし、並列装置、保存イメージ、放棄された予約、未公開署名、復旧試行は見えない。証明書の有効期間を満たす残量も分からない。もう一方の分岐署名が検証者へ届いていなければ、緑の結果は完全な履歴と分岐した履歴を区別できない。

証跡は分けるべきだ。形式を解釈できること、署名が有効なこと、パスと失効状態を受容できること、索引が一度だけ予約されたこと、消費が永続化されたこと、別装置が同じ位置を使えないこと、公開物と台帳が一致すること、そしてアプリケーションが結果を出したこと。X.509が主に扱うのは前半で、状態の運用者が中間を、利用側が最後を担う。

Lu HengのRunning-Code Primacyを当てはめれば、OIDは調整のための共通言語であり、一意な状態消費は実働システムが維持すべき現実である。最小初期仕様とローカルな将来判断は、共通符号化と各運用者の復旧設計を分離する。現実を可視化するという議論は、見栄えのよい証明書を背後の運用史の代用品にしないための基準になる。

情報源