Re: [saag] post-X509 cryptographic identities

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 14 February 2020 20:13 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2424E120A99 for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.417
X-Spam-Level:
X-Spam-Status: No, score=-1.417 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2MnWjyKpyl8F for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:13:17 -0800 (PST)
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 AC3D412022C for <saag@ietf.org>; Fri, 14 Feb 2020 12:13:17 -0800 (PST)
Received: by mail-ot1-f44.google.com with SMTP id j16so10360797otl.1 for <saag@ietf.org>; Fri, 14 Feb 2020 12:13:17 -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=I1/mXlFblM+Y6eS7g8+0kh3MRozLFS8NiBy2w8OS/4o=; b=Gx7IpzCgidafmye8WyG20SHHeEakejjo/sKetsIfI6nztkcydzl+2PjFB2qRQ0Nncp i+YCQQFE9jGPyNzd0FWauVX/HlSp1nEs7ux0u4AUpoiH5fo2xzGXXPCQ8JWk5lPtTCxb YBqoOge3qRyrOafF+sqaF5yYCRJi23xUCOOEJ9vY4Dth6/5WEZnf8BdrfdCNyok9JdUh 4MsDic9na0AFOZF92xBC6Bbfv17XULyMmKwMxldTIuNpKvSpaqKPfm8VkrL1+0UMxjxY 9m/5Xvh8ku9+WFnFt4bcNv7oo68V1l3QsuErT5zSA/wqhFQeZzx0bTXVDz8vzX9pQizp AUeA==
X-Gm-Message-State: APjAAAWmX94k61lk7mxIoOPnrkInRYDdy/AkHciFAsDacg0UEt0frJ5H HUcAiAkq5mhcsjiqzf4Oo0G6TqNYaunBQ+j4xSInfXX1aCg=
X-Google-Smtp-Source: APXvYqyOUocjtdRkh76veZaiqb9TgafKdoaGJbAIH1SgFVSsXJYs+L1rC9o5eABIvUdyzsnYc3ujYVzxbTod7RZNLFw=
X-Received: by 2002:a9d:729c:: with SMTP id t28mr3678475otj.66.1581711196972; Fri, 14 Feb 2020 12:13:16 -0800 (PST)
MIME-Version: 1.0
References: <alpine.DEB.2.20.2002131443470.25433@grey.csi.cam.ac.uk> <20200213171324.GP18021@localhost> <d3d01f1f-5784-da84-1c59-e636d349bd2a@netmagic.com> <20200213175626.GR18021@localhost> <65357327-e2d7-89cc-221e-ed8ac2875048@netmagic.com> <A91F5BD6-BFBA-4BA7-9158-3F41A8F0F7D9@gmail.com> <20200213191952.GS18021@localhost> <9FEBBD2A-3578-436A-92E3-192CADC9FA8B@gmail.com> <20200213205158.GT18021@localhost> <43D1454A-C1DD-4742-A14C-F608F296208C@gmail.com> <20200213213953.GU18021@localhost> <2945E4D6-BFFF-4477-9AB3-24534CC687A0@gmail.com> <2de1f6eb-d0af-73f7-3662-ed4b93368421@netmagic.com> <CACsn0cnrZhTpgC9aQgciJjfhGC4VuhV4irYbO3om6c-vsrYnFw@mail.gmail.com> <8728.1581708714@dooku>
In-Reply-To: <8728.1581708714@dooku>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 14 Feb 2020 15:13:05 -0500
Message-ID: <CAMm+Lwh=QnO-m-v9Xhmyx+fSJKhJWbEzi2x4H==A+aXuiBydjg@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000086ced059e8ed6d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/It5mlpGAltA-a_pp4c0-bO7_iwk>
Subject: Re: [saag] post-X509 cryptographic identities
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2020 20:13:19 -0000

On Fri, Feb 14, 2020 at 2:32 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Watson Ladd <watsonbladd@gmail.com> wrote:
>     > In this world plenty of economic transactions take place with DNS
> names
>     > as the only identifier. Plenty of people are known by monikers that
>     > have nothing to do with any government: Muhammed Ali, Prince, Kirk
>     > Douglass, Liberace, etc. The state doesn't determine these: remember
>     > "Say my name!"?
>
> Agreed, and those are all, btw, local names.
>
> Those people convince the world to accept them as their name, to enter it
> into our personal trusted store.  That we all happen to believe we are each
> referring to the same person when say "Prince" just means that they are
> effective. (But, an aunt has a dog named "Prince", and I know who is
> referring to when she says _Prince_.  It's Mimi's Prince, not AMI's Prince)
>

Let's start thinking in a post anti-Trust IoT world in which the majors are
no longer trying to establish monopolies with their voice control systems
and we want to be able to give voice commands to any of the devices we own
from any of the voice input devices and we want them all to give the same
result.

That is the following commands should all have the exact same result:

"Alexa, shut off the lights in the basement"
"Siri, shut off the lights in the basement"
"Zen, shut off the lights in the basement"

This can only work if there is a common understanding of "in the basement".
Which means that all the systems are using the same catalog to interpret
'basement'. And this has to be a local name. I want the system to do the
right thing even if I have more than one house.

According to Noth, a name is a signifier that has no direct correspondence
to the signified, it is a purely conventional relationship mediated by some
agreed registrar. In the case of my basement, that registrar is obviously
going to have to be me or someone in my house. Certainly not ICANN.

DNS names attempt to be universal names. They aren't quite, because the
registration is only temporary. The names are leased, not owned.

There is a role for universal names in PKI but we go about it the wrong
way. Not wanting to mention blockchain, let us consider a Merkle Tree
authenticated sequence as in CT or a DARE Sequence.

The logical implementation of the RPKI is as an incrementally authenticated
sequence. Each IP address block assignment is enrolled in the sequence as
it is granted or transferred. The entry specifying the range(s) of IP
addresses it applies to and the signature key(s) to which they are bound.

This structure allows a single signature by the registry to verify the
entire RPKI. We can extract individual range assignments and the
corresponding Merkle proof chain or we can just synchronize the entire
database.

We can imagine constructing something of the sort for 'real names' with a
different binding. So 'Microsoft', the Microsoft Logo, the Microsoft
enterprise root key and the address of the .Microsoft DNS server might be
enrolled in such a sequence after going through a CABForum EV type process
plus some form of trademark verification.

Issuing .Microsoft in this way would naturally upset folk thinking that
TLDs should cost $750,000 because they want a nice yacht. But it could
easily be done for $1000 without the need for any renewal fees. Though
there would be a need for a dispute arbitration process etc. And we might
want to have a rule that name owners have to make a maintenance post every
so often so as to allow unused names to be recycled.