Re: What ASN.1 got right

Phillip Hallam-Baker <> Wed, 03 March 2021 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E05103A174F for <>; Wed, 3 Mar 2021 09:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id slxQkhBda_0o for <>; Wed, 3 Mar 2021 09:43:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 451A43A174E for <>; Wed, 3 Mar 2021 09:43:20 -0800 (PST)
Received: by with SMTP id d9so25447222ybq.1 for <>; Wed, 03 Mar 2021 09:43:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvlgh+eG4Iavw+VnMFMSTmuddY8MQe+QuxLibPB9CK0=; b=L4EkrUiQGohGkhte5QL1V+cyJHkA0UEywDfr4bSSGaLo41RCX6mcbpCeL6Y+xNFEqQ grqV0X+bWWlANhj1+XVSnkKuVcvtrHj4F+XbMWoqYJLNDi6NErIa+GGJ4+QXftVuuyPo jCxsOqIgAmA6cFOqmdJXfG6NuOV816nDk67vk9nFh/0Jvt9yzAyJVot5jQQiVnfjseq/ rJKQQtMKY+f3+T6SkxnZWRz2YgAhz8TUiSKgQfc/XUadE8i8Lg/65qoRCTVEobWL4ch7 YL6RuYBXi14lSmi4WlxgXqWsTuo9lHbyPbI7nDbj5TQPIiLYB6La0P6KhWz2qOnGsGPP WLHg==
X-Gm-Message-State: AOAM533JNtPVgsBy/fnj/h3d6dVq9OFpYddrjkLyYcB6a7ufGc9xwY80 F+WiCdDbEtCzsuy4e99zS0DQkjvib0Ij7xSJdlsSb+esz1M=
X-Google-Smtp-Source: ABdhPJz0eMNmyQlkpS0hTXH14Zd3a96Zn40UyFdR1urp78fmvfdqGC3qx/Gqd1Bk+8SzbhPDvCknS+IuQBONxmY68i8=
X-Received: by 2002:a25:aa6d:: with SMTP id s100mr496110ybi.523.1614793399458; Wed, 03 Mar 2021 09:43:19 -0800 (PST)
MIME-Version: 1.0
References: <20210302234928.GX30153@localhost> <> <20210303002330.GZ30153@localhost> <> <20210303005136.GB30153@localhost> <> <20210303022234.GE30153@localhost> <> <20210303033555.GG30153@localhost> <> <20210303152632.GH30153@localhost>
In-Reply-To: <20210303152632.GH30153@localhost>
From: Phillip Hallam-Baker <>
Date: Wed, 3 Mar 2021 12:43:08 -0500
Message-ID: <>
Subject: Re: What ASN.1 got right
To: Nico Williams <>
Cc: Michael Thomas <>, IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="000000000000f5dd7705bca562d7"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Mar 2021 17:43:22 -0000

On Wed, Mar 3, 2021 at 10:26 AM Nico Williams <> wrote:

> On Wed, Mar 03, 2021 at 12:34:19AM -0500, Phillip Hallam-Baker wrote:
> > The practical limit on certificate lifespan is 48 hours renewed every 24
> > unless you have a means of reliably getting trusted time into the client.
> For server certificates five days is fine.  For clients you want
> something akin to Kerberos.  Typical Kerberos installations issue 10
> hour TGTs that are renewable (note: Kerberos sense of renewal) for a few
> days, and after that the user has to type in their password or do
> whatever MFA dance.
> > I have been trying to find info on SSH user certs on and off for quite a
> > while. Seems like an under-documented feature... They solve a big problem
> > for me :-)
> Honestly, they're not that interesting to me because of the limited
> hierarchy they have.  I'd rather it were PKIX certs.  But at least they
> got something right: subject naming, which they call principal names,
> and which are just strings, freeform strings.  That means that if you
> are migrating from some other system, you can keep that other system's
> naming.

Thats all I need. Consider the case where Alice is using the Mesh to manage
her SSH credentials. She has 5 devices she uses as a client and accesses 24
different servers.

Cryptographic hygiene requires each device have separate SSH credentials.
Doing that with raw keys is beyond tedious because the admin tool has to
log into every one of those 24 servers to update Alice's authorized
keys file.

If the certificates are actually supported by GitHub etc, and can be used
in the same spot that regular keys are, everything is tickety boo. If this
is a theoretical feature supported by a fraction of the installed base...
not so much.

And it looks like Github supports user certs but only in the paid
enterprise version. Which doesn't work for my objective of getting the open
source development ecosystem fixed...

Part of the plan here is that I want to get to a place where ALL code is
signed. Especially code that is in development. Every build should be
signed, every item in every assembly. Which is yet another reason why my
Merkle Tree based DARE is vastly superior to WPACK.