要約

  • BRSKI-AEの登録要求は、新しい秘密鍵の所持証明と、製造時IDevIDに基づく由来証明を内包する。最初のTLSセッションが消えた後でも、遠隔RAが元の証拠を検証できる。
  • 署名済みオブジェクトは認可判断の材料であって、判断そのものではない。RA機能をバックエンドへ委任しても、RFC 9733はドメインRegistrarを参加判断から外さない。
  • Voucher、Registrar同意、RA判断、CA応答、証明書確認、登録状態テレメトリー、実運用アクセスは別々の記録である。一つの「オンボーディング成功」に畳むと責任が消える。

工場へ届いた制御装置は、現地のRegistrarには到達できたが、中央PKIへの回線は切れていた。証明書要求はいったん保管され、回線が戻った時に転送された。バックエンドRAが受け取った頃には、装置を認証した最初のTLSセッションは存在しない。それでもRAは、転送者の説明ではなく、装置自身がどの鍵について何を要求したかを確かめなければならない。

RFC 9733は、その証拠をセッションからメッセージへ移す。BRSKI with Alternative Enrollmentでは、証明書要求が認証済み自己完結オブジェクトになる。将来のLDevIDに使う秘密鍵を所持していることと、製造時に与えられたIDevIDを持つPledgeが要求を発したことを、別の証拠として保持する。

この仕組みは非同期処理に強い。しかし、自己完結とは自己認可ではない。要求は自分の所属ドメインを決められず、証明書属性を承認できず、CAへ発行を命じることもできない。証拠が移動できるようになったからこそ、移動しない決定権を明示する必要がある。

新しい鍵が証明できること、できないこと

所持証明は鍵に関する検査である。PKCS #10は通常、要求対象の秘密鍵で要求自身を署名する。CRMFは、署名できない鍵種向けを含む別方式も扱える。成功すれば、公開鍵に対応する秘密を要求者が操作できると分かる。

だが、新しい鍵は自分を署名しただけで持ち主の身元を獲得しない。誰でも鍵ペアを生成し、その鍵の所持を証明できる。RFC 9733の身元証明、すなわち由来証明は、既存の認証済み資格へ要求を結び付ける。BRSKI-AEでは通常、IDevID秘密鍵で装置識別子を含む要求を保護する。

二つの検査結果は一致するとは限らない。攻撃者が自分の鍵を正しく所持していても、正当なIDevIDはない。本物の装置が由来を示しても、禁止された名前や権限、鍵用途を求めているかもしれない。両方の暗号検証が通っても、所有権、失効、資産台帳、リスク方針によって拒否できる。

したがって監査では、鍵所持、要求由来、ポリシー認可を別フィールドにする。「署名OK」は、発行許可を表すには広すぎ、障害原因を示すには粗すぎる。

最初の通信路から証拠を切り離す理由

従来のBRSKIで使われるESTは、PKCS #10要求をPledgeとRegistrar間のTLSクライアント認証へ結び付けられる。直近のRegistrarにとっては有効だが、さらに奥のRAが同じセッションを見たり再検証したりできるとは限らない。Registrarが「私は認証した」と伝えるだけでは、元の証拠をバックエンドが独立確認できない。

BRSKI-AEは、メッセージレベルで自身を認証する登録プロトコルを採用する。規範的なCMP構成では、PKIMessageの保護がIDevID由来を示し、内部のCRMFまたはPKCS #10がLDevID鍵の所持を示す。Registrarは、消えたTLSセッションを要約する代わりに、原要求を維持して転送できる。

これにより、現地Registrarはドメインの入口を管理し、中央RAは豊富な情報で審査し、CAは証明書を生成する、という分担が可能になる。Store-and-forwardを通っても、運搬者が装置身份の代役になる必要はない。

ただし、トランスポート非依存はトランスポート無関係を意味しない。PledgeからRegistrarまでは既存のTLSまたはDTLSを使う。Registrarからバックエンドへの方式はRFC 9733の範囲外である。CMPの保護は真正性と完全性を与えるが、それ自体は暗号化ではない。後段を保護しなければ、どの装置が登録中か観測され、選択的に妨害され得る。

Voucherが与えるのは信頼先であり、LDevIDではない

代替登録に入る前、PledgeはRegistrarとMASAを介してBRSKIのVoucher交換を行う。Voucherは対象ドメインを認証するための信頼アンカー、典型的にはpinned-domain-certをPledgeへ渡す。装置が偶然見つけたサーバをドメインだと思い込まないための基盤である。

Voucherは重要だが、装置のLDevID証明書ではない。後続要求の承認、CA発行、ネットワーク参加を証明しない。「どのドメインを信じるべきか」を支え、「そのドメインが何を許可したか」は別の証拠に残す。

