Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05

Jim Schaad <ietf@augustcellars.com> Thu, 03 May 2018 00:01 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4441126DED; Wed, 2 May 2018 17:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7hQ7tR_OfoNr; Wed, 2 May 2018 17:01:23 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E46126BF6; Wed, 2 May 2018 17:01:23 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 16:58:44 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Matthew Miller' <linuxwolf+ietf@outer-planes.net>, secdir@ietf.org
CC: spasm@ietf.org, draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf@ietf.org
References: <152432458128.20660.6956595430755199355@ietfa.amsl.com>
In-Reply-To: <152432458128.20660.6956595430755199355@ietfa.amsl.com>
Date: Wed, 02 May 2018 17:01:14 -0700
Message-ID: <054301d3e271$dc22db10$94689130$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIiXucpxcMduUMNivilcG+pvhU0KKOAJOiA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/jWAFhJe3iFnh8t0OviWZE0eS4Xc>
Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Thu, 03 May 2018 00:01:26 -0000


> -----Original Message-----
> From: Matthew Miller <linuxwolf+ietf@outer-planes.net>
> Sent: Saturday, April 21, 2018 8:30 AM
> To: secdir@ietf.org
> Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; ietf@ietf.org
> Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05
> 
> Reviewer: Matthew Miller
> Review result: Has Nits
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> Document: draft-ietf-lamps-rfc5750-bis-05
> Reviewer: Matthew A. Miller
> Review Date: 2018-04-21
> IETF LC End Date: 2018-04-27
> IESG Telechat date: N/A
> 
> Summary:
> 
> This document is ready, but there is one nit around PKCS #6 handling that
> might benefit from explanation.
> 
> This document describes the certificate handling expectations for senders
> and receivers of S/MIME 4.0.  It obsoletes RFC 5750, adding requirements to
> support internationalized email addresses, increase RSA minimum key sizes,
> and support ECDSA using P-256 and Ed25519; older algorithms such as DSA,
> MD5, and SHA-1 are relegated to historical.
> 
> Major Issues: N/A
> 
> Minor Issues: N/A
> 
> Nits:
> 
> Section 2.2.1. "Historical Note about CMS Certificates" is almost entired
> unchanged, but added a requirement that receivers MUST be able to process
> PCKS #6 extended certificates.  This almost seems at odds with the rest of
> the paragraph that precedes this MUST, noting PKCS #6 has little use and
> PKIX is functionally equivalent.
> A short explanation of why this additional handling requirement would seem
> helpful.

How about the following which is just a description of what we are looking for in terms of behavior.

   Receiving agents MUST be able to parser and process a message containing PKCS #6 extended certificates although ignoring those certificates is expected behavior.