Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Thu, 13 February 2020 20:33 UTC

Return-Path: <henry.story@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 8324C1201CE for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 12:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IADzQNRRUk31 for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 12:33:52 -0800 (PST)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 5F721120013 for <saag@ietf.org>; Thu, 13 Feb 2020 12:33:52 -0800 (PST)
Received: by mail-wm1-x342.google.com with SMTP id b17so8258941wmb.0 for <saag@ietf.org>; Thu, 13 Feb 2020 12:33:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4jXonVVr2/MnIyKEfQz/cI0cQdifhGwj2LW4Zim7SXc=; b=elDg0FYPiDIQKEAe1MX7rReqVGLKheRtQXCdhKiHdNZqC5+1kqMNnsnbZIAwnX0J1q RL+9JDw0R82oOUakc822WDzNx6ENLT5jijCkeeE6Scy4pr+kL4q38DGUuojCO6a6iVcK MWDqGH+vx8nUiJ1Wb9KwvghHah4FTKmdz+c0Ex5R+FTZO8BDKeRddTyIVpDzj1e1S953 +wxUanLfJXDCI43NPDmBWMRdXZO+W6yHhHWyOvVdYOs8SMkTYElBWIDgrl8RUR9ai4oJ OPFwHsMCSl1QBlBGQdiL/2it9JrYz7LUP1FCUzKKfbZr54HCzJIDZFrnX0YgpHg3H40y sGmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4jXonVVr2/MnIyKEfQz/cI0cQdifhGwj2LW4Zim7SXc=; b=djjVhlNeqGiswbzBmZVh6a7ZbVEB8ZCttlVOIm2ibFYPFg0/aNApyLuMPSzLm1hKyA uZm1TLabIG/Kx8XMSYWpxDzmS+8VtPUQNZg0CYsOaLNXcPlVi9czcWBr8vOaaLnxdt3a sNPp5sTKEOWjvOzKsKh39ZQFNDoT9o4ex2e7Dng6rUtI5g3n19dVfwN2NQ2/QCVgsSE/ kTal+HPXDgQ9/HlRTgWo0lZZdUO/KVngGKZ4y4trquyibLijxdUzx23YTobcJj8AGdlz JaYQf3uh4mxTMREuf2Az+feZ+ZJHcxdW/GQWK9NuqM8havsLwT05Ul5IlqFWazyO22Fa Twrg==
X-Gm-Message-State: APjAAAVwLBF6Ek9ICgPsLF1gbsAGLhMvX82MUqUWoqF7jTZRR60wFUsq cRlJd+ejmuP0HMKS4mPxYT8=
X-Google-Smtp-Source: APXvYqyYyqeleGYwNl2sMsQAFr6TRejNvR2rsmXHW+pleVXO73IGArt+AxzfFREfuAamdu4pzMR0LA==
X-Received: by 2002:a7b:c14d:: with SMTP id z13mr7711333wmi.71.1581626030713; Thu, 13 Feb 2020 12:33:50 -0800 (PST)
Received: from [10.1.33.10] (ipb218ec89.dynamic.kabel-deutschland.de. [178.24.236.137]) by smtp.gmail.com with ESMTPSA id x7sm4224557wrq.41.2020.02.13.12.33.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 12:33:50 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Henry Story <henry.story@gmail.com>
In-Reply-To: <20200213191952.GS18021@localhost>
Date: Thu, 13 Feb 2020 21:33:47 +0100
Cc: trutkowski@netmagic.com, Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FEBBD2A-3578-436A-92E3-192CADC9FA8B@gmail.com>
References: <CABcZeBNJWmFTV==6sa0qnAPyRr4=6OiCacchzobE=RozHnqPdg@mail.gmail.com> <7901248e-c7dd-8a12-65df-f40415fde5e2@cs.tcd.ie> <26497.1581418516@dooku> <20200212002125.GO18021@localhost> <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>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Cau1xVHmaBYctKWWBZswFV-5M8I>
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: Thu, 13 Feb 2020 20:33:55 -0000


