Last Call Review of draft-ietf-lamps-rfc5750-bis-05

Request Review of draft-ietf-lamps-rfc5750-bis
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-27
Requested 2018-04-13
Authors Jim Schaad, Blake Ramsdell, Sean Turner
Draft last updated 2018-04-21
Completed reviews Opsdir Last Call review of -06 by √Čric Vyncke (diff)
Genart Last Call review of -05 by Ines Robles (diff)
Secdir Last Call review of -05 by Matthew Miller (diff)
Genart Telechat review of -06 by Ines Robles (diff)
Assignment Reviewer Matthew Miller
State Completed
Review review-ietf-lamps-rfc5750-bis-05-secdir-lc-miller-2018-04-21
Reviewed rev. 05 (document currently at 08)
Review result Has Nits
Review completed: 2018-04-21


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document: draft-ietf-lamps-rfc5750-bis-05
Reviewer: Matthew A. Miller
Review Date: 2018-04-21
IETF LC End Date: 2018-04-27
IESG Telechat date: N/A


This document is ready, but there is one nit around PKCS #6 handling
that might benefit from explanation.

This document describes the certificate handling expectations for
senders and receivers of S/MIME 4.0.  It obsoletes RFC 5750, adding
requirements to support internationalized email addresses, increase
RSA minimum key sizes, and support ECDSA using P-256 and Ed25519;
older algorithms such as DSA, MD5, and SHA-1 are relegated to

Major Issues: N/A

Minor Issues: N/A


Section 2.2.1. "Historical Note about CMS Certificates" is almost
entired unchanged, but added a requirement that receivers MUST be
able to process PCKS #6 extended certificates.  This almost seems
at odds with the rest of the paragraph that precedes this MUST,
noting PKCS #6 has little use and PKIX is functionally equivalent.
A short explanation of why this additional handling requirement
would seem helpful.