Hi Neil, Thanks for taking the time to thoroughly review the spec. That's super helpful. Hannes, Orie, and I went through your comments and created an editor's draft incorporating proposed resolutions to them (which was also approved by the other editors). You can view it at https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html. We'll include these resolutions in draft 10 when we publish it - possibly after incorporating suggestions from additional WGLC feedback.
Replies to your specific comments are inline below, prefixed by "Mike>". From: Neil Madden <[email protected]> Sent: Friday, June 13, 2025 3:42 AM To: Karen ODonoghue <[email protected]> Cc: JOSE WG <[email protected]> Subject: [jose] Re: WGLC for draft-ietf-jose-hpke-encrypt-08 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"? Mike> You're right that this was overreaching. Please review the revised abstract text on this topic. The abstract should probably also mention that only unauthenticated HPKE KEMs are supported. Mike> We generalized this comment by adding "The specification chooses a specific subset of the HPKE features to use with JOSE.", since there are other HPKE features that we intentionally also don't support. These are discussed in the body of the specification. 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-"? Mike> Yes. The specification now says this explicitly. 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". Mike> The spec already described that an exception is made for the AEAD rule for "inc". But rather than just say so inline, we now also added this explicit statement in response to your and Brian's feedback: This specification updates the "enc" definition in Section 4.1.2 of [RFC7516<https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html#RFC7516>] by allowing the "enc" value "int" when the "alg" value is a JOSE-HPKE algorithm. When "alg" is not a JOSE-HPKE algorithm and the "enc" value is "int", the input MUST be rejected. 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. Mike> The second sentence of what we added explicitly answers that question. 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/) That would defeat the entire purpose of the work. The purpose is to be able to use JWE encryption with HPKE algorithms. The IETF is going all-in on HPKE as the new way of expressing encryption, including PQ encryption. This spec lets JWE and JWTs ride that wave. This is particularly important for JWTs, which are now widely used in ways that the authors never imagined. Doing something that's not a JWE wouldn't help JWTs. "If "enc" is an AEAD algorithm [...]" - all "enc" values are supposed to be AEADs. Maybe this should say "is not "inc""? Mike> See the above added text making this explicit. Note also, that the version you reviewed already included this text when describing integrated encryption: The protected header MUST contain an "enc" with value "int". This is an explicit exception to requirement in Section 4.1.2 of [RFC7516<https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html#RFC7516>] that "enc" must be an AEAD algorithm. There seems to be a broken reference to RFC 9180 in the last sentence of this section. Mike> Thanks - fixed 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."? Mike> This was reworded to: Despite similarities to ECDH-ES, this specification does not use the apu and apv header parameters, which are described in Section 4.6.1 of [RFC7518<https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html#RFC7518>]. 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? Mike> The AAD processing rules were made more explicit, including referencing the relevant processing steps in JWE. The next sentence about terminology should be moved to section 3 and then used consistently throughout the document, as it isn't currently. Mike> This was deleted, as it was no longer accurate. 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"? Mike> We incorporated your suggestion. 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? Mike> The steps in 5.1 are now explicitly referenced. 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? Mike> The relationships between the steps were made explicit. Section 5.1: This example is not a valid JWE Compact Serialization - it's missing a "." somewhere. It has exactly four period, per the JWE Compact Serialization. Maybe you didn't see the one at the end? Section 5.2: This example appears to be of the Key Encryption mode not the Integrated mode? Mike> Correct. We moved this into the appropriate section, as also suggested by Sebastian Stenzel. 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. Mike> Thanks - done Section 6: There is no "RSA-OAEP-384" algorithm - presumably "RSA-OAEP-256" is intended? Mike> Thanks - fixed "The encoding of the protected header encoding remains consistent with existing JWE formatting rules." - one too many "encoding"s in this sentence, I think? Mike> Thanks - fixed "The HPKE AAD parameter MUST be set to the empty string." - now I'm completely confused about the AAD handling! Mike> See the updates to 4.1. <https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html#section-4.1> Auxiliary Authenticated Application Information<https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html#name-auxiliary-authenticated-app> Section 7: What is "AKP" key type - does it need a reference? Mike> Reference added 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? Mike> When using integrated encryption, HPKE public keys *are* used to directly encrypt the plaintext. We also added a sentence about the use of "key_ops": "encrypt" in this context, so others aren't confused by this. 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. Mike> We deleted this unnecessary text. 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). Mike> We went with RFC 4086, as you suggested. 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? Mike> Changed this to "should not", particularly since it's in the Security Considerations section, and therefore not normative. Sections 8.2-8.6 seem like they could be replaced with a general recommendation to review RFC 8725. Mike> Done Section 9.2.8 - presumably the quotes are not needed around "int"? Can we also mention "HPKE" somewhere in the description? Mike> Quotation marks removed 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? Mike> I use this notation all the time and the RFC Editor always does the right thing 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. Mike> Thanks - done 9.3.2 - a HPKE psk_id is an arbitrary byte string, so presumably this header is also base64url-encoded? Mike> Likewise Overall, I'd say this draft still needs a lot of work to be ready for publication. Mike> Sincere thanks for the detailed review that helped us with that work! - Neil Thanks again, -- Mike On 4 Jun 2025, at 21:25, Karen ODonoghue <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
