Re: Key provenance

On Oct 4, 2013, at 5:07 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Fri, Oct 4, 2013 at 2:03 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> Hey all,
>> 
>> I've been thinking about some identity use cases for WebCrypto, and in several cases, it seems useful for someone who looks at a key object to be able to tell if it only exists in that browser instance.  The "extractable" attribute provides part of that, but you still have to know that the key was generated by the host, and not by importKey or unwrapKey.
>> 
>> Proposal:  Add an attribute to the Key interface ("provenance" or "source") that specifies how the key was introduced to the API.  Possible values are "generate" and "import", indicating that the key was generated by the browser or imported by some other JS code, respectively.
>> 
>> It seems like it would be trivial for browsers to set this attribute, and there are no other API changes needed.  And it seems like being able to know this property of keys could lead to some interesting applications.
>> 
>> Cheers,
>> --Richard
> 
> Can you please describe these applications?
> 
> I'm extremely reticent to introduce API surface changes simply because
> it "might" be useful, without a clear and demonstrated use case (and
> how an application cannot already accomplish this today).
> 
> I do not see any such need for this today, since an application can
> already know - because keys are not shared and fully controlled by the
> application.


The example I'm working on now requires this precisely because it involves sharing keys.  

Suppose you've got a site that is using an identity federation system such as OpenID Connect or Persona.  If you look at how these systems work today, they're based on assertions that anyone can present.  So they've got replay vulnerabilities -- the relying party doesn't know that the entity presenting the assertion is the one that the identity provider issued the assertion for (the subject of the assertion).

On the other hand, if the assertion could be bound to a key pair whose private key exists only in a single browser instance, then the relying party could be assured that the assertion is for the current browser instance by verifying that the browser possesses the private key corresponding to the assertion.

In this process, both the IdP and the RP want assurance that the private key exists only in the subject browser instance.  However, in the current system, you need to know both (1) the "extractable" attribute of the key and (2) whether the key was generated imported -- and only the party that generates the key pair knows that.  Whichever party didn't generate the key doesn't know whether the other side imported the key from elsewhere -- in which case the identity might not be for this browser instance.  So in addition to extractability, the private key needs to be tagged with its origin.

This can't be done today because there's no such thing as non-stealable information in the current DOM API.  Key handles are unique in this regard.

Hope that helps,
--Richard

Received on Friday, 4 October 2013 21:24:07 UTC