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/CAEmnErdme7QtrGE1DLY6fDNA6fCm4R_Pm7OteeyvjpF1s9TVJQ%40mail.gmail.com.
