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

Hi Richard,

I think you're confusing the issue.

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.

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.

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:08:27 UTC