All, Here are the changes mentioned in my previous email on this thread.
https://github.com/BenWilson-Mozilla/pkipolicy/commit/0c4201a2cfab4a68f82c99f4efcdc5bd14bf4785 And here is the blob - https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md Please provide any comments or questions. Thanks, Ben On Mon, Apr 25, 2022 at 2:26 PM Ben Wilson <[email protected]> wrote: > 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%2B1gtabkrrYNmtu93_swiTeBuqzqso6y1XtVGNFRjRdLLv_2VA%40mail.gmail.com.
