Russ:
See comments in line
-----Original Message-----
From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx]
Sent: Monday, April 23, 2001 4:21 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys
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.
{Santosh Says: Item 1 will require a change to the IDP extension syntax. Would n't that make PKIX non-compliant with X.509?)
>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.
(Santosh Says: That is what I have been advocating. But, mandating that a CA retain old private keys and issue multiple CRLs may be excessive.)
>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.
(Santosh Says: But there is nothing in X.509 that a designated CA can not issue its own regular CRL and issue an indirect CRL for its peers. The designated CA may use the same key. The requirement you are levying has marginal benefit for the directories and clients who do not do multi-valued attributes and that only if the CA does NOT use a CRL DP for the indirect CRL. There is no particular need or requirement for having a separate name or a separate key)
>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.
(Santosh Says: I think the best engineering solution is for the CA to keep the old keys and sign multiple CRLs. That said, I do not want to mandate it and I for sure want the PKIX community to approve the RFC knowing this implication.)
>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