On Tue, Jul 18, 2023 at 4:59 PM Clint Wilson via Servercert-wg < [email protected]> wrote:
> > - 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. > - 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? > > The Let's Encrypt CP/CPS contains the following text: ----- Section 4.9.12: Special requirements re key compromise 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 ----- 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. Aaron
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
