Re: What ASN.1 got right

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 02 March 2021 21:39 UTC

Return-Path: <hallam@gmail.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 6D7F73A10DF for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 13:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.156
X-Spam-Level:
X-Spam-Status: No, score=-0.156 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, LOTS_OF_MONEY=0.001, NUMERIC_HTTP_ADDR=1.242, 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 bhFR3WlIQvGc for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 13:39:10 -0800 (PST)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 ED5FA3A10DC for <ietf@ietf.org>; Tue, 2 Mar 2021 13:39:09 -0800 (PST)
Received: by mail-yb1-f179.google.com with SMTP id b10so22289307ybn.3 for <ietf@ietf.org>; Tue, 02 Mar 2021 13:39:09 -0800 (PST)
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=1ixxYX6bo+NibXQ4IKkmVFMXtPlPuk0Eu1i807gBGLc=; b=LAiGaIeTq8l80L0imdoaVEVtaQINugjuLnH4/HGevprP0pozogHbRqpC/pbXjJKS0G Tuwa14saJaYp15Nbd7I9FoTYLGKVmOJPf1FbAMw6BZGkEl0X9P9IgdRewCOeONY7M3iI NOo9zZMDdDcexedn/ujK+yeolVI5dEyHMPb3EOI8wajCzkk9lvaJKawAg4Xm2BFVVIqv AOyzPptLQCQyh54yrPAUX4vtvJ7X4GiLZEKb0Ve+EaFBRUhfCfKRu1U6iV37zxjIvCRe DQmramHjlg+AA7+NLSmoB/evtzTIupNO9+FKMPRtkU0R0ZFwGTLsyvZvCpmP7ErMHAas zOyg==
X-Gm-Message-State: AOAM531g+bUGIdIUmZkYgcYCgMSPOdUY4rSe3hkF3VVeTNMqLGD24XUH zLVZWsV47AF5gQL6bgdEUka0igjPUeU0mIX6T0RcG+A0zVdBJQ==
X-Google-Smtp-Source: ABdhPJzlBw6VynpZrOe/cXOuSu6+Hg+OZGUtOVSrMoWRP9ISIxnf5tecH6e8dV0BouTkihfIixK206/7Igb+EwkMxlE=
X-Received: by 2002:a25:2ac3:: with SMTP id q186mr35323014ybq.213.1614721149072; Tue, 02 Mar 2021 13:39:09 -0800 (PST)
MIME-Version: 1.0
References: <20210302010731.GL30153@localhost> <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com> <006750D4-B70D-44F8-A01A-BD3AB136D9D3@webweaving.org> <a584ff73-34ae-1c9e-e746-ce98749461d7@mtcc.com> <20210302183901.GV30153@localhost> <CAMm+Lwj8QwuqaA3f625Ui8arc0TxY3uLXbG-PKToWGdtq8az6w@mail.gmail.com> <613072c6-5518-91e3-41b9-3b7590ee2346@mtcc.com>
In-Reply-To: <613072c6-5518-91e3-41b9-3b7590ee2346@mtcc.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 2 Mar 2021 16:38:58 -0500
Message-ID: <CAMm+LwiEqL3bMg09e5NBNZwkPJ90DmQgLTy=SQNEN0q=vp=wrQ@mail.gmail.com>
Subject: Re: What ASN.1 got right
To: Michael Thomas <mike@mtcc.com>
Cc: Nico Williams <nico@cryptonector.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080799905bc94908d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/u5k7YNE1JV_fMiWklTo8L5qaLEY>
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 21:39:12 -0000

On Tue, Mar 2, 2021 at 3:56 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 3/2/21 12:44 PM, Phillip Hallam-Baker wrote:
>
> On Tue, Mar 2, 2021 at 1:39 PM Nico Williams <nico@cryptonector.com>
> wrote:
>
>> On Tue, Mar 02, 2021 at 10:19:53AM -0800, Michael Thomas wrote:
>> >                                                    [...] And once you
>> rely
>> > on online crl's, it's all the same.
>>
>> Yes, well, wherever possible we should be using short-lived credentials
>> and dispense with revocation.
>>
>
> Getting back to the constraints of 30MHz Windows 95 PCs. Has anyone here
> tried to create a 2048 bit RSA key on a BBN safekeyper box?
>
> The notary videographer did not expect to be spending eight hours filming
> absolutely nothing happening.
>
> Back in 1995, signing a new cert for each subscriber every day was
> impossible. Now it is completely feasible.
>
> With threshold techniques, we don't even need the subscriber to make a new
> cert request and we can still roll the key:
>
> * Alice creates public/private key pair {a.P, a}, sens a.P to Carol
>
> t=0) Carol validates the request generates a new keypair {c0.P, c0} and
> sends back a certificate for { (a+c0).P, a+c}. and the value c0 Carol
> doesn't know a of course but she can calculate a.P + c0.P which is the same
> thing. This cert is valid for 48 hours.
>
> t=1) The next day, Carol sends a certificate for { (a+c1).P, a+c}. and the
> value c1
>
> t=2) The next day, Carol sends a certificate for { (a+c2).P, a+c}. and the
> value c3
>
> t=3) 'Alice' turns out to have never been Alice, it was Mallet. Carol
> stops sending her new certificates.
>
>
> Or skip all of this complexity and just enroll the naked public key bound
> to whatever name you like (if any) and having the side benefit of not
> having to deal with a dinosauric encoding scheme.
>
https is not the same as TLS. You don't need the TLS name to be bound to
the domain but the https name does. And you also have to provide backwards
compatibility for 30 years of https browsers.

