S/MIME Example Keys and Certificates
RFC 9216
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Roman Danyliw Yes
Alvaro Retana No Objection
Erik Kline No Objection
Francesca Palombini No Objection
John Scudder No Objection
Lars Eggert No Objection
Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/mflhoJqZWKiXwKjyiy2xzxTsVj4). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.3. , paragraph 3, nit: - (see the CRL Disttribution Points X.509 extension as defined in - -
Murray Kucherawy No Objection
I agree with Benjamin that it doesn't seem like RFC 5322 needs to be normative here.
Robert Wilton No Objection
Hi, Only one minor nit on the security considerations: Any application which maintains a denylist of invalid key material SHOULD include these keys in its list. Having this as a SHOULD seemed very broad to me, I would suggest "recommended to" instead. Regards, Rob
Éric Vyncke No Objection
Thank you for the work put into this document. Congrats to use UTF-8 charset for some nice graphics and for the example names. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tim Hollebeek for the shepherd's write-up including the section about the WG consensus (even if very terse). I hope that this helps to improve the document, Regards, -éric -- Section 2.2 & 2.3 -- Would it be useful to include expired certificates ? And/or a CRL for those examples ? Would providing those additional examples make possible more extensive testing? -- Section 4 -- <joke>Please s/Alice Lovelace/Ada Lovelace/ ;-) </joke> (to be ignored of course but I could not resist) Alas not applicable to Charles/Bob Babbage or Alan/Carlos Turing or Grace/Dana Hopper :-)
(Benjamin Kaduk; former steering group member) No Objection
Thanks for producing these; they should be really useful for future development and testing. Should we say that the private keys are represented as the RFC 5958/PKCS#8 structure, and that the RFC 8479 validation parameters attribute is included? At least, I think that's what it looks like... Section 13.1 It's not really clear to me that RFC 5322 needs to be classified as normative. Section 13.2 RFC 7468 seems like it ought to be classified as normative, since it specifies the formats we use.