要約

  • RFC 9641 は証明書と公開鍵の名前付きバッグ、中央参照、インライン定義をモデル化するが、通知や参照解決だけで認証の完了は示さない。
  • 期限通知は状態変化の信号であり、配送、受領、交換、配備、参照切替、次回検証の成功まで追跡して初めて運用上の閉路になる。
  • 受入レシートには、設定由来、解決した正確なアンカー、相手の実体、経路、時刻、サービス名、用途、失効方針、検証理由、認証後の権限判断が必要である。

監視画面には、証明書の期限通知が一件表示されていた。発生時刻も対象エントリも正しかった。運用報告はその一行をもって「更新制御は作動した」と結論づけた。

しかし、通知先の購読者は保守中だったかもしれない。代替証明書が中央バッグに追加されても、あるクライアントはインラインの旧証明書を持ち続けたかもしれない。新しいオブジェクトが存在しても、実行中の検証器が古いキャッシュを使っていた可能性もある。信号は開始点であって、結果ではない。

RFC 9641 は ietf-truststore により、証明書と生の公開鍵を名前付きバッグとして管理し、他の YANG モデルから中央参照できるようにする。消費側はインライン定義も選べる。共通の設定面を整える一方、個々の認証判断を中央モデルに吸収しない。この節度こそ、運用側が守るべき境界である。

通知から次の成功まで

RFC 9641 は 2024 年 10 月に IETF NETCONF ワーキンググループから Standards Track として公開された。実装が対応する場合、証明書エントリは期限が近づいた時点、または期限到来時に certificate-expiration 通知を出せる。

通知が直接証明するのは、実装がある時刻にある期限条件を報告したことまでである。受信者が存在したこと、配送が成功したこと、担当者が確認したこと、交換物が正当だったこと、全消費者が新しい物を解決したことは別の証拠を要する。

閉路には、機能の有効化、購読設定、発生イベント、配送先、受領確認、交換証明書の指紋、承認、参照変更、配備状態、実行中の解決結果、次の検証成功を並べる。失敗も残す。中央バッグは更新済みだがインライン設定が古い、証明書は未期限だが名前照合に失敗した、という分岐は期限だけを見ても分からない。

バッグの説明は実行規則ではない

証明書バッグと公開鍵バッグは共通目的ごとに整理される。証明書バッグでは目的を説明することが推奨され、公開鍵バッグでは必須である。だが説明文はガバナンス上の入力であり、実行された制約ではない。

消費コンテキストや補助方針が狭めない限り、設定されたアンカーは、任意の名前を含み得る証明経路を任意の目的に使うため暗黙に信頼される。汎用モデルが広いのは再利用のためである。production-server と呼ばれるバッグが、自らホスト名や Extended Key Usage を検査するわけではない。

RFC 9645 の TLS 用 grouping などは、どこで信頼ストアを選ぶかを表現できる。それでも実装は、参照名、用途、アルゴリズム、失効などの具体的方針を実行し、その判断を残さなければならない。生の公開鍵と X.509 証明書を同じ一語の「信頼」で処理したことにしてはならない。

中央参照とインラインは時間の持ち方が違う

対応 feature がある場合、inline-or-truststore grouping は、インライン定義と中央信頼ストア参照のどちらかを必須選択にする。ある瞬間に双方が同じ DER バイトを持てば、同じ結果を返せる。しかし更新の所有者と波及範囲は異なる。

中央バッグは、危殆化または期限切れのアンカーを一度に交換できる。一方、一回の誤変更が複数サービスの受入面を同時に変える。インライン定義は変更を局所化するが、オフライン機器や別運用チームでドリフトしやすい。

ゆえにイベント記録は、バッグ名だけでなく、解決されたオブジェクト ID、正確なバイトまたは指紋、内容ハッシュ、データストア由来、消費側設定パス、解決時刻を固定する。可変の名前は設計を示す。受入レシートは、その時点で使われた版を示す。

system 由来は製造履歴ではない

機器には、メーカーサービス、安全なブートストラップ、公開認証局のためのアンカーが組み込まれることがある。RFC 9641 はそれらを operational に、system データストアを実装する場合は system に、通常の intended 設定とは異なる由来で表す。

この区別は、メーカー提供の状態を運用者の選択と誤認しないために有効である。ただし RFC は、組込みアンカーを設定・変更する方法を実装固有としている。system という由来は、工場で誰が承認したか、どのビルドが導入したか、更新がどう認可されたか、問題のセッションで選ばれたかを証明しない。

RFC 8572 の安全なゼロタッチ設定では、初期信頼が後の管理主体を決め得る。意図、system、operational の各層を一枚の一覧に潰せば、その権限移転を追えなくなる。

NACM の拒否と保存時保護を分ける

信頼ストアのノードと参照には nacm:default-deny-write が付く。RFC 8341 に従い、明示的な許可がない書込みは拒否から始まる。公開情報でも、置換すれば相手の受入先が変わるため妥当な防御である。

だが既定拒否は、過去の変更レシートではない。NETCONF または RESTCONF の認証主体、保護チャネル、適用された NACM 規則版、合致した規則、対象パス、変更前後、業務承認、コミット、operational への投影を結ぶ必要がある。RFC 8342 はデータストアを区別するが、因果関係までは自動生成しない。

さらに YANG は保存時保護を規定できない。API と NACM が守るのは管理面の経路であり、特権ローカル処理、パッケージ更新、バックアップ復元、保存媒体の破損は別経路である。実装の改ざん防止証拠を独立して確認しなければならない。

経路の成功からサービス受入へ

X.509 では RFC 5280 が証明書経路検証を定義する。検証器は候補経路を選び、制約とローカル方針を処理する。RFC 6125 は、経路の有効性と期待したサービス identity の照合を分ける。RFC 8446 は証明書と署名が交換される TLS セッションを与える。

受入の説明には、相手証明書または公開鍵、セッション ID、解決したバッグとアンカー、候補経路と採用経路、検証時刻と時計、期間、参照 identity、照合規則、Key Usage、Extended Key Usage、名前制約、証明書方針、アルゴリズム、必要な失効情報、検証器の版、理由付き結論が要る。

認証の後には認可がある。正しく認証された相手でも、テレメトリー閲覧だけが許され、設定変更は拒否され得る。ブートストラップ用 identity に日常運用権限を与える必然性もない。二つの判断を別々に保存する。

受入レシートを組み立てる

モジュール revision、feature、正確なパスから始める。インライン、中央、組込みの区別、intended・system・operational の由来、変更主体、承認、NACM、保存時完全性を記録する。実行時には、消費サービスと設定版を正確なオブジェクトへ解決する。

そこへ相手、セッション、経路、時刻、名前、目的、方針、検証結果、認可結果を結ぶ。中央変更は消費者ごとの前後比較を要求し、期限通知は受領・交換・成功確認まで閉じない。

RFC 9641 は共有すべき最小の表現を提供する。各実装が将来どの判断を採用するかは、ローカルな選択と実行証拠に残される。通知やバッグ名を成果に見立てず、状態から決定までを具体的に結ぶことが信頼の管理である。

出典