Re: Use case: Authenticate using eID

Hi. Ryan.
I understand the risk with CORS.
my previous example of CORS was incorrect.

also we can think CORS vice versa.

If the Key-A has the origin "good.com",
then when the user visits "good.com", "good.com" allow Key-A can be shared
with "company.com" with CORS header.
then "good.com" still has control for Key-A and "company.com" will share it.

CORS stands for Cross-Origin-Resource-Sharing.

it is not just for remote resources, but for just resources.
local resources like cryptography keys can be in scope of CORS.

our cryptography Key's origin control is also URL based.

regards
mountie



On Thu, May 9, 2013 at 10:06 AM, Ryan Sleevi <sleevi@google.com> wrote:

> 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.
>



-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

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