Re: [Jmap] Warren Kumari's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 05 January 2022 17:17 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0453A1200; Wed, 5 Jan 2022 09:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level:
X-Spam-Status: No, score=-2.812 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOSDd8yQbtjj; Wed, 5 Jan 2022 09:17:35 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A257A3A11FD; Wed, 5 Jan 2022 09:17:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1641403050; d=isode.com; s=june2016; i=@isode.com; bh=ZOuklyWvl+Yf1VumOLoapSyGQ3/F76h60ACkHXHG9Ac=; 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=VDzKv9/7ZSLYCR1nCFCbzGXDzms+WIWUzUFGX8ZvMkBBauIW6sTeEnknoKoene3bU6UJcS AaNy+kJT/dpLet1lgdZXleSuLUwpKC70Kyy9lJgxJMA6+5Diae587LBbVH0HR2jU0Qxuzo 3Xl8qaapyiT8/GC83lNLFfB9KKHOEwo=;
Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <YdXSqQADl7mc@waldorf.isode.com>; Wed, 5 Jan 2022 17:17:30 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <c4ab1d0f-d540-50e2-149e-10f87e95b01d@isode.com>
Date: Wed, 05 Jan 2022 17:17:30 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: מנחם דודג' <menachemdodge1@gmail.com>, Warren Kumari <warren@kumari.net>
Cc: opsdir@ietf.org, brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, The IESG <iesg@ietf.org>, jmap-chairs@ietf.org
References: <163468502899.24369.8234838512678972724@ietfa.amsl.com> <CAJ2jOhVr0eZVq0CrbTxEAa_uDDu0gMSS-iV5KUD-NHgP7ZyTiw@mail.gmail.com> <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com>
In-Reply-To: <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------nCcV0DJXn9A1uxWT04h830Ym"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/VsujV3xEcKIsT5wlp0W9__43gIA>
Subject: Re: [Jmap] Warren Kumari's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 17:17:41 -0000

Hi Menachem,

As Warren pointed out, I've addressed most of your comments in earlier 
version. The upcoming -12 will clarify your comment #5:

> 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?
After further discussion with the WG, 10 minutes were changed to 24 
hours, which is a better period for certificate expiration. The value 
was determined empirically.

In regards to signature verification, I've added references to RFC 8551 
and RFC 8550 elsewhere in the document.

Best Regards,

Alexey


On 21/10/2021 14:59, Alexey Melnikov wrote:
>
> Hi Menachem/Warren,
>
> My apologies, I don't think I've seen the OpsDir review, so I will 
> reply to it separately.
>
> In regards to lack of "Updates: 8621": as this defines a JMAP 
> extension that doesn't modify the base JMAP protocol (other than 
> extending it), it is not customary to include "Updates: 8621". Or to 
> rephrase: a reader of RFC 8621 doesn't need to know about existence of 
> this document unless there is desire to implement it.
>
> Best Regards,
>
> Alexey
>
> On 20/10/2021 06:02, מנחם דודג' wrote:
>> Hello,
>>
>> I was not involved in any email discussions regarding my review.
>>
>> Thank you kindly.
>>
>> Best Regards,
>> Menachem
>>
>> ‫בתאריך יום ד׳, 20 באוק׳ 2021 ב-2:10 מאת ‪Warren Kumari via 
>> Datatracker‬‏ <‪noreply@ietf.org‬‏>:‬
>>
>>     Warren Kumari has entered the following ballot position for
>>     draft-ietf-jmap-smime-09: No Objection
>>
>>     When responding, please keep the subject line intact and reply to all
>>     email addresses included in the To and CC lines. (Feel free to
>>     cut this
>>     introductory paragraph, however.)
>>
>>
>>     Please refer to
>>     https://www.ietf.org/blog/handling-iesg-ballot-positions/
>>     for more information about how to handle DISCUSS and COMMENT
>>     positions.
>>
>>
>>     The document, along with other ballot positions, can be found here:
>>     https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/
>>
>>
>>
>>     ----------------------------------------------------------------------
>>     COMMENT:
>>     ----------------------------------------------------------------------
>>
>>     Thanks to Menachem Dodge for the OpsDir review; I see that the
>>     author has
>>     incorporated / addressed many of the comments/nits, but I don't
>>     think I saw any
>>     sort of discussion around the "Please consider whether the
>>     document header
>>     should indicate "Updates: 8621"." (which Benjamin also referenced).
>>
>>     It is entirely possible that I completely missed any discussions,
>>     but I'd be
>>     interested in an answer if possible.
>>