<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Tim,<br>
<br>
<div class="moz-cite-prefix">On 18/7/2023 5:59 μ.μ., Tim Hollebeek
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:010001896983bc72-51c83d47-993f-4a07-9d55-44df19c8dcff-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Part of the problem here is a lack of a
shared understanding of what it means to bind a keypair to an
identity.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.</p>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:010001896983bc72-51c83d47-993f-4a07-9d55-44df19c8dcff-000000@email.amazonses.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
I agree with your comments but as you very well know, the
attack/abuse cases are not negligible and are very hard to mitigate.<br>
<br>
<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:010001896983bc72-51c83d47-993f-4a07-9d55-44df19c8dcff-000000@email.amazonses.com">
<div class="WordSection1">
<p class="MsoNormal">-Tim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div
style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Clint Wilson
<a class="moz-txt-link-rfc2396E" href="mailto:clintw@apple.com"><clintw@apple.com></a> <br>
<b>Sent:</b> Monday, July 17, 2023 5:28 PM<br>
<b>To:</b> Wayne Thayer <a class="moz-txt-link-rfc2396E" href="mailto:wthayer@gmail.com"><wthayer@gmail.com></a>;
ServerCert CA/BF <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Cc:</b> Tim Hollebeek
<a class="moz-txt-link-rfc2396E" href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a><br>
<b>Subject:</b> Re: [Servercert-wg] [secdir] Secdir last
call review of draft-gutmann-testkeys-04<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Wayne,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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 <i>also</i> not necessarily increasing the
meaningful security provided by the BRs. Is that correct?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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 <i>not</i> 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.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is separate, in my mind, to any
potential interpretation that would expect CAs to go out
and <i>look</i> 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 <i>looking</i> 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 <a
href="http://pwnedkeys.com" moz-do-not-send="true">pwnedkeys.com</a> and
I could see that, and related topics, coming up again
with <a
href="https://www.ietf.org/archive/id/draft-mpalmer-key-compromise-attestation-00.txt"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-mpalmer-key-compromise-attestation-00.txt</a>).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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 <a
href="https://github.com/cabforum/servercert/issues/442"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/cabforum/servercert/issues/442</a> to
track this if there’s further interest in ensuring the BRs
could address this worry.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Clint<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jul 7, 2023, at 3:13 PM, Wayne
Thayer via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Thanks for sharing this Tim.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Wayne<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jul 5, 2023 at
11:43 AM Tim Hollebeek via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">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).<br>
<br>
-Tim<br>
<br>
-----Original Message-----<br>
From: secdir <<a
href="mailto:secdir-bounces@ietf.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">secdir-bounces@ietf.org</a>>
On Behalf Of Melinda Shore via Datatracker<br>
Sent: Tuesday, July 4, 2023 8:33 PM<br>
To: <a href="mailto:secdir@ietf.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">secdir@ietf.org</a><br>
Cc: <a
href="mailto:draft-gutmann-testkeys.all@ietf.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">draft-gutmann-testkeys.all@ietf.org</a>;
<a href="mailto:last-call@ietf.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">last-call@ietf.org</a><br>
Subject: [secdir] Secdir last call review of
draft-gutmann-testkeys-04<br>
<br>
Reviewer: Melinda Shore<br>
Review result: Ready<br>
<br>
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).<br>
<br>
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.<br>
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.<br>
<br>
Anyway, this is a tidy, well-written document
that does exactly what it sets out to do, and
it's ready.<br>
<br>
<br>
_______________________________________________<br>
secdir mailing list<br>
<a href="mailto:secdir@ietf.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">secdir@ietf.org</a><br>
<a
href="https://www.ietf.org/mailman/listinfo/secdir" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.ietf.org/mailman/listinfo/secdir</a><br>
wiki: <a
href="https://trac.ietf.org/trac/sec/wiki/SecDirReview" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://trac.ietf.org/trac/sec/wiki/SecDirReview</a><br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>