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]