I meant in the sense that if you see an AKP inside a CWT / COSE Sign1, the algorithm on the key would be signed over. The AKP thumbprint for a COSE Key also includes the algorithm.
Current x25519 example ( https://datatracker.ietf.org/doc/html/rfc9528#section-3.5.2-5): { /CCS/ 2 : "42-50-31-FF-EF-37-32-39", /sub/ 8 : { /cnf/ 1 : { /COSE_Key/ 1 : 1, /kty EC2/ 2 : h'00', /kid/ *-1 : 4, /crv X25519 /* -2 : h'b1a3e89460e88d3a8d54211dc95f0b90 /public key / 3ff205eb71912d6db8f4af980d2db83a' } } } Hypothetical Hybrid: { /CCS/ 2 : "42-50-31-FF-EF-37-32-39", /sub/ 8 : { /cnf/ 1 : { /COSE_Key/ 1 : 1, /kty AKP/ 2 : h'00', /kid/ *3 : e'X-WING', /alg X-WING/* -1 : h'b1a3e89...980d2db83a' /public key/ } } } Note the e-ref thing comes from: https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-e-ref/ On Sat, Mar 7, 2026 at 11:28 AM John Mattsson <john.mattsson= [email protected]> wrote: > Hi Ilari, > > Given ML-KEM-512 = TBD1 in the COSE Algorithms Registry my understanding is > that the COSE_KEY part of a CWT would be: > > 1 : { /COSE_Key/ > 1 : 7, / kty / > 3 : <TBD1> / alg / > 2 : h'00', / kid / > -2 : h'<ML-KEM-512 public key>' / x / > } > > I think this would work for EDHOC. Seems very similar to a CWT for X25519 > > 1 : { /COSE_Key/ > 1 : 1, / kty / > 2 : h'00', / kid / > -1 : 4, / crv / > -3 : h’<X25519 public key>' / x / > } > > A static key in a CWT would be used for authentication. > > >For draft-spm-lake-pqsuites, seems like it only needs signature keys, > >which AKP was designed for (why is draft-ietf-jose-pqc-kem a normative > >reference? It does not seem to be used for anything...) > > > draft-spm-lake-pqsuites uses the code point in the COSE algorithms > registry. draft-spm-lake-pqsuites use ephemeral ML-KEM for key exchange > together with PSK, Signature, or Static DH authentication. KEM > authentication may be specified later. > > (If would be a bit strange to use the same alg for key exchange and > authentication, but I don’t think it would cause any problems for EDHOC). > > Cheers, > John > > *From: *Ilari Liusvaara <[email protected]> > *Date: *Saturday, 7 March 2026 at 16:13 > *To: *JOSE WG <[email protected]>, cose <[email protected]> > *Subject: *[jose] Re: [COSE] Re: Re: COSE and LAKE needs > draft-ietf-jose-pqc-ke (was Proposal: Use HPKE for JWE PQ/PQT straight away) > > On Sat, Mar 07, 2026 at 08:25:03AM -0600, Orie wrote: > > On Sat, Mar 7, 2026, 2:31 AM John Mattsson <john.mattsson= > > [email protected]> wrote: > > > > 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. > > >From the quoted post by John Mattsson: "In the future, LAKE would likely > want to use CWTs with public KEM keys for authentication.". > > Those keys do not commit to any KEM algorithm (at least one that makes > any sense in COSE). > > For draft-spm-lake-pqsuites, seems like it only needs signature keys, > which AKP was designed for (why is draft-ietf-jose-pqc-kem a normative > reference? It does not seem to be used for anything...) > > > > > -Ilari > > _______________________________________________ > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
