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.
