RE: Use case classification, and associated security models

Ø  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?

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