Re: the reason why we need Web Certificate API

On Tue, Nov 5, 2013 at 2:38 AM, 조상래 <sangrae@etri.re.kr> wrote:

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

This is not a good argument, nor what I asked for.

The first demonstration of a problem is "Can you polyfill it". If not, what
is needed. If so, then we can explore the actual deployment of those
polyfills on the Web, and look as to whether it SHOULD be brought into the
browser.

To see how this works, just look at how selectors from libraries such as
Prototype and jQuery eventually made it into the DOM, even though they were
polyfillable.

However, when you are starting from scratch, there's no reason to try to
shove something into the browser "just because"


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

See above

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

I'm sorry, you've not stated any technical requirements here, so I cannot
respond.


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

There is no other API (to my knowledge) that seeks to provide, as a
guarantee, the ability to store data in one browser and retrieve it from
another. Please realize this is an incredibly high bar you're asking for.

>  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'm sorry, perhaps it's a language barrier, but I do not feel you've
responded in a way that allows us to make forward progress here. This seems
to be much of a restatement of previous claims, without examining the
polyfill aspect.

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