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

Mountie,

I have provided examples already.

Certificates do not follow any policy, except the one of browsers.

Whether it's your concern or not, I think the key point is exposing certificates, and not let browsers decide for you.

Then I would like to have an answer about my last proposal, this impacts the whole DOM but the implementation is trivial.

If this can not solve what you want to do, please let me know.

Regards

Aymeric

Envoyé de mon iPhone

Le 8 juil. 2013 à 15:49, Mountie Lee <mountie@paygate.net> a écrit :

> Hi.
> 
> in this WG, when we handle certificate technology, we have to remember the Certificate Authority is TRUSTED THIRD PARTY between UA and Server.
> any certificate which is issued by server itself, it will be self-signed certificate and can not be trusted.
> 
> the very basic mechanism of certificate itself has THREE PARTIES.
> SOP can not be applicable to certificate model.
> 
> we all know what is certificate which was issued from trusted third party.
> 
> for non-repudiation services,
> at ISO/IEC 13888-1~3, ISO/IEC 10181-4
> TTP is almost always required.
> TTP is independent from service providers.
> 
> SOP mechanism is always based on TWO parties. there is no room for TTP.
> 
> I have no objection for same origin policy of current WebCrypto spec as PKCS#1 level of public key handling.
> but with certificate model,
> CA should be independent and out of control from service providers.
> 
> that is the reason still why I need exception of SOP for certificate.
> 
> regards
> mountie.
> 
> 
> 
> 
> 
> On Mon, Jul 8, 2013 at 7:32 PM, 조상래 <sangrae@etri.re.kr> wrote:
> Hi Arun,
> 
>  
> 
> I took a look at BrowserID use case that you mentioned.
> 
> The use case is very different from Korean banking use case.
> 
>  
> 
> <image002.jpg>
> 
>  
> 
> 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*
> 
> 
> 
> 
> -- 
> Mountie Lee
> 
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
> 
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>