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

Tue Jul 18 14:59:27 UTC 2023

Part of the problem here is a lack of a shared understanding of what it means to bind a keypair to an identity.

It’s perfectly reasonable to argue that a certification authority’s only role is to verify the identity (which could be a domain name), and associate the owner’s chosen public key with it in a digital certificate.  Whether that individual or organization has chosen its public key wisely or not could be on them.  I do not subscribe to this view, but it isn’t unreasonable.

Remember, after all, we don’t even verify whether they own the private key associated with that public key, and for good reason.  There are legitimate use cases where requiring proof of possession makes the world worse instead of better.  Because of this, an certificate applicant may end up with a public key bound to their identity that they are completely unable to use.  And this is harmless, as has been extensively discussed every time someone successfully chooses Let’s Encrypt’s root public key as their public key.

It DOES probably make the world a better place if certification authorities police weak or badly chosen keys, as people make all sorts of mistakes, and if someone unknowingly uses a weak or compromised key, bad things happen.  CAs are the experts in the ecosystem, and customers are not.  Catching those sorts of things is certainly a valuable service CAs can provide to customers.  But is this a REQUIRED service?  Exactly how much effort is worthwhile, as the potential investment can range from zero to nearly infinite?

If it is an auditable minimum requirement, we need to be pretty explicitly clear what the minimum bar is.  This is very different from a SHOULD requirement, where we can be a bit handwavy, or an industry best practice, which doesn’t necessarily even need to be standardized.

One of the reasons I’ve been supportive of at least something similar to the Palmer draft at IETF is because I think it would be very helpful if the expectations in this area were much clearer.  Having an explicit standard for “here’s how you prove a key is compromised” and “here is the central list of keys you shouldn’t issue for” and “here’s the carefully crated requirements we’ve thought carefully about that include all the boring considerations like what to do if/when that source is unreachable” would be a huge improvement.

-Tim

From: Clint Wilson <clintw at apple.com> 
Sent: Monday, July 17, 2023 5:28 PM
To: Wayne Thayer <wthayer at gmail.com>; ServerCert CA/BF <servercert-wg at cabforum.org>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

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.

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.)

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 <http://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).

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.

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

On Jul 7, 2023, at 3:13 PM, Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Thanks for sharing this Tim.

I want to comment on the statement that CAs should blocklist the keys published in this RFC. Doing that may very well be helpful to the CA and their customers, but I do not believe it is a requirement set forth by the CAB Forum or root store policy.

Prior discussions on this topic have not resulted in requirements beyond the clarification of BR 6.1.1.3(4): "The CA has previously been made aware that the Applicant’s Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;". My worry is that we will begin interpreting "has previously been made aware" as inclusive of keys published in a RFC that Tim sent to the mailing list, without any bounds or guidance on where else CAs must look for compromised keys (e.g. scanning online databases and software packages). I don't necessarily intend to start a big debate about this, but rather just hope to avoid confusion about the current requirements and expectations.

- Wayne

On Wed, Jul 5, 2023 at 11:43 AM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Just wanted to make sure CAs are aware of the Gutmann testkeys draft, which will be an RFC soon.  CAs should add these keys to the list of keys they refuse to issue certificates for (because the private keys have been disclosed publicly).

-Tim

-----Original Message-----
From: secdir <secdir-bounces at ietf.org <mailto:secdir-bounces at ietf.org> > On Behalf Of Melinda Shore via Datatracker
Sent: Tuesday, July 4, 2023 8:33 PM
To: secdir at ietf.org <mailto:secdir at ietf.org> 
Cc: draft-gutmann-testkeys.all at ietf.org <mailto:draft-gutmann-testkeys.all at ietf.org> ; last-call at ietf.org <mailto:last-call at ietf.org> 
Subject: [secdir] Secdir last call review of draft-gutmann-testkeys-04

Reviewer: Melinda Shore
Review result: Ready

The use of the plural "PKCs" surprised me a bit, but that's a taste question rather than a substantive one.  I've verified that the test keys in the document are usable and that the struct representation produces the same keys as the PEM encodings in the draft (there are some unsurprising differences in the PEM encoding of the keys by different libraries, but the actual contents are identical).

I recently retired from a CA and when the -00 version of the draft was uploaded we had some discussion of whether or not these were keys that we'd need to add to the "badkeys" list (i.e. keys for which certificates can't be issued), and since the document is going to RFC it's now clearly the case that we'd need to.
 It may be worth sending a heads-up to the CA/B Forum about that.  It's also common now to see test vectors included in protocol specifications (or adjacent to protocol specifications) and I wonder if it's possible to encourage document authors to use these keys where appropriate.

Anyway, this is a tidy, well-written document that does exactly what it sets out to do, and it's ready.

_______________________________________________
secdir mailing list
secdir at ietf.org <mailto:secdir at ietf.org> 
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230718/a1e6d12c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5120 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230718/a1e6d12c/attachment-0001.p7s>