Illari's recommendations make sense to me. > * JWE per-recipient headers SHALL contain BASE64URL encoding of the HPKE enc output as "epk" parameter.
seems like a new header param here might be better. > The "epk" (ephemeral public key) value created by the originator for the use in key agreement algorithms. This key is represented as a JSON Web Key [JWK] public key value. It MUST contain only public key parameters and SHOULD contain only the minimum JWK parameters necessary to represent the key; other JWK parameters included can be checked for consistency and honored, or they can be ignored. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used. - https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.1.1 This is related to the comments I have made a few times about wrapping HPKE's enc as a "kind of key", The requirements for JWK and COSE key are trivial, and we could easily make "encapsulated keys", valid "JWK or COSE Key". If we reuse the "epk" param, I suggest we do that... otherwise we should register a new param. strawman JWK for HPKE encapsulated key: { "kty" : "oct", // required (oct is usually used for symmetric, not sure if this is legal ... but can't use EC or OKP because HPKE output is opaque.) "k" : "FdFYFzERwC2uC...bt-KWRBICVQ" // raw output of HPKE (k is a Private Parameter, but here it transports a Public encap key) // per the SHOULD, other optional stuff is allowed here... } If we can't figure out how to make "encap" output serialized as JWK COSE Key, we should register new headers, not abuse existing ones. I agree if we have to sacrifice, we should cut on the JWE side. OS On Tue, Jan 9, 2024 at 11:08 AM Ilari Liusvaara <[email protected]> wrote: > On Tue, Jan 09, 2024 at 03:42:56PM +0000, Aritra Banerjee (Nokia) wrote: > > Hi Ilari, > > Please find my responses (in green) > > I note that the -01 version does nothing to fix the flaws, just > > specifies the flawed construction more precisely. > > We made the changes in -01 as suggested and put the 'encapsulated_key' > > parameter in the protected header for the Direct Key Agreement mode. > > Stick HPKE "enc" output in "JWE Encrypted Key" field. > > > > The "enc" output is carried in the "encapsulated_key" parameter in > > alignment with COSE draft. JWE Encrypted Key will carry ct in Key > > Agreement with Key Wrapping mode. > > > > Prohibit "enc" parameter, with a major warning about controverting a > > MUST in JWE. > > We will prohibit the "enc" parameter. > > > Basically, one must sacrifice one of: > - Alignment with COSE-HPKE. > - JWE requirements. > > > What I think would work: > > 1) If using JWE compact serialization: > > * The aad for HPKE SHALL be UTF-8 encoding of the JWE protected header. > * If JWE protected heder has "zip" parameter, the plaintext for HPKE > SHALL be the raw payload compresed using the specified algorithm. > Otherwise plaintext for HPKE SHALL be the raw payload. > * JWE protected header SHALL contain a JOSE-HPKE algorithm as parameter > "alg". > * JWE protected header MUST NOT contain parameter "enc". > * JWE encrypted key SHALL be raw enc output from HPKE. > * JWE initialization vector SHALL be empty. > * JWE ciphertext SHALL be raw ciphertext from HPKE. > * JWE authentication tag SHALL be empty. > > This is modification to JWE as specified in RFC7516. The original > JWE does not allow for integrated asymmetric encryption. > > > 2) If using JWE JSON Serialization, for each recipient: > > * The aad for HPKE SHALL be empty. > * The plaintext for HPKE SHALL be the raw CEK value. > * JWE per-recipient headers SHALL contain a JOSE-HPKE algorithm as > parameter "alg". > * JWE per-recipient headers SHALL contain BASE64URL encoding of the > HPKE enc output as "epk" parameter. > - JWE encrypted key SHALL be raw ciphertext from HPKE. > > > > This chooses JWE requirements to be sacrificed. What this specifies for > compact serialization breaks JWE in number of ways (the JSON > serialization stuff should be compliant). > > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
