In this case, I think they are lucky to be actually having curves, and not some other thing that signals the actual key type.
[image: Screen Shot 2022-03-24 at 8.05.03 AM.png] https://datatracker.ietf.org/doc/html/rfc8037#section-2 I think it's a mistake to not use OKP for an elliptic curve public key cryptosystem, especially if you will need to register a value for `crv` AND you won't be using `y`. I think the MUST for `crv` in there is also a big mistake, since OKP can now only be used for EC... but we already had EC. If we are not going to use OKP for new EC keys.... why did we create it? To recap the problems with kty: 1. RSA isn't a key type, it's a cryptosystem family (1024, 2048, 4096, etc....) 2. EC requires x and y because of a sad patent that is now expired, we would have compressed from the start if we could have. 3. OKP works only for EC keys, and implies compression iirc. Registering a new cryptosystem is getting harder and harder because of these problems... there is a lot to debate and lots of possible ways that we could proceed. We need to write a convention and agree to it. IMO, the convention moving forward should be: 1. If you are registering an elliptic curve, use OKP. 2. If you are registering a post quantum system, use PQK.... or if we want, we can split PQK into "lattice", "hash" and "isogeny" variants.... so you can register your system under those... we SHOULD NOT be registering a new kty for every new cryptosystem. Are pairing friendly curves worth their own kty? seperate from OKP?.... I don't think so, but the considerations from 2 apply to pairing friendly curves much like they apply to lattice based systems. Registering kty seems to not be enough, so we will also register some `alg` and then we will have the issues we outlined on this issue here: https://github.com/mesur-io/post-quantum-signatures/issues/50 If `alg` remains optional, PQK keys will need to register yet another field to signal dilithium, falcon, sphincs or xmss parameters... Every parameter that is required is a chance to make mistakes. When keys are generated, per NIST 800-57 they should be used for 1 purpose, and configured for 1 algorithm, and this should not change... making alg optional was a mistake. You generate a key and then it's immutable... having key representations that have algorithms that "pop in and out of existence" due to optionality, is dangerous. In the future, when someone figures out how to do "pairing friendly ECDH" should BLS12381 keys just magically start supporting that?... no alg? why not? Imagine if knowing the key representation was spec valid, meant knowing it was also safe to use... you need alg to know that. An optional algorithm increases the chances of security misconfiguration, and invites additional key parameterization that can easily lead to bugs. TLDR; Let's write a rule for making sense of this moving forward, then apply the rule to BLS12381 and Post Quantum systems, to determine what we need to register. OS On Thu, Mar 24, 2022 at 3:51 AM Anders Rundgren < [email protected]> wrote: > This I-D should IMHO hook into the previous PQK versus OKP discussions. > > Since we apparently need additional RFCs for each new crypto system, the > only gain with overloading OKP is saving one IANA registration. > > In this particular case, I would strongly recommend defining "kty" as > "BLS". > > Code-wise this is close to a no-issue: > switch(keyType) { > case "EC": > ... > > case "RSA": > ... > > case "OKP": > case "BLS": > ... > > However, this is a big simplification because in object oriented platforms > like Java, BLS keys would anyway be represented by specific classes in the > same way as Ed25519/Ed448 and X25519/X448 are today. That is, possible > code sharing isn't for real, while confusion is. > > Related: > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html > > thanx, > Anders > > _______________________________________________ > 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
