RE: the reason why we need Web Certificate API

Hi Ryan,



Thanks for your comment.



The following is the another reason why Web Certificate API is needed.



Web Certificate API is trying to provide certificate management functionalities using various existing methods including CMC, CMP, PKCS10.

So, it is not just about CMP alone.

We think that certificate-related functions should be essential security service that a browser should provide because it is baseline security functions that other web apps can easily use for authentication and digital signature.



Is it really efficient that every web service provider implements certificate management in JS if they need it?

I think the certificate function is a building block that can used to build other security services or functions. Implementing in JS means that every web service provider who wishes to use a certificate has to implement on its own. It is not always easy to implement certificate function using WebCrypto unless you are very familiar with security technologies. Even if you do, this will require a lot of efforts for testing and complying with the standard protocol. Therefore I think it is much more efficient if it is implemented in the browser. Once it is provided in the browser, it will be very useful to implement security service in JS.



JS is not secure enough to execute certificate management function compared to implementing in a browser. Certificate management is a starting point for many security related solutions requiring robust and secure implementation. JavaScript has security vulnerabilities in nature. It is not a suitable programming language for security sensitive program like certificate management. Certificate management is like a Trust anchor. I know that WebCert JavaScript API is used to call certificate management function in the browser and calling JS API is also vulnerable too. However, it is necessary to ensure that certificate management is implemented in secure way.



Standard way to access key and certificate store since user can get cert issued in one browser and use it for login in other browser.

This last one is very crucial for certificate usage. The certificate is a kind of security token that should be stored and accessed for later use. Therefore, certificate storage API including export and import capability is needed for proper use.



I think this is the another reason why Web Certificate API is needed.



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: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Friday, November 01, 2013 2:42 AM
To: Mountie Lee
Cc: Web Cryptography Working Group
Subject: Re: the reason why we need Web Certificate API


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.