要約

  • RFC 9642 は対称鍵、非対称鍵、証明書、中央参照、inline 定義を扱う YANG keystore を規定するが、復旧完了の判定までは行わない。
  • 暗号化された鍵を別装置へ移すには、共有 KEK と装置固有の主鍵、再ラップ、認可、全依存辺を再現する必要がある。
  • 復旧レシートは設定の受理で終わらず、消費サービスが正しい鍵と証明書を選び、許可された操作を実行し、禁止された操作を拒否した事実まで結ぶ。

証明書の期限通知は予定どおり発報された。新しい証明書も同じ非対称鍵の下へ登録された。作業票はそこで「ローテーション完了」となった。

翌日の接続では古い証明書が提示された。TLS サービスの参照が更新されておらず、keystore に新しい物が存在することと、利用側がそれを選ぶことが混同されていた。

RFC 9642 の価値は、この種の材料を ietf-keystore という共通構造で扱える点にある。中央 keystore、inline 定義、鍵と証明書、暗号化された値、期限通知を同じ語彙で表せる。ただし、その語彙は実行結果を自動的には記録しない。

実装機能を固定してから読む

RFC 9642 は 2024 年 10 月に IETF 標準化過程の RFC として公開された。中央 keystore、inline 定義、非対称鍵、対称鍵は別々の feature である。消費モジュールは中央参照か inline かを選択でき、固有の保存場所を追加することもできる。

したがって、「RFC 9642 対応」という表示だけでは移行可能性は分からない。レシートはモジュール revision、feature、YANG Library、datastore、完全なパス、内容ハッシュ、消費モジュールを固定する。リストの name は一つの YANG インスタンス内のキーであり、世界的な鍵 ID や所有権の証明ではない。

leafref が解決できるのは設定上の結合である。稼働中プロセスが同じ revision を読んだか、inline の別定義が優先されていないか、実際の署名で使われたかは別の証拠になる。

system origin は供給経路の要約ではない

RFC 8342 に従い、サーバー提供の組み込み鍵は <operational> や <system> に system origin として現れ得る。製造時に設定された場合も、初回起動やサービス有効化で生成された場合もある。

この印は、通常の運用者設定とサーバー提供値を区別する。しかし生成者、エントロピー、ハードウェア境界、エクスポート可否、導入 firmware、証明書の有効性までは示さない。RFC は組み込み鍵を設定・変更する実装固有プロセスを範囲外に置く。

組み込み鍵へ運用者が配備証明書を追加したなら、鍵と証明書の origin は異なる。復旧時にそれを一つの「設定済み ID」に平坦化すると、後の調査で供給責任と運用責任を分けられない。

暗号化グラフを復元する

暗号化値には、それを保護する対称または非対称鍵への encrypted-by 参照がある。サーバーは KEK 自体か、その KEK を使う API に到達できなければならない。密文が完全でも、この辺が切れれば実行不能である。

RFC 9642 の非規範的な移行例では、多数の鍵を共有 KEK で暗号化し、その KEK を各サーバー固有の組み込み主鍵で保護する。別サーバーでは共有 KEK だけを宛先主鍵向けに再ラップし、他の密文は維持できる。

効率と集中リスクは同じ構造から生じる。KEK を失えば多くのサービスが同時に止まり、置換すれば多くの権限が同時に変わる。バックアップの完全性はファイルの hash だけでなく、全密文、参照辺、主鍵、KEK、形式、algorithm、認可された再ラップ、検証結果が閉じたグラフになっているかで判断すべきである。

主鍵の導入方法は RFC の外にある。標準の図をなぞったという説明は、製品が同じ処理をした証拠ではない。送信元・宛先装置、バックアップ hash、鍵識別子、担当者、二重統制、結果、rollback を記録する。

hidden と encrypted を過大解釈しない

RFC 9640 の hidden は、モデル化された管理面から秘密値を返さない形を表す。メモリ、ローカル API、backup、debug、hardware の全経路で抽出不能だとは言っていない。encrypted も KEK の保護や可用性を自動保証しない。

RFC 9642 は不揮発保存時の暗号化と、不要になった揮発メモリ内平文の zeroize を推奨する。未暗号化で保存するならアクセス不能にしなければならない。YANG ノードから disk replica、swap、crash dump、権限利用の実態は見えない。

そこで復旧証拠には保存層、メモリ処理、コピーの棚卸し、アクセスログ、負のテストを加える。観察できない層については断定を狭める。

NACM の既定値は出来事の記録ではない

書き込み可能なノードには nacm:default-deny-write があり、平文秘密には強い読み取り拒否がある。RFC 8341 は重要な防御だが、どの会話、規則、例外が使われたかを注釈だけでは再現できない。

変更レシートは NETCONF/RESTCONF の identity、channel、NACM policy revision、matched rule、path、before/after、commit、承認、operational 投影を結ぶ。YANG を通らない local、vendor、hardware 経路も列挙する。RFC 6241 と RFC 8040 は安全な管理文脈を与えるが、鍵の履歴そのものではない。

RFC 9642 自体は RPC/action を定義しない。生成や暗号化は SSH/TLS の消費モジュール、または外部の crypto officer が担い得る。完成したノードだけから生成式を逆算することはできない。

証明書の存在からサービス選択へ

非対称鍵には複数の証明書を関連付けられる。終端証明書の参照は鍵と証明書を二段で選ぶ。Verified Errata 8441 は説明文の copy-paste を修正し、これは対称鍵ではなく非対称鍵・証明書ペアだと明確にした。

RFC 9644 と RFC 9645 の SSH/TLS モデルは keystore を消費できる。復旧試験は参照解決、消費設定 revision、鍵操作、session 結果を同じ object version に結ぶ必要がある。

また、keystore は私有鍵の用途を署名や復号に限定しない。証明書は関連公開鍵の用法を制約し得るが、組織上の権限と実際の私有鍵操作は別である。意図した操作の成功と、意図しない操作の拒否を両方試す。

期限通知を完了扱いしない

期限通知は時点を知らせるだけで、配信、受領、承認、置換、参照更新、再起動、次の成功を証明しない。古い backup の復元で、既に交換済みの証明書が戻ることもある。

イベントから受信者、新証明書、鍵との一致、消費側の選択、配備状態、実際の接続までを一本の chain にする。中央は新しいが inline は古い、という分岐も保存する。

復旧レシートの終点

最初に backup object、送信元、schema、feature、datastore、origin、鍵と証明書の fingerprint、全 encrypted-by 辺を固定する。次に双方の主鍵、共有 KEK、認可された再ラップと結果を記録する。

宛先では必要な値が解け、中央/inline 参照が正しい revision を選び、証明書が対応し、消費側が鍵を使い、禁止操作を拒否することを検証する。最後に service outcome と独立 rollback を観察する。

RFC 9642 は最小共通仕様として構造を揃える。実行コードが権限を行使する。復旧という言葉は、この二つを証拠で接続できた範囲にだけ使うべきである。

出典