Re: What ASN.1 got right

Nico Williams <nico@cryptonector.com> Wed, 03 March 2021 19:56 UTC

Return-Path: <nico@cryptonector.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 0C0943A1958 for <ietf@ietfa.amsl.com>; Wed, 3 Mar 2021 11:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, 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=cryptonector.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 2k6ttW7p5qmi for <ietf@ietfa.amsl.com>; Wed, 3 Mar 2021 11:56:34 -0800 (PST)
Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net [23.83.209.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5F23A1957 for <ietf@ietf.org>; Wed, 3 Mar 2021 11:56:34 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0C257402C2E; Wed, 3 Mar 2021 19:56:33 +0000 (UTC)
Received: from pdx1-sub0-mail-a55.g.dreamhost.com (100-96-133-25.trex.outbound.svc.cluster.local [100.96.133.25]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 84223401D46; Wed, 3 Mar 2021 19:56:32 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a55.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.133.25 (trex/6.0.2); Wed, 03 Mar 2021 19:56:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Zesty-Coil: 364b7e127b93c01e_1614801392844_399151649
X-MC-Loop-Signature: 1614801392844:2796452519
X-MC-Ingress-Time: 1614801392844
Received: from pdx1-sub0-mail-a55.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a55.g.dreamhost.com (Postfix) with ESMTP id 447677EFCB; Wed, 3 Mar 2021 11:56:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7zAibUd/FX+qtS w/OTVCFqVvFx0=; b=w9Zv4hDsqNEntcP6kkQ3KN+S6XCN5WOMjod5fWLjKrOY9V /YosL5oMNdcd08s16YIQJJlAdILb21814ZqhIUxk2C4Z5u6RfJsKQ6s1vOAI65Td es/vWwnvQsDMfAiitZDV0ZUTg+vpIUhuZCwzqnVDt1Pl0YaCAg3UVBdI7rEy0=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 648847E39F; Wed, 3 Mar 2021 11:56:30 -0800 (PST)
Date: Wed, 03 Mar 2021 13:56:28 -0600
X-DH-BACKEND: pdx1-sub0-mail-a55
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Michael Thomas <mike@mtcc.com>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: What ASN.1 got right
Message-ID: <20210303195627.GK30153@localhost>
References: <20210303002330.GZ30153@localhost> <7d70044c-88e8-0165-5ce3-4c8612965f16@mtcc.com> <20210303005136.GB30153@localhost> <8e4d3b84-0357-524e-b8f5-b8f7290adf2b@mtcc.com> <20210303022234.GE30153@localhost> <b87a101d-dcad-1f75-aeec-a2d19022ce35@mtcc.com> <20210303033555.GG30153@localhost> <370a2bd4-46b2-aad2-3ae2-31e92888a8a3@mtcc.com> <20210303183823.GJ30153@localhost> <CAMm+Lwiedc5yOfZwZAsU3MhOEsh7qy8hFO4E7e_9JV0wAAUM3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwiedc5yOfZwZAsU3MhOEsh7qy8hFO4E7e_9JV0wAAUM3w@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/oHNQhznKE8vAsJnfxE7zM5wDgXw>
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 19:56:36 -0000

On Wed, Mar 03, 2021 at 02:05:33PM -0500, Phillip Hallam-Baker wrote:
> When I was writing my intro to crypto course, I covered Kerberos and then
> moved on to PKI, I was astonished at just how close the Kohnfelder model
> hews to Kerberos (maybe not so surprising, it was an MIT undergrad thesis).
> 
> But here is the thing, nobody should ever be ashamed of 're-inventing'
> systems of the past. If old techniques work, then use them.
> 
> Since adding PKI to Kerberos wasn't exactly successful, one is going to

I wouldn't say that PKINIT has failed.  It works, and it is used.  It's
not used widely as intended (i.e., with smartcards) because what failed
is smartcards.

If you use PKINIT as a bridge, and you have online CAs, and online JWT
issuers, and... you can have whatever kind of credential you want as a
root credential.  One might use KSATs or GSATs as root credentials, or
Kerberos, or smartcards, or whatever.

I've been building authentication bridges because it turns out that
getting the whole world to support the one authentication system, or
some minimal set of authentication systems, is impossible.

(Aside: one design for PKCROSS is basically online CAs + PKINIT.)

> have to add PKI to Kerberos or Kerberos to PKI and the complexity of either
> is likely to be rather greater than designing something from scratch using
> the experience of the past 40 years.

I'd rather start from scratch when it comes to Kerberos.  Too many
mistakes were made in Kerberos V's design (listing them should require a
separate thread).

Also, Kerberos as a competitor to TLS failed, leaving it mostly only a
role as a token system akin to JWT with symmetrically encrypted tokens
(a mostly unused option of JWT's).  GSS-API as a pluggable system has
also failed except in so far as it could be an API for TLS (as GSS-API's
Windows cousin, SSPI, is).

Note that failure in this context doesn't mean "and we can obsolete and
remove the failed thing".  Even failed things tend to last forever :(

The great thing about Needham-Schroeder is that it depends only on
symmetric crypto, which is good news in a PQ world, and in a post-RSA
world (if we're there).  Even better is that combining PK and Needham-
Schroeder is an optimization for slow PK, which is what you want in a PQ
world.

The bad thing about Needham-Schroeder is that setting up trusts is a
very manual process and needs PK in order to automate it (or better, in
order to not need to setup trusts at all).  But again, that just leads
one to want to combine Needham-Schroeder with PK.

Nico
--