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

Thanks for the pointer to the discussion that predated the filing of the errata. To close the loop, it's here: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU. 

On 10/24/22, 4:53 AM, "pkix on behalf of Tim Hollebeek" <pkix-bounces@ietf.org on behalf of tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote:

    I think it should be rejected as well, but for different reasons.

    The discussion has been very interesting and helpful; for people who want further background, there's a thread about this on mozilla.dev.security-policy as well.  There certainly is potential for confusion in this area as one well-meaning individual has already been confused.  However, I think the proposed solution in this errata doesn't significantly improve the existing text.

    The reason I think it doesn't improve the existing text is because it relies a lot on various assumptions about how various words should be read, and changes some of them in the hope that fewer people will misread them in the future.  I think this is unlikely to succeed.  If we want to make improvements here, I think the errata would need to add more explicit clarifying statements about exactly what the issues are here and clarifying the original intent.  Errata are not supposed to change the meaning of the existing text, and we're tiptoeing in that direction here, trying to "improve" the text instead of fixing an error.  

    I think I'm leaning towards the idea that this is best handled at the policy level, and the wheels are already in motion to clarify in the Baseline Requirements what the exact expectations here are for the Web PKI.

    Also, having the errata rejected is in no way a value judgement on the filing of the errata.  The discussion was interesting and I think this has shown that this can be a productive way of handling confusion about the interpretation of RFC 5280 text in the future.

    -Tim

    > -----Original Message-----
    > From: pkix <pkix-bounces@ietf.org> On Behalf Of Russ Housley
    > Sent: Friday, October 14, 2022 10:17 PM
    > To: aaron@letsencrypt.org
    > Cc: Roman D. Danyliw <rdd@cert.org>; Stefan Santesson <sts@aaa-
    > sec.com>; IETF PKIX <pkix@ietf.org>; Paul Wouters <paul.wouters@aiven.io>
    > Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (7164)
    > 
    > Upon further reflection,  I think the should be rejected.
    > 
    >    DistributionPoint ::= SEQUENCE {
    >         distributionPoint       [0]     DistributionPointName OPTIONAL,
    >         reasons                 [1]     ReasonFlags OPTIONAL,
    >         cRLIssuer               [2]     GeneralNames OPTIONAL }
    > 
    > The distributionPoint says where to get the CRL.
    > 
    > The reasons define the scope.
    > 
    > The cRLIssuer identifies the entity that signs and issues the CRL.
    > 
    > So, I believe the original text is correct.
    > 
    > Russ
    > 
    > 
    > > On Oct 14, 2022, at 4:03 PM, Russ Housley <housley@vigilsec.com> wrote:
    > >
    > > I see your point, but I think we should keep "if any"
    > >
    > > Russ
    > >
    > >
    > >> On Oct 14, 2022, at 3:39 PM, RFC Errata System <rfc-editor@rfc-
    > editor.org> wrote:
    > >>
    > >> The following errata report has been submitted for RFC5280, "Internet
    > >> X.509 Public Key Infrastructure Certificate and Certificate Revocation List
    > (CRL) Profile".
    > >>
    > >> --------------------------------------
    > >> You may review the report below and at:
    > >> https://www.rfc-editor.org/errata/eid7164
    > >>
    > >> --------------------------------------
    > >> Type: Technical
    > >> Reported by: Aaron Gable <aaron@letsencrypt.org>
    > >>
    > >> 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
    > pkix@ietf.org
    > https://www.ietf.org/mailman/listinfo/pkix

    _______________________________________________
    pkix mailing list
    pkix@ietf.org
    https://www.ietf.org/mailman/listinfo/pkix