Re: What ASN.1 got right

Nico Williams <nico@cryptonector.com> Tue, 02 March 2021 07:08 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 E7F043A2757 for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 23:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_DNSWL_BLOCKED=0.001, 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 DsbY2Hm8b33l for <ietf@ietfa.amsl.com>; Mon, 1 Mar 2021 23:08:09 -0800 (PST)
Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 3B01B3A2751 for <ietf@ietf.org>; Mon, 1 Mar 2021 23:08:09 -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 C94E5320E78; Tue, 2 Mar 2021 07:08:05 +0000 (UTC)
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (100-98-118-122.trex.outbound.svc.cluster.local [100.98.118.122]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 67E43320630; Tue, 2 Mar 2021 07:08:05 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.98.118.122 (trex/6.0.2); Tue, 02 Mar 2021 07:08:05 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Spicy-Society: 73ae41dd268a0690_1614668885680_1852501899
X-MC-Loop-Signature: 1614668885680:3294553512
X-MC-Ingress-Time: 1614668885680
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a86.g.dreamhost.com (Postfix) with ESMTP id 2080787299; Mon, 1 Mar 2021 23:08:05 -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=idHMcZvGHY+Wc+ UF8J9tSrrefhk=; b=sqPVlFPMbUeADFL3To3zQ1r5hTNzB9FpD7Il6+9sFKH9hL uAqD0mietlNBtMIy//uoXhKbKqjqoZDRfSTSIRhf8W6Jhd37CWc6bW60m/YEhbce xocBTCdPsqk6eL6zW8JWELcLO+RIs2ZbCrPdR7/a6RwKpoMMBO+Pq1CehS3j4=
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-a86.g.dreamhost.com (Postfix) with ESMTPSA id 78AC87EF9C; Mon, 1 Mar 2021 23:08:03 -0800 (PST)
Date: Tue, 2 Mar 2021 01:08:01 -0600
X-DH-BACKEND: pdx1-sub0-mail-a86
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: <20210302070800.GS30153@localhost>
References: <20210302010731.GL30153@localhost> <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com> <CAMm+Lwjgv1jj6txiDRik_3by_FL0RKRqD=-8ds0bPvDKDw98-g@mail.gmail.com> <20210302060622.GR30153@localhost> <CAMm+LwhZn09i_u_AsrQvHdmXy0D02Ypr0hhdd=tDTeM-EErAeg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+LwhZn09i_u_AsrQvHdmXy0D02Ypr0hhdd=tDTeM-EErAeg@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ltaNir-XHm17CjeG2xgErtzKRcc>
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: Tue, 02 Mar 2021 07:08:11 -0000

On Tue, Mar 02, 2021 at 01:45:59AM -0500, Phillip Hallam-Baker wrote:
> > I don't follow.  Given all the CPU, RAM, and storage available now, what
> > would you do differently?  Mesh, yes, I know, but, remind me how Mesh
> > uses all that extra HW that PKIX leaves on the table?
> 
> The original goal of the Mesh was to make computers easier to use by making
> them more secure.
> 
> WebPKI is really limited to authenticating organizations. Private key
> management considerations are pretty much out of scope. The assumption is
> that Alice has a public key pair which is stretched to separate keys for
> encryption and decryption.
> 
> The Mesh has a separate key for every function and for every device and
> application. So if Alice has a dozen machines connected to her Mesh, they
> each have separate encryption, authentication and signature keys. And they
> are all used for threshold operations which really don't fit into the RSA
> scheme of things.

But do you need to store a huge mesh on every device?  Where is all the
power of modern HW being used here?

> Introducing more keys allows me to deal with all the real world use cases
> that get ignored like what to do if Alice loses her phone, if she is
> planning to go through an airport in a hostile police state, etc. etc.
> 
> Sure, now I have the architecture, we could go back and spend ten years
> working out how to retrofit to PKIX. Or we could write some end to end
> secure applications that are exactly as easy to use as the applications
> people use today. I am talking about zero user impact security, zero trust
> models, etc.

I mean, Alice can have a private CA for her devices, with secret
splitting / threshold crypto used to spread that around, and/or secure
elements storing the keys or key shares, and yet all the devices might
not need to know all the other devices' keys because they might always
present EE certs chaining to her private CA.  The naming on the
certificates would be all pseudonymous perhaps, or real names encrypted
to a key specifically for that purpose that all of Alice's devices have,
so that she can identify them.

PKIX certificates are just bags of "extensions", so you can fit any of
that into it.  There's even an extension for encrypted naming, though I
forget right now what it's called, and it might not fit your needs.

(And yes, if a bad of random extensions + a signature is all one needs,
then ASN.1 is overwrought for it.  Just if you use JSON, please don't
make the schema for that overwrought either.)

> Social media where the service cannot read any of the posts.

But they give you the software you need to use it, right?

All these apps that claim to have end-to-end crypto, but where you have
to run an implementation you didn't write, so you don't really know if
there's a MITA or backdoor or whatever.

> > > If you want a decent PKI for user authentication you need to be
> > > willing to do Internet2 for PKI and do some blue sky research.
> >
> > No please.  That's how we got X.500 naming to begin with.  Subject Alt
> > Names exist because X.500 failed.
> >
> > SMTP and RFCx822-style email address naming killed X.400 because X.400
> > inherently meant an awful UX.  X.500 naming needs to die.
> 
> I come to bury X.500 naming, not to praise it.

+1

> People don't have DNS names and a majority of people on the planet can't
> afford $10/yr to rent one. And that tomato has sailed.

Well, certainly DNS naming is 1e6 times better than X.500.  But I agree
that for individuals it doesn't work.

> We need names that cost $0.10 for life. If we can get the price that low,
> we can get to universal coverage some day. We can find someone to pay even
> if the end user can't afford it.

+1.

> $10/yr is a thousand bucks over a lifetime. Won't be able to find someone
> to sign that check for the planet.

Well, most households pay for utilities, but I agree.