On Mon, Jul 11, 2022 at 08:59:11AM -0500, Orie Steele wrote: > > 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.
Why can it not be OKP? > It could be a unique class name for lattice, hash-based, isogeny... > etc... (each a generic family) No, that will not work. The key format is required to be uniform and to encode the structure of keys. This presents two major issues: 1) The problem classes are either just too diverse for uniform keys to exist at all, or such format would result significant key size expansion. 2) None of the proposed algorithms have keys that encode the structure of their underlying problem. > Based on the existing conventions there is no obvious choice. Based on existing precedent, there is obvious choice, and it is OKP. For Kyber, which is not totally incompatble, I do not think there is anything capable of rivaling that. For totally incompatible stuff like Dilithium, Falcon and Sphincs, I think the only thing that could be capable of rivaling that is AKP (note: I am not saying AKP is outright better). > 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. > > > Given, RSA and EC/EC2 are "families"... These "families" actually encompass all algorithms that can use key of kind. Which would lead to somewhat whacky stuff if followed strictly: - Kyber and SIKE would have the same kty, as both are KEMs with octet- string keys. - Dilithium2 and Dilithium3 would be different kty's, as algorithms are actually different. RFC 8037 would have had three kty's in design like that: Ed25519, Ed448 and the X-functions (aside: what separates Ed25519 and Ed448 is what makes the EdDSA algorithm overload technically work). Of course, that would have been more complicated than how RFC 8037 ended up. > Option 1: (a single post quantium "family") > { kty: AKP, pset: SPHINCS+-128s } > { kty: AKP, pset: CRYDI3 } > { kty: AKP, pset: FALCON-xxx } The whole point of AKP is to subtype on "alg" and not have "pset". > Option 2: (specific system for post quantum family) > { kty: CRYDI, pset: CRYDI3 } > { kty: FALCON, pset: FALCON-xxx } > { kty: SPHINCS+, pset: 128s } This seems to increase complexity with no benefit. And as pointed above, is not consistent with strict reading of the specification (not that I think that is a good idea). > Option 3: (generic system for post quantum family) > { kty: LATTICE, pset: CRYDI3 } > { kty: LATTICE, pset: FALCON-xxx } > { kty: HASH, pset: SPHINCS+-128s } This will not work due to reasons stated above. > Of these options I still think Option 1 matches most closely the > existing systems... That's because replacing alg with pset makes it isomorphic to OKP. > 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 No, that does not follow. secp256k1 and secp384r1 are not only members of same uniform key class, they admit the same algorithms. Dilithium and Falcon do not admit the same algorithms, and admit just a single algorithm. They (and Ed25519!) are in the same uniform key class tho. In the end, there are three possible conclusions: - Both use OKP. - Both use AKP. - Dilithium2, Dilithium3, Dilithium5, Falcon512 and Falcon1024 all have different kty. I do not think the last one is a good idea. > 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. No, that does not follow either. Ed25519 and secp256r1 are not in the same uniform key class. Which impiles the kty's have to be different. Dilithium and Falcon are in the same uniform key class. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
