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

Reply via email to