W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2012

Re: ECC vs RSA, and Similar Conflicts

From: Richard L. Barnes <rbarnes@bbn.com>
Date: Thu, 10 May 2012 11:08:34 -0400
Cc: David Dahl <ddahl@mozilla.com>, Nadim <nadim@nadim.cc>, public-webcrypto@w3.org, Cullen Jennings <fluffy@cisco.com>
Message-Id: <5929EE50-6856-4114-BCC0-A5BBAB384E5B@bbn.com>
To: Eric Rescorla <ekr@rtfm.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.

Received on Thursday, 10 May 2012 15:09:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC