On 2022-03-24 15:12, Orie Steele wrote: <snip>
If we are not going to use OKP for new EC keys.... why did we create it?
OKP was undoubtedly created with good intents. However, shutting the door to a more modular and pluggable approach to crypto system support (which currently is on the "menu"), is IMO a VERY BIG decision. AFAIK, each of the CURRENT kty definitions represent: - Keys for a more or less specific crypto system - A unique namespace holding other, and for the associated key type and algorithms suitable parameters. <snip>
We need to write a convention and agree to it.
Totally agree. It is now or never :) My suggestion is simply freezing the existing kty definitions and create new ones when needed, like for BLS. Using this convention, a generic PQK would not work. Since few if any cryptographic platforms use COSE or JOSE as their native format, conversions will usually be needed. IMO, this kty-specific, code naturally belongs to the same code base (aka provider) that implements the actual algorithms. Thanx, Anders
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 <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] <mailto:[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 <https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html> thanx, Anders _______________________________________________ COSE mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose <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
