Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Tue, 11 February 2020 17:32 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 3C70D12099E for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:32:49 -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 ybueLmgqi6sm for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:32:47 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 D65D7120812 for <saag@ietf.org>; Tue, 11 Feb 2020 09:32:46 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id c9so13478805wrw.8 for <saag@ietf.org>; Tue, 11 Feb 2020 09:32:46 -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=TAl5cxonZYDUq62TwyVqlUeUj6GTl7k1bzXyt3UnpO4=; b=nMbfQwqj1wISWwHSimA8nG2RSE0JoEam8p4Oijjl7TC1ZABXkq7ysOG0BaWQSLzmSm vHSbQWu8oqkqXJ+qCH2nfADxKjATCRiV78j/WhhGjN+5ID/QvNOpPGrPHXk/3XMq5VBW LVKGmgYcGP8rpd5b6TyeNAhK9ztGxXVKcXKt6aeAm3Yho7H5EQh/g6lPWZDjAhCoyaN0 vQe0bIp4hIyvUiYYG+cZogLKUwth5upLSwdg8IqwAhlMZG4wQcaYiwyt5Hsi3pPjy8SL oUelLFdKcSbELIzcriLd/1WzEa6I/iff8AW3yGP9c/qTBB3F8k+gRnSsVwdhU5NU3VZx /qdA==
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=TAl5cxonZYDUq62TwyVqlUeUj6GTl7k1bzXyt3UnpO4=; b=tioHqud/PY9WRzA6PCTyepamQEAXgYuXaOQgmnRpGaFDsDp84H7EPE0igl4NIWs/Jg 1AbxMWGO/8Eus/flc+gsiQ4Kl8jJ4km/jFGvUKAC2FvV+1qnTX3srYc6O1AwWncs6RAF 5uWfQa1ZmXQWzzoHQoD4X+hzVCT5Nb6DGYIE/K8qHHRxubcY9lMduDrvlN0VmPPGmMSm bmhPdVMJfo2VjdObRJeE9MSLNd/+Z7lQSQGgcvdVMn61MvEvcA6an7JW8k9fuxvj62i0 pUerno0lOIu47xgSjL3nF6DvmQp+xEEURZs6sBEHgormZDyr9zkkaQeQbA183HIFzInQ m2yg==
X-Gm-Message-State: APjAAAVxrLZfuZrt09OK1I98Yel0wSFS1kQ0BMtb8+wgjeZ+1cUfX9bT SzeazpSnbe++rWvRlLWGlra+nlraRdI=
X-Google-Smtp-Source: APXvYqxT92Ue8XpZhqjQmSU5xFL5S21JKfDz8pATNwlaxSlefSuVnIXry9a2mCJhVreJYuNxPWPUfA==
X-Received: by 2002:adf:e910:: with SMTP id f16mr9495339wrm.20.1581442364921; Tue, 11 Feb 2020 09:32:44 -0800 (PST)
Received: from [192.168.43.200] ([92.184.96.212]) by smtp.gmail.com with ESMTPSA id a198sm4495562wme.12.2020.02.11.09.32.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 09:32:44 -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: <20200211165720.GH18021@localhost>
Date: Tue, 11 Feb 2020 18:32:42 +0100
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Nico Williams <nico@cryptonector.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF09BF39-20E3-4BDE-B1E2-8C84864DF0F7@gmail.com>
References: <157762745765.1150.7880025422884493076@ietfa.amsl.com> <2C5DFA70-AD0E-4139-B28E-2D4EDB6E5409@sinodun.com> <46BDE9EB-6306-4194-AFFA-7E9E6604765F@sinodun.com> <825b8c8e-7ee9-9276-d09e-9c006acf3804@ericsson.com> <CABcZeBOzJ2MRS8deZqN+e-o9tFDwgSrYK3_hmV-0pfO+L9oaVw@mail.gmail.com> <53c87d6b-cad1-3a80-291d-e2a896705da5@ericsson.com> <CABcZeBNJWmFTV==6sa0qnAPyRr4=6OiCacchzobE=RozHnqPdg@mail.gmail.com> <7901248e-c7dd-8a12-65df-f40415fde5e2@cs.tcd.ie> <26497.1581418516@dooku> <20200211165720.GH18021@localhost>
To: saag@ietf.org
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/g_pbM1_7FIRUpgMgAKqX2gL3WCo>
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: Tue, 11 Feb 2020 17:32:49 -0000

