Re: [Technical Errata Reported] RFC5280 (7164)

If the proposed fix were accepted, what would be included in a CRL that included an IDP extension with the distributionPoint field absent and the onlyContainsCACerts field set to true?

 

From: pkix <[email protected]> on behalf of Aaron Gable <[email protected]>
Date: Friday, October 14, 2022 at 7:14 PM
To: "David A. Cooper" <[email protected]>
Cc: RFC Errata System <[email protected]>, <[email protected]>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (7164)

 

Ah, interesting. I agree that the distributionPoint URL does not seem necessary in cases where the CRL contains extensions which fully describe its scope and inclusion in a scope which can be computed based on fields of the certificate itself. For example, a CRL with a crlScope extension with a serialNumberRange indicating that it contains entries for certificates with even-numbered serials is not vulnerable to substitution attacks because a relying party can compute whether or not the certificate in question falls within the scope of the CRL.

 

But Section 5 explicitly allows CRLs to have scopes which cannot be encoded using the issuingDistributionPoint, crlScope, or AAissuingDistributionPoint extensions, such as "all certificates issued to the NIST employees located in Boulder". And, of course, the crlScope extension was already deprecated by the time X.509 (08/2005) was published, removing the ability of even a CRL with a scope like "all even-numbered serials" to be representable within the CRL itself.

 

This leads me to believe that the intent of this requirement was to ensure that all sharded/partitioned/scoped CRLs should have a distributionPoint to defend against substitution attacks. However, the actual text of the requirement, via its inclusion of the "within its scope" qualifier, fails to convey that intent. That is why I suggested this errata in this location.

 

Aaron

 

On Fri, Oct 14, 2022 at 1:17 PM David A. Cooper <[email protected]> wrote:

I believe that this errata is incorrect. The text from RFC 5280 that is 
proposed to be modified is referring to the distributionPoint field of 
the issuingDistributionPoint extension, whereas the text that is quoted 
from X.509 is referring to the issuingDistributionPoint extension as a 
whole.

X.509 is noting that if there is no extension limiting the scope of the 
CRL, then the scope of the CRL must be all unexpired public-key 
certificates issued by the CRL issuer. The extension limiting the scope 
could be the issuingDistributionPoint extension or it could be some 
other extension (e.g., crlScope or AAissuingDistributionPoint). The text 
from Section 5.2.5 of RFC 5280 is about the case in which the 
issuingDistributionPoint extension is present, but the distributionPoint 
field in that extension is absent, in which case the scope of the CRL is 
presumably limited by some other field in the issuingDistributionPoint 
extension.

The submitter may be correct that RFC 5280 never explicitly says that 
the scope of a CRL must include all unexpired certificates issued by the 
CRL issuer unless the CRL contains an extension (or extensions) that 
limit the scope, but addressing that would involve a different change 
from the one proposed here.

On 10/14/22 12:39 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5280,
> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
>
> --------------------------------------
> Type: Technical
> Reported by: Aaron Gable <[email protected]>
>
> Section: 5.2.5
>
> Original Text
> -------------
>     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.
>
> Corrected Text
> --------------
>     If the distributionPoint field is absent, the CRL MUST contain
>     entries for all revoked unexpired certificates issued by the CRL
>     issuer.
>
> Notes
> -----
> The removed phrase does not appear in the original text that this requirement is derived from, ITU-T Rec. X.509 (08/2005) Section 8.6.2.2: "If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer."
>
> The removed phrase does not serve to create a stricter requirement; rather it creates a looser requirement which allows a CRL which does contain entries for all revoked unexpired certificates *within its scope* to not include the distributionPoint field. Given that the distributionPoint field serves an important security purpose in preventing substitution attacks, it is unlikely that this loosening was the intent of the original authors.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5280 (draft-ietf-pkix-rfc3280bis-11)
> --------------------------------------
> Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
> Publication Date    : May 2008
> Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


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

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