Ben, I’m glad this subject is being brought up, and I think this item needs to be broader than just the updates for version 2.8.
As you may remember, we at Sectigo have in the past suffered from unclear expectations on effective dates ( https://bugzilla.mozilla.org/show_bug.cgi?id=1741777) and have even brought up the issue of new requirements and pre-existing services at one of the 2021 CA/B Forum F2F meetings. As Aaron mentioned, section 6.1.1 calls out very specifically what’s being affected and how to proceed with past revocations. Section 5.4.3, in a way is also very specific. We, at least, don’t see another way of interpreting the word “all”. The effective date states when the OCSP and CRL services must comply, for the CA’s entire non-expired certificate base. However as there do appear to be different interpretations, it seems we may need a path forward for when new changes are proposed and/or implemented. In general, we believe the review periods given by Mozilla are fair. CAs need to take this time to analyze the impact of a proposed change and raise concerns when they see them. But besides that, CAs and other members of this community should also try and see if different interpretations could possibly be created from a proposed change. Thanks, Martijn Op woensdag 2 november 2022 om 00:25:08 UTC+1 schreef [email protected]: > It has generally been my belief that new requirements affect all *actions* > (usually, > but not always, signing actions) which take place after their effective > date. If the requirement concerns the contents of certificates, then > certificates issued on or after the effective date are covered. If the > requirement concerns the contents of OCSP responses, then OCSP responses > created on or after the effective date are covered. And similarly for CRLs. > > For MRSP 5.4.3 specifically, nothing in the requirement affects the > contents of certificates. All "certificate[s] presumed to exist'' are based > on precertificates which are already subject to the requirement to contain > an OCSP URL, so there's no change there. This requirement only affects the > contents of OCSP responses, namely, that they need to be retrievable and > that they need to be updateable from "valid" to "revoked". Handling a > request for revocation is an event that occurs after the effective date. > Handling an OCSP request and producing a new OCSP response is an event that > happens after the effective date. Therefore it seems clear to me that the > requirement applies to all OCSP services on the effective date, regardless > of when the certificate in question was issued. > > For MRSP 6.1.1, the language specifically calls out that it affects > "revocations performed" after the effective date -- not certificates issued > after that date, nor OCSP responses produced after that date, nor CRLs > produced after that date. This language is simple to check thanks to the > fact that CRL entries contain a mandatory "revocation date" field. The > requirement affects all CRL entries whose revocation dates are before the > effective date. I don't see any reason for old certificates to have their > revocation reasons backfilled, as long as they appeared on a CRL prior to > the effective date. > > I do think that MRSP 6.1.1 would have been better phrased as "Revocation > entries that have a revocationDate prior to October 1, 2022 are not subject > to the requirements of this section." It's much easier to check the > revocationDate in a CRL entry than it is to crawl backwards through > previous versions of that CRL to see when the entry was added. But the > intent is still clear to me: only revocations which happen after the > effective date are subject to the new requirements. > > Aaron > > On Tue, Nov 1, 2022 at 3:58 PM Ben Wilson <[email protected]> wrote: > >> All, >> >> In a recent bug[1] we received a couple of requests for clarifications of >> the Mozilla Root Store Policy (MRSP), version 2.8, which require further >> discussion here. >> >> The first request concerned OCSP for precertificates generated before >> October 1, 2022,[2] and the second highlighted how we do not require >> revocation reason codes for end entity certificates revoked before October >> 1, 2022. At least one common thread is the retroactive application of new >> requirements. >> >> 1. MRSP section 5.4[3] says, “Effective October 1, 2022, … a CA MUST >> provide CRL and OCSP services and responses in accordance with this policy >> for all certificates presumed to exist based on the presence of a >> precertificate, even if the certificate does not actually exist.” >> >> One interpretation is that the effective date showed an intent to allow >> CAs to start implementing this requirement for certificates and >> precertificates issued on or after October 1, 2022. Another interpretation >> is that the requirement mainly concerned the provision of CRL and OCSP >> services as of October 1, 2022, regardless of certificate/precertificate >> issuance dates.[4] >> >> 2. MRSP section 6.1.1[5] says, “This section applies to revocations that >> are performed after October 1, 2022. Revocation entries that appeared on a >> CRL prior to October 1, 2022, do NOT need to be changed as a result of this >> section.” >> >> In the bug mentioned above, Dimitris made a comment[6] that, according to >> a discussion previously on m.d.s.p.[7], the community expected that CAs >> would retroactively update revocation reason codes for CA certificates, >> which was different from section 6.1.1 in the v.2.8 policy, which did not >> require that for end entity TLS certificates. I believe his points were >> that section 6.1.1 also needed clarification and that more consistency was >> needed. >> >> We’d like to provide more clear guidance on the two issues mentioned >> above. >> >> Kathleen and I both believe that we need to balance the need to move the >> implementation of requirements forward with the benefits of requiring >> retroactive compliance. There is benefit in moving forward from an >> effective date, but there may also be a benefit in reaching back when >> requirements can be reasonably implemented. >> >> To promote clear and consistent requirements, we’d like to discuss these >> issues further. >> >> We look forward to your thoughtful comments. >> >> Thanks, >> >> Ben >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1793443 >> >> [2] In the referenced incident, precertificates were created before >> October 1, 2022, but no corresponding final certificates were created. We >> responded, “our effective dates for policy changes typically apply to >> certificates issued after the effective date” and “The requirement does not >> include pre-certificates issued before October 1, 2022. All >> pre-certificates issued on October 1, 2022, or later must satisfy the >> requirement.” https://bugzilla.mozilla.org/show_bug.cgi?id=1793443#c9 >> >> [3] >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#54-precertificates >> >> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1793443#c6 >> >> [5] >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons >> >> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1793443#c17 >> >> [7] >> https://groups.google.com/g/mozilla.dev.security.policy/c/7z6dqwdc16o/m/RKj7RXitCgAJ >> >> -- >> 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%2B1gtab_XKqMqxrkvY3DSYm5LXRFfF0X4xgA6Om4r1Vrm6FjDw%40mail.gmail.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtab_XKqMqxrkvY3DSYm5LXRFfF0X4xgA6Om4r1Vrm6FjDw%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/4a802a32-9c0a-4dc5-8a15-2f1106e3361dn%40mozilla.org.
