On Feb 13, 2018, at 14:27, Yuriy Ackermann <[email protected]> wrote: > > We are proposing adding secp256k1 into list of curves, in section 13.1 with > value 8
Hi Yurij, please have a look at Section 16.8 of RFC 8152. This details the procedure for adding new curves. In particular, it defines the different registration policies that apply to different number ranges that could be used here. Some of the number ranges are “Standards Action”, because they are encoded slightly more efficiently but are not very large, so there should be some consensus for using up numbers in those ranges. Others are “Specification Required” or even just “Expert Review”. Analogously, Section 16.4 of RFC 8152 is used for new algorithms. Again, it defines the different policies that apply to different number ranges that could be used here. One example of exercising this in a Standards Action was RFC 8230, which adds algorithm and key type values to COSE to support some older RSA-based signature and key encryption algorithms that weren’t listed in RFC 8152. While I can’t comment on the merits or demerits of secp256k1 (or even whether key type EC2 would be the right one here), if you want to get the number 8 here for the curve, writing up a short Internet-Draft and getting consensus to move forward with it as a standards-track RFC like RFC 8230 would be the correct procedure. Or maybe it’s not that important to save that one byte, and you can go for Specification Required, possibly pointing to one of the existing FIDO documents as the specification (or making up a new one, possibly even an independent track RFC). Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
