W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2014

[Bug 25985] WebCrypto should be inter-operable

From: <bugzilla@jessica.w3.org>
Date: Mon, 07 Jul 2014 09:46:10 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25985-7213-DxDpBDcY9t@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

--- Comment #33 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Ryan Sleevi from comment #30)
> (In reply to Henri Sivonen from comment #28)
> > Which major browsers defer to libraries that are not shipped by the same
> > entity that ships the browser?
> 
> This is not the correct question to ask.
>
> CNG is only updated on major Windows releases. IE is on a separate timeframe.
> Common Crypto is only updated on major OS X releases. Safari is on a
> separate timeframe.
> Firefox intentionally supports OS-distributed NSS. In fact, it is the most
> common distribution of Firefox on Linux platforms that Mozilla has no direct
> control over the version of NSS used.
> Similarly, Chrome on Linux makes the same deferral. On other platforms, it
> uses a mix of cryptographic capabilities provided by the OS or by
> third-party libraries.

So the propagation time of changes to the systems libraries is longer. It
doesn't follow that Microsoft couldn't make changes to their platform crypto to
accommodate IE's Web Crypto impl, Apple couldn't make changes to their platform
crypto to accommodate Safari or Red Hat couldn't make changes to NSS to
accommodate Firefox--eventually.

My comments are about converging on interop eventually--not about exiting CR
next week.

> > I believe it happens. I just think it is sufficiently unreasonable that it's
> > not good for the spec to treat it as a legitimate conforming thing and from
> > the spec perspective it would make more sense to treat it like a user
> > self-sabotaging other features of their self-compiled copy of an Open Source
> > browser.
> 
> This is an unreasonably hostile path to take to users, and on an extreme
> that is not accurate. Show me an industry regulation that says things like
> "Thou shalt not access the camera", compared to the many industry and
> governmental regulations that say "Thou shalt not use SHA-1" (for example).

So if you are banned from using a particular crypto primitive, don't invoke it
in your intranet app. It's not reasonable to withdraw it from the browsers you
have installed thereby breaking random external sites.

> > Right. My point is that the dynamics of Web compatibility are such that if
> > an algorithm is shown weak in the future, you won't be able to make Web apps
> > secure by withdrawing the algorithm from the API underneath those apps.
> 
> Correct.
> 
> And that WebCrypto, in present form, allows implementations to do this, is a
> FEATURE, not a bug.

Wait, you think it's a FEATURE to *allow* something that you think is correctly
characterized as "won't be able to"???

> > For the rest of the Web that doesn't seek deliberate incompatibility, there
> > is value in having a clear definition of what the compatible feature set for
> > vanilla browsers is.
> 
> Again, you have seemingly missed the point, or at least placed conflicting
> statements.
> 
> Your position, simply stated, appears to be that if I want to disable SHA-1,
> as a user, my only recourse is to disable all of WebCrypto, because it no
> longer fits the mandatory to implement algorithms.

No. What makes you think that a user who want to remove features from their Web
browser--be it crypto primitives or anything else--needs anyone to bless the
resulting personal feature set as conforming? We don't need a spec to consider
it conforming for a user to delete a block of code from the HTML parser and
recompile their personal browser instance.

I don't care about whether users can call their browser compliant if they
disable some features either by flipping pref or by changing code and
recompiling. I'm interested in documenting an eventually consistent target
state across the feature set offered by major browsers in their default
configurations. For browsers that suffer some non-agility from deferring to
platform libraries, "eventually" may take a bit more time than the WG has
planned for their CR schedule.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 7 July 2014 09:46:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:23 UTC