RE: Dedicated CRL signing keys

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

Santosh:

Thanks for posting your summary of the thread.  I hope it will allow us to 
focus on the issues, and reach consensus quickly.

> First, I think that the restriction that a CA who desires to issue 
> Indirect CRL needs to set itself up as a separate name is unduly 
> restrictive.  There is no need for a CA to do that.  A CA can issue a full 
> CRL as well as an Indirect CRL and populate these in the same or different 
> entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509 
> for how to process CRL.  So, may be Russ can explain why this requirement 
> comes about.

I agree that the use of a separate name is overly restrictive.  That 
portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk 
pointed out, CAs cannot change their names when they rekey.

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.

> Second, when we say that a CA may not use different keys for signing 
> certificates and CRLs, we are again not thinking of 
> operations.  Operationally, a CA is going to rekey.  When it does, it will 
> have issued the certificates using the old key and will sign CRL with new 
> key.  There are your different keys.

The simple CA could reasonably expect the CA to generate CRLs using the 
same key that was used to sign certificates until all of the certificates 
signed with that key have expired.

> Also, I think a standard should be flexible and promote security.  From 
> operational security viewpoint, a CA may not want to keep the certificate 
> signing key active all the time, but may need to keep the CRL signing key 
> active to help meet CRL issuance obligations.  This will mean a separate 
> CRL signing key since compromise of that key still does not compromise 
> anything.  The attacker needs to compromise some subscriber keys to create 
> a true compromise, denial-of-service notwithstanding.  Thus, we should 
> accommodate separate keys for certificates and CRLs.

We need to balance the complexity of the software that we expect the 
clients to handle and CA operational security.  Errors in either place will 
lead to vulnerabilities.

> In short, requiring the CA to use a different name to issue indirect CRL 
> is not well-grounded and should be deleted.

Agree.

> Requiring a CA to use different key for indirect CRL is not well-grounded 
> and should be deleted.

I do not recall a discussion on this point.  Usually, Indirect CRLs are 
employed to delegate CRL generation responsibility.  I would expect the two 
authorities to have different keys.

> Requiring the same key for certificate and CRL signing may not be possible 
> due to rekey or operational security requirements and should be deleted.

We need to be pragmatic with respect to simple clients.  I hope that I made 
my thoughts clear above.

> Finally, as to Steve Farrell's question regarding client simplicity, I 
> wish I could answer that.  The client will need intelligence to handle 
> rekey and secure CA who use different keys for certificate and CRL signing.

Again, I hope that I made my thoughts clear above.

Russ