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

Well, I think the original discussion started with x-domain key access. In general, I think that that is a good reason to have accessControl specified at the time of key creation. One use case I can think of is that of sister-sites (back-end synchronization for symmetric keys is an implementation problem).

I am not sure that SOP (Same Origin Policy – thanks Ryan : ) ) is applicable when we have accessControl attribute values specified by the origin (key creator).

I understand that the cookie model is constrained by SOP at the domain level, we can do the same (keep SOP), or do something else (break SOP, I guess). May be I am opening a can of worms here.



On 8/22/12 3:35 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 22, 2012 at 2:32 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
Ryan
I understand that the current spec is limited to origin-bound key set. I was
just extrapolating wrt this issue (26). You are right, I think we need to
spend good time munching this issue. However, I also think that this could
be a powerful feature (again – like cookie domain/path).

Thanks,
Seetharama

Just to make sure we're on the same page: cookie domain/path is not
related to the SOP and is a different security model. It is still
constrained by SOP.

We're talking about breaking SOP. That's a big discussion.


On 8/22/12 3:17 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 22, 2012 at 2:07 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:

Assuming that cross-domain usage of keys applies to only asymmetric keys
(thus we have 'certificates' with attributes the user can inspect), I tend
to agree with you.


I'm not sure this is inherently true. See Netflix's case for (master)
symmetric keys being used to derive (origin-specific) derived keys.

However, putting the privacy hat on, its possible that users are not always
wise-enough or attentive-enough to know what decision to make (another
pop-up to click-through). It is possible that a corporate cert could be
detected by other sites where they had no business of knowing.


Agreed. Although you can already do this to some degree with TLS client
auth...


This brings me to another question – I am assuming that the application
sifts through crypto.keys array to decide which key to use and which key to
prompt the user with. Again, putting the privacy hat, that may be too late
to prevent the application to know what all keys are there.

Seetharama


Note that, as currently spec'd, there is no inter-domain access going
on. KeyStorage is the origin-bound key storage.

So iterating through crypto.keys at present *only* returns keys that
the system generated, imported, or (for implementations that support
pre-provisioning) pre-provisioned.

IF we decide to permit multi-origin access, then we'll need to decide
how it should work. One proposal was the KeyQueryList way of key
discovery, but that has problems mentioned on
http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0161.html

Just to be clear: We're not exposing the entire key store to any
application to interrogate. As noted in the security considerations,
exposing the platform key store is equally problematic and should only
be done so with careful consideration and, likely, with a different
security model. For example, for Chromium, I'm not sure we would
expose system keys to web origins, but instead leave it for SysApps
(W3C SysApps WG) or through our extension mechanisms. This is not a
commitment either way, but just highlights the real security concerns
we have for a feature that, to some degree, has been promoted by us. I
just want to make sure that the messaging is clear.



On 8/22/12 2:07 PM, "David Dahl" <ddahl@mozilla.com<mailto:ddahl@mozilla.com>> wrote:

I think at first the single-origin concept for this API was short-sighted as
we will not have the ability to build decentralized, non-walled-garden
applications.

On the question of whether an approved-origin for a specific key can approve
further origins: This operation is perhaps better and more securely handled
by the browser implementation. I can imagine an implementation prompting the
user for approval when an attempt to use a key is initiated x-domain for the
first time, with the browser updating the key origin access list with
"remember this choice" checked, etc...

Cheers,

David

----- Original Message -----

From: "Web Cryptography Working Group Issue Tracker" <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>>
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Sent: Wednesday, August 22, 2012 2:43:00 PM
Subject: crypto-ISSUE-26 (multi-origin access): Should key generation be
allowed to specify multi-origin shared
access [Web Cryptography API]
crypto-ISSUE-26 (multi-origin access): Should key generation be
allowed to specify multi-origin shared access [Web Cryptography API]
http://www.w3.org/2012/webcrypto/track/issues/26
Raised by: Ryan Sleevi
On product: Web Cryptography API
The charter defines as "out of scope" as "access-control mechanisms
beyond the enforcement of the same-origin policy"
However, it was initially proposed by David Dahl, that during key
generation, an application may be permitted to specify alternative
origins be allowed to access the same key material. For example, it
might include a DOMString[] of authorized origins, for which, if the
key is generated, they're permitted to access.
Additionally, there's outstanding question as to whether an origin,
with access to a key, may be able to grant access to other origins
proactively.