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.
