RE: Dedicated CRL signing keys

[Nada Kapidzic Cicovic <nada@xxxxxxxxxxxxx>]

At 05:45 PM 4/23/01 -0400, David A. Cooper wrote:
> 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.

This is my viewpoint exactly. I agree with Dave's reasoning.

Nada



> 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.