Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Thu, 13 February 2020 22:13 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 07600120817 for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 14:13:02 -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 mGOEOLf_xtT7 for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 14:12:59 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 6185B12080E for <saag@ietf.org>; Thu, 13 Feb 2020 14:12:59 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id y11so8638200wrt.6 for <saag@ietf.org>; Thu, 13 Feb 2020 14:12:59 -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=XZ1hVmUWfVaFt3e61sHnrEfp5tmBul0Hq6EIyOKdgxo=; b=LJipwMRWZiPjFH1C+yMdiqMNqFVUkYfQAHP9APBQNY2IxU2QpHIz3DfxSM69CpAJTF cObPtGBtkf5h08v7QXtctDHarp+JaBXGA7qqIFHDXAaQ/GjN1XeuRZSQKTOc+VD06CX4 nn4xvN2gme38+NpZT7oXdR89MKHztOeX0CkGd2amn/mA+Lc/pjjvcc9SkNsl162l8AR/ jKpnYULnaUZaREmPNj3yafBYQ63DUFnl0N3Pa9zeQ5CZO2p7iMaArgwWd4nE72LIp6Eb dPqv/IVpsKpXHH/TaYm2kwVKmVpGUoGh5k/814fbd1G52b2IelVFuDhkBGU2CXFyxHAM dEbw==
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=XZ1hVmUWfVaFt3e61sHnrEfp5tmBul0Hq6EIyOKdgxo=; b=W+du0EhxYmqRn9T46Q0k0eBMmAWR0TzEQDXb4syrV3eQyZNwCqMgaF7ohm72qJqoIZ kGZXlnt4o5+bCbbGnqwMWBs9Pm7syDfdTMTRKProamDfrJJv8KEp44clC+Yr84WVv5kU /cz57++alYGhbxSthXsjulINy7I3VI/ieNt2ARzchHz4URCSKbmLqQBUt8gj0bx5xOcD mg76y1OV6Mt66MnmokYr7du7/zzf/6Arm6UUqrgcwAv6dm89QQqWLqXbXimBCunKQrHX oQbUR9VKVQ71IgFQlJxH7x2duqOIwHZhSiAVt1J3rizUMGHCHSLsaBePXw7XViJ7kzH0 NH9g==
X-Gm-Message-State: APjAAAUJ82do55DUGhpuvKOubgbryibqkeqqmb3gLXAj+fpfLvE5u705 +3yPmdPhbmfor+t35aDr0FM=
X-Google-Smtp-Source: APXvYqyU0Qi8UHm9dPXsI8iI+r6GrFVKNnKELclQRMSlLRTfbbEKUjqnt5OWBYKuFWrj2M0MACaYzA==
X-Received: by 2002:a5d:4446:: with SMTP id x6mr23432281wrr.312.1581631977791; Thu, 13 Feb 2020 14:12:57 -0800 (PST)
Received: from [10.1.33.10] (ipb218ec89.dynamic.kabel-deutschland.de. [178.24.236.137]) by smtp.gmail.com with ESMTPSA id u14sm4441303wrm.51.2020.02.13.14.12.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 14:12:57 -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: <20200213213953.GU18021@localhost>
Date: Thu, 13 Feb 2020 23:12:54 +0100
Cc: trutkowski@netmagic.com, Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2945E4D6-BFFF-4477-9AB3-24534CC687A0@gmail.com>
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>
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/UNyOhCht7xf3D4Mcjy6BcyKaExM>
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 22:13:06 -0000


> On 13 Feb 2020, at 22:39, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Thu, Feb 13, 2020 at 10:21:05PM +0100, Henry Story wrote:
>>> On 13 Feb 2020, at 21:51, Nico Williams <nico@cryptonector.com> wrote:
>>> DNS is very much also about registries and registrars, and that is where
>>> the rubber (protocol) meets the road (international law).
>> 
>> I have seen no DNS registrar publishing anywhere near the rich type
>> of information currently being published by companyhouse
>> https://www.gov.uk/government/organisations/companies-house 
> 
> They have the information.  Whether or not to publish it is a policy
> decision for the _registries_ and the sovereigns who have jurisdiction
> over them.

Let’s say the company registrars have the information for sure: 
they use it to collect taxes. DNS registrars may or may not be
able to get it, but it’s not as useful to them, they can’t 
use it to get taxes. 
In every country there are government appointed company
registrars that have been doing the job for at least a century.
It is just a question of tying them into the system. That’s 
what linked data is about.

> 
>> That is unlikely to happen either as DNS registrars are not in 
>> the business of describing legal entities, and they would not 
>> want to be liable for that type of information anyway. 
> 
> They could require, at registration time, permission to publish, though
> they almost certainly wouldn't.  They could reserve the right to publish
> it, or share it with researchers -- this most probably do.

See point above about the reason for governments to collect
this information and keep it. It’s very important to the
functioning of the state.

> 
>> On the other hand it is the role of national company registrars,
>> such as companyhouse.gov.uk to provide that.
>> 
>> It depends on what one considers a registrar.
> 
> Yes.
> 
> What's your proposal though?  To have us force them to publish this
> data?  To replace DNS so we can force publication of this data?
> Something else?  I'm confused.

State registrars are already starting to publish this data. I
gave you an example earlier in the thread about CompanyHouse
publishing it in json-ld.

They also have it available in html
https://beta.companieshouse.gov.uk/company/09920845

And you can query it with SPARQL
http://business.data.gov.uk/companies/app/explore/sparql.html

So there is no need to force them to do anything.

What is needed is to get a few of these national registrars to
agree on an ontology, so as to make it valuable for browsers
to get that information and display it in an elegant and
attractive fashion when needed, and for there to be
a way for that to be findable, either from the web site
or through DNS or both or more.

> 
>> It’s a lot easier for state registrars to publish their data
>> in extensible human and machine readable formats such as JSON-LD
>> on HTTPS servers that in DNS. So that’s where it is happening
>> and that’s where I expect it to continue happening.
> 
> Meh.  Either way.
> 
>>> DNS already has this by way of the registrars, which already have this.
>> 
>> Those are just special type of registrars. If you extend your
>> view of registrars, then you will see that what is
>> needed is to tie web sites (via DNS or HTTP headers or X509
>> fields) to those that are ultimately responsible for the rich
>> data that is needed, namely state based company or institution 
>> registrars.
> 
> Who needs that?  The public?  Maybe.  The public needs trust, and that
> could be transitive via the registries.  I don't think the public is
> going to be able to review this metadata anymore than they can review
> PKIX certificate and issuer metadata.  And having this metadata gets us
> no closer to solving the WebPKI problems.

That’s a User Interface issue.
I think it is quite clear that amazing user interfaces can
be built inside browsers.
That these have not been build around X509 is partly to do
with the poverty of the information available in those 
certificates, the static nature of them, the difficulty on
agreeing on OID standards to extend them, etc...

> 
> I'll make an assertion we can debate: it will be easier to earn user
> trust if there's a proper rooted issuer chain mirroring the DNS (i.e.,
> DNSSEC), but even then we'll need better regulation of registries by
> nation states, and of registrars by registries and nation states.

If you include company house they are already regulated, and they
are already publishing. They need to standardize somewhat so
that browsers can more easily consume the information, but that’s
it.

> 
>>> Whether such metadata should be public or not is a policy matter for
>>> each registry and associated governance framework (i.e., in the
>>> registry's legal jurisdiction(s)).  The IETF should not mandate
>>> publication of that data because publication is a policy matter, and the
>>> IETF has no leverage to impose such a mandate anyways.
>> 
>> The IETF like the W3C takes on the role of building spaces for
>> different groups to come to a consensus on some topic of relevance.
>> Improving security on the internet and the web is relevant to both.
>> I guess that the W3C is better equipped to help governments come
>> to consensus with web browsers on ontologies. Nevertheless there
>> would certainly be a role also at the IETF level too. In any case
>> being aware of this possibility could help direct future work here.
> 
> We don't quite have the political reach to solve the legal problems.  We
> can advise nation states.  We can attempt to create a replacement for
> the DNS and once again create monopolistic registries that nation states
> can then choose to regulate.  We probably cannot do much better than
> that.

Or we can do a duck-rabbit trick and see that what we need is right
there emerging in front of our eyes. :-)

> 
> Nico
> --