Re: Path Discovery Test 4.1.1.3

["David A. Cooper" <david.cooper@nist.gov>]

Steven Madwin wrote:

> Is it normal practice when you issue two certificates for separate 
> purposes (one that signs the end-entity and the other for signing the 
> CRL) to have identical Key Usage?  I would think that if you are 
> issuing two certificates (especially if they have identical DNs) that 
> they should have unique Key Usage values. I'd appreciate to hear what 
> anyone thinks on the subject.

Steve,

At the moment, I think it is very rare for a CA to generate two 
different key pairs with one only being used to sign certificates and 
the other only being used to sign CRLs.  But if a CA were to do so, then 
I think that the certificate certifying the certificate verification key 
should only assert keyCertSign and the certificate certifying the CRL 
signing key should only assert cRLSign.  One reason that a CA may wish 
to use two different keys is if the certificate signing module is kept 
off-line and is only turned on infrequently but there is still a need to 
issue CRLs regularly.  By using two different keys are only asserting 
the necessary keyUsage bits in each certificate, an attacker who 
compromises the on-line CRL signing key cannot generate bogus certificates.

Currently, the most likely reason that a scenario such as the one in 
test 4.1.1.3 would occur is if the subordinate CA had performed a key 
rollover and is using its new key pair to sign newly generated 
certificates and CRLs, but there are still valid certificates that were 
signed with the old key pair.  The certificate issued by the superior CA 
to the subordinate CA's old public key would assert both keyCertSign and 
cRLSign since the old key was being used for both purposes at the time 
the certificate was issued and the certificate issued to the new public 
key would assert both key usages since the new key is currently being 
used for both purposes.

Test 4.1.1.3 could have been designed to mimic the case in which a CA 
uses different keys pairs for certificate and CRL signing rather than 
mimicking key rollover, but I was worried that that would make path 
discovery more complicated.  If the certificate with the subject public 
key used to verify the CRL signature only asserted the cRLSign bit then 
that certificate should either not include a basicConstraints extension 
or if the extension were present, the cA flag should be set to false 
since X.509 states that the cA flag "indicates if the certified public 
key may be used to verify certificate signatures."  However, in order 
for a version 3 certificate to be stored in the cACertificate or 
crossCertificatePair attribute of the directory, it must include a 
basicConstraints extension with cA set to TRUE.  So, a certificate that 
asserted only cRLSign would need to be stored in the userCertificate 
attribute of the directory.  While there is nothing technically wrong 
with this, I would guess that many applications would be looking for the 
certificate in the cACertificate and/or crossCertificatePair 
attributes.  I will likely include a test at the Intermediate or 
Advanced level in which the certificate holding the key needed to verify 
the CRL signature is stored in the userCertificate attribute, but I did 
not think such a test belonged at the Rudimentary or Basic level, so I 
got around the problem by that any certificate that asserted cRLSign 
also asserted keyCertSign (and included a basicConstraints extension 
with cA set to TRUE).

Dave