> On 13 Feb 2020, at 20:19, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Thu, Feb 13, 2020 at 07:48:18PM +0100, Henry Story wrote:
>> I think one has to take it as a ”fait accompli” that domain name
>> dilution has happened. In any case asking people to remember the
>> meaning of 2 character codes for country names globally would have
>> required a huge investment in teacher training, child training etc… to
>> accomplish.  Most Europeans have trouble remembering where US states
>> are located even though it is taught in final years around the age of
>> 17-18. Most US citizens have trouble remembering all the states of
>> Europe, even though many had ancestors the immigrated from here.
> 
> That's a misconception, that peole need to know country codes.  Or that
> we need anything like geopolitical hierarchy in the DNS, except for the
> purposes of registration and dispute resolution, which requires
> namespaces with registries, registrars, and sovereign jurisdictions, but
> not much more.
> 
>> That is not the way to do things. Instead lets accept that choosing
>> domain names is taken over by marketing folks, that poor countries are
> 
> Yes.
> 
>> selling their domains to make much needed money, etc… Furthermore the
>> only way to get rid of domain name squatters is to make their business
>> irrelevant by just adding new domain names.
>> 
>> Instead one should lead the Sovereigns to enter into the web by providing
>> data in machine readable format, about the companies and web sites that
>> wish to tie themselves to those legal institutions, the benefits of
>> which are not to be underestimated: you only need to live some time in
>> lawless zones, from squats onwards to understand how helpful the law
>> is.  This can be done in a purely opt in basis, though it would
>> require some conventions to be agreed upon, and the basic naming
>> infrastructure to work securely.
> 
> We have this now.
> 
> You might propose tweaking governance.  You might propose all sorts of
> things, but some will be easier to pull off than others.

This official data is being put together in machine readable format
such as JSON-LD, under umbrella projects going under the name of ”Open Data”. 

> 
>> Btw. one of the reasons why the system worked for so long, is that initially
>> the web of trust on which domain names and URIs built was built up
>> in a peer to peer manner by people linking pages. Those pages that got
>> the most links rose to the top in search engines that started using that
>> information (At AltaVista we did not know how to do it).
> 
> Yes, the search engines function as a sort of registry.

One that depends on the correctness of the information published,
even if only statistically. 

> 
>> Now that undermining the system of links through bots has a lot of 
>> value, that architecture no longer works. One actually now needs the
>> systems that have evolved to deal with law and law breakers, which
>> are called states, and which exist in diplomatic/anarchic relations
>> with one another.
> 
> Yes.  But would any alternative look that different to the current DNS?
> I am very skeptical.

As I see it, the problems is not at the naming layer
at which DNS is located where the problem is that of attaching a name 
to an IP Address. Whatever system is used - bare ipv6-addresses, 
namecoins, onion domains,… - all these  only give a way to identify 
agencies in charge of machines. What is important is knowing what
agencies those are!

What is needed is rich information that ties these ”publication machines” 
to machine readable official information about those entities.  This info
exists: states put that together to gather taxes, provide services, base legal enforcement on it, … 

The web site could link to such official machine readable information
by using a ”registry” Link relation in an http header.

I have illustrated this on my web site 

$ curl -I https://co-operating.systems/
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2020 20:08:05 GMT
Server: Apache/2.4.38 (Debian)
Last-Modified: Thu, 16 Jan 2020 21:48:01 GMT
ETag: "22d6-59c48c7766109"
Accept-Ranges: bytes
Content-Length: 8918
Vary: Accept-Encoding
Link: <https://api.companieshouse.gov.uk/company/09920845>; rel="registry"
Content-Type: text/html


The data one can get by following that link, is the following
(though for some reason the machine readable version of the public
information is currently protected by a api token)

$ curl -u token https://api.companieshouse.gov.uk/company/09920845
{
  "registered_office_address": {
    "locality": "London",
    "address_line_1": "2, Harlequin Court",
    "address_line_2": "6 Thomas More Street",
    "country": "United Kingdom",
    "postal_code": "E1W 1AR"
  },
  "undeliverable_registered_office_address": false,
  "has_insolvency_history": false,
  "company_number": "09920845",
  "jurisdiction": "england-wales",
  "company_status": "active",
  "has_charges": false,
  "type": "ltd",
  "company_name": "CO-OPERATING SYSTEMS LTD.",
  "date_of_creation": "2015-12-17",
  "domain": ["co-operating.systems","www.co-operating.systems"], 
  "accounts": {
    "next_due": "2018-09-30",
    "accounting_reference_date": {
      "day": "31",
      "month": "12"
    },
    "last_accounts": {
      "period_start_on": "2015-12-17",
      "made_up_to": "2016-12-31",
      "period_end_on": "2016-12-31",
      "type": "dormant"
    },
...,
}


Notice the ”domain” attributes, which provides a link back, in
order to allow the web agent to verify that the json-ld record above
is indeed information about that web site, and not some other.

How does the agent know https://api.companieshouse.gov.uk is
an official web site? Well the same game is played once more
creating a chain of trust up to a Web of Nations linking to
the browser users trust anchor. For a US citizen that could
be gov.us 

I summaries this in 2 pages here:

https://co-operating.systems/2019/07/29/Web_of_Nations.proposal.pdf

Technically this is pretty simple. Most of the standards to 
do this exist. Some ontologies would need to be developed and
agreed upon.

> 
> Nico

> --