要約

  • RFC 10002のProof-of-Possessionは、エンドエンティティが公開鍵に対応する秘密鍵を所持し、使えることを示す。本人性、名前の利用権、証明書発行の承認までは示さない。
  • CMCは本人性の証明と鍵の所持証明を別に運び、同じ主体から来たことを結び付ける。登録局の変更は署名済み要求の外側に残り、認証局は独自の方針で発行、変更、保留、拒否を決める。
  • 調査可能な証跡には、元の要求、所持証明、本人性、すり替え防止の結び付け、各登録局の包み、認証局の判断、CMC応答、発行された証明書、配布、設置、経路検証、失効を順番に残す必要がある。

秘密鍵で署名した証明書要求は、申請者の言葉を固定する。公開鍵を別の鍵へ差し替えれば署名は壊れる。これはPKCS #10が与える重要な性質だ。しかし、言葉を固定することと、その内容を承認することは同じではない。

たとえば要求にサーバー名、鍵用途、有効期間の希望が書かれていても、署名はその希望への権限を証明しない。登録局が後から別の拡張を求めたかもしれない。認証局は方針に合わない名前を削り、要求そのものを拒否することもできる。

2026年7月に公開されたRFC 10002、RFC 10003、RFC 10004は、この間を構造化するCMCの一組である。RFC 10002はCMS上の証明書管理メッセージ、RFC 10003はHTTP・ファイル・メール・TCPによる搬送、RFC 10004はCMCエージェントの適合要件を定める。3文書はいずれもJoseph MandelとSean Turnerを編集者としている。PKCS #10、CRMF、CMS、X.509を引き継いだ共同作業であり、Turner一人の発明ではない。

IETF Datatrackerの2026年9月1日時点の記録では、TurnerはIETF 34から参加し、50本を超えるRFCの著者または共著者で、2007年から2014年までSecurity Area Directorを務め、複数の作業部会で議長を経験している。長い標準化歴は文書の背景を説明する。一方、個別の登録局や認証局に対する承認権を与えるものではない。

POPが証明する範囲を広げない

RFC 10002は、公開鍵に対応する秘密鍵をエンドエンティティが所持し利用できることの証明をProof-of-Possession、POPと呼ぶ。署名、直接のチャレンジ応答、間接方式、公開、アテステーションなどの形があり、CMCが常に全方式を使うわけではない。

方式が強固でも、対象は鍵である。盗まれた秘密鍵は正しい署名を作れる。正規の端末が誤った資産名に登録されることもある。鍵管理者が組織名やサービス名を申請する権限を持つとは限らない。POPが成功したまま、本人性や発行判断が失敗する場面は十分にある。

RFC 2986も、認証局の仕事を署名検証だけにしていない。申請主体を認証し、署名を検証し、要求が妥当なら証明書を作る。ここでいう妥当性には認証局の方針が入る。暗号計算だけで決まる条件ではない。

運用上の誤りは、下位の正しい主張を上位の主張へ言い換えることから始まる。「秘密鍵を使えた」が「本人である」になり、「その名前を使える」になり、「発行を承認した」になる。それぞれの間に、新しい証拠と責任者が必要である。

本人性と鍵を結ぶ処理も一件の検証である

CMCではProof-of-Identityを別に扱う。本人性の証明を含める必要がある場合、Simple PKI Requestは使わない。Full PKI Requestなら共有秘密に基づくwitness、既存証明書、または当事者間で合意した方法を利用できる。

別々の証明には、別々に正しくても組み合わせが誤る危険がある。ある利用者の本人性と、別の利用者の有効なPOPを結合してはならない。RFC 10002は、同じエンティティが本人性情報とPOPを提供したことを保証するよう求める。共有秘密とsubject名の対応、witnessの計算、既存証明書とのリンクは、そのすり替えを防ぐためにある。

したがって、リンク処理を単なる内部手順にしてはいけない。双方の識別子、対象バイト列、検証方法、検証者、時刻、結果を一つの証跡として残す。二つの画面に「成功」と表示されても、共通識別子がなければ同一主体の証明にはならない。

