W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

From: David Dahl <ddahl@mozilla.com>
Date: Thu, 9 Jun 2011 14:17:39 -0700 (PDT)
To: Nico Williams <nico@cryptonector.com>
Cc: public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>
Message-ID: <1165568190.163425.1307654259801.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
----- Original Message -----
> From: "Nico Williams" <nico@cryptonector.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-web-security@w3.org, "Jarred Nicholls" <jarred@sencha.com>
> Sent: Thursday, June 9, 2011 2:56:31 PM
> Subject: Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal
> On Thu, Jun 9, 2011 at 1:40 PM, David Dahl <ddahl@mozilla.com> wrote:
> >> Performing keyed cryptographic operations (as opposed to hash
> >> functions) requires keys. Whence the keys? And what are their
> >> semantics? This is where trust comes in.
> >
> > Right. The concept that has evolved is where the origin generates
> > the keys and only that origin can access that key pair. For
> > symmetric keys, we will need some kind of index of wrapped keys, and
> > the application only needs to know the key's ID to use it - as well
> > as - perhaps - the enduser being able to unwrap the key.
> >
> > I think the API gives application developers a couple of methods for
> > helping deal with symmetric key use (and distribution via various
> > application methods that are dreamed up).
> So you presume a client-side (browser or platform) softtoken or
> smartcard?
> How are the keys to be distributed or exchanged?
What I mean is that there is a way for web application developers to dream up mechanisms for key exchange, perhaps by wrapping symmetric keys that another party needs with a public key or something like that. This API has no designs on key exchange whatsoever, that is another spec and conversation entirely. I removed the "addressbook" API methods and concept because I was biting off too much in one spec.

> > There is a really great use-case here: the server operator does not
> > want to hang on to any plaintext data the user is entering into the
> > application. This is huge from the standpoint of data breaches.
> On which side? If on the server-side, how does JS crypto help? Or
> did you mean that the server stores ciphertext for which it knows no
> keys? I could see this being useful for dealing with user profiles
> that store credit card numbers, but which require the client to
> decrypt such information with client-side keys.
> Alright, you've found a use for JS crypto for which I can get
> on-board. Although key management is a problem (e.g., if derived from
> a password then an attacker could mount offline dictionary attacks
> after acquiring a copy of the ciphertext).
> (Or did you mean on the client-side?)
The client does all crypto operations and the server is only given cipher text to store - and, yes, key management is still a problem, which I know is a huge problem that will have a solution at some point. I think starting small and focused is a good way to get things rolling. This API is useful enough as is, and a key management and exchange API will be designed to complement this.


Received on Thursday, 9 June 2011 21:18:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:26 UTC