RE: UA interop

Somehow that got implanted in my fingers muscle memory; implementation was what I was thinking :-)

s/implantation/implementation

>Michael

-----Original Message-----
From: Hutchinson Michael [mailto:Michael.Hutchinson@gemalto.com] 
Sent: Thursday, April 25, 2013 5:48 PM
To: Richard Barnes; Ryan Sleevi
Cc: public-webcrypto@w3.org
Subject: RE: UA interop

1st of all I hope that nobody took my questions as a request to change the normative sections of the WebCrypto API specification...they weren't!

They were more to stimulate debate about how different UA designs might end up complicating the end users life; and to see if there was any way to improve the situation.

That being said to extend the thought process...

If I store files on the secure file server from home, using a desktop (I know who still uses a desktop!), using an IE browser...the key material being persisted in a KSP

...and then later while at work with my corporate image, on a laptop, I want to download the secure files...I have to re-import my key material maybe to a file system (who knows I could be someone's implantation).

If I later want to do it with a mobile device I have to re-import it again.

In an internet café to a USB stick...etc etc etc

Is this just the cost of doing business from multiple machines and browser or can it be improved upon?

>Michael

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Thursday, April 25, 2013 4:39 PM
To: Ryan Sleevi
Cc: Hutchinson Michael; public-webcrypto@w3.org
Subject: Re: UA interop

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 22:54:58 UTC