Hi all, I'd like to get some input from the WGs on the history and intent of the relationship between elliptic curves and their corresponding key type(s).
At present, it seems that for every elliptic curve listed in the respective COSE and JOSE registries (https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves , https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve), there is exactly one key type that is used for points on that curve. For example, the NIST curves P-256, P-384, and P-521 use key type EC (for JOSE) and EC2 (for COSE), and the "CFRG curves" Ed25519, Ed448, X25519, and X448 use OKP. There is not a huge amount of guidance in the foundational RFCs, but I'll try to summarize the hints I found, below: JOSE only had the NIST curves in RFC 7518, so all the original elliptic curves used the "EC" key type. The registry template for curves does not include the "kty" value(s), but the template for key parameters does. In particular, the column heading has the formulation 'Used with "kty" Value(s)' that admits more than one "kty" for a given parameter (and indeed, "crv" us used with both "EC" and "OKP". But this seems to only be used in practice, at least so far, as just another means for scoping the parameter name -- the aforementioned "crv" entries appear on separate lines in the registry, with the implication that the "crv" parameter might have a different interpretation depending on which "kty" value it was seen with. RFC 8037 added the CFRG curves and the "OKP" key type, with description: A new key type (kty) value "OKP" (Octet Key Pair) is defined for public key algorithms that use octet strings as private and public keys. It has the following parameters: [...] o The parameter "crv" MUST be present and contain the subtype of the key (from the "JSON Web Elliptic Curve" registry). [...] In particular, the "public key algorithms that use octet strings as private and public keys" suggests (at least to me) that the document was written with an assumption that a given public-key algorithm would have a single way in which to represent public and private keys. COSE has done things a bit differently than JOSE (and not just by changing the "kty" name to "EC2"), in particular by having a "key type" column in the registry for COSE Elliptic Curves. I note that in the live registry and in RFC 8152, the column heading is the singular "Key Type", but in RFC 8152 the description of this column is "This designates the key type(s) that can be used with this curve" that apparently admits more than one. draft-ietf-cose-rfc8152bis-algs does not have a description of the registry in its IANA Considerations section to refer to for comparison. There are admonitions throughout RFC 8152 and the bis, that applications must check that the curve and key type are consistent and reject a key if they are not. As written, that seems to allow a notion of "consistent" that is not strictly 1:1, but all of the curves defined so far only have that 1:1 mapping, and trying to use any other "kty" for an existing curve would run into interop problems with existing implementations that reject other "kty" values for that curve. Do we expect a strict relationship where each curve has exactly one "kty" that it's used with? If not, in what scenario(s) would there be multiple "kty" values to use with a single curve? Thanks, Ben _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
