Subject: [pkix] Binding between CRL and DP.

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 15 Jun 2010 13:35:03 +0100

A recent discussion on an OpenSSL mailing list caused me to revisit the RFC5280
CRL algorithms.

This was prompted by mentioning a CA which partitions CRLs according to serial
number, including an appropriate DP in the EE certificate but does not include
an IDP extension in the CRLs.

So for example serial numbers 1..99 might have http://foo.bar.com/CRL1.crl
100..199 http://foo.bar.com/CRL2.crl and so on.

My thoughts are that this is at best troublesome and at worst non-compliant and
insecure. For example suppose an attacker with a revoked certificate intercepts
CRL download (if it uses http) and replaces CRL1.crl with CRL2.crl. Their
revoked certificate will appear on CRL1.crl but not CRL2.crl and so will appear
valid after the substitution because there is no way to detect the substitution.

An alternative scenario is where CRLs are included with a structure: for example
S/MIME signedData, again substituting an out of scope CRL is possible.

If IDP was present the mismatch between DP and IDP could be detected.

Then I re-read RFC5280 and see the following comment regarding partitioning by
reason code:

         (3)  If the IDP CRL extension is not present or omits
              onlySomeReasons but the DP includes reasons, then set
              interim_reasons_mask to the value of DP reasons.

This seems to have the same issue: CRLs could be substituted if they give no
indication of the reason codes they cover.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Jun 2010 09:29:10 -0400

> valid after the substitution because there is no way to detect the substitution.

Yes, this is both non-compliant and insecure.

> indication of the reason codes they cover.

Section 5.2.5 (Issuing Distribution Point) of RFC 5280 says:

    The reason codes associated with a distribution point MUST be
    specified in onlySomeReasons.  If onlySomeReasons does not appear,
    the distribution point MUST contain revocations for all reason codes.

So, if the CRL was issued in conformance with the standard then there 
will be no substitution risk, since the CRL will actually cover all 
reason codes.

I suppose that there are three options in the case that the value of 
reasons in the cRLDistributionPoints extension doesn't match the value 
of onlySomeReasons in the issuingDistributionPoint extension:

1) reject the CRL

2) accept the CRL for only those reasons that are specified in both the 
reasons field in the cRLDistributionPoints extension and in the 
onlySomeReasons field in the issuingDistributionPoint extension

3) accept the CRL for all reasons specified in the 
issuingDistributionPoint extension

The editors of RFC 3280 choose option 2).  Compared to option 3), option 
2) just forces the relying party to expend more effort obtaining 
additional CRLs to ensure that all revocation reasons have been covered.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jun 2010 10:54:05 -0400

Steve,

I agree with you top level observation, and with David, that if there 
is a partitioned CRL, then each CRL MUST contain an IDP value that an 
RP matches against the IDP value in the CRL.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Mon, 21 Jun 2010 08:23:29 -0400

Doesn't RFC 5280 6.3.3 check b-2-i deal with this ("If the 
distribution point name is present in the IDP CRL extension and the 
distribution field is present in the DP, then verify that one of the names 
in the IDP matches one of the names in the DP")?  That's especially true 
since section 5.2.5 says in part "If the distributionPoint field is 
absent, the CRL MUST contain entries for all revoked unexpired 
certificates issued by the CRL issuer, if any, within the scope of the 
CRL."  I suppose that it's possible to interpret that latter section as 
not requiring the IDP extension for partitioned CRL's, but only requiring 
the DP field within it when it's present, but that doesn't seem natural to 
me.

                Tom Gindin

From:
Stephen Kent <[email-masked]>
To:
Dr Stephen Henson <[email-masked]>
Cc:
pkix <[email-masked]>
Date:
06/15/2010 11:47 AM
Subject:
Re: [pkix] Binding between CRL and DP.
Sent by:
[email-masked]

Steve,

Steve
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Jun 2010 03:33:49 -0400

>the DP field within it when it's present, but that doesn't seem natural to

Tom,

I think we are in agreement, and I appreciate the citation of the 
specific text from 5280 that clarifies the issue.

Steve