Subject: Re: [Last-Call] Genart last call review of draft-ietf-jmap-smime-07

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Oct 2021 14:28:24 +0300

Peter, thank you for your review. I have entered a No Objection ballot for this document.

Lars

> On 2021-9-7, at 10:00, Peter Yee via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Peter Yee
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-jmap-smime-07
> Reviewer: Peter Yee
> Review Date: 2021-09-06
> IETF LC End Date: 2021-09-06
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document provides a JMAP extension that allows the JMAP server to
> provide its thoughts on the verification of a messages S/MIME signature.  While
> the details of the extension seem fine, I'm not convinced that the rationale
> for it and the consequences of trusting the server to perform the verification
> are well described. [Ready with issues]
> 
> Major issues: None
> 
> Minor issues:
> 
> Page 2, section 1: There really ought to be a description of why a client would
> want to do this and why it would trust the results. This is taking a decision
> on something that is normally an end-to-end property of a message and
> delegating its verification to a server. Is signature verification so onerous?
> 
> Page 4, smimeErrors, 3rd sentence: the error may also be in the certificate
> chain.
> 
> Page 5 and 6 examples: Put an introduction before each example so the reader
> knows that it is an example and what it intends to show.
> 
> Page 7, section 6: I think a stronger description of the implications of doing
> server-side verification is merited. The document is written as though it is a
> forgone conclusion that a client would want to do this without much explanation.
> 
> Nits/editorial comments:
> 
> General:
> 
> The use of asterisks and underscores for emphasis or for offsetting various
> items is not explained. The usage is also inconsistent. I note that RFC 8621
> does some of this as well, but I think it would be preferable to abstain from
> extravagant use of these characters unless their significance is explained.
> Sometimes items are marked with asterisks, other times with quotation marks. I
> find it all rather off-putting and could not find anything in the RFC Editor's
> Style Guide indicating a standardized meaning for the characters.
> 
> Do not put a colon after the title of each example (e.g., "Example 1:")
> 
> Specific:
> 
> Page 2, section 1, 2nd paragraph: insert "the" before "multipart/signed media"
> and "application/pkcs7-mime".
> 
> Page 2, section 3, 1st sentence: change "the JMAP spec" to "[RFC8621]". This
> obviates the need to use underscores around the following "this".
> 
> Page 3, section 4, 1st paragraph, 1st sentence: insert "the" before "Email/get".
> 
> Page 3, *smimeStatus*: insert "the" before the final '"smimeStatus"'.
> 
> Page 3, *smimeErrors*: insert "the" before the final '"smimeErrors"'.
> 
> Page 3, *smimeVerifiedAt*: insert "the" before the final '"smimeVerifiedAt"'.
> 
> Page 3, *smimeStatusAtDelivery*, 1st sentence: insert "the" before the final
> '"smimeStatusAtDelivery"'.
> 
> Page 3, *smimeStatusAtDelivery*, 2nd sentence: insert "is" before "effectively
> ". Insert "the" before '"smimeStatus"'. Change "deliver" to "delivery".
> 
> Page 3, smimeStatus, 2nd real sentence: change "This" to "Otherwise, this".
> 
> Page 3, smimeStatus, 4th real sentence: change "Client" to "Clients".
> 
> Page 3, smimeStatus, unknown, 1st sentence: delete the comma after "signed".
> 
> Page 3, smimeStatus, unknown, 2nd sentence: insert "an" before "unknown".
> 
> Page 3, smimeStatus, signed, 2nd sentence: insert "a" before "signature".
> 
> Page 3, smimeStatus, signed/verified: insert "the" before "sender matches".
> Append a comma after "field".
> 
> Page 4, 1st non-status paragraph, 1st sentence: delete the comma after
> '"smimeStatus"'. Insert "is" before "calculated".
> 
> Page 4, 1st non-status paragraph, 2nd sentence: insert "the" before "S/MIME".
> Change "it helps to" to "to help".
> 
> Page 4, smimeErrors, 1st sentence: insert "the" before "S/MIME".
> 
> Page 4, smimeErrors, 2nd sentence: append a comma after "I.e.".
> 
> Page 4, smimeErrors, 3rd sentence: insert "the" before "Content-Language ".
> 
> Page 4, smimeErrors, 6th sentence: insert "a" before "CRL".
> 
> Page 4, smimeVerifiedAt, 2nd sentence: insert "the" before "S/MIME".
> 
> Page 4, smimeVerifiedAt, 3rd sentence: insert "an" before "S/MIME".
> 
> Page 4, last paragraph, 1st sentence: change "it's" to "its".
> 
> Page 5, 1st paragraph: append a comma after "server".
> 
> Page 6, 1st paragraph after Example 2, 1st sentence: insert "the" before
> "Email/query".
> 
> Page 7, section 6, 1st paragraph, 1st sentence: change "Server side" to
> "Server-side". Insert "the" before "server".
> 
> Page 7, section 6, 2nd paragraph, 1st sentence: insert "a" before "Denial".
> 
> Page 7, section 6, 2nd paragraph, 2nd sentence: append a comma after "reason".
> 
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call