要約

  • 9月23日に公開されたIETF SCITTのCCF向けCOSE受領証案の第05版は、データ構造のアルゴリズムに加えて二つの証明種別をIANAに申請する。
  • 第04版にはアルゴリズムの申請しかなかった。第05版は構造番号2を希望し、その下に包摂証明のラベル-1、整合性証明のラベル-2を求める。
  • 公開中のIANA登録簿にはまだCCFの行がない。改訂によって審査が必要な状態に戻ったのであり、承認されたわけではない。

証明を受け取るプログラムにとって、構造の番号は入口にすぎない。その番号でどの種類の証明を読めるのか、符号化された値をどう処理するのかが決まらなければ、第三者による独立した検証は難しい。CCFの受領証を扱う草案の第04版は、まさにこの組合せを登録申請で欠いていた。9月12日のIANA専門家の指摘は、構造の申請はあるのに対応する証明が申請されていない、という点だった。23日の第05版はその穴を二つの明示的な申請で埋めた。

申請先は別々の登録簿である。構造アルゴリズムの登録簿では、CCF_LEDGER_SHA256 に値2を希望する。証明の登録簿では、その構造に属する包摂証明を-1、整合性証明を-2として求める。既存の登録簿にも-1と-2は載っているが、対象は RFC9162_SHA256 の構造1だ。同じ負のラベルだけを見てCCFの証明が登録済みだと解釈してはいけない。構造と証明種別の組が意味を定める。

第05版は受領証内での置き場所も整理している。保護されたヘッダーの vds が構造を示し、保護されないヘッダーの vdp マップが証明を種類別に収める。RFC 9942が定めるCOSE受領証の枠組みに沿って、草案は包摂と整合性の検証手順を記す。しかし、草案を提出したこととIANAが番号を割り当てることは別だ。文書自体も2を希望値と呼び、割当て待ちの仮置きとして扱う。

手続きの記録を追うと、第04版は IANA - Not OK だった。第05版の提出に伴い表示は Version Changed - Review Needed へ変わったが、専門家レビューの欄には以前の Issues identified が残る。IANAの公開表は構造1とその二種類の証明だけを示す。新しい文書の掲載を、規格化や登録完了の知らせと取り違えれば、実装の説明まで誤る。

なお、整合性証明の検証には、検証者が以前に確かめた古いルートが必要だ。受領証と同時に渡された値と照らすだけでは独立した根拠にならない。草案は、整合性だけでは登録ポリシーの正しい運用も保証できないと明記する。今回の修正対象は、そのような運用判断ではなく、共有の証明形式を指定する登録上の欠落である。

出典