Re: [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