[lamps] Paul Wouters' Yes on draft-ietf-lamps-documentsigning-eku-05: (with COMMENT)

Paul Wouters via Datatracker <noreply@ietf.org> Tue, 23 August 2022 16:57 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 9B994C14F73B; Tue, 23 Aug 2022 09:57:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lamps-documentsigning-eku@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, housley@vigilsec.com, housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.14.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <166127382763.13969.2657445663675576159@ietfa.amsl.com>
Date: Tue, 23 Aug 2022 09:57:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/u0v8wRcMq9hhRmdVp9n-z3MWuKg>
Subject: [lamps] Paul Wouters' Yes on draft-ietf-lamps-documentsigning-eku-05: (with COMMENT)
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: Tue, 23 Aug 2022 16:57:07 -0000

Paul Wouters has entered the following ballot position for
draft-ietf-lamps-documentsigning-eku-05: Yes

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/about/groups/iesg/statements/handling-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-lamps-documentsigning-eku/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Security AD comments for {draft-ietf-lamps-documentsigning-eku-04}
CC @paulwouters

## Comments:

### humans

   The term "Document Signing" in this document refers to digitally
   signing contents that are consumed by people.  To be more precise,
   contents are intended to be shown to a person with printable or
   displayable form by means of services or software, rather than
   processed by machines.

Is there a reason to only include human readers and not machines? Why not
leave it to users to decide how to use this?

### key usage vs KU

   The EKU extension can be used in conjunction with the key usage extension

Would it make sense to call that the KU extension, or key usage (KU) extension

### Section 4 humans again

   The signed contents of Internet-Drafts are primarily intended to be
   consumed by people.

### RFCs is people?

What is this "signed contents of Internet-Drafts" ? Should that be "signed
contents of Documents" ?

### single example?

   When a single application has the capability to process various data
   formats, the software may choose to make the excluded and permitted
   decisions separately in accordance with the format it is handling
   (e.g. text, pdf, etc).

Why is this text in the document? It seems kinda out of scope.

### Section 6 allows squatting?

   This general
   document signing KeyPurposeId may be used as a stop-gap for those
   that intend to define their own KeyPurposeId

It seems weird for this document to say "this is for document signing, but hey
go squat on this value for other uses if that's convenient".


## NITS

### Section 1

[RFC5280]  is a broken link

I can't parse: the usage can easily become out of control.

weird use of "-" in:  use. - If the

Paragraph 3 in Section 1 is in its entirety hard to parse.

### Section 3

[RFC5280] is a broken link