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 <[email protected]>
*Sent:* Monday, July 17, 2023 5:28 PM
*To:* Wayne Thayer <[email protected]>; ServerCert CA/BF
<[email protected]>
*Cc:* Tim Hollebeek <[email protected]>
*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
<[email protected]> 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
<[email protected]> 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 <[email protected]> On Behalf Of Melinda
Shore via Datatracker
Sent: Tuesday, July 4, 2023 8:33 PM
To: [email protected]
Cc: [email protected]; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
