Re: [saag] post-X509 cryptographic identities

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 February 2020 11:22 UTC

Return-Path: <mcr@sandelman.ca>
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 441A012004F for <saag@ietfa.amsl.com>; Mon, 17 Feb 2020 03:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.835
X-Spam-Level:
X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 OEd7rGsOmKKC for <saag@ietfa.amsl.com>; Mon, 17 Feb 2020 03:22:40 -0800 (PST)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C538120046 for <saag@ietf.org>; Mon, 17 Feb 2020 03:22:40 -0800 (PST)
Received: from dooku.sandelman.ca (client-141-23-178-142.wlan.tu-berlin.de [141.23.178.142]) by relay.sandelman.ca (Postfix) with ESMTPS id 925901F458; Mon, 17 Feb 2020 11:22:38 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1FAD91A2BAD; Mon, 17 Feb 2020 12:22:38 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Nico Williams <nico@cryptonector.com>
cc: saag@ietf.org
In-reply-to: <20200215184827.GB18021@localhost>
References: <ac360994-e747-6913-fdc3-19b7db2e00c3@netmagic.com> <3854.1581431519@dooku> <20200213174617.GQ18021@localhost> <18044.1581688781@dooku> <20200214203306.GW18021@localhost> <3586.1581771453@dooku> <20200215184827.GB18021@localhost>
Comments: In-reply-to Nico Williams <nico@cryptonector.com> message dated "Sat, 15 Feb 2020 12:48:28 -0600."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 17 Feb 2020 12:22:38 +0100
Message-ID: <3459.1581938558@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/8MeyYvSgUdwYHZ2UbTeQOIpHp6k>
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: Mon, 17 Feb 2020 11:22:42 -0000

Nico Williams <nico@cryptonector.com> wrote:
    > On Sat, Feb 15, 2020 at 01:57:33PM +0100, Michael Richardson wrote:
    >> Nico Williams <nico@cryptonector.com> wrote: > Sure, but PKIX let's
    >> you have this too: it's just an alternate issuer > (root).
    >> 
    >> > What would SPKI have given us, really?
    >> 
    >> No, PKIX does not have an alternate issuer.  That's outside of the
    >> PKIX.  It's another instance of PKIX.

    > Sounds like a matter definitions.

It's not.  It's critically important.
PKIX has no way to name another trust anchor/namespace from within your
current trust anchor/namespace.

X509 was architected on the "There shall be only one" principal, and
all the patching we've had to do (from path name constraints to CT) is to
deal the fact that this is not how things worked out.
[In a strict hierarchal, top-down, PKI, I think a subservient CA would only
ever be able to extend the DN, never change it. That is, constrained would
have been implied]

    >> What SPKI gives is the alternate roots are explainable and codifiable
    >> within the system, rather than making it an externality.

    > Out of curiosity, why couldn't that have been done with PKIX?

Of course, you can write any ASN.1 you want, and you can encode SPKI concepts
in ASN.1, but it wasn't done.

    >> > (A relying party might need to change root trust anchors when
    >> traveling > if they are forced to or want to change roots.)
    >> 
    >> Yes, possibly.  It's definitely an open question, and there is a
    >> tussle there.

    > Sure.  At worst the traveler's origin country and destination might
    > have conflicting requirements and even great firewalls.

So, just like with Netflix: do I get the access of the geo-location of my
credit card, or the geolocation of my device?  Today, in Berlin, I can watch
Big Bang Theory and Dr.Who on netflix (both licensed in Canada to Bell),
while I can't watch Elementary [on Prime].

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [