[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #36 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Henri Sivonen from comment #35)
> I expect Web Crypto be implemented piecewise.

Considering CSS doesn't have varying export controls, that's not surprising.

This is very similar to the WebGL EXT_ sets - except in addition to the IPR
concerns, the on-chip concerns, the question about whether an EXT_ can be
sufficiently emulated to drop the EXT_, the OS level concerns, there's also the
export concerns.

Finally, there's clearly a diverse set of people interested in this - from the
"Node.JS/Win.JS" folks looking for server-side operation, from the "exposed to
websites" group, to the "exposed to sysapps", to the "usable in devices that
use web technologies" (e.g. set top boxes), there's a vast and varying set of
requirements here, even beyond that of CSS.

> 
> > What's the expected behaviour, for a UA, if a user chooses to disable an
> > algorithm (by policy)?
> > Does it
> >   a) Allow all of WebCrypto, mod the disabled algorithm
> >   b) Disable all of WebCrypto, because it fails to meet the profile?
> >   c) Other?
> 
> Preferably c): Making it hard to to mess with the feature set so that only
> those who *really* have to do so. But when they do, a).

Specs don't get to decide how hard we make something. Nor should they. But I
agree, a) is the only 'sane' approach.

> > - What should the behaviour of the site operator's script be when it
> > attempts to use SHA-1?
> 
> The same as requesting an unknown algorithm.

Agreed.

> 
> > - What should "well-behaved" application developers do to handle this?
> >   a) Not handle it at all. Watch it burn!
> >   b) Handle it, with fallback to JS crypto
> >   c) Other?
> 
> b) is likely in the short term with a) likely becoming more prevalent over
> time (based on what we know about how Web developers behave as features
> become more consistently available across browsers).
> 
> I imagine once in a while someone will do c): Show a UI message to tell the
> user go download a browser that supports Web Crypto.

Yup.

> > - If you answered (b) [which, evidence suggests, is invariably what people
> > will do], how is that different than the present state of things?
> 
> There's a difference between
> 
>  1) establishing a feature set that implementors agree is a worthwhile
> target to converge their default configurations to over time
> 
> and
> 
>  2) not even setting the expectation for browsers converging on a common
> interoperable feature set available by default (either resulting in a mess
> or resulting in expectation setting happening outside the WG/spec).

Considering that the converging set of expectations vary based on device
profiles/platforms/use cases (Node vs Set-Top Box vs 'traditional'
desktop/mobile UA, which themselves vary by desktop and mobile), I absolutely
think it's something that will have different use cases and profiles.

Let me emphatically state that "conformance" lacks a strong definition in the
context of cryptographic operations. It is essential to treat them "as if" they
were hardware capabilities. These capabilities MAY be emulated in software, but
that is dependent on a variety of externalities.

Consider RSA-OAEP as an example. Chromium wants to use the cryptographic
capabilities of Linux (the NSS library), except different distros ship
different versions of NSS with different capabilities.

What does "conformance" mean, for the Chromium developers?
- Does "conformance" simply meaning making the calls to the underlying library,
in the hope that they'll succeed?
- Does "conformance" mean that Chromium should try to implement RSA-OAEP
itself, independent of the cryptographic libraries?
  - Is a distinction made between the library being an older version, which may
not support RSA-OAEP, and the library being newer, but having RSA-OAEP
explicitly disabled by the user (through means outside of Chromium's control?)
- What about for algorithms for which there are no PKCS#11 mechanism points
assigned yet, like Curve25519 or the NUMS curves?
  - Does conformance mean implementing in software, ala
WebGL-software-rendering?

What does it mean for the web developer, who wishes to use Curve25519 or the
NUMS curves or RSA-OAEP? What if it's available on every other platform but
Chromium for Linux, and only under certain situations, does this change the
answer?

The choice of no-MTI is a choice that reflects the reality that there are
untold numbers of ways and reasons for which a given algorithm can be
unavailable. The ideal, aspirational world is that every UA is able to
implement every algorithm, on every platform, and for every key size, parameter
size, etc. But the real world is that will never be possible, and developers
have to design their code around that.

Some of this can be handled gracefully by the author - after all, there may be
a choice of algorithms that they can use. They can negotiate a-priori on the
cryptographic construction (as most protocols do anyways, for cryptographic
agility). It does not imply a lack of utility for the API.

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

Received on Wednesday, 9 July 2014 23:44:54 UTC