Hi Rene, The current draft is primarily targeting JWE support for HPKE.
That means support for encrypted JWTs (single recipient), and multiple recipient interoperability via json serialized JWE. We're obviously excited about enabling a path to post quantum kems like ML-KEM or XWING for JOSE. The flow you describe sounds like a series of messages, instead of a single message with one or more recipients. That being said, there is potentially some opportunity to share algorithm identifiers, public key formats, and possibly adjust the integrated encryption or key encryption mode requirements to align more with your use case. There is also COSE HPKE, is support for CBOR a consideration? Perhaps there is path to ommiting the encapsulated key if specific protected header parameters were present... And that could be made to be compatible with integrated encryption mode... Or perhaps this is a new JOSE HPKE model entirely. I'll need to read up on CXP, but I'm happy to propose some message examples to ground the discussion in the current drafts capabilities. Regards, OS On Fri, Oct 25, 2024, 4:18 PM Rene Leveille <rene.leveille= [email protected]> wrote: > Hello JOSE mailing list, > > As some of you may be aware, the FIDO Alliance has been working on some > new specifications for interoperability of credential managers. The Credential > Exchange Protocol > <https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html> (CXP) > specifically leverages HPKE (RFC 9180) for the encryption of the credential > payload. Seeing as this is a JSON based protocol, the use of > draft-ietf-jose-hpke-encrypt > <https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/> is a > logical choice for containing the encrypted payload. To that effect, I am > reaching out to make the working group aware of the use case and the > importance of the draft for CXP. > > To this end, i also have questions regarding the draft: > > - The protocol will be encrypting multiple payloads using the same > AEAD context. HPKE encryption contexts use a counter as a state for > deriving the nonces. However it seems that the current draft seems > to support only the one shot API of the RFC. Would the authors be open to > adding a sequence key to the schema to support longer lived encryption > contexts? > - In the case of a longer lived context, having the JWE hold the > encapsulated key would be redundant. Would it make sense to have the > encapsulated key be optional when a sequence key is present? > > Regards, > > René Léveillé > Senior Developer, Security Development > [email protected] > > More than 100,000 businesses trust 1Password to secure their most > important information. Try it free. <https://1password.com/teams/pricing/> > _______________________________________________ > 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]
