要約

  • IESG は 2026 年 9 月 24 日、draft-ietf-jose-hpke-encrypt-22 を Proposed Standard として発行することを承認した。現時点では Internet-Draft であり、RFC 発行や実装配備を証明するものではない。
  • Integrated Encryption は HPKE で平文を一人の受信者へ直接暗号化する。Key Encryption は共有 CEK を保護し、JWE JSON 内で HPKE と ECDH、RSA の受信者を併存させられる。
  • 少なくとも一人の検証成功が必要だが、一人で足りるか全員が必要かはアプリケーションが決める。共有 CEK の機密性は、それを暗号化する最弱の受信者アルゴリズムに制約される。

復号成功のランプが隠すもの

本番サービス、監査保管、災害復旧の三者を受信者とする JWE を考える。本番サービスの鍵で CEK を取得でき、本文の認証も通った。ライブラリは平文を返す。この成功は正しい。

しかし、災害復旧の経路が鍵ローテーション後に壊れていても、同じ平文は得られる。監査保管の経路が社内で禁止済みのアルゴリズムを使っていても、最初の経路は成功できる。そもそも三者すべてが必須だったのかも、平文からは分からない。

9 月 24 日の IESG 承認は、この区別を実務上の論点にした。JOSE ワーキンググループの第 22 版は HPKE を JWE で使う相互運用規則を定める。一方で、特定製品の実装、テストベクトルへの適合、鍵運用、受信者ポリシーの実行を認定しない。RFC Editor の工程も残っているため、既発行 RFC と表現することもできない。

同じ HPKE でも記録の形が違う

Integrated Encryption では、HPKE が本文を直接暗号化する。独立した CEK はなく、enc は存在してはならない。保護ヘッダーの alg が完全指定された HPKE スイートを選び、ek は禁止され、受信者は一人だけである。JWE Encrypted Key には HPKE の encapsulated secret が入り、JWE の IV と Authentication Tag は空になる。

Key Encryption では本文層と鍵層が分かれる。ランダムな CEK と enc で本文を一度暗号化し、各 HPKE 受信者について CEK を暗号化する。受信者の JWE Encrypted Key は CEK の HPKE ciphertext、ek は encapsulated secret である。HPKE の info に入る Recipient_structure は、JOSE 固有の文脈、本文暗号アルゴリズム、任意のアプリケーション情報を鍵導出に結び付ける。

この構造なら、JWE JSON の同じ本文に HPKE 受信者と ECDH-ES+A128KW、RSA-OAEP-256 の受信者を並べられる。本文は一度だけ暗号化され、各経路が同じ CEK への別々の入口となる。

段階移行や復旧鍵の追加には有用だが、評価対象は一経路ではなく受信者集合になる。

「一人以上」は組織の最終ルールではない

第 22 版の復号手順は、複数受信者のうち誰の検証成功を要求するかをアプリケーション判断としている。用途によって一人で足りる場合も、全員の成功を要求する場合もある。ただし一人も成功しなければ JWE は無効である。

JWE JSON の処理結果は、どの受信者が成功し、どれが失敗したかもアプリケーションへ返す。その配列が、ローカルルールを適用するための証拠になる。

A は HPKE で成功、B は古い鍵のため失敗、C はレガシー方式で成功したとする。A のみを必須とする用途なら受理できる。A と B の両方が必要なら拒否する。C のアルゴリズムを禁止している用途なら、C が CEK を開けても無効と判断できる。同じ平文に対し、正当な結論が異なる。

草案は、復号できても使用アルゴリズムがアプリケーションにとって許容されなければ無効と考えるべきだとも述べる。共通仕様は観測可能な事実を揃え、リスクを負う主体に判断を残している。

共有 CEK は最弱経路からも開く

Key Encryption の受信者は、いずれも同じ CEK へ到達する。したがって Security Considerations は、複数受信者時の本文セキュリティが CEK を暗号化する最弱アルゴリズムに制限されると明記する。

混在移行が常に誤りという意味ではない。最新の HPKE 経路だけを見て封筒全体を高く評価できない、という意味である。同じ CEK を取り出せる弱い経路が許可されたままなら、その経路も本文全体のリスクを決める。

第 22 版への変更もモード単位の管理を示す。二度目の JOSE Working Group Last Call は HPKE-4-KE と HPKE-6-KE の削除だけを対象にした。Key Encryption 用の二識別子は第 22 版から消えたが、Integrated Encryption 用の HPKE-4 と HPKE-6 は残った。「HPKE 対応」という一項目では、この差を記録できない。

同じ KEM 鍵ペアを複数の HPKE モードやスイートで使うこと、HPKE と非 HPKE アルゴリズムで共用することも推奨されない。監査記録には受信者名だけでなく、モード、スイート、鍵 ID、許可用途が必要になる。

Heng Lu の現実層という視点を当てると、IESG 承認は制度上の事実、alg はワイヤ形式の事実、受信者成功は暗号処理の事実である。受信者リストと「一人か全員か」は統制上の事実であり、実際の受理結果は稼働系の事実だ。隣接していても同一ではない。

情報源