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

Re: Use case: Authenticate using eID

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Thu, 09 May 2013 23:28:14 +0200
Message-ID: <518C14EE.4060008@gmail.com>
To: Mountie Lee <mountie@paygate.net>
CC: Ryan Sleevi <sleevi@google.com>, Arun Ranganathan <arun@mozilla.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
iframes and postMessage, you can not do anything else, CORS is about 
fetching resources from different origins, keys are local.

Regards,

Le 09/05/2013 11:44, Mountie Lee a écrit :
> Ryan.
>
> could you recommend me cross-origin solutions for the use cases (eID 
> or Korean Banking)?
>
>
> On Thu, May 9, 2013 at 11:17 AM, Ryan Sleevi <sleevi@google.com 
> <mailto:sleevi@google.com>> wrote:
>
>
>     On May 8, 2013 6:55 PM, "Mountie Lee" <mountie@paygate.net
>     <mailto: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 <http://good.com>",
>     > then when the user visits "good.com <http://good.com>",
>     "good.com <http://good.com>" allow Key-A can be shared with
>     "company.com <http://company.com>" with CORS header.
>     > then "good.com <http://good.com>" still has control for Key-A
>     and "company.com <http://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
>     <mailto:sleevi@google.com>> wrote:
>     >>
>     >> On Wed, May 8, 2013 at 5:49 PM, Mountie Lee
>     <mountie@paygate.net <mailto: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 <http://good.com>", then
>     when the user visits
>     >> "attacker.com <http://attacker.com>", the "good.com
>     <http://good.com>" key can be listed in the header of
>     >> "attacker.com <http://attacker.com>".
>     >>
>     >> Such a solution exposes Key-A to "attacker.com
>     <http://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 <mailto:mountie@paygate.net>
>     >
>     > =======================================
>     > PayGate Inc.
>     > THE STANDARD FOR ONLINE PAYMENT
>     > for Korea, Japan, China, and the World
>     >
>
>
>
>
> -- 
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>
>

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Thursday, 9 May 2013 21:25:49 UTC

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