- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Mon, 04 Nov 2013 11:23:29 +0100
- To: Mountie Lee <mountie@paygate.net>, Ryan Sleevi <sleevi@google.com>
- CC: Web Cryptography Working Group <public-webcrypto@w3.org>
- Message-ID: <527775A1.5010104@gmail.com>
As far as I am concerned, not talking about provisioning but certificate management, and not talking about standards, certficate management and certs/keys pem/der/asn1/whatever conversion should do very exactly what is doing this API: https://github.com/digitalbazaar/forge I did not give up for a SSL/TLS proposal, and I think for this the idea should be something like: http://nodejs.org/api/tls.html#tls_tls_createsecurepair_credentials_isserver_requestcert_rejectunauthorized using the Streams API Regards Aymeric Le 02/11/2013 04:37, Mountie Lee a écrit : > Hi. Ryan. > > thank you for your comment. > > your comment is very helpful. > > I will try to prepare and share the true statement. > > thanks again. > > regards > mountie. > > > On Fri, Nov 1, 2013 at 2:41 AM, Ryan Sleevi <sleevi@google.com > <mailto:sleevi@google.com>> wrote: > > > On Thu, Oct 31, 2013 at 5:14 AM, Mountie Lee <mountie@paygate.net > <mailto:mountie@paygate.net>> wrote: > > Hi. Folks. > > I have discussed with sangrae for problem statement. > before updating Wiki page, I want to share the reason via > email first. > > let me inform that why we need Web Certificate API. > > ---- > at the charter, certificate related requirements are described. > to approach certificate relates issues, we need certificate > itself. > > at least, we have two technical standards for certificate > management. > > PKCS#10 and CMP > > keygen is based on PKCS#10. > we have no API with CMP > > followings are the details why we need CMP based certificate > management API. > > 1. CMP has full key lifecycle control > PKCS#10 is just for certificate issuance. > but > CMP protocol has certificate issue/renew/revocation/suspend > these are the full lifecycle of certificate. > > 2. ASN.1 > ASN.1 is widely used format specially required for CMP. > current browser does not expose ASN.1 functions to api level > > 3. different security control > > 3.1 CMP has POP(Proof of Possession) support. > > CMP use reference and authentication code which is generated > from CA(or RA) > reference and authentication code can be generated by strong > face-to-face identity verification. > but PKCS#10 has none. > CSR from PKCS#10 is signed by private key of user browser. > but self-signed signature does not provide POP(Proof of > Possession) for certificate issuance. > the CSR need additional protection mechanism to prevent MITM > attack. > > 3.2 CMP provide application level protection. > > Certificate Issuing request of CMP is encrypted with CA's > public key and transmitted over normal HTTP or TLS session. > TLS itself is just protecting transport layer of OSI 7 layers. > if the data is transmitted over multiple nodes, TLS is not enough. > the public key encryption used in CMP is applicable on the > application layer (the top level of osi 7 layers between > browser sandbox and server memory of application server) > > 4. backward compatibility > because of above technical/security reasons, many countries > (at least, Korea) adopted CMP as their default certificate > management system. > and those public key infrastructure is escalated to > regulational level. > if browser support CMP, it will give backward compatibility > with existing infrastructures. > > 5. Plugin Replacement > because of above reasons, > plugins (activeX, java applet and so on) are widely used for > certificate management in many countries. > the native support for CMP will help kicking off plugins. > > 6. Certificate is useful. > the certificate and it's related infrastructures are used for > non-repudiation service, verifying identity or many other usages. > it is also mentioned at charter of our working group. > the API for certificate issuance will be the base for > discussion of some part of high level api. > it will also touch keyStorage security issue. > > ------------------ > > we have too much reasons why certificate is necessary. > PKCS#10 based keygen itself is useful. > but it has some missing parts. > > that is the reason why we need Web Certificate API. > > regards > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 <tel:%2B82%202%202140%202700> > E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > Hi Mountie, > > As noted during a previous call, the IETF has multiple standards > for managing and provisioning certificts - CMS, CMC, CMP, and more > recently, EST. > > Rather than focusing on a particular solution (eg: an API for > CMP), can you focus on the problem statements themselves? I would > simply state that it's unlikely to argue for CMP simply because it > "does what you need" - instead, it's important to understand what > you actually need. > > Also, as requested repeatedly, can you explore a hypothetical > implementation *in Javascript* of CMP/CMS/CMC/EST/etc. When you > examine what it would take, *in Javascript*, to fully implement > these protocols, please explore what deficiencies exist in the > WebCrypto API when compared with <keygen> > > For example, the 'obvious' aspect that immediately stands to mind > is that keys provisioned via <keygen> are, traditionally, made > available to some system-wide store (on browsers that implement > keygen, which is not universal). Certificate provisioning > traditionally happens via application/x-x509-user-cert delivering > a certificate/certificate chain. You can readily see this > deployed, in the real world, by looking at CAs like StartCom > (operators of StartSSL), which use this as a key part of their > authentication flow. > > If WebCrypto allowed keys to be generated in such stores, would > that be sufficient for a fully-JS implementation of CMP? Why or > why not? > > Rather than focusing on CMP specifically as being supported by a > browser, please take a critical look at what it would take to > implement *in Javascript*. What security or functional > deficiencies exist (and without proposing a resolution for them), > as that's the true problem statement. > > > > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > > > -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Received on Monday, 4 November 2013 10:24:20 UTC