- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 1 Jun 2012 10:42:34 -0700
- To: "Richard L. Barnes" <rbarnes@bbn.com>
- Cc: Seetharama Rao Durbha <S.Durbha@cablelabs.com>, "Da Cruz Pinto, Juan M" <juan.m.da.cruz.pinto@intel.com>, David McGrew <mcgrew@cisco.com>, Anil Saldhana <Anil.Saldhana@redhat.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Jun 1, 2012 at 10:39 AM, Richard L. Barnes <rbarnes@bbn.com> wrote: > Assuring the server that the client's key is held in a given module is a really non-trivial problem. If you want to do that, you need to have some form of remote attestation [1]. And for that, you'll need to issue certificates to browser crypto engine instances (or have browsers pass through certs from chips), and have an auditing API so that the crypto engine can prove to the server that it did what the server asked. So it may be technically a solvable problem to assure servers of key provenance, but it's a long, twisty trail to go down. Not one that I think is a primary feature. > > Ideas like PKCS#11 and "safe/unsafe" API calls are still relevant, though, because they provide other flavors of assurance. For instance, if I'm a client, and I run code that only makes safe API calls, then I know that my key hasn't been exported somewhere without my knowledge. Richard, I think we also need a notion of key tagging, i.e., to set keys to be usable only with safe APIs. Otherwise if there is an XSS problem the key could be exported even if the real site only uses safe APIs. -Ekr
Received on Friday, 1 June 2012 17:43:43 UTC