- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 8 May 2013 18:06:13 -0700
- To: Mountie Lee <mountie@paygate.net>
- Cc: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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.
Received on Thursday, 9 May 2013 01:06:40 UTC