W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2016

Re: Secure context requirement?

From: Eric Roman <ericroman@google.com>
Date: Fri, 22 Apr 2016 12:55:21 -0700
Message-ID: <CAFswn4k0kzoOy6wLjBhmxRbsUtyc81L4+v3+rGWNrFCBuvQ2sA@mail.gmail.com>
To: Charles Engelke <w3c@engelke.com>
Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
tl;dr: Chrome throws a NotSupportedError.

Secure origins were discussed by the WG (largely in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972), however the current
spec does not restrict implementations to secure origins, nor give guidance
to implementations that do.

Other specs, such as Encrypted Media, do make an attempt to describe a
preference for secure origins and how that works. Also more description is
available in the Secure Contexts spec.

As far as I know, Chrome is currently the only browser that restricts
WebCrypto to secure origins. (Haven't tested Microsoft Edge, perhaps it
does too).

In Chrome the particular error used is *NotSupportedError*.

Why NotSupportedError? I don't have a solid standards answer for this, but
here is my thinking:

Comment #3 of bug 25972 models this as an implementation-specific choice,
analogous to a NotSupportedError for an implementation that chooses not to
implement a particular algorithm. This was largely the inspiration for
choosing NotSupportedError. Applications already need to test for
NotSupportedError in case a particular key size or algorithm is not
supported, and in some sense access from a non-secure origin could be
though of similarly.

Looking at other choices for exception: The WebCrypto Exceptions section
(14.4.) lists other candidates: InvalidAccessError, and OperationError. If
we understand that the exceptions listed in section 14.4 are the ONLY
exceptions that an implementation may throw (again I am not super clear
from the phrasing, but that is how I interpreted it), then we are limited
to just this selection of error types.

InvalidAccessError is currently described in terms of a keyed operation so
as described has some issues. And similarly OperationError is more of an
internal error to the algorithm, and also feels like a poor choice.

The Secure Contexts spec (
https://w3c.github.io/webappsec-secure-contexts/#new) mentions rejecting a
promise with a *SecurityError* in section "7.3. Restricting New Features"
-- however this is non-normative. Also based on my understanding of
WebCrypto's Exceptions section 14.4, an implementation is not expected to
throw a SecurityError anyway.

On Fri, Apr 22, 2016 at 11:59 AM, Charles Engelke <w3c@engelke.com> wrote:

> Oops, no, Firefox isn't enforcing the restriction (at least on Linux).
> I don't have a Windows machine close to hand to check Edge, but I
> believe it required a secure context when I tried it last.
> Charlie
> On Fri, Apr 22, 2016 at 2:52 PM, Charles Engelke <w3c@engelke.com> wrote:
> > From what I've seen, both Firefox and Edge enforce the same
> > restriction as Chrome.
> >
> > Charlie
> >
> > On Fri, Apr 22, 2016 at 2:50 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> IIRC, it was never agreed in the Working Group that WebCrypto must be
> >> restricted to secure contexts. Chrome have chosen to do so, but I
> believe
> >> this restriction does not apply in other browsers.
> >>
> >> ...Mark
Received on Friday, 22 April 2016 19:55:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 22 April 2016 19:55:50 UTC