Re: Use case: Authenticate using eID

On May 8, 2013 6:55 PM, "Mountie Lee" <mountie@paygate.net> wrote:
>
> 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.

That is not how CORS works.

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

That is not correct. Please read the spec again.

Again, "resources" are a particular term of art in the web, and are not
what you describe. This is very clear when you look at how CORS works, by
setting *request* headers on outgoing responses.

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

This is also incorrect on many levels.
- Origin != URL
- We do not discover keys as URLs.
- you do not access the API by making HTTP requests to a remote server.

I'm sorry that you're having trouble understanding CORS, but it is not the
mechanism relevant to this discussion.

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