Hi Dimitris, The current expectation is described in the Apple Policy:
Effective October 1, 2022, CA providers must populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" on Root and Intermediate Certificate records, within 7 days of the corresponding CA issuing its first certificate. This requirement applies to each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program. Notably, there is not currently an exclusion for certificates which do not contain the id-kp-serverAuth or id-kp-emailProtection EKUs; it applies to all the Root CAs included in the Apple Root Program as well as each subordinate CA which chains up to one of those Root CAs. Thank you, -Clint > On Jan 23, 2023, at 10:32 AM, Dimitris Zacharopoulos <ji...@it.auth.gr> wrote: > > Hi Corey, > > I think Apple has clarified that they expect the full CRL URL to be added for > CAs that are for the issuance of email protection or TLS certificates. It > should not be required for CAs that contain an EKU with only > id-kp-timeStamping or id-kp-codeSigning or id-kp-clientAuth. If I recall > correctly, this was also confirmed by Kathleen during a CCADB presentation in > February 2022. > > > Thanks, > Dimitris. > > On 20/1/2023 6:00 μ.μ., 'Corey Bonnell' via dev-security-policy@mozilla.org > <mailto:dev-security-policy@mozilla.org> wrote: >> Hi Ben, >> I think this change is fine from a Mozilla Policy standpoint, as Mozilla >> only requires the disclosure of CRL URLs for TLS-capable CAs in CCADB. >> Apple, on the other hand, requires the disclosure of CRL URLs for all CAs >> regardless of technical capability (i.e., non-TLS CAs also have this >> disclosure requirement). Further guidance in the Apple root program policy >> on the encoding requirements for IDPs may be needed to cover the non-TLS CA >> case. >> >> Thanks, >> Corey >> >> From: Ben Wilson <bwil...@mozilla.com> <mailto:bwil...@mozilla.com> >> Sent: Thursday, January 19, 2023 5:46 PM >> To: Corey Bonnell <corey.bonn...@digicert.com> >> <mailto:corey.bonn...@digicert.com> >> Cc: Aaron Gable <aa...@letsencrypt.org> <mailto:aa...@letsencrypt.org>; >> dev-secur...@mozilla.org <mailto:dev-secur...@mozilla.org> >> <dev-security-policy@mozilla.org> <mailto:dev-security-policy@mozilla.org>; >> Andrew Ayer <a...@andrewayer.name> <mailto:a...@andrewayer.name> >> Subject: Re: Policy 2.8.1: MRSP Issue #256: Requirement that Partitioned >> CRLs include an Issuing Distribution Point extension >> >> 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 <bwil...@mozilla.com >> <mailto:bwil...@mozilla.com>> wrote: >> For review, see >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/de5e462f4ac16bd1e33c470a149061927b805e99. >> >> >> On Sun, Dec 4, 2022 at 11:21 PM Corey Bonnell <corey.bonn...@digicert.com >> <mailto:corey.bonn...@digicert.com>> 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 <bwil...@mozilla.com <mailto:bwil...@mozilla.com>> >> Sent: Wednesday, November 30, 2022 3:15 PM >> To: Aaron Gable <aa...@letsencrypt.org <mailto:aa...@letsencrypt.org>> >> Cc: Corey Bonnell <corey.bonn...@digicert.com >> <mailto:corey.bonn...@digicert.com>>; dev-secur...@mozilla.org >> <mailto:dev-secur...@mozilla.org> <dev-security-policy@mozilla.org >> <mailto:dev-security-policy@mozilla.org>>; Andrew Ayer <a...@andrewayer.name >> <mailto:a...@andrewayer.name>> >> 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 <aa...@letsencrypt.org >> <mailto:aa...@letsencrypt.org>> 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 <corey.bonn...@digicert.com >> <mailto:corey.bonn...@digicert.com>> 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 <aa...@letsencrypt.org <mailto:aa...@letsencrypt.org>> >> Sent: Thursday, November 17, 2022 5:32 PM >> To: Corey Bonnell <corey.bonn...@digicert.com >> <mailto:corey.bonn...@digicert.com>> >> Cc: Ben Wilson <bwil...@mozilla.com <mailto:bwil...@mozilla.com>>; >> dev-secur...@mozilla.org <mailto:dev-secur...@mozilla.org> >> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>> >> 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 <corey.bonn...@digicert.com >> <mailto:corey.bonn...@digicert.com>> 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 dev-security-policy@mozilla.org >> <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org >> <mailto:dev-security-policy@mozilla.org>> >> Sent: Thursday, November 17, 2022 4:03 PM >> To: Ben Wilson <bwil...@mozilla.com <mailto:bwil...@mozilla.com>> >> Cc: dev-secur...@mozilla.org <mailto:dev-secur...@mozilla.org> >> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>> >> 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 <bwil...@mozilla.com >> <mailto:bwil...@mozilla.com>> 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 >> "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>" >> group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org >> <mailto:dev-security-policy+unsubscr...@mozilla.org>. >> 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 >> "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>" >> group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org >> <mailto:dev-security-policy+unsubscr...@mozilla.org>. >> 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 >> "dev-security-policy@mozilla.org" <mailto:dev-security-policy@mozilla.org> >> group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org >> <mailto:dev-security-policy+unsubscr...@mozilla.org>. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186105AA08E6F862CEA599592C59%40DM6PR14MB2186.namprd14.prod.outlook.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186105AA08E6F862CEA599592C59%40DM6PR14MB2186.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>" > group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org > <mailto:dev-security-policy+unsubscr...@mozilla.org>. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/71a7667c-3858-cf91-8e65-b09ce6c4c44f%40it.auth.gr > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/71a7667c-3858-cf91-8e65-b09ce6c4c44f%40it.auth.gr?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/735603BA-10B2-4DBF-9C37-6983F176F49C%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
