- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Jul 2014 11:37:20 +0000
- To: public-webcrypto@w3.org
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