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%2B1gtabNVx8jVhzomWK5iJMvKXr%3DW68VCj_DmwG1me5FNLXNww%40mail.gmail.com.
