- From: Channy Yun <channy@mozilla.or.kr>
- Date: Sun, 26 Aug 2012 19:33:45 +0900
- To: Web Cryptography Working Group <public-webcrypto@w3.org>
- Message-ID: <CAG5Kj5EnhRQw8t6-it-soo_mTqoT4cgkHzRjsG8W0FO_gHEJig@mail.gmail.com>
2012/8/25 Wan-Teh Chang <wtc@google.com> > I am not proposing we solve that problem in the first version of the > API, but we should design the API so that it could support the > "certificate-private key pair" use case in the future. This seems to > require adding an input argument related to key access control to the > generateKey() method. We could require that input argument be "same > origin policy" in the first version of the API. > > Wan-Teh > > +1 A case of traditional auth or sign with "client certificate" in SSL/TLS was single original too. Korean use case has modified from this case with making own protocol between CA and host server to verify user's certificate and signtext. I think multi-origin is risky in most cases and single origin model for multi domain can be accetable by Ryan's suggestion. (For Korean use case, the CA server can offer trustable JS application to issue and treat certificate and host server can get sign text and verify message with protocol with CA.) But, most "certificate-private key pair" case treats keypairs in browser's certificate store. If user select certificate store as a keypair repository, we can prompt alert to users for multi-origin access and give a choice to users. Channy
Received on Sunday, 26 August 2012 10:34:37 UTC