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

Hi.
I think cross-origin access is necessary.

in current status is
certificate issued from one CA and the private key pair can be used is
different site.

so I suggest followings
- depending on user agent. but working group recommend the security
consideration to implementer
- is user agent trust certificate on client side and server side (ssl
server cert),
- allow cross-origin access.
- allow for asymmetric key only

this is the best balance for security concerns and real world requirement.

user generate key pair from CA (as origin-A)
and origin-B is able to initiate key operation with key-A

best regards
mountie.

On Thu, Aug 23, 2012 at 7:23 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Wed, Aug 22, 2012 at 3:02 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
> > 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.
> >
>
> Right. If we're going to allow cross-domain access, I'd say that
> breaks the same origin policy, and that's a dangerous proposition.
>
> I think everyone with an opinion on this (positive or negative) should
> make sure to read [1]. Additionally, for those not familiar with the
> concerns and paranoia of the user agent vendors, [2] is solid reading
> to understand the many security issues that have arisen related to the
> same origin policy.
>
> These concerns may not be immediately obvious, but other web platform
> APIs have taken significant efforts to preserve the same origin policy
> and security. For example, consider the <canvas> tag, which blocks raw
> access to pixels for images that have been 'tainted' by cross-origin
> resources, since such access may represent a way for security issues
> to arise [3].
>
> I think this API, being so explicitly security related, should
> absolutely respect SOP.
>
> [1] http://tools.ietf.org/html/rfc6454#section-3.4
> [2] http://code.google.com/p/browsersec/wiki/Part2
> [3] https://developer.mozilla.org/en-US/docs/CORS_Enabled_Image
>
> >
> >
> > On 8/22/12 3:35 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
> >
> > 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.
> >
> >
> >
> >
> >
>
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World