[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #30 from Ryan Sleevi <sleevi@google.com> ---
(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.


> Suppose the protocol you implement is OpenPGP. You receive a message signed
> with RSA. If you want to verify the signature, you have to have RSA
> signature verification--either via Web Crypto or via a polyfill. You don't
> get to negotiate an algorithm at that point even though OpenPGP support
> multiple signature algorithms.

Correct. And as an author of such an application, you can make a reasonable and
informed choice about whether a polyfill implementation is appropriate when
receiving messages (for signature verification, it might be; for decryption, it
might not), and you can make informed choices when sending messages.

> As for the point about standards bodies, I think it's not reasonable to
> expect that even the majority of application-specific protocols that could
> potentially use Web Crypto, if Web Crypto ended up being consistent enough a
> basis to write apps on, would be standards body-specified.

That is something we have repeatedly and emphatically, unquestionably,
discouraged within the security considerations and the discussions for the past
two years.

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

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

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

As an implementor, author, and user, that is unacceptable.

If we allow for SHA-1 to be disabled - by user/policy - while still allowing
other algorithms to be enabled (SHA-256, RSA-OAEP with SHA-256, perhaps even
HMAC-SHA1 and only disable SHA-1 for digest), then application developers are
in the exact same position as they are now.

The "all or nothing" approach to WebCrypto, as you seemingly are arguing for
(in the name of interop), makes WebCrypto practically useless.

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

Received on Wednesday, 11 June 2014 09:06:11 UTC