要約

  • RFC 9763 では、新しい証明書を申請する主体が既存証明書の秘密鍵を支配していることを示し、認証局は既存証明書全体のハッシュを新しい証明書へ記録できる。
  • その拡張は発行時の関係を表すだけで、二枚の併用を命じず、現在の通信で両方の鍵が働いたことも示さない。認証を一つで足りるとするか二つ要求するかは検証側の方針である。
  • 監査では、登録時の証明、発行判断、正確な証明書バイト列、現在の署名、各パスの信頼判断、ネゴシエーション、接続結果を別々の記録として扱う必要がある。

証明書移行には二つの時計がある。一つは申請窓口で動く。既存鍵が要求データへ署名し、認証局がその時点の支配を確認する。もう一つは実際の接続で動く。相手は、その場で届いた証明書と署名を検証し、自分の方針で受け入れるかを決める。

最初の時計が正しく動いたからといって、二番目の時計が自動的に進むわけではない。

RFC 9763 は relatedCertRequest という CSR 属性と、X.509 の RelatedCertificate 拡張を定義する。狙いは、二つのエンドエンティティ証明書が同じエンドエンティティに属するという追加の保証を与えることだ。仕様は同時に、これらの仕組み自体はセキュリティ機能を発生させないと明記する。

古い鍵と新しい鍵は別の仕事をする

既存の証明書を Cert A、新たに要求する証明書を Cert B とする。古典暗号から耐量子暗号へ移る際に、従来の利用先を維持しながら新方式を追加する場面が典型例である。

Cert B の通常の申請には新しい公開鍵が入る。RFC 2986 の PKCS#10 では、主体が申請情報へ署名し、主体名、公開鍵、属性を結び付ける。この署名は、申請された公開鍵に対応する秘密鍵の所持を示す。

RFC 9763 が追加するのは Cert A 側の行為だ。relatedCertRequest は A の発行者とシリアル番号、要求時刻、取得場所、署名を持つ。A の秘密鍵で署名する対象は、DER で符号化した発行者・シリアル番号と BinaryTime の連結である。

RFC 6019 の BinaryTime は、1970 年 1 月 1 日 00:00:00 UTC からの秒数をうるう秒を除いて表す。符号化方法は共通だが、「十分に新しい」時間幅は共通ではない。RFC 9763 は認証局のローカル方針に委ねる。

よって fresh=yes だけを保存しても再検証できない。要求時刻、判定時刻、許容幅、方針の版を残す必要がある。時刻の書式を標準化することと、リスク許容度を中央で一つにすることは別である。

発行前の確認は分解できる

この属性を扱う認証局は、指定された場所から A を取得し、RFC 5280 に従って証明パスを検証する。次に、取得した A の発行者とシリアル番号を certID と照合し、時刻の鮮度を確認し、A の公開鍵で属性署名を検証する。

取得成功、パス成功、識別子一致、鮮度合格、署名合格は同じ事実ではない。取得はどのバイト列を得たかを示す。パス検証は、どの信頼アンカーとポリシー入力の下で受け入れたかを示す。識別子は目的の証明書かを示し、署名は A の秘密鍵が要求に関与したことを示す。

障害理由を「関連付け失敗」の一語に畳むと、リポジトリ障害、置換攻撃、時計ずれ、外部 CA への不信頼が区別できない。運用上必要なのは一つの緑色ではなく、各判定の受領証である。

RFC 5280 のパス検証も、世界共通の無条件な信頼を作らない。信頼アンカーと証明書ポリシーは入力であり、アプリケーションは最小条件より厳しい制約を課せる。key usage と extended key usage が両方あれば別々に処理し、両方に整合する用途に限られる。

確認後、認証局は B に RelatedCertificate を入れられる。そこに含められるのは、申請で示された A だけである。A は B が主張する key usage ビットと extended key usage OID を持たなければならない。発行時に A が有効であることも確認すべきだ。

ただし、A と B の有効期間が実際にどれだけ重なるかは加入者の責任である。A の失効、更新、期限切れによって、正しく発行された関係が運用上使えなくなることはある。発行日の有効性を将来の利用可能性へ読み替えてはならない。

拡張が指すのは「同じ名前」ではない

B の拡張にはダイジェストアルゴリズムと、A 全体をハッシュした値が入る。対象は A の公開鍵だけでも、主体名だけでもない。一回の発行でできた証明書の完全なバイト列である。

検証者は受信した A を同じ方法でハッシュし、B の値と比較できる。この比較はローカルかつ決定的で、オンラインの認証局へ意味を問い合わせる必要がない。最小限の共通層として優れた性質だ。

一方、A を更新すれば同じ主体名と同じ公開鍵でも、シリアル番号、有効期間、拡張、署名が変わり得る。その場合はハッシュも変わる。新 A は B が指した旧 A ではない。資産台帳が主体名だけで証明書をまとめていると、画面上の関係と実際の拡張が食い違う。

この拡張は critical にすべきではない。理解しない実装との相互運用性を大きく損なうからだ。また CA 証明書ではなくエンドエンティティ証明書だけに置く。非 critical であることは段階導入を助けるが、古い実装が無視してもエラーにならない。エラーがないことを関係確認の成功と数えてはいけない。

照合後の動作は検証者が決める

非複合のハイブリッド認証に対応するエンドポイントが適切な認証材料を受け取った場合、関連拡張を探し、もう一方の証明書をハッシュして一致を確かめる。RFC 9763 が共通化するのはここまでである。

