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

[Bug 25985] WebCrypto should be inter-operable

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 Jul 2014 11:37:20 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25985-7213-wj12GoZJeJ@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

--- Comment #39 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Ryan Sleevi from comment #36)
> 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.

I think it's fine for Node.js to implement browser APIs, but I think it's a
mistake to let the server side wag the browser-side spec. See: DOM.

I also think it's a mistake to make browser API specs vaguer in order to make
devices with low-quality browsers or browser ports comply. See: Various Mobile
Profiles from the feature phone era.

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

Do you say this in order to make sure that stuff *can* map to hardware
capabilities like AES-NI or do you say this in order to be able to treat crypto
differently policy-wise compared to features that browsers are expected to have
regardless of the underlying hardware?

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

Is this issue going to be moot once Chromium starts using BoringSSL?

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

Isn't this what Chromium is on track to doing once it switches to BoringSSL?

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

I'd say the question of whether Chromium is conforming in that case wouldn't be
of practical importance. From the practical perspective, it matter if stuff
works. If stuff doesn't work, the system+configuration as a whole would be
non-conforming if RSA-OAEP was in the set of algorithms that the WG has deemed
to be part of the Web Platform.

> - What about for algorithms for which there are no PKCS#11 mechanism points
> assigned yet, like Curve25519 or the NUMS curves?

Seems reasonable to implement Curve25519 without any PKCS#11 layer in between
in that case.

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

If the Web developer is implementing something that has NaCl at the other end
of the pipe, then if Curve25519 isn't available, AFAICT, the options are
polyfilling with JS (including asm.js) with the risk to timing side channel
attacks, telling the user to get another browser or changing what's at the
other end of the pipe (if possible).

> What if it's available on every other platform but
> Chromium for Linux, and only under certain situations, does this change the
> answer?

Probably make the "telling the user to get another browser" option the most
likely one.

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

I don't expect a world where every browser implements every algorithm ever
thought up. I expect the WG to maintain documentation of which set of
algorithms browsers are expected to implement either because the algorithms
provide good crypto and should *become* more common or because they are needed
for compatibility with very common legacy at the other end of the pipe. That
target set might expand over time and expansions of the set might not be
implemented immediately, but it's still better than not trying to aim for
convergence of the available features across implementations.

In particular, I'd expect the WG to reject from that set algorithms that are
neither necessary for compatibility nor provide better (yeah, what's "better"
is probably hard to articulate fully) crypto than what's already in the set.
("Our research department came up with these" shouldn't be good enough, in
itself, for inclusion.) As a obvious example, just because there exists a
definition for a BADA55 curve somewhere doesn't mean that such a curve should
be put in the set of algorithms that browsers are supposed to implement. (More
controversially: The most common NIST curves probably need to be in the set due
to compatibility considerations despite the open questions about their
constants, but it doesn't follow that a bunch of other curves whose constants
have similar provenance should be added, too. Instead, other curves added to
the set should probably have better justifiable design choices.)

In practice, though, I'd expect the set of algorithms to be pretty heavily
influenced by what the browsers with the most market share are willing to
implement (in the fashion of comment 37) and not just by abstract discussions
in the WG.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 30 July 2014 11:37:22 UTC

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