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

[Wayne Thayer]

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