W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 23 Aug 2012 17:43:48 -0700
Message-ID: <CACvaWvbyoLSYQjcS2yt9i2_++GEv2cH2QuJSGo+rgBrhKghYUQ@mail.gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Cc: David Dahl <ddahl@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
On Thu, Aug 23, 2012 at 5:38 PM, Wan-Teh Chang <wtc@google.com> wrote:
> window.crypto.getRandomValues is the other operation that does not
> require a key. In addition to the digest operation, getRandomValues
> should also be considered when we resolve this issue.
> Wan-Teh

Good point. Perhaps it's worth doing the interface split then.

It was pointed out to me by a colleague that a CSP such as 'self' may
be too prohibitive, in that it actively restricts the inclusion of
script or objects from other domains, and suggested simply the
1) Require SSL
2) Require that 'unsafe-eval' NOT be present
3) Require that 'unsafe-inline' NOT be present

That's also reasonable approach, but it does increase the attack
surface of the API.

A possible refinement of the above proposal would be to allow, during
key generation, whether the key was to be extended beyond 'self'. That
is, restated:
#4) If a key was generated in 'self' mode (for lack of a better word),
it would only be available on window.crypto.keys when the CSP also
indicated 'self'.

The default mode for keys would be 'permissive' (eg: only require
items #1 - #3), but optionally during generation/provisioning/import,
#4 could be specified.
Received on Friday, 24 August 2012 00:44:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC