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-----

Received on Monday, 13 October 2014 13:38:45 UTC