Hi,

I did a quick high-level review of draft-ietf-jose-hpke-encrypt-12

---

OLD HPKE offers a variant of public key encryption of arbitrary-sized 
plaintexts for a
recipient public key.

NEW  HPKE offers IND-CCA2 public key encryption (PKE) of arbitrary-sized 
plaintexts for a recipient public key.

(I think the document should include the terms IND-CCA2 and PKE, likely in more 
places than this. Knowing that it is IND-CCA is essential for using the draft, 
and I think you should use the term PKE. I have seen weird statements in the 
IETF that HPKE is a KEM)

---

- "HPKE is a general encryption framework utilizing an asymmetric key 
encapsulation mechanism (KEM)."

While 5.1.1 and 5.1.2 utilize a KEM API, 5.1.3 and 5.1.4 utilizes a NIKE API. 
But I suggest refering to draft-ietf-hpke-hpke which will fixes this and only 
utilize KEMs.

---

- OLD: Hybrid Public Key Encryption (HPKE) [RFC9180] is a scheme that provides 
public key encryption of arbitrary-sized plaintexts given a recipient's public 
key.

NEW: Hybrid Public Key Encryption (HPKE) [RFC9180] is a public key encryption 
(PKE) scheme that provides encryption of arbitrary-sized plaintexts given a 
recipient's public key.

---

"This specification enables JSON Web Encryption (JWE) to leverage HPKE, 
bringing support for KEMs and the possibility of Post Quantum or Hybrid KEMs to 
JWE."

The draft has no motivation for what the benefit of adding HPKE to JWE is. This 
definitely need to be added.

Bringing support for KEMs and PQC is not true. JOSE already has KEMs like the 
ECDH-ES KEM. PQC KEMs are straightforward drop-in replacements for the ECDH-ES 
KEM, so HPKE is not needed for KEMs or PQC...

---

- "Key Encapsulation Mechanism (KEM), see [RFC9180]."

RFC 9180 has a very incorrect definition of a KEM, but that is fixed in 
draft-ietf-hpke-hpke

---

   *  Authenticated Encryption with Associated Data (AEAD), see
      [RFC9180].

   *  Additional Authenticated Data (AAD), see [RFC9180].

This needs to also point to JOSE definitions of AEAD and AAD which are also 
used by the doc.

--

   *  If "enc" is an AEAD algorithm, the recipient Key Management mode
      is Key Encryption.

   The HPKE KEM, KDF, and AEAD used depend on the JOSE-HPKE algorithm
   used.

(This is likely confusing to the reader. The HPKE AEAD has not been introduced 
before)

---

- "In JOSE-HPKE, only "mode_base" and "mode_psk" are supported."

Can be removed/rewritten when updating to  draft-ietf-hpke-hpke

---

OLD: MUST be rejected.
NEW: MUST NOT be used and MUST be rejected.

---

Header Parameter Name: "ek"
encapsulated keys

ek is a very unsuitable name for anything related to KEMs. ek is standard 
notation for the encapsulation key.

And “encapsulated key” is very easy to confuse with the encapsulation key.

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf

---

- The whole section 8.2 Static Asymmetric Authentication in HPKE can be removed 
when refering to draft-ietf-hpke-hpke

--

   | HPKE-0              | EC  | P-256     |
   | HPKE-1              | EC  | P-384     |
   | HPKE-2              | EC  | P-521     |
   | HPKE-3, HPKE-4      | OKP | X25519    |
   | HPKE-5, HPKE-6      | OKP | X448      |

I am skeptical to register more quantum-vulnerable stuff to JOSE. NIST will 
disallow (much stronger than deprecate) all standalone ECC in 2035, and many 
countries has even harder recommendations.

Also if introducing more quantum-vulnerable stuff, do we really need Weierstraß 
curves? On the Web in TLS, NIST P-curves are more or less only used by legacy 
systems and declining fast.

--

“A single KEM key should not be used with multiple algorithms.”

RFC 2119? Need to add “MUST NOT be used with multiple KEM algorithms”.

---

Cheers,
John Preuß Mattsson

From: [email protected] <[email protected]>
Date: Thursday, 2 October 2025 at 19:05
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [jose] I-D Action: draft-ietf-jose-hpke-encrypt-12.txt
Internet-Draft draft-ietf-jose-hpke-encrypt-12.txt is now available. It is a
work item of the Javascript Object Signing and Encryption (JOSE) WG of the
IETF.

   Title:   Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing 
and Encryption (JOSE)
   Authors: Tirumaleswar Reddy
            Hannes Tschofenig
            Aritra Banerjee
            Orie Steele
            Michael B. Jones
   Name:    draft-ietf-jose-hpke-encrypt-12.txt
   Pages:   21
   Dates:   2025-10-02

Abstract:

   This specification defines Hybrid Public Key Encryption (HPKE) for
   use with JSON Object Signing and Encryption (JOSE).  HPKE offers a
   variant of public key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE is a general encryption framework utilizing an asymmetric key
   encapsulation mechanism (KEM), a key derivation function (KDF), and
   an Authenticated Encryption with Associated Data (AEAD) algorithm.

   This document defines the use of HPKE with JOSE.  The specification
   chooses a specific subset of the HPKE features to use with JOSE.

The IETF datatracker status page for this Internet-Draft is:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-jose-hpke-encrypt%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C80a24e808a964415b66108de01d5e076%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638950215308506419%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v%2BB0HXNgWZKFpDLMUo5Bbc49VkL0lyRpOnOZpG2ryK8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/>

There is also an HTML version available at:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-jose-hpke-encrypt-12.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C80a24e808a964415b66108de01d5e076%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638950215308535808%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x%2FFf24g8%2FeOT0SPY1BQOeTk9wQCiXdx11u8eImr7f9s%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-12.html>

A diff from the previous version is available at:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-jose-hpke-encrypt-12&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C80a24e808a964415b66108de01d5e076%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638950215308551197%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Cm40qQkzWISvOSVqEA%2BmcprzMZSjjYnW9wuCFL%2BON%2F0%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-hpke-encrypt-12>

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to