Define (or reference an existing definition for) the expected method by which CAs are "made aware"

[clintwilson]

Sections 4.9.1.1, 4.9.1.2, and 6.1.1.3 place requirements on CAs when they are or have been "made aware" of certain information, however whether there are limitations on what could constitute the CA being made aware is not clear.
4.9.1.1 and 4.9.1.2 already have the requirements of 4.9.2 and 4.9.3 to lean on, but I think we could remove ambiguity here by defining a, or clarifying the use of an already defined, method by which concerned parties can share compromised keys with CAs.

I'd currently lean towards simply reusing the Certificate Problem Report as that mechanism, but also want to ensure we're not introducing arbitrary or challenging barriers for compromised keys to be shared with CAs, especially when considering a large data set being disclosed (e.g. requiring one Certificate Problem Report per key would be an overreach imo). I would appreciate discussion and rough consensus on the best approach.
There might also be value in lightly reviewing other things that a CA can be informed of and which would require action by the CA thereafter, but which don't use the specific "made aware" language. Such things could perhaps also be folded into this centralization of official CA communication channel(s) -- avoiding a ton of scope creep if possible.

[wthayer]

Circling back around to this given the recent publication of RFC 9500 (test keys). @barrini I think this is a topic worthy of prioritization and discussion in the SCWG. Here's a link to the previous discussion: https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html