Hi Orie and Tirumal, Thank you for your responses.
The flow in CXP is indeed a series or messages with a single recipient. The key lifecycle is dictated by the protocol itself, the encapsulated keys will still be ephemeral but would be kept in memory for a short period of time. I do see this being either an adapted integrated encryption mode or a similar but new mode. I am aware of COSE HPKE, however it does seem to follow the same use cases as JOSE HPKE. We also do not intend on supporting CBOR for the protocol at this time. We would also prefer to have only one encoding and not mix CBOR and JSON together if possible. Regards, René Léveillé On Mon, Oct 28, 2024 at 6:17 AM tirumal reddy <[email protected]> wrote: > Similar to ECDH-ES, JOSE HPKE for traditional algorithms would be using > ephemeral keys. In the proposed use case, the keys will be used for > long-term and will not provide forward-secrecy. It looks like a new mode to > me > > In case of Hybrid or pure PQC, the output of KEM encaps will be > non-deterministic and this new mode is not required. It seems adding a new > just for traditional algorithms seems unwarranted. > > -Tiru > > On Sat, 26 Oct 2024 at 03:09, Orie Steele <[email protected]> > wrote: > >> 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] >> >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
