Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)

Christian Amsüss <christian@amsuess.com> Sun, 07 March 2021 17:00 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781AA3A1949; Sun, 7 Mar 2021 09:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3RCiCgC5UH0T; Sun, 7 Mar 2021 09:00:48 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AA13A1910; Sun, 7 Mar 2021 09:00:48 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8B48740897; Sun, 7 Mar 2021 18:00:45 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0441ED3; Sun, 7 Mar 2021 18:00:44 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:73a1:128f:55bf:b6cf]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 909A210A; Sun, 7 Mar 2021 18:00:43 +0100 (CET)
Received: (nullmailer pid 3219855 invoked by uid 1000); Sun, 07 Mar 2021 17:00:43 -0000
Date: Sun, 07 Mar 2021 18:00:43 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Carsten Bormann <cabo@tzi.org>, Jaime Jiménez <jaime.jimenez@ericsson.com>, core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG <iesg@ietf.org>, core@ietf.org
Message-ID: <YEUGuw5ZuAcfOhCW@hephaistos.amsuess.com>
References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <YDkUiTAo0YlEOMfw@hephaistos.amsuess.com> <20210227205638.GJ21@kduck.mit.edu> <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> <20210227213759.GN21@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="TnqGgIUpo1AhH34/"
Content-Disposition: inline
In-Reply-To: <20210227213759.GN21@kduck.mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/m2SRK3FTVawyUVO3CZAoEJS5c9k>
Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2021 17:00:52 -0000

Hello Ben, Carsten,

On Sat, Feb 27, 2021 at 01:37:59PM -0800, Benjamin Kaduk wrote:
> On Sat, Feb 27, 2021 at 10:01:35PM +0100, Carsten Bormann wrote:
> > > use "authoritative" instead of
> > > "authorized" in the couple places I indicated
> > 
> > Authoritative sounds like it is an intrinsic property of the source.
> > Authorized means that the specific policies that apply to the consumer authorize use of the source for the purpose at hand.
> > So I think this substitution should not occur lightly.
> 
> When the data in question is "what resources are available at this host", I
> think authoritative is pretty intrinsically a property of the host itself :)
> 
> Now, if the question was "what resources are supposed to be at this host
> that I'm allowed to use?", your considerations become quite relevant.

After several attempts to phrase the text to reflect that sentiment, I
am now of the opinion that that getting this picture over in a fashion
that is both comprehensible and correct takes more explanation than is
helpful for understanding RD at large.

Distinguishing between what a requires authorization and what is
authoritative information implies making a call on what is factual
information and what is an assertion on a resource, and these depend on
the semantics of the individual attributes which can not be done
universally:

* A statement on a resoure like the attribute <...>;trustworthy=yes is
  an assertion on which the ultimate authority is with the entity defining
  the security policies. 

* An attribute like <...>;rt="...:firmware" is factual in a sense (after
  all, what a malicious party hosts there is *some* firmware) but also
  the prime example of something that needs additional authorization to
  state.

* A statement like the plain "</res/fw>" is factual and can thus
  authoritatively be claimed by the endpoint. Still, some applications
  (not those we define because we adhere to BCP190) may ascribe
  semantics to it that need more authorization than just relaying a
  factual statement.

Pitting all those on the term "authorized" is admittedly pulling in
aspects of authority, but plucking them apart would help neither the
casual nor the careful reader.

Hoping that this contributes to your satisfaction with the
now-to-be-submitted -28
BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom