- From: Richard L. Barnes <rbarnes@bbn.com>
- Date: Thu, 10 May 2012 11:08:34 -0400
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: David Dahl <ddahl@mozilla.com>, Nadim <nadim@nadim.cc>, public-webcrypto@w3.org, Cullen Jennings <fluffy@cisco.com>
On May 10, 2012, at 11:00 AM, Eric Rescorla wrote: > On Thu, May 10, 2012 at 7:57 AM, Richard L. Barnes <rbarnes@bbn.com> wrote: >> On May 10, 2012, at 10:44 AM, Eric Rescorla wrote: >> >>> On Thu, May 10, 2012 at 7:30 AM, David Dahl <ddahl@mozilla.com> wrote: >>>> One of the reasons for establishing this WG is to try and provide a more secure way of using crypto on the web. Keeping the private keys private is at the top of this list. We can establish a spec that only ever references private key IDs, making this much more secure than existing JS crypto libraries that have access to private key material. >>> >>> It's not clear to me that this is "much more secure". What's the >>> threat model under which >>> that is the case? >> >> Same as the threat model under which HSMs are more secure than software crypto modules. If the API ensures application-layer code can't see the keys, it's one less thing to validate / worry about. > > And yet nearly all HSMs have some mode for exporting the keys. > > -Ekr > s/exporting the keys/exporting wrapped keys/ Plus, the export operation is often quite involved, involving special hardware, etc. In the web context, it seems like this is an operation that would present special chrome to "formalize" the transfer. In any case, the export operation is clearly separated from normal operations, which again simplifies validation. --Richard
Received on Thursday, 10 May 2012 15:09:14 UTC