Re: Origin-bound keys

On Aug 13, 2012, at 4:38 PM, Ryan Sleevi wrote:

> 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

I don't much mind whether the identifier is app or UA-generated. It doesn't really affect this discussion.

> 
> 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' }

I thought you were against the kvps ? Anyway, if the UA generated the identifier, I can just put my mapping in local storage/IndexDB "nflx-ksh" : "54efigf88iuyte4oqt==".

> 
>> 
>> 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' }.

So then I think that would discourage me from specifying the kvp - so that it became more difficult for others to find my key ;-)

> 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.

I think this would be another element in KeyGenerationParams, "same-origin" or something like that, with the definition "true if the application requires that the key should not be visible to other origins". 

I'm sure the wording will need some work. A restriction on allowing cross-origin access that is as strong as the similar restriction for local storage or cookies would probably be sufficient (presumably the user is allowed to override those restrictions, based on the same arguments you've given for keys).

…Mark

> 
> What do you think?
> 
> Ryan
>

Received on Tuesday, 14 August 2012 00:45:02 UTC