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

Wayne Thayer wthayer at gmail.com
Fri Jul 7 22:13:31 UTC 2023

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230707/bdca6bfb/attachment.html>

More information about the Servercert-wg mailing list