Last Call Review of draft-ietf-lamps-documentsigning-eku-05
review-ietf-lamps-documentsigning-eku-05-secdir-lc-cam-winget-2022-08-22-00
Request | Review of | draft-ietf-lamps-documentsigning-eku |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-08-11 | |
Requested | 2022-07-28 | |
Authors | Tadahiko Ito , Tomofumi Okubo , Sean Turner | |
I-D last updated | 2022-08-22 | |
Completed reviews |
Genart Last Call review of -04
by Dale R. Worley
(diff)
Secdir Last Call review of -05 by Nancy Cam-Winget (diff) |
|
Assignment | Reviewer | Nancy Cam-Winget |
State | Completed | |
Request | Last Call review on draft-ietf-lamps-documentsigning-eku by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/e8WdDB9Y2vwlnzKGv5E48bpAMN8 | |
Reviewed revision | 05 (document currently at 06) | |
Result | Ready | |
Completed | 2022-08-22 |
review-ietf-lamps-documentsigning-eku-05-secdir-lc-cam-winget-2022-08-22-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. This document describes a KeyPurposeId for document signing. As written, the document is straightforward and on point. I only have the following editorial nits. NIT: Introduction: 2nd paragraph first sentence may have extraneous "also"? The paragraph is describing when both code signing and S/MIME are used how adverse affects can occur; but given the long length of the sentence it reads awkwardly. Section 6: this may be redundant (or rhetorical) but worth mentioning. Ass this is now a new id-kp for document signing (e.g. id-kp-documentSigning), would it be an error Or a "no op" if there was the presence now of the combination of the old use e.g. id-kp-emailProtection, id-kp-codSigning and id-kp-documentSigning? I don't think is further breaks or worsens current security considerations, but its handling And expected behavior may be worth a mention.