We looked at this approach in 1995. Really we did. And the problem is that
you aren't avoiding a central point of control, you are pretending ICANN is
that point of control. And it isn't up to that role institutionally, nor is
DNS suited for that purpose.

The Mesh callsign registry is designed to support exactly that.

Henry's Hosting registers the callsign @henry as follows

Callsign: @henry
Profile fingerprint : MD4R-HO4D-AZY3-MZ3A-K7KP-N67I-LSUT
DNS: {10.0.0.1,  10.0.0.2}

Alice uses Henry's hosting:

Callsign: @alice
Profile fingerprint : MCQB-GS7P-HBSV-TKWW-WSD5-NSID-VU4L
Service: @henry

Both are enrolled in the notorized, append only callsign log. Think of it
as a blockchain that doesn't require more electricity than Argentina uses
to function. So the binding from the callsigns to the keys is solid. It
cannot be unrolled without relying parties being aware it has been unrolled.

The Mesh foundation is a wafer thin registry that does not provide query
functions. All it supports is incremental zone transfer of the entire log
to parties who do provide that function. The $0.10 fee to create a new
callsign is principally there to keep the log size bounded so that an
incumbent doesn't try to spam the log to raise the cost to service
providers.


Alice can now create a web site https://alice.mesh/ which can be found by
any Mesh aware browser as follows:

.mesh is a reserved TLD that I don't feel the need to pay $250,000 in ICANN
rent to get. Flood the zone worked for .onion and it will work for this.

Bob's mesh aware browser interprets the domain as follows:

1) Query Bob's MSP to resolve the callsign @alice, this causes both records
to be returned.

2) Query Henry's DNS at 10.0.0.1/10.0.02 which publishes the authoritative
zone for alice.mesh. This zone MUST be DNSSEC secured under a key that has
a validation path up to Henry's profile MD4R-...

3) Start TLS, get the cert back, this MUST include a valid chain to Alice's
cert root under her profile MCQB-... It MAY include a valid chain up to a
CABForum DV or EV root. A Mesh aware browser will trust it either way.


Carol's non mesh browser can only resolve this web site if there is some
registry out there providing a shadow service of the .mesh pseudo domain
using the callsign registry to populate it. That may happen of course. In
fact it is likely to happen but Carol's non mesh aware browser will only
consider the cert valid if there is a valid cross cert to one of the
browser roots.


So did people notice what I did there? This trust chain costs only a few
pennies to set up if Alice and Henry chose callsigns of 9 characters or
more. It provides the functionality of a DNS name AND the functionality of
a TLS DV cert. And there are no renewal fees for either.
This trust chain can be validated by Bob and the only thing he is trusting
is that nobody have futzed with the Merkle Tree authenticated append only
callsign log. And I can make the work factor on that practically infinite.
Oh and BTW, I didn't write a single line of description or code for this
project until after I left Comodo and after my non compete clauses had
expired (not that they would have been enforceable).


The trust path for validating the name of the site does not involve either
ICANN or any CA. [There are some issues to do with IPR in the names I am
eliding but these are considered in the detailed specs]

So what does this mean for CAs? Well they still have two important WebPKI
roles. First, they are the only parties that can provide certs that work
with legacy browsers and that will be a profitable number of users for at
least a decade. Second, they will still have an important function for
providing the accountability that the WebPKI is there to provide.

But more importantly for them, Threshold Key Infrastructure provides vastly
more functionality than legacy PKI. The Mesh will cannibalize their legacy
business over time but the opportunities that will replace that are orders
of magnitude greater. The Mesh protocols make use of Lototypes for
communicating trust to the end users. Also, the CAs are the parties best
positioned to run MSPs.


What does this mean for the wider industry? Well it is simple: This is how
all the IoT devices you are wanting to sell to Alice can use TLS to secure
the connection to their local web server console. You give each customer a
voucher that is redeemable for registering one callsign and that will cost
you $0.10 if they need to use it.