IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 17 August 2021 18:08 UTC

Return-Path: <mcr@sandelman.ca>
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 454113A27A2 for <spasm@ietfa.amsl.com>; Tue, 17 Aug 2021 11:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.489
X-Spam-Level:
X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 Df4FlwNd5xr8 for <spasm@ietfa.amsl.com>; Tue, 17 Aug 2021 11:08:15 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621AC3A2796 for <spasm@ietf.org>; Tue, 17 Aug 2021 11:08:15 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2620:120:9002:101:c29b:efaa:cb5d:348f]) by relay.sandelman.ca (Postfix) with ESMTPS id 4C6621F44D; Tue, 17 Aug 2021 18:08:13 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6E04B1A02EC; Tue, 17 Aug 2021 14:08:10 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
cc: LAMPS WG <spasm@ietf.org>
In-reply-to: <87sfz8m34p.fsf@fifthhorseman.net>
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>
Comments: In-reply-to Daniel Kahn Gillmor <dkg@fifthhorseman.net> message dated "Tue, 17 Aug 2021 12:45:26 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 17 Aug 2021 14:08:10 -0400
Message-ID: <407442.1629223690@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/k9f0epLfxtzIcjNm1wKIRCt-dcs>
Subject: Re: [lamps] 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, 17 Aug 2021 18:08:21 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
    >> Many people have spoken in support of this document, and two have
    >> spoken against.
    >>
    >> If it is to be adopted, an addition to the chart is needed:
    >>
    >> The LAMPS WG will support new definitions of objects registered in the
    >> following IANA registries: 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).
    >>
    >> What do people think about this approach?

    > The above strikes me as an extremely broad change to the charter,
    > permitting apparently arbitrary work within LAMPS as long as it manages
    > to touch those IANA registries.

    > Both objectors to and supporters of the proposed document-signing work
    > appear to be concerned about proliferation of Extended Key Usage (EKU)
    > OIDs with semantics that are ill-defined enough to produce interop
    > failures, and to potentially increase the costs of certificate
    > management.

Being charted to be able to make a billion EKUs doesn't mean that the WG or
the IESG will sign off on doing that.

    > But opening the charter wide to encompass any work that happens to
    > touch one of the arcs mentioned above seems like writing a blank check.
    > Maybe that's what the WG wants to do, but it doesn't look like it will
    > help the WG stay focused.

I want to avoid stopping work every 4 weeks to revise the charter.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email