> As a general principle, this would be regardless of how much they have been discussed in the past as discussion does not always lead to something becoming a requirement.
I agree with Dustin. This message [1] made it clear that providing revocation information for pre-certificates is a recommended (but not required) practice: "I've gone ahead and moved [4] to the "Recommended Practices" section. The ballot to modify the BRs is now in the formal discussion period leading up to a vote [5]." I am unaware of any changes in the written requirements in the BRs or Mozilla Policy to make this a required practice until the MozPol 2.8 proposal. Given this, I believe a reasonable effective date should be included to give time for CAs to update their operations to comply. Thanks, Corey [1] https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/tPrL7rNkBAAJ On Wednesday, April 20, 2022 at 2:08:09 AM UTC-4 Dustin Hollenback wrote: > Andrew, > > I agree with you that while the entire Section 5.4 is new in the policy, > the first two bullet points have been well understood as requirements for > some time. I thought it would be easier to set an effective date for the > entire section out of simplicity, but have no concern with not defining a > future effective date for these first two bullet points. > > For the last two bullet points, while I agree that they have been > discussed for quite some time, they are still new MRSP requirements. And, > while I fully agree with and support the requirement change, the ask is > that there be a transition time for any new requirement once it is > approved. As a general principle, this would be regardless of how much they > have been discussed in the past as discussion does not always lead to > something becoming a requirement. > > With that said, I recommend the following text for section 5.4: > > > > > > > *### 5.4 Precertificates ###Certificate Transparency precertificates are > considered by Mozilla to be a binding intent to issue a certificate, as > described in [section 3.1 of RFC 6962][6962-3.1], and thus in-scope for > enforcing compliance with these requirements. Thus,* if a final certificate > cannot be verified as matching a precertificate using the algorithms in RFC > 6962, then two distinct final certificates are presumed to exist, and it is > misissuance if the two final certificates have the same serial number and > issuer, even if only one final certificate actually exists; and* if a > precertificate implies the existence of a final certificate that does not > comply with this policy, it is considered misissuance of the final > certificate, even if the certificate does not actually exist.Effective > October 1, 2022,* > > > > ** a CA must be able to revoke a certificate presumed to exist, if > revocation of the certificate is required under this policy, even if the > final certificate does not actually exist; and* 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.* > > > Regards, > > > Dustin > > On Tuesday, April 19, 2022 at 5:44:37 PM UTC-7 Andrew Ayer wrote: > >> On Tue, 19 Apr 2022 16:29:29 -0700 (PDT) >> "'Dustin Hollenback' via [email protected]" >> <[email protected]> wrote: >> >> > >> > Our understanding is that the information in Section 5.4 >> > Precertificates has been a Recommended Practice >> > ( >> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates) >> >> >> > for some time. Adding this new section changes it from a Recommended >> > Practice to a Requirement. >> > >> > Similar to Section 6.1.1 that has a new requirement, can you set an >> > effective date within the section that is farther out than the 2.8 >> > effective date. For consistency, I'd recommend setting the same date >> > as another new section, 6.1.1, which is effective October 1, 2022. >> >> The first two bullet points in Section 5.4 (about misissuance) are not >> new requirements, but follow from from this statement in RFC6962: >> >> "The signature on the TBSCertificate indicates the certificate >> authority's intent to issue a certificate. This intent is considered >> binding (i.e., misissuance of the Precertificate is considered equal to >> misissuance of the final certificate)." >> >> This has been covered on this list and in >> incident reports ad nauseam since 2016, long before >> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices even had >> a Precertificates section. All Section 5.4 does is make the existing >> requirements very explicit. >> >> The last two bullet points in Section 5.4 (about revocation) >> were originally listed on >> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices as a >> Required practice, as a clarification of Mozilla's existing >> requirements, which some CAs had already been held accountable for >> violating: >> >> >> https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/S-aAK3r1BAAJ >> >> >> However, they were moved to the Recommended section because of a >> concern that they conflicted with the Baseline Requirements: >> >> >> https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/FzKrQbQJBwAJ >> >> >> This conflict was resolved in 2019 with the passage of SC23. Thus, CAs >> have long been on notice about Mozilla's expectations and intentions. >> Indeed, at least one CA already considers it a "clear" requirement to >> operate revocation services for certificates presumed to exist based >> on precertificates: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1763203#c1 >> >> Any CA that wasn't already compliant in 2019 has already had over >> two years to resolve that. >> >> I therefore see no reason why Section 5.4 needs a later effective date. >> >> Regards, >> Andrew >> > -- 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/b15001a9-6cf3-4d39-a660-72f6563247fbn%40mozilla.org.
