Russ:
But the semantics of that extension does NOT mean that the CRL is signed by a different key.
Actually, a CA typically uses this extension, chops up the CRL and signs them all using the SAME key.
-----Original Message-----
From: Housley, Russ [<mailto:rhousley@xxxxxxxxxxxxxxx>mailto:rhousley@xxxxxxxxxxxxxxx]
Sent: Tuesday, April 24, 2001 3:11 PM
To: Santosh Chokhani
Cc: Santosh Chokhani; ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys
At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:
> >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?)
The IDP syntax is:
issuingDistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE }
I was simply suggesting that this extension be present if the CRL is signed with a key other than the one used to sign the certificate. I would expect the distributionPoint field to be present (probably with a URL (ldap://...)). The boolean flags would be set based on the contents of the CRL (probably all FALSE). The reason codes would also be set based on the contents of the CRL (probably absent).
Russ