要約

  • COSE作業部会は2026年9月24日にC509草案の第21版を提出した。IESGが7月に承認したのは第20版であり、文書はなおRFC編集工程にある。
  • 改訂は署名されるCBORの列を明示し、シリアル番号を小さい値でもバイト列として表し、発行者の省略を主体との完全なバイト一致に限った。
  • DERで署名済みのX.509を可逆変換する方式と、CBORを直接署名する方式では検証の入口が異なる。どちらも証明書パス検証を免れない。

同じ主体名と公開鍵が見える二つの証明書でも、同じ検証器で同じように確かめられるとは限らない。C509はX.509をCBORで小さく表す仕組みだが、形式の違いには署名対象の違いが含まれる。読み取りに成功したというログを、そのまま本人性を受け入れた証拠にするのは早い。

草案は方式を二つに分けている。タイプ3では、すでにDER形式で署名されたX.509を可逆的に再符号化し、元の署名を運ぶ。元のDERを復元できれば、その署名を従来の方式で検証できる。タイプ2はCBORそのものに署名する。ASN.1を扱わない限定的な環境では有用でも、DER専用の検証器に後からそのまま読ませられるわけではない。X.509としての意味が共通であることと、運用中のソフトウェアが両形式に対応することは別の話だ。

第21版が踏み込んだのはこの変換の精度である。C509証明書全体をCBOR配列と記し、その要素が列を成すこと、末尾の署名値を除いたTBSCertificate群が署名対象であることを整理した。シリアル番号は通常のCBOR整数に収まる値でもバイト列で表す。タイプ3からDERへ戻すとき、最上位ビットの条件によって先頭のゼロを復元する。発行者をnullに短縮できるのは、主体と発行者が見た目で似ている場合ではなく、オクテット単位で一致するときだけだ。

これは既存製品の不具合を報告した文書ではない。署名対象を一意に扱うための草案上の明確化である。IESGは7月20日に第20版を承認し、文書はRFC編集待ちとなった。9月24日の第21版を新たなRFC発行や再承認と呼ぶことはできない。確認時点の記録には、RFC編集側で著者の対応が必要であり、IANAの作業も著者待ちとある。草案の圧縮率の例も、現場の導入率を測ったものではない。

安全性の判断は形式だけでは終わらない。草案はC509にもRFC 5280の証明書パス検証を要求し、COSEヘッダー内の証明書情報を検証前から信頼しないよう注意する。IANAに番号があることもアルゴリズムの推奨を意味しない。導入を考える組織なら、方式番号、変換器の版、署名対象の実バイト列、復元したDER、検証器ごとの結果を一緒に記録するのが妥当だろう。これは本稿の提案であって、IETFが追加した手続きではない。

出典