Re: [saag] post-X509 cryptographic identities
Nico Williams <nico@cryptonector.com> Fri, 14 February 2020 20:33 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 4958A1201AA for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 vU2eGWil03L6 for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:33:30 -0800 (PST)
Received: from basenji.birch.relay.mailchannels.net (basenji.birch.relay.mailchannels.net [23.83.209.12]) (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 B3A0F1201DE for <saag@ietf.org>; Fri, 14 Feb 2020 12:33:17 -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 AC1B25025CC; Fri, 14 Feb 2020 20:33:16 +0000 (UTC)
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-217-4.trex.outbound.svc.cluster.local [100.96.217.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0282F502583; Fri, 14 Feb 2020 20:33:16 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a88.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); Fri, 14 Feb 2020 20:33:16 +0000
X-MC-Relay: Junk
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Scare-Stupid: 02296a8b2ef2e153_1581712396464_3400858473
X-MC-Loop-Signature: 1581712396464:236097024
X-MC-Ingress-Time: 1581712396464
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id 3EDB8A466D; Fri, 14 Feb 2020 12:33:11 -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; s=cryptonector.com; bh=NZ1kRUioBhGLZn dpCH++ypI2Z98=; b=pYrB48FAifDltfg24nW7GAOVBP8Rxr0xCy2+6DzmmY8Uij O5uPLDHLngoQ7kz62+FwAuMEeZNKinZHFmSk9ebapDT4T3BB52kOfmCMDbk+hCyu 6RPMeAA+OFQ46krZG3AnUBlZv66rj/F8eevrs3INUJrUz1sKnePnvUN9RBmLQ=
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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 30090A466B; Fri, 14 Feb 2020 12:33:09 -0800 (PST)
Date: Fri, 14 Feb 2020 14:33:07 -0600
X-DH-BACKEND: pdx1-sub0-mail-a88
From: Nico Williams <nico@cryptonector.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: saag@ietf.org
Message-ID: <20200214203306.GW18021@localhost>
References: <ac360994-e747-6913-fdc3-19b7db2e00c3@netmagic.com> <3854.1581431519@dooku> <20200213174617.GQ18021@localhost> <18044.1581688781@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <18044.1581688781@dooku>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrjedtgddugedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpegtrhihphhtohhnvggtthhorhdrtghomhdptghrhihpthhnvggtthhorhdrtghomhdpvgigrghmphhlvgdrtghomhdprghmrgiiohhnrdgtohhmpdhthhgvihhrrdgtohhmpdhkihhllhdrtghomhenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/v97E3DaF1aNjM0ADgjmh4P0RRyA>
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: Fri, 14 Feb 2020 20:33:34 -0000
On Fri, Feb 14, 2020 at 02:59:41PM +0100, Michael Richardson wrote: > Nico Williams <nico@cryptonector.com> wrote: > > It seems like a miracle that we have DNS at all. > > > And when you talk about x.509 naming, it really does seem to mean that > > you're referring to dNSName SANs, so, DNS. > > > It seems unlikely to me that we could replace a global system we have > > (DNS) with a non-global system. That's a lot of value to leave behind! > > SPKI permitted things like: > DNS's www.cryptonector.com > or: Nico's second-floor bathroom And for the first it's no different than PKIX. And it'd better have name constraints or it's worth diddly squat. (It's hard to come up with a generic syntax for the second name form that is amenable to name constraints, of course. Name constraints in that case have to be relying-party-side configuration. That's OK for simple name forms that are not meant to scale to Internet scale.) > and in particular it would permit: > or: Russia's nameservice cryptnector.com (national DNS root) > or: employer.example.com's www.amazon.com (forced corporate proxy) Sure, but PKIX let's you have this too: it's just an alternate issuer (root). What would SPKI have given us, really? > >> Typical PKI implementations just makes it really hard for end users to > >> actually manage their trust anchors, because it pretends that the > >> local trust anchors were a pronouncement from god. > > > Yes. But that's not a fault of PKIX, or DNS, or anything other than > > the > > I agree, it's not inheirently the result of PKIX, but then we got meaningless > junk like CPS which makes it really hard for people (even lawyers) to have > their own. CPS is useless lipstick on a pig (WebPKI), so don't use it. > > So I take the opposite view: a single global namespace IS fine. It may > > well be the single biggest key to the Internet's success. WebPKI is > > busted. ISTM incorrect to conclude that because WebPKI is busted, and > > that because the "I" in it wanted it to be a single global namespace, > > that then it must be that a global namespace is bad. > > In the SPKI days I wanted no DNSSEC root. > I wanted 158 national roots with k-of-n cross-signatures. Cross-signing roots ~= a root anyways. Every country could run its own roots with mostly or entirely the same contents as all the others. From a relying party's point of view, there's a single root, and _that_ is what matters. (A relying party might need to change root trust anchors when traveling if they are forced to or want to change roots.) I.e., DNS and DNSSEC are no as strongly single-rooted as they are made out to be, we can continue to have interop with multiple mostly-the-same national roots, and still avoid the mess of WebPKI because for every RP there will always only be one root. This can only introp well provided that the alternate roots keep the same public keys for all the TLDs, naturally, but it's feasible and workable and radically different from WebPKI. > Countries would recognize (in the political/legal, UN sense) each other by > signing each other's ccTLD trust anchors. > > Everyone in Canada would be obligated by law to use the "CA" trust anchors, > and to get to "amazon.DE", I'd have to go "CA-cross->DE->amazon". Sure. We could still have this, but people sure like their .com domains. Without legal requirements to use ccTLDs, they won't be. > Which definitely lets my government spoof me, which they already say they > have the right to do under certain circumstances, but it doesn't let them > spoof you. Would we have to kill ".com", etc. and all the ICANN zoo? > Maybe. It's not a big loss to me, but others would object. And we don't need > to do it overnight. Yes. But if governments won't force you to do this, I don't mind. That is, we can have a single-root PKI (or a cross-signed root if you prefer) in all cases. And we can have mandatory or optional use of ccTLDs. It's all good. > It also means that my government is assuming liability if I get spoofed, > which also seems reasonable. Sovereigns always immunize themselves. You will not be able to sue your government over attacks on you resulting from your country's ccTLD private keys being compromised. At best some may be able to avoid some losses when their counter-party is also operating in the same country, but only entities other than their government will be taking the losses. > >> learn this practice as infants. In the family environment names work > >> as identifiers, even today. What we learn as infants is especially > >> difficult to re-learn later in life. Therefore, it is natural for > >> people to translate the need to know who the keyholder is into a need > >> to know the keyholder's name. > > > Locality in naming usage does not imply that a global namespace is bad. > > So, we see this in things like maps where national authorities inform > google/bing/etc. what the official name of a conquored place is, in > contradiction to what name the locals, (and possibly, the world) use. > I don't know which name is global and which name is local, but I can do all > of that with relative (SPKI) names. Names relative to global names are still global names. Names relative to name-less issuers are truly local names: local to RPs that trust those issuers. But RPs cannot trust very many such issuers, so PKI for local names is not very interesting. Nico --
- [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Derek Atkins
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Derek Atkins
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Watson Ladd
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Stephen Farrell
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Eric Rescorla
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Stephen Farrell
- Re: [saag] post-X509 cryptographic identities Eric Rescorla
- Re: [saag] post-X509 cryptographic identities Stephen Farrell
- Re: [saag] post-X509 cryptographic identities Eric Rescorla
- Re: [saag] post-X509 cryptographic identities Stephen Farrell
- Re: [saag] post-X509 cryptographic identities Eric Rescorla
- Re: [saag] post-X509 cryptographic identities Stephen Farrell
- Re: [saag] post-X509 cryptographic identities Peter Gutmann
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Tony Finch
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Watson Ladd
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Phillip Hallam-Baker
- Re: [saag] post-X509 cryptographic identities Phillip Hallam-Baker
- Re: [saag] post-X509 cryptographic identities Tony Rutkowski
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Phillip Hallam-Baker
- Re: [saag] post-X509 cryptographic identities Phillip Hallam-Baker
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Henry Story
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Michael Richardson
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Viktor Dukhovni
- Re: [saag] post-X509 cryptographic identities Nico Williams
- Re: [saag] post-X509 cryptographic identities Tony Finch
- Re: [saag] post-X509 cryptographic identities Michael Richardson