Clarifications for MRSP v.2.8 Effective Dates

[Ben Wilson]

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

[Aaron Gable]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
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.

[Martijn Katerbarg]

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 aa...@letsencrypt.org: