要約

  • RFC 9809は、設定署名、信頼アンカー設定署名、更新パッケージ署名、安全クリティカル通信に別々のExtended Key Usageを割り当てた。EKUが示すのは認証された鍵の目的であり、個別の成果物、相手、配備、結果への承認ではない。
  • 発行方針、用途の組み合わせ規則、証明書利用者による強制、対象物の検査、運用上の実行判断、実測結果を分けて記録して初めて、用途制限は統制になる。

同じルートに連なる二枚の証明書がある。一枚は更新パッケージ署名だけを持つ。もう一枚は、それに信頼アンカー設定署名が加わっている。署名も有効期間も認証パスも正しい。それでも更新装置は後者を拒否する。

この拒否は暗号の失敗ではない。通常のソフトウェアを配布する権限と、将来どの署名を信頼するかを書き換える権限を、同じ侵害点に置かないという設計判断である。有効な用途が二つ並んでいても、その組み合わせまで有効とは限らない。

RFC 9809は、その判断を相互運用可能にする語彙を定めた。2025年7月にStandards Trackとして公開され、id-kp-configSigning、id-kp-trustAnchorConfigSigning、id-kp-updatePackageSigning、id-kp-safetyCommunicationの四つを定義する。それぞれ、設定、信頼アンカーを変更する設定、ソフトウェアまたはファームウェア更新、生命・健康・財産・環境に影響し得る通信を対象とする。

RFC Editorの情報ページは、著者Hendrik BrockhausとDavid Goltzsche、公開日、標準上の位置を記録する。IETF Datatrackerには文書の経緯が残る。IANA SMIレジストリは、PKIXの鍵用途枝に41から44までの番号を割り当てた。

OID登録の成果は、権力ではなく同じ言葉である。独自OIDや広すぎる代用品を使わず、CA、証明書プロファイル、検証ライブラリ、監査が同一の目的を機械的に識別できる。IANAは名前を安定させるが、工場の変更窓や車両の安全判断を引き受けない。

RFC 5280によれば、EKUは認証された公開鍵を利用できる目的を制限する。Key Usageもある場合、両方に整合しなければならない。Key UsageのdigitalSignatureが「署名という演算」を許しても、EKUが「何のための署名か」を別に狭める。演算可能、目的適合、対象承認は三つの異なる判断である。

RFC 9809は四用途を本質的に排他的とはしていない。許される組み合わせと禁止される組み合わせは、アプリケーション標準とPKI証明書ポリシーに委ねられる。産業設備、鉄道システム、汎用機器は故障の広がり方が違う。すべてに一枚の組み合わせ表を押しつければ、再利用できる共通語彙が、現場を知らない中央許可へ変わってしまう。

CAは申請者を確認し、正しいEKUとKey Usageを発行し、その主張を支えるポリシーを公開する。しかし、各利用システムの職務分離、保守時間、ロールバック能力までは所有しない。アプリケーション側は必要用途だけでなく、同居を許さない用途も定義する必要がある。RFC 9336は認証パスに許可EKUと除外EKUの制約を導入する。最後に、その規則を本番コードで実行するのは証明書利用者である。

必要なOIDが含まれるかだけを見る実装は不十分だ。禁止された二つ目のOIDを見落とすからである。anyExtendedKeyUsageも同じ境界を弱める。互換性には便利でも、権限を目的別に狭めた証拠にならない。RFC 9809が通常利用を勧めないのは、精密な四つの名前をワイルドカードで再び曖昧にしないためだ。

証明書の受理後には、署名対象そのものの検査が残る。更新には対象機種、版、依存関係、鮮度、処理条件、復旧手順がある。RFC 9019はファームウェア更新の著者、マニフェスト著者、配布者、デバイスなどを分離する。RFC 9124はマニフェストが部品、ペイロード、条件を結び付ける情報モデルを示す。更新署名EKUはマニフェストを完成させず、再起動後の健全性も観測しない。

設定も、正しく署名されたまま間違った機器群へ送られ得る。信頼アンカー設定はさらに特殊で、将来受理される権威を変える。別のOIDは、別鍵、二者承認、オフライン保管、厳しい復旧という境界を作りやすくするだけで、それらを自動的に実装しない。

安全クリティカル通信では、目的と結果の距離が最も大きい。鍵がその通信目的で発行されたことを確認しても、受信側は相手と文脈、鮮度、順序、再送、内容を検査しなければならない。インターロックや故障時の安全動作はシステムの性質である。EKUは列車が停止したことも、警報が間に合ったことも証明できない。

用途の明示には情報開示の面もある。RFC 9809は、TLS 1.2の証明書交換や公開Certificate Transparencyログで目的が見える可能性を指摘する。RFC 5246はTLS 1.2を定義する。RFC 8446ではTLS 1.3のServerHello以後のハンドシェイクが暗号化され、証明書も保護される。RFC 9162は現在のCT枠組みを定める。一つの経路を暗号化しても、公開ログ、別プロトコル、内部資産台帳からの露出は残る。

監査証跡は「証明書有効」の一行では足りない。指紋と認証パス、発行ポリシー、すべてのKey UsageとEKU、組み合わせ規則の版、検証器の判定、対象物のハッシュ・対象・鮮度、実行を承認した主体、配備の範囲と時刻、その後のテレメトリや相手からの受領証を連結する。拒否時も、どの除外規則に触れたかを残す。

Heng Luの「現実の層」は、登録された意味、技術的な検証状態、運用行為、実際の帰結を分離する。「動くコードの優位」は、図面上の方針より本当に走る検証規則を重く見る。「最小初期仕様」は、四つの名前だけを共通化し、将来の組み合わせ判断を各共同体に残す制度設計を説明する。

RFC 9809は四つの許可証を作ったのではない。四つの権限を分けて議論できる座標を作った。その座標を実際の境界に変えるのは、発行者ではなく、規則を選び、動かし、結果を確かめる側である。

情報源