On Wed, Jul 10, 2024, 7:02 PM Matt Chanda <cha...@apple.com> wrote:
> Responses inline > > On Jul 10, 2024, at 6:36 PM, Orie Steele <orie@transmute.industries> > wrote: > > > Hi Matt, > > That text is present to ensure that JWE implementations do not break > interoperability by doing something undefined with setup info. > > In the other threads, Ilari has suggested using setup info in a manner > similar to how info is used with concat kdf in ECDH-ES. > > It sounds like that would work for your use case as well. > > > Agreed. > > Is the nonce in the headers or is it private information (both parties are > aware of it, but it's not present in headers). > > > The data is known to both parties but it is not in the headers. > I think you just supply it as SuppPrivInfo here: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2 In your API, you expose the ability to pass in whatever value, and have your library compute the full info structure including apu / apv when present, then pass the resulting info structure to hpke info. If this works for you, it's an extra argument in favor of Ilari's suggestion to use info with both HPKE JWE modes. > > If you have sample messages, I'm happy to try to add them to my prototype > and include them as test vectors in the next draft version. > > > In my samples, I set the info when I create the HPKE context and > authenticate the aad for the seal() call itself. (I’m compact mode only). > When the response is received, I set the expected nonce on the context and > attempt to open(). > > > Regards, > > OS > > > > On Wed, Jul 10, 2024, 6:07 PM Matt Chanda <cha...@apple.com> wrote: > >> 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 <orie@transmute.industries> >> 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 -- jose@ietf.org >> To unsubscribe send an email to jose-le...@ietf.org >> >> >>
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
