I would not do the private range version below if you are going to publish
in FIDO docs.  This is really meant for completely closed and experimental
and not for any public standards use.




From: COSE [mailto:cose-boun...@ietf.org] On Behalf Of Laurence Lundblade
Sent: Tuesday, February 13, 2018 9:36 AM
To: Yuriy Ackermann <yu...@fidoalliance.org>
Cc: cose@ietf.org
Subject: Re: [COSE] Adding secp256k1


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
<https://www.iana.org/assignments/cose/cose.xhtml>  IANA COSE registry.

- Write a specification (presumably public) and get it set
<https://www.iana.org/assignments/cose/cose.xhtml>  IANA COSE registry.

- Use an identifier in the private range and publish it only in FIDO docs.






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

 <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> 


COSE mailing list

Reply via email to