要約

  • RFC 10002 では、エンドエンティティが署名した内側の要求を保ったまま、RA が外側の PKIData 層に本人性・鍵保有の証言や証明書項目の変更を追加できる。
  • 要求署名、Proof of Possession、本人性確認、RA の証言、変更処理、CA の発行は、それぞれ別の判定である。「検証済み」という一語に集約してはならない。
  • 原要求、全 CMS ラッパー、各制御の順序と権限範囲、CA ポリシー、発行証明書との差分を保存して初めて、事故時に誰の判断だったかを再現できる。

発行後の証明書を申請ファイルと突き合わせたところ、公開鍵は一致していた。ところが、申請にあった拡張が一つ消え、名前を構成する値も変わっていた。申請の署名は有効であり、証明書の CA 署名にも問題はない。

このとき、署名の破壊を探すだけでは調査を誤る。変更は攻撃ではなく、CMC が想定する正規の経路で入った可能性がある。RA が本人確認を行い、署名済み要求を直接書き換えずに外側から変更を指示し、CA が証明書ポリシーに従って採否を決めたのかもしれない。

RFC 10002 は、2026 年 7 月に公開された IETF Standards Track の Certificate Management over CMS であり、RFC 5272 と RFC 6402 を置き換える。構造と制御を RFC 10002、搬送を RFC 10003、適合要件を RFC 10004 が担う。この分割自体が、メッセージが届いたことと、誰の権限で何が発行されたかが別問題であることを示す。

PKCS #10 の署名が固定する範囲

RFC 2986 の PKCS #10 では、主体名、公開鍵、任意の属性からなる要求情報に申請者が署名する。受信側は保護された情報の改変を検出し、対応する署名鍵が使われたことを確認できる。

ただし、その署名は組織名を使う法的権限までは証明しない。署名できない暗号鍵の保有も、それだけでは示せない。CA に全拡張の採用を命じる効力もない。署名は強い事実だが、証明書発行全体の委任状ではない。

CMC の Simple PKI Request は PKCS #10 をそのまま運べる一方、本人性証明や高度な制御を含められない。署名能力を持たない鍵にも適さない。Full PKI Request は CMS の SignedData または AuthenticatedData に PKIData を格納し、複数の要求本体と制御をまとめる。

RFC 5652 の CMS は、保護済みの内容をさらに別の層で包める。RA はエンドエンティティの PKCS #10 や CRMF を直接変更して署名や POP を壊すのではなく、内側を保ったまま自らの制御を外層に加える。RA が複数なら層も増える。

したがって、内側の署名は「申請者が何を保護したか」を示し、外側の署名は「どの中間者が何を追加したか」を示す。どちらも、その中間者が業務上その変更を行う権限まで自動的に証明しない。

鍵を持つことと、誰であるか

Proof of Possession は、要求公開鍵に対応する秘密鍵を扱えるかを問う。署名鍵なら署名が使える。暗号化専用鍵や鍵共有用鍵では、チャレンジ、後続メッセージ、証明書受領後の確認など別の方式が必要になる。RFC 4211 の CRMF はこうした選択肢を備え、一定の条件では RA が POP を実施済みと示す raVerified も定義している。

本人性証明は「この取引を誰に結び付けるか」を問う。RFC 10002 の Identity Proof Version 2 は、共有秘密による MAC を要求材料に適用できる。これは鍵保有とは違う検査である。

秘密鍵を持つ人が、要求した組織名を使えるとは限らない。人事台帳で本人を確認できても、端末内の非抽出鍵を保持している証明にはならない。両者を一つの verified に落とす設計は、異常時に必要な区別を消してしまう。

RA POP Witness は、RA が POP を実施したという下流向けの主張である。RA Identity Proof Witness は、CA が共有秘密を知らない場合や、対面など帯域外で本人確認した場合にも使える。ここで CA が受け取るのは原証拠ではなく RA の証言だ。誰の、どの方式の、どの対象に関する証言で、元の証拠をどこまで保存するのかを別途決めなければならない。

Control Processed はさらに一般的で、制御を処理した、または後段で処理することを示す。本人確認方式まで重要なら、RFC 10002 はより具体的な Identity Proof Witness を使う方向を示す。「処理済み」は、何を確かめたかの代わりにならない。

