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

----- Original Message -----
> From: "Nico Williams" <nico@cryptonector.com>
> To: "Jarred Nicholls" <jarred@sencha.com>
> Cc: public-web-security@w3.org
> Sent: Thursday, June 9, 2011 12:56:16 PM
> Subject: Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal
> On Thu, Jun 9, 2011 at 12:14 PM, Jarred Nicholls <jarred@sencha.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).

> 
> If I don't trust some script, then it should have access to no keys
> other than those it carries, generates, or exchanges. But if I don't
> trust the script, then what is there to be gained from the script
> being able to carry, generate, exchange, and use its own keys? I see
> no advantage to be had from that.
> 
> > Application driven - server exchanges with client over secure
> > channel and
> > typical authentication system, application manages the key.
> 
> Aha! You're presuming that you have a secure channel. Let's say you
> do have one. Now what? Why do any crypto in the script? To avoid
> sending passwords to the server?? 

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.

Cheers

Received on Thursday, 9 June 2011 18:41:26 UTC