IETF Logo Mail Archive

Re: [saag] post-X509 cryptographic identities

Nico Williams <nico@cryptonector.com> Tue, 11 February 2020 17:02 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 0FD71120809 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:02:49 -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, 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 RjtrgpSXQ4-D for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:02:47 -0800 (PST)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 471F3120806 for <saag@ietf.org>; Tue, 11 Feb 2020 09:02:46 -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 03E8F1A28F5; Tue, 11 Feb 2020 17:02:46 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-206-172.trex.outbound.svc.cluster.local [100.96.206.172]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 832671A1F11; Tue, 11 Feb 2020 17:02:45 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a89.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); Tue, 11 Feb 2020 17:02:45 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Absorbed-Tasty: 65f451684bd08751_1581440565789_2965650806
X-MC-Loop-Signature: 1581440565789:1121562436
X-MC-Ingress-Time: 1581440565789
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id 58B327EC9F; Tue, 11 Feb 2020 09:02:40 -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=5BxD1G5IGCmv1U m9qNg6myFESnk=; b=Keq2zz2Ht1rwJaT+Sq6/qhIuK2Rx3+zt62nbO7AOhvtOJc oxxW8YK10gYZVU0cX8EpZkx55lw++qO+YhOfC2an80cobW3Q7JRDUNHPmG9akCLu +v/Vijwl79JtX/G50VBoPOIe+3ylsKDl9AlGUAIGxM82qVkIli6I0foKGsk7E=
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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 3B89B7E619; Tue, 11 Feb 2020 09:02:20 -0800 (PST)
Date: Tue, 11 Feb 2020 11:02:12 -0600
X-DH-BACKEND: pdx1-sub0-mail-a89
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: trutkowski@netmagic.com, Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Message-ID: <20200211170211.GI18021@localhost>
References: <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> <8ccb201a00d4e693c882225170ca424f.squirrel@mail2.ihtfp.org> <3643.1581431204@dooku> <a8435b3674ac1a98820e7dd653725613.squirrel@mail2.ihtfp.org> <1fe3db74-061a-d241-b9eb-316d2165307c@netmagic.com> <CACsn0cn=wk5k3MKT65=km1nxJBw+1H0e+gvAs_4=rhgazODSWA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACsn0cn=wk5k3MKT65=km1nxJBw+1H0e+gvAs_4=rhgazODSWA@mail.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: gggruggvucftvghtrhhoucdtuddrgedugedrieefgdeltdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/ysYAX8YeebFbKdFphv90UDZYFrM>
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:02:49 -0000

On Tue, Feb 11, 2020 at 08:54:00AM -0800, Watson Ladd wrote:
> Let's actually look at the dominant by order of magnitude application of
> the PKI, namely authenticating servers identified by domain names.
> 
> The authoritative information is in the DNS. The CA system is only an extra
> point of failure here, which is why things like DANE are promising.

Yes!  And with DNSSEC/DANE we can even have an appropriate link to PKIX
and avoid killing off PKIX altogether.

With DANE each site can operate a private CA and attest to it in their
DNS.  For now that's not a workable option for HTTPS server certs
because relying parties are still mired in WebPKI, but there's hope yet.

One could even use TLSA RRsets to indicate the issuer for user
certificates with rfc822Name SANs from a given domain.

> None of the extensions like policy mapping etc.  matter.

+1

Nico
--

v2.23.0 | Report a Bug | By Email