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