In response to the following concern raised by Andrew: On Mon, Feb 21, 2022 at 11:06 AM Andrew Ayer <[email protected]> wrote:
> I took a look at parts of Certainly's CP/CPS. I'm happy to see > Certainly use a combined CP/CPS. However, section 3.2.2 says: > > "Certainly validates domain control primarily in an automated fashion > using the ACME protocol. In exceptional cases control may be validated > using methods similar to those employed by ACME, but performed > manually." > > The BRs permit the ACME methods. The BRs do not permit CA-invented > methods that are "similar to" ACME methods. This is the same as the > forbidden "any other method of confirmation", and relies on trusting > the CA's judgment that the methods "similar to" the allowed methods > are as secure as the allowed methods themselves. It should be > very clear that the BRs no longer permit CAs to make this judgment call. > > *The CP/CPS goes on to describe specific methods that are used by Certainly. The language Andrew is pointing out is referring to the ACME dns-01, http-01, and tls-alpn-01 implementations. It meant that Certainly might foreseeably perform a manual 3.2.2.4.7 validation rather than using Boulder’s dns-01 implementation. We’ve never done that, and given the complexity of getting it right I’m confident that we never will. I don’t agree that this is a “security-critical omission”, but I do see how this language is concerning, so it has been removed from the latest version of the CP/CPS that Ben reviewed.* - Wayne -- 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/CAPh8bk9_ZL9FZp8f0_pkFMV%2BaEba5TCZg1WpUXRHAVV8DrS76g%40mail.gmail.com.
