W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

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

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 22 Aug 2012 14:35:46 -0700
Message-ID: <CACvaWvZau0oTDFrg-gEPPnGpxJr0t44LJVXh8Cnq83U-o8WqnQ@mail.gmail.com>
To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Cc: David Dahl <ddahl@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
On Wed, Aug 22, 2012 at 2:32 PM, Seetharama Rao Durbha
<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> wrote:
>
> On Wed, Aug 22, 2012 at 2:07 PM, Seetharama Rao Durbha
> <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> 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>
> To: 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.
>
>
>
>
Received on Wednesday, 22 August 2012 21:36:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC