Hi Ilari, To quote RFC 9528: "EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR-encoded X.509 (C509) certificates; see Section 3.5.2). COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT."
EDHOC utilizes the COSE Algorithms Registry, COSE header parameters, COSE_Encrypt0, and optionally COSE_Sign1 and COSE_Key. While EDHOC initially represented each message as nested COSE structures, it was soon recognized that some of the targeted network technologies would benefit greatly from a more compressed encoding. >Would that be sufficient? Section 3.7. of rfc9528 seems to use >(modified) COSE_Key structure. And that requires codepoints for the >keys. > >(The construction only being defined for EC2 and OKP is unlikely to >become a problem, as any modern KEM design should be using OKP. This >holds for ML-KEM and the CFRG hybrids.) > >FIPS 203 does not register the codepoints, and I am not aware of any >draft seeking to do so. Furthermore, there seems to be opposition for >it. AKP keys are not suitable for EDHOC, because EDHOC does not use >COSE algorithms. https://datatracker.ietf.org/doc/draft-spm-lake-pqsuites/ proposes to register EDHOC cipher suites based on the draft-ietf-jose-pqc-kem COSE algorithms and specifies the exact data transmitted over the wire in EDHOC. In the future, LAKE would likely want to use CWTs with public KEM keys for authentication. https://datatracker.ietf.org/doc/draft-pocero-authkem-ikr-edhoc/ https://datatracker.ietf.org/doc/draft-pocero-authkem-edhoc/ https://datatracker.ietf.org/doc/draft-papon-lake-pq-edhoc/ LAKE has just been rechartered to be able to adopt and work on making EDHOC quantum-resistant. Cheers, John Preuß Mattsson From: Ilari Liusvaara <[email protected]> Date: Saturday, 7 March 2026 at 08:25 To: [email protected] <[email protected]>, cose <[email protected]> Subject: [COSE] Re: [jose] Re: COSE and LAKE needs draft-ietf-jose-pqc-ke (was Proposal: Use HPKE for JWE PQ/PQT straight away) On Fri, Mar 06, 2026 at 06:01:25PM +0000, John Mattsson wrote: > > Ilari Liusvaara wrote: > >From quick read, it seems to me that what is needed > >is a key format for PQ keys > > EDHOC would need on-the-wire formats for ek, and c, and these are > already defined in FIPS 203 Would that be sufficient? Section 3.7. of rfc9528 seems to use (modified) COSE_Key structure. And that requires codepoints for the keys. (The construction only being defined for EC2 and OKP is unlikely to become a problem, as any modern KEM design should be using OKP. This holds for ML-KEM and the CFRG hybrids.) FIPS 203 does not register the codepoints, and I am not aware of any draft seeking to do so. Furthermore, there seems to be opposition for it. AKP keys are not suitable for EDHOC, because EDHOC does not use COSE algorithms. -Ilari _______________________________________________ COSE 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]
