Last Call Review of draft-ietf-lamps-rfc5750-bis-06
review-ietf-lamps-rfc5750-bis-06-opsdir-lc-vyncke-2018-05-04-00
Request | Review of | draft-ietf-lamps-rfc5750-bis |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2018-04-27 | |
Requested | 2018-04-13 | |
Authors | Jim Schaad, Blake C. Ramsdell , Sean Turner | |
I-D last updated | 2018-05-04 | |
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 | Éric Vyncke |
State | Completed | |
Request | Last Call review on draft-ietf-lamps-rfc5750-bis by Ops Directorate Assigned | |
Reviewed revision | 06 (document currently at 08) | |
Result | Ready | |
Completed | 2018-05-04 |
review-ietf-lamps-rfc5750-bis-06-opsdir-lc-vyncke-2018-05-04-00
Reviewer: Eric Vyncke Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-lamps-rfc5750-bis-06 Intended Status: Standards Track As the title indicates, this document is about how certificates are to be handled by a S/MIME client; both for sending and receiving. It is well written and clear. Section 1.3 to 1.6 are explicitly about compatibility and interoperation with previous version of the S/MIME specification. Section 4 is about the provisioning of the certificates of other parties. In the absence of a protocol for this purpose, the proposed technique is archaic and manual; far from being easy for operations but I am afraid that there is no other choice. Section 4.3 specifies key lengths, which also means that another RFC will have to be authored when those key lengths will become too weak. In case of trouble or invalid certificates, the only specified action is to inform the end user; which is again the usual procedure when dealing with certificates.