There is not a single elliptic curve system I am aware of that is acknowledged as being post quantum.
We're really just looking for consensus on what to use for `kty` for new post quantum schemes... it can't be OKP, EC, EC2. It could be a unique class name for lattice, hash-based, isogeny... etc... (each a generic family) But then the actual type would have to be signalled elsewhere, for example: dilithium, kyber, falcon, sphincs, ntru, etc... (each a specific family) Based on the existing conventions there is no obvious choice. https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key, such as "RSA" or "EC". "kty" values should either be registered in the IANA "JSON Web Key Types" registry established by [JWA] or be a value that contains a Collision- Resistant Name. The "kty" value is a case-sensitive string. This member MUST be present in a JWK. A list of defined "kty" values can be found in the IANA "JSON Web Key Types" registry established by [JWA]; the initial contents of this registry are the values defined in Section 6.1 of [JWA]. The key type definitions include specification of the members to be used for those key types. Members used with specific "kty" values can be found in the IANA "JSON Web Key Parameters" registry established by Section 8.1. Given, RSA and EC/EC2 are "families"... Option 1: (a single post quantium "family") { kty: AKP, pset: SPHINCS+-128s } { kty: AKP, pset: CRYDI3 } { kty: AKP, pset: FALCON-xxx } Option 2: (specific system for post quantum family) { kty: CRYDI, pset: CRYDI3 } { kty: FALCON, pset: FALCON-xxx } { kty: SPHINCS+, pset: 128s } Option 3: (generic system for post quantum family) { kty: LATTICE, pset: CRYDI3 } { kty: LATTICE, pset: FALCON-xxx } { kty: HASH, pset: SPHINCS+-128s } Of these options I still think Option 1 matches most closely the existing systems... See this list of "EC" types... that have drastically different security properties: - https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve - https://safecurves.cr.yp.to/index.html If it's ok to have "secp256k1" and "secp384r1" both use kty: EC.... Then it follows that its ok for dilithium and falcon to both use kty: LATTICE If it's ok to have "Ed25519" us "OKP" and "secp256r1" use EC.... Then it follows that it's ok for dilithium and falcon to both use kty: CRYDI and FALCON. Can we agree to eliminate option 1? OS On Sat, Jul 9, 2022 at 3:50 AM Ilari Liusvaara <[email protected]> wrote: > On Fri, Jul 08, 2022 at 10:34:11PM +0200, Anders Rundgren wrote: > > I can only iterate my claim that overloading an existing definition is > an unusual solution. > > > > However, since even the author of > https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 > > have abandoned [*] the (IMO) most logical interpretation, I guess > > this is it: > > > > All new keys having a "crv" SHOULD have "kty" = "OKP". > > Well, if the new key is some prime-field weierstass elliptic curve, > then it should be EC (EC2 in COSE). EC/EC2 was designed for those > things. > > BLS is not prime-field, so it does not fit EC/EC2. > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
