RE: Dedicated CRL signing keys

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

Russ,

I have a problem with the idea that we need to include a critical extension in any CRL where some of the certificates covered by that CRL were signed using a different key than the one used to sign the CRL.

The main problem that I see is the CA rekey issue. Suppose that a CA rekeys and then issues a single CRL, signed with its new private key, that covers all of its unexpired certificates. The older certificates issued by this CA will have been signed with the old key, but the newer certificates will have been signed with the same (new) key as the CRL. As things stand at the moment, simple clients will be able to use the CRL when validating the "new" certificates and will fail when using the CRL to validate "old" certificates. If we place a critical extension in the CRL that the simple clients can not process, then they won't be able to use the CRL to validate any certificates. So, adding a critical extension would actually reduce the functionality of simple clients.

I also believe that there is already sufficient information available in the CRLs. A client can simply compare the authority key identifier in the certificate and the corresponding CRL. If they differ, the client will know that the certificate and CRL were signed using different keys and can return an "unsupported feature" error just as if the CRL contained an unrecognized critical extension.

Right now, simple clients will return an error if a certificate and its corresponding CRL were signed using different keys. Simple clients that want to provide an "unsupported feature" error message instead of "signature invalid" can compare authority key identifiers in order to determine which error message to return. If we force the CRLs to include critical extensions, we will be unnecessarily increasing the number of cases in which simple clients are unable to validate CRLs. So, I think we should leave things as they are.

Dave 

At 04:21 PM 4/23/01 -0400, Housley, Russ wrote:
>I think that everyone agrees that a CA makes a commitment to provide some form of revocation information for the duration of the certificate life.  When CRLs are employed, does the CA use the same key to sign the CRL as was used to sign the certificate?  Clearly, the CA is permitted to use different keys -- the key usage bits are there to allow this separation.  However, several clients cannot handle this situation, and they would like to see an error message that says "unsupported feature" instead of "signature invalid."
>
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are subsequent CRLs signed with the new key or the old one?  A CA could generate one CRL with each key.  They two CRLs could even be distributed by different distribution point to avoid the download of CRLs that cannot be employed.  Alternatively, the CA could publish one CRL signed with the new key.  This leads to the scenario where cert path construction must be evoked to generate validate the CRL when trying to validate a certificate signed by the old key.  This is the behavior that we are trying to make SHOULD.
>
>Therefore, the CA MUST generate the CRL using the same key as was used to sign the certificate, or it MUST include an extension in the CRL to indicate that cert path construction might be needed to validate the CRL signature.  I proposed that an Issuing Distribution Point (IDP) CRL extension might be the correct approach.  The IDP extension will not be supported by the simple clients, so they can generate the "unsupported feature" error, and the more complex clients can use the information in the IDP to support path construction.  They will of course, also use Authority Key Identifier extension.