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

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.****
>
> ** **
>
> ****
>
> ** **
>
> 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.comfor 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-protocolsand 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