要約

  • 第21版は、元のDERへ可逆変換できるC509と、CBORそのものへ署名するネイティブC509を定義する。
  • 復号と署名検証に成功しても信頼は成立しない。RFC 5280の経路検証は必須で、COSE内の証明書材料も信頼されていない入力である。
  • IANAコードポイントは意味を登録するが、アルゴリズムの推奨や利用許可は与えない。

何に署名したかを残す

タイプ3はDER X.509証明書の可逆なCBOR再符号化である。受信側は元のDERを復元し、既存の署名を検証する。タイプ2はCBORのTBSCertificateへ直接署名する。意味はX.509と同じでも、検証証跡は違う。前者は復元DER、後者は正規CBORを保存しなければ、「C509を読めた」という一語だけが残ってしまう。

小型化は、静的・重複フィールドの省略、OIDの短い整数化、時刻値や一部の楕円曲線点の圧縮から生まれる。これは表現と輸送の成果であり、秘密鍵の現在の管理者、発行者の用途権限、有効時点、アプリケーションの実行許可を証明しない。

草案はRFC 5280第6節と同じ経路検証を要求する。信頼アンカー、CA制約、時刻、名前、ポリシー、重要拡張、用途を調べて初めて信頼判断になる。署名の緑表示は、その途中の一つの受領証にすぎない。

COSE内の証明書は自分をルートにできない

c5b、c5c、c5t、c5uは証明書や参照先を運ぶが、その内容は信頼されていない。自己署名証明書が届いても、別の認可なしに信頼アンカーへ追加してはならない。保護済みCOSEヘッダーは外側を認証するだけで、内側にルート選定権を渡さない。

メディアタイプ、CoAP形式、TLS証明書タイプ、TLSAセレクターも同じである。相互運用できる名前を与えるが、DNSSECやDANEの規則、サービス識別、アプリケーション認可を代行しない。

仕様はIANA登録が推奨を意味しないと明記する。既存証明書を表現するため、非推奨アルゴリズムにもコードが必要な場合がある。TLSレジストリのC509は値4でRecommended = Nである。Nは欠陥認定ではないが、一般的な有効化命令でもない。番号の意味、標準化状態、推奨、ローカル許可は別々だ。

サイズ表の外にある現実

RFC 7925で絞ったIoT証明書ではC509の削減が大きい。Brotliはチェーン全体の重複を別に圧縮できる。FN-DSAやML-DSAでは大きな公開鍵と署名が支配的で、ほぼランダムなため削減は小さい。これらの例は、実網の消費電力、遅延、成功率を証明しない。

境界ゲートウェイでC509をX.509へ戻せば、旧式サーバーを保てる。しかし草案は、未暗号化証明書が必要となり、識別情報保護を損ね得ると警告する。証明書をエンドツーエンド暗号化するプロトコルでは端点実装が必要だ。変換忠実性、パーサー安全性、信頼判断は別に試験する。

第21版は2026年9月24日公開で、IESG承認後にRFC Editorキューへ入り、現在は著者回答待ちで止まっている。これは出版工程であって、RFC番号、技術的否決、導入実績のいずれでもない。

出典