Summary

  • RFC 10003はCMCの転送手段としてHTTP、ファイル、メール、TCPを定義する。各手段の成功は搬送についての事実であり、PKI操作の成否はCMC応答を検証して初めて分かる。
  • 2XX、メール受理、応答ファイルの存在、TCP送信完了のいずれも、CA/RAの承認、意図した証明書の発行、端末への導入を単独では証明しない。
  • Daniel Kadeは、限定的な転送記録、検証済みCMC状態、保留処理、発行証明書の指紋、実運用での有効化を結ぶ「転送・判断レシート」を提案する。

「届いた」と「認められた」の間

証明書管理の自動化では、要求を送り、応答を受け、次の工程へ進む。一見すると一つの取引だが、実際には別々の主体が別々の判断をしている。ネットワークはメッセージを運び、登録局や認証局は申請を審査し、対象システムは発行物を導入する。

RFC 10003は最初の仕事を標準化する。Certificate Management over CMSのメッセージをHTTP、ファイル、メール、TCPで運ぶ規則を定める。RFC 10004では全CMCエンティティにHTTP実装を求め、ほかの手段は任意としている。相互運用に必要な形式、メディアタイプ、接続上の順序がここで揃う。

処理結果はRFC 10002の領域である。Full PKI Responseは成功だけでなく、失敗、保留、一部完了、未対応、証明書受領確認の要求、追加の鍵所持証明などを表せる。遅延発行なら複数往復になる。搬送の完了と、認証局の判断完了は同じ時計では動かない。

2XXはHTTPについて語る

RFC 10003では要求にPOSTを使い、成功したHTTP応答に2XXを使う。本文はPKIメッセージのバイナリ表現で、Full PKI Requestなら application/pkcs7-mime; smime-type=CMC-Request、Full PKI Responseなら smime-type=CMC-Response となる。簡易形式には別の識別子がある。

これらは価値の高い転送証跡を生む。宛先URI、メソッド、時刻、ステータスコード、Content-Type、TLS方針の参照、要求と応答のハッシュを記録すれば、特定エンドポイントが受理して返答したことを確認できる。

しかし2XXは本文中の判断を先取りしない。正常なHTTP応答が failed や pending を運ぶことはあり得る。HTTPサーバーは応答を正しく返し、CMCサーバーは申請を拒否または保留した。双方とも仕様どおりである。

非2XXをすべてCA拒否と呼ぶのも誤りだ。プロキシ、経路、HTTP認証、コンテンツ処理の段階で止まり、CMCの審査に到達していない可能性がある。その場合に証明できるのは「判断を観測できなかった」ことであって、「否決された」ことではない。

保留は終了予定ではなく継続状態

pending には、後で自動的に成功へ変えてよいという意味はない。RFC 10002の PendInfo はトークンと再照会の推奨時刻を示し、要求者にポーリングを求める。partial なら満たされていない部分を追跡する必要がある。トランザクション識別子を使う場合は、Full PKI Responseが取引を完了するまで保持される。

証拠記録もこの未完了性を維持しなければならない。最初の応答は「搬送済み・判断保留」と記録する。次の問い合わせは同じ取引と保護されたトークンに結び付ける。トークン紛失、未実施の再照会、一部だけ処理されたバッチを、時間経過で完了扱いにしてはいけない。

再送にも注意が要る。POSTは冪等ではないため、RFC 10003はTLS 1.3またはQUICを使うCMC実装に0-RTT early dataを禁じる。応答を失ったクライアントが同じ本文を再送すれば、配送事実は二つになる。トランザクションID、nonce、ハッシュがなければ、回復のための再試行、リプレイ、新しい正規申請を区別できない。

媒体ごとに違う早合点

ファイル転送では、一ファイルに一つのバイナリ要求または応答を格納し、推奨拡張子を使う。ディレクトリに要求ファイルが現れた事実は、プロセスが書き出したことを示す。応答ファイルが戻っても、解析、署名確認、内容上の承認は別に確かめる必要がある。

メールではMIMEラッピング、メディアタイプ、ファイル名、base64の例が示される。Message-Id やSMTP受理はメール運用の記録であって、CMC状態ではない。さらに最初のMessage Submission AgentまでTLSでも、その後の中継が認証・暗号化される保証はない。REQUIRETLSは対応中継に保護を要求できるが、非対応箇所があれば不達を招く。

TCPでは追加ラッパーなしにバイナリを送り、pkix-cmc の登録ポート5318を利用できる。同じ接続で次の要求を出す前に完全な応答を待つ必要がある。接続成立や書き込み完了は、応答の真正性や判断内容を示さない。

媒体ごとのログを一律にする必要はない。ただし、搬送観測を業務判断に格上げしないという原則は共通である。

メッセージ保護と経路保護を混同しない

CMCのCMS構造は完全性、認証、機密性を提供し得る。経路側ではHTTPSやIPsecを使え、事前の信頼がない場合に EnvelopedData や AuthEnvelopedData で内容を隠せる。複数の保護があるからこそ、何を証明したかを限定する必要がある。

TLS接続が正しくても、要求者がその名前の証明書を求める権限、RAの検証、CAの発行方針適合は証明されない。CMSオブジェクトが完全でも、どの入口を通ったか、中継で何が起きたか、どの再送に対する応答かは別の記録が要る。

RFC 10003は、CMCクライアントがHTTP認証やCookieを実装する義務を負わないとも明記する。サーバーはそれらの存在を前提にできない。初期信頼の作り方と発行権限は、転送手順の外に残る。

運用文言も「安全に送達」の一語で済ませてはならない。「TLS経路を検証」「CMS本文を認証」「CMC判断は保留」「証明書指紋を発行」「対象機器で有効化」のように主語と層を付けるべきだ。

CMC転送・判断レシート

そこで、私はCMC転送・判断レシートを提案する。これはDaniel Kadeによるガバナンス案であり、RFC 10003やIETFの追加要件ではない。

第一部は媒体事実を記す。HTTPならエンドポイント、POST時刻、コード、メディアタイプ、TLS方針参照、本文の限定ハッシュ。メールなら送信メッセージID、宛先、観測した引き渡し、認証済み中継方針の範囲。ファイルとTCPなら管理対象チャネル、方向、時刻、オブジェクトハッシュである。本文、秘密鍵、資格情報、内部構成を保存する必要はない。

第二部はアプリケーション解釈を記す。Simple/Fullの別、トランザクション識別子、対象body part、完全性と認証の検証結果を含む。バイト列を受け取っても解析できなければ、証拠は転送層で止まる。

第三部はCMC状態を原形のまま残す。保留ならトークンへの保護された参照、推奨照会時刻、解決したポーリングを連結する。一部完了なら未完部分を限定して示す。失敗理由も運用に必要な範囲にとどめ、本人確認資料を一般ダッシュボードへ複製しない。

第四部は発行物が存在するときだけ作る。証明書指紋、発行者、シリアル番号、公開鍵参照、名前、有効期間を申請と判断に結ぶ。応答中の証明書順序を仮定せず、同梱された自己署名証明書を自動的にトラストアンカー扱いしない。

最後に導入を独立して記す。正しく発行されても、機器が旧証明書を保持し、別チェーンを読み、あるいは新しい資格情報を有効化しないことがある。利用側から実際に提示された指紋を観測して初めて、その段階を閉じられる。

緑の数ではなく接続の完全性

監視すべきは、2XXなのに本文を解析できない取引、CMC失敗を成功と表示する集約、再照会されない保留トークン、別IDで重複した要求、期待した鍵・名前と異なる証明書、発行後に導入記録がない機器、旧証明書を提示し続けるサービスである。

指標の分母を「HTTP成功数」にすれば、最も早く返る層だけが優秀に見える。分母は開始した全CMC取引とし、それぞれについて最後に証明できた段階と根拠を答えられる割合を測るべきだ。

RFC 10003はCMCメッセージの道を標準化した。到着と承認を分け続けることが、その道を統治する最低条件である。

出典

  1. Lu Heng — データ主権：技術と実務の現実
  2. Lu Heng — BTW Mediaが存在する理由
  3. Lu Heng — 稼働コード優先
  4. RFC 10003 — CMC転送プロトコル
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — CMC適合要件
  7. RFC 5273 — 旧CMC転送仕様
  8. RFC 5967 — application/pkcs10メディアタイプ
  9. RFC 8551 — S/MIME 4.0メッセージ仕様
  10. RFC 9110 — HTTP Semantics
  11. RFC 9205 — HTTPを用いたプロトコル設計
  12. RFC 9325 — TLS/DTLSの安全利用勧告
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — SMTP REQUIRETLS
  16. RFC 3207 — TLSによるSMTP保護