Re: [jose] [EXTERNAL] COSE and JOSE Keys for Kyber

[Mike Ounsworth <[e-mail]>]

Hi all,

I admit that I’m an outsider and don’t grok why you need a KTY and an ALG, but the naming proposed below seems odd to me.

I suppose you can group things into “LWE”, “NTRU”, “HASH”, but the various LWE schemes do not have interchangeable key types; a Dilithium3 key is a Dilithium3 key, you can’t use it with any other algorithm, even within the LWE family. So for anyone outside the PQC experts I think this is going to cause more confusion than help, ex.: people trying to use a Dilithium key with Kyber.encaps(), or whatever.

I also don’t love “CRYDI3”. Why not just “DI3”? I would vote for a naming convention of “2-letter + param set” (which Orie suggested in a private email)

FA512 / FA768 / FA1024 / DI3 / DI5 / KY768 / KY1024 / SP256

“SPHINCS+-SHAKE-256s-robust” seems obscene, especially if you’re only supporting one variant. Do “SP256” or “SP256sr”. Also, I’m not a deep SPHINCS+ expert, but the “-robust” is probably overkill for JOSE / COSE. I think Scott Fluhrer suggested that it’s even overkill for 30-year windows code-signing certs, do “-simple” and save yourself 1/2 the bandwidth.

---
Mike Ounsworth
Software Security Architect, Entrust

From: Orie Steele <[e-mail]>
Sent: November 13, 2022 3:00 PM
To: cose <[e-mail]>; JOSE WG <[e-mail]>; Mike Ounsworth <[e-mail]>
Subject: [EXTERNAL] COSE and JOSE Keys for Kyber

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Friends,

Mike O. and I have been discussing the need to represent Kyber keys in JOSE and COSE, especially as we prepare to consider their use with HPKE.

Mike P. and I have previously shared a draft for presenting Dilithium, Falcon and Sphincs - https://datatracker.ietf.org/doc/draft-ietf-cose-post-quantum-signatures/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-cose-post-quantum-signatures/__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIFXLOHms$>

I reviewed the original registries established in: https://www.rfc-editor.org/rfc/rfc7518.html#section-7<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7518.html*section-7__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIkFE2gTI$>

I also reviewed the latest "kty" and "alg" registered in https://datatracker.ietf.org/doc/html/rfc8778<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8778__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIVxp-mn8$>

I'm going to stick to JOSE(ish) notation here, my goal is to get a clear answer on "which values for `kty` and `alg` are relevant to kyber".

See the latest editor's draft for additional details: https://github.com/OR13/draft-steele-cose-kyber<https://urldefense.com/v3/__https:/github.com/OR13/draft-steele-cose-kyber__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIlrb1NBk$>.

First, let's start with what we have today:

- https://www.iana.org/assignments/cose/cose.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/cose/cose.xhtml__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuI7xRKz4s$>
- https://www.iana.org/assignments/jose/jose.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/jose/jose.xhtml__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIHk5wYN0$>

{ kty: RSA, alg: PS384 / RSAES-OAEP w/ SHA-256}
{ kty: RSA, alg: RS384 / RSAES-OAEP w/ SHA-256}
{ kty: EC2, crv: P-256, alg: ES256 / ECDH-ES+A256KW }
{ kty: OKP, crv: Ed25519, alg: EdDSA } - https://www.rfc-editor.org/rfc/rfc8037#section-2<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8037*section-2__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuI1uryn64$>
{ kty: OKP, crv: Bls12381G1, alg: ??? } ... https://datatracker.ietf.org/doc/html/draft-ietf-cose-bls-key-representations-01#section-2.1.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-cose-bls-key-representations-01*section-2.1.3__;Iw!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIQW72VRU$>
{ kty: HSS-LMS, alg: HSS-LMS }
{ kty: WalnutDSA, alg: WalnutDSA }

Observations:

1. Although `alg` is optional... It looks especially needed in some cases (RSA), and especially not needed in others (HSS-LMS, WalnutDSA)
2. We appear to have slowly started to encode "Purpose" in the key type (HSS-LMS / WalnutDSA) , which suggests that we are commiting to keeping `alg` optional forever, and also acknowledging that it is best to use a key for a single purpose.
3. It is possible to define a key and NOT define any algorithms for it... (see bls-key draft above).
4. OKP is reserved for Elliptic Curves only.
5. IANA Registries exist for Elliptic Curves but no other "families" such as lattices, stateful hash based schemes, or stateless hash based schemes... based on HSS-LMS not attempting to fix this, it seems we are ok not establishing new IANA registries for lattice or hash types.
6. Walnut encodes parameters as separate values in the key type, but not the algorithm name... similar to RSA... which seems like a step backwards to me.

Here is a proposal for Kyber keys that aligns with the previous proposals and drafts for post quantum signatures:

{ kty: LWE, alg: CRYDI5 }
{ kty: LWE, alg: CRYDI3 }
{ kty: LWE, alg: CRYDI2 }

{ kty: NTRU, alg: FALCON1024 }
{ kty: NTRU, alg: FALCON512 }

{ kty: HASH, alg: SPHINCS+-SHAKE-256s-robust }

{ kty: LWE, alg: Kyber-1024 }
{ kty: LWE, alg: Kyber-768 }
{ kty: LWE, alg: Kyber-512 }

Please focus your comments on establishing consensus for relevant values for `kty` and `alg`.

Regards,

OS



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIUR8efA4$>

[Image removed by sender.]<https://urldefense.com/v3/__https:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fv6kERm44AJw2Rwx8nmq-c7of45L5FbTjlApg70kVdFzo551o2OaOMS0VfKWXe0n1I_43upzNBY1UhZ8UDuIup8-YOU$>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.