- From: David McGrew <mcgrew@cisco.com>
- Date: Tue, 29 May 2012 16:55:01 -0400
- To: "Richard L. Barnes" <rbarnes@bbn.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, Anil Saldhana <Anil.Saldhana@redhat.com>, public-webcrypto@w3.org
Hi Richard, On May 25, 2012, at 3:39 PM, Richard L. Barnes wrote: > How about this as a compromise: Split the API into two halves, safe and unsafe. The safe methods preserve key isolation, have been reviewed by Dan, etc. The unsafe methods might leak key material. > I think this dichotomy makes sense. It seems technically feasible, and as a direction it allows the development of both safe and unsafe APIs in parallel. Disclaimer: I am not an expert in API security. It would be good to hear from someone who has been analyzing PKCS#11. David > You can imagine a couple of ways this could be useful... > -- Browsers through big red flags when an app tries to use unsafe stuff (especially if JS arrived over HTTP) > -- Web sites could publish over HTTPS a manifest of whether they intend to be safe/unsafe > -- Code/security reviews could focus on unsafe sections of the API > > At the very least, if we enforce the discipline of marking methods as safe or not, then it allows us to move ahead with the API, optionally kicking out the unsafe methods later. > > --Richard > > > > > On May 22, 2012, at 11:54 AM, Eric Rescorla wrote: > >> On Tue, May 22, 2012 at 2:23 AM, David McGrew <mcgrew@cisco.com> wrote: >>> On May 10, 2012, at 10:36 AM, Anil Saldhana wrote: >>> >>>> Giving direct access to private keys to the JS api is trouble. >>>> >>>> I support David's thoughts on just allowing references to IDs of Private Keys. >>> >>> +1 >>> >>> It will also be important that the API itself not allow manipulations of the secret and private keys that allow an attacker to cause one of those keys to be revealed by executing a (possibly convoluted) sequence of operations on it, as has been shown to be the case for PKCS#11 (see for instance <http://www.lsv.ens-cachan.fr/~steel/pkcs11/>) >> >> David, >> >> I think this is actually an argument *against* key isolation. >> >> As soon as protecting the keys becomes a system invariant, then the >> introduction of any new API call requires extensive cryptographic >> review. As I've been putting it lately, "every time you want to add >> a new API point, you need to call Dan Boneh". >> >> This isn't to say that there is no use for key isolation, but that making it >> a security guarantee of the system is quite expensive in terms of >> design cost. >> >> -Ekr >> >
Received on Tuesday, 29 May 2012 21:06:58 UTC