[lamps] Opsdir last call review of draft-ietf-lamps-rfc5750-bis-06

Éric Vyncke <evyncke@cisco.com> Fri, 04 May 2018 12:18 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4FA126BF0; Fri, 4 May 2018 05:18:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke <evyncke@cisco.com>
To: ops-dir@ietf.org
Cc: spasm@ietf.org, draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.79.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152543633033.11713.14519946575146524568@ietfa.amsl.com>
Date: Fri, 04 May 2018 05:18:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/7MGyTpmNAnmDI67uw34H-cjaxPg>
Subject: [lamps] Opsdir last call review of draft-ietf-lamps-rfc5750-bis-06
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2018 12:18:50 -0000

Reviewer: Éric Vyncke
Review result: Ready

Reviewer: Eric Vyncke
Review result: Ready

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.

Document reviewed: draft-ietf-lamps-rfc5750-bis-06
Intended Status: Standards Track

As the title indicates, this document is about how certificates are to be
handled by a S/MIME client; both for sending and receiving. It is well written
and clear.

Section 1.3 to 1.6 are explicitly about compatibility and interoperation with
previous version of the S/MIME specification.

Section 4 is about the provisioning of the certificates of other parties. In
the absence of a protocol for this purpose, the proposed technique is archaic
and manual; far from being easy for operations but I am afraid that there is no
other choice.

Section 4.3 specifies key lengths, which also means that another RFC will have
to be authored when those key lengths will become too weak.

In case of trouble or invalid certificates, the only specified action is to
inform the end user; which is again the usual procedure when dealing with