S/MIME Example Keys and Certificates
draft-ietf-lamps-samples-08

I agree with Benjamin that it doesn't seem like RFC 5322 needs to be normative here.

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 :-)

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.

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
-                    -

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