Chromium/Chrome planning to ship unprefixed WebCrypto

Speaking on behalf of the Chromium team, we wanted to notify the WebCrypto
WG of our plans to ship, unprefixed, a version of WebCrypto as part of the
"M37" timeframe - e.g. what will become part of Chrome 37.

This has already been enabled on our latest Canary versions, and will
follow the flow of landing in versions of Chrome Dev channel, then Beta
channel, and eventually, when Chrome 37 reaches Stable, enabled for all
users.

The details of our implementation are available in this document -
https://docs.google.com/a/chromium.org/document/d/184AgXzLAoUjQjrtNdbimceyXVYzrn3tGpf3xQGCN10g/edit

As noted in that document, we have tried to be compliant with the draft the
WG sent to WGLC, on the basis of the signals provided by the WG on the
stability and maturity of the specification.

There are several known, and intentional, differences, as noted on that
document. Some of these issues were identified prior to the WGLC, and
agreed upon in principle by the WG when it decided not to postpone LC to
address these. Some of these are arguably minor and implicit in the WGLC
version (eg: digest()/exportKey() returning errors), but are now explicitly
spelled out.

Notable, however, is that Chrome and Chromium will only allow access to
WebCrypto if the origin is recognized as a secure transport. Within
WebCrypto, this is tracked as
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 .

The definition Chrom{e/ium} has taken for Secure Origin is, admittedly,
more restrictive than may be desired at this time. However, we've deemed it
more important to fail securely, rather than to allow this API in
unquestionably insecure usages. We hope to refine and improve this over
time, granting greater access to the API.

Going forward, we would like to continue implementing additional algorithms
- particularly for EC and KDFs. However, this would require strong signals
from the WG about the stability and maturity of these algorithm
definitions. As it stands, ECC such as ECDSA and ECDH lacks these signals -
as evidenced by bugs such as 26080, 25839, and 25618.

Speaking as editor, my plan is to continue resolving as many
algorithm-specific concerns as possible, so that the WG may reach consensus
and agree upon the definitions of as many algorithms as possible. There are
still several editorial-style cleanups to be done, admittedly, but many of
these will not result in user-visible effects except in rare and unlikely
events, and have behaviours that have been discussed on the WG before, so
are unlikely to result in different implementations.

If there are any concerns - with this editorial approach/prioritization or
with the Chromium/Blink team's plans - we would love to hear and address
them as quickly as possible.