- From: Brian LaMacchia <bal@microsoft.com>
- Date: Wed, 25 Jun 2014 23:31:16 +0000
- To: Ryan Sleevi <sleevi@google.com>
- CC: GALINDO Virginie <Virginie.Galindo@gemalto.com>, Henri Sivonen <hsivonen@hsivonen.fi>, "hi@okturtles.com" <hi@okturtles.com>, Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, "w3@bluematt.me" <w3@bluematt.me>
- Message-ID: <777941cf10254effb504ee07d64bad4c@BL2PR03MB242.namprd03.prod.outlook.com>
I offered the “All curves are optional to implement, including the NIST curves” option since that seems to be the option closest in line with this WG’s apparent strong preference for no mandatory-to-implement algorithms, Bug #25985 notwithstanding. If as part of resolving Bug #25985 the WG is now willing to include mandatory-to-implement algorithms in the specification, then my second option is clearly the better choice. Commenting on my second option (P-256 and P-384 mandatory, all others optional), Ryan replies that this appears to conflict with Bug #26080, which claims that the NIST Prime curves are “unsafe” (in the words of the bug author). The claims of “insecurity” contained in that bug are based on unsubstantiated claims from the SafeCurves website that border on conspiracy theory. To date the cryptographic community has seen no technical evidence of willful manipulation in the construction of those curves. Furthermore, those curves are mandated by Suite B and thus there are large customer segments that will continue to demand support for those curves. I’ll leave it to the W3C folks to address the questions concerning rechartering. --bal From: Ryan Sleevi [mailto:sleevi@google.com] Sent: Wednesday, June 25, 2014 3:59 PM To: Brian LaMacchia Cc: GALINDO Virginie; Henri Sivonen; hi@okturtles.com; Harry Halpin; public-webcrypto@w3.org; w3@bluematt.me Subject: Re: Web Crypto API - about named curve addition On Wed, Jun 25, 2014 at 2:25 PM, Brian LaMacchia <bal@microsoft.com<mailto:bal@microsoft.com>> wrote: Hello Virginie, I will commit to providing text for at least the MSR curves, but we (Microsoft) disagree with your suggestion that the bug be resolved via extension specifications. Our consensus opinion is that it would be much better if we try to resolve this bug with changes to the main text. As has been pointed out previously, the current text in the draft implies that in order to implement ECDSA and ECDH, one must implement all of the NIST Prime curves, and the text in sections 18.8 and 18.9 must be modified to permit anything other than the NIST curves to be used. So main text edits are required to resolve this bug in any way other than “won’t fix”. This is agreed, and already being tracked as https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618 as the set of necessary changes to be made to the main specification to accomodate this. Given all algorithms are optional, we think that we should put all of these non-NIST curves into the main text and then choose one of the two following positions: 1) All curves are optional to implement, including the NIST curves This would seem to conflict with https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 2) NIST P-256 and NIST P-384 are mandatory-to-implement if you implement ECDSA and/or ECDH, and everything else is optional. (I would not argue for P-521 to be mandatory as it’s just not used in practice anywhere.) This would seem to conflict with https://www.w3.org/Bugs/Public/show_bug.cgi?id=26080 If we following this procedure, then additional curves may be added to the list of named curves and we will just have to change the NIST curve-only text. We can add Curve25519, the MSR curves and even the Brainpool curves (as I pointed out in my original bug comment) as a group to accommodate the various requests that have been received. We think that’s the best way forward. Harry, Virginie, Wendy, If the WG proceeds this route, will we need to recharter in order to accommodate a new Working Group Working Draft (and potentially Working Group Last Call), given the nature of these substantive changes? After we deviated from our last set of delays from our original chartered timeline ( http://www.w3.org/2011/11/webcryptography-charter.html ), it was suggested that any further delays will require a rechartering. Assuming you agree with this revised proposal, I’ll commit to being point person for the MSR curves and collaborating with Matt and Henri on a combined set of edits to permit non-NIST curves to be used in Web Crypto. Thanks, --bal From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>] Sent: Wednesday, June 25, 2014 1:59 PM To: Henri Sivonen; hi@okturtles.com<mailto:hi@okturtles.com>; Brian LaMacchia Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; w3@bluematt.me<mailto:w3@bluematt.me> Subject: Web Crypto API - about named curve addition Dear Henri, Greg, Brian, Thanks for reviewing this recent comment in Web Crypto API bugzilla https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839#c39 This is the proposal from the chair to resolve that bug, and it implies some quick actions on your side. Regards, Virginie ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Received on Wednesday, 25 June 2014 23:31:49 UTC