Deliverable web certificate API

Use Case and Requirement for Future Work

Korean banking use case and requirements for future work that is derived from the prototype implementation [presentation]

Key Ownership

current design principle of Web Crypto Low Level API is based on that the key ownership is belong to provisioner (normally servers). before taking more steps for certificate, we have to clarify the key ownership.

certificate mechanism has three entities.

• the certificate key pair (certificate + private key)
• the certificate authority
• the servers

certificate will be issued to client or user (not for servers) and certificate authority itself is the trusted third party.

if we deploy the same origin policy on certificate mechanism, some conflicts will be occured.

• certificate authority has no room in SOP mechanism because it is 3rd party.
• if the certificate key pair is owned by server, the CA have to issue the cert to server by Proof of Possession concept. this is second conflict.
• hardware token or other secure elements will have conflict on SOP and key ownership of certificate key pair.

if the certificate key pair is owned by user, many conflicts will be solved naturally.

• key owner have the privilege using MY KEY on any web servers (SOP solved)
• if the certificate key pair is stored on secure elements(for example, hardware token), the key ownership principle match the real fact (token is in user's pocket).
• the CA has room to operate certificate management as trusted 3rd party.

Certificate and SOP exception

to give key ownership, we can apply following technical solutions

• if the certificate is valid(issued from trusted CA, not expired, not revoked), allow SOP exception
  • for SOP exceptions, we can consider CORS
• get user consent (password, hardware token with pin, biometric) when the private key is bound to valid certificate.

Problem statement

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.

Current working draft

The current working draft is in here.

This is the version that was presented in concall held on 14th Oct. 2013.

First working draft

The first working draft is in here.

This is the version that was presented in WebCrypto F2F meeting held on 24th April 2013.