Re: PROPOSAL: Close ISSUE-19 - Does it make sense to have authorized-origin and specific-origin keys

> I think you're confusing the issue.

Really?  I think I'm being completely clear :)


> Granting access to the same key to multiple origins allows any of
> those origins to spoof messages between eachother. To some, that's a
> feature. To most, that's a security risk.

I'm not sure what you mean by "spoof messages between each other".  If you assume that a key is bound to a domain in the first place -- in the sense of some remote entity's understanding, not in terms of the API -- then sure, cross-origin sharing allows the recipient origin to masquerade as the sending origin.  But it's not clear to me that the assumption in the previous sentence is valid.


> There's further the question about how that reasonably interacts with
> user security expectations.
> 
> It further creates an opportunity to allow origins to bypass existing
> origin communication mechanisms, by using keys to coordinate as
> persistent tracking identifiers across multiple origins.

I don't see anything new here.  Domains can already pass the value of a cookie, or some token to be held in localStorage.

In fact, you can do better here than those examples, because the UA can impose controls on which origins can actually use the key.  Those controls can be done outside the scope of this spec, much like the privacy controls on the Geolocation API.

Maybe you're envisioning a different flavor of key than I am?  In my mind, a Key object is a static collection of bits, which represents the key in a way that is intelligible to the API, but not to the application (except for the exposed fields).  In that case, you don't even get a covert channel from, say, changing key attributes.

--Richard





> On Mon, Feb 4, 2013 at 12:00 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> IIRC, you had invited proposals for cross-origin key management in a previous call.
>> 
>> PolyCrypt has one example of how to do so.  In that context, Key objects are self-contained; the key object contains a wrapped version of the actual key data, encrypted under a symmetric key held by the API implementation.  When an operation using the key is to be performed, the API unwraps the key and performs the operation.
>> 
>> The upshot of this design is that keys can be cleanly transferred between domains using mechanisms like postMessage, so that cross-domain sharing of keys is solved trivially using existing mechanisms.  An implementation could layer cross-origin restrictions on top of is by including information out the "owner" domain within the wrapped (and thus integrity-protected) key octets.
>> 
>> I'm not sure how this would show up in the API spec, however.  Maybe there's some interface (Transferable? Clonable?) that would encode these expectations.   We could discuss this implementation possibility as a possible realization.
>> 
>> --Richard
>> 
>> 
>> On Jan 31, 2013, at 2:11 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> 
>>> http://www.w3.org/2012/webcrypto/track/issues/19
>>> 
>>> I would like to propose that we CLOSE ISSUE-19. The group has not made
>>> any progress on this issue since it was raised in August 2012, nor
>>> have there been any proposals on how to resolve this.
>>> 
>>> The current specification limits storage to single-origin, consistent
>>> with all other web storage APIs. There have been no proposal for
>>> origin-authorized keys at this point, and such proposals would
>>> introduce significant security concerns that would need to be
>>> resolved.
>>> 
>>> I would like to propose that this issue be CLOSED against the current
>>> specification.
>>> 
>> 
>

Received on Monday, 4 February 2013 20:21:23 UTC