要約

  • RFC 9646は二つの get-bootstrapping-data 呼び出しの間にHTTP 400を置く。能力通知、サーバーの選択、返送されたCSRはそれぞれ異なる記録である。
  • CSR署名は対応する秘密鍵の所持を示すが、装置の由来、CA承認、証明書の配送、導入、権限ある利用までは示さない。
  • csr-request はRFC 8572のブートストラップデータのように署名できないHTTPエラー内にあるため、信頼していないブートストラップサーバーには使えない。

一つのステータスコードが全体の結論になった

RFC 9646 はSecure Zero Touch Provisioningを拡張し、装置がオンボーディング中に本番環境向けの本人性証明書を取得できるようにする。特徴は、CSRを一回の成功応答で運ぶのではなく、二回の要求と中間の指示に分けたことである。

最初の要求でSZTPクライアントは csr-support を送る。新しい非対称鍵を生成できるか、どの鍵アルゴリズムを扱えるか、どのCSR形式を作れるかを通知する。サーバーがCSRを必要とする場合、HTTP 400を返し、RESTCONFの error-info に csr-request を入れる。ここでアルゴリズムと形式を選び、必要なら証明書要求情報も指定する。

クライアントはその指示を処理し、二度目の get-bootstrapping-data で p10-csr、cmc-csr、または cmp-csr を送る。サーバー、登録局、認証局が検証し、承認した場合に限って、署名済み証明書を含み得るオンボーディング情報が戻る。

HTTPの観測者にとって400はクライアントエラーである。RFC 9646の状態機械にとっては次の作業を指定する期待された遷移である。どちらも正しいが、どちらも発行決定ではない。

能力と実行を一つの欄に入れない

csr-support は可能性の集合である。実際に新しい鍵を作ったこと、十分な乱数を使ったこと、秘密鍵がTPMの外に出なかったことは示さない。サーバーの選択は可能性を狭めるが、まだ命令である。装置が鍵を生成または選択し、指定された要求を構成して二回目の呼び出しを完了して初めて実行記録になる。

この境界はLu Hengの最小初期仕様と整合する。共通仕様は相互運用に必要な受け渡しを定め、CAの審査、証明書の運搬、サービス権限といったローカル判断を隠さない。YANGの選択肢は制度上の承認を代行しない。

「CSR対応済み」という一つの状態では、未通知のアルゴリズムをサーバーが選んだのか、新しいはずの鍵が再利用されたのか、二回の要求が同じ交換に属するのかを後から判定できない。

鍵を持つ者と要求の出所

所持証明では、CSR内の公開鍵を使ってCSRの署名を検証する。成功すれば、要求を作った主体が対応する秘密鍵を制御していたことが分かる。これは強いが範囲の狭い証拠である。

出所証明は、その主体がどの装置または認可された本人であるかを問う。生のPKCS #10構造には出所認証がない。TLSまたはHTTPで認証されたクライアント関係が外部の根拠になり得るため、そのセッション情報をCSRと結び付けて保存しなければならない。ファイルだけを残せば、所持証明は残っても出所は消える。

CMCとCMPは、PKIまたは共有秘密による出所認証を扱える。またCAの前段に登録局を置ける。それでも自動承認にはならない。IDevID証明経路、共有秘密の識別、またはプロトコル保護を検証し、その後に発行方針を適用する必要がある。

メーカー鍵を再利用する場合、IDevIDの証明経路を検証し、CSRが同じ鍵対を使うことを確かめる。新しいローカル鍵の場合、CMCまたはCMPがメーカー鍵や共有秘密を用いて由来を結び付けられる。この二つの経路は責任主体も検証内容も違う。

新規性は条件付きの安全性である

RFC 9646はCSRごとに新しい秘密鍵を推奨する。サーバーの指示後に本当に生成されれば、その乱数はnonceに似た役割も果たす。返された証明書に新しい公開鍵が含まれれば、装置は応答を今回の交換に結び付けられる。

しかし key-generation という表示だけでは不十分である。公開鍵指紋が過去と同じなら新規性はない。一方、装置が新しい鍵を内蔵メーカー鍵と同程度に保護できない場合、RFCは弱い新鍵より保護された既存鍵の再利用を勧める。新規性は再送リスクを抑え、強い保管境界はなりすましリスクを抑える。目的が異なる。

動的秘密鍵は漏えいから守られなければならず、HSMやTPMが推奨される。十分な保護がない場合は寿命を短くする運用が必要になる。工場出荷状態へ戻すとき、配備用証明書と新規鍵は利用者データとして消去されるべきである。発行時点だけの記録では、この終点を確認できない。

署名できない指示が信頼境界を決める

RFC 8572には、クライアントがまだ信頼していないサーバーへ接続し、署名済みブートストラップデータに依存する経路がある。RFC 9646の中間指示は同じ保護を受けられない。csr-request はHTTPエラーに入り、そのエラーはブートストラップデータとして署名できないからである。

したがって、信頼していないサーバーではこのCSR機構を使えない。クライアントは csr-support を渡さず、signed-data-preferred を選ぶべきである。これは単なる推奨ログ項目ではなく、誰が本番本人性要求の内容を決められるかという権限境界である。

境界を越えると、未認証の相手が鍵アルゴリズム、要求形式、属性内容を指定できる。後で正しく署名されたCSRが得られても、それは装置が指示に従った証拠にすぎない。指示者の権限を遡って作ることはできない。

発行後にも三つの境界がある

CSR受領後、サーバー、RA、CAは所持、出所、資産情報、要求属性を検証し、承認または拒否する。CSR署名はその組織判断を置き換えない。

RFC 9646は、署名済み証明書をオンボーディング情報内でどう運ぶかを規定範囲外に置く。RFC 9642のkeystoreと関連付ける例はあるが、一つの方法を義務付けない。発行と配送は別の結果である。

導入も別である。証明書を正しい鍵に関連付け、正しい保存先へ反映し、予定したサービスが選択したことを確認する。対向装置による最初の検証成功が運用上の証拠になる。それでもアプリケーション操作の認可は認証より後に残る。

Lu Hengの実行コード優先に従えば、モデルの完全さより実行された遷移と効果を重視する。YANGは交換を記述し、CA、データストア、サービスはそれぞれ別の現実を作る。

一連の証跡を組み立てる

最初にブートストラップサーバーの本人性、信頼アンカー経路、TLSとHTTPの認証事実、csr-support または signed-data-preferred を選んだ理由を記録する。第一要求のnonce、機種・ソフトウェア情報、アルゴリズムと形式も保存する。

HTTP 400はプロトコル遷移として保存し、完全な csr-request、選択結果、要求された内容、時刻、相関IDを含める。鍵については生成か再利用か、公開鍵指紋、乱数またはHSMの証拠、秘密鍵の保護境界、新規性の判定を残す。

第二要求ではCSR形式とハッシュを保存する。所持と出所に別々の判定を付け、IDevID経路、共有秘密、TLS本人性、HTTP本人性のどれを使ったかを明記する。RA/CA判断、証明書指紋、配送、導入、初回利用、更新、消去まで接続する。

現実の層という考え方が防ぐのは、ある層が次の層の権威を借りることである。400、プロトコル指示、鍵所持、出所、制度上の承認、導入状態、運用結果は隣接していても同義ではない。

Sources