I have reviewed the -09 version and have many comments:
In the abstract:
"HPKE works for any combination of an asymmetric key encapsulation mechanism
(KEM), key derivation function (KDF), and authenticated encryption with
additional data (AEAD) function."
I don’t think this is true - there is an IANA registry of the specific
combinations it works with. Even if we take it as “in principle, it could” I
don’t think that is true either - there are specific requirements on the
components (eg IND-CCA2). I’m not sure what the purpose is of this sentence, so
I’m not sure what alternative text would look like. Maybe “HPKE is a general
framework that supports several algorithms”?
The abstract should probably also mention that only unauthenticated HPKE KEMs
are supported.
Section 4:
"When "alg" is a JOSE-HPKE algorithm” - how do implementors determine if x is a
JOSE-HPKE algorithm? Do they need to keep a list of these? Will they always
start “HPKE-“?
I find “enc”: “inc” to be problematic. It’s not an AEAD, so violates the
requirement in section 4.1.2 of RFC 7516:
"This algorithm MUST be an AEAD algorithm with a specified key length.”
Neither of these requirements are satisfied by “inc”.
On a related note, what does {“alg”: “RSA-OAEP”, “enc”: “int”} mean? If it is
not allowed, then how is it prevented? Resolving these issues with the current
design will need at least an update of 7516, but it really takes such a
sledgehammer to the existing JWE specifications that I’m not sure an update is
enough.
I’m more and more convinced that Brian’s suggestion to define a new JWHPKE
would be a better solution than trying to crowbar this into JWE.
(https://mailarchive.ietf.org/arch/msg/jose/ssmlqF2lUGXwqnhD8SU7l2E1Aqg/)
"If "enc" is an AEAD algorithm […]” - all “enc” values are supposed to be
AEADs. Maybe this should say “is not “inc””?
There seems to be a broken reference to RFC 9180 in the last sentence of this
section.
Section 4.1:
"HPKE algorithms are not required to process "apu" and "apv" as described in
Section 4.6.1 of [RFC7518], despite appearing to be similar to key agreement
algorithms (such as "ECDH-ES”).”
Does “are not required to” here actually mean “cannot”? I think this sentence
needs rewording to more clearly say what is meant here. Maybe something like
“Despite appearing similar to ECDH-ES, JOSE-HPKE does not use the “apu” and
“apv” headers.”?
I find the discussion of “aad” in this section and the previous one extremely
confusing. Section 4 says that compact serialization cannot use aad, but 4.1
says:
"The "aad parameter" for Open() and Seal() MUST be used with both HPKE JWE
Integrated Encryption and HPKE JWE Key Encryption.”
which is it?
The next sentence about terminology should be moved to section 3 and then used
consistently throughout the document, as it isn’t currently.
Section 5:
"JWE Initialization Vector and JWE Authentication Tag MUST NOT be present”
These are mandatory fields, so perhaps this means to say “MUST be an empty
octet sequence”?
How do the encryption steps in section 5.1 of RFC 7516 relate to HPKE
encryption? I think quite a lot need to be skipped or changed?
For decryption, the draft says "When decrypting, the checks in [RFC7516]
section 5.2, steps 1 through 5 MUST be performed.” - what about the steps 6–18?
All of these steps are mandatory in JWE, how can you say this is a JOSE
algorithm and then drive a coach and horses through most of the processing
rules?
Section 5.1:
This example is not a valid JWE Compact Serialization - it’s missing a “.”
somewhere.
Section 5.2:
This example appears to be of the Key Encryption mode not the Integrated mode?
It would be extremely helpful to link to Appendix A in these examples, and to
also consider a step-by-step description of how the examples were generated, as
I think a lot is being left to implementors to figure out on their own.
Section 6:
There is no "RSA-OAEP-384” algorithm - presumably “RSA-OAEP-256” is intended?
"The encoding of the protected header encoding remains consistent with existing
JWE formatting rules.” - one too many “encoding”s in this sentence, I think?
"The HPKE AAD parameter MUST be set to the empty string.” - now I’m completely
confused about the AAD handling!
Section 7:
What is “AKP” key type - does it need a reference?
Section 7.1:
I find the use of “encrypt” for the “key_ops” to be interesting. I would have
expected maybe “wrapKey”? I don’t think HPKE public keys are ever used to
directly encrypt content? The draft should maybe clarify how key_ops relate to
JOSE-HPKE operations?
Section 8:
"In this case JOSE constructs like JWS and JSON Web Tokens (JWTs) can be used
to add authentication.”
JWT is not a JOSE construct but rather an application of JOSE. I suggest
removing the “and JSON Web Tokens (JWTs)” part completely.
It seems a bit strong that the approach of the Informational RFC 8937 is a
“MUST” here. Are we really saying that CEKs MUST be generated as a pseudorandom
function over a signature signed with the *recipient’s private key*??? I don’t
see how this is even possible, let alone a hard requirement. Did you mean to
link to eg RFC 4086 here instead (as JOSE already does)? (If it’s really a MUST
then it also needs to be a Normative Reference).
Section 8.1:
"Additionally, the same key MUST NOT be used for both key encryption and
integrated encryption, as it may introduce security risks. It creates algorithm
confusion, increases the potential for key leakage, cross-suite attacks, and
improper handling of the key.”
Are we sure all these risks are real? I’m not really sure how using the same
key for both key wrapping and integrated encryption leads to most of these
things? Also, I’m not really sure how you can prevent it - does this place a
requirement on recipients to somehow communicate to all senders which mode to
use? Should there be a new JWK field to communicate this?
Sections 8.2-8.6 seem like they could be replaced with a general recommendation
to review RFC 8725.
Section 9.2.8 - presumably the quotes are not needed around “int”? Can we also
mention “HPKE” somewhere in the description?
For all of these registrations do we need a note to the RFC Editor to replace
“this specification” with the actual RFC when it’s published?
Section 9.3.1 - I’m still not really clear why the existing JWE Encrypted Key
is not sufficient here, but nevermind. This registration should mention that it
is base64url-encoded.
9.3.2 - a HPKE psk_id is an arbitrary byte string, so presumably this header is
also base64url-encoded?
Overall, I’d say this draft still needs a lot of work to be ready for
publication.
— Neil
> On 4 Jun 2025, at 21:25, Karen ODonoghue <[email protected]> wrote:
>
> jose working group,
>
>
>
> This starts a two-week Working Group Last Call (WGLC) for the Use of Hybrid
> Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)
> specification
> https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-08.html. The
> WGLC will run for two weeks, ending on Friday, June 20, 2025.
>
>
>
> Please review and send any comments or feedback to the JOSE working group at
> [email protected] <mailto:[email protected]>. Even if your feedback is “this is
> ready for publication”, please let us know so that we can accurately document
> consensus.
>
>
>
> Note that this WGLC is intentionally running concurrently with a COSE WGLC
> for https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html because the
> drafts are closely related and their functionality is intended to be aligned.
> Please reply to the COSE WGLC on the [email protected] <mailto:[email protected]>
> mailing list.
>
>
>
> Thanks,
>
> Karen, John, and John (jose wg chairs)
>
>
>
> _______________________________________________
> 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]
