On Feb 13, 2018, at 14:27, Yuriy Ackermann <yu...@fidoalliance.org> 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
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Reply via email to