Clarify policy about CRL shards listing their own URI in the issuingDistributionPoint extension

[WilsonKathleen]

Updated request based on feedback and on https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU/m/4VUJ1HiqAAAJ "inclusion of the IDP extension and distributionPoint field in sub-scoped CRLs is a requirement of RFC 5280 and X.509 and thus must be unconditionally included (it is a deviation of the profile to omit it). Given that the inclusion of the IDP is the standard mechanism to prevent exactly the attack described in this thread, it should be employed here as opposed to layering hacky fixes on top of CRLs that do not adhere to the profile."

Therefore, MRSP should clarify that in each CRL shard CAs must list the its own URI in its issuingDistributionPoint extension. (Then the consumer can check that they received 1.crl when they fetched http://example.org/1.crl, etc.)

[vanbroup]

2. the CRLs are available over https

Would this not trigger another revocation check of the TLS connection to download the CRL, which could trigger another revocation check, etc.

[techliaison]

The way I read the description of the attack, it only works if there is no CDP in the certificate. So please make that distinction in the Mozilla policy. I ask because within the last year or 2, I remember one CA being told that they needed to switch from using https to http in the CDP of issued certificates. And this seems to reverse that position.

Thanks, wendy

From: Kathleen @.> Sent: Tuesday, October 11, 2022 8:36 PM To: mozilla/pkipolicy @.> Cc: Subscribed @.***> Subject: [mozilla/pkipolicy] Clarify policy about CRL shards listing their own URI in the issuingDistributionPoint extension (Issue #256)

CRLs are typically served over http, so there is an attack scenario as described here: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU/m/AtPQquhQCAAJhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fg%2Fdev-security-policy%2Fc%2FqhrGxLvyreU%2Fm%2FAtPQquhQCAAJ&data=05%7C01%7Cwendy.brown%40protiviti.com%7Cce13caf6ce304911177808daabe9c208%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C638011317718709339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IXUlQB3wnPggtMJEajamZYkXRPdD41hskruOX0pLPN8%3D&reserved=0

Therefore, CAs should do at least one of the following for CRL shards:

1. each CRL must list its own URI in its issuingDistributionPoint extension. (Then the consumer can check that they received 1.crl when they fetched http://example.org/1.crlhttps://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org%2F1.crl&data=05%7C01%7Cwendy.brown%40protiviti.com%7Cce13caf6ce304911177808daabe9c208%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C638011317718709339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XGgopskd2HqHHO9wra0zDWZhocdVXc9G%2FstuqDjbyWc%3D&reserved=0, etc.)
2. the CRLs are available over https

- Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F256&data=05%7C01%7Cwendy.brown%40protiviti.com%7Cce13caf6ce304911177808daabe9c208%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C638011317718709339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MOPFKASSb8EFYNf1ln2bnOhcKB9cVP%2BavMltL%2FBdAXg%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAENXKOYUMHDQ2QYEPSVPDW3WCYBXTANCNFSM6AAAAAARCZDBVA&data=05%7C01%7Cwendy.brown%40protiviti.com%7Cce13caf6ce304911177808daabe9c208%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C638011317718709339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dqyF2dj7Eqfo0O6KxyzSp9Kmdz14dPgEv6wOIbF3DA0%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

[WilsonKathleen]

Thanks! I've updated the request to have MRSP clarify that in each CRL shard CAs must list the its own URI in its issuingDistributionPoint extension.

[WilsonKathleen]

Clarification: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/qhrGxLvyreU/m/7p-TufyxAAAJ "The IDP URL must be present in sharded CRLs (i.e. if a CRL is not a complete CRL for the entire CA). I'm also inclined to say HTTPS must not be used here. There are cases where it could work, others where it could cause issues, but overall I don't believe it brings sufficient benefit to be worth outlining the allowance. Further, it's probably worth noting that CRL URL(s) referenced only in the CCADB JSON array should match the IDP URL(s)."

[BenWilson-Mozilla]

The current proposal being circulated within the CA/Browser Forum is "Effective [date], if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain the Issuing Distribution Point extension and MUST populate the distributionPoint field of that extension."

[BenWilson-Mozilla]

Ballot SC-058 at the CA/B Forum passed with this language "Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the distributionPoint field of that extension." With the passage of this ballot, can this issue be closed, because I don't think we need to put it in the Mozilla Root Store Policy anymore?

[AGWA]

I don't think Ballot SC-058 is sufficient because it doesn't specify what the IDP's distributionPoint must contain. RFC 5280 says that it should contain the same URL as the certificate's CRL Distribution Points extension, but as far as I can tell doesn't provide any guidance for when the CRL URL is distributed out-of-band, such as via the CCADB.

[BenWilson-Mozilla]

Hi @AGWA , this should probably be handled in the CCADB policy, don't you think? Or in section 4.1 of the Mozilla Root Store Policy? What you're saying is that, for sharded CRLs in the JSON array in CCADB, it needs to say that they "must contain a critical Issuing Distribution Point extension and MUST populate the distributionPoint field of that extension"? Is there anything more specific that would need to be said? Thanks.

[CBonnell]

I think the most natural location for this requirement would be in MRSP, as the CCADB policy doesn't currently specify the profile of certificates, CRLs, or OCSP responses, whereas MRSP does.

Perhaps adding a section 6.3 "CRLs" with the following passage would be sufficient:

A CRL whose scope does not include all unexpired certificates that are issued by the CA SHALL contain a critical Issuing Distribution Point extension. The distributionPoint field of the extension SHALL include a UniformResourceIdentifier whose value is derived from one of the two following sources:

1. The UniformResourceIdentifier as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5); or
2. The URL as included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.

[AGWA]

@BenWilson-Mozilla I agree CCADB Policy or Section 4.1 of MRSP is the best place to put this as it's a requirement specifically on the CRLs referenced by the CCADB. (CC @clintwilson who might appreciate it in the CCADB Policy so Apple can benefit as well.) How about this language:

Each CRL referenced by the JSON Array of Partitioned CRLs MUST contain a critical Issuing Distribution Point extension. The Issuing Distribution Point extension MUST contain a distributionPoint containing a UniformResourceIdentifier whose value equals the URL of the CRL in the the JSON Array of Partitioned CRLs.

The goal is to make sure that someone downloading each CRL in the JSON array can verify that the CRL hasn't been swapped with a different CRL, and I believe the above text will ensure that.