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:17:15 -0700
Message-ID: <CACvaWvbw9Fab+cJN5TTYQnFoqzjNGzGCbm8LX4b-8UN7jHU46A@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: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

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:17:53 UTC

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