要約

  • 9月6日、JOSE Working GroupはnoneとRSA1_5を非推奨にする第05版をIESGへ送付し、公開を要請した。これは審査の引き継ぎであり、IESG承認、RFC化、IANA登録の変更完了ではない。
  • 案は両アルゴリズムを既定で無効にし、新しいJOSE仕様での利用を禁じる。その一方、既存アプリケーションは特定のオブジェクトまたは操作に限って有効化できる。この例外にはローカルな終了時計が必要だ。

四つの主体に異なる指示

Datatrackerの履歴では、2026年9月6日にWorking Groupの状態が「Submitted to IESG for Publication」へ、IESGの状態が「Publication Requested」へ移った。担当Area DirectorにはDeb Cooleyが記録され、document shepherdのwrite-upも掲載された。

しかし、第05版は6月23日付のInternet-Draftである。IESGはまだ承認しておらず、IANAも提案された行変更を実施していない。調査時点のJOSEレジストリでは、noneはOptional、RSA1_5はRecommended-のままだった。未完了の手続きを示す差であって、遅延や拒否の証拠ではない。

承認されれば、案はRFC 7518を更新し、責任を四つに分ける。JOSEライブラリの開発者はサポートを非推奨にすべきである。アプリケーション開発者は既定で無効にしなければならない。固有の必要があるアプリケーションは、そのオブジェクトまたは操作だけで有効にしてよいが、全体設定にしてはならない。今後のJOSE仕様は両者を許してはならない。

目標はDeprecatedであり、Prohibitedではない。既存仕様とアプリケーションは利用を続けられるが、将来の更新で代替へ移るよう促される。RSA署名のRS256、RS384、RS512は対象外だ。ここでいうRSA1_5はJWEのRSAES-PKCS1-v1_5鍵管理を指す。

したがって、レジストリの表示、ライブラリにコードがあること、アプリケーション設定、実トランザクションで受理されたことは別々の事実である。「禁止済み」という一語では境界を誤る。

セキュリティと互換性は同じ時計で動かない

noneは署名もMACもないUnsecured JWSを作る。RFC 7518はすでに既定での受理を禁じていたが、案は誤って受理した実装に生じた複数の脆弱性を挙げる。RSA1_5のRSA暗号化はPKCS #1 v1.5パディングを使い、その問題は1998年のBleichenbacher攻撃以来知られている。案はOAEPや楕円曲線方式を代替として挙げ、米国連邦利用に関するNISTの移行指針も参照する。

一方、OpenID Connect Coreには、TLSで伝送を保護する未署名ID Tokenや、未署名request objectという歴史的な利用法がある。Shepherdによれば、IETF 124での議論後、2026年2月に2週間のconsensus callが行われた。妥協文は利用例を認めつつ、非推奨化の結論を維持した。

延長されたWorking Group Last Callでは支持があり、反対はなかったとwrite-upは述べる。IETF 126の投票は公開支持27、反対0、意見なし8だった。文書を前へ進める判断の根拠にはなるが、実装数や利用者数、依存件数の調査ではない。

IANAに運用監視まで背負わせない

IANAは識別子の意味、参照、change controller、推奨度を共有できる。案は将来の登録審査にも基準を足す。JWSの署名・MACにはEUF-CMA、JWEの鍵管理には暗号化処理全体としてのIND-CCA2、JWEの内容暗号にはAEADを求める考えだ。最初からDeprecatedまたはProhibitedとして登録するアルゴリズムには、この追加基準を適用しない。

ただしIANAは、あるサービスが古いオブジェクト向けにnoneを再び有効化したか、取引先がまだRSA1_5を要求するかを観測できない。案はテレメトリー、例外台帳、移行プロトコルを作らない。Shepherdも、新しいプロトコル機構の実装を要求する文書ではないと明記する。

これは中央集権化で埋める穴ではない。IANAの薄いレジストリに、非公開アプリケーションや保護対象、商取引先を集めるべきではない。判断は事情を知る運用者に残し、証拠もその近くで保持すべきだ。

ローカル例外の記録には、正確なアルゴリズム、JWS/JWEの別、許可するオブジェクトまたは操作、サービスと責任者、除去を妨げる依存、補償策、グローバル設定が無効であることの試験、最初と最後の利用観測、移行先、再審査日、失効日が要る。これは本稿の提案であり、Internet-Draft、RFC 7518、IANA、NIST、OpenID Connectの要件ではない。

公開手続きとローカル例外の二つの時計

公開側の時計はArea Director審査、IETF Last Call、IESG評価、RFC化、IANA更新を順に進む。Datatrackerの概要はいまもInternet Standardを表示するが、shepherdはProposed Standardを要請し、前者のメタデータを誤りと記した。これは解消待ちの記録差であって、最終的な位置付けや手続き違反ではない。

ローカル時計は、アプリケーションが意図的に再有効化した瞬間に始まる。期限がなければ「固有の必要」は依存消滅後も残る。最終利用が見えなければ、本物の互換性と触れられない古い設定を区別できない。責任者がいなければ、ライブラリ更新のたびに停止か全面的な再開かを迫られる。

Heng LuのMinimum Initial Specificationは、共通層を安全な既定値と将来仕様の制限に絞り、後の判断をローカルに残す考え方を示す。Running-Code Primacyに従えば、公開は規則を変えるだけであり、何が動くかは設定と観測された取引で証明する。

中央を厚くする必要はない。必要なのは、ローカル例外を名指しし、範囲を絞り、観測し、必ず終わらせることだ。

出典

  1. IETF Datatracker — noneとRSA1_5の非推奨化
  2. Datatracker履歴とshepherd write-up
  3. Internet-Draft第05版
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — JOSEレジストリ
  6. RFC 5116 — 認証付き暗号
  7. RFC 8017 — PKCS #1 Version 2.2
  8. NIST SP 800-131A Revision 2
  9. OpenID Connect Core 1.0
  10. ドラフトのソースリポジトリ
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy