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> 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" 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" 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/08421678-D612-45E7-B05A-A35FD9E68A89%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
