Hello all, I just wanted to quickly mention that the Apple Root Program Policy has been updated, hopefully in a way that makes the expectations clear with regards to the Full CRL disclosure requirements and their interaction with both dormant CAs (i.e. those that have never issued a certificate) and timeliness of disclosure. The relevant bullet now states:
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. Thanks again for the feedback and input on this. Cheers! -Clint > On Sep 21, 2022, at 4:45 PM, Ben Wilson <bwil...@mozilla.com> wrote: > > Hi Rob, > > Your message is well-received. I'll see what we can do to clarify this in the > MRSP soon. I have tagged Issue #251 > <https://github.com/mozilla/pkipolicy/issues/251> in Github for an interim > MRSP version 2.8.1, but I certainly won't be able to make any MRSP changes > before October 1. > > Also, I need to work on the previously proposed language--"Full CRL URLs MUST > be provided in the CCADB before the CA signs certificates, or if it is > already signing certificates, then within 7 days of disclosing the CA > certificate in the CCADB."--to make it more clear. With that wording, it > seems to contradict the October 1 deadline, and it doesn't seem to address > all scenarios. I'll need to work on language that makes more sense. > > Thanks, > > Ben > > > On Wed, Sep 21, 2022 at 3:32 PM Rob Stradling <r...@sectigo.com > <mailto:r...@sectigo.com>> wrote: > Thanks Clint. Your interpretation of the Apple Root Program's CRL URL > disclosure requirement is crystal clear to me, thanks to your comments here > and in the official communication you mentioned. Sectigo's compliance to > this requirement in Apple's eyes is actually the least of my concerns, TBH. > > It's the second order effects of this sort of situation that bother me. If a > document that purports to be "the root store policy" is in reality "most of > the root store policy, with some bits that are (at best) misleading or (at > worst) wrong", then how can we expect CAs' auditors and the wider community > to accurately interpret the actual policy? CAs are expected to read every > MDSP message, but auditors and the wider community are not. CAs receive > official communications from root programs, but auditors and the wider > community do not. > > From: 'Clint Wilson' via dev-security-policy@mozilla.org > <mailto:dev-security-policy@mozilla.org> > Sent: Wednesday, September 21, 2022 21:36 > To: Rob Stradling > Cc: Ben Wilson; Christophe Bonjean; MDSP > Subject: Re: CRL Issuance Frequency for non-published CRLs > > Hi Rob, > > It’s possible, but not guaranteed at this moment, that the policy update will > be published prior to October 1st, however an official communication was sent > to CAs (earlier this month) participating in the Apple Root Program > clarifying interpretation of this requirement. If that is insufficient in the > interim in the view of CAs or other interested parties to be comfortable with > their own compliance, I would appreciate that feedback and will certainly > work with any impacted CAs in this regard. > > Thank you! > -Clint > >> On Sep 21, 2022, at 1:21 PM, Rob Stradling <r...@sectigo.com >> <mailto:r...@sectigo.com>> wrote: >> >> AIUI, the latest published version of a root store policy always takes >> precedence over (1) draft updates to that policy, (2) language proposed for >> public discussion by the policy's owner, and (3) expressions of intent by >> the policy's owner that are at odds with the latest published policy >> language. With that in mind... >> >> Clint, thanks for confirming that Ben's proposed language matches the intent >> of the similar Apple Root Program requirement. Do you plan to update >> https://www.apple.com/certificateauthority/ca_program.html >> <https://www.apple.com/certificateauthority/ca_program.html> before October >> 1st, so that the Apple Root Program's effective policy for CRL URL >> disclosures matches your intent? >> The current language - "for each included CA Certificate and each CA >> Certificate chaining up to an included CA Certificate in the Apple Root >> Program" - leaves no room for a "before the CA signs certificates" >> carve-out, and there's also no permission for any delay between the issuance >> of a Subordinate CA Certificate and the disclosure of its CRL URL(s). >> >> Ben, thanks for proposing some language for discussion. Do you plan to >> (quoting you) "modify MRSP section 4.1 to more clearly indicate when full >> CRLs need to be added to the CCADB" before October 1st? >> The current language in >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements >> >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements> >> leaves no room for a "before the CA signs certificates" carve-out, and >> there's no permission for any delay between the issuance of a Subordinate CA >> Certificate and the disclosure of its CRL URL(s). >> >> Alternatively... >> If Mozilla's and Apple's intended policies are aligned on these matters, >> would it be better to add the language to >> https://www.ccadb.org/policy#4-intermediate-certificates >> <https://www.ccadb.org/policy#4-intermediate-certificates> and then update >> both the MRSP and https://www.apple.com/certificateauthority/ca_program.html >> <https://www.apple.com/certificateauthority/ca_program.html> to defer to the >> CCADB Policy? >> >> From: 'Clint Wilson' via dev-security-policy@mozilla.org >> <mailto:dev-security-policy@mozilla.org> >> Sent: Thursday, August 25, 2022 18:31 >> To: Ben Wilson >> Cc: Christophe Bonjean; MDSP >> Subject: Re: CRL Issuance Frequency for non-published CRLs >> >> Hi all, >> >> FWIW, the below language also matches the intent of the similar Apple Root >> Program requirement. >> >> Thanks, >> -Clint >> >>> On Aug 25, 2022, at 10:20 AM, Ben Wilson <bwil...@mozilla.com >>> <mailto:bwil...@mozilla.com>> wrote: >>> >>> Hi Christophe, >>> >>> We do want to maintain some flexibility here and to mirror current >>> practices without creating new unnecessary requirements. We could modify >>> MRSP section 4.1 to more clearly indicate when full CRLs need to be added >>> to the CCADB. For discussion, the language could be something like, "Full >>> CRL URLs MUST be provided in the CCADB before the CA signs certificates, or >>> if it is already signing certificates, then within 7 days of disclosing the >>> CA certificate in the CCADB." >>> >>> Thoughts? >>> >>> Ben >>> >>> >>> >>> On Tue, Aug 23, 2022 at 12:33 PM Christophe Bonjean >>> <christophe.bonj...@globalsign.com >>> <mailto:christophe.bonj...@globalsign.com>> wrote: >>> Hi Ben, >>> >>> There’s a few CA and CRL lifecycle events linked to this change: >>> T= 0 : CA creation >>> T= 0 + a: CRL URL assignment (not yet publishing CRLs) >>> T = max 7 days: CA disclosure in CCADB (section 5.3.2) >>> T = 7 days + b: CRL disclosure in CCADB (section 4.1) >>> T = 7 days + c: First CRL published >>> T = d: First certificate issued from CA (with CRL in certificate profile) >>> >>> The proposed change to section 4.1 means that CRLs need to be published as >>> soon as they are being disclosed in CCADB. >>> >>> In some cases, CAs are generated a while before they are used, for example >>> TLS CAs that we rotate on a quarterly basis. In that case, CRLs will only >>> be published close to the when the CA becomes operational. >>> >>> It seems the timeline to populate the CRL information in CCADB is currently >>> flexible and supports this approach (i.e. populating and publishing the CRL >>> a while after the CA is disclosed). >>> >>> Is this the correct understanding? If there’s a different interpretation or >>> intention to restrict this timeline in the future, we would like to further >>> discuss. >>> >>> Thanks >>> >>> Christophe >>> >>> From: dev-security-policy@mozilla.org >>> <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org >>> <mailto:dev-security-policy@mozilla.org>> On Behalf Of Ben Wilson >>> Sent: Thursday, 11 August 2022 17:03 >>> 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>> >>> Subject: Re: CRL Issuance Frequency for non-published CRLs >>> >>> All, >>> >>> Mozilla's position is that adding CRL URLs to the CCADB (as required >>> effective Oct. 1, 2022, by MRSP section 4.1 >>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements>) >>> will be considered "publishing" them because we will be relying on that >>> information in the CCADB to operate CRLite. I have added Issue #251 >>> <https://github.com/mozilla/pkipolicy/issues/251> to GitHub to address this >>> issue more precisely in the next version of the Mozilla Root Store Policy. >>> For this, we will use the timeframes from section 4.9.7 of the Baseline >>> Requirements, "the CA SHALL update and reissue CRLs at least once every >>> seven days ...." (In the future, we might want to see that time frame >>> shortened.) >>> >>> Thanks, >>> >>> Ben Wilson >>> Mozilla Root Store Program >>> >>> >>> On Fri, Aug 5, 2022 at 1:08 PM 'Corey Bonnell' via >>> dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> >>> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>> >>> wrote: >>> Hi Aaron, >>> >>> > As long as we do not publish the CRLs, they are not required to be >>> > updated on specific timetables. >>> >>> My understanding is that absent the inclusion of a URI in a CRLDP extension >>> of a Certificate that is subject to the BRs or some other Root Program >>> requirement, there is no obligation by the CA to publish and update >>> CRL-based revocation information on any specific cadence. >>> >>> Given this, I believe that it’s compliant to not publish CRLs that are >>> signed by the CA. >>> >>> Thanks, >>> Corey >>> >>> 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, August 4, 2022 4:10 PM >>> To: dev-secur...@mozilla.org <mailto:dev-secur...@mozilla.org> >>> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>> >>> Subject: CRL Issuance Frequency for non-published CRLs >>> >>> Hi MDSP, >>> >>> Section 4.9.7 of the Baseline Requirements says (emphasis added): >>> >>> > If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at >>> > least once every seven days, and the value of the nextUpdate field MUST >>> > NOT be more than ten days beyond the value of the thisUpdate field. >>> >>> Let's Encrypt is currently in the final stages of standing up >>> infrastructure to issue and publish CRLs, in compliance with the upcoming >>> Apple and Mozilla root program requirements that go into effect on October >>> 1st. >>> >>> As with many systems, we would like to test this as thoroughly as possible >>> prior to making it fully available. Of course we're already running it in >>> our non-production environment with an untrusted hierarchy of issuers. But >>> there's a risk that, if we were to run the new infrastructure in our >>> production environment and discover some sort of fault, we would not be >>> able to turn it off again due to the reissuance and update requirements. >>> >>> It is our interpretation of the above-quoted text from Section 4.9.7 that >>> this risk does not actually exist. As long as we do not publish the CRLs, >>> they are not required to be updated on specific timetables. >>> >>> Does anyone disagree with this interpretation? Are there other requirements >>> that I'm missing that would prevent us from turning the new infrastructure >>> off? >>> >>> Thanks, >>> Aaron >>> -- >>> 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/CAEmnErfY4g7_6yz%2BLZ-mO0k_bDaSrxy4d9AJ8O8BQD-Et888tA%40mail.gmail.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfY4g7_6yz%2BLZ-mO0k_bDaSrxy4d9AJ8O8BQD-Et888tA%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/DM6PR14MB2186BFE4B53C139E80C133DC929E9%40DM6PR14MB2186.namprd14.prod.outlook.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186BFE4B53C139E80C133DC929E9%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/CA%2B1gtab97PjAttWujLsH7YX1L%2B5j8cNruEaq1kBFPz5AECq4eQ%40mail.gmail.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtab97PjAttWujLsH7YX1L%2B5j8cNruEaq1kBFPz5AECq4eQ%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/CA%2B1gtabYw%3D51CmBZ9b96MnGmo3u4z6GOSQwj0iurMtg%2BsjMrgQ%40mail.gmail.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabYw%3D51CmBZ9b96MnGmo3u4z6GOSQwj0iurMtg%2BsjMrgQ%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/08421678-D612-45E7-B05A-A35FD9E68A89%40apple.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/08421678-D612-45E7-B05A-A35FD9E68A89%40apple.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/9C565465-7738-48A2-A9A9-06E21176CCF6%40apple.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9C565465-7738-48A2-A9A9-06E21176CCF6%40apple.com?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 > <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%2B1gtaYP%3D0sm6Ms0DHL_-su_%2BH-Bxg%2Bd1UP2XPJMX9b1h7Vz_Q%40mail.gmail.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYP%3D0sm6Ms0DHL_-su_%2BH-Bxg%2Bd1UP2XPJMX9b1h7Vz_Q%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" 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/4DD9A0FC-4604-4FE3-915E-1B9E27AE58EC%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
