Re: [lamps] [EXTERNAL] Re: Call for adoption for draft-ito-documentsigning-eku

Russ Housley <housley@vigilsec.com> Tue, 24 August 2021 19:20 UTC

Return-Path: <housley@vigilsec.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 D87393A0D7F for <spasm@ietfa.amsl.com>; Tue, 24 Aug 2021 12:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 9r0UltM4ke5q for <spasm@ietfa.amsl.com>; Tue, 24 Aug 2021 12:19:59 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781DE3A0D7E for <spasm@ietf.org>; Tue, 24 Aug 2021 12:19:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 00D11300BFC for <spasm@ietf.org>; Tue, 24 Aug 2021 15:19:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5KOLGPs3Qxe2 for <spasm@ietf.org>; Tue, 24 Aug 2021 15:19:55 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C7634300BF4; Tue, 24 Aug 2021 15:19:55 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <35A25818-D87E-4B00-8472-21E4A9FE4893@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FB4ED2C-4CEF-4FDA-B273-CE2470EAF2D8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Tue, 24 Aug 2021 15:19:54 -0400
In-Reply-To: <CH0PR11MB57395C1A892C211BA0AAC4699FC59@CH0PR11MB5739.namprd11.prod.outlook.com>
Cc: LAMPS WG <spasm@ietf.org>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>
References: <CD589623-52EE-4958-80AB-73F0CFB3A36E@vigilsec.com> <19561F5C-1EED-4D7E-81EB-210A2B47556C@vigilsec.com> <BE91DB62-683E-4AD6-9E0D-B11CCC247E5F@vigilsec.com> <87sfz8m34p.fsf@fifthhorseman.net> <407442.1629223690@dooku> <D8AF50F7-05EF-40C6-8ADC-2F5E82FEC910@vigilsec.com> <CAErg=HE1_8jux58_XegD3UXz6ovyrhkc8mxHBdUgL0gNgt1EJA@mail.gmail.com> <67DC5185-F440-4B2B-B2A0-CAC1BAD68A06@vigilsec.com> <CH0PR11MB57395C1A892C211BA0AAC4699FC59@CH0PR11MB5739.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/kCAPwHDKRYPP-K4f_cc8JKNYMLs>
Subject: Re: [lamps] [EXTERNAL] Re: Call for adoption for draft-ito-documentsigning-eku
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 24 Aug 2021 19:20:06 -0000

Remember that to top of the charter says:

   The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working 
   Group is chartered to make updates where there is a known constituency 
   interested in real deployment and there is at least one sufficiently 
   well specified approach to the update so that the working group can 
   sensibly evaluate whether to adopt a proposal.

I was trying to align with that context.

The traditional definition for rough consensus for the document is adequate from my perspective.

Russ


> On Aug 24, 2021, at 3:15 PM, Mike Ounsworth <Mike.Ounsworth@entrust.com> wrote:
> 
> Do you need a critical mass of interested implementors, or is a single constituent enough?
>  
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>  
> From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> On Behalf Of Russ Housley
> Sent: August 24, 2021 2:11 PM
> To: LAMPS WG <spasm@ietf.org <mailto:spasm@ietf.org>>
> Subject: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku
>  
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> All:
>  
> Obviously any document that would make an assignment in any of the PKIX or S/MIME registries needs consensus, with the possible exception of the module OIDs, which have no impact on interoperability.
>  
> I agree that we want the WG to only make new assignments where there is intent to implement.  How about the following?
>  
>   The LAMPS WG will support new definitions of objects registered in the following
>   IANA registries when there is a known constituency interested in real deployment
>   of the new registration: SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16)
>   and SMI Security for PKIX (1.3.6.1.5.5.7).
>  
> To be clear about the scope, I have copied the topic associate with these registries below.
>  
> The PKIX OID registry covers:
>  
> SMI Security for PKIX Module Identifier
> SMI Security for PKIX Certificate Extension
> SMI Security for PKIX Policy Qualifier
> SMI Security for PKIX Extended Key Purpose
> SMI Security for PKIX CMP Information Types
> SMI Security for PKIX CRMF Registration
> SMI Security for PKIX CRMF Registration Controls
> SMI Security for PKIX CRMF Registration Information
> SMI Security for PKIX Algorithms
> SMI Security for PKIX CMC Controls
> SMI Security for PKIX CMC GLA Requests and Responses
> SMI Security for PKIX Other Name Forms
> SMI Security for PKIX Personal Data Attributes
> SMI Security for PKIX Attribute Certificate Attributes
> SMI Security for PKIX Qualified Certificate Statements
> SMI Security for PKIX CMC Content Types
> SMI Security for PKIX OIDs Used Only for Testing
> SMI Security for PKIX Certificate Policies
> SMI Security for PKIX CMC Error Types
> SMI Security for PKIX Revocation Information Types
> SMI Security for PKIX SCVP Check Types
> SMI Security for PKIX SCVP Want Back Types
> SMI Security for PKIX SCVP Validation Policies and Algorithms
> SMI Security for PKIX SCVP Name Validation Policy Errors
> SMI Security for PKIX SCVP Basic Validation Policy Errors
> SMI Security for PKIX SCVP Distinguished Name Validation Policy Errors
> SMI Security for PKIX Other Logotype Identifiers
> SMI Security for PKIX Proxy Certificate Policy Languages
> SMI Security for PKIX Proxy Matching Rules
> SMI Security for PKIX Subject Key Identifier Semantics 
>  
> The S/MIME OID Registry covers:
>  
> SMI Security for S/MIME Module Identifier
> SMI Security for S/MIME CMS Content Type
> SMI Security for S/MIME Attributes
> SMI Security for S/MIME Algorithms
> SMI Security for S/MIME Certificate Distribution Mechanisms
> SMI Security for S/MIME Signature Policy Qualifier 
> SMI Security for S/MIME Commitment Type Identifier
> SMI Security for S/MIME Test Security Policies 
> SMI Security for S/MIME Control Attributes for Symmetric Key Distribution 
> SMI Security for S/MIME Signature Type Identifiers 
> SMI Security for X.400 Encoded Information Types (EIT) for S/MIME objects 
> SMI Security for S/MIME Capabilities (other than cryptographic algorithms)
> SMI Security for S/MIME Portable Symmetric Key Container (PSKC) Attributes
> SMI Security for S/MIME Other Recipient Info Identifiers 
>  
> Russ
>  
> On Aug 19, 2021, at 12:34 PM, Ryan Sleevi <ryan-ietf@sleevi.com <mailto:ryan-ietf@sleevi.com>> wrote:
>  
>  
>  
> On Tue, Aug 17, 2021 at 4:57 PM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> DKG:
> 
> I suppose it does allow many OIDs to be assigned.  I was trying to come up with a way to allow simple documents that assign an OID and achieve WG consensus to move along without too much administrative overhead.
>  
> Is that the goal of LAMPS? That is, such generic assignment seems to run counter to the (present) charter of being Limited, with known constituencies interested in real deployment with at least one sufficiently well-specified approach. The generic OID assignment seems to run counter to that, and reintroduce the issues of PKIX.
>  
> Assigning new OIDs equally seems to run counter to simplify clarify existing PKIX and S/MIME WG documents; typically, a new OID would be used to describe new functionality, rather than clarify existing.
>  
> That's not to say we can't charter to become PKIX 2.0, if that's the explicit goal, but it does seem to be a shift from a closed set to a very open set, as flagged by DKG.
>  
> While Michael mentions wanting to avoid stopping work every 4 weeks for a recharter, I'd be remiss if I didn't mention my goal is to ensure we don't become PKIX 2.0 where we continue to add to the ever growing, ever unnecessary, ever uninteroperable set of features that we call PKIX, and I worry this language would.
>  
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.