[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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