Re: Web Crypto API - about named curve addition

All,

It seems to be that we could expect suggestions for additional algorithms,
or additional options within existing algorithms, to be an ongoing
occurrence, as new algorithms, curves, padding etc. are invented and
problems discovered with old ones.

I'd very much prefer that the base specification was able to handle such
future additions in a clean (non-monkey-patch) way and that we had a
process for considering and defining such extensions, rather than delaying
the specification further for the first such proposals that come along.

In fact, treating these first proposals as the first "test case" for the
extensibility of the specification would be an excellent way to validate
that the specification is indeed extensible in (some of) the ways we might
want.

So, I guess my preference is for anything that wasn't accompanied by a
detailed proposal in LC to be dealt with in an extension specification.

...Mark


On Wed, Jun 25, 2014 at 4:39 PM, Harry Halpin <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 06/26/2014 12:58 AM, Ryan Sleevi wrote:
> > On Wed, Jun 25, 2014 at 2:25 PM, Brian LaMacchia
> > <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.
>
> In general, is not surprising to fall behind the timeline in the
> charter (see HTML5's charter and note that our charter has CR in June
> 2014)), but given that deadlines for contributions to resolve the Last
> Call issues were agreed upon that are reasonable, a rechartering
> should not be necessary.
>
> Substantial changes could require a second Last Call, but we can make
> it quite short (i.e. 2 weeks). Wendy agreed when I discussed this with
> her.
>
> Whether or not any change is substantive can be determined when any
> change is actually sent to the WG.
>
>    cheers,
>      harry
>
>
> >
> >
> >>
> >>
> >> 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]
> >> *Sent:* Wednesday, June 25, 2014 1:59 PM *To:* Henri Sivonen;
> >> hi@okturtles.com; Brian LaMacchia *Cc:* public-webcrypto@w3.org;
> >> 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.*
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTq13GAAoJEPgwUoSfMzqccj8P/16wbIRzkb5FFXbTNWWZleFu
> Sh2NCCCx7srySE99LTU1ZvLWz5KjvJcAPs/a5TOf+uNivqMOkIe6k8AALBpqkwfl
> VucxxcmJ23hjP4lzoeBK6Y8W4QJho4n+V3LbLCVkoqpsb9vToAbPPXNco0sBC43L
> tqwbtWeiDGqoLuivaWEjdFYLK+Tw0QdphwUHfZOtull1jp7scFyGv5+2BCno5IrR
> qtw3zWiCR7Mpc4NXsGxMp0597QqcZD6JnhOsvo3yzITKwFPHQWbwCdM+3kH4rk3h
> E09VC3IYRGQYr+7qbId0cJAHpMLL3aXBj0v18VcGbIcOedOYd8x1vbOWUCLUWv+x
> kJe8x9VoE3sIqaLYYPqyuWHXv7uTWGphfOU2R3DsZPEZNkSXmNzrUZCD16MGu9ZQ
> 0udjIpESFofMbXgXcXNCoJ4u4WIh1q1yq0PSi5FRxIBSgSWKV17/6xKY+GwQ8Qjm
> +k7JqsMOUrA0tY3h0wQW9yQ+q3YcopPz9Agz2q7Nxo3WQCQF4wBuvP8VraMp4W5O
> 1WRDDn4LUWLyTftecuM0qOZCcyaIj1aucTG//GLkxRU7b9kPHGCJZYsDysiWgPdz
> zNnSNBjxm14KmFn1J7qdWQzxKLhPHJkIldr4hwZv/JGTFuDlDk6PdR/3SmLqEdye
> tyRVFTy3YGp3kXypNY0Q
> =qPlK
> -----END PGP SIGNATURE-----
>
>