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

Mike Ounsworth <Mike.Ounsworth@entrust.com> Tue, 24 August 2021 19:24 UTC

Return-Path: <Mike.Ounsworth@entrust.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 6DAFA3A0D82 for <spasm@ietfa.amsl.com>; Tue, 24 Aug 2021 12:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com
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 Z6edWXH_JHP8 for <spasm@ietfa.amsl.com>; Tue, 24 Aug 2021 12:24:05 -0700 (PDT)
Received: from mx07-0015a003.pphosted.com (mx07-0015a003.pphosted.com [185.132.183.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F453A0DB7 for <spasm@ietf.org>; Tue, 24 Aug 2021 12:24:05 -0700 (PDT)
Received: from pps.filterd (m0242864.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 17OExQma017187; Tue, 24 Aug 2021 14:24:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=mail1; bh=eqYjlfmFX4uoOEfYUhmsUgTUv8o+SU5l9DVLbG9L4Nw=; b=Vnf9Y/2Xywo3zbbDMchW+yv/YcemGnjx2IA2MudzqK2z38QxV9GlNnc+3uM1vKPIC20a LjeCUv9HBKVAYYDK0SWMdtPOvC51aMtJx6qEBA6wTlgokTIDBkeHG5XR9B9RDpmJsbFI mcojmCqH3eEpxlOVuhKOV8d/mg6TFIoDSAOMp0BPom451B6nnKEg10dh+H33kBzm51a+ g2fsIGF/DqpETQzFF3J7Lf77A9TzljNthSdCSPvCDdO5Fi906qYN28++0uRaZVJaXMIq xrzUHQhviLiJA3AMk9cvLWu5sr3/d+3rzRRM0VDDyMS6eiP3uTqvjNtLQdfyv05hfoU/ hg==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2103.outbound.protection.outlook.com [104.47.70.103]) by mx08-0015a003.pphosted.com with ESMTP id 3amkmrjmbh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Aug 2021 14:24:02 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VLW+w1T9qAXbmNnWX8jsdjKiKvv5FalRTnBDz3pnfqkPxmpB8GfxEqLa5PJioU3bcerHXdjt2hNDxqwfT1vMSWtyZmQKLMGaBtHJIVI785Uk61Pt2F2NJKeqOe3rn69E2259oUThwea8mAj+5spLiwZyDu3UI9pno/Q3UliSNteOuKmHEE03arVEz7S8w7Des9kSqiErCydWRFrZCz/ki3Ha7rjd32Hi6tWYFQvYyxc4eEAO98b99Xi2K4nUQjMulBr1TW2funWTZk4PX7Ra9qDkFTImfRVHMKn4G7ldrMpl87NSuWZKHRXBKdmMhan1adW1QHikLqN/doU2yy+HPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eqYjlfmFX4uoOEfYUhmsUgTUv8o+SU5l9DVLbG9L4Nw=; b=oek0KNxTp/okCZQqIikM5znCxkHow+2/cypGBvmTyObNEyuJ0a9dWwFZoZMFohDkDTzjcyyYm0c/clCMpx7RIWxHIqP9UZC0p9WvtlKXXvDlh2GLWDoerFZOxh4TDwlmdg6sxg2RPAEW0qeuzkNTPhH3z7cYrZiJwPx6Rf0IRWbTx+j6CJJ/IXw5WEQiLsa6EhXeEqmnk6eepPXlsFxwfN0WJZqiD9TrH7yS8RpONG/OKMLAtr1TFaPNWxsf7Y0E6S3pBTwalNC44Fz56+rQ1jZn/GgBvPsj+No34ULfeQThlZ5FQZeSFtofM7JKNYjHas1uFclEkh39+dD+PslRKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by CH0PR11MB5361.namprd11.prod.outlook.com (2603:10b6:610:b8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Tue, 24 Aug 2021 19:23:59 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::add2:5c10:f40:939e]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::add2:5c10:f40:939e%4]) with mapi id 15.20.4436.025; Tue, 24 Aug 2021 19:23:59 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: Russ Housley <housley@vigilsec.com>
CC: LAMPS WG <spasm@ietf.org>
Thread-Topic: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku
Thread-Index: AQHXg/V5IRZWaHWny0SOl4Ou8R6Ny6t2tZKAgAFREgCAABcdAIAAL1cAgALbSoCACAclAIAAASIQgAABdQCAAAD7UA==
Date: Tue, 24 Aug 2021 19:23:59 +0000
Message-ID: <CH0PR11MB5739E6DA75C72ACB75AEE0D29FC59@CH0PR11MB5739.namprd11.prod.outlook.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> <35A25818-D87E-4B00-8472-21E4A9FE4893@vigilsec.com>
In-Reply-To: <35A25818-D87E-4B00-8472-21E4A9FE4893@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=entrust.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4218fcd1-5a39-4711-7f55-08d96734b979
x-ms-traffictypediagnostic: CH0PR11MB5361:
x-microsoft-antispam-prvs: <CH0PR11MB5361510D6DE3FACFC3FFE5619FC59@CH0PR11MB5361.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WgBEyhF3xXzI9BojhrjjAUMUHCwVVCen3skIcUxJQLuHl9L52NAewT6kBfKGcjtI4UgdvoDdh7BNwTdkkB18XM2ap1tel02qtY2Cs0PlSNzxbHwzP+Ge25/dUTi59I0wmJwi9J0GIMU2y9kurxAe1hDPrfX505K2iI4id4+trnGCYHnL5WdNgNb99CZ/gqbTCum1YExne6319Xq9ciqP6/5SbIZqbVyqLdMFfYJaITgI5WSwzHdiDMJbysuhnVik1IylB4UagJtkWUrNl1WR5l9HxnXnsfzh2cEZBdl3uIV6A5S+yWe1HQiCnIspDDs0LNDB4G2+UUpbWnq0wYUgfuvonmBOdB4HUBhjAwbdYhnMro0HsvfiLkRJIJgrB0pvd8DjvYUD2r1BjFWH24zqZKf9jxoMEq1L9v01N+xcJ5QEpKNd8fH1jY4hHXAgumtw9mKCgwuFvjsDRRqwJQdX9mpYMqn/LVgsHWfXy/FnxYjW/rOrNJlYRiLwLmGhJQYQBUyE+uM+E3Lk+rJQqsStJvyQP0ONzXrGzTvPS+6k8LvlRz9Uw2LfYXB42y7MpYPyjv3K1aD5ofbwpqK6r5xHt4ebf5CQil53d0xdJoLHze+F7x7/l7xXVEOpsjSyvAZdtLt8DhttDXvLtDOG2HMQPqF/IjYMYxLjrqSAA6Q6y6cM0IsPZlVvZTIoRe4AHUCEQBvjXIGtAbfGq6URAIz/Bw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5739.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(76116006)(33656002)(66476007)(66556008)(64756008)(66446008)(6506007)(53546011)(52536014)(71200400001)(186003)(4326008)(9686003)(66946007)(8676002)(6916009)(26005)(83380400001)(316002)(2906002)(8936002)(122000001)(38070700005)(508600001)(38100700002)(7696005)(86362001)(5660300002)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: vDToGxDuwlMOX7kuv67w1Zok2glt3CkJLVn9Mws5fw+Td812vktYaUk5PLOWkgrSCdcY5qyt+QCXem4gcydK3U6HrYIzHW7CpLL4Dmmll5vgwfSZMWrN+k4w3lNAD9clYF/dEvby0iDvNb8/dB6MFJ+k2SnyPlqVSifVW50u5PACk241ZYGrDLXapsnUvZsnrsR9YbZPXMCV7GzkkySIALa3wD9OEVFJHGbPjURAVZ3psfBiCanzZmk1yvBiDjUPMIyVWe7mKW04VZoUncsCwO/+w2p9NFMHZvWA5dchOmGUFecL01+jy4lmbxApXucrtO1g+GdUSBQKHQtsllmUIG3hx7J4WegxUD0h87U67yvIuBmCUb9AJ64hVMovbLqqylDC2XVkuWCnvVc3/1jxKEmMUsUVv51uW98pH/LhDEXhyRZaRIK1PLYD5LoqE9H0VN4efc5OocGGxKJ6tRd1Dv7WS8E0M6tX3f8Z0fiX6lGIpAX0ilRxOjyp6kFPTjI/bCiLowSmEP3vbcfREXgnz6sm4mRjGPyVtM17vfUc/gWdR11LWvM4g8BSVxjFSGo4DEOZAwaLNC5F1mcNgdXMqRKM0Bg1dTEEk227golwE3uESpKF1JuRnb4YE8t0Ng9dHgG3tBJjDAxBlZIvQyk6BmdPTWx6tYvmt06fWVwGRAWoqgV8VSPXxZjKcTwqir7dHNZNmb04iFN8HNap0G+IqMZuEKKoxtOyDms52RhMev654gHUN3RDCxMRXbNONSeb8rNdCCHDbzTHEVfF25DYrAhpjFd54xZc6eWaaRUGQ717AxSXndgYEaB5aWt/UznUkcF+85s78p66aTXg7eeonSjT0JVkd7wqcruOMr+y5P9zh0ijgc8VJEvXMyfffQzz9kFn74nsUFrS+fMLUGougSwIwV22ZXIysX+jsqL4MfoRMpzfgjx9e8Q/n2lQjJVHUtiRgzt6GJqm4Qqjb9LwwKcfTTo9miU+xnXzakyZV10MVv5P72MYK4k4rr0ta7urh/N0aL98yaSgDB47wujOuiU9DwhPX3ut06EZl+zjJEZpa0QpbU47jaLUREtyEIaSgE+egA4yHIcTsW4Zw/kO2mrqhlIx1bg9AYhTWnmlTFo7GuJmdNXUzzLBun/4woUyjvZJW/iwvDxa4iHZr2CTJwAwkQI4rPE69/mSJwkh6unMPbA9QOIxkKaiynRCZT+E5nU4p1/Sf33/dGY4s3Xfd7yaW0bh1RRSUoYhr8OZssf/AVh7LScFZMwdoxrLRLYJzRp+e6J5/VhnHNjINPBUbjjnYxgRidVLjiyTdugcOsg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH0PR11MB5739E6DA75C72ACB75AEE0D29FC59CH0PR11MB5739namp_"
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4218fcd1-5a39-4711-7f55-08d96734b979
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2021 19:23:59.5173 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MMoLBdLW7U2JB7bmI26jEJ2Xfp4+bpihwRuh2kI0uvTxE/9FaXAlSYWaZCIR412b9MrkmxpXtjttDJPbEW3qvkeLNXRv721o7bLcMjG79wE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5361
X-Proofpoint-GUID: LQQKLqt-UcVEyyKxoUtrGSxYcYYNbot_
X-Proofpoint-ORIG-GUID: LQQKLqt-UcVEyyKxoUtrGSxYcYYNbot_
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-08-24_06,2021-08-24_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=957 bulkscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108240122
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/dbnJu3TEA7OOKlmVZLKDGIFLS-w>
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:24:13 -0000

Makes sense.

I'm sure that over the years, LAMPS has had no lack of submissions that smell like proprietary solutions.

---
Mike Ounsworth

From: Russ Housley <housley@vigilsec.com>
Sent: August 24, 2021 2:20 PM
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>
Cc: LAMPS WG <spasm@ietf.org>
Subject: Re: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

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<mailto: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.