[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #5 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #4)
> > Consider a hypothetical world where we require algorithms X, Y, and Z.
> 
> I understand that this world is not reasonable.
> 
> Can we have a world where we require at least one of X, Y, and Z?  And if we
> can have requirements where if you implement less-secure X you also need to
> implement more-secure Y, that's good too.  I understand how this last may
> not be possible, though, given the various legal issues.

Let's use a concrete example here. X is RSASSA-PKCS1-v1_5. It's popular (still
used for most X.509 certificates, for example), but as noted by INRIA, lacks a
proof, and is a bit long in the tooth. The replacement, RSA-PSS, is recommended
for new systems.

I believe that Microsoft and Apple support RSA-PSS. NSS does and doesn't ("it's
complicated"). Fixable, but this will only apply to users running the latest
NSS - and distros are notoriously slow to update system NSS (because it's a
security-sensitive package)

The same was true for RSA-OAEP support, a secure (barring the implementation
bugs that every open source implementation has seemed to have) means of using
RSA for encryption - which, again, Apple and Microsoft support. When I added
support to NSS, to put it as opaquely as possible, I needed to have a number of
non-technical discussions with decidedly non-engineers, even though the
implementation was relatively straightforward. I would expect that Mozilla
engineers are going to need to have those *exact same* discussions with their
versions of the exact same people, prior to integrating support within Firefox.
These conversations take time and cost money, of the billable hours sort.

And, yet again, it only applies to users with the latest (as of yet unreleased)
version of NSS. This being over a decade since RSAES/RSASSA were "deprecated".

When we started WebCrypto, and began defining algorithms, NSS lacked AES-GCM
support, even though Microsoft and Apple had been shipping for some time. It's
also something that won't be available on certain Linux distributions for ~2-3
years, even though it will be part of NSS.

> 
> > Is it against interoperability if a user agent doesn't implement <img> support? 
> 
> It depends.  HTML defines several different conformance profiles which have
> slightly different requirements on UAs, and also has certain behaviors that
> are in fact optional.  For this particular case, a UA is allowed to not show
> images, but in that case it's required to do certain other things (e.g. show
> the alt text).
> 
> > What about Javascript? Cookies? Location APIs?
> 
> UAs are allowed to let the user do whatever they want, including the user
> explicitly instructing the UA to violate the spec.  That's what makes UAs
> _user_ agents.
> 
> The default UA configuration, however, for the "web browser" HTML
> conformance class, is expected to have JavaScript and cookies enabled.  Also
> location APIs, though whether to expose location information to pages is
> subject to user control, of course.  On the other hand, the "mail reader"
> HTML conformance class is not expected to have JavaScript enabled.

As it relates to cryptographic subsystems, it's hard for a user agent to know
whether an algorithm was disabled by choice or not.

Further, unlike a variety of other things, UAs are generally in a Danger Zone
if they ship polyfills of algorithms. The reality is more complex, and again,
generally involves talking to people who measure time in billable hours.

> 
> But the number of these conformance classes in HTML is finite and small, and
> the general aim is to minimize the number of conformance classes and
> possible different behaviors.

In this respect, Web Crypto is more in the vein of a Device API (in practice)
than a Web API - in that it's very much tied to the system it's running on. You
*can* create it all in software, much like you could do WebGL software
rendering, but unlike WebGL software rendering, you would have to navigate a
vast minefield of related issues that will keep your counsel very happy,
generally speaking.

> 
> > Is it against interoperability if a (generic, desktop) UA that supports the
> > location API executes on a device that does not have access to location
> > information?
> 
> Obviously, yes, since the API won't actually work.  ;)
> 
> Whether such interop problems are _avoidable_ is a different question, of
> course.  Sometimes they're not.
> 
> > Similarly, if a UA restricts access to audio/video access (via
> > getUserMedia()), is it against interoperability?
> 
> The spec for getUserMedia explicitly allows the UA to restrict access based
> on the user's decision here, for obvious reasons.   Yes, this means a page
> might not work as the page author intended if the user decides to not let it.
> 
> In practice, most modern consumer hardware (e.g. most laptops and pretty
> much every single phone and tablet) has a webcam, microphone, location
> support, etc.  And people who try to use such things understand when they
> might be missing and why.  That's a lot less obvious to me with algorithms. 

To extend the metaphor, the cryptographic situation - whether by library or OS
- is akin to being on a platform where the OS can hide the availability of the
microphone/webcam from the UA. The UA has no way of knowing whether it's simply
not there, it's disabled, etc.

In theory, we could (try to?) normatively require that support for algorithms
X, Y, and Z MUST be understood by the UA, even if the underlying cryptographic
library doesn't support them, but that's a bit hard to do.

There's a set of cryptographic libraries that understand algorithm X, but which
may have it disabled. But there's also a set of cryptographic libraries that
simply do not have a way of communicating X - so the UA's parsing of the
algorithm is for naught, because there's no way a user could 'enable' X.

A very real example of this is the PKCS#11 definitions (as used by NSS) for
things like CONCAT, so there's no way to spec that a UA based on NSS MUST
handle it.

In practice, this will apply for all new algorithms.

> Are we expecting most UAs to actually ship overlapping algorithm sets, for
> example, or disjoint ones?

Given by the draft implementation shipping by Microsoft (the pre-promises
msCrypto) and by Apple (which I'm unclear whether it's prefixed or not, but
looks to be prior to much of the change from operation params -> generate
params, AFAICT), and the version in Chrome available behind a flag, I think
we'll see reasonably sizeable overlap.

IE's support -
http://msdn.microsoft.com/en-us/library/ie/dn302338(v=vs.85).aspx
Safari's support is roughly at https://bugs.webkit.org/show_bug.cgi?id=122679 ,
which is a very similar set of algorithms
Chromium's supported algorithms (for M-37, with expansion planned), from the
Intent to Ship (
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Tn3pfJZDcGg/nUlvUOFKL_QJ
) is
https://docs.google.com/a/chromium.org/document/d/184AgXzLAoUjQjrtNdbimceyXVYzrn3tGpf3xQGCN10g/edit
, which is very similar to MSFT.

However, please note the considerations. It's inconsistent between Chromium
platforms, due to dependencies on libraries like the version of NSS or support
within OpenSSL (which is missing a number of algorithms, or has them
implemented insecurely)

This again goes back to the general statement about being a set of Device APIs
(conceptually), even though they're exposed through a common interface.

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

Received on Thursday, 5 June 2014 03:46:05 UTC