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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Tue Jul 18 17:27:35 UTC 2023

Hi Tim,

On 18/7/2023 5:59 μ.μ., Tim Hollebeek via Servercert-wg wrote:
> 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.

However, CAs DO check for proof of private key possession if there is a 
Certificate Problem Report where a key is reported to be compromised, 
and according to the rules if the reporter proves possession of a 
private key, the CA must revoke all certificates associated with that 
key. As you said, CAs don't follow a similar process for certificate 
enrollment which seems a bit inconsistent but based on the corresponding 
risks, it makes sense to be more stringent for revocation cases than for 
the issuance of new certificates.

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

I agree with your comments but as you very well know, the attack/abuse 
cases are not negligible and are very hard to mitigate.


> -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 and,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 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,, and, 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> 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 "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
>;". 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> 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> On Behalf Of Melinda
>         Shore via Datatracker
>         Sent: Tuesday, July 4, 2023 8:33 PM
>         To: secdir at ietf.org
>         Cc: draft-gutmann-testkeys.all at ietf.org; 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
>         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
>         https://lists.cabforum.org/mailman/listinfo/servercert-wg
>     _______________________________________________
>     Servercert-wg mailing list
>     Servercert-wg at cabforum.org
>     https://lists.cabforum.org/mailman/listinfo/servercert-wg
> _______________________________________________
> Servercert-wg mailing list
> 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/46a0323d/attachment-0001.html>

More information about the Servercert-wg mailing list