[Servercert-wg] FW: [secdir] Secdir last call review of draft-gutmann-testkeys-04
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 22.214.171.124(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 126.96.36.199;". 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.
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).
> -----Original Message-----
> From: secdir <secdir-bounces at ietf.org> On Behalf Of Melinda Shore via
> 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
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg