Subject: Qualified Certificate Requests - RFC

From: Philipp Gühring <[email-masked]>
Date: Tue, 2 Aug 2005 22:13:55 +0200

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:46:46 +0200

Hello,

> The PEM format for OpenSSL is not standard by any means, the DER format
> is equivalent to the SubjectPublicKeyInfo format which is standard (its
> is used in certificates).

Ok, then I will try to switch to that format.

> In fact since the aim seems to be to sign one public key (which resides
> on a smart card) with another (certifying it is on a smart card) and
> possibly include additional parameters why not just do this with a
> standard certificate?

Good question, thank you!

* There is no "identity" attached to the public key, at the point of time, 
where the CSR is generated.
* I want to reuse the normal Certificate Request workflow with PKCS#11, 
browsers, and CSR´s, the <keygen> integration in the browsers and the HTTP 
based communication with the CA.
* I don´t want difficult to secure out-of-band communication (having to 
transport the raw certificate additionally to the CSR for the real 
certificate)

So I think I need an additional field in the CSR.

At the beginning of the project, I thought that it would be necessary to sign 
the whole CSR, so I would need an external signature, and could not send it 
in the normal certificate request. (Which would have meant, that I would have 
to redesign the whole communication.) 
Then I had the good idea, that a signature of only the public key would be 
enough, and that I could put the signature into the CSR itself.

I have to make sure that the generated private key is in the smartcard. Since 
the generated public key determines the private key, it is enough to sign the 
generated public key.
I also thought about a secret-key signing system, which could be 
computationally easier, but then the CA would have to keep it secret, and a 
secret key couldn´t easily be shared between several CA´s, all trusting the 
same vendor´s tokens.

Regards,
Philipp Gühring

---

From: Philipp Gühring <[email-masked]>
Date: Wed, 3 Aug 2005 23:52:25 +0200

Hi,

> I was instead suggesting that an appropriate certificate (or a reference
> to one) is included in the CSR. That is the signature format is a
> certificate, with optional appropriate additional conditions.

Including a certificate as an OCTETSTRING into a CSR?

The more I think about it, the less I like that idea.
* Possibly not enough memory in SmartCards
* unnecessary overhead
* possibly interoperability issues

I am more for the keep it simple stupid method here. Let us find one good and 
simple way, and implement that everywhere.

> The "identity" can be anything appopriate. The subject DN could be empty
> and an appropriate subjectAltName identity used instead which asserts
> something appropriate. This might for example be and encoded version of
> "Foobar smart card manufacturer, FIPS140-2 level 4 card, Serial number
> 1234".

Hmm. Either a card is secure enough for qualified signatures, or not.

I even heard of a concept that had a complex point system for the 
qualification of a signature. You get points for each FIPS level, for 
biometrics, ...

But I think we should keep it as simple as possible.

That´s the only way to get it implemented, I think.

> Doing this has a number of advantages.
>
> It can be used with other signing algorithms, not just RSA.

Hmmm. That´s an interesting point.
On the other hand, if you want to use a different signing algorithm, you will 
likely have to change your hardware, which should be re-evaluated anyway.

And I don´t see a problem in assigning OID´s to every new parameter set.

> The format is already standardised as are mechanisms for verification,
> policy checking and revocation. For revocation consider what would
> happen if the key becomes compromised or inaccessible meaning a new key
> is required.

That means that you can´t use your SmartCard for any new qualified 
certificates then.

I don´t think that the hardware vendor will operate it´s own CA to publish the 
certificates, CRL´s, ...
Do you know any hardware vendor that wants to operate it´s own CA?
So I guess that the CA service for the qualified tokens would have to be done 
by the same CA, being just more work, to operate yet another root ...
The other variant would be to have the auditor operate the CA.
I also doubt that an auditor wants to run a CA. (Altough it would make sense 
to do so)

> In the system you have AFAICS the trust model is for a single RSA key
> which asserts that the key resides on a smart card. In the certificate
> model you can have an appropriate hierarchy which can certify individual
> manufacturers. A verifier then just has to trust a root.

Can´t the RSA key be externally linked in a X.509 or OpenPGP chain?

> Policy processing allows finer control over the asserted features, a
> given policy might assert additional levels of security. For example
> FIPS level 3 or higher.

Yes, it would be nice to have all information inside the request. But I don´t 
see a real need for it.
Do you know any existing policy system, where I can decide which FIPS level 
the card has to minimum have?

Any other opinions on the topic Signature vs. Certificate?

Regards,
Philipp Gühring

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 03 Aug 2005 23:12:11 +0100

> Including a certificate as an OCTETSTRING into a CSR?

Note the "or a reference to one" including a URI where it could be
downloaded would have a smaller overhead.

> That means that you can´t use your SmartCard for any new qualified 

I hadn't seen the full details when I suggested a certificate. Since
I've now seen that the vendor key signs other keys generated on the
smartcard it wouldn't serve the purpose I originally thought.

It could serve a different purpose of certifying vendor keys though: see
below...

> Can´t the RSA key be externally linked in a X.509 or OpenPGP chain?

