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

I'm not convinced of the value of requiring CSP in the first place. This is not a statement for or against CSP by itself; I just don't know what tying WebCrypto to it buys us.

It is not the mission of this WG to single-handedly make all browser JS safe. An app with a security hole is broken with or without WebCrypto, and CSP itself is a defense-in-depth measure. We also have use cases (non-browser JS has been brought up) where CSP may not be necessary at all. Finally, I'm leery of going down the slippery slope of specifying policy and not just mechanisms in the API.

Why not just recommend use of CSP in Security Considerations and leave it at that?

-----Original Message-----
From: Ryan Sleevi [] 
Sent: Thursday, August 23, 2012 5:44 PM
To: Wan-Teh Chang
Cc: David Dahl; Web Cryptography Working Group
Subject: Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

On Thu, Aug 23, 2012 at 5:38 PM, Wan-Teh Chang <> 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 following
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 Monday, 27 August 2012 10:01:29 UTC