Skip to main content

Last Call Review of draft-ietf-jmap-smime-07
review-ietf-jmap-smime-07-opsdir-lc-dodge-2021-09-01-00

Request Review of draft-ietf-jmap-smime
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2021-09-06
Requested 2021-08-23
Authors Alexey Melnikov
I-D last updated 2021-09-01
Completed reviews Artart Last Call review of -08 by Kirsty Paine (diff)
Genart Last Call review of -07 by Peter E. Yee (diff)
Opsdir Last Call review of -07 by Menachem Dodge (diff)
Genart Telechat review of -09 by Peter E. Yee (diff)
Assignment Reviewer Menachem Dodge
State Completed
Request Last Call review on draft-ietf-jmap-smime by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/16V_Ww3SaZbiWveeBztQCbaQq0k
Reviewed revision 07 (document currently at 12)
Result Has nits
Completed 2021-09-01
review-ietf-jmap-smime-07-opsdir-lc-dodge-2021-09-01-00
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.

The document explains the need to add an extension to JMAP for returning S/MIME
signature verification status. The document is written clearly.

Please consider whether the document header should indicate "Updates: 8621".

Nits:

1. Section 4:  Paragraph 5 - *smimeStatusAtDelivery*:
The brackets:

OLD==> (It effectively the same as "smimeStatus" value
 calculated at the date/time of deliver, as specified by
 "receivedAt".)
Suggested==> (It is effectively the same as the "smimeStatus" value
 calculated at the date/time of delivery, as specified by "receivedAt".)

2. Section 4: Paragraph 7 beginning with ' smimeStatus: "String|null". '
OLD==> ' Client MUST treat unrecognized values as "unknown" or "signed/failed".
' SUGGESTED==> ' Clients MUST treat unrecognized values as "unknown" or
"signed/failed". '

3. Section 4: Paragraphs 8,9,10 and 11. Missing colon following the first word
of the paragraph, this word being the possible string values of the property.
 Suggest that it be:        "unknown:" , "signed:" , signed/verified:", 
 "signed/failed:"

4. It would be useful to add additional actual examples of  messages - and to
refer to them in the text. So for the paragraph on "smimeErrors" it would be
useful to refer to the Example 2 below. It would be good to have an additional
example  showing the case where: "For example, the signing certificate might be
 expired and the message From email address might not correspond to
 any of the email addresses in the signing certificate."

5. In section 6 "Security Considerations" - it would be nice to have some
additional explanation of the recommendation to cache the results for 10
minutes. Is this to be done on the server side or at the client? Should there
be a reference here to other documents on signature verification?

Thank you kindly.

Menachem Dodge