Skip to main content

S/MIME Example Keys and Certificates
RFC 9216

Yes

Roman Danyliw

No Objection

Alvaro Retana
Erik Kline
Francesca Palombini
John Scudder

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

Comment (2022-01-03 for -07)
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

Comment (2022-01-05 for -07)
I agree with Benjamin that it doesn't seem like RFC 5322 needs to be normative here.

Robert Wilton No Objection

Comment (2022-01-05 for -07)
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

Comment (2022-01-03 for -07)
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

No Objection (2022-01-05 for -07)
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.