CMP Problem Statement

[Mountie Lee]

안녕하세요. 이동산입니다.

지난번 Web Crypto KR 회의에서 

조상례 선임님이 알려주신 내용을 바탕으로 W3C Working 그룹에 아래와 같이 메일을 발송하였습니다.

-------------

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 : mou...@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World

[Mountie Lee]

그리고 구글 Ryan으로부터 아래와 같은 답변을 받았습니다.

-------------

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]

Ryan의 코멘트에서 진짜 문제가 뭐냐는 의미를 파악하였고

Problem Statement를 문제기술 정도로 단순하게 생각했다가

Wikipedia의 정의(http://en.wikipedia.org/wiki/Problem_statement)를 살펴보니

조금더 보완해야할 사항이 있는듯합니다.

What is Problem?

=> can not issue certificate via browser native api (이정도가 우리 답변인데요)

==> Ryan의 말은 Javascript으로도 구현이 가능한데 Why Native? 정도로 반문하고 있습니다.

===> Javascript으로 CMP에 의한 인증서 발급을 진행할 수 있다는 말은 어느정도 맞는 말이라고 생각합니다.

===> 인증서 발급에 소요되는 어플리케이션의 무결성을 보장하기 위하여? (이게 답이 될까요?)

===> 인증서 발급을 플러그인 없이 할 수 있도록 하기 위하여? (이건 답변이 안될것 같군요)

===> 왜 JS로도 구현 가능한 CMP를 꼭 Browser native로구현해야하는가? 라는 질문에 우리 자체적으로 답변을 해볼 필요가 있습니다.

Who has the problem?

=> 누가 문제를 가지고있는가? 라는 부분인데요.

=> 한국이나 유럽의 일반 이용자들?(Web Cert API는 인증서 발급 관리에 관련된 문제이므로 사용에 관련된 일반 이용자에게 문제가 생긴다라는 답변이 정확할까요?)

=> 인증기관 (Certificate Authority)! 이게 더 정확한 답변일것 같군요. (그런데 이렇게 답변하면 Native API를 만들어 누리는 수혜자가 너무 적다는 문제제기가 있을까 걱정됩니다.)

What form can the resolution be?

=> 문제 해결방법은?

==> Web Cert API를 채택하여 구현하면 문제가 해결되는가에 대해서 자문자답이 필요해보입니다.

-----------------

이상 내용에 대한 의견 부탁드립니다.