Subject: clarification of CRL processing in RFC3280

From: Julien Pierre <[email-masked]>
Date: Wed, 11 Feb 2004 23:31:45 -0800

Hi,

In section 6.3.3, (b) , RFC3280 states

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indrectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

I am interested in a clarification of the "otherwise" case. What test is 
specifically intended to match the CRL issuer to the certificate issuer ?

(a). matching certificate
(b). matching subject
(c). some other entity matching test, and if so, which one ?

It seems to me that (a) can't be the correct test, since even if DP/IDPs 
are not used, both the certificate being verified and the CRL can still 
contain AuthorityKeyID extensions, therefore making the CRL issuer 
certificate distinct from the certificate's issuer certificate.

(b) seems like a good test to require. This is what NSS does today. But 
I can't help but think that it is not sufficient.
If only the issuer subject matches, then technically the CRL issuer 
certificate and certificate issuer certificate could in fact be 
otherwise totally different, even chaining to different roots. This 
would be similar to the case of indirect CRLs, except without the proper 
extensions. Would that be acceptable under RFC3280 ? Is there something 
else I'm missing, perhaps name constraints, that would invalidate this 
case ? It seems to invite some attacks, which I will describe once I 
know the answer to my inquiry.

(c) Hopefully this is the correct answer. Which is the more 
comprehensive matching test to be used in this case ?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Feb 2004 09:13:28 -0500

Julien:

Let us say that you are checking the revocation status of certificate "X
and you have obtained CRL A (using CDP or other means).  The check is
saying that verify Issue of X == Issuer of A.

This check is helpful when CA has rekeyed and the certificate and CRL are
not signed using the same or if the CA uses different keys to sign
certificates and CRLs.

Few months ago, I pointed out that X.509 and 3280 need to be enhanced
since this check is not sufficient.  Only Denis Pinkas responded to it and
I interpreted his statement as agreement to my proposal.  The checks are
to ensure that the both certification paths (for the certificate in
question and for CRL being checked for it) being with the same trust
anchor issuer/subject name and the names in the two paths match ignoring
self-issued certificates.  The actual text is more precise and appears in
the latest Path Development I-D (on Informational RFC track).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Pierre
Sent: Thursday, February 12, 2004 2:32 AM
To: [email-masked]
Subject: clarification of CRL processing in RFC3280

Hi,

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Feb 2004 10:07:26 -0500

>specifically intended to match the CRL issuer to the certificate issuer ?

If Certificate.extensions.DistributionPoint.cRLIssuer is not present, then
    Certificate.issuer MUST match CertificateList.issuer

>certificate distinct from the certificate's issuer certificate.

The same certificate is not required.  If this were required, then the CA 
would have a very difficult time rolling its signing key.  We need to allow 
the certificate to be signed by the 'old' key and the CRL to be signed by 
the 'new' key.

>(b) seems like a good test to require. This is what NSS does today. But I 
>can't help but think that it is not sufficient.
>certificate and certificate issuer certificate could in fact be otherwise 
>totally different, even chaining to different roots. This would be similar 
>to the case of indirect CRLs, except without the proper extensions. Would 
>that be acceptable under RFC3280 ? Is there something else I'm missing, 
>perhaps name constraints, that would invalidate this case ? It seems to 
>invite some attacks, which I will describe once I know the answer to my 
>inquiry.

Generally, they will be the same certificate.  When two different 
certificates are used, it should be die to the CA signing key being rolled 
over.  To this end, there has been discussion of also requiring the two 
certificates to terminate at the same trust anchor.  What if it is the 
trust anchor that is rolling over its signing key?

Basically, it comes down to an old problem.  One needs to make sure that 
there cannot be two CAs operating with the same distinguished name.

>(c) Hopefully this is the correct answer. Which is the more comprehensive 
>matching test to be used in this case ?

Answered above.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Feb 2004 13:30:22 -0500

Russ:

The proposal is to begin with the same TA issuer/subject name and not with
the same key.

The idea is to ensure that the two certification paths are for the same PKI
hierarchy and the approach is workable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, February 12, 2004 10:07 AM
To: [email-masked]; [email-masked]
Subject: Re: clarification of CRL processing in RFC3280

>I

Answered above.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Feb 2004 16:15:06 -0500

Santosh:

Thanks for filling in the missing detail.

Russ