Re: [Jmap] Genart last call review of draft-ietf-jmap-smime-07

Alexey Melnikov <> Fri, 10 September 2021 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C25D53A0781; Fri, 10 Sep 2021 07:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ofQwJ39NS-MS; Fri, 10 Sep 2021 07:22:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 031443A077E; Fri, 10 Sep 2021 07:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1631283725;; s=june2016;; bh=VrqX1tcHsYPKCWOZBrpf1Ja5FEg6T2abFsMsolRmIiA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cxufgtw+9jDJmFn/GfxADYTwEr8wYzMQEaWmbDJOlrW9ntflyFgwa6uIOGiS2jETKiD3F0 JgXQx/k2FXZFHpIHzNMPoTiXLJdNjjaHjT05XIuAhiAJsZbub5Miw7Pv1lWFJPDmMpb2Fy 3puCfgRozer5HCy2kwqkxncbQ7OB5no=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 10 Sep 2021 15:22:04 +0100
To: Peter Yee <>,
References: <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Fri, 10 Sep 2021 15:21:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Jmap] Genart last call review of draft-ietf-jmap-smime-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Sep 2021 14:22:13 -0000

Hi Peter,

Thank you for your review.

On 07/09/2021 08:00, Peter Yee via Datatracker 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
> <>.
> 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?
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 
> Page 4, smimeErrors, 3rd sentence: the error may also be in the certificate
> chain.
Added, thanks.
> 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.
Fair enough. I think your exchange with Bron has some good suggestions.
> 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.
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,