Subject: RE: AW: Qualified Certificate Requests - RFC

From: "Schwebler, Hans-Peter" <[email-masked]>
Date: Wed, 3 Aug 2005 11:25:06 -0400

Phillip,

Nothing is wrong with this concept but it's not new.  You need to pay
attention to the different keys, though.  If you want to be able to
determine that the certificate request was signed by a specific smart card,
then the number of manufacturer keys is huge.  

The concept, as far as I am aware of, was developed by TC TrustCenter (they
are an accredited CA in Germany).  The concept was implemented with one of
the major HSM vendors.  I don't know which one but it might be Eracom.

Best regards,
Hans-Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Philipp Gühring
Sent: Wednesday, August 03, 2005 10:58 AM
To: [email-masked]
Subject: Re: AW: Qualified Certificate Requests - RFC

Hello,

> 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.

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

---

From: Philipp Gühring <[email-masked]>
Date: Thu, 4 Aug 2005 00:42:45 +0200

Hans-Peter,

> Nothing is wrong with this concept 

Thanks.

> but it's not new.   

I already heard about several similar concepts:
* One complex one from Novell with a point system (abandoned, too complex)
* TPM (it could be compatible)
* IBM HSM (not officially documented)
* The first generation of Crypto iButtons (before they used Java)
* Fortezza Cards (I didn´t found information about it, but I guess that I do
   not need it anymore)

The technical model behind is not new, obviously.

But most of them are overly complex, and there is no standard way for doing 
it.
But we need a standard method now for qualified certificates, that can be used 
by all the vendors (SmartCards, HSM´s, TPM´s, other Tokens)

And we need to integrate it into the standard software now.

> You need to pay 
> attention to the different keys, though.  

What exactly do you mean?

> If you want to be able to 

No, I just need to make sure that it comes from a secure smart card. I don´t 
care, which one. (And I don´t want to know which one)

> the major HSM vendors.  I don't know which one but it might be Eracom.

Thanks for the information, I´ll ask them both about it.

Regards,
Philipp Gühring