Hi Melinda, Thanks for your review and the independent confirmation that the struct representations of the private keys match the PEM encoding. Here's the (hacky) Python script that generated the PEM encodings from the struct representations in case anyone would like to see: https://gist.github.com/CBonnell/2c1108bcacb4c9bc3137537efdafdaf2. Thanks, Corey -----Original Message----- From: Melinda Shore via Datatracker <noreply@xxxxxxxx> Sent: Tuesday, July 4, 2023 8:33 PM To: secdir@xxxxxxxx Cc: draft-gutmann-testkeys.all@xxxxxxxx; last-call@xxxxxxxx Subject: 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
