Re: What ASN.1 got right

Michael Thomas <mike@mtcc.com> Wed, 03 March 2021 03:00 UTC

Return-Path: <mike@fresheez.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A363A178A for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 19:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 Km2Nu8O7G3hD for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 19:00:39 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 3B7413A1789 for <ietf@ietf.org>; Tue, 2 Mar 2021 19:00:39 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id b15so3270091pjb.0 for <ietf@ietf.org>; Tue, 02 Mar 2021 19:00:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jT5Ov3jaqTYKYf9fV3pUyjNWVmuSknMLY5zWxynk7G4=; b=URG/HUlckv2ygkAfD4PE+nxetFJoxYH1EJ9bu+VTBfqowTYfhUnSInUxJJWJXB62PJ Moi64z7wIY1EkPbx+oGB0N0JjGOHYjlGG5FUjrx/h5p9qELnH0gy91bfYAnfbwJKFNJ/ HOeYMT8KT8BE3UWtoISTudH0VUy419EzZgO3ifThkonAQdH0ZlodVrOIO0jg2M3ykAhc iG2cmubGHsxXwGZWTbqWH/LZHvVMWjT/JtEM/xHJ+ZOl9tPtp8//jis8D/HoVwLYA3aW glJARjtWPEqOX29siuosDvkik6eCbqzBrx79dRQcjfpQM4F+UZKBi7kVq0y7HquoBiwv E3nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jT5Ov3jaqTYKYf9fV3pUyjNWVmuSknMLY5zWxynk7G4=; b=tzFsimb5K7kpO5ooXnkAzdLiEYCeN1YCKHcEiey+p6sn6Zx3HPEIFuKzW+XvTs3woe 3okrwfYoLz0kYul5Ww3202TfoYYNkkRoU1u+tzeQzHGHXyhOO6s4kB/D426f+W53gztu 26xzVFInEKibweO02ql/YLx8d6kNQ0MiCN0+3mvVZyAmBQ42UmnU5uFQu5802DG6WZOZ +iwLxJXdGVyCYrLoENOtKu5QwTqVJu8C92msIV0yPRTabrHF4C7x58PKEXMVQaj5MeeO o0GRCXamE3nrGRoj/pOv3XxzG0Biymy4wOfhUkLjqHya8CoTLiOJT159bXGe4xLOSJ6D Y9jQ==
X-Gm-Message-State: AOAM533rD6wcJO1fjSWiAR7myq8O9G7SZzu0PJn2jrDg+N7KmwEWf8Qd ttDYVu2j2Wy9WxEqlx7XcQrnkZYtT4LJWA==
X-Google-Smtp-Source: ABdhPJw8g+R5F4P5tt0Qmo5vsXs67nyvvcZmpB9pbWlrWAXR6V8DcNZa+MNqfmGXllduH3dL8HTnsg==
X-Received: by 2002:a17:902:b942:b029:e4:87be:be8c with SMTP id h2-20020a170902b942b02900e487bebe8cmr17901391pls.81.1614740437479; Tue, 02 Mar 2021 19:00:37 -0800 (PST)
Received: from mike-mac.lan ([206.107.197.192]) by smtp.gmail.com with ESMTPSA id o127sm22567840pfg.202.2021.03.02.19.00.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 19:00:36 -0800 (PST)
Subject: Re: What ASN.1 got right
To: Nico Williams <nico@cryptonector.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <CAMm+LwiEqL3bMg09e5NBNZwkPJ90DmQgLTy=SQNEN0q=vp=wrQ@mail.gmail.com> <ed6830b3-e650-d3fa-b253-9f53e01f9615@mtcc.com> <CAMm+LwifpPg-Sg9cXLpWvjmExt8KfuYq6oRZd4D1L0ZBR3nRFg@mail.gmail.com> <1631e20d-9d8a-b8c2-9d5e-6c7f4defa72d@mtcc.com> <20210302234928.GX30153@localhost> <cb4960e2-05a1-9d28-f17b-9f610ac378c9@mtcc.com> <20210303002330.GZ30153@localhost> <7d70044c-88e8-0165-5ce3-4c8612965f16@mtcc.com> <20210303005136.GB30153@localhost> <8e4d3b84-0357-524e-b8f5-b8f7290adf2b@mtcc.com> <20210303022234.GE30153@localhost>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <b87a101d-dcad-1f75-aeec-a2d19022ce35@mtcc.com>
Date: Tue, 2 Mar 2021 19:00:35 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <20210303022234.GE30153@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zT1EbcRUrZv5KCZH4R_zSUV8WxE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 03:00:41 -0000

On 3/2/21 6:22 PM, Nico Williams wrote:
> On Tue, Mar 02, 2021 at 05:06:47PM -0800, Michael Thomas wrote:
>>> It's the same problem as getting the keys into the directory.
>> But it's not the same problem as getting a cert (chain) out of the CA and
>> installing it on the client. [...]
> The latter is strictly simpler for the reasons I gave.

It is literally nothing different in use, rather than having to figure 
out how to install certs. It is ridiculously harder to use client certs. 
If it weren't we'd see client side certs all over the place. We don't. 
That is for a reason.


>
>>>> Not having to do anything at all on the client is a significant savings. I
>>>> would much rather the help desk cost of nothing different than taking calls
>>>> on how to install the ssh certs on exotic and not so exotic clients.
>>> Yes, if you ignore the part about having to get the keys into the
>>> directory.
>> They both have to do that, so it cancels that out.
> But the directory case requires things that don't exist (e.g., schema,
> tools) and also online infrastructure.  Certificates don't.
NRE vs constant help desk. I'll take that. And of course there is 
considerable NRE for certs too.
>>> We have an online CA with an HTTP API.  You POST a CSR authenticating
>>> with whatever credentials you've got, and you get back a short-live
>>> certificate for your authenticated name(s) or for the requested name(s)
>>> if you're authorized to them.  Using this is trivial.
>> That doesn't alter that needing offline authentication is niche. A Mars
>> rover might need that. My phone connected to the internet, not so much.
> You say niche, but it's not at all.  And before anyone mentions CRLs
> and/or OCSP, the real answer to revocation os short-lived credentials
> (with fast, unforgiving rotation schedules).

Where are all of these use cases that need offline verification? I asked 
somebody else and didn't get an answer.

All of this tells me that there is a witching hour with certs that 
hasn't been broken in almost 40 years.

Mike