I have reviewed this draft, and I broadly agree with Neil's comments [1]. The document has one fatal flaw, and one that may be straightforward to fix: "int" should be "alg", not "enc".
The fact that "enc": "int" is bad has been argued in several places. I won't reprise them here. On the other hand, "alg": "int" makes sense, with "enc" set to an HPKE algorithm. It's a direct parallel to "dir", just with an asymmetric key pair instead of a symmetric key. If you don't like "enc" encompassing authenticated public-key encryption, use something else, say "ies"; "enc" is not required. It's worth noting, though, that this is a non-trivial semantic change to JWE. It introduces a new "Key Management Mode" to JWE, in addition to the ones defined in RFC 7516 (Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, and Direct Encryption). Call it "Direct Public Key Encryption", say. This document needs to define that whole mode, with HPKE as the first instance. That's the "make JWE look like HPKE" approach. You could also take the "make HPKE look like JWE" approach. Recall that the definition of "alg" is "the cryptographic algorithm used to encrypt or determine the value of the CEK". You could use HPKE to determine a CEK by just doing the Setup operation and exporting a key suitable for the "enc" AEAD algorithm. This just makes HPKE work like ECDH does today. Even if you use it with DHKEM, you still get some improved binding properties over raw JWE ECDH. Personally, I prefer the "make JWE look like HPKE" approach, because it reuses more of HPKE. But I could understand if you didn't like the extra text to define a new Key Management Mode. In any case: Although HPKE and JWE have slightly different shapes, it's possible to align them in a couple of sensible ways. Unfortunately, the current draft does neither, so it needs to be revised to do one or the other. Other than that, it seems like there's just a bunch of pretty boring clean up. --Richard [1] One factual correction. This is not true: "there is an IANA registry of the specific combinations it works with". HPKE is secure when it is built with any combination of secure primitives, in the sense described in its security considerations. But basically: IND-CCA KEM, RO KDF, IND-CCA2 AEAD. On Fri, Jun 13, 2025 at 6:42 AM Neil Madden <[email protected]> wrote: > 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]. 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] 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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
