This problem has been pretty well-researched, but not much published since the research has been associcated with specific applications and not across broader PKI deployments.  Much of the research was associated with the SET application so didn't make it out of the bank card associations beyond their security requirements (and then only vaguely suggested).

To summarize my own work, it is inappropriate to issue two certs with the same public key with overlapping validity periods.  In the event of key comprimise or unauthorized key usage problems, both certificates are impacted even though only one would be listed on a CRL.  The integrity of the CA associated with a CERTIFICATE hierarchy would be in question but the overall use of the key across all hierarchies using eh keys would be in question.  Its also best practice to gen new keys and not re-use keys after a certificate has expired.

Audit of single key usage associated with multiple certificate hierarchies is also a problem.

Best practice is to gen a new key pair and create a separate cross-certified hierarchy so that there are unique keys tracked independently.  This just solves a lot of problems with key usage and audit.  There is no impact on any hierarchy if the keys are retired for any reason. 

I agree with the feature of OpenCA that disqualifies multiple certificates associated with the same public key.

Bill

Pierre Scholtes wrote:

Hi

I'm trying to do the following:

I issued a cross-certificate on RootCA1 for RootCA2 and set the extended key usage field to emailProtection. When I now use this crosscertificate to build a certificate chain, I can only verify emailProtection certificates (that's perfect and just what I wanted, restrict what certificates I want to accept from the cross-certified domain)

Now my next step is to issue a second cross-certificate on RootCA1 to RootCA2 but set the extended key usage field to clientAuth and serverAuth, so that users that use this cross-certificate can only verify ssl certificates coming from the cross-certified domain. So depending on the cross-certificate I give to my users I can restrict who can verify what certificates.

But here comes the problem: when trying to issue the second cross-certificate, RootCA1 (openCA)  tells me that there already exists a certificate with this public key and that this will result in a key compromise. This is what I don't understand: there is no key compromise as long as the subject to whom the public key belongs is the same in the 2 certificates (or am I wrong here).
 Is it correct that openCA never lets you issue 2 certificates for the same public key:subject pair?

Isn't it possible to check whether the subject in the existing certificate is the same than the one requesting the new certificate and then issue the second certificate.
I really need 2 (or may be more) cross-certificates to restrict what group of users can verify what type of certificates.

Thanx for any reflections
Pierre

PS: Is it right that openCA does not support any naming or policy constraints in cross-certificates (because of openssl not supporting them)?

_________________________
Pierre Scholtes
Unicible

tel: +41 (0)21 644 6111
fax: +41 (0)21 644 6300
mailto:[EMAIL PROTECTED]
http://www.unicible.ch

Reply via email to