[jose] COSE and JOSE Keys for Kyber

[Orie Steele <[e-mail]>]

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/

I reviewed the original registries established in:
https://www.rfc-editor.org/rfc/rfc7518.html#section-7

I also reviewed the latest "kty" and "alg" registered in
https://datatracker.ietf.org/doc/html/rfc8778

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.

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

- https://www.iana.org/assignments/cose/cose.xhtml
- https://www.iana.org/assignments/jose/jose.xhtml

{ 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
{ kty: OKP, crv: Bls12381G1, alg: ??? } ...
https://datatracker.ietf.org/doc/html/draft-ietf-cose-bls-key-representations-01#section-2.1.3
{ 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://www.transmute.industries>