Re: Use case classification, and associated security models

On Mon, Jun 18, 2012 at 12:18 PM, Mark Watson <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> 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 *may* represent a completely different
>    key than "NetflixAuthKey" at 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?