[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

--- Comment #48 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #47)
> (In reply to Harry Halpin from comment #45)
> > Extension spec S2 would normatively reference S1. Why would it make sense to
> > have S1 reference S2? 
> > 
> 
> This was answered two lines below in the message you were replying to.
> 
> > > 
> > > If you were talking about versions of implementations, I have no idea what
> > > you were trying to say.
> > > 
> > > > No one is "pretending" S2 doesn't exist.
> > > 
> > > Please put yourselves in the shoes of an implementor who is told to
> > > "implement S1".  They find the S1 spec and implement.  How do they find out
> > > about S2?
> > 
> > Like I said, the W3C has offered to host either a web-page or wiki, which
> > can be pointed at from S1, for these. That's pretty simple and solves your
> > problem. 
> 
> It doesn't solve the problem for a second.
> 
> One, the issue at hand is "Implement S1", except the Web now depends on
> "S1+S2" because some Vendor C implemented S2 and decided to ship it, and
> sites and authors came to believe that S1 (the Web Crypto API, in this case)
> also guarantees support for S2, because for some vendors, it does.

You are assuming "entire Web" depends on S2. It is more realistic certain
classes of applications and countries depend on S2.

First of all, can you please clarify if this position is *your personal
position* or an agreed-upon internal Google position?

Microsoft has made their agreed-upon position clear, and W3C would appreciate
the same from Google. 

> 
> So now you have two problems:
> 1) How do authors realize that S1 and S2 are disjoint (answer: And this is
> true for nearly every implementor - is that they don't, no matter how much
> we try to spin it)

There are separate specs.

Again, cryptographic applications are not adding new shiny graphics to CSS that
we expect everyone to implement.

Particular implementers are not idiots, particularly if they are using a
library that is called "SubtleCrypto". 

> 2) How do implementors realize that sites are expecting S2 when they ask for
> S1 (answer: Again, plenty of experience here is that they don't, until well
> after the fact)
> 
> The question of "Put it in S1" vs "Put it in a wiki that is put in S1" is
> silly. It highlights the exact process issues being discussed in
> http://www.w3.org/community/w3process/track/issues/141

No, it's not silly. It's a perfectly fine solution. I think not supporting
Curve25519 or other specific crypto and then asking the rest of the world and
other browser vendors not to specify it is not exactly a good idea.

Furthermore, you have changed your mind on this *several* times on this. Now,
you are basically arguing *all algorithms* should be normative.

Can you explain why?

> 
> > Agreed. We wanted extension specs to be discoverable. Ryan pushed against it
> > for reasons which he has not clarified. 
> 
> No, that's not really true. I've provided quite clear reasons why
> non-discoverable extension specs are a problem. I've also provided quite
> clear reasons why "random extension specs" are a problem, especially for the
> Web Platform (i.e.. the 'IETF and JOSE developed extension specs')

Again, see above question. You can't have it both ways. Either you declare all
algorithms are normative and MUST be implemented or you allow extension specs.
Otherwise none of the examples you discuss hold.

> 
> > Why would sites assume S2 is implemented if it's clearly an extension?
> 
> Because that's exactly how the web and authors work? We're being pragmatic,
> rather than dogmatic, in that the process here continually leads to failure.
> 
> > > As in, if S2 is in fact a required consequence of having S1, then by not
> > > making that clear you set up people implementing S1 to fail.
> > 
> > However, using Curve25519 and NUMs curves as examples, we are *not* saying
> > they are required.
> 
> And yet, when a critical mass of UAs implement Curve25519 or NUMS, then
> _regardless_ of what the spec says, it is in fact required for a UA that
> wishes to expose the web.
> 
> This is what we've seen time and time again w/r/t HTML, which is why we have
> the WHATWG documenting the way the world _is_, not the way the W3C imagined
> the world should look like. Because ultimately, the world we live in is the
> messy one where sites depend on these algorithms, and so any new UA, or any
> UA freshly implementing S1, needs to know that S2, despite being
> "extension", is in effect "required" (the same as the majority of S1 is
> already)

Hey, I'm not the one blocking Curve 25519, which developers do want, I believe
you are. We are trying to have some agility so as crypto changes and developers
need, we can let them have it.  I think that's dealing with the messy world
actually. 

> 
> > Given there is a vastly decreasing amount of browsers, I don't think this is
> > a huge problem. Indeed, the problem is that some jurisdictions and
> > applicaitons *require* crypto that for, some reason or another, some browser
> > vendor won't implement but another will. To discpline this, an extension
> > spec mechanism makes sense. 
> > 
> > Also, note the point made by Mark that at least his company is interested in
> > using this API in JS programs that aren't browsers. 
> 
> Which just amplifies the problem that either the W3C and Web Crypto WG are
> either set up to serve UAs for the web, or they aren't. If you're trying to
> be ecumenical for NodeJS, WinJS, <insert some language here that doesn't
> even use ES but uses WebIDL for reasons yet unknown>, then all you're doing
> is forcing UAs to go off on their own to focus on the things that matter.
> 
> This is how and why we got the WHATWG, and why it increasingly may be a
> better place for future development. UAs cannot effectively discuss what
> matters or is idiomatic for NodeJS or WinJS, nor, as has been repeatedly
> shown in this WG, can vendors of non-UAs be expected to effectively discuss
> what matters or is idiomatic for the Web.
> 
> > Yes, because the patent commits go to the spec and adding algorithms to the
> > base spec would cause us to go back to Last Call.
> 
> That's not a BUG. It's a FEATURE.

Not if the editors are not fixing bugs in the time scale needed to push the
spec out to developers with test-suites. 

> 
> > No, we are not prioritizing the comfort of the working group. Certain
> > groups, like *entire countries*, need crypto that is not included in the
> > base spec for some reason or another. 
> 
> Put differently: You believe that the legislative fiat of independent
> countries should trump implementor or developer concerns.

No, I believe the needs of developers and users overrun the comfort of browser
vendors and the W3C. It's interesting that you call the concern for non-NIST
curves "boutique crypto". I think a lot of people would disagree.

> 
> Either the boutique crypto needs of these *entire countries* are of concerns
> for implementors - in which case, it's an implementation issue - or they
> aren't, in which case, discussions of them are in effect placing a higher
> priority on legislation than implementation.
> 
> That's not a good path.
> 
> > 
> > As a global standards body we can't ignore whole countries. I rank ordinary
> > people above both the comfort of standards bodies and implementers to be
> > honest. 
> > 
> > We will clearly define a browser profile that every developer can depend on. 
> > 
> > However, we do understand some browsers don't have the resources or desire
> > to implement certain crypto (like Curve25519 or NUMS or SEED or GOST) that
> > certain people (and again, whole countries) need. As long as specs for these
> > are written and code works in at least one browser, I think extension specs
> > are a good idea for tackling this issue without putting any additional
> > weight on browser vendors. If the browser vendors decide later to implement
> > extension specs, then we can update accordingly but no reason to hold up
> > other browser vendors and the rest of W3C now.
> 
> This ignores how the Web has worked, currently works, and, from
> implementors, how they desire it to work.
> 
> For the W3C to ignore these concerns or reality seems... less than ideal.

Ditto for any individual person. For implementors to ignore the needs of users
isn't great either. 

That's why W3C have a consensus-based process and clear governance.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 10 October 2014 15:29:13 UTC