Skip to main content

Last Call Review of draft-ietf-lamps-rfc5750-bis-05
review-ietf-lamps-rfc5750-bis-05-secdir-lc-miller-2018-04-21-00

Request Review of draft-ietf-lamps-rfc5750-bis
Requested revision 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 C. 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 A. Miller (diff)
Genart Telechat review of -06 by Ines Robles (diff)
Assignment Reviewer Matthew A. Miller
State Completed
Review review-ietf-lamps-rfc5750-bis-05-secdir-lc-miller-2018-04-21
Reviewed revision 05 (document currently at 08)
Result Has Nits
Completed 2018-04-21
review-ietf-lamps-rfc5750-bis-05-secdir-lc-miller-2018-04-21-00
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

Summary:

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

Major Issues: N/A

Minor Issues: N/A

Nits:

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.