RE: A modest proposal on extensibility

On Oct 11, 2014 9:41 AM, "Mike Jones" <Michael.Jones@microsoft.com> 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.

I don't think it would. The entire point of the W3C Process improvements is
to try to make AND ENCOURAGE spec authors to do just that!

That is, continually updated via errata that reflects reality, rather than
registries or, as inevitably happens, WHATWG forks.

I understand you're coming at this problem as a veteran of the IETF
process, in which Errata are equivalent to Big Bugs, but that's not the
case. The WHATWG - responsible (in effect) for specing everything your UA
does, lives by _living_ specs. This has been the inherent conflict with
something like HTML - no HTML spec ever produced by the W3C has ever
reflected what UAs do or need (in the non-normative, but necessary for web
compat sense) to implement.

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

It is a non-goal of ours to be able to create extensions without modifying
the base spec.

If we go down the path of a static base spec, then I think we'll just see a
fork of the spec that reflects an integrated reality develop in the WHATWG.

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

No, it doesn't. The non-NIST EC keys do not require a
non-(SPKI,PKCS8,JWK,RAW) format.

It requires flexibility in how those keys are expressed in those formats,
but does NOT require introducing some Curve25519 specific format capable of
expressing algorithm and attributes.

>
>
>                                                             -- 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> wrote:
>>
>> On Fri, Oct 10, 2014 at 4:34 PM, Mark Watson <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> wrote:
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> >
>> >
>> >> 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)
>> >
>> > iQIcBAEBAgAGBQJUN/8KAAoJEPgwUoSfMzqcTlAQALObP2+Cwaka8+/S3abpQhuS
>> > rN1RWucStMZDoJOlKo+0PvEZTxzsmr71561m3ijb54p9heI7erU4wbeH50sF4LxD
>> > DZBXj8tLKTVgLfugbaSKiHpjR/Pyf2eWCOcfV+mbnSnSh+Q0w4Yf8BlrZi5oB3p6
>> > ce3L7HxxuOux2MXGvxxYep4PH8UK3S2L4WJXilCMskQYj9qrd6vXspcw3qvGwZbi
>> > V1QjvqHktm3JO9w9FKCRec516llD5WJ36Ltg4BkPixoNPV6MPThDW6j59skysmE0
>> > 4Wo0bGCgz2mcNou19C1FrdMZ6odX9aVZH0DHDD+/CzzMGw5jQcgmpUzOFVkzxcew
>> > SAT1QcIKpKzjryS/xS7YXC/Nzao8AxwFy+ucIF3N62f0SW2p4HJJwG7GxPvfBGEU
>> > S5ljf3xqbDnKPQ9+m5pHzN1LxaPe+zYiie+OQinC7l6tE0k+qewGAKIwXGkNV8hL
>> > 9ldLEtSDw7bJR7GrL/8aMdbiLquub08eFdaPlmrh24a8qmjqeOKn+5o2heWF4Oih
>> > F833shgvq+YPhJZrEbiw117GQTWEQRl3F6SGG9b5F6oU9idtsUmxAIMOIuqAQ81i
>> > ebjLPGRuSt9p6dY5qMJ4/VM1XWR2cIkc1dOmVurL74OezRT/XeJLJRQ+dts2vodk
>> > +mKQlPwShHMN85bsjqYf
>> > =E1rh
>> > -----END PGP SIGNATURE-----
>> >
>
>