Subject: [Gen-art] Genart last call review of draft-ietf-jmap-smime-07

From: Peter Yee via Datatracker <[email-masked]>
Date: Tue, 07 Sep 2021 00:00:03 -0700

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 07 Sep 2021 22:09:32 +1000

> are well described. [Ready with issues]

Thanks for the detailed review Peter!  I'll leave the specific nits to Alexey as author.  Good point with the "rationale for trusting the server".  We did discuss this during the early meetings when this draft came up, and considered that this would most likely be used within an organisation which controls both the client and the server.  JMAP is particularly well suited to very simple and light-weight clients.

It's envisioned that JMAP clients may even be a simple widget which displays some details like mailbox counters or previews of the most recent few messages.  By having the server side do S/MIME validation, a client can simply check a property to display an icon next to a preview without being a full S/MIME client.  Obviously this isn't something you would do where you didn't trust the server absolutely!

It seems reasonable to me to add some text that summarizes this understanding in the introduction, along with the existing "requires the client to trust server verification code" in the security considerations.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 7 Sep 2021 21:19:39 -0700

Thanks for that Bron. I suspected there was a discussion about this topic in
the WG, but that it simply wasn't reflected in the I-D. For those of us who
haven't kept up, adding a little bit of that discussion into the
introductory material would help a lot. 

                                Kind regards,

                                -Peter

From: Bron Gondwana <[email-masked]> 
Sent: Tuesday, September 07, 2021 5:10 AM
To: Peter Yee <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-jmap-smime-07

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

for it and the consequences of trusting the server to perform the
verification

Thanks for the detailed review Peter!  I'll leave the specific nits to
Alexey as author.  Good point with the "rationale for trusting the server".
We did discuss this during the early meetings when this draft came up, and
considered that this would most likely be used within an organisation which
controls both the client and the server.  JMAP is particularly well suited
to very simple and light-weight clients.

It's envisioned that JMAP clients may even be a simple widget which displays
some details like mailbox counters or previews of the most recent few
messages.  By having the server side do S/MIME validation, a client can
simply check a property to display an icon next to a preview without being a
full S/MIME client.  Obviously this isn't something you would do where you
didn't trust the server absolutely!

It seems reasonable to me to add some text that summarizes this
understanding in the introduction, along with the existing "requires the
client to trust server verification code" in the security considerations.

Cheers,

Bron.

--

  [email-masked] <mailto:[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Sep 2021 15:21:58 +0100

Hi Peter,

Thank you for your review.

> delegating its verification to a server. Is signature verification so onerous?
I think this depends on the goals. There is cost of writing/testing the 
code, as well as the cost of bandwidth. For clients that try to minimize 
bandwidth used to display a message, client side S/MIME signature 
verification in the most generic case is very expensive, as it requires 
downloading the whole message, even body parts that the user doesn't 
necessarily care about. (JMAP's philosophy is to only download 
information that is needed, which is much smaller than the whole message 
content).
> Page 4, smimeErrors, 3rd sentence: the error may also be in the certificate
Added, thanks.
> knows that it is an example and what it intends to show.
Added.
> forgone conclusion that a client would want to do this without much explanation.
Fair enough. I think your exchange with Bron has some good suggestions.
> Style Guide indicating a standardized meaning for the characters.
I copied this from the original JMAP draft, but I agree that this should 
be reviewed/rationalized.
> Do not put a colon after the title of each example (e.g., "Example 1:")
I expected these to appear above the block. So I removed them now.
> Specific:

Thank you, I addressed all of your nits.

Best Regards,

Alexey