RE: Use case classification, and associated security models

Good points all.

I think the idea of generic metadata (which may include a name, as well as properties taken from a certificate) is a good one, but will need careful scoping to keep it from becoming over-complex. Do you think this should be restricted to specific defined attributes or left generic as you are advocating with algorithm parameters?

From: Ryan Sleevi [mailto:sleevi@google.com]<mailto:[mailto:sleevi@google.com]>
Sent: Monday, June 18, 2012 3:29 PM
To: Mark Watson
Cc: Vijay Bharadwaj; Mitch Zollinger; <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>
Subject: Re: Use case classification, and associated security models


On Mon, Jun 18, 2012 at 12:18 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jun 13, 2012, at 6:13 PM, Ryan Sleevi wrote:



On Wed, Jun 13, 2012 at 6:00 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto: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")

It's not a question of comparing advantages: we need both kinds of identifier. An identifier for the general 'class' of key (e.g. "NetflixAuthKey") and something which identifies the specific key. If there are thousands of devices deployed, each with a different pre-provisioned "NetflixAuthKey" I need to know which one I am talking to to decrypt/verify the message

I think I see where the disconnect was. I had been assuming that there was already some external data that provided the 'who' answer. For example, if using a direct username (eg; jdoe), then if you successfully locate the "NetflixAuthKey", you know that it's jdoe's NetflixAuthKey. If they have multiple auth keys that match that name, it's up to the app to disambiguate (eg: hash of public key? some other identifier). It sounds like you're wanting a way to discover, with key alone, that this is jdoe's auth key - is that a roughly correct understanding?




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<http://netflix.com/> may represent a completely different key than "NetflixAuthKey" at netflixcdn.com<http://netflixcdn.com/>.
This is fine for identifying the key amongst other keys present within that device. The UUID is also needed to identify the key amongst all the other NetflixAuthKeys across different devices.

...Mark

And that's where I think the general privacy concerns rightfully creep in, I think. Such keys are, if persistent, super-cookies. If different origins (even if operated by the same organization) can discover a specific key, then they can collaborate to track the user in some form.

However, setting aside the cross-origin concerns temporarily, my gut is that identifying keys (and metadata associated with those keys) is going to be something that may vary on an application-by-application basis. I'll see about proposing a concrete Key object API that can intersect/overlap with David Dahl's github experiments, but one idea I've been toying with is whether or not it's possible to allow applications to associate arbitrary meta-data with a key. For example, a NetFlix app may, at key creation (or at offline pre-provisioning, which is out of scope), associate some meta-data with the key, such as

var key = /* get the key somehow */;
key.setAttribute('uuid', generateSomeUUID(key));
key.setAttribute('subscriber_id', 'some other value');

That at least allows an origin to define its own criteria for key identification, and it can then do the rest via KeyQueryList (or whatever API the editors go with). I can think of several downsides with this approach - for example, I'm most concerned with whether or not this data is replicated across origins and, if so, if it might allow for cross-origin communication and/or poisoning. Alternatively, if the key ID is treated entirely as an opaque DOMString/Uint8Array, then a web application could simply implement their own attribute storage via LocalStorage in order to determine/map UUID.

Broadly speaking, the question of key metadata seems to also be of relevance to the use of/management of certificates, at least in the case of asymmetric algorithms. After all, the point of the certificate encapsulating the public key is, in part, to convey a wide array of additional information - constraints/restrictions (basicConstraints, keyUsage, extendedKeyUsage), identity (subject DN), authority (issuer DN), etc. So far, this has been pushed to the secondary goals, as I understand it. However, if we think either UUIDs or arbitrary attributes are in-scope primary features, should certificates (which are just a different form of storage) also be in scope?