Hi,
I'm not very familiar with edhoc, but if edhoc supports multiple
algorithms, and has private and public key components, AKP could be used.
If edhoc needs kems without hpke, new COSE algorithms would be need to be
registered.
{ kty: AKP, alg: <kem>, pub:..., priv:..}
If edhoc, needs a key representation that does not commit to a specific kem
algorithm, then AKP is not a suitable option.
I would tend to register only what edhoc needs, in contrast to registering
whatever is needed to complete parity vs hpke.
Regards,
OS
On Sat, Mar 7, 2026, 2:31 AM John Mattsson <john.mattsson=
[email protected]> wrote:
> 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]
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
