FWIW, I'm confident that my reading is what was intended when this sentence was added to the MRSP, because I recall some of the events that led to that language being proposed. It's very unfortunate that an alternative interpretation is possible, and that there don't seem to be any Incident bugs dating back to previous occasions that CAs were found to be omitting IDP in partial CRLs, and that RFC5280 bungled X.509's requirement that IDP must be present in all partial CRLs. ________________________________ From: 'Aaron Gable' via [email protected] <[email protected]> Sent: 07 October 2022 18:45 To: Rob Stradling <[email protected]> Cc: 'Aaron Gable' via [email protected] <[email protected]>; Corey Bonnell <[email protected]>; Andrew Ayer <[email protected]> Subject: Re: CRL partitioning and IDPs
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, Oct 7, 2022 at 8:49 AM Rob Stradling <[email protected]<mailto:[email protected]>> wrote: Although this "defect" remains in RFC5280, ISTM that the original X.509 requirement is restored by MRSP section 5.2 [2], which says: "CA operators MUST NOT issue ... partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension" Does this observation cause you to rethink your conclusion? I had read that requirement differently, as "MUST NOT issue CRLs that have a critical issuingDistributionPoint extension that does not have a distributionPoint field". My reading bound the verb "lack" to the noun "distributionPoint", rather than to the noun phrase "distributionPoint in a critical issuingDistributionPoint extension". I think the appropriate text to convey the intended requirement here would be "partial/scoped CRLs which lack a critical issuingDistributionPoint extension with the distributionPoint field". It's of course also unfortunate that it picks as an example something that is not clearly laid out by RFC 5280; examples should be drawn from the underlying source, not laid on top of it. But I agree that there's a reasonable reading which arrives at your interpretation, and we have already decided<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fletsencrypt%2Fboulder%2Fissues%2F6410%23issuecomment-1270705003&data=05%7C01%7Crob%40sectigo.com%7Ccfe63097c11c4fbeb79108daa88bb576%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638007615258505045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pW8yu8n7tpDxOVnTO1M3sLtBLofizm7dLhYYVWDsFS4%3D&reserved=0> to begin including the issuingDistributionPoint in our CRLs in the near future in order to prevent replacement attacks. Aaron -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdZnuDo2%2BUtsY8q_8YBCYUKpojPdbrkEWboDqUMjH1rWw%40mail.gmail.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCAEmnErdZnuDo2%252BUtsY8q_8YBCYUKpojPdbrkEWboDqUMjH1rWw%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Crob%40sectigo.com%7Ccfe63097c11c4fbeb79108daa88bb576%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638007615258505045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kpmU4tpbI1eMKkvLdcnsMYnn8U2KwY2u5Z9Azs5VYXI%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729FD4765F33D946DEF5453AA229%40MW4PR17MB4729.namprd17.prod.outlook.com.
