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