Thanks, Clint. Mozilla will be following this same language in MRSP 4 for populating the CCADB full-CRL fields. "CA operators must do this within 7 days of such intermediate CA issuing its first certificate." Thanks again, Ben
On Wed, Sep 28, 2022 at 9:38 AM Clint Wilson <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 [email protected] >> *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 <[email protected]> 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 *before >> October 1**st*, 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 >> 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 and then update >> both the MRSP and >> https://www.apple.com/certificateauthority/ca_program.html to defer to >> the CCADB Policy? >> >> ------------------------------ >> *From:* 'Clint Wilson' via [email protected] >> *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 <[email protected]> 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 < >> [email protected]> wrote: >> >> Hi Ben, >> >> There’s a few CA and CRL lifecycle events linked to this change: >> >> 1. T= 0 : CA creation >> 2. T= 0 + a: CRL URL assignment (not yet publishing CRLs) >> 3. T = max 7 days: CA disclosure in CCADB (section 5.3.2) >> 4. T = 7 days + b: CRL disclosure in CCADB (section 4.1) >> 5. T = 7 days + c: First CRL published >> 6. 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:* [email protected] <[email protected]> >> *On Behalf Of *Ben Wilson >> *Sent:* Thursday, 11 August 2022 17:03 >> *To:* Corey Bonnell <[email protected]> >> *Cc:* Aaron Gable <[email protected]>; [email protected] < >> [email protected]> >> *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 >> [email protected] <[email protected]> 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 [email protected] < >> [email protected]> >> *Sent:* Thursday, August 4, 2022 4:10 PM >> *To:* [email protected] <[email protected]> >> *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 >> "[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/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 >> "[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/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 >> "[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%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 >> "[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%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 >> "[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/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 >> "[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/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 " > [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%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 "[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%2B1gtaY2e3BCHhSjZr43L3224U0O40HHbXiTaR8PH6iUg3urwA%40mail.gmail.com.
