Re: [saag] post-X509 cryptographic identities

Nico Williams <nico@cryptonector.com> Thu, 13 February 2020 21:40 UTC

Return-Path: <nico@cryptonector.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 8E50A120288 for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 13:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 bOQH8JDr6ekS for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 13:40:05 -0800 (PST)
Received: from anteater.elm.relay.mailchannels.net (anteater.elm.relay.mailchannels.net [23.83.212.3]) (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 24B31120273 for <saag@ietf.org>; Thu, 13 Feb 2020 13:40:05 -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 8EA1C541037; Thu, 13 Feb 2020 21:40:04 +0000 (UTC)
Received: from pdx1-sub0-mail-a6.g.dreamhost.com (100-96-1-6.trex.outbound.svc.cluster.local [100.96.1.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E0878541083; Thu, 13 Feb 2020 21:40:03 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a6.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 13 Feb 2020 21:40:04 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Attack-Average: 6422796f0920de07_1581630004367_1419678378
X-MC-Loop-Signature: 1581630004367:1572994461
X-MC-Ingress-Time: 1581630004367
Received: from pdx1-sub0-mail-a6.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTP id 9A9157E5E1; Thu, 13 Feb 2020 13:39:58 -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:content-transfer-encoding; s= cryptonector.com; bh=6v4sS1Bi0XrJG0+loyZwRQVYxgk=; b=LAfIiYI0FYR neUZCj8EUE3Fh8aXLXst+9d1/WiVy1xgiFnj2nTguwJl9BXq2eGpFAHIkHj+RdeW ozl+vzmvHwAulcIKgH+T4/tMb8+fRsWTOVDCHAJsFuFFrSYZrT/j6Jt+hSheoBCj YM8fl3AjIYqGOTHNtD1FiCxdTySz/Oeo=
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-a6.g.dreamhost.com (Postfix) with ESMTPSA id EEB487EE69; Thu, 13 Feb 2020 13:39:56 -0800 (PST)
Date: Thu, 13 Feb 2020 15:39:54 -0600
X-DH-BACKEND: pdx1-sub0-mail-a6
From: Nico Williams <nico@cryptonector.com>
To: Henry Story <henry.story@gmail.com>
Cc: trutkowski@netmagic.com, Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Message-ID: <20200213213953.GU18021@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <43D1454A-C1DD-4742-A14C-F608F296208C@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrieekgdduheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpeiffiifrdhgohhvrdhukhdphhhtthhpshhsvghrvhgvrhhsthhhrghtihhnughnshdrshhonecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/7W4oeg2uyiH9edEs4QOkbbB4VLY>
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 21:40:08 -0000

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.

> 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.

> 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.

> 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.

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.

> > 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.

Nico
--