Re: [DNSOP] Definition of "trust anchor"

George Michaelson <ggm@algebras.org> Mon, 26 March 2018 10:17 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519411242F7 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 03:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 gvfYlM0QwdXJ for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 03:17:40 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 2D8CF127077 for <dnsop@ietf.org>; Mon, 26 Mar 2018 03:17:40 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id s48so18954119qtb.10 for <dnsop@ietf.org>; Mon, 26 Mar 2018 03:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJVAdh3GABBjDGjNoj607nKJLriMLNBeTVvp0tfm6DQ=; b=ZxB9sff/Wl2SMF0dGDBghBbXgNImLWwgwdK4SdWDgiF2f/2U9y8Eq+X8xCNUc+DWZp 3Bh/5kM7xxMtS8iBchxsANS8kHG7eBG24KQ0uk/CdT7HLJTcxqtIwUuFFL9PgTGOdAlb MqINLav/7xcx7juT0BH6yR436CBMWkV2mDOw8BDFrVHn8qBzQGN3EGeip14wBrlag9Lm 6d9pQsxKVcFkvZXAeJ3tThIQ3jpUK/1DiOEzmNb18QFkdqphrFlfKl1C1rc1RGII/smy AFvShL0udOrA+xDKB0vseBKC7sp8AS41B9Cc/G6xpxXFZBYdZcN/SWxwXJu3l+CeV+og +7pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJVAdh3GABBjDGjNoj607nKJLriMLNBeTVvp0tfm6DQ=; b=bEfGV1iQc4LkmmTn5CMt+aufKXksdCGzTu3RxgyoyavZ4G4+1XOgolndODyGYS4+NH htHdCaXpxViHQx3YLxui1AucHIXrAoQsQj6zhzKJsJemvFdkc/0+TmH0kZj0stjaHI8C ZDtp54fatsVSJrcUGYhlIe/OGxn+sxCumc85kASoSthhCpFkKvlb6rAQg6rWi0AqIzg6 OIkBqL/e9dGsVpVQUOAsKdZd37aF/d/tMaIn55qPgmZCOYCzvqTUSIUjWe7GGmpnIc4a sD4AvCXdQWBxA+d7xa4OLiAeWlVw59jFlOYGDqbLdj0Lv9ID7axGDBmT9beh5STRskqG d3dA==
X-Gm-Message-State: AElRT7ECLId4nNRXopByQkbNl0D0fkVZHC691mzCoPkjcJAIFGypvCUJ X2t7el0NL3wtshq7vYtOJuMgOr471kPxOHUM/buRtQ==
X-Google-Smtp-Source: AIpwx48rWwMLtSIDANyOq48OA44fdXQhyeYGVaE7TFZk6HladWx2npkwawpSjCkafzOI3IK+rQk6l+GQhuK05Eujp/I=
X-Received: by 10.200.82.86 with SMTP id y22mr22001860qtn.167.1522059459277; Mon, 26 Mar 2018 03:17:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.37.11 with HTTP; Mon, 26 Mar 2018 03:17:38 -0700 (PDT)
X-Originating-IP: [111.223.108.25]
In-Reply-To: <90927103-F76F-488D-898C-514655CB9035@vpnc.org>
References: <90927103-F76F-488D-898C-514655CB9035@vpnc.org>
From: George Michaelson <ggm@algebras.org>
Date: Mon, 26 Mar 2018 10:17:38 +0000
Message-ID: <CAKr6gn07qX=V_o1CT0w91e3N7p+xeVrE_j13RnyyL-TYaYMSYg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tNpJep040NY4wfS610Z-ha7CFqQ>
Subject: Re: [DNSOP] Definition of "trust anchor"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2018 10:17:42 -0000

This doesn't seem a good fit for the PKI definition of a TA.

You can have several TA. any are sufficient to define a trust point to
anchor validation. you don't care which.

how the path is built, is not the same as where it terminates. top
down or bottom up is legal in PKI.

-G

On Sun, Mar 25, 2018 at 8:21 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> The current text is:
>
> "A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
> validating security-aware resolver uses this public key or hash as
> a starting point for building the authentication chain to a signed
> DNS response." (Quoted from <xref target="RFC4033"/>, Section 2)
>
> The WG has has a preference for quoting from RFCs, but there was also some
> hesitation about this. How would people change this, possibly updating RFC
> 4033?
>
> --Paul Hoffman
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop