[lamps] Secdir last call review of draft-ietf-lamps-documentsigning-eku-05

Nancy Cam-Winget via Datatracker <noreply@ietf.org> Mon, 22 August 2022 19:35 UTC

Return-Path: <noreply@ietf.org>
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 CAAB1C1524DF; Mon, 22 Aug 2022 12:35:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Nancy Cam-Winget via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-lamps-documentsigning-eku.all@ietf.org, last-call@ietf.org, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.14.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166119691582.15164.2568316001434410524@ietfa.amsl.com>
Reply-To: Nancy Cam-Winget <ncamwing@cisco.com>
Date: Mon, 22 Aug 2022 12:35:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/skKwmcoxh-6XJMrFKbNIhRZ_NBM>
Subject: [lamps] Secdir last call review of draft-ietf-lamps-documentsigning-eku-05
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 22 Aug 2022 19:35:15 -0000

Reviewer: Nancy Cam-Winget
Review result: Ready

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.

This document describes a KeyPurposeId for document signing.  As written, the
document is straightforward and on point. I only have the following editorial

Introduction: 2nd paragraph first sentence may have extraneous "also"?
The paragraph is describing when both code signing and S/MIME are used
 how adverse affects can occur; but given the long length of the sentence
it reads awkwardly.

Section 6: this may be redundant (or rhetorical) but worth mentioning. Ass this
is now a new id-kp for document signing (e.g. id-kp-documentSigning), would it
be an error Or a "no op" if there was the presence now of the combination of
the old use e.g. id-kp-emailProtection, id-kp-codSigning and
id-kp-documentSigning? I don't think is further breaks or worsens current
security considerations, but its handling And expected behavior may be worth a