Re: A modest proposal on extensibility - wrap up

Virginie,

Just to re-iterate the two minor points I made in response to Richard's
proposal:

(1) I don't believe we have a need or desire for additional values of the
KeyFormat enum or the usages strings
(2) The text change to handle the recognized values of other things, with
extensibility, is a little more involved that Richard says - to deal for
example with parameterized hash algorithms - but this should be ok.

I could do the editing for this tomorrow.

...Mark

On Tue, Oct 14, 2014 at 8:20 AM, GALINDO Virginie <
Virginie.Galindo@gemalto.com> wrote:

> Hi all,
>
> It looks like we are in a good direction to move forward on
> extensibility/errata. Thanks Richard for making that proposal.
>
> After discussing with Harry and Wendy, we came to the slightly modified
> proposal. We were thinking about submitting it as part of the proposed
> resolution to close the extensibility bug.
>
> ** process for extending W3C specification with new algorithms **
>
> 1. Wherever a string/enum value is defined, insert something like the
> following:
> 1.1. This specification defines values X, Y, Z
> 1.2. Implementations MAY support other values
> 1.3. When an extension is made to add a value, a reference should be added
> to the "Extensions" section
>
> 2. Wherever a string/enum value is used as a branch point, insert
> something like the following:
> 2.1. If X... If Y... If Z...
> 2.2. If another recognized value, process according to that value 2.3. If
> an unrecognized value, raise an NotSupportedError (or TypeError for
> enums)
>
> 3. Add an "Extensions" section as errata to the specification where links
> can be added to point to extension.
>
> **
>
> FYI, errata description in W3C can be found under
> http://www.w3.org/Consortium/Process/errata
>
> Hope this is agreeable to you.
> Virginie
>
>
>
> -----Original Message-----
> From: Harry Halpin [mailto:hhalpin@w3.org]
> Sent: lundi 13 octobre 2014 15:39
> To: Mike Jones; Mark Watson; Richard Barnes
> Cc: public-webcrypto@w3.org
> Subject: Re: A modest proposal on extensibility
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 10/12/2014 09:02 PM, Mike Jones wrote:
> > It's the extra layer of indirection that makes them completely
> > different and actually solves the problem of being able to list
> > extensions without modifying the base spec.  If they're equivalent to
> > you and others, then you should have no problem with the Web page
> > approach, and it would satisfy Microsoft's extensibility goals.  So
> > let's do that!
> >
>
> The list of extensibility algorithms is vetted by the W3C WG and in an
> official errata.
>
> I'm also happy to have the W3C/WG maintain a web-page with proposed
> extensions that have not yet made it to the official errata. That is at
> least good house-keeping as a pointer to proposals that have not gone
> through the WG.
>
> I think either of these solves Boris' issue but I think Ryan and Richard
> prefer having the errata as official.
>
> I think there is no huge difference in practice. Ryan's argument, as I
> understand it, is that keeping any forward references in an errata makes it
> easier for implementers to know what is really out there in terms of
> algorithms.
>
> I would just like to close this while keeping extensibility for curves
> like Curve25519 that aren't in main spec.
>
>
> > -- Mike
> >
> > -----Original Message----- From: Harry Halpin [mailto:hhalpin@w3.org]
> > Sent: Sunday, October 12, 2014 10:03 AM To:
> > Mike Jones; Mark Watson; Richard Barnes Cc:
> > public-webcrypto@w3.org Subject: Re: A modest proposal on
> > extensibility
> >
> >
> >
> > On 10/11/2014 06:40 PM, Mike Jones wrote:
> >> I’d been travelling internationally and so am just now getting to
> >> this.  The problem with Richard’s proposal is that updating the
> >> “Extensions” section he proposed would still require updating the
> >> specification for every extension – defeating the purpose.  A slight
> >> variant of it could work however.  If the “Extensions”
> >> section instead pointed to a Web page maintained by the W3C that was
> >> updated every time that an extension was defined, then only the Web
> >> page would have to be updated and not the base spec.
> >> That would achieve the purpose of being able to create extensions
> >> without modifying the base spec *and* provide an actionable way for
> >> implementers to locate extensions.
> >
> >
> > I see "references to extensions in errata" as just one layer of
> > indirection less than "link to web-page with references in errata".
> > Thus, they are functionally equivalent in my book, with the only point
> > that it's a bit harder to update errata (but hopefully W3C will make
> > this easier in the near-term future) but also easier for readers of
> > the spec to find the references.
> >
> >> As for the other topic of extending key formats, I believe that we
> >> already know that this is necessary.  For instance, 25519 keys are
> >> expressed in a different format than NIST EC keys.  That alone is
> >> enough of an existence proof to demonstrate that we must enable key
> >> format extensions.
> >
> >> -- Mike
> >
> >> From: Mark Watson [mailto:watsonm@netflix.com] Sent: Friday, October
> >> 10, 2014 2:09 PM To: Richard Barnes Cc: Harry Halpin;
> >> public-webcrypto@w3.org Subject: Re: A modest proposal on
> >> extensibility
> >
> >
> >
> >> Sent from my iPhone
> >
> >> On Oct 10, 2014, at 1:55 PM, Richard Barnes
> >> <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote: On Fri, Oct 10, 2014 at
> >> 4:34 PM, Mark Watson
> >> <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote: This seems
> >> fine, except: - we have discussed key format and agreed we do not
> >> want / need extensibility for this - no one has suggested we need an
> >> extensibility point for usages
> >
> >> I agree that key formats are low priority for extension, but I'm a
> >> little surprised that we would forego it entirely.  I guess it just
> >> means that extending the set would need a spec update (to add
> >> extensibility), which seems OK.
> >
> >> I'd suggest that we include a table which lists all the WebCrypto
> >> algorithms and for each one lists the specification(s) that define
> >> that algorithm. The initial value for the existing algorithms will be
> >> 'This specification' but we will add values - through the errata
> >> process - as we write extension specifications.
> >
> >> The definition of 'other specifications' will be revised to be
> >> restricted to those specifications listed in the table.
> >
> >> This seems fine to me.
> >
> >> The only remaining issue is whether we should arrange the procedures
> >> for import / export of keys for algorithms parameterized by a hash
> >> function such they it does not appear that import / export for the
> >> existing cases can be overridden, even though we constrain extensions
> >> to definition of new hash algorithm values in prose.
> >
> >> That was what I was trying to get at with the proposed branch
> >> structure: -- One of the hash functions defined in this spec...
> >> -- Another one you recognize... -- Error
> >
> >> It's not quite as simple as that in the specification text as we want
> >> to defer to the extension specification exactly how the new hash
> >> function is signalled, including the possibility that it is
> >> parameterized. But still, we can do this.
> >
> >> ...Mark
> >
> >
> >> --Richard
> >
> >
> >> ...Mark
> >
> >> Sent from my iPhone
> >
> >>> On Oct 10, 2014, at 8:45 AM, Harry Halpin
> >>> <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
> >>>
> >
> >
> >>>>> On 10/10/2014 05:27 PM, Richard Barnes wrote: Talking to a few
> >>>>> folks off-list, it seems like the extensibility discussion has
> >>>>> gotten a bit muddled.  The goal of this message is to try to
> >>>>> focus/clarify with a specific proposal. It sounds like the general
> >>>>> desiderata people have
> >>>>> are: 1. To make it possible to add new values for strings/enums
> >>>>> without major spec surgery 2. To make it easy for developers to
> >>>>> find extensions
> >>>>>
> >>>>> To that end, I would like to propose a way forward for
> >>>>> extensibility:
> >>>>>
> >>>>> <proposed-plan>
> >>>>>
> >>>>> 1. Wherever a string/enum value is defined, insert something like
> >>>>> the following: 1.1. This specification defines values X, Y, Z 1.2.
> >>>>> Implementations MAY support other values 1.3. When an extension is
> >>>>> made to add a value, a reference should be added to the
> >>>>> "Extensions" section
> >>>>>
> >>>>> 2. Wherever a string/enum value is used as a branch point, insert
> >>>>> something like the following: 2.1. If X... If Y...
> >>>>> If Z... 2.2. If another recognized value, process according to
> >>>>> that value 2.3. If an unrecognized value, raise an
> >>>>> NotSupportedError (or TypeError for enums)
> >>>>>
> >>>>> 3. Add an "Extensions" section to the bottom of the spec, where
> >>>>> links can be added to point to extension specs.
> >
> >> As noted on Bugzilla, as long as Extensions are in Errata, that's
> >> fine by W3C Process I believe.
> >
> >> cheers, harry
> >
> >>>>>
> >>>>> </proposed-plan>
> >>>>>
> >>>>> Does that overall approach seem agreeable to people?
> >>>>>
> >>>>> --Richard
> >>>
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUO9XaAAoJEPgwUoSfMzqcoZ8P/RijOqRTAhQhKMYpeHF6Ytg/
> /IBgtQtJAsH6jD6ZJox1Nn5/CPsyPci5hGwxth2dJgSsOrp6kimHNlK1IQabSqTi
> xIYiiWnygj8jSngjb0MQce4GfgKdo2+YELGwHT+X6X+S3k0tkW//J8Z7zI4msF4q
> 3v8fw4h0XcSj/aqCR6N86l5ki+RVLrJQesQXWc0lPZiNYNfL1j0MznV/Fusfp1/A
> 36eGNihw6lXAgyqg2adsiroAeCa6Q0HsmgeWUmBsHQpZrnuD+6juhmgJpcUuQCuo
> 3A6ELJXl4bSekfyG/skuCHMfw/I3e2AO3WSyxp80c4zjrti2PYsmCBfL8WuVARKJ
> 4SMa0XDvNjfZqgJGfYa9OIS/7n5dqmF+r8qDds15lU5AQKhB/cMLfuysLTlSVmx5
> an9NPRIocDAd40DE/YSFEs+AvpLoudHnd5YzV1goJxw8X8BvDSvY/EbwjLI8ShYG
> rkDR+hPOvTXe/YPllKxboDspZbph207vdE2/hOJFCtlVHP2bVMy8ElGWR7UpmW8t
> xPWBtoGhL7RKHITVYU8CorvpdrhR4RtQWQ75SwtIyltS97Ru+iXKT+D8gke9EJwx
> Q4JvKQefSv2ae/V79VeeSbvaLB54pgJ+9+xTzHo26zXYquKQfTopgKQjeC6zBbmQ
> hxXhmmscpwPE0rGgTlRW
> =nUWf
> -----END PGP SIGNATURE-----
>
> ________________________________
>  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.
>