- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 09 May 2013 23:28:14 +0200
- 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>
- Message-ID: <518C14EE.4060008@gmail.com>
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