Imprint後、PledgeはLDevID秘密鍵を生成し、自己完結要求を送る。CMP応答はVoucherで確立したアンカーに基づいて検証する。二つの工程は連鎖するが、同一ではない。Voucherがドメインを定め、そのドメインPKIが特定の鍵と属性へ証明書を出すか決める。

管理画面がVoucher成功だけを「装置承認」と表示すると、その後のポリシー拒否が不可解になる。逆に証明書だけ残すと、装置がなぜその発行者を信頼したか追えない。両方の記録が必要である。

RAを委任してもRegistrarは迂回できない

RFC 9733の統治上の要点は、Registrarがドメイン参加の判断に残ることだ。RegistrarはRA機能の一部または全部を別システムへ委ねられるが、PledgeがRegistrarを避けてCAからLDevIDを取れる構成にしてはならない。

同意の表現は複数ある。厳格な関係における黙示、データベースへの事前登録、別メッセージ、あるいは明示署名である。CMPでは、Pledgeの原要求をRegistrar自身が署名した入れ子メッセージに包む方式が推奨される。バックエンドには二つの発言が届く。「この装置がこの鍵を要求した」と「このドメインが審査への持ち込みを認めた」である。

原要求を残すことで、中間者の要約に依存しない。Registrar署名を追加することで、製造者身份をローカル権限と誤認しない。RAはなお拒否でき、CAは必要な認証と認可がそろって初めて発行する。正当な工場IDが、運用ドメインへの恒久的な通行証になることはない。

障害の所有者も区別できる。IDevID検証失敗は由来、同意欠落はRegistrar、プロファイル不適合はRA、発行内容不整合はCAの問題である。「PKIエラー」一語では改善先を示せない。

非同期キューは現実の時間を止めない

バックエンドが常時接続されない現場で、自己完結要求は大きな利点を持つ。回線が戻るまで待っても、由来証拠は保持される。一方で、待機中に組織上の状態は変化する。

装置の所有者が変わる、Registrar同意が取り消される、証明書プロファイルや信頼アンカーが更新される、応答が失われたため同じ要求が再配送される。古い署名は数学的に有効でも、現在の意思決定を表さない場合がある。

運用系は、Voucher身份、要求鍵指紋、所持・由来検証、要求属性、Registrar同意、バックエンド取引ID、RA判断、CA応答、最終証明書指紋を一つの耐久記録に結び付ける必要がある。再試行は「未承認」と「発行済みだが返答紛失」を区別しなければならない。キュー滞留時間は輸送指標ではなく、判断の鮮度である。

真正性は「誰が署名したか」を答える。現在性は「今もその署名に結果を生じさせてよいか」を答える。この二つを混ぜないことが、非同期設計の中心になる。

証明書応答の後にも終点が複数ある

成功応答には証明書が入り、中間CA証明書や追加アンカーが含まれることもある。CMPでは任意のCertificate Confirmを使える。Pledgeは証明書を受け取り検証した後、自分の要求に適合し登録できたかを肯定または否定で伝える。PKIまたはRegistrarがその確認を受領したと返す。

さらにBRSKIは、PledgeからRegistrarへの必須登録状態テレメトリーを残す。RFC 9733はこれを独立した最終フェーズにしている。CMP確認はPKIに証明書評価を伝え、BRSKIテレメトリーはRegistrarへ登録結果を伝える。宛先と責任が異なる。

その後に、証明書の設置、ネットワークアクセス制御、設定、実際の機能がある。CAが正しく発行しても証明書が使われないことがある。登録成功後にNACが拒否することも、ネットワーク参加後に業務機能が失敗することもある。

状態表示は、Voucher受領、鍵所持・由来確認、Registrar同意、RA承認、CA発行、Pledge確認、登録テレメトリー、運用許可を順に示すべきだ。最後に観測した段階より先を緑にしない。

サービス名が示すのは入口であって権威ではない

RFC 9733はURIを/.well-known/<enrollment-protocol>/<request>へ一般化し、CMP対応Registrarの最小発見手段としてbrski-reg-cmpを登録した。Pledgeは該当エンドポイントを試し、HTTP応答から操作の対応状況を判断できる。

これは機能発見であり、正当なドメイン権限の発見ではない。IANA登録は特定実装の稼働や適合を証明しない。HTTP成功は外側の受領にすぎず、内部CMP取引は待機や拒否かもしれない。エンドポイント、TLS相手、固定ドメインアンカー、登録プロトコル、取引ID、決定主体を同じ追跡線に残す必要がある。

凍結した資料は、特定の鉄道、変電所、ビル、充電事業者がRFC 9733を導入したとは示していない。標準の応用例は設計動機であり、導入報告ではない。ここで主張できるのは、証拠と権限を分ける仕組みまでである。

出典