署名を壊さずに要求を変える

Modify Certification Request により、RA は証明書要求の項目を置換または削除するよう求められる。元の署名対象は変えず、変更命令を外側に置くため、申請者の要求と RA の判断を同時に保存できる。

RA がディレクトリ名を正規化し、未承認の拡張を落とし、組織ポリシーに合う値へ直すこと自体は合理的だ。しかし、対象となる body part、変更前後の値、根拠、RA の識別子が再現できなければ、柔軟性は不透明な権力になる。

ネストされた変更は内側から外側へ適用される。同じ層の複数制御について、標準は順番を定めていない。実装の配列順に結果を委ねると、ライブラリ交換だけで証明書が変わり得る。順序が重要なら、一つの決定へ統合するか、別層に分けて優先順位を明示すべきだ。

CA も要求の複写機ではない。RFC 10002 は、申請者や RA が求めたすべての拡張を含めるよう要求していない。CA はポリシーで省略や変更ができる。ただし、申請者が明示した禁止を許可に反転させるような変更はできない。

そこで必要になるのが三者比較である。原要求、RA が積み上げた変更、CA が署名した証明書を並べ、差異ごとに責任主体とポリシーを付ける。CA 署名の検証だけでは、各フィールドの来歴は分からない。

200 応答の先にある状態

RFC 10003 はファイル、メール、HTTP の搬送を定め、HTTP では POST を使う。HTTPS は盗聴対策になる。それでも TLS 成功や HTTP 2XX は、CMC 制御の処理や最終発行を証明しない。

取引は pending や部分完了になり得る。Query Pending で後から結果を問い合わせ、Confirm Certificate Acceptance で証明書受領後の状態まで扱う。必須の未知制御を処理できない最終サーバーは、PKIData 全体を失敗させる必要がある。知らない制御だけを捨てた成功は、意味の欠けた成功である。

Transaction ID は一連のメッセージを結び、sender nonce と recipient nonce は応答対応やリプレイ対策を支える。再送制御や業務上の冪等性は別途必要だが、これらを保存しなければ同じ要求、別の要求、失われた応答の区別が難しくなる。

RFC 10004 の役割別表は、RA に Modify Certification Request、Control Processed、RA Identity Proof Witness の実装を要求し、RA と連携する CA に対応能力を求める。つまり変更と委任は例外的な裏技ではなく、適合性の中心にある。それでも表への準拠は個別取引の証拠ではない。実装が正しく制御したこと、RA が権限内だったこと、監査資料が残ったことは、運用側が証明する。

RFC 5280 の X.509 プロファイルも、特殊な領域が追加ポリシーを持ち得ること、依拠者が CA ポリシーを確認すべきことを述べる。発行は信頼判断の終点ではない。また RFC 7030 の EST という別方式もあり、CMC の採用そのものを不可避の権威にしてはならない。

証拠を層のまま残す

監査可能な記録は、原要求のバイト列とハッシュから始まる。形式、公開鍵、署名結果、POP 方式、本人確認方式、実施者、時刻、ポリシー版を分けて記録する。

各 RA 層について、署名済みラッパー、RA 証明書、権限範囲、追加制御、削除した層、次の受領者を保存する。変更には対象と前後値を、証言には元の証明種別を付ける。秘密鍵や共有秘密そのものをログに残す必要はない。

CA は、各要求項目への判断と証明書差分を、Transaction ID、nonce、再試行、pending、受領確認、公開、稼働開始まで結び付ける。RA が侵害された場合、原要求の署名が有効でも、正規 RA 鍵で悪意ある外層が作られ得る。改ざんがないという事実は、権限乱用がないことを意味しない。

Running-Code Primacy の観点では、制御名より、実際に層を検証し、RA の範囲を照合し、判断を残すコードが重要になる。Minimum Initial Specification は共通機構を必要最小限にし、証明書ポリシーの裁量を責任主体へ戻す。Reality Layers の区別は、「署名済み」「証言済み」「発行済み」を一つの象徴的安全宣言にしないための実務的な歯止めになる。