Apologies, I misread the compact form in the version 01 draft - it does indeed included the cek ciphertext, but not the iv or aad tag. But my comments/questions about mandatory `alg` and `enc` values are still valid I believe.
On Mon, Jul 8, 2024 at 9:58 AM Les Hazlewood <[email protected]> wrote: > 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]
