W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

Re: Use case: Authenticate using eID

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 8 May 2013 18:06:13 -0700
Message-ID: <CACvaWvaxnRsEA-S3urXX7UUs7yWAZHUCh=LLMKTN4M3Ww9WZzQ@mail.gmail.com>
To: Mountie Lee <mountie@paygate.net>
Cc: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, May 8, 2013 at 5:49 PM, Mountie Lee <mountie@paygate.net> wrote:
> Hi.
> eID in EU and personal certificate in KR is almost same.
> we also need cross-origin exceptions from current API.
>
> when I think the "bridge" between origin-specific and cross-origin policies,
> following bridges can be considered.
>
> - Certificate Trust Chain
> if the certificate is valid up to UA's trusted root CA, allow cross-origin
> operation with some restrictions

As several browser vendors explained during the F2F, this has no
meaning - from a sense of interoperability and because of the general
issue.

Having a certificate chain up to a "trusted" CA (for which "trusted"
differs for every UA) does nothing to assert that the site is not
"evil". I can go get a DV cert from any CA and use that to host
malware. I could also be a "legitimate" business interested in
super-cookies by tracking your ID.

It's equally grossly insufficient to say that the root of the server's
certificate chain should or could be equal to the root of the client's
certificate chain (as was proposed previously). When you consider
national schemes like the bridge PKI, and you realize that a variety
of commercial CAs also cross-sign national ID schemes for purposes of
interoperability (again, whether server or client certs), it's not at
all uncommon to see the 'blurring' of these domains.

>
> - CORS
> currently CORS is for remote resources.
> but we also can use CORS policy for our origin specific key issue.
>
> if the key-A has the origin-A,
> when user visit origin-B, the origin-A can be listed in the header of
> origin-B.

This will not work. Simply fill in the blanks for the origins to see why:

If the Key-A has the origin "good.com", then when the user visits
"attacker.com", the "good.com" key can be listed in the header of
"attacker.com".

Such a solution exposes Key-A to "attacker.com". This is insufficient.

CORS is about URL requests (not strictly XHR, but certainly for
*resources* accessed via uniform resource locators). It's not about
securing or protecting native Javascript objects. Please do not
confuse them.

>
> -------
>
> the cross-origin operation can be allowed with Certificate Chain and CORS
> combinations.
Received on Thursday, 9 May 2013 01:06:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC