- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Fri, 10 May 2013 12:28:59 +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: <518CCBEB.7020407@gmail.com>
Mountie, Your example can not work, the origin is the one of the page (ie from where your html code is loaded), and you can interact with the servers from the main page and iframes. Let's take Karen's first example, maybe there are other (and nicer) way to do it, but I would do something like : - Dr Smith loads healthcare page - healthcare page includes an iframe to e-prescription, - healthcare page generates keys for Dr Smith and a reference for Dr Smith, and then send keys+reference to e-prescrition iframe via postMessage - e-prescription iframe registers the keys in indexedDB with the reference to Dr Smith and sends a xhr to e-prescription server with the reference to Dr Smith - Dr Smith loads e-prescription and logs in, e-prescription recognizes Dr Smith and knows his reference - e-prescription uses Dr Smith's reference and can access Dr Smith's keys in indexedDB and use them This is about exactly what we are doing in [1] (nothing to do with crypto) to store gadgets created at an origin to your account on another origin. Regards, http://extractwidget.com/#demo Le 10/05/2013 03:11, Mountie Lee a écrit : > with iframe, we have no control > the WebApp should be interactive with server. > > with postMessage, > as my understanding, it is difficult to control for interactive > communication between UA and server. > > with script-src > does it make sense with following scenario? > > - load scripts from two origins (origin-A, origin-B) with CSP > - key-A will be accessable by the script-A > - generate signature with Key-A > - the signature message will be handled by script-B which is loaded > from origin-B > > in the page > we can see these style > > <html><head><title>test</title> > <script language="javascript" > src="https://originA.com/scriptA.js"></script> > <script language="javascript" > src="https://originB.com/scriptB.js"></script> > </head> > <body>...</body></html> > > scriptA has control for key-A > the generated signatureA message can be handled with scriptB > scriptB send signatureA to originB via postMessage or other mechanisms > > > > > On Fri, May 10, 2013 at 6:28 AM, Aymeric Vitte <vitteaymeric@gmail.com > <mailto:vitteaymeric@gmail.com>> wrote: > > 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 <mailto: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 <http://www.jcore.fr> > Webble :www.webble.it <http://www.webble.it> > Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com> > BlimpMe! :www.blimpme.com <http://www.blimpme.com> > > > > > -- > 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 Friday, 10 May 2013 10:26:36 UTC