Hi Yuri,

The COSE specification probably should not change to accommodate this. The IANA 
COSE algorithm registry should be used instead.

There are several options:
- Write a standards track IETF document and get it set in the  IANA COSE 
registry<https://www.iana.org/assignments/cose/cose.xhtml>.
- Write a specification (presumably public) and get it set  IANA COSE 
registry<https://www.iana.org/assignments/cose/cose.xhtml>.
- Use an identifier in the private range and publish it only in FIDO docs.

LL



On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann 
<yu...@fidoalliance.org<mailto:yu...@fidoalliance.org>> wrote:

Hey guys. I work for FIDO Alliance. We are currently selecting a list of curves 
we going to support. We want to support secp256k1 in COSE, as we are already 
supporting it in UAF, and we have companies who really want it.

I know that in security considerations you've said that there is possibility of 
collision of the signatures from k1 and p1, but the chances of such thing 
happening are enough low for it to be ignored.

We are proposing adding secp256k1 into list of curves, in section 13.1 with 
value 8

Regards. Yuriy

[FIDO Alliance] <https://fidoalliance.org/> Yuriy Ackermann
Senior Certification Engineer
email: yu...@fidoalliance.org<mailto:yu...@fidoalliance.org>
skype: ackermann.yuriy
website: https://fidoalliance.org<https://fidoalliance.org/>

_______________________________________________
COSE mailing list
COSE@ietf.org<mailto:COSE@ietf.org>
https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

Reply via email to