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]
