W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: UA interop

From: Richard Barnes <rbarnes@bbn.com>
Date: Thu, 25 Apr 2013 17:38:44 -0400
Cc: Hutchinson Michael <Michael.Hutchinson@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-Id: <130B9A2B-5075-4DBA-A916-4E7676DF8D05@bbn.com>
To: Ryan Sleevi <sleevi@google.com>
On Apr 25, 2013, at 3:18 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, Apr 25, 2013 at 12:14 PM, Hutchinson Michael
> <Michael.Hutchinson@gemalto.com> wrote:
>> If one UA (i.e. IE) persists its key material using one method (CNG - KSP) are were sure that a second UA (i.e. FF) can make use of it?
> 
> No. This is out of scope. Just because one browser has a cookie store,
> for example, does not mean other browsers can use that cookie store.
> 
> Same for IDB, localStorage, etc.

+1

This could be a use case for key wrap/unwrap, however.  Imagine a service with long-lived keys (e.g., a secure file storage service) that can be accessed from multiple UA instances.  Then the server would want to have the client that generates a long-lived key cache an encrypted copy on the server (wrap), then provision those keys out to UAs (unwrap).

--Richard



> 
>> 
>> Implication would be that the user must use the same UA for all key operations...
> 
> Correct. Same as they have to for cookies/localStorage/IDB/etc.
> 
> The Web Crypto API explicitly does not declare how keys are to be
> stored, and this is intentional. They behave "just" like existing Web
> APIs, with the advantage that they can be used to poke into the UA's
> existing cryptographic stack to take advantage of the reasons
> enumerated (eg: correctness of implementation, performance, security,
> etc)
> 
>> 
>>> Michael
>> 
>> 
> 
Received on Thursday, 25 April 2013 21:39:12 UTC

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