<div dir="ltr"><div dir="ltr">On Tue, Jul 18, 2023 at 4:59 PM Clint Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><ul><li>After exploring these possibilities (and quite probably missing others), I’m personally left with the same conclusion as I shared previously (and it sounds like there hasn’t been immediate disagreement with this as a positive action/next step either?), which is: further specification is a reasonable way to address at least some of the ambiguity around the method and/or means of communication necessary to constitute a CA being made aware of compromised keys.</li><ul><li>It further seems to me that this additional specification is probably(?) best suited for the BRs, but I also haven’t come up with a reason a CA couldn’t do something similar themselves in their own document(s). Perhaps some already do this?</li></ul></ul></div></div></div></blockquote><div><br></div><div>The Let's Encrypt CP/CPS contains the following text:</div><div><br></div><div>-----</div><div>Section 4.9.12: Special requirements re key compromise</div><div>Key compromise must be demonstrated via the Certificate Revocation method of the ACME Protocol defined in RFC 8555, Section 7.6 by signing the request using the private key corresponding to the public key in the certificate</div><div>-----</div><div><br></div><div>We do on occasion block keys for other reasons (and in fact have already blocked the keys in draft-gutmann-testkeys-04), but this section attempts to state that the ACME API is the only method we accept for being made aware of key compromise. Perhaps this phrasing could be even clearer.<br></div><div><br></div><div>Aaron</div></div></div>