• QualifiedCertificateRequest

• česky | english

Qualified CSR´s (Certificate Request) are necessary for CAcert to be able to provide qualified certificates.

The vendor has to provide a method to deliver unforgeable identification of certificate requests that were generated with a secure private key, which was generated in the SmartCard an can never leave the SmartCard. For example the certificate request could be digitally signed with a vendor key that is integrated in the SmartCard.

We have created a reference-implementation for qualified CSR´s:

http://www2.futureware.at/svn/sourcerer/CAcert/QCSR/ (Subversion Repository)

Here is the description for it:

With "make" you can run through the whole testsysem.

vendor.pl generates or loads the secret vendorkey (vender*.pem). If you delete all the *.pem files before running it, a new vendor key is automatically created. (rm *.pem)

token.pl generates the keypair of the user, extracts the public key, and signs it with the secret vendor key. Then it generates the CSR, with the signature as an additional field in the CSR, called "qcsr".

ca.pl takes the request, extracts the public key and the qcsr field, verifies the signatur, and decides whether it is a valid qualified certificate request, or not.

The task of the SmartCard vendor is now to implement the functionality in token.pl securely in the SmartCard. The implementation will have to be audited (by the CA or an independent auditor), to make sure that the implementation is correct and secure.

The following things are still open and can be changed by the vendor:

• The crypto algorithm (we have chosen RSA here)
• The encoding of the public key (we have chosen PEM encoding from OpenSSL)
• The signature methor (we have chosen the RSA signature from OpenSSL, which normally gives 128 binary bytes as signature)
• The encoding into the qcsr field in the CSR (we have chosen Hex-encoding, since we didn´t found an easy way to do it directly binary)
• The OID for the qcsr field (we have allocated a OID from CAcert

If the vendor wants to change something on the implementation, he must provide a software reference-implementation, that is bit-compatible to the proposed hardware implementation, so that the security can be evaluated. (It will be best, if it is based on our reference-implementation)