IETF Logo Mail Archive

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

Ryan Sleevi <ryan-ietf@sleevi.com> Thu, 29 July 2021 21:31 UTC

Return-Path: <ryan.sleevi@gmail.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 645B83A08CE for <spasm@ietfa.amsl.com>; Thu, 29 Jul 2021 14:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 nfJRMe_8aUXt for <spasm@ietfa.amsl.com>; Thu, 29 Jul 2021 14:31:39 -0700 (PDT)
Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 050C93A08CC for <spasm@ietf.org>; Thu, 29 Jul 2021 14:31:38 -0700 (PDT)
Received: by mail-pl1-f171.google.com with SMTP id t21so8495219plr.13 for <spasm@ietf.org>; Thu, 29 Jul 2021 14:31:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6yt2FkRxSR0MaJkp//t7vwVjjtDjnulIk5vSvk3ecZ4=; b=Rh1PY5GEzTl6PKKwVmodmAynviiIFirzISgmrlQIoutVs36B0Tmx5jlwFq7O0J6bI7 i99jRZcmXYTi/yAgvmj8OWmKAEcCZSljKf2h26+v5s54HF4TUkhkIu+zflhDKwOP1DfJ EBl3BQ6iTy0Kv28btPuLwuvzw0XljXaMuli0xcaNHdcF5jUItCuez/Ztur2h+FIvVS7p QUVdcIV6wEHLEjfd14sLjJef0akDWaRTdOY8zX32OW8Ngu3/4LrpxoRi9B7fx4wjRKk2 CB8USy56ikIoqche7TcQflxxBJeFwsx7uleTMy03SnhUkeLBxLlzaWRBbNJGghXyMJ16 QekQ==
X-Gm-Message-State: AOAM532dacQ/sE1GFF8j5XDZrZasuh0GfBX6S1fLhKX6U3Lyrsg92w3C strNsoUrwYAI6XAWLGS3GjnAkHliYGE=
X-Google-Smtp-Source: ABdhPJzAghPwXpmY94xryEpbBJpy6mAvB+kKhwqP8wKoandExzdbYZUkqHLoJTE0Cyh1o6l1+7wbJw==
X-Received: by 2002:a62:dec1:0:b029:32d:1f6:3890 with SMTP id h184-20020a62dec10000b029032d01f63890mr7127978pfg.13.1627594298056; Thu, 29 Jul 2021 14:31:38 -0700 (PDT)
Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com. [209.85.216.48]) by smtp.gmail.com with ESMTPSA id o8sm4340601pjm.21.2021.07.29.14.31.37 for <spasm@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 14:31:37 -0700 (PDT)
Received: by mail-pj1-f48.google.com with SMTP id mt6so12183734pjb.1 for <spasm@ietf.org>; Thu, 29 Jul 2021 14:31:37 -0700 (PDT)
X-Received: by 2002:a05:6a00:124b:b029:358:fcd2:fa37 with SMTP id u11-20020a056a00124bb0290358fcd2fa37mr7013996pfi.35.1627594297296; Thu, 29 Jul 2021 14:31:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAErg=HFqfek5titw0R_yp2aZBZJQiWXVhRWc1g9O+bst_2tkyA@mail.gmail.com> <CC5594C7-5338-40FE-8366-7CC7A994F8B7@redhoundsoftware.com>
In-Reply-To: <CC5594C7-5338-40FE-8366-7CC7A994F8B7@redhoundsoftware.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Thu, 29 Jul 2021 17:31:26 -0400
X-Gmail-Original-Message-ID: <CAErg=HH3SprO0YMEtSnxgv57K0receHakHNH=u3ms_TzutTxRQ@mail.gmail.com>
Message-ID: <CAErg=HH3SprO0YMEtSnxgv57K0receHakHNH=u3ms_TzutTxRQ@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, LAMPS WG <spasm@ietf.org>, "Cooley, Dorothy E" <decoole@nsa.gov>, Deb Cooley <debcooley1@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000edcc8e05c849d3ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/gaCLsfzEE69-8FNSGTEUiQBGLs4>
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:31:44 -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?

>

v2.23.0 | Report a Bug | By Email