一致した後にどうするかは範囲外だ。一つのピアは両方の認証成功を要求できる。別のピアは少なくとも一つを認めるかもしれない。CMS や S/MIME のように署名者が提示方法を選ぶ仕組みと、通信中に認証方法を交渉する仕組みでは制御点も違う。RFC 5652 は CMS の構文を、RFC 8551 は参照される S/MIME の証明書運搬を定めるが、アプリケーションの許可までは決めない。

RFC は、二つの証明書を一緒に使うことは要件でも命令でもないと述べる。同じ主体が秘密鍵を支配するので併用できる、という保証にとどまる。

認証局の署名が検証者の判断を代行しないことは、制度設計として重要だ。CA は登録と発行の事実に責任を負う。接続を受ける側は、自らの信頼アンカー、許容アルゴリズム、現在の署名、用途、接続結果に責任を負う。

登録時の証明はセッションへ持ち越せない

RFC 9763 のセキュリティ考察は、同じ主体が全秘密鍵を支配する証拠が登録時には CA に、利用時には検証者に必要だと区別する。

relatedCertRequest の署名は A の鍵が登録時に動いた証拠である。通常 CSR は B の新しい鍵を扱う。発行された拡張は両証明書の関係を保存する。しかし後日の通信では、プロトコルが要求する鍵が改めて動かなければならない。

B を添付しただけでは B の秘密鍵は認証に参加していない。二つの署名があっても片方を検証しなければ保証にならない。両署名が数学的に正しくても、一方のパスがローカルで認めないアンカーに終われば受け入れられない。関係ハッシュはこの判断を上書きできない。

RFC 9883 との違いもここにある。RFC 9883 は、既に認証された署名鍵が別の鍵確立用秘密鍵を所持するという声明を出し、その別鍵について技術的な所持証明を与えない方式を扱う。RFC 9763 では A の鍵が実際に署名し、通常の申請では B の鍵も CSR を署名し、その後に証明書同士を結ぶ。今回は「声明で証明を代える」問題ではなく、「登録の証明を将来の利用証明へ昇格させない」問題である。

RFC 9955 はハイブリッド署名の性質や検証規則を論じる。RFC 9763 は普遍的な結合規則を選ばない。関係を検証する材料だけを提供し、利用規則は別に残す。

CA をまたぐと信頼の契約が増える

A と B を同じ CA 組織が扱うなら、既存のリポジトリとアンカーを利用しやすい。別組織が B を発行する場合、その組織は A を検証できる設定を持たないかもしれない。RFC 9763 は、契約、事前設定した信頼アンカー、申請・発行・受入方針の合意が必要になり得るとする。

同一主体が二鍵を支配することと、二つの認証ポリシーが同等であることは違う。本人確認、鍵保護、取消応答、加入者義務は CA ごとに異なる。B の CA は A の保護に見合う自らのポリシーを選ぶべきだが、その比較は責任者を持つ判断であり、ハッシュ照合の結果ではない。

「同一主体」を「同一保証水準」と書き換えず、「有効なパス」を「この用途で許可」と書き換えず、「関係一致」を「二重認証成功」と書き換えないことが、報告書の最低条件になる。

証明書の取得にも証拠が要る

属性は A の場所を示す。同一 CA 組織なら HTTP(S) 上の証明書だけを含む CMS メッセージを使える。別組織なら、A の検証に必要な証明書と取消情報を data: URL へ埋め込む方法が推奨される。RFC 2397 はこの URL 方式を定義する。

署名された URL でも取得内容が安全とは限らない。悪意あるコードや壊れた形式を指す可能性があるため、構文を確認して完全に検証する必要がある。ネットワーク取得は観測され、特定の既存証明書との関連申請を処理中だと漏れることもある。埋め込み方式は観測面を減らすが、検証責任を消さない。

記録には取得方式、実データのハッシュ、解析結果、パス材料、取消情報、利用したアンカーを残すべきだ。最終的な B だけでは、発行時に何を検査したか再現できない。

ダウングレードは拡張より前に起きる

ハイブリッド実装では、悪意あるピアが強い方式への対応を示さず、弱い方式だけに依存させるダウングレードが起こり得る。証明書拡張は証明書受信後に初めて処理される。どの能力が提示され、途中で保護され、選択されたかは証明できない。

必要なのは最小許容アルゴリズムの設定、利用可能なら認証された交渉記録、選択モードのテレメトリ、以前は二方式だった相手が一方式へ戻った際の警告である。関連証明書の枚数は準備度を示す。実トラフィックだけが採用を示す。

これは Heng Lu のランニングコード優先と整合する。文書や登録は運用現実そのものではない。最小初期仕様、将来判断の局所化、自発的採用に従えば、共通層はフィールド、署名、ハッシュ、照合を厳密に定め、将来の受入判断を実装者へ残せる。

現実の層として見れば、登録証拠、CA の発行主張、証明書バイト列、ハッシュ一致、現在の署名、パス判断、認可、サービス結果は別々である。一つのステータスへ統合してはいけない。

後から再生できる記録

登録時には CSR 全体、A の識別子、時刻、取得場所、署名対象、署名結果、A のパス材料を保存する。発行時には A の正確なバイト列とハッシュ、B のバイト列、用途比較、ポリシー対応、有効期間の重なりを保存する。

利用時には実際に届いた証明書、両パスの結果、関係ハッシュ、実行された署名検証、交渉モード、ローカル方針の版、接続判断と結果を残す。記録量を増やすこと自体が目的ではない。どの権限とどの機構が失敗したかを後から区別できることが目的だ。

情報源