RE: [W3C Web Crypto WG] about extensions to Web Crypto specification

If “3) Monolithic specification with fancier extension mechanism” and “4) Specification written in a way that it can be extended without requiring it to be revised” are equivalent in your mind, so be it.  Rather being “fancy”, allowing extension without spec modification seems as simple as it can get.  Nothing fancy about it.

Again, I wrote what I wrote to try to provide a concrete, actionable way forward.  I realize you don’t like it for some reason, Ryan.  Nonetheless, I’d be interested in hearing what others think, because it could provide us a straightforward way to address the extensibility issue once and for all.

                                                                -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, August 28, 2014 2:24 PM
To: Mike Jones
Cc: Mark Watson; GALINDO Virginie; public-webcrypto@w3.org
Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification



On Thu, Aug 28, 2014 at 2:21 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
Thanks for listing these three options, Mark.  That’s clarifying.  What surprised me is that there’s a fourth option which wasn’t listed (which I thought was being considered) that I believe is superior to the three you listed:

4) Specification written in a way that it can be extended without requiring it to be revised.

This is easy to do.  Every place that there’s a fixed list of choices in the spec, explicitly make it clear that the values listed are only the initial set defined, and that other values can be defined by other specifications and used.

As a specific example, EcKeyGenParams in https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#EcKeyGenParams-dictionary defines NamedCurve as:
The NamedCurve type represents named elliptic curves, which are a convenient way to specify the domain parameters of well-known elliptic curves. The following values are recognized:
"P-256"
NIST recommended curve P-256, also known as secp256r1.
"P-384"
NIST recommended curve P-384, also known as secp384r1.
"P-521"
NIST recommended curve P-521, also known as secp521r1.

After that, I would suggest adding the sentence “Other NamedCurve values MAY also be defined by other specifications and used.”

This is just Mark's proposal 3, and I've already explained the issues with this at such length that I'm losing the energy or desire to continue the discussion, because it's clear we're just circling in the same thing.


Likewise, in the SHA description at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#sha, after listing the current SHA algorithm names, I would add “Other names for additional SHA algorithms MAY be defined by other specifications and used.”

Etc.

This is really easy to do, editorially, and solves the extensibility problem.

As an existence proof, the JOSE specs use this technique to good effect and are therefore extensible without requiring modifications to them.  In fact, the WebCrypto spec extends the JOSE specs in https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#iana-section-jws-jwa without modifying them.  Note that even if we don’t have registries, we can still enable new specs to extend the base spec without having to modify it.

JOSE is not an API. As I've said repeatedly. How JOSE solves problems is great for JOSE, but neither responsible nor appropriate for API.

I realize you don't think this is an API, and so we'll continue to have this conversation over and over, but it just wouldn't be a thread if I didn't say the exact same thing I've been saying for two and a half years now.


I would ask everyone to consider this more flexible approach.  It lets us keep all the existing algorithms in the core spec, while being clear that new algorithms and parameters can be defined by other specs, as the need arises.

This note is intended to provide a constructive, actionable way forward to enable extensibility and let us move on to addressing other issues to finish the spec.

                                                                Cheers,
                                                                -- Mike

From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Thursday, August 28, 2014 12:53 PM
To: Mike Jones
Cc: GALINDO Virginie; Ryan Sleevi; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>

Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification



On Thu, Aug 28, 2014 at 12:37 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
What I don't understand is this: If you know how to express algorithms in extension specs, then why not just express them exactly the same way in the main spec?  I don't see carving up the spec into little pieces as adding any value.

​The difference is that with separate specifications, it's reasonable to do future extensions by revising those specifications​. Our extensibility story would be that we have component specs that are easy to update.

With a monolithic specification - and no extensibility mechanism - every extension involves a revision of the whole thing (or monkey-patching).

So the other option is a monolithic specification with a good extensibility mechanism. We are close, IMO, as the ability to add whole new algorithms is a universal extensibility mechanism. It's just quite blunt in some cases: if you use that mechanism to, say, add a new hash algorithm to RSA-OAEP, you end up with RSA-OAEP-2 and Ryan, at least, objects to that.

As I see it, there are three options:
1) Monolithic specification as is (Ryan, at least, does not like the RSA-OAEP-2 consequence)
2) Multiple distinct, easily revisable, algorithm specs (Mike, at least, does not like this)
3) Monolithic specification with fancier extension mechanism (Ryan, at least, does not like the proposals so far)

...Mark



________________________________
From: Mark Watson<mailto:watsonm@netflix.com>
Sent: ‎8/‎28/‎2014 12:28 PM
To: GALINDO Virginie<mailto:Virginie.Galindo@gemalto.com>
Cc: Mike Jones<mailto:Michael.Jones@microsoft.com>; Ryan Sleevi<mailto:sleevi@google.com>; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>

Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto specification
If it was going to unblock us on extensibility and EC then I could justify prioritizing work on that and have significant time to spend on it in the next week. I would expect it's largely a question of cloning the spec five times and then deleting all-but-the-bit-we-want from each one, adding some common bollerplate and pruning the references.

...Mark

On Thu, Aug 28, 2014 at 12:03 PM, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:

Ryan,  Mark,

what would be the realistic delay for you as editors to actually execute that split?

Virginie



---- Ryan Sleevi a écrit ----




On Thu, Aug 28, 2014 at 11:19 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
You wrote “Perhaps this is the solution: pull out all the algorithms into, say, five extension specifications:
- RSA
- AES
- EC
- Hash algorithms
- Key Derivation
”

That would just make things needlessly harder on developers.  As a working group, we owe it to developers to make the core spec as easy to use as possible, while still enabling extension in a timely manner.  Yes, obtaining consensus in the working group may be painful, but that’s not an excuse for us to inflict enduring pain on developers using our specs as a result.

I strongly oppose removing any of the existing algorithms from the core spec.

                                                                -- Mike


Mike,

The above proposal is entirely reasonable, and reflects the approach other WGs have done, whether it be for treating elements like CSS, treating features of the Web such as Service Workers, DOM events, gamepads, or File access, or in handling elements like WebGL.

Despite your concerns, developers have not only succeeded, they've thrived AND benefitted from clear and digestable specifications, compared to the 'traditional' hundreds-of-pages-of-boilerplate.

I would again encourage you to reconsider your position, and also helpfully clarify whether this is a personal concern or if you have discussed it within the broader space of your colleagues at Microsoft (including the IE team), so that we can be clearer both what the concerns are, and how to solve it.

You can see that Mark and I are both trying to expend significant energy to find solutions to deal with real and ongoing problems that this WG is facing. It would be helpful for dialog if you would further explain your objections and, when possible, provide alternatives you feel meet these concerns.

I, again, remind you that these specifications, as with the specifications for things like HTML or XMLHttpRequest, do not and have not targetted developers. They target, primarily, implementors, to ensure that implementors can correctly create interoperable implementations. The W3C has a venue for Developer-facing documentation and guidance, and it's not the specification.

Thus, your first and foremost objective when evaluating the specification is not, should not, and cannot be "Is this hard for developers to understand", but "Is this easy for implementors to understand and reach interoperable implementations"

To that end, Mark's proposal, which I've said for some time, absolutely gives greater ability and flexibility to do just that.
________________________________
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.