[Jmap] Robert Wilton's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Wed, 20 October 2021 09:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4EC3A095F; Wed, 20 Oct 2021 02:36:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <163472256651.12981.413656253938594590@ietfa.amsl.com>
Date: Wed, 20 Oct 2021 02:36:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/fIuFN41raiKhT6F30DNqZzsj6So>
Subject: [Jmap] Robert Wilton's No Objection on draft-ietf-jmap-smime-09: (with COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Oct 2021 09:36:16 -0000

Robert Wilton 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:
----------------------------------------------------------------------

Hi,

I have to confess that I don't know IMAP, and hence my question may have an
obvious answer, but it is unclear to me whether a server supporting the
smimeverify capability implies that it SHOULD also support checking the S/MIME
signature at delivery time?  If this is the case, should this be clarified,
perhaps in section 3?

I.e., section 3 states:
   Servers supporting
   _this_ specification MUST add a property called
   "urn:ietf:params:jmap:smimeverify" to the capabilities object.

E.g., section 4.1 states:

   signed:  S/MIME signed message, but the signature was not yet
      verified.  Some servers might not attempt to verify a signature
      until a particular message is requested by the client.  JMAP
      servers compliant with this document SHOULD return "signed/
      verified" or "signed/failed" instead of this signature status.

These two statements seem to imply that a server returning the smimeverify
capability SHOULD also support checking the S/MIME signature at delivery
because they SHOULD either return signed/verified or signed/failed for a
request for smimeStatusAtDelivery, which at least implies that they have
previously checked the signature when it was delivered.  Is that was is
intended?

Thanks,
Rob