W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: Use case classification, and associated security models

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 13 Jun 2012 15:58:44 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: Mitch Zollinger <mzollinger@netflix.com>, "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>
Message-ID: <191A96AA-7F01-4C1E-924E-44EAC3A16360@netflix.com>

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.

Received on Wednesday, 13 June 2012 15:59:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC