Re: Origin-bound keys

On Mon, Aug 13, 2012 at 3:55 PM, Mark Watson <watsonm@netflix.com> wrote:
> Ryan,
>
> To follow up on the discussion on the call today, I'd like to check if I understood correctly what you said about the id field being origin-specific correctly:
>
> Suppose https://netflix.com uses Diffie-Hellman key generation to generate a key (A) which it gives the id 'netflix-key'.
>
> Suppose https://freenetflix.com also uses Diffie-Hellman key generation to generate a key (B) which it also gives the same id, 'netflix-key'.

I think it's still an open issue where .id will contain the
'meaningful' id (eg: application gets to define its identifiers), like
you've described here, or whether it contains a browser-auto-generated
name.

I strongly believe something like blobURIs or equivalent is
appropriate here - eg, http://www.w3.org/TR/FileAPI/#url

So, as proposed in the past by (I believe) ddahl, the id here would
contain a canonical UUID.

Under such a scheme, you would have keys with attributes/value pairs,
such as via KeyAttributes. Something like { 'name': 'nflx-ksh' }

>
> Keys (A) and (B) are necessarily different having come from separate DH exchanges. Later, if https://netflix.com attempts to use the key with id 'nflx-ksh', which key will be used ? A or B ?
>
> I understand from the ids being origin-specific, that A and B are separately stored and that https://netflix.com will get key A, right ?

Yes.

>
> Next, if only https://netflix.com has generated a key as above and then http://freenetflix.com attempts to retrieve a key with id 'netflix-key', what could happen:
> (a) this fails because http://freenetflix.com has never generated a key with this id
> (b) the user is asked whether http://freenetflix.com can access key id 'netflix-ksh' from https://netflix.com
> (c) the user is given a dialog saying 'please choose a key for http://freenetflix.com to use as netflix-key from the following list, where the list includes the https://netflix.com netflix-key (and probably many others)
>
> Or multiple of the above options ?
>
> I would expect the answer in the first case is A and in the second case is (a). If not, I don't really understand what 'origin-specific' means in the definition of the id.

Dependent on the KeyQueryList parameters, I would think.

The default I think would be (a), provided the KQL was for some
specific UUID. I would think (c) would come into play if the
application indicated it would accept any key from any origin that,
say, met the criteria { 'name': 'nflx-ksh' }. Then it's up to the
implementation to decide appropriate behaviour (including prompt or
app policy, as two examples), but with the default being "No, you
can't".

>
> Are you are looking for a method for an application to "generate a new key in a manner specified by the user", where the user could specify that the key be generated randomly, or that an existing key (from any origin) be used ? What other methods would you see providing a key generated by one origin to another origin ?

This is important when we consider this API as a replacement for
<keygen>. Some implementations of <keygen> allow the user to select an
existing key (or further alter the key generation criteria), others
simply generate a new key every time.

When you consider the CA issuance model, such as what Mountie brought
up and as discussed during the F2F, I think this is an important use
case that we should be considering.

That said, I think I definitely agree with the application's abilities
to provide hints and guidance for an implementation about
(origin-authorized) vs (origin-generated), but I don't think the spec
should be have normative text about how to specifically handle those.

What do you think?

Ryan

Received on Monday, 13 August 2012 23:38:29 UTC