W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > December 2013

Re: Web Crypto -- Named Curve Dictionary (adding secp256k1)

From: Ryan Sleevi <sleevi@google.com>
Date: Sun, 15 Dec 2013 11:52:27 -0800
Message-ID: <CACvaWvYTcknxmUYjcZW0c4wBxDakaHFOHnWGsb-AHiRNC3iTtQ@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, public-webcrypto-comments@w3.org
On Dec 15, 2013 10:10 AM, "Melvin Carvalho" <melvincarvalho@gmail.com>
> Harry and David suggested I send a message to this group.  I was
wondering if the crypto group may consider adding support for secp256k1 in
the browser Named Curve dictionary.
> http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary
> enum NamedCurve {
>   // NIST recommended curve P-256, also known as secp256r1.
>   "P-256",
>   // NIST recommended curve P-384, also known as secp384r1.
>   "P-384",
>   // NIST recommended curve P-521, also known as secp521r1.
>   "P-521"
> };
> Over the last year, there has been a significant increase in deployment
for this curve.  It's used in bitcoin and many other crypto currencies.
Bitcoin deployment now numbers in the millions of users and hundreds of
companies.  There are also free software implementations in most
> For more background on Koblitz curve used by bitcoin see:
> https://bitcointalk.org/?topic=2699.0
> I'm aware that the API tends to expose what's existing in NSS, but, imho,
if it were possible to add support for this curve would be a great step to
help to many people that already work with crypto currencies in the browser.

That is not accurate. The API tends to expose what is universal in the
cryptosystems that browsers and user agents already have. This is, among
other things, called out in the charter.

With respect to secp256k1, only NSS and OpenSSl have implemented it. I am
not aware of any implementations from MSFT or AAPL, for example.

To the extent WebCrypto is 'just' a registry, this addition seems fine, but
as to whether it will ever actually be implemented and exposed (ala SEED,
ala GOST), I defer that to the other UAs. It would certainly be a feature
at risk that, given current implementation status, would not meet our exit
criteria for CR and thus be removed.

There is a tension here because this API is not trying to be proscriptive
or dictate what UAs MUST implement to provide 'good' crypto. It merely
seeks (at this time, at least) to expose what is already there.
Received on Sunday, 15 December 2013 19:52:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:26 UTC