Intent to ship Web Crypto
ero...@chromium.org
Spec
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/
Summary
- Adds crypto.subtle, which contains methods for generating keys, importing keys, unwrapping keys, wrapping keys, encrypting, decrypting, signing, verifying, and digest
- Exposes the pre-existing crypto.getRandomValues() to Web Workers
- This API will only be exposed to secure origins, as security-sensitive operations are inherently dangerous when performed on insecure connections.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
However the specific algorithms supported on each platform varies. In particular on Linux, version 3.16.2 of NSS is required, and on Android fewer algorithms are currently implemented.
Support for additional algorithms, on all platforms, will be added in future releases.
Compatibility Risk
The WebCrypto API does not mandate any particular algorithms. It is possible for different user agents to support different ones, leading to incompatibilities between consumers of the API.
Another consideration is that support for algorithms may be deprecated once they are deemed insecure. Hence strict compatibility between past and new versions of Blink cannot be guaranteed.
OWP launch tracking bug?
Link to entry on the feature dashboard
Alex Russell
Spec
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/
Summary
- Adds crypto.subtle, which contains methods for generating keys, importing keys, unwrapping keys, wrapping keys, encrypting, decrypting, signing, verifying, and digest
- Exposes the pre-existing crypto.getRandomValues() to Web Workers
- This API will only be exposed to secure origins, as security-sensitive operations are inherently dangerous when performed on insecure connections.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
However the specific algorithms supported on each platform varies. In particular on Linux, version 3.16.2 of NSS is required, and on Android fewer algorithms are currently implemented.
Support for additional algorithms, on all platforms, will be added in future releases.
Compatibility Risk
The WebCrypto API does not mandate any particular algorithms. It is possible for different user agents to support different ones, leading to incompatibilities between consumers of the API.
Another consideration is that support for algorithms may be deprecated once they are deemed insecure. Hence strict compatibility between past and new versions of Blink cannot be guaranteed.
OWP launch tracking bug?
Link to entry on the feature dashboard
http://www.chromestatus.com/features/5030265697075200
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Eric Roman
On Tue, Jun 3, 2014 at 4:21 PM, <ero...@chromium.org> wrote:
Spec
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/
Summary
- Adds crypto.subtle, which contains methods for generating keys, importing keys, unwrapping keys, wrapping keys, encrypting, decrypting, signing, verifying, and digest
- Exposes the pre-existing crypto.getRandomValues() to Web Workers
- This API will only be exposed to secure origins, as security-sensitive operations are inherently dangerous when performed on insecure connections.
Presumably, as with Service Workers, the restriction to Secure Origins will simply cause APIs to fail, not to be selectively available depending on origin type?
Anne van Kesteren
> crypto.subtle would be visible from all origins, however all its methods
> will fail [1]
> More details on the proposed change: in
> https://codereview.chromium.org/299253003/
--
http://annevankesteren.nl/
Ryan Sleevi
Can you clarify what you would expect? Something similar to Service Workers' language?
The spec already permits user agents the flexibility in how algorithms are exposed, as Eric has noted. This is inherently necessary for legal and political reasons (crypto is still classified/controlled similarly to munitions, 15 years after the great crypto wars)
Within Chrome, the API is exposed, but on insecure origins, no algorithms are implemented.
Anne van Kesteren
> Can you clarify what you would expect? Something similar to Service Workers'
> language?
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#entry-settings-object
's origin is not an
https://w3c.github.io/webappsec/specs/mixedcontent/#assumed-secure-origin
(or whatever definition is actually used here), reject p with a
TypeError."
If the APIs are exposed at all, it seems like that can be a normative
requirement and probably should be.
--
http://annevankesteren.nl/
Ryan Sleevi
There is, unfortunately, not consensus within the WG for such language being a normative requirement of the spec, despite the clear impossibility of building a trusted system on an untrusted connection, without an a-priori or out of bands means of building trust.
This is, in part, reflected by the desire of some WG members to use these APIs within consumer devices (eg: smart TVs), for which TLS is seen as unreasonably expensive or complex, and similarly, including or exposing hardware identifiers ( http://www.w3.org/TR/webcrypto-key-discovery/ ) is viewed as a valid way to bootstrap an 'acceptable' level of trust.
In this regard, there has been a rather long-standing spirited debate within the WG on what represents an acceptable minimal security guarantee, and whether applications can achieve that with no reliance on TLS. Unfortunately, the lowest common denominator currently prevails.
While the WGLC has completed, enough feedback has been received to warrant a new edition that contains substantive API changes - many already identified before WGLC was entered. As such, support for a normative requirement for TLS would still, no doubt, be very welcome within the WG.
Anne van Kesteren
> While the WGLC has completed, enough feedback has been received to warrant a
> new edition that contains substantive API changes - many already identified
> before WGLC was entered. As such, support for a normative requirement for
> TLS would still, no doubt, be very welcome within the WG.
--
http://annevankesteren.nl/
Alex Russell
Eric Roman
Adam Barth
Ping.Yay or nay on shipping Web Crypto?
While the WGLC has completed, enough feedback has been received to warrant a new edition that contains substantive API changes - many already identified before WGLC was entered.
Ryan Sleevi
Adam Barth
On Tue, Jun 10, 2014 at 2:31 PM, Adam Barth <aba...@google.com> wrote:
On Tue Jun 10 2014 at 2:21:41 PM, Eric Roman <ero...@chromium.org> wrote:Ping.Yay or nay on shipping Web Crypto?I have one concern about the issue below:On Wed Jun 04 2014 at 12:50:16 AM, Ryan Sleevi <rsl...@chromium.org> wrote:While the WGLC has completed, enough feedback has been received to warrant a new edition that contains substantive API changes - many already identified before WGLC was entered.
Are these changes likely to break the API? I'm concerned that the spec might change after we ship the feature.
There is one API breaking change that the WG agreed on, and had outstanding, before pushing to WGLC; This was unfortunate, but governs how import/export of JSON Web Keys is handled.This is in the process of being resolved (in spec and in Chrome's implementation).There is one other public-API-relevant change outstanding (exposing the length of HMAC keys); however, that can be determined for existing keys, and thus doesn't change.The remainder of the changes focused on elements that were critically under-specified, but which implementors had consistently implemented the same thing in existing implementations.Then again, no other UA is shipping something spec-compatible at the moment, simply prefixed.
Alex Russell
Ryan Sleevi
API surface? Confident of no further changes.
There is still ongoing discussion about MTI algorithms and key sizes. The spec requires none at present. There is also requests for addition algorithms or supported parameters, but those too are uneventful.
Adam Barth
TAMURA, Kent
TAMURA Kent
Software Engineer, Google
