Subject: CRL Issuer Name = Subject name from crl signer cert?

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 04 Jun 2003 15:27:04 +0200

Hi.

I have a question regarding the naming scheme for CRLs. Consider the
following:

EE certificates are issued by a CA, Issuer-DN "CA1". 

The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
Subject-DN "CA1", serialnumber "1". 

The CA issues CRLs, and signs them with a CRL certificate wich was also
issued by a root CA, but with another distinguished name than the main
CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"

Is an RFC 3280 compliant client supposed to be able to process the CRLs
if the CRL Issuer-DN is set to "CA1" and the CRL contains an
AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
"CRL1"?

Is this scheme, where the issuer name from CRL does not match Subject DN
from CRL signing certificate, covered by step f) from chapter 6.3.3 from
RFC 3280?

 "f) Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set."

Regards,
   Juergen

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 Jun 2003 13:30:37 -0400

Juergen,

What you are describing below is an indirect CRL, a CRL that covers 
certificates issued different entity.  (I know you stated that same CA 
issues both the certificates and the CRL, but since the issuer names are 
different, they are considered different entities.  Furthermore, there 
is no way for a relying party to know whether the certificate issuer and 
CRL issuer are the same entity).

Usually, a CRL can not be used to determine the status of a certificate 
unless the certificate and CRL both have the same issuer name.  The 
value of the AKI extension does not matter, as it is only a hint that 
can aid in building paths and in selecting the right CRL.

In order to allow a relying party to use a CRL to determine the status 
of a certificate where the issuer names differ, you need to do the 
following:

1) Each certificate issued by "CA1" must include a cRLDistributionPoints 
extension with a cRLIssuer field that indicates that "CRL1" is the CRL 
issuer.

2) The CRLs issued by "CRL1" must include an issuingDistributionPoint 
extension with the indirectCRL flag set to TRUE.

3)  If any of CA1's certificates have been revoked, the 
certificateIssuer CRL entry extension must be used within the CRLs 
issued by "CRL1" to indicate that list of revoked serial numbers are of 
certificates issued by "CA1" (see RFC 3280 for details on the use of 
these three extensions).

While the rules for issuing and processing indirect CRLs are specified 
in RFC 3280, RFC 3280 compliant clients are not required to be able to 
process indirect CRLs.

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 11 Jun 2003 12:40:32 +0200

David,

It has been a long time since we exchanged e-mails on delta CRLs. :-)

