IETF Logo Mail Archive

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

Carl Wallace <carl@redhoundsoftware.com> Thu, 29 July 2021 21:49 UTC

Return-Path: <carl@redhoundsoftware.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 F39213A005E for <spasm@ietfa.amsl.com>; Thu, 29 Jul 2021 14:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=redhoundsoftware.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 TNjvv3UlJfmA for <spasm@ietfa.amsl.com>; Thu, 29 Jul 2021 14:49:43 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27D73A003D for <spasm@ietf.org>; Thu, 29 Jul 2021 14:49:42 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id h27so5003073qtu.9 for <spasm@ietf.org>; Thu, 29 Jul 2021 14:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=QaqXILl4yxecW4Ssct4hZK3zOA/1Ts/OpKSj7ggbwsk=; b=XMI85GvZOuzeVIo+qZbdiIJit9I4VmvS3jUqj0wB5erXBpxV7ThoqkAC+v5RnO/iJ5 1sa8JeKByiX66jUWfkJHm+kf/YQWXVCDvazTVbqQMVQoGK2k0dtMxkNFa9Ucisu8+9gP aXSxC07UABU4znMak6joCwwu0T3ThCjIRvIb0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=QaqXILl4yxecW4Ssct4hZK3zOA/1Ts/OpKSj7ggbwsk=; b=gsO7HtPvey9ivLVBGC4fdjMYXqW8zKNDJ1FMFXAUY2Z7cgqWuv11IxoKvyhz7UGDrp G7HsC6bQlFJc8kO0EbyUkOg65yTvsuCH4BqnBcJWE5YMROuuceuJwT1VJAcmvJTl1ho8 Ri8TAzYQUolB3SoJlQcBzfdDN6kJ+lG+d4z/jtnwp8NL/9Of9jyqbNTiIM3d/Kl2kAlu Um6TKNhv3ANxv+EIbhn1+0255c7Ejs1FX5D33YajwKAFEGayNz/XNrTHKfgekpbDJ9vp FxovMVnfp8TlJffqMfwasZxDnbsgBTuz+qwJIF1ky7xFw8zcHx2cdT3k4L9gpunJ02Dx 0TqQ==
X-Gm-Message-State: AOAM5302lIMydlPtFiDgPNNS9AhuVUyaU8hk5g+fMDp881tr8gc3/0xF 3CWZ8Pq1MwRFlGTAcNK9/4rdbw==
X-Google-Smtp-Source: ABdhPJwAG2C2btvXvhyunNqDwY4iCxHlWV+kRNBMQ7diTzCMwpKt+uaJPoJ9kC/cnVbDVlbuco9yjw==
X-Received: by 2002:ac8:70d2:: with SMTP id g18mr1539645qtp.58.1627595380906; Thu, 29 Jul 2021 14:49:40 -0700 (PDT)
Received: from [192.168.2.16] (pool-173-73-191-214.washdc.fios.verizon.net. [173.73.191.214]) by smtp.gmail.com with ESMTPSA id l4sm2477108qkd.77.2021.07.29.14.49.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 14:49:40 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.51.21071101
Date: Thu, 29 Jul 2021 17:49:39 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
CC: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, LAMPS WG <spasm@ietf.org>, "Cooley, Dorothy E" <decoole@nsa.gov>, Deb Cooley <debcooley1@gmail.com>
Message-ID: <FBDAE4CD-317E-4E10-B8DC-A60EAA04AF1C@redhoundsoftware.com>
Thread-Topic: [lamps] Call for adoption for draft-ito-documentsigning-eku
References: <CAErg=HFqfek5titw0R_yp2aZBZJQiWXVhRWc1g9O+bst_2tkyA@mail.gmail.com> <CC5594C7-5338-40FE-8366-7CC7A994F8B7@redhoundsoftware.com> <CAErg=HH3SprO0YMEtSnxgv57K0receHakHNH=u3ms_TzutTxRQ@mail.gmail.com>
In-Reply-To: <CAErg=HH3SprO0YMEtSnxgv57K0receHakHNH=u3ms_TzutTxRQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3710425780_1263188730"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/GpxC1doUFvzdTLhqBKBXFGwnrxg>
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: Thu, 29 Jul 2021 21:49:48 -0000

 

 

On Thu, Jul 29, 2021 at 5:27 PM Carl Wallace <carl@redhoundsoftware.com> wrote:

Sure but given cert lifetime management is relatively tight now and the implementations you likely care about more easily updated, EKU2 could be written to match reality and be deployed without glacial delay. You’d just need a new OID and some processing language. 

 

I may be misunderstanding, but that seems to be just saying "Ah, but if you can't spec the existing, widely implemented behaviour, which fully conforms to the spec, you should change all the implementations to a new behaviour that does the exact same thing as the existing behaviour, and maybe you can spec it then"

 

Everything I've stated about EKU on this thread is both fully consistent with RFC 5280 _and_ fully consistent with 20 years of discussion in PKIX/LAMPS, as to why I don't support this draft. I'm unclear if you're saying that, however true that may be, every implementation should change, in order to make some vocal folks in this WG... happy?

 

[CW] I am also not saying anything to make “vocal folks” happy but instead am saying a spec for each camp might be the best way. At least then the situation would be documented. Without two specs there is only perpetual “widely implemented” vs “documented”. Who does that serve? A spec for each camp worked for cert enrollment protocols:-) Note, I am not against changing the current definition, but don’t much care for folklore.

v2.23.0 | Report a Bug | By Email