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]
