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

[Wayne Thayer]

Hi Clint,

Thank you for helping to unpack my concerns.

On Mon, Jul 17, 2023 at 2:28 PM Clint Wilson <clintw at apple.com> wrote:

> Hi Wayne,
>
> I’d like to better understand your worry and perhaps interpretation of BR
> 6.1.1.3(4) and 4.9.1.1(3,4,16). Just to restate for my benefit, the concern
> is that: IF we interpret Tim’s message regarding the testkeys draft as
> qualifying the keys present in the draft as “[All] CAs [subscribed to the
> Servercert-wg list being] made aware that [a future] Applicant’s Private
> Key has suffered a Key Compromise….” THEN, in a similar situation, any
> servercert-wg member could share any number of compromised keys here and,
> theoretically, bloat (with no upper bounds) the set of known compromised
> keys a CA has to retain and check in order to reject certificate requests
> as needed to meet the requirements of 6.1.1.3 WHILE *also* not
> necessarily increasing the meaningful security provided by the BRs. Is that
> correct?
> As a concrete example (an extreme I could imagine), someone could
> generate, and potentially delete, 100 or 100,000,000,000 keypairs easily
> (for a value of “easily” most associated with effort rather than time or
> resources), share a CSV, or even just pointer to a repository/document,
> with the Servercert-wg, and (if interpreted per your worry) cause a bunch
> of keys never intended to be used for actual certificate issuance to be
> forever part of a set of keys which all CAs must check every received
> certificate request against.
>
>
The magnitude of the problem is not my primary concern, but that is
something to consider.


> Notable to this worry, I think, is that nothing about the language in in
> the BRs today indicates to me that Tim’s message or the above, somewhat
> silly, scenario would *not* be interpreted to qualify as a reason to
> reject those associated keys. That is, if a CA subscribed to this mailing
> list and conforming to the BRs, issued a certificate to a key in the
> testkeys draft after July 4, 2023, it seems that the BRs would consider
> that a misissuance as there’s no limitation or specification regarding what
> (or whether) any specific bar is met in order to constitute “the CA [being]
> made aware”. 4.9.3 I think comes quite close, but stops short of saying
> something like “For the purposes of requirements in 4.9.1.1, 4.9.1.2, and
> 6.1.1.3, the CA MAY require a Certificate Problem Report to be submitted in
> order to constitute being made aware of reasons to reject certificate
> requests or revoke certificates.” which I think would remove the current
> ambiguity regarding what needs to happen in order for a CA to need to begin
> rejecting certificate requests for compromised keys. (Note, I’m not saying
> this change is a good or well-thought-out idea, just what came to mind as
> one option to increase clarity in a way that would address the worry
> raised.)
>
>
My understanding is that you believe the BRs require every CA reading this
message to add the keys in draft-gutmann-testkeys-04 to their blocklist.
That is precisely what I was worried about. I seriously doubt that all CAs
have made that same determination. I'm not opposed to your interpretation,
but as Tim stated, 'If it is an auditable minimum requirement, we need to
be pretty explicitly clear what the minimum bar is.'

On a side note, under your interpretation of 6.1.1.3, even accepting a
certificate request for one of the keys contained in that draft is a BR
violation.


> This is separate, in my mind, to any potential interpretation that would
> expect CAs to go out and *look* for compromised keys elsewhere. “Looking"
> implies to me a proactive effort, whereas “made aware” is much more passive
> and would seemingly include any receipt of information by the CA (or its
> official representatives?). More to the point, I don’t see any implication
> that CAs should be *looking* for compromised keys in the current BR text,
> which hopefully helps with part of the worry (though adding something like
> that as a requirement has been discussed before, iirc, especially in the
> context of pwnedkeys.com and I could see that, and related topics, coming
> up again with
> https://www.ietf.org/archive/id/draft-mpalmer-key-compromise-attestation-00.txt
> ).
>
>
Has everyone reading this now been made aware of pwnedkeys.com???

Aside from highlighting the ambiguity, I agree that 'been made aware' does
not imply 'seeking out'.


> While I don’t foresee near-term, major, and negative impact from my
> interpretation of the BRs, I do think we can maintain the intent of the
> requirement without leaving it as open as a rough analogue to a zip bomb.
> While I proposed something purely for illustration above, I’ve also filed
> https://github.com/cabforum/servercert/issues/442 to track this if
> there’s further interest in ensuring the BRs could address this worry.
>
>
Thank you for filing that issue. Relying on problem reporting mechanisms is
a reasonable solution that might be relatively easy to build consensus
around.

- Wayne

As always, please let me know if I’ve missed some crucial detail or
> interaction here that’s led me to an erroneous conclusion on the topic.
> Cheers!
> -Clint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230718/bcb4f68f/attachment.html>