Re: Use case classification, and associated security models

On Wed, Jun 13, 2012 at 6:00 PM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

>  **Ø  **When it first runs, the script does not know the UUID of any
> pre-provisioned keys - it must query based on the origin-specified naming
> scheme.****
>
> ** **
>
> Is this necessarily true?****
>
> ** **
>
> Crazy idea – what if the origin-specified naming scheme is based on UUIDs?
> Specifically, if each pre-provisioned key had a UUID that was a function of
> the user’s identity? (e.g. an HMAC of the user name with some key held by
> the service, or just a random UUID associated with the user in a
> server-side table) The service could query for the key by UUID because for
> any user it would know the expected UUID of the key. But the UUID is
> effectively random to anyone else who doesn’t know the HMAC key, so there
> is no feasible way anyone else can probe for it.****
>
> ** **
>
> Would requiring keys to be named with UUIDs in this way make our API
> simpler?
>

In this formulation, what is the advantage of a UUID over an opaque string
supplied by the application (which may be a UUID, or may be a string such
as the simple English string "NetflixAuthKey")

My thought is that whatever naming scheme we go with, it should be:

   - Entirely up to the implementing application/web site how it wants to
   refer to keys. That is, it can dictate the key name itself.
   - Entirely scoped/bound to the current security origin. That is
   "NetflixAuthKey" at netflix.com *may* represent a completely different
   key than "NetflixAuthKey" at netflixcdn.com.

This then opens two new desired behaviours:

   - Users may wish to re-use the same key under the same name or different
   name between origins (eg: the scenarios #1 and #2 I gave for Alice and Bob)
   - Site operators may wish to share the same key under the same name
   between different origins (eg: the netflix.com and netflixcdn.com, both
   entities presumed operated by Netflix, that both wish to perform some
   keying operation)

>From the perspective of the application consuming the API (eg: doing
operations with the keys), a key handle is a key handle. The above
scenarios only come up with key discovery. However, whether the key's
provenance is via Scenario #1, #2, or #3, and whether it's a shared key,
unique-per-origin, or pre-provisioned, is something largely transparent at
the API layer outside of discovery.

****
>
> ** **
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Wednesday, June 13, 2012 8:59 AM
> *To:* Ryan Sleevi
> *Cc:* Mitch Zollinger; <public-webcrypto@w3.org>
>
> *Subject:* Re: Use case classification, and associated security models****
>
>  ** **
>
> ** **
>
> On Jun 12, 2012, at 3:58 PM, Ryan Sleevi wrote:****
>
>
>
> ****
>
> If we adopt some form of UUID notation (which I still need to mull over
> the privacy risks), one might further expand to****
>
> ** **
>
> var kql = window.crypto.queryKey(****
>
>   {****
>
>     'id': [ 'UUID_1', 'UUID_2' ],****
>
>   })****
>
> ** **
>
> or with an origin-specified naming scheme:****
>
> ** **
>
> var kql = window.crypto.queryKey(****
>
>   {****
>
>     'name': 'NetFlixAuthenticationKey',****
>
>   });****
>
> ** **
>
> It's not really "either-or", you need both. When it first runs, the script
> does not know the UUID of any pre-provisioned keys - it must query based on
> the origin-specified naming scheme. If it finds a pre-provisioned key, then
> it must be able to obtain the UUID of that key. I am not sure there is a
> need to be able to retrieve keys by UUID.****
>
> ** **
>
> Regarding privacy, as a starting point I would say all keys, including
> pre-provisioned ones, should be origin-bound. So the UUID is visible only
> to one origin.****
>
> ** **
>
> It's possible that an implementation might use a single pre-provisioned
> master key to generate pre-provisioned keying material for multiple
> origins, but in this case it must use some one-way origin-specific function
> to generate the key and UUID for each origin.****
>
> ** **
>
> Extending this to pre-provisioned keys visible to multiple origins indeed
> requires some more difficult privacy issues to be addressed. That's not
> something that is necessary for our use-case, though others may have this
> requirement.****
>
> ** **
>
> …Mark****
>