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

On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj
<> wrote:
> 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.

Trying not to repeat the mistakes of the past two decades, when
defining a new API, I think we should make use of the knowledge,
experience, and risks learned in the past.

That is to say, sure, it's not essential to tie it to CSP, but then
you'll leave it in the realm of implementations to do so (which I
think we're likely to do for general usage, but practically assured
for any non-browser-maintained key storage)

> 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.

Sure. But if a new JS API has a host of new security considerations -
and certainly, this does, with the frequent talk about pre-provisioned
or out-of-band keys - then I think it's reasonable to have that API
require stronger security guarantees than the existing ('broken')
guarantees today.

As it relates to non-browser-JS, our charter is within the W3C, and
we're scoped to Browser objects. To the extent non-browser-JS can use
the same bindings is fine, but I think it's inevitable that they will
have to adjust the spec to their non-browser needs. This is no
different than how existing non-browser JS bindings handle existing
W3C specs, so I don't think it's a statement one way or the other.

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

Previously, the addition of key taining to the Security Considerations
was objected to, because it leaves some behaviours implementation
dependent if it's not mandated. As such, it was moved to the Editor's
Note for the time being. Moving CSP to the SC seems to be a prelude to
the same discussion, with the end result is that no reference to CSP
appears in the final document or it is required.

Currently, no normative text requiring CSP appears - but I think
adding it is the right step.

> -----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 Friday, 31 August 2012 19:26:50 UTC