要約

  • JOSE HPKE草案の第22版は9月24日のIESG会合で提案標準の審議対象となる。公開上の状態はまだ評価中で、承認やIANA登録の完了を示さない。
  • 二度目の最終意見募集では、JOSEにChaCha20/Poly1305の本文暗号化アルゴリズムの登録がないことを理由に、鍵暗号化用のHPKE-4-KEとHPKE-6-KEが外された。統合暗号化用のHPKE-4とHPKE-6は残る。
  • 導入時には「HPKE対応」の一語ではなく、JWEのモード、algとencの組み合わせ、受信者数を確認する必要がある。

まず統合暗号化を見る。このモードはHPKEが平文を直接暗号化し、受信者は一人に限る。別の本文暗号化方式を選ばないため、JWEヘッダーにencを入れてはならない。草案の候補には、HPKE内部のAEADとしてChaCha20Poly1305を使うHPKE-4とHPKE-6が引き続き並ぶ。この事実だけでも、今回の削除をChaCha20Poly1305全体の否定と読むのは誤りだ。

末尾に-KEが付く鍵暗号化では役割が分かれる。HPKEが守るのは本文暗号化鍵（CEK）で、本文はencで指定する別の方式が暗号化する。JWEのJSON形式なら、HPKE以外の鍵管理方式を使う相手も含めて複数の受信者を扱える。封入された秘密はekに置かれ、受信者の文脈にはencの値が結び付けられる。第22版に残った-KEの番号は0、1、2、3、5、7の六つだ。

この欠番には手続き上の理由がある。8月3日に終わった二度目のLast Callは、JOSEにChaCha20/Poly1305を本文暗号化に使う登録がないため、4と6の-KE候補を削るという変更について合意を求めた。担当の分野責任者も9月15日の再投票説明で、変更点はそれだけだと記している。HPKE内部のAEADとJWE本文のencは別の位置にある。前者が利用できることは、後者の登録を代用しない。

Datatrackerには可決に足る投票状況が表示され、今日の議題にも載っている。しかし最終承認の記録ではない。IANAの表示も「OK – Actions Needed」であり、登録済みを意味しない。実装や障害の実例が明らかになったという話でもない。問われるのは、製品がどちらの経路を、どの条件で本当に受け付けるかである。

出典