共有秘密にはさらに前史がある。RFC 10002は、秘密を帯域外でどう配布するかを規定しない。誤った端末へ配布した、複数資産で使い回した、再試行のたびに同じ値を残した、といった問題は正しいwitness計算では修復できない。証明の限界は配布方法とともに記録すべきである。

登録局の変更は外側に積み重ねる

CMCのエンドエンティティは鍵ペアを持ち、証明書の対象になる。登録局（RA）は本人確認、鍵生成や保管、要求の束ね、ルーティング、拡張処理を担える。認証局（CA）が証明書を発行する。一つのノードがエンドエンティティ向けにはサーバー、CA向けにはクライアントとして動いても、役割上の権限まで同一になるわけではない。

署名済みのPKCS #10またはCRMF要求をRAが直接変更すれば、署名とPOPが無効になる。RAが証明書の項目を変えるよう求める場合は、元の要求を包む外側のCMCコントロールに記す。RAが複数あれば包みも複数になる。

この設計により、エンドエンティティの要求と仲介者の判断を同時に保存できる。最後の状態だけを残すと、RAが加えた名前や用途まで申請者自身が求めたように見えてしまう。

拡張の扱いも自動承認ではない。サーバーは定義された拡張を処理するが、要求された全項目を証明書へ載せる義務はない。変更する場合も元の意図を反転させてはならない。CAは元の要求、RAの外側の指示、許可されたテンプレート、方針を比較し、最終内容を決める。

発行済み証明書だけでは、何が削られ、誰が追加し、どの方針が働いたか分からない。元の要求だけでも、実際の発行決定を説明できない。両者と中間層を一続きに残して初めて、変更可能でありながら改ざんされない履歴になる。

搬送が成功してもCMCは保留できる

RFC 10003のHTTP搬送では、定められたメディア型をPOSTする。HTTPSは通信路を保護できるが、すべてのCMCクライアントにHTTP認証を義務付けてはいない。通信路の機密性、HTTPの相手認証、CMCの本人性、POPは別の層である。

HTTP 2xxもその層だけの成功だ。内側のCMC応答は、処理中、badIdentity、popRequired、popFailed、未対応拡張などを返せる。配送受付の成功を発行完了と呼ぶことはできない。

CMCが成功を返した後も、実物を確認する。返された証明書の公開鍵が要求と一致するか、subject、名前、用途、方針、有効期間は何か、意図したエンドエンティティへ届いたか。証明書のバイト列を伴わない完了表示は、発行証跡として弱い。

RFC 10004の適合性は、実装があるクラスの能力を満たすかという問いに答える。特定の組織で正しく導入されたこと、特定の申請が承認されたこと、市場で利用されたことまでは示さない。

発行後は信頼経路と利用権を分ける

RFC 5280による経路検証では、トラストアンカー、名前制約、証明書方針、有効期間、失効状態を評価する。その前後に配送、設置、秘密鍵との対応、サービス固有の認可がある。

正しく発行された証明書が端末へ届かないこともある。設置済みでも秘密鍵が違えば使えない。経路が有効でも、アプリケーションはその主体に操作権を与えない場合がある。後日の失効は、以前の有効状態を終わらせる。

Heng LuのRunning-Code Primacyを適用するなら、主張ごとに再現可能な材料を残す。登録では要求、POP、本人性、リンク、RAの包み、CA方針、応答。運用では証明書、鍵対応、設置先、経路結果、状態情報源、ローカル認可である。

最低限の台帳は、申請者と時刻、要求鍵と項目、POPの方法と結果、本人性の方法と限界、両者のリンク、RAごとの変更と署名、CAと方針版、CMC状態、証明書そのもの、配送と設置、失効・交換・訂正を別行にする。後の成功で前の行を上書きしない。

TurnerらのCMC文書が提供するのは、秘密鍵を証明書へ直結させる近道ではない。どの証拠が、どの権限へ届いていないかを示す道筋である。

情報源