Re: UA interop

On Thu, Apr 25, 2013 at 3:48 PM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> 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

There is no guarantee that your key material may be placed in a KSP.
This is an implementation assumption here.

>
> ...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

This API is not trying to define key storage, intentionally.

For example, at least two user agents that participate in this WG
support some form of "cloud sync" that synchronizes preferences,
passwords, and other elements of user personalization. It's entirely
possible that such UAs MAY support synchronizing keying material
(along with web storage data, presumably). As I understand it, for
"sysapps" (eg: extensions/web apps), they already do perform such
synchronization.

There are some use cases that strongly prefer key-per-UA/per-device.
There are other use cases that strongly prefer key-per-user, a much
more abstract concept.

That's a problem to be solved at the application layer, for which a
variety of solutions and innovations exist both at the browser layer
and within the application layer. Attempting to define a one-size fits
all solution, or attempting to improve before there's a clear set of
problem statements, use cases, and deployed applications would likely
be a bit misguided.

So yeah, for now, it's "working as intended". If you want to use a
common key across multiple devices, you likely want to examine some
form of escrow or key derivation (such as password based key
derivation, which this API does support).

>
> -----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 23:02:34 UTC