Re: the reason why we need Web Certificate API

On Thu, Oct 31, 2013 at 5:14 AM, Mountie Lee <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
> E-Mail : 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.