RE: Possible solution for same origin policy problem in Web Certificate API

Hi Arun,

I took a look at BrowserID use case that you mentioned.
The use case is very different from Korean banking use case.

[cid:image002.jpg@01CE7C11.EB45C6F0]

The above figure is simplified Korean banking use case. We get a certificate issued from caserver.com, which is a CA Server.
We then use the issued certificate at bank.com to sign a message digitally. At this time, Web browser doesn’t need to visit caserver.com for login or digital signature. Only bank.com needs to visit caserver.com to verify digital signature.

In this use case, it is very hard to provide PKI services under the same origin policy.

Best Regards

Sangrae Cho
===========================================================
Sangrae Cho
Authentication Research Team
ETRI (Electronics and Telecommunications Research Institute)
218 Gajeongro, Yuseong-Gu, Daejeon, 305-700, KOREA
Phone : +82-42-860-6939   Fax : +82-42-860-1471
===========================================================

From: Arun Ranganathan [mailto:arun@mozilla.com]
Sent: Monday, July 08, 2013 11:08 AM
To: 조상래
Cc: Web Cryptography Working Group (public-webcrypto@w3.org)
Subject: Re: Possible solution for same origin policy problem in Web Certificate API

Hi Sangrae,

On Jul 5, 2013, at 4:02 AM, 조상래 wrote:


Hi all,

I presented draft Web Certificate API in April F2F meeting and there were many questions about
same origin policy problem in WebCert.
The following is a possible solution for same origin problem in WebCert to consider.

PKI operates based on the concept of a circle of trust or trust domain with a Trusted Third Party. When a browser sends a digitally signed document to a web server, the server can verify the signature using a certificate sent from the browser. This can only be possible when two entities trust a CA server that issued the certificate. In this case, if the web server and CA server operates in the same domain, then PKI works fine under same origin policy (SOP). Otherwise it will not work unless cross origin policy (COP) is permitted.
We can find an example how PKI used in the web environment without SOP. In SSL client authentication, a web server can send a trusted CA list to a web browser to indicate which certificate can be used for client authentication. This means that TLS/SSL protocol works in the absence of same origin policy.

From this example, I think that the SOP and COP can co-exist in a single web browser as follows.
The Korean banking use case indicates that a user gets a certificate issued by a CA server and uses it to a bank for digital signature. The URL of two websites, CA server and bank, is totally different. So cross origin policy is strongly required to support for this use case.
As it is used in SSL case, if a server sends no trusted CA list to a web browser, the same origin policy governs to access to a stored certificate and the key belongs to the origin server.


Can you take a look at https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#browserid-use-of-cryptography-for-identity-protocols and see it if addresses your use case?  I'm wondering whether BrowserID can serve as a role model for cross-origin crypto, using structured clones and cross-origin messaging.

The sample code could be rewritten to exploit structure clonability, although now it makes use of JWT.

-- A*