要約

  • RFC 9908 により、EST サーバーは後続の PKCS #10 要求について、固定値、必要なフィールド種別、クライアントが埋める空欄を提示できる。
  • その応答が示すのは作成指示である。CSR 署名、鍵所持、接続相手の認証、CA の認可、発行済み証明書、配備、実利用は、それぞれ別の証拠を要する。

端末が /csrattrs を取得しただけで、管理画面の「ID 承認済み」が点灯したとする。応答には組織単位の固定値、端末が決める共通名、P-256 の指定、値の一部が空いた SAN が入っている。要求書の設計図としては豊富だが、端末はまだ署名済み CSR を送っていない。CA も発行を判断していない。

これは特定製品の事例ではなく、設計上の落とし穴を示す仮想例である。構造化された値は権威的に見えるため、後段の判断まで済んだかのように扱われやすい。RFC 9908 が曖昧さを減らす対象は符号化と意味であり、認可責任を前倒しすることではない。

同 RFC は EST を定める RFC 7030 と、CoAP 上の EST を定める RFC 9148 を更新する。従来からクライアントは、CA が証明書要求に期待する属性を問い合わせられた。しかし、属性 OID だけでなく具体的な値、とりわけ X.509 拡張値をどう伝えるかには解釈差があった。

新しい CertificationRequestInfoTemplate は、PKCS #10 の要求情報部分に似ている。ただし署名の外枠はなく、意味を持って省略できるフィールドがある。部分的に埋めた要求の型であって、完成した CSR でも発行証明書でもない。

subject が無い場合、サーバーは主体 DN に要件を表明していない。特定 RDN を求めるなら、その型を載せる。型と値があればクライアントはその値を使い、型だけなら適切な値を補う。subjectPKInfo も、無ければ鍵要件なし、あれば期待するアルゴリズムを示す。RSA の長さを指定する際には、所望のモジュラス長を持つプレースホルダーも使える。

id-aa-extensionReqTemplate は拡張にも同じ考えを適用する。サーバーは拡張 ID を示し、値を全部与えることも、空にすることも、一部だけ埋めることもできる。SAN の一要素を固定し、別の要素を端末に補わせられる。RFC 8994 の Autonomic Control Plane で特定の subjectAltName を伝える必要は、この機能の具体的背景である。

互換性のため、既存の CsrAttrs ワイヤ構造は維持される。テンプレートの版は v1 で、id-aa-extensionReqTemplate の重複や、旧 id-ExtensionReq との併記は禁止される。これは要求の構文を統一する規則であって、名前の利用資格を立証する規則ではない。

RFC 7030 は /csrattrs と発行を明確に分けている。属性取得は任意であり、その問い合わせへの応答だけなら通常はクライアントの認証・認可を要求しない。さらに、どのような応答を返した場合でも、EST サーバーと CA は後続の登録要求を任意の理由で拒否できる。記入方法を知る権利は発行を受ける権利ではない。

署名済み要求が到着して初めて、別の検査が始まる。サーバーはクライアントを認証し、要求サービスの利用を認可する。CSR 署名は、適用可能な鍵について秘密鍵の所持を示す。EST はその証明を認証済み TLS セッションに結び付けることもできる。RFC 5272 は CMC の所持証明と証明書管理の枠組みを提供する。

鍵の所持、接続相手の認証、名前の認可は別問である。秘密鍵を操作できても特定 DNS 名を名乗る権利は得られない。登録用アカウントが認証されても、CSR に並べた全 SAN が許可されるわけではない。

発行は CA のローカルポリシーに従う。RFC 7030 は手動審査と HTTP 202 による保留も認める。PKCS #10 でも、CA は申請者を認証し、署名を検証し、有効と判断した場合に、要求内容だけでなく CA の選択や他の情報を使って証明書を構成する。正しく符号化された CSR が拒否、保留、変更される余地は残る。

従って、発行済み証明書は独立の成果物として保存しなければならない。シリアル番号、有効期間、発行者、拡張、制約はテンプレートから推測せず、署名された証明書で確認する。テンプレート、完成 CSR、判断記録、証明書を比較して初めて、固定、補完、承認、変更、追加の所在が分かる。

発行は稼働の証明でもない。RFC 5280 は X.509 プロファイルと後段のパス検証を扱う。証明書は未配備のままかもしれず、誤った装置に入る、旧証明書と併存する、相手側ポリシーで拒否される可能性もある。配備台帳と実際のハンドシェイク観測が必要になる。

監査記録は一つの成功フラグでは足りない。/csrattrs の正確なバイト列、サーバー ID、取得時刻、キャッシュ期間、テンプレートのハッシュを保存し、固定値、空欄、省略を区別する。完成 CSR を利用したテンプレート版に結び付け、署名検証、鍵所持、認証 ID、認可入力、ポリシー版、CA 判断、証明書指紋、配備先、観測期間を連鎖させる。

テンプレートに無いフィールドは、サーバーがそこで要件を示さなかったことだけを意味する。後の値が許可済みとは限らない。固定 SAN があれば、サーバーがその値を要求させた事実は残るが、なぜその名前を認可できたのかは説明しない。根拠は ASN.1 の外側に必要である。

旧クライアントへの移行も観測すべきだ。ワイヤ構造の互換性は、全クライアントが新属性や部分値を正しく理解する保証ではない。対応版を棚卸しし、未知要件の黙殺を検出し、旧形式へ戻す条件をポリシーとして決める必要がある。

ロールバックは段階ごとに違う。誤ったテンプレートは停止でき、キャッシュは無効化でき、未処理 CSR は拒否できる。しかし発行・配備後にテンプレートを戻しても証明書は消えない。失効、交換、オフライン端末、検証側の挙動を別途判断する。

Heng Lu の実行コード優先は、公開された仕様と実装された状態を分ける。最小初期仕様、将来判断の局所化、自発的採用も、狭い共通規則を暗黙の権限へ膨張させないための原則になる。

現実の層で見れば、指示、要求、所持、ID、認可、署名物、観測稼働は別々である。データ主権の技術と実務が示す通り、技術的に名前を記入できることと、その名前を主張する組織的・法的権限も同じではない。

RFC 9908 はサーバーの期待を明瞭にすることで EST を改善する。その精密さを守るなら、後続工程を省略してはならない。テンプレートが指示し、クライアントが補完して署名し、サーバーが認証し、ポリシーが認可し、CA が発行し、運用者が配備し、相手が検証する。信頼できる自動化は、その全部を示せる。

出典