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

My order of preference (most to least) is (2), (3), (1).

(3) is in my mind the least-worst fallback for the eventuality that we
cannot get consensus on what constitutes a reasonable extensibility
mechanism for algorithm parameters. Mike's proposal seems reasonable to me.

...Mark


On Tue, Sep 2, 2014 at 3:47 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  These are my preferences in order:
>
>
>
> -          Scenario 2 : We work harder on the extension mechanism.
>
> This is the right solution.  In addition, I’d previously proposed specific
> language to accomplish this.  At each extension point, we should include
> language something like “Other values may be defined by other
> specifications and used.”
>
>
>
> -          Scenario 3 : We fragment the specification into several
> specifications, by algorithm family. This scenario looks like scenario 1,
> but makes updates easier on specific portions of the specification.
>
> This makes the whole of the WebCrypto unnecessarily hard to understand.
> And adding algorithms and algorithm parameters should not require updating
> specs – just writing new ones.
>
>
>
> -          Scenario 1 : We update the entire specification each time we
> have a new algorithm (bug requiring extensibility mechanism is WONTFIX)
>
> This would make WebCrypto as hard to update as specs like XMLDSIG and
> XMLENC.  The W3C’s negative experience in this regard should clearly steer
> us away from this path.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
> *Sent:* Tuesday, September 02, 2014 2:16 PM
> *To:* public-webcrypto@w3.org
> *Cc:* Harry Halpin; Wendy Seltzer
> *Subject:* [W3C Web Crypto WG] about extensions to Web Crypto
> specification
>
>
>
> Hi all,
>
>
>
> Thanks Mark for trying hard to make progress on that discussion. Lets
> measure motivation for the different scenario you mentioned for updating
> the web crypto API when a new algorithm needs to be added.
>
>
>
> -          Scenario 1 : We update the entire specification each time we
> have a new algorithm (bug requiring extensibility mechanism is WONTFIX)
>
> -          Scenario 2 : We work harder on the extension mechanism.
>
> -          Scenario 3 : We fragment the specification into several
> specifications, by algorithm family. This scenario looks like scenario 1,
> but makes updates easier on specific portions of the specification.
>
>
>
> Please state your preference order among those scenario from 1 to 3 (1:
> your preferred scenario, 2 : the medium attractive one, 3 : the one
> gathering lower support from you, but you could live with it).
>
> Please state scenario you object to.
>
>
>
> Note that we target to exit Last Call for Web Crytpo API mid-sept. As
> such, I would appreciate that constructive discussions happens here, as
> this bug is the last one preventing us from reaching that goal.
>
>
>
> Regards,
>
> Virginie Galindo
>
> chair of web crypto wg
>
>
>
>
>
>
>
>
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com <watsonm@netflix.com>]
> *Sent:* jeudi 28 août 2014 23:37
> *To:* Ryan Sleevi
> *Cc:* Mike Jones; GALINDO Virginie; public-webcrypto@w3.org
> *Subject:* Re: [W3C Web Crypto WG] about extensions to Web Crypto
> specification
>
>
>
>
>
> Sent from my iPhone
>
>
> On Aug 28, 2014, at 2:23 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
>
>
>
> On Thu, Aug 28, 2014 at 2:21 PM, Mike Jones <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.
>
>
>
> Actually, what Mike said is an *example* of an extension mechanism,
> whereas option 3 doesn't imply a specific extension mechanism: that option
> was intended to cover all paths where we embed more extensibility into the
> base spec than we have today.
>
>
>
> Ryan - I hope your comment above applies to Mike's suggestion specifically
> and not to extension mechanisms generally.
>
>
>
> Anyway, despite the long discussions, it's not clear to me why Mike's
> proposal doesn't work. Developers really just need to know where they
> should expect changes / additions to appear in future so they can design
> code that is future-proof, to some extent. But we all know that trying to
> hard to be future-proof is a fools errand since none of us are too good at
> predicting the future.
>
>
>
> ...Mark
>
>
>
>
>
>
>
>
>
> 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]
> *Sent:* Thursday, August 28, 2014 12:53 PM
> *To:* Mike Jones
> *Cc:* GALINDO Virginie; Ryan Sleevi; 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>
> 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 <watsonm@netflix.com>
> *Sent: *‎8/‎28/‎2014 12:28 PM
> *To: *GALINDO Virginie <Virginie.Galindo@gemalto.com>
> *Cc: *Mike Jones <Michael.Jones@microsoft.com>; Ryan Sleevi
> <sleevi@google.com>; 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> 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>
> 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.*
>
>
>
>
>
>
>
>  ------------------------------
>
>
>
> *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.*
>