Subject: AW: Qualified Certificate Requests - RFC

From: [email-masked]
Date: Wed, 3 Aug 2005 16:01:32 +0200

Philipp,

how do you imagine a "qualified CSR"? The problem is, that a CA must get a
prove that the CSR is generated by a smartcard or an HSM and not by a peace
of fake software.
Until now, IMHO, there's no feasible concept to prove that.

Best Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]]Im Auftrag von Anders Rundgren
> Gesendet: Mittwoch, 3. August 2005 15:11
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: Qualified Certificate Requests - RFC
> 
> 
> 
> Hi Philipp,
> 
> <snip>
> >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.
> <snip>
> 
> You mean that MSFT would dump their 
> proprietary Xenroll scheme? That is a hard sell.
> 
> Although I don't see 
> much vendor interest in this area at all[1], I believe that an XML-
> based "certgen" browser object triggered by a specific 
> MIME-type would 
> be considerably better than improving an outdated ASN.1 based 
> pkcs #10 
> scheme driven by arbitrary amounts of Javascript and ActiveX code. 
> 
> regards
> Anders Rundgren
> 
> 1]  In spite of the fact that web-browser-
> based on-line signatures are MUCH more used (and useful) than 
> signed e-
> mail, no browser vendor or standardization organization have to date 
> publicly not even mentioned the possibility of a standard.  There are 
> virtually HUNDREDS of proprietary signature schemes in use, including 
> the Austrian bürgerkarte scheme:  http://www.buergerkarte.at
> 
> 
>

---

From: Philipp Gühring <[email-masked]>
Date: Wed, 3 Aug 2005 16:58:27 +0200

Hello,

> Until now, IMHO, there's no feasible concept to prove that.

My concept is the following:

First the SmartCard vendor generates a public/private keypair, the so-called 
vendorkey.

When the SmardCard (or HSM) is manufactured (or initialized), the private 
vendorkey is burnt into the SmartCard.
The SmartCard has to enforce two things:
  The private vendor key can´t leave the SmartCard
  The private vendor key can only be used to sign public keys, for which the 
corresponding private key´s were generated in the SmartCard, and are also 
securely stored in it.

The SmartCard (and it´s vendor) has to be audited (by a third party auditor, 
or by the CA).
When the audit succeeds, the CA approves the public vendorkey for qualified 
certificates.

Now the user buys the SmartCard.

Then the user let´s the SmartCard generate a User-Keypair.
The SmartCard signs the user´s public-key with the vendor´s secret key.
The software requests both the user-public key and the signature of the users
´s public key from the Smartcard.
The software generates a certificate request for the User-Keypair, and 
includes the signature as a extension (or attribute) in the request.

The certificate request is sent to the CA in the normal way.

The CA detects the qualification signature, verifies it against the public key 
of the vendor, and if everyhting matches, the CA can issue a qualified 
signature.

Anything wrong in that method?

Regards,
Philipp Gühring