Blimey. I've totally missed it. I will email AINA then. Thank you.
Regards. Yuriy [image: FIDO Alliance] <https://fidoalliance.org/> * Yuriy Ackermann * Senior Certification Engineer *email:* yu...@fidoalliance.org *skype:* ackermann.yuriy *website:* https://fidoalliance.org On Tue, Feb 13, 2018 at 5:36 PM, Laurence Lundblade < llund...@qti.qualcomm.com> wrote: > 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> > 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 > > [image: FIDO Alliance] <https://fidoalliance.org/>*Yuriy Ackermann * > Senior Certification Engineer > *email:* yu...@fidoalliance.org > *skype:* ackermann.yuriy > *website:* https://fidoalliance.org > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > >
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose