Re: the reason why we need Web Certificate API

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> wrote:

>
> 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.
>



-- 
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