Hi John,
thanks for your review comments.
Am 03.10.2025 um 08:40 schrieb John Mattsson:
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 placesthan 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)
Note that we are just specifying the use of HPKE in JOSE in this
document and do not go into the details of HPKE itself since such text
would be redundant. With regards to this text in particular, it is
actually a copy from the abstract of the HPKE RFC. This text also has
not changed in the draft-ietf-hpke-hpke either. If something needs to be
changed then it is in draft-ietf-hpke-hpke.
---
- "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.
I am not sure what document you are referring to but I think we should
just re-use text from draft-ietf-hpke-hpke here. No need in innovating
at this point.
My suggestion is to put the following text into the abstract:
HPKE also
includes a variant that authenticates possession of a pre-shared key.
HPKE works for any combination of an asymmetric KEM, key derivation
function (KDF), and authenticated encryption with additional data
(AEAD) encryption function.
---
- 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.
Introducing the PKE abbreviation is fine for me.
---
"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 KEMsand 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...
The HPKE specification provides the motivation of why it is a better
choice than other approaches (see . If you believe their argument then
you will use it. It turns out that many companies seem to agree and that
is why they are using HPKE or want to use it. So, if you buy into HPKE
then you also want to use it with JOSE and COSE.
---
- "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
I just looked at RFC 9180 and I do not think it even offers a definition
for KEMs. IMHO draft-ietf-hpke-hpke does not change that.
---
* 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.
OK.
--
* 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
introducedbefore)
Tiru added a note.
---
- "In JOSE-HPKE, only "mode_base" and "mode_psk" are supported."
Can be removed/rewritten when updating to draft-ietf-hpke-hpke
Changed it to "HPKE supports two modes, which are described in Table 1
of I-D.ietf-hpke-hpke."
---
OLD: MUST be rejected.
NEW: MUST NOT be used and MUST be rejected.
Ok.
---
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
It is straight out of the HPKE spec. I agree with you that the authors
of the HPKE specification could have come up with a less confusing name.
---
- The whole section 8.2 Static Asymmetric Authentication in HPKE can
be removed when refering to draft-ietf-hpke-hpke
Fine for me.
--
| 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 evenharder 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 systemsand declining fast.
I understand your excitement for PQC algorithms. But I see no harm in
adding these algorithms to the registry. We can always deprecate them
later - when time comes.
--
“A single KEM key should not be used with multiple algorithms.”
RFC 2119? Need to add “MUST NOT be used with multiple KEM algorithms”.
Changed.
---
Here is the PR that Tiru created:
https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/68
Ciao
Hannes
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 [email protected]
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
