要約

  • RFC 9883は、認証済みの署名鍵に、別の鍵確立証明書要求の保有声明を担わせる。
  • 声明は保有の主張であり、新しい秘密鍵の技術的な保有証明ではない。
  • CAは署名証明書の認証パスと要求署名を検証し、主体やSANが異なる場合は証明書ポリシーに従って同一性を判断する。

運用上の落とし穴は、署名の検証結果が二つの問いに答えると思い込むことです。署名は「誰が要求を署名したか」を示しますが、「新しい秘密鍵を誰が管理しているか」は示しません。privateKeyPossessionStatementは、すでに証明された署名鍵から別の鍵へ保証を移しますが、その形は署名付きの主張にとどまります。

属性のOIDは1.3.6.1.4.1.22112.2.1です。完全な構造はPrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }で、signerは発行者名とシリアル番号によって署名証明書を特定し、任意のcertはその署名証明書自体を格納します。certを省略できるのは、CA自身が署名証明書の発行者であり、自分が発行した有効な証明書をすべて取得できる場合だけです。これは限定的な取得の例外であり、署名者を推測してよいという意味ではありません。

CAは署名証明書の認証パスを検証し、無効なら要求を拒否しなければなりません。また、その証明書の公開鍵で要求署名を検証し、失敗した場合も拒否しなければなりません。主体名とSANは署名証明書のものと一致すべきです。異なる場合、証明書ポリシーが同等性を説明し、CAが同等性を確立できなければ拒否します。この属性を署名証明書の取得に使ってはなりません。

PKCS#10では、subjectPublicKeyInfoに鍵確立公開鍵を置き、属性に保有声明を置き、要求署名を署名証明書で検証します。CRMFでは、証明書要求が主体と鍵確立公開鍵を運び、形式のproof-of-possessionは署名選択と送信者識別子を使い、regInfoが保有声明を運びます。目的が似ていても、両者の符号化構造を同一視してはいけません。

RFC 5280は認証パスとkey usageの基準を提供します。RFC 6955は、Diffie-Hellman鍵について技術的な保有証明を提供する機構との比較対象です。したがって、RFC 9883の属性自体が2つ目の秘密鍵の暗号学的証明になるわけではありません。対象も、PKIXのML-DSA識別子を扱うRFC 9881や、CMSの署名対象バイトを扱うRFC 9882とは異なります。

Theo Marchの分析では、署名証明書は第二の鍵に対する委任された保証の根に近いものです。これはRFCの要求ではありません。運用側は派生した各鍵確立証明書を認可した署名証明書へ監査上関連付け、同等性の判断を記録し、署名者ごとの件数、主体変更、再送、検証失敗を監視すべきです。保証移転を後から追跡できることが重要です。

この関係は失効の波及を生みます。RFC 9883は署名証明書が侵害された場合、適時の失効が仕様上示される唯一の保護であり、その証明書の声明から得た鍵確立証明書をCAが失効させるべきだと述べます。派生証明書の棚卸し、通知、ファンアウトの自動化はTheo Marchの分析であり、RFCの監査スキーマではありません。署名鍵の強度は鍵確立鍵以上であるべきです。移行では弱い署名鍵を止め、アルゴリズムと同等性の境界をテストします。

試験項目には、正常なパスと署名、無効なパス、改変署名、発行者でないCAでの証明書省略、発行者による取得成功時の省略、同等性説明の有無を変えた主体・SAN不一致、署名証明書申請、弱い署名鍵、そしてPKCS#10とCRMFの各配置を含めます。記録には発行者・シリアル、要求と鍵の指紋、ポリシー判断、発行証明書を関連付けます。

インシデント時は疑わしい署名証明書からの発行を止め、証拠を保存します。侵害を確認し、署名証明書を速やかに失効させ、声明から派生した証明書を列挙して方針に従い評価・失効します。その後、必要な鍵を更新し、同等性と強度の例外を再検討し、再送と新規声明を監視します。これは運用上の分析であり、RFCが完全な対応手順を規定するわけではありません。

出典