[Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

[Tim Hollebeek]

It is not entirely clear that a CA can use its CPS to enforce new requirements on third parties that are reporting key compromises in BR-compliant ways.  I get why it might be attractive to do so, but people should focus their efforts on fixing the BR language instead of just unilaterally claiming the right to fix it in their own CPS.

If a CA receives a BR-compliant problem report, I would expect it to be handled in a BR-compliant manner, including inspection of any evidence to see if it meets 4.9.1.1 (3), and taking appropriate action if it does.  If you don’t wanna, a better set of BRs is only a ballot away.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Aaron Gable via Servercert-wg
Sent: Wednesday, July 19, 2023 11:54 AM
To: Clint Wilson <clintw at apple.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

On Tue, Jul 18, 2023 at 4:59 PM Clint Wilson via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230719/af5692db/attachment-0001.html>