Hi Orie, The draft says: "The "Setup info" MUST NOT be used with either HPKE JWE Integrated Encryption and HPKE JWE Key Encryption." Could you provide some more information about this part?
RFC 9180 section 8.1 doesn't have this restriction unless using single shot APIs. I'm planning on using a nonce in the info field to make sure the key material is specific to the transaction per the advice on NIST 800-56A Appendix B. Thanks! -matt > On Jul 7, 2024, at 5:16 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]
