I am proposing that instead of having a section 6.3 (CRLs) we have a section 6.1.2 (TLS Certificate CRL Issuing Distribution Points) - thoughts, comments, suggestions? See https://github.com/BenWilson-Mozilla/pkipolicy/commit/f634a41671fe1319b1449a9ffe253449b380fcf9
On Wed, Dec 7, 2022 at 12:38 PM Ben Wilson <[email protected]> wrote: > For review, see > https://github.com/BenWilson-Mozilla/pkipolicy/commit/de5e462f4ac16bd1e33c470a149061927b805e99 > . > > On Sun, Dec 4, 2022 at 11:21 PM Corey Bonnell <[email protected]> > wrote: > >> I like this solution. It establishes the CCADB-specific requirement in >> the section dedicated to CCADB but also specifies the CRL profile with >> details that are not necessarily specific to CCADB. >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* Ben Wilson <[email protected]> >> *Sent:* Wednesday, November 30, 2022 3:15 PM >> *To:* Aaron Gable <[email protected]> >> *Cc:* Corey Bonnell <[email protected]>; >> [email protected] <[email protected]>; Andrew Ayer < >> [email protected]> >> *Subject:* Re: Policy 2.8.1: MRSP Issue #256: Requirement that >> Partitioned CRLs include an Issuing Distribution Point extension >> >> >> >> What about adding something in both locations? >> >> >> >> (1) Making the change in MRSP section 4.1 to say, "Each CRL referenced >> by the JSON Array of Partitioned CRLs MUST contain a critical Issuing >> Distribution Point extension *as described in section 6.3*. The Issuing >> Distribution Point extension MUST contain a distributionPoint containing a >> UniformResourceIdentifier whose value equals the URL of the CRL in the JSON >> Array of Partitioned CRL;" >> >> >> >> *AND* >> >> >> >> (2) making Corey's suggested change to MRSP section 6.3 so that it says, >> >> >> >> 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. >> >> Will that create any conflicting language or leave a gap that would allow >> CRL swapping? If not, then I don't mind if it's slightly redundant in some >> aspects. >> >> Thanks, >> >> Ben >> >> >> >> On Mon, Nov 28, 2022 at 5:17 PM Aaron Gable <[email protected]> >> wrote: >> >> I think you make a really good point! I'm not a fan of repeating >> ourselves, but clarity is very valuable. >> >> >> >> I'd be happy with this requirement in either phrasing. >> >> >> >> Aaron >> >> >> >> On Tue, Nov 22, 2022 at 8:30 AM Corey Bonnell <[email protected]> >> wrote: >> >> Hi Aaron, >> >> I prefer explicitly stating that something is allowed, because we have >> seen previously that the lack of explicit allowance (or prohibition) in >> these requirements is the source of much disagreement. For this reason, I >> think explicitly enumerating what is allowed provides the most clarity (and >> less room for future disagreements). >> >> >> >> That being said, I agree that your proposal is much more concise than the >> other proposals. If folks think my concern about explicitly enumerating >> allowances is unreasonable, then I think your language is fine. >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* Aaron Gable <[email protected]> >> *Sent:* Thursday, November 17, 2022 5:32 PM >> *To:* Corey Bonnell <[email protected]> >> *Cc:* Ben Wilson <[email protected]>; [email protected] < >> [email protected]> >> *Subject:* Re: Policy 2.8.1: MRSP Issue #256: Requirement that >> Partitioned CRLs include an Issuing Distribution Point extension >> >> >> >> I believe that my proposal addresses that case. It only establishes a >> single requirement: that the URLs in CCADB and (one of) the URIs in the >> CRLs match. It doesn't matter why the CA is producing those CRLs >> (specifically for CCADB, or for use directly by relying parties, or both) >> or what the sharding strategy is: the important thing here is that the URL >> requested by CRLite infrastructure contains a CRL with a matching >> distributionPoint. >> >> >> >> Aaron >> >> >> >> On Thu, Nov 17, 2022 at 2:21 PM Corey Bonnell <[email protected]> >> wrote: >> >> I think the proposal may need accommodate the case where issued >> certificates have a CRLDP that contain a URI which points to a sharded CRL >> that may not be disclosed in CCADB. In other words, it is possible that the >> CA employs one sharding strategy for CCADB while using a different strategy >> for the CRLs that are referenced in the CRLDP of certificates it issues. >> The CA may be producing more CRLs than strictly necessary in this case, but >> I’m unaware of anything prohibiting such practice today and am hard-pressed >> to think of any issues that may arise with such an arrangement. I attempted >> to capture this consideration in my language proposal on Github [1]. >> >> >> >> Thanks, >> >> Corey >> >> >> >> [1] >> https://github.com/mozilla/pkipolicy/issues/256#issuecomment-1315648591 >> >> >> >> *From:* 'Aaron Gable' via [email protected] < >> [email protected]> >> *Sent:* Thursday, November 17, 2022 4:03 PM >> *To:* Ben Wilson <[email protected]> >> *Cc:* [email protected] <[email protected]> >> *Subject:* Re: Policy 2.8.1: MRSP Issue #256: Requirement that >> Partitioned CRLs include an Issuing Distribution Point extension >> >> >> >> Thanks Ben, this language seems reasonable to me (with one edit: the last >> acronym "CRL" needs to be plural). >> >> >> >> That said, rather than repeating-and-extending the BRs language, I would >> consider turning this requirement on its head: >> >> >> >> "Each URL listed in the JSON Array of Partitioned CRLs MUST match a >> distributionPoint UniformResourceIdentifier value in the referenced CRL." >> >> >> >> Basically, because the CRLs are already required to include the >> distributionPoint field, there's no need to specify that again. Instead, >> just specify that the URL listed in CCADB must match the distributionPoint, >> because otherwise Mozilla won't trust the fetched CRL. >> >> >> >> Does that approach seem reasonable as well? >> >> >> >> Aaron >> >> >> >> On Wed, Nov 16, 2022 at 9:01 PM Ben Wilson <[email protected]> wrote: >> >> This discussion thread is to address Issue #256 >> <https://github.com/mozilla/pkipolicy/issues/256> and the need to >> clarify that partitioned CRLs need to include a critical Issuing >> Distribution Point extension. >> >> >> >> The language proposed for addition to Mozilla Root Store Policy section >> 4.1 >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements> >> would read, "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 JSON >> Array of Partitioned CRL". >> >> >> >> Please provide any comments or suggestions. >> >> >> >> Thanks, >> >> >> >> Ben >> >> -- >> 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/CA%2B1gtaZ3nUbS9_hQUJ5rUzb%3DyPYkA-3ienthPwqMGdP8Fo-86g%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ3nUbS9_hQUJ5rUzb%3DyPYkA-3ienthPwqMGdP8Fo-86g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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/CAEmnErdgaxi9TROWe5GdQ%3DFpMXpQcQcquL8xgGgrVfxCyOeydw%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdgaxi9TROWe5GdQ%3DFpMXpQcQcquL8xgGgrVfxCyOeydw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/CA%2B1gtaawqLqPRGs8xsFESTzj7bz81w6%3DPu-25P994u%2B_aFA1Aw%40mail.gmail.com.
