CA Key Reuse in Sub CA Certificates with Different Subject Distinguished Names

[Ben Wilson]

Hi,

Is anyone aware whether there is any allowance or prohibition on issuing two subordinate CA certificates (or root certificates, for that matter) to the same key with different Subject DNs? 

It appears that this was considered a possibility if you look at section 4.1 of RFC 2560 (OCSP requests must include an issuerNameHash--even though it also requires the issuerKeyHash), but I can’t seem to find references elsewhere where the practice is allowed or prohibited. 

Maybe we should prohibit the creation of CAs with different DNs using the same key, if we haven't already? Or require one-to-one matching between keys and CA names? Or is there any use case where allowing such practice would make sense?

Thanks in advance,

Ben

[Ben Wilson]

All,

As a follow-up to today's discussion on this topic, here is the situation that my questions aim to address: For purposes of revocation checking, can we be assured that the combination of issuerKeyHash and serialNumber uniquely identify an end entity certificate?  OCSP uses issuerNameHash, issuerKeyHash, and serialNumber, whereas CRLite just uses issuerKeyHash and serialNumber.

At least for end entity certificates, we would like to ensure the uniqueness of issuer keys. Therefore, we would like to propose that section 3.1.5 of the TLS BRs (Uniqueness of Names), or section 7.1.2 of the TLS BRs, state something similar to:

"CAs SHALL NOT issue CA certificates that contain a Subject DN that is known to be used in another CA certificate with a different public key."

If we wanted to go further and ensure a one-to-one relationship between CA names and public keys, then we could also say, "Each subject DN in a CA certificate SHALL be uniquely associated with a single public key, and each public key in a CA certificate SHALL be uniquely associated with exactly one subject DN."

Thanks,

Ben

[Ben Wilson]

All,

Wendy Brown noted that some of the language might prevent CA key rollover. Alternative language that might avoid this consequence is

"CAs SHALL NOT issue CA certificates that contain a public key that is known to be associated with a different subject DN in another CA certificate." 

Ben