要約

  • 第 06 版の IETF Last Call は 2026 年 10 月 9 日までで、文書はまだ Internet-Draft、IANA レジストリも未変更である。
  • JWS の署名・MAC は EUF-CMA、JWE の鍵管理は暗号化処理全体の IND-CCA2、内容暗号化は AEAD を基準に審査する案だ。
  • 基準の明文化は登録判断を説明しやすくする一方、ライブラリ、鍵、設定、展開、個々の通信を保証しない。

レジストリが問う内容を狭くする

IESG は 9 月 25 日に Last Call を開始し、10 月 9 日まで意見を募っている。Datatracker 上は Proposed Standard を目指す作業中の草案であり、IANA review needed の状態だ。Last Call は決定でも、表の更新でもない。

現行の RFC 7518 は Specification Required と公開レビューを採用し、Designated Experts に重複、一般性、記述の明確さ、暗号学的な信頼性を確認させる。第 06 版は、この広い「信頼性」を三つの攻撃モデルに結び付ける。

JWS の署名と MAC には EUF-CMA を求める。選んだメッセージの正しい認証結果を取得できても、新しいメッセージの有効な結果を偽造できないという目標だ。JWE の内容暗号には AEAD を求める。平文の機密性だけでなく、暗号化しない関連データの真正性と完全性も守る。

鍵管理の文章はさらに重要である。IND-CCA2 の対象を、鍵管理アルゴリズム単体ではなく、そこから生じる JWE 暗号化処理全体 と明記した。安全な部品を使っていても、組合せ、パラメータ、エラー処理、フィールドの結び付けが弱ければ全体の主張は成立しない。レビュー資料も部品の境界を越えなければならない。

数式で裁量が消えるわけではない

草案は「合理的に満たすと考えられる」アルゴリズムを承認対象とする。単一の証明書式や試験所を指定してはいない。形式的な議論、公開研究、長期の検討、構成全体の分析をどう評価するかは、なお専門家の判断である。

それでも改善は大きい。申請者と審査者は、EUF-CMA を示したのか、IND-CCA2 の範囲が JWE 全体に届くのか、enc が関連データを認証するのかを具体的に議論できる。「暗号学的にもっともらしい」という一語より、理由と反論を記録しやすい。

Deprecated または Prohibited として登録する場合は新基準の対象外になる。レジストリには、推奨しない方式を識別する役割もあるからだ。したがって、表に存在することを採用許可と読むのは誤りである。

登録後に必要な別の証拠

凍結時点の IANA 表は従来の状態を保っていた。監査では、草案の版、Last Call、最終 RFC、IANA の変更、製品が参照した表の時点を分けて残す必要がある。

一行の登録情報は、識別子、用途、実装要件、変更管理者、仕様と分析文献を示せる。しかし、どのソフトウェア版が実装したか、構成が分析対象と一致するか、鍵がどう生成・保管されたか、ダウングレードを防いだか、実際の通信が目的を達したかは示せない。

Heng Lu の Minimum Initial Specification を編集上の物差しにすると境界が見える。相互運用に必要な共有安全不変条件は共通層に置ける。一方、公開や登録だけで採用を宣言してはならず、実装と運用が現実を作る。三つの目標は共通層を強くするが、ローカルな判断を代行しない。

出典