- From: Ryan Sleevi <sleevi@google.com>
- Date: Sun, 15 Dec 2013 11:52:27 -0800
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, public-webcrypto-comments@w3.org
- Message-ID: <CACvaWvYTcknxmUYjcZW0c4wBxDakaHFOHnWGsb-AHiRNC3iTtQ@mail.gmail.com>
On Dec 15, 2013 10:10 AM, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote: > > 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 languages. > > 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