- From: Richard Barnes <rbarnes@bbn.com>
- Date: Thu, 25 Apr 2013 17:38:44 -0400
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Hutchinson Michael <Michael.Hutchinson@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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