On Tue, Jul 09, 2024 at 12:55:16PM -0500, Orie Steele wrote: > On Tue, Jul 9, 2024 at 10:58 AM Ilari Liusvaara <[email protected]> > wrote: > > > On Mon, Jul 08, 2024 at 09:05:58PM -0500, Orie Steele wrote: > > > > > > This leads us back to the current proposal... > > > > > > - alg: HPKE-P256-SHA256-A128GCM ... enc: A128GCM // in separate headers > > -> > > > key encryption > > > - alg: HPKE-P256-SHA256-A128GCM, enc: A128GCM // in the same header > > -> > > > integrated encryption > > > > This does not work because JWE unions recipient headers. > > > > Which part would you change?
The enc value for integrated encryption. After all, integrated encryption does not have enc as meant in JWE. However, just omitting it could cause implementation problems. > > > hpke-info = empty > > > hpke-aad = protected (.aad) // how the distinction is authenticated > > > > ... And this does the wrong thing with Key Encryption (and causes > > implementation problems). > > > > What would you set HPKE AAD to be for Key Encryption? > What would you set HPKE AAD to be for Integrated Encryption? Protected(.aad) is fine for Integrated Encryption. One idea for Key Encryption would be to use the same FixedInfo as used by ECDH-ES: (For reference: be32(len(enc))||enc||be32(len(apu))||apu||be32(len(apv))||apv||be32(keybits) ... Where apu and apv default to empty if missing) - It encodes enc, apu and apv. - All fields are well-defined. - It does not overlap with Integrated Encryption (as any sane length encodes with NUL). > > This is also prohibited by draft-ietf-jose-fully-specified-algorithms > > (It requires what alg to be independent of enc). > > > > Drafts can only be cited as work in progress... it's also in conflict with > RFC7518: > > See also: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2 > > For "ECDH-ES", this is the length of the key used by the "enc" > algorithm. > For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this > is 128, 192, and 256, respectively. > > So as you can see... "alg" and "enc" are already dependent, as specified in > RFC7518. There is big difference between property lookup that is technically required and operations executed depending on another value. > We could write: > > For "HPKE-P256-SHA256-A128GCM", the length of the content encryption key is > the length of a key used by the "enc" algorithm, note that > "HPKE-P256-SHA256-A128GCM" can be used to encrypt an A256GCM key. > > ... or someone can propose alternative text that explains how HPKE "alg" > and "enc" values are related. If not using Integrated Encryption, RFC7516 already expains that. For Integrated Encryption, the only sensible "enc" is the one that delegates to "alg" via new algorithm operations. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
