- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 23 Aug 2012 17:43:48 -0700
- 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 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, 24 August 2012 00:44:15 UTC