All, During my final read-through, I noticed some things that I want to fix, in addition to minor grammar and punctuation (e.g. I'll replace the hyphen with a space between "end" and "entity" as requested by Dimitris and in accordance with usage in RFC 5280):
1 - In section 5.2, I'll change "included certificate" to "root certificate" or "included root certificate" to clarify that it applies to root certificates and not to intermediates and for consistency with the Baseline Requirements (see https://github.com/mozilla/pkipolicy/issues/242); 2 - I'll rephrase the sentence in section 5.3 which says that an "intermediate CA operator" "refers to any organization or legal entity ..." and move it to section 1 (because it is better to define CA operator earlier in the document); and 3 - in the much-discussed new section 6.1.1 (TLS revocation reasons) and in 6.2 (S/MIME revocation reasons), I'll replace most instances of "CA" with "CA operator" - for consistency with the rest of the MRSP. I'll make those changes now, and then I'll circulate the Github commit that shows those changes when I'm done. Ben On Fri, Apr 22, 2022 at 8:48 AM Ben Wilson <[email protected]> wrote: > Thanks, Andrew > > I think it will be really helpful for OCSP Watch to monitor compliance > based on precertificates going forward. > > Ben > > On Fri, Apr 22, 2022 at 7:37 AM Andrew Ayer <[email protected]> wrote: > >> I am concerned by effective date of October 1, 2022 for the last two >> bullet points of Section 5.4 (Precertificates). Although some CAs have >> argued that these are "new" requirements, they haven't explained _why_ >> they need this amount of time to become compliant, and for the reasons I >> previously stated >> < >> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-yDazqfWzN8/m/FvyoY6KfCQAJ >> >, >> such a long phase-in period doesn't seem justifiable given the history. >> >> The second-to-last bullet point is especially important, and if Mozilla >> doesn't enforce it until October, then for the next 5+ months, CAs will >> be allowed to leave misissued certificates unrevoked by simply claiming >> that they never issued a final certificate, which no one has any way of >> verifying. >> >> Note that both of these bullet points are already implied by RFC6962's >> statement that precertificates create a binding intent to issue a >> certificate. CAs should not assume that other root programs have made >> or will make an exception to RFC6962's implication. Apple and Chrome >> likely have strong opinions here, since as CT-enforcing UAs, their >> users have the most to lose from a weakening of a precertificate's >> meaning. Unless these other root programs say otherwise, I will >> continue reporting noncompliance observed by OCSP Watch even when the >> only evidence of issuance is a precertificate. >> >> 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/CA%2B1gtaZauiF-42yOQLnk5eUV5zt%3D3nqpLRGzR4sHbxk3-g8zXw%40mail.gmail.com.
