Re: [pkix] [Technical Errata Reported] RFC5280 (7164)

["David A. Cooper" <[e-mail]>]

On 10/14/22 4:13 PM, Aaron Gable wrote:
> 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. 

I believe that when Section 5 noted that the scope of a CRL could be 'a 
set of certificates based on arbitrary local information, such as "all 
certificates issued to the NIST employees located in Boulder",' it meant 
that something like this could be accomplished using the 
distributionPoint field in the cRLDistributionPoints and 
issuingDistributionPoint extensions. It would just involve creating a 
distribution point for the certificates issued to NIST employees located 
in Boulder and then including this in the distributionPoint field in the 
appropriate certificates and CRLs. It wasn't suggesting that the scope 
of a CRL could be limited in this way without having an extension in the 
CRL that limits the scope of the CRL.

Section 5.2.5 clearly indicates that a issuingDistributionPoint 
extension may have just the onlySomeReasons field present:

    Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of
    the issuing distribution point extension is an empty sequence.  That
    is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and
    onlyContainsAttributeCerts are all FALSE, then either the
    distributionPoint field or the onlySomeReasons field MUST be present.

If you were correct that setting onlyContainsUserCerts to TRUE is not a 
way to limit the scope of the CRL but only a way to indicate that the 
CRL issuer only issued end-entity certificates (suggesting it should 
have been named the onlyIssuesUserCerts field), then that would seem to 
imply that similarly the onlySomeReasons is not a way to limit the scope 
of the CRL, but only a way to indicate that the CRL issue only revokes 
certificates for the specified reasons. However, Section 6.3 clearly 
indicates otherwise. It indicates that if a CRL contains the 
onlySomeReasons flag, then the relying party needs to obtain additional 
CRLs until CRL covering all revocation reasons have been obtained and 
checked. Even if this were not the case, the fact that a CRL could 
contain an issuingDistributionPoint extension with just the 
onlySomeReasons field present and that this CRL would not necessarily 
contain entries for all unexpired revoked certificates (as confirmed by 
Section 6.3.3), demonstrates that the proposed change would be a 
technical change, not a clarification of the original intent of the text.

On 10/14/22 4:33 PM, Aaron Gable wrote:
> The CRL would contain entries for all revoked unexpired certificates 
> issued by the CRL issuer. It would also be asserting that the CRL 
> issuer does not issue any end-entity public key certificates, and 
> therefore that all certificates issued by the CRL issuer are CA 
> certificates. If this assertion were not true, the CRL would be 
> considered misissued.
>
> I think this interpretation is reasonable, given that the 
> conditionality of the requirements around the distributionPoint field 
> and the requirements around the onlyContainsCACerts field are 
> opposites. The former says "if this field is missing, then something 
> must be true", while the latter says "if something is true, then the 
> field must be present". It does not matter *why* that condition is 
> true -- perhaps the scope only contains CA certs because the CA has 
> decided that should be the scope, or perhaps the scope only contains 
> CA certs because the issuer has in fact only issued CA certs -- the 
> consequence of the condition being true is the same either way.
>
> Aaron
>
> On Fri, Oct 14, 2022 at 4:23 PM Carl Wallace 
> <[e-mail]> wrote:
>
>     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 <[e-mail]> on behalf of Aaron Gable
>     <aaron=[e-mail]>
>     *Date: *Friday, October 14, 2022 at 7:14 PM
>     *To: *"David A. Cooper" <[e-mail]>
>     *Cc: *RFC Errata System <[e-mail]>, <[e-mail]>
>     *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
>     <[e-mail]> 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 <[e-mail]>
>         >
>         > 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
>         <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F8.6.2.2%2F&data=05%7C01%7Cdavid.cooper%40nist.gov%7Cd05c7e9473ca425d348508daae3c8948%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638013872273508417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RNbXDZm1QyhWKX5J78kL2m7%2FF5EcNmtN7S8MQRRiPKM%3D&reserved=0>:
>         "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
>     [e-mail] https://www.ietf.org/mailman/listinfo/pkix
>     <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpkix&data=05%7C01%7Cdavid.cooper%40nist.gov%7Cd05c7e9473ca425d348508daae3c8948%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638013872273508417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T3eMl%2BRa5807O4Pe2U0LLzXZFn2ADKLFvolZPAKwr%2BA%3D&reserved=0>
>
>