Re: crypto-ISSUE-26 (multi-origin access): Should key generation be allowed to specify multi-origin shared access [Web Cryptography API]

I began working out a justification of my own use case for multi-origin keys. In the face of window.postMessage, cross-origin XHR and reading up on previous web APIs that stuck to the SOP, I cannot justify it.

At the end of the day, browsers are already building in ways to share resources between domains. It may be that multi-origin key sharing is  unnecessary.

Regards,

David

----- Original Message -----
From: "Ryan Sleevi" <sleevi@google.com>
To: "Wan-Teh Chang" <wtc@google.com>
Cc: "Mountie Lee" <mountie.lee@mw2.or.kr>, "Seetharama Rao Durbha" <S.Durbha@cablelabs.com>, "David Dahl" <ddahl@mozilla.com>, "Web Cryptography Working Group" <public-webcrypto@w3.org>
Sent: Wednesday, August 22, 2012 8:46:19 PM
Subject: Re: crypto-ISSUE-26 (multi-origin access): Should key generation be  allowed to specify multi-origin shared access [Web Cryptography API]

On Wed, Aug 22, 2012 at 6:28 PM, Wan-Teh Chang <wtc@google.com> wrote:
> It would be nice for implementations to be able to support two types
> of key access:
> - origin-bound keys
> - shared keys that are associated with certificates
>
> The Key object should be specified to have an attribute related to
> which origins may use the key. We can start with supporting
> origin-bound keys only.
>
> Also, after a signing key has been used, it seems dangerous to broaden
> the origins. I am worried that an old signature generated when only
> one origin was allowed may become valid for other origins
> retroactively. So this key attribute for access control probably
> should be immutable for signing keys at least.
>
> Wan-Teh

Mountie, Wan-Teh, or Seetharama,

Could one of you please write-up a concrete Use Case for multiple
origin key access? I want to make sure we have a place where we can
capture:
1) Why is it useful/valuable
2) What are the security and privacy risks
3) Why other alternatives are not suitable
  3a) script-src , which inherits the SOP of the including domain
  3b) Web Intents
  3c) inter-origin communication mechanisms (postMessage, iframe, CORS, etc)

I'm deeply concerned about #2 here, so I want to make sure we can
actually have something concrete to discuss.

I also don't believe we should attempt to reach consensus on this
issue prior to FPWD. As referenced in previous documents, the state of
the art and the active encouragement of the web community is not to
violate the SOP. In order to help reviewers understand why the
violation is useful or important, I think a strong use case will need
to be presented.

Received on Thursday, 23 August 2012 17:01:11 UTC