Re: A modest proposal on extensibility - wrap up

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/14/2014 09:09 PM, Wendy Seltzer wrote:
> On 10/14/2014 08:32 PM, Mike Jones wrote:
>> W3C experts – could you tell us practically what it takes to
>> update the errata page for a spec, both process wise and timeline
>> wise? Does it require a working group action or is it just
>> someone recording the contents of an e-mailed request on the web
>> page?  Is there a review process or are proposed errata simply
>> recorded as they come in?  I’d like to get some sense of how
>> easy/hard this will be to do in practice and who will have the
>> rights to update the page.
> 
> Here's the W3C Process on errata:
Correction: here's the new process link:
http://www.w3.org/2014/Process-20140801/#errata

> 
> The WG needs to propose changes to appear on errata pages, and to 
> approve them through the full process before new features become 
> normative, That process can go quickly (more quickly under the
> recent process revision), if the group can get consensus and review
> quickly. On the plus side, you have royalty-free patent commitments
> on those normative extensions.
> 
> --Wendy
> 
>> Responding to Mark’s comments, I could imagine someone inventing
>> a new key format, so I’d think that KeyFormat should be a
>> defined extension point. As much as I’m fond of JWK, it may not
>> be the last key format ever.  I’m fine not having usages be an
>> extension point.
> 
>> -- Mike
> 
>> From: Mark Watson [mailto:watsonm@netflix.com] Sent: Tuesday, 
>> October 14, 2014 11:21 AM To: GALINDO Virginie Cc: Harry Halpin; 
>> Mike Jones; Richard Barnes; public-webcrypto@w3.org Subject: 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<mailto: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<mailto:hhalpin@w3.org>] Sent: lundi 13 
>> octobre 2014 15:39 To: Mike Jones; Mark Watson; Richard Barnes
>> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>> Subject: Re: A modest proposal on extensibility
> 
> 
> 
>> 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<mailto:hhalpin@w3.org>] Sent: Sunday, 
>>> October 12, 2014 10:03 AM To: Mike Jones; Mark Watson; Richard 
>>> Barnes Cc: 
>>> public-webcrypto@w3.org<mailto: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<mailto:watsonm@netflix.com>]
>>>> Sent: Friday, October 10, 2014 2:09 PM To: Richard Barnes Cc:
>>>> Harry Halpin;
>>>> public-webcrypto@w3.org<mailto: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<mailto:rlb@ipv.sx>>> wrote: On 
>>>> Fri, Oct 10, 2014 at 4:34 PM, Mark Watson 
>>>> <watsonm@netflix.com<mailto:watsonm@netflix.com><mailto: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><mailto: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
>>>>> 
> 
> 
> 
>> ________________________________ 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.
> 
> 
> 

- -- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUPcnvAAoJENTy3wcgk0elDC4QANQOX+mFC4THz/PooAKgsVUI
rva4IbelMCyqVhwLjPIvp+oQeYziiuZjP3MgItj+Tjm+CK/Sqs90Ja2DFIBfJQGS
Vs8OJRDEs1uEgaCX1HMqguPB9R+A35Bpc5hdi7JYaa2ZpBDV+2e65oziKlJeCmYj
2OjoJ0H1AjU3IHewZNM/4tcDIQKgdtd72iFF10SlqNY4cEM/1alv+mzSA4/5j4JZ
RPZXhzsShrxCvukTgGJZfowMMd+qoD2w8I4ULimhXkNHM2i+artQFw9921INxyg5
dOin8hLvQBpVYYVH84vGCqW66sB9K/QzaWkR68MDVLyQOXwxQMtIIcdrHLgWJjMW
RszvG5CU9JNzdd51H/AMYGy4XT9HjEUISI7N2+IKFHWep+N5UGziPRudrGkBs5iw
v/eMJy7HdTIQrp7T22HZ3FoQD8obS/bjM+m9WSnxjAWqOCscBylJQ/wDp6kW/wdD
KkgfA9WWHuv1nLBr3Q7rh4JrMjAMF6ZWB8jSQ9DwglK0u1FH4giE0od5RhF/jPfi
Xwt24QLLz99j6Ifdgo3wMNbjbhK1j6hX5cGUwSpi8fFoFNtzByLscwwwQCUBuPW5
DOCDNZvm8/l8pBJleDeM0duymrYIQYWYakQQNeLjb71tuvzDdxvqMoEeHV0CRfa4
xvcpCO9IqV+RB7srwwyn
=IUC9
-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 01:12:25 UTC