要約

  • RFC 9810は、要求どおりの証明書を得た accepted と、類似しているが変更を含み差分確認を要求者に委ねる grantedWithMods を区別する。
  • CMP応答の認証は送信元とトランザクションの連続性を証明できるが、主体名、SAN、有効期間、Key Usage、EKU、制約、ポリシーが承認済み意図と一致することまでは証明しない。
  • 要求、実際の証明書、項目差分、変更権限、受理・拒否を結ぶ最小限の「証明書意図レシート」を残せる。これはDaniel Kadeによる編集上の提案であり、RFCのフィールドでも秘密鍵の台帳でもない。

CMPの処理画面では、応答が検証されると「成功」に見える。トランザクションIDは一致し、nonceもつながり、CAの署名も正しい。だが、RFC 9810が二つの肯定状態を用意した理由は、その緑色を一種類にしてはいけないからである。

grantedWithMods は障害を意味しない。CAは、自らが署名する内容に責任を持つ。ポリシーに従って有効期間を短くし、名称を正規化し、シリアル番号を割り当て、未対応の拡張を外し、必要な用途を付与することがある。そこで残る問いは、変更後の証明書が要求者の運用目的にとって受け入れ可能か、誰が判断したかである。

要求テンプレートは発行者への命令ではない

RFC 9810は2025年7月にIETF Standards Trackとして公開された。X.509証明書の作成・管理に用いるCMPを定義し、エンドエンティティ、登録局RA、認証局CAの相互作用を扱う。RFC 4210を廃止し、RFC 9811と合わせてRFC 9480も廃止した。

要求者は CertTemplate に希望する証明書内容を表せる。この構造はX.509の署名前部分に似ており、公開鍵、主体、有効期間、拡張などを状況に応じて指定する。要求前にテンプレートを取得し、CAが期待する値を知る仕組みもある。

それでも、完全な指定はそのままの発行を強制しない。RFC 9810は、要求者が全項目を指定してもCAが実際の証明書を変更できると明記する。accepted は「要求どおり」、grantedWithMods は「似たものを受け取り、差分確認は要求者の責任」という別の結果である。

この区別は、CAの裁量を無制限にするものではない。むしろ、CAの発行判断と要求者の受理判断を混同しないための境界である。両方を一つの成功フラグに変換して自動配備する実装は、その境界を消している。

差分は書式ではなく権限を変え得る

RFC 5280の TBSCertificate には、シリアル番号、発行者、有効期間、主体、SubjectPublicKeyInfo、拡張などが含まれる。これらは証明書の外見ではない。誰または何を表すか、いつ使えるか、鍵にどの行為を認めるかを構成する。

Key Usageはデジタル署名、鍵暗号化、鍵合意、証明書署名、CRL署名などを区別する。Extended Key Usageは用途を追加する。Basic ConstraintsはエンドエンティティとCAを分け、認証パスを制限できる。SANはサービス識別子になり得る。Certificate Policiesは依拠当事者が適用条件を判断する手がかりになる。

したがって、全差分を同じ重大度で扱うべきではない。CAが選ぶシリアル番号は通常の差分である。期間短縮は安全側の変更かもしれない。プロファイルに定めた同値の名称正規化もある。一方、公開鍵の置換、別SAN、予期しないEKU、CA署名能力、critical属性の変更、未知のcritical拡張は、実際の権限を変える。

RFC 9810は、PKI管理役割に関する特定EKUの発行を、CA証明書に元来あった認可の委任として説明する。それは非常に慎重に扱うべき行為であり、正当な主体だけが取得しなければならない。項目差分は、制度上の権限移転そのものになり得る。

ハッシュ比較は異なることを示すだけで、意味を示さない。正規化されたフィールド差分が、有効期間、EKU、SAN、制約の変化を示し、ローカルポリシーが自動許可、追加承認、再要求、拒否を決める必要がある。

認証された応答にも意味の審査は残る

CMPはメッセージ保護、トランザクションID、nonceを使って応答を結び付ける。プロファイルにより共有秘密や署名が使われる。Proof-of-Possessionは対応する秘密鍵の支配を示す。RAは要求を検証・認可し、自らの保護を加え、転送または変更できる。

これらは不可欠である。攻撃者の応答を比較対象にしないための前提だからだ。しかし、正しいCAから届いたことは、変更後の内容をサービス所有者が承認したことではない。送信元の真正性と発行内容の適合性は別の命題である。

RAが変更した場合は、もとのエンドエンティティ値、RAが補正した値、CAが最終的に署名した値、その変更を許した規則を分けて残す必要がある。「RA確認済み」という一語では、どの段階で証拠や用途が変わったのか分からない。

certConf は対象物を受理する判断である

RFC 9810の certConf で、クライアントは受領した証明書を受理または拒否できる。証明書を示す CertStatus で statusInfo を省けば受理になる。該当する CertStatus 自体を省けば拒否であり、空の並びで全証明書を拒否できる。証明書ハッシュと拒否状態を明示する方法もある。

この確認は単なる終了メッセージではない。CAが提示したオブジェクトを要求者が自らの状態に取り込む前の、明確な可逆点である。要求IDが正しいことではなく、実際に届いた証明書に対して判断しなければならない。

軽量CMPプロファイルであるRFC 9483は、accepted または grantedWithMods の後、暗黙確認が成立していなければ certConf と pkiConf を交わす流れを示す。期待した確認が届かなければ拒否として扱う。

implicitConfirm は1往復を省く。要求者が明示確認を不要とし、CAまたはRAが応答で同意する。しかし省略されるのはメッセージであり、ローカル審査ではない。多数端末に使うなら、許可された差分、禁止された差分、期限付き例外を評価器が先に知っていなければならない。

ポリシーと実務が変更理由を説明する

RFC 3647は、何を要求するかを示すCertificate Policyと、CAが手順・統制をどう実施するかを示すCertification Practice Statementを分ける。CMP状態だけでは、個々のフィールドを変更する制度的理由をすべて伝えられない。

要求が2年の有効期間を指定しても、プロファイルが1年を上限にすることがある。要求したEKUが、管理対象端末のクラスに合わないこともある。CA側では正しい発行でも、要求者側の設計には不適合になり得る。必要なのは、どのプロファイルのどの版を要求者が採用したかという証拠である。

同時に、発行者が本来決める項目を異常扱いしてはならない。レシートは項目ごとの決定権を明示し、期待された発行者値と、要求者の権限範囲を変える実質差分を区別する。

CTの可視性は受理でも配備許可でもない

RFC 9162のCertificate Transparencyは、CAの発行活動を監査し、疑わしい証明書を発見できる追記型ログを定義する。同時に、ログ自体は誤発行を防止しないと説明する。

CTに載った証明書は観測可能だが、要求者が受理したとは限らない。RFC 9810は間接的なProof-of-Possessionの場面で、証明書ハッシュを含む certConf を受け取る前に最終証明書をCTへ公開してはならないとする。発行、確認、公開は異なる状態である。

受理後も配備は別である。一つのサービスには配備され、別のサービスでは使われないことがある。依拠当事者はそれぞれのポリシーで検証する。観測可能性は重要だが、全当事者の認可を一つにまとめない。

証明書意図レシートは差分判断だけを残す

提案する証明書意図レシートは、保護された要求、CertTemplate、適用プロファイル、発行証明書の正規化された識別子から始める。CMP状態も記録するが、秘密鍵、共有秘密、復号した集中生成鍵、不要な身元資料は保存しない。

比較対象は公開鍵、主体、SAN、有効期間、Key Usage、EKU、Basic Constraints、ポリシー、必要なName Constraints、critical属性、アプリケーション依存拡張である。各実質差分を「プロファイルで予期」「権限者が承認」「拒否」「未解決」に分類し、評価器とポリシーの版を残す。

受理、公開、配備は別の状態にする。確認方式、当該サービスクラスの受理権限者、例外期限、ロールバック対象、失効・再発行による訂正を記録する。訂正は過去を上書きせず、後続状態として接続する。

レシートはローカルでアクセスを制限する。公開証明書であっても、内部名、端末識別子、例外、登録メタデータは機密性の高い構成図になり得る。CTは公開観測を担い、レシートは内部判断の由来を担う。

実装はプロトコルの正直さを捨ててはならない

Heng Luが分ける仕様、局所判断、自発的採用、実行、観測結果は、この問題にそのまま当てはまる。RFCが状態を定義し、CAが発行し、要求者が受理し、所有者が配備し、依拠当事者が結果を判断する。前段の成功は後段の権限を代行しない。

Running-Code Primacyも「インストールされたものが正しい」という意味ではない。実装の実際を、掲げたルールと比較可能にするという意味である。二つの肯定状態を一つに潰すコードは、プロトコルが与えた統治情報を失っている。

CAによる変更を禁止する必要はない。全件を人が見る必要もない。期待差分をプロファイルで許可し、禁止差分を機械的に拒否し、例外には権限者と期限を与え、配備を別判断にする。それが高速で責任の残る自動化である。

情報源