Re: Request for feedback: DOMCrypt API proposal

----- Original Message -----
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Adam Barth" <w3c@adambarth.com>
Cc: "David Dahl" <ddahl@mozilla.com>, public-web-security@w3.org
Sent: Monday, June 6, 2011 12:26:49 AM
Subject: Re: Request for feedback: DOMCrypt API proposal

> Well, here is the big decision-point.  Is this API dedicated for
> keys that are store in the web environment only?  I.e. the API
> does not have access to (for example) on smart cards?

The chief use case is web application encryption. What has surfaced in these discussions is the need to try and devise some better APIs that can work with smart cards, but is a secondary concern.

>> Another idea is treat keypairs similar to the data in localStorage where a script 
>> cannot use the API unless it has been granted access and it is with the keypair
>> generated by the current origin only.

> I couldn't deduct that from the specification but it is IMO the only way
> ahead otherwise the whole thing will collapse on security issues!

This needs to be eloquently stated in the spec. I will be working on this today.

>> Right.  All state should be per-origin.  We don't want to repeat the
>> mistakes of SSL client certs!

> SSL client certs will remain the most important PKI method because
> DOMCrypt/web storage has huge limitations, particularly with respect
> to credential mobility.  Payment credentials such a Google wallet
> will be stored in SE (Security Elements) and unlikely be available
> through DOMCrypt.

> Don't get me wrong, but we are talking about two entirely different
> use-cases.

It will be good to list all of these additional use cases with what needs to be done to allow interoperability (if possible). 

Regards,

David

Received on Monday, 6 June 2011 13:41:50 UTC