Thanks Orie, As a long-time implementer and maintainer of a widely used JOSE library, I'm have some concerns that I hope could be addressed. Admittedly, most of my questions are relevant to single recipient and compact (JWT) forms.
I don't think for JWE there should ever be an omitted `alg` header parameter: its omission and/or 'none' value can and has caused security problems in the past for parsers and this feels like opening a can of worms again. Further, it adds cyclomatic complexity (conditionals) for validation assertions that, I hope, shouldn't ever be necessary. Non-absent deterministic values are so much nicer and reduce potential problems. The way `alg` has always worked (conceptually at least) IMO from a library implementor point of view is it means "the algorithm used to obtain the AEAD content encryption key and its potentially associated ciphertext". `enc` is "the algorithm used to AEAD encrypt the payload". That is, (pseudocode): enc_alg = enc_registry.find( header['enc'] ) key_alg = alg_registry.find( header['alg'] ) kek = keystore.find( header['kid'] ) cek, cek_ciphertext = key_alg((kek, encAlg, header) For JWE: - No `alg` inherently means "there isn't a way to obtain an cek/cdk". - No `enc` means "the payload is not encrypted", so both must always be present for JWE. - No JWE ciphertext token in the compact JWE string means 'there is no encrypted key ciphertext', when clearly there is (encapsulation). I could be missing something (and happy to be educated accordingly), but I would really like to see the HPKE work maintain these existing constructs - changing them to introduce additional complexity is not an intuitive, nor safe, idea IMO. Respectfully, Les Hazlewood JJWT author/maintainer On Sun, Jul 7, 2024 at 3:17 PM Orie Steele <[email protected]> wrote: > Hello, > > I have done my best to apply all the feedback gathered from the adoption > call, and I want to draw your attention to the latest draft, and its > primary remaining obstacles for discussion at ietf 120. > > In my haste, I may have destroyed something essential. Apologies to my > co-authors, feel free to roast me at the mic line. > > Be advised the github repo for the working group adopted draft is > currently here, PRs are welcome: > > https://github.com/OR13/draft-ietf-jose-hpke-encrypt > > As you can see from the document history -01 addresses several points of > feedback, and uses the terminology and guidance regarding algorithm names > provided by Ilari and others. > > Major changes in this version: > > - JWK is no longer used for encapsulated keys, but "encrypted_key" JWE > member and "ek" header parameter are. > - HPKE mode (base / auth / psk / psk_auth) is no longer included in > algorithm registrations. > - HPKE Setup info and aad are addressed in a single location for both > integrated and key encryption with hpke. > - "dir" approach has been replaced with "enc": <some registered aead>. > - "jwe aad" examples have been added. > - "psk_id" and "auth_kid" examples have been added. > > I've implemented version -01, and the examples are produced from my > prototype. > > Risk areas, and things which we would like to resolve ASAP. > > ### Fully specified HPKE algorithms > > It would be nice to have confidence that the algorithm names will not > change. > > For example where we currently see: > > ``` > "alg": "HPKE-P256-SHA256-A128GCM", > "enc": "A128GCM", > ``` > > We might see: > > ``` > "alg": "HPKE-P256-SHA256", > "enc": "A128GCM", > ``` > > Or whatever the working group decides counts as a "fully specified HPKE > algorithm". > > ``` > "alg": "HPKE-P256-SHA256+A128KW", ? > ``` > > ### HPKE AAD vs JWE AAD > > I think the current approach is better than computing some custom KDF info > from apu / apv... But is setting the following as HPKE AAD enough? > > hpke-info = empty > hpke-aad = encode-protected-header . aad (when JWE aad is available) > > Where encoded protected header is either the protected header for > hpke jwe integrated encryption, or the protected header used in content > encryption, for which the content encryption key is being encrypted? > > ### Lossy conversions > > It's possible to express things in JSON Serialization that can't be > expressed in Compact serialization. > I tried to make this explicit, but we could decide to simply forbid > conversions from JSON to Compact that lose information, or that would move > things around "ek" to "encrypted_key". > > > Thanks for all the feedback during the adoption call. > > Regards, > > OS > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > 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]