Ah now that's another issue. Would this "vendor key" be the same on each
smartcard or different for each one? Presumably it would have to be
different for each vendor?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

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

Hi,

> downloaded would have a smaller overhead.

The problem is that the scenario is a normal user requesting a qualified 
certificate. 
The keypair is generated directly before the request is sent. If it were 
generated by the vendor before, it would make sense to put the certs on a 
server. But that´s not the case.
And the request should be processed as fast as possible. I don´t see where a 
normal user has a webserver available, where the PKCS#11 driver or CSP could 
upload the certificate. And I don´t think that the user will be happy doing 
that himself.
So referencing an external certificate is not an option, I would say.

> different for each vendor?

Every vendor has his own key, or a couple of keys, perhaps one for each kind 
of device the vendor produces. Let´s say normally a vendor should have <10 
keys. But definitly not for every single device.

Regards,
Philipp Gühring

---

From: Stephen Henson <[email-masked]>
Date: Thu, 04 Aug 2005 00:29:19 +0100

> So referencing an external certificate is not an option, I would say.

I should've qualified the statement. Its clear now I've read the full
details that a certificate isn't appopriate to sign the public key of a
smart card key. Where it might be appropriate is in signing the vendor's
key for trust purposes, see below.

> keys. But definitly not for every single device.

So how does a CA processing the CSR and vendor key know that it can
trust the vendor's key?

That's a case where I believe certificates could have a role. An
authority could certify each vendor key and the vendor would include
references to this information in the form of a URI on its site.

Steve.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 4 Aug 2005 09:12:47 +0200

Stephen,
Your suggestion seems to be the right way of doing this.

I would though equip each TPM [1] with a unique certificate containing
the device serial number etc.   This has the advantage that a CA may
record this data together with other issuance data making it possible
to trace credential misuses (theft) down to a particular "container".

Regarding the name of the RFC, "Qualified Certificate Request", I would
not associate this with qualified certificates in the EU sense, as TPM
requirements is by no means limited to this particular class of certificates.

Anders Rundgren

1] Trusted Processing Module is becoming the collective term for things
that were previously known as smart card or HSM

----- Original Message -----
From: "Stephen Henson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 04, 2005 01:29
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate

Steve.

---

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

Hi,

> key for trust purposes, see below.

Ok.

> So how does a CA processing the CSR and vendor key know that it can

The vendor has to undergo an audit to proof the security and trustworthyness 
of the system and the vendor´s operations.
That audit can be done by any third party (Common Criteria would be an idea 
here, FIPS certification would be good too), or by the CA itself (to reduce 
the costs).

> references to this information in the form of a URI on its site.

Yes, that´s also possible to use authorities who certify the vendor key.
Anyway, there has to be a relationship between the vendor and the CA, I think. 
An external audit or approval by an authority just helps in that 
relationship, but I wouldn´t suggest to do it anonymously.

I think even the CA has to proof to the authorities that the overall solution 
(both the CA and the SmartCard, ...) is good enough for qualified 
certificates to be issued. So both CA and Vendor might have to be audited 
together by the authority ...

Regards,
Philipp Gühring

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 4 Aug 2005 22:29:19 +0200

TPMs are actually used in contexts outside of trustedcomputingroup (which
I BTW am a member of).  TPMs do not by definition have to be in HW but we
are unlikely to see much SW versions except for reference designs.
A TPM does not by definition have to bolted to a motherboard to perform
useful functions.  That is, TPMs can do many other things than protecting
operating systems including secure crypto operations on user keys in the same
was as typically associated with smart cards and HSMs.

Smart cards OTOH is not only an soon-to-be obsoleted technology, but also
a meaningless term, as "smart" does not say anything about its functionality.
Sounds more like a marketing phrase to me.  

It takes a NIST, GSA and a DoD to come up with "smart" card readers for $234:
http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_detail-83.html
when a TPM-based scheme will soon be for free and add zero weight to a mobile unit.
In addition to supporting a magnitude more use cases than a discrete card is able to.

Regarding the privacy issue with binding certs to TPM IDs including
serial number, the comparison with Intel's removed CPU number
is pretty flawed as the binding in the former case is only known by the CA
while the in the Intel case, more or less any program could read and use this
information.  In case you have a privacy issue also with the CA, I suggest
that you run it yourself.

/anders

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 04, 2005 09:40
Subject: Re: Qualified Certificate Requests - RFC

>that were previously known as smart card or HSM

More accurately, TPM is a reference to a set of hardware functions 
that are intended for inclusion in general purpose computers, as 
defined by the Trusted Computing Group 
(www.trustedcomputinggroup.org/home). Smart cards and most HSMs would 
not qualify under this more precise use of the acronym.

Also note that the creation of a cert bound to a device serial 
number, at least for PCs, is precisely the sort of concept that got 
Intel a lot of bad PR a few years ago.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Aug 2005 15:36:59 -0400

Anders,

You may choose to redefine terms in your circle of friends, but for 
purposes of the list let's stick with terms that are widely accepted. 
In this case, the term has a meaning relevant to the PKI context, and 
it is not the one you espouse.

Steve