> certificates issued by "CA1" (see RFC 3280 for details on the use of 

While what is above is true, I wonder that is the *only* case "to allow a 
relying party to use a CRL to determine the status of a certificate where 
the issuer names differ".

In particular, if CDP are *not* used, then it is still possible to have a 
CRL issuer.

RFC 3280 states:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

    CRL issuers issue CRLs.  In general, the CRL issuer is the CA.
    CAs publish CRLs to provide status information about the certificates
    they issued.  However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

The wording may be confusing. A CRL issuer name is a name that is different 
from the name of the CA. However, since the CA may delegate the publication 
of the CRLs to a CRL issuer, is it still the CA or a CRL issuer ? I would 
think the later.

    Whenever the CRL issuer is not the CA that issued the certificates,
    the CRL is referred to as an indirect CRL.

I wonder whether the wording indirect CRL is fine, since it has a different 
meaning in section 5.2.5  Issuing Distribution Point.

    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
    the CRL includes certificates issued by authorities other than the
    CRL issuer.

The indirectCRL boolean flag is something that may be present or absent in 
what is currently called a indirect CRL. A little bit confusing. A change or 
a clarification would be apropriate.

> in RFC 3280, RFC 3280 compliant clients are not required to be able to 

Section 6.3 CRL Validation is almost silent on how to determine that the CRL 
is the right one, in particular when the CRL issuer name is different from 
the CA name and when no CDP is being used. The only guidance is:

" (f)  Obtain and validate the certification path for the complete CRL issuer."

I would assume that this means find out a certificate issued by the CA which 
has issued the certificate to be tested and which includes the cRLSign bit 6 
in the keyUsage extension. Then, use that certificate to validate CRLs that 
seem to be originating from that CRL issuer name.

It would be useful to include such additional information in a revised 
version of RFC 3280.

    Conforming applications are NOT
    REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
    with a scope other than all certificates issued by one CA.

Conforming applications are certainly not required to be able to process the 
indirectCRL boolean, when CDP are being used. What does mean however mean 
"not required to processing of indirect CRLs" in case the CA nominates a 
single CRL issuer ?

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 11 Jun 2003 09:36:06 -0400

Denis,

I believe that RFC 3280 is quite clear on this issue.  If the 
certificate does not include a cRLDistributionPoints extension with 
cRLIssuer present, then the CRL used to determine the certificate's 
status must have the same issuer name as the certificate:

    6.3.3  CRL Processing

       For each distribution point (DP) in the certificate CRL distribution
       points extension, for each corresponding CRL in the local CRL cache,
       while ((reasons_mask is not all-reasons) and (cert_status is
       UNREVOKED)) perform the following:

          (a) ...

          (b)  Verify the issuer and scope of the complete CRL as follows

             (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.

       ...

       If the revocation status has not been determined, repeat the process
       above with any available CRLs not specified in a distribution point
       but issued by the certificate issuer.  For the processing of such a
       CRL, assume a DP with both the reasons and the cRLIssuer fields
       omitted and a distribution point name of the certificate issuer.
       That is, the sequence of names in fullName is generated from the
       certificate issuer field as well as the certificate issuerAltName
       extension.

So, if the cRLDistributionPoints extension is absent, revocation status 
must be determined as specified in the final paragraph of 6.3.3 which 
states that the CRL issuer and certificate issuer must match (this is 
stated in the first sentence and backed up in the second sentence which 
states that the CRL should be processed as if the certificate included a 
CDP with the cRLIssuer field absent).  Step (b)(1) states that if the 
cRLIssuer field is absent, the certificate and CRL issuer names must match.

Dave

Denis Pinkas wrote:

>> certificates issued different entity.  (I know you stated that same 
>> CA issues both the certificates and the CRL, but since the issuer 
>> names are different, they are considered different entities.  
>> Furthermore, there is no way for a relying party to know whether the 
>> certificate issuer and CRL issuer are the same entity).
>>
>> Usually, a CRL can not be used to determine the status of a 
>> certificate unless the certificate and CRL both have the same issuer 
>> name.  The value of the AKI extension does not matter, as it is only 
>> a hint that can aid in building paths and in selecting the right CRL.
>>
>> In order to allow a relying party to use a CRL to determine the 
>> status of a certificate where the issuer names differ, you need to do 
>> the following:
>>
>> 1) Each certificate issued by "CA1" must include a 
>> cRLDistributionPoints extension with a cRLIssuer field that indicates 
>> that "CRL1" is the CRL issuer.
>>
>> issued by "CRL1" to indicate that list of revoked serial numbers are 
>> of certificates issued by "CA1" (see RFC 3280 for details on the use 
>> of these three extensions).
>
>
> While what is above is true, I wonder that is the *only* case "to 
> allow a relying party to use a CRL to determine the status of a 
> certificate where the issuer names differ".
>
> In particular, if CDP are *not* used, then it is still possible to 
> have a CRL issuer.
>
> RFC 3280 states:
>
> The wording may be confusing. A CRL issuer name is a name that is 
> different from the name of the CA. However, since the CA may delegate 
> the publication of the CRLs to a CRL issuer, is it still the CA or a 
> CRL issuer ? I would think the later.

A CA may delegate CRL issuing, but must use the cRLIssuer field of the 
cRLDistributionPoints extension to indicate that it has done so.

> I wonder whether the wording indirect CRL is fine, since it has a 
> different meaning in section 5.2.5  Issuing Distribution Point.
>
> The indirectCRL boolean flag is something that may be present or 
> absent in what is currently called a indirect CRL. A little bit 
> confusing. A change or a clarification would be apropriate. 

If the indirectCRL flag is absent, then the CRL is not an indirect CRL.  
If the indirectCRL flag is not set to TRUE, then the CRL may only covers 
certificates issued by the CRL issuer.  Such a CRL is not an indirect CRL.

>
>> While the rules for issuing and processing indirect CRLs are 
>> specified in RFC 3280, RFC 3280 compliant clients are not required to 
>> be able to process indirect CRLs.
>
>
> Section 6.3 CRL Validation is almost silent on how to determine that 
> the CRL is the right one, in particular when the CRL issuer name is 
> different from the CA name and when no CDP is being used. The only 
> guidance is:
>
> I would assume that this means find out a certificate issued by the CA 
> which has issued the certificate to be tested and which includes the 
> cRLSign bit 6 in the keyUsage extension. Then, use that certificate to 
> validate CRLs that seem to be originating from that CRL issuer name.
>
> Conforming applications are certainly not required to be able to 
> process the indirectCRL boolean, when CDP are being used. What does 
> mean however mean "not required to processing of indirect CRLs" in 
> case the CA nominates a single CRL issuer ?
>
> Denis
>
>
>> Dave
>>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 11 Jun 2003 16:22:18 +0200

David,

Thank you for this very prompt response.

>        but issued by the certificate issuer.  

This text only mentions the case of a CRL issued by the CA, not the case of 
a CRL issued by a CRL Issuer nominated by the CA. So implicitly the case of 
a CRL issuer without a CDP does not exist.

 >        For the processing of such a

> cRLIssuer field is absent, the certificate and CRL issuer names must match.

Thank you for the clarification. This answers my main question.

So I understand, when no CDP is being used, that different keys can still be 
used for cert signing and CRL signing, as long as the CA name is the same.

A minor point: in section 5.2.5 Issuing Distribution Point we still have:

Certificates are NOT issued by CRL issuers. Isn't there some typo here ?

Denis