Re: [saag] post-X509 cryptographic identities

Tony Rutkowski <trutkowski.netmagic@gmail.com> Thu, 13 February 2020 22:02 UTC

Return-Path: <trutkowski.netmagic@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 0111A120274 for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 14:02:22 -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, 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 gKzHgUgYgYXf for <saag@ietfa.amsl.com>; Thu, 13 Feb 2020 14:02:19 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 2C38912026E for <saag@ietf.org>; Thu, 13 Feb 2020 14:02:19 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id l14so3363199qvu.12 for <saag@ietf.org>; Thu, 13 Feb 2020 14:02:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qFKpUAtpHthaOT0HnDAVPL6BHwfseE5eTlAzLQTAPuI=; b=QpplWQv8Kb39s6+KRqIaaMGE0nGeOsWn9MbxuOfvCuQk6sV9uPWP/zDh7dFnm6ZkIP DiFIEFrQVboXDxbBnGlcxtf7sb7ujXOpNnM/T8TttTrfV5UAltkt2rV44xVxAokP0/R5 QECSnhlUUhS2aRAXfMAHsKMQxpPWRz4MtMT5KXulk5Tj2GtVbbcI5HAUAnoKSGzyn1BY nvS5AJewwVHnC9e2/GT0xZZJAspFAHId9OljCEIRvjI5wU4w29+acHZlsEU/HXgf28OS hv5oeMKhTAIhd/a5T8ngRrslUBUfZR2RACMI8i6NnXnGr8LTFu/TX2YGfVorCt4fKMzd z6dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=qFKpUAtpHthaOT0HnDAVPL6BHwfseE5eTlAzLQTAPuI=; b=SDmWr92r7gz24p7q7324pQqllhMCmaqY0MKwW5CXsLEwu+su5VPoaXFAJj7KwY0dOZ arh/SRQdQE3xOhIfb9mF/z6oCwGgF2Q6ZIfkUgvy0Np+hO+pQyiHnTJm83Z/MxDPNVTl tNk7LwZU1hwSWMGJfFSagAyUKeTDdwigmKlzF/VakFS9FUaImX1uqYME01HVgGfO5E0a Lu1XGkNEA2MqwEkyhJGJUSos+6X8h6rQS/Qxf/Jz/ASqwFa9j4sqKF+S13uyKvgLQImj EbMZpIh3bTlWyt1v7fKrdUyfsOJ0inf2BnlX2QZbO5q3XXy4Det9QJNd2M7KV/oUvpzc 5emA==
X-Gm-Message-State: APjAAAU+DOjJNnmlPV7tjy/BzAPzSppY/q72HWCDW5OUoV+PogRttI56 qoaI3G4ygEeSXhpbuYthWFzxPdpg
X-Google-Smtp-Source: APXvYqy0NiJg2UWKLVXUjJIgMWTIi/SqegkowOZ2PMp7x9SgJMiaoPVcY14XQIc4O28YM/2UqWcADA==
X-Received: by 2002:ad4:46af:: with SMTP id br15mr13515882qvb.216.1581631337754; Thu, 13 Feb 2020 14:02:17 -0800 (PST)
Received: from [192.168.1.53] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id h8sm2152926qtm.51.2020.02.13.14.02.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Feb 2020 14:02:16 -0800 (PST)
From: Tony Rutkowski <trutkowski.netmagic@gmail.com>
X-Google-Original-From: Tony Rutkowski <trutkowski@netmagic.com>
Reply-To: trutkowski@netmagic.com
To: Nico Williams <nico@cryptonector.com>, Henry Story <henry.story@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
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>
Organization: Netmagic Associates LLC
Message-ID: <8390efa4-a212-f0ee-d78e-8e997242d72a@netmagic.com>
Date: Thu, 13 Feb 2020 17:02:16 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200213213953.GU18021@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/oqd4WafUVKW7rhaTT5jXR5QU3Pk>
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:02:22 -0000

All important electrical communication identifier systems invariably end 
up at the point of nation state regulation. Consider what is occurring 
now with telephone CallerID which went through a full cycle of 
regulation to deregulation to re-regulation.  There are several 
compelling bases.  On one side, nation states have sovereign 
jurisdiction over all communication within their geospatial boundaries 
and assert it for a swath of national security and law enforcement 
reasons.  On the other, the providers seek indemnification (antitrust 
and tort) and the end users an expectation of trust and consumer 
protection.  Consider it a recognition of relevance.

The DARPA DNS itself went through a cycle of strong government 
regulation to deregulation to Ira Magaziner's scheme for healthcare 
governance (a/k/a ICANN) and now likely to re-regulation or irrelevance.

-t


On 2020-02-13 4:39 PM, Nico Williams 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.
>
>> 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