Summary

  • IANAのSFrame Cipher Suites表は最終更新日を2026年5月5日と記す。Nh、Nka、Nk、Nn、Ntの五欄を備え、0x0006から0x0008までをAES-256-CTR/HMAC-SHA512の三方式に割り当てた。いずれもRecommendedはYで、参照先は草案第06版を指す仮の表記だ。
  • IETF Datatrackerでは当該文書がRFC Editor Queueにある。登録表は番号と定数の公開記録になる。最終RFC、実装、運用時の選択にはそれぞれ別の証拠が要る。

番号だけでは足りなかった表

もとのRFC 9605は、SFrameの暗号スイートについてValue、Name、Recommended、Reference、Change Controllerを登録する仕組みを作った。暗号の細かな長さは本文の定義を読んで確認する形だった。更新草案が求めたのは、ハッシュ出力Nh、複合AEADの基礎となる鍵Nka、暗号鍵Nk、nonceNn、通常は認証タグの分に当たる追加バイト数Ntを登録表にも載せることだ。これは宣伝のための欄ではない。二つの実装が同じ番号を違う長さで処理していないか、見るための欄である。

現行のIANA表では旧来の五方式にも数値が入った。新しい三方式ではNhが64バイト、Nkaが32、Nkが96、Nnが12で共通し、Ntが10、8、4に分かれる。草案は、AES-128-CTR/HMAC-SHA256の内部導出材料48バイトに対して、256ビット側では96バイトが必要だと説明する。初期タグ値も32から64バイトに変わる。付録には暗号処理とSFrame全体のテストベクトルまである。番号、寸法、検証用出力が揃って初めて、実装の説明を測れる。

表のYには別の手続きがある。RFC 9605によると、Specification Requiredによる通常の登録ではRecommendedの初期値はN。YやDを付けたり、その値を変更したりするにはStandards Actionが必要だ。IETFの履歴には、4月の審議で文書のStandards Trackという位置づけと、推奨される登録値の整合性が議論されたことが残る。たった一文字でも、誰がどの手続きで書けるかが決まっている。

仮の参照名を隠していない

新しい三行はRFC-barnes-sframe-iana-256-06を参照する。完成したRFC番号のように見せてはいない。第06版の日付は5月4日、IANA表の最終更新はその翌日。10月28日のDatatrackerはRFC編集待ち、IANAの作業状態はRFC-Ed-Ackと示す。公開台帳の先行と正式文書の仕上げが、同時に読める状態だ。

それでも通話で何が起きるかは、表からは出てこない。RFC 9605はSFrameをいつ使い、どの暗号スイートを採用するかをアプリに委ねる。短い認証タグは偽造への追加対策が必要で、フルサイズのタグなら設計が簡単になる場合が多いとも説明する。新しい三行のNtが10、8、4バイトに分かれる以上、製品側の選択と防御策は具体的に聞ける。Yを読んでそこで質問を止めてはならない。

出典には、新番号を利用した特定の製品や実際の通話記録はない。番号付きRFC、製品設定、運用試験が揃えば採用状況を語れる。現時点で確かなのは、IANAの表が厳密な割り当てと寸法をすでに公開していることだ。