Subject: Re: Qualified Certificate Requests - RFC

From: Anders Rundgren <[email-masked]>
Date: Wed, 3 Aug 2005 10:11:08 +0200 (MEST)

Hi,

Most QCs are probably manufactured in closed processes making 
standards less applicable.

For on-line generated and distributed 
certificates, practically the entire process is currently non-standard, 
beginning with browsers.   Few on-line certificate systems therefore 
use the browser stuff and have introduced their own proprietary 
methods.  These methods typically also address PIN-code policies, 
something which seems to be missing in PKCS #10.  The 
OpenMobileAlliance have created additional standards but I don't think 
these have much acceptance by browser vendors.

Anders Rundgren

----
Original Message----
From: [email-masked]
Date: Aug 2, 2005 10:13:55 
PM
To: [email-masked]
Subj: Qualified Certificate Requests - RFC

Hello,

I have been reading through the PKIX archive, and found a lot 
of interesting 
material on the topic of qualified certificates.

But 
what I am completely missing is the necessary foundation of qualified 
certificate requests.

Regarding the requirements for qualified 
certificates, the only obstacle I 
currently have is the problem, that 
I have to make sure, that the private key 
for the certificate is 
generated and stored securely in a SmartCard, or 
another Hardware 
Token.

Since the users should be able to issue the certificates at 
home, I need a 
technical solution to make sure, that the private key 
is from within a 
SmartCard, when we receive a certificate request.

Therefore I designed "Qualified Certificate Requests", which 
cryptographically 
signs the public key in the CSR with a vendor key, 
to state that it comes 
from a secure device.

Now I created a software-
based reference implementation, so that the security 
of the system can 
be evaluated, and that the Token Vendors can see how to do 
it, and can 
do interoperability testing:

http://www2.futureware.
at/svn/sourcerer/CAcert/QCSR/
 
The following parameters 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 method (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 (I have 
chosen Hex-encoding,
     since I didn´t found an easy way to do it 
directly binary yet) 
  The OID for the qcsr field (we have allocated a 
OID range below our range
     for all QCSR OID´s. Feel free to contact 
me if you want an OID for your
     parameters)

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

Should qualified certificate requests be documented in 
a own RFC, or added to 
the Qualified Certificates RFC?

Regards,
Philipp Gühring

---

From: Philipp Gühring <[email-masked]>
Date: Wed, 3 Aug 2005 10:50:36 +0200

Hi,

> standards less applicable.

Yes, and the reason for that is that there are no qualified certificate 
requests yet.
Having no QCSR´s makes it expensive for the manufacturing process, and 
impossible for QC creation at home.

If it is just an standardized, additional field in the CSR´s, then it should 
be easy to adopt for browser vendors, smartcard vendors and CA´s.

Overall it makes it possible to create it at home, and the manufacturing 
process will be cheaper. Vendors will produce standard "Qualified 
SmartCards". For the Browser vendors it will be a short amount of additional 
code, that I will try to offer them as easy to apply patches for their code.

Ah, good that you remind me, I haven´t worked out the PKCS#11 and CSP 
integration yet.

> beginning with browsers.

Yes, non-standard and therefore unnecessary costly.

> Few on-line certificate systems therefore 

Thanks. I´ll take a look at it.

Regards,
Philipp Gühring

---

From: "Julian Inza" <[email-masked]>
Date: Wed, 3 Aug 2005 11:48:11 +0200

Hello friends,

I completly support the position of Mr. Philipp Gühring

By the way, I have been acting as special Registration Authority Support 
Expert in order to assure in the registration process of a Qualified 
Certificates Issuer CA that a specific certificate request has been 
generated inside of a secure signature creation device.So I can atest that 
this specific need exists.

This is not only the case of smartcards but also of Hardware Security 
Modules when qualified certificates are managed in behalf of a legal 
persons.

Things would be a lot easier if the request could be backed by a device 
signature.

Best regards,

_____________________________________________________
-Julián Inza (mailto:[email-masked])
-President
-Interactiva (http://www.interactiva.com.es)

This e-mail message could contain CONFIDENTIAL INFORMATION  property of 
Albalia Interactiva. If received by mistake, please ignore it, delete it and 
notify the sender. Your personal information can be added to a relationships 
file (that can include marketing information) at Albalia Interactiva where 
you can exercise your rights to access, rectify or cancel your data 
according spanish 15/1999 Organic Law (Act). You are authorised to use 
personal data of the signer of this message as long as there is a way to 
exercise the mentioned rights by the signer.
_____________________________________________________