要約

  • RFC 9883 では、既に認証された署名鍵で、別の鍵確立用秘密鍵を所持していると申告できるが、その所持を技術的に証明したことにはならない。
  • CA は署名証明書のパス、申請署名、名前の同一性、証明書の取得可能性、そして代替を認める明示的なポリシーを確認する。
  • 署名鍵が侵害された場合、その鍵の申告に依存して発行された鍵確立証明書を検索し、失効させる関係表が必要になる。

受付記録には新しい公開鍵、所持申告の属性、正しい署名がそろう。だが、署名を作ったのは既存の署名用秘密鍵である。新しい公開鍵に対応する鍵確立用秘密鍵は、検証可能な動作を一度もしていない。

二つの鍵を一つの事実にしない

PKCS#10 の手順では、主体はまず署名鍵ペアを生成し、通常の申請に署名して署名証明書を得る。次に鍵確立用のペアを生成する。二番目の申請には新しい公開鍵と privateKeyPossessionStatement を入れるが、その申請を署名するのは最初の秘密鍵である。

RFC 9883 は意味を明記している。署名証明書の主体は、鍵確立用秘密鍵を所持していると「証明を示さずに」述べる。証明書ポリシーが許可する場合に限り、CA は通常の所持証明の代わりにそれを受け入れられる。RFC 6955 の DH/ECDH 向け技術方式は PKCS#10 に適さず、ML-KEM のような KEM も扱わない。新しい属性は PKCS#10 と CRMF の双方で使える。

したがって、正しい署名が立証するのは署名鍵をこの申請で制御したことだ。既存の認証済み主体を別の鍵についての主張に結び付けることはできる。しかし、鍵確立用秘密鍵の生成場所、持ち出し可否、現在の可用性、ハードウェア内の保護を示すものではない。

ポリシーが不足分を負担する

CA は RFC 5280 に従って署名証明書のパスを検証し、その公開鍵で申請署名を確認しなければならない。失敗時は拒否する。主体名は一致することが望ましい。主体名や SAN が異なるなら、同じ実体だと判断する方法を証明書ポリシーが定め、判断不能なら拒否しなければならない。

属性は署名証明書を発行者名とシリアル番号で示し、証明書自体も任意で含められる。同じ CA が両方を発行する場合は省略できるが、CA が自ら発行した有効な全証明書を取得できることを前提にする。識別子は取得済み証明書でも、検証済みパスでも、決定時点の状態でもない。

CRMF では ProofOfPossession の署名選択、poposkInput、送信者、鍵確立用公開鍵の複製を要求し、regInfo に申告を置く。構造は PKCS#10 と異なっても、鍵確立用秘密鍵が証明動作をしていない点は同じである。

この属性を署名証明書の取得に使ってはならない。署名可能な秘密鍵なら、自分の申請への署名で直接所持を証明できるからだ。

失効は発行時に設計する

署名用秘密鍵を奪われれば、第三者も所持申告を作れる。RFC 9883 が示す防御は署名証明書の迅速な失効である。侵害を理由に失効させた CA は、その証明書で署名された申告から得た鍵確立証明書も失効させることが望ましい。

そのため、署名証明書から申請、ポリシー版、本人性判断、発行済み証明書へ進める逆引き索引が要る。署名鍵の強度も鍵確立鍵以上であるべきだ。そうでなければ、信頼を肩代わりする側が弱点になる。

情報源