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>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
