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/475eeac7-5fb2-433e-bd4e-c591593fc9ddn%40mozilla.org.