Hi all,

  I think that if one is going to rethink security and identity
on the internet one needs to revisit some deep assumptions about
what web site identities are and their relation to legal spaces.

DNSSEC DANE can be an answer to identity of web sites and it can be politically acceptable if DNSSEC moves towards being decentralized on a national basis the way it was designed to be. But it cannot deal with the 
legal aspect of identity which requires deeper tie in to legal systems.

The same is true of X509. It can also work to verify identifiers for
web sites, and Let’s encrypt does a great job for that. 
I explain what is is good and what the limitations are in
"Stopping (https) phishing"
https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9

But one has to think much bigger and from an epistemological point
of view. That is one has to consider what it is that the user of
a browser can learn from the information given to him.
I explain that in 
”Epistemology of the Screen”
https://medium.com/cybersoton/phishing-in-context-9c84ca451314

Currently one learns nearly nothing from an X509 certificate. Nothing
that is interesting enough and useful enough to a user, that they would feel 
like looking there. And nothing that really helps establish trust in an international environment. That requires one to tie these into rich data
provided by legal systems tied into a ”Web of Nations” 
https://co-operating.systems/2019/07/29/Web_of_Nations.proposal.pdf

This is following an idea that we are both individuated by the nations
in which we live (or smaller local structures) and individuate them 
(by helping create standards for example, or writing great poetry, or educating children...). We  then individuate each other through commerce
and intellectual exchange.

In the international space it is nations that provide guarantees of legal status. They themselves form a social network of higher level 
agents of which we are part. To defend this requires some deeper philosophical, and I can provide links to some thinkers working on 
it if needed.
The idea is to build a structure for internations, by linking 
them together in an  open non coercive way, and make it possible for companies to make their legal ties visible to citizens around 
the world, in a purely opt-in manner. 

Hope that helps,

Henry Story
https://co-operating.systems/
@bblfish on Twitter


> On 11 Feb 2020, at 17:57, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Tue, Feb 11, 2020 at 11:55:16AM +0100, Michael Richardson wrote:
>> Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote in a IETF-last call thread:
>>> Anyway overall I take this as more evidence that
>>> x.509-based pki has outlived it's useful lifetime.
>>> Given the webpki needs CT (which it totally does)
>>> and now maybe novel revocation mechanisms like this,
>>> (as well as soon-to-be PQ schemes if we believe
>>> what people tell us), I'd argue it may well be time
>>> to try see if there's any consensus on a post-x.509
>>> direction towards which to head.
>> 
>> I agree with you strongly.
>> A centralized, single CRL from the single global PKI was certainly among the
>> original ideas envisioned.
>> Then we decentralized the PKI, add CT and added OCSP.
>> 
>> Now we are unifying again :-)
>> Mozilla could, for instance, create a new higher-level CA, sign all of the
>> existing trust anchors they ship, and effectively be back at X509.
> 
> The worst thing about x.509/PKIX was x.500 naming, and that's
> essentially fixed by using appropriate SANs.  Sure, it's still awful
> ugly on the inside, but the naming on the outside is now OK.
> 
> That leaves only one lasting bad thing about x.509/PKIX: revocation, and
> the answers to that we already know and have and would implement for
> PKIX as much as for any PK-based replacement.  Short-lived credentials,
> CT, a real root (see below) -- these are things we know to do.
> 
> I wouldn't throw the baby out with the bathwater.
> 
> However, if we must, then naming is the first thing to get right.
> Naming is where the crypto rubber meets the UI/UX road.
> 
> And can I refrain from mentioning that DNSSEC is the _only_ true rooted
> PKI we've ever managed to deploy?  Evidently I can't.
> 
> Nico
> -- 
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag