Re: [core] Tossing around URIs to use outside an application

"Christian M. Amsüss" <> Tue, 25 May 2021 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36D4F3A1E0D for <>; Tue, 25 May 2021 02:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dwxNMpj7DP9Q for <>; Tue, 25 May 2021 02:30:27 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0948C3A1E07 for <>; Tue, 25 May 2021 02:30:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 7754E4073E; Tue, 25 May 2021 11:30:17 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 66A7F108; Tue, 25 May 2021 11:30:15 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPSA id 32629CD; Tue, 25 May 2021 11:30:15 +0200 (CEST)
Received: (nullmailer pid 1749731 invoked by uid 1000); Tue, 25 May 2021 09:30:14 -0000
Date: Tue, 25 May 2021 11:30:14 +0200
From: "Christian M. Amsüss" <>
To: Klaus Hartke <>, Carsten Bormann <>
Cc: " WG" <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Bl7awLLtwY1G8qht"
Content-Disposition: inline
In-Reply-To: <> <> <>
Archived-At: <>
Subject: Re: [core] Tossing around URIs to use outside an application
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 09:30:33 -0000


On Sat, May 22, 2021 at 02:44:32PM +0200, Klaus Hartke wrote:
> In addition to secure usage, this came also up with respect to the
> vocabularies used e.g. in CoRAL documents. I.e., if we need to pass
> more than just a URI, such as security-related information, could we
> also pass vocabulary-related information in the same way?

Well we already *have* methods for hint-level metadata, as in ct="0 40".
(Not sure whether we'll want to use content format numbers there or
something on a more detailed level, but I think it should be hint-level
negotiation just the same, with multiple possible representations of a

> When a Web browser is tossed a URI, it's preconfigured with a set of
> root certificates and a single purpose: Make a GET request to that URI
> and render the resulting HTML document. In a CoREnvironment, there are
> probably no root certificates and no predefined purpose.

There may not be root certificates, but I think that the same semantics
can still be applied: If someone requests, say, that a resource's
representation be shown on a display, and gives the resource's name as
"" or "coap://", in both
cases a PKI'd certificate is a sane default to provide.

Sure, for most plain IP addresses, no such guarantee ca be made, but
even that may not hold: If the IP address is part of a VPN, host
authentication would be such a sane default. Similarly,
"https://3g2upl4pq6kufc4m.onion/" is also self-contained in that any
host that can access the resource can also make sure the server's
identity is what whoever sent the URI intended.

(Same goes for URNs, by the way: When someone hands over a blob and
claims that to be identified by urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
that can not be verified without more context. But nih:sha-256-32;53269057;b
can be used to verify alleged representations).

> At a minimum, you probably always toss a URI together with something
> like "Your resource directory is at this URI" or "Please POST your
> sensor data to this URI".

Yes -- either (as Carsten observed) in a link relation, or by the
precise point you place the URI. (Even if a system were not to work with
link-format or CoRAL style links: If, on a thusly defined system, you
PUT a plain URI to /2/0/1/3/2, that may *mean* "this is the resource to
POST your sensor data to").

On Sat, May 22, 2021 at 10:09:04PM +0200, Carsten Bormann wrote:
> If that document does contain a link relationship (and possibly
> further parameters), these become part of the application state,
> hopefully together with the provenance of that tossed document.

On Sat, May 22, 2021 at 02:44:32PM +0200, Klaus Hartke wrote:
> Additionally, you probably also need to configure some certificate/PSK
> and the intents/wills of the stakeholders/principals involved. Maybe
> some of that needs to be set directly, maybe some could be discovered
> through a layer of indirection. Is there something we could
> standardize here?

Sure, the link relation is part of the document (or its context), but
anything more should be as-necessary.

I'd like to reach a point where you *can* add some information about the
link (or the target?), but that'd be optional add-in because wherever it
makes sense there are good defaults.

These configurations may be separate even: Setting the address(es) of
the light switches may be done by a different entity (say, an RD
through which things are discovered) than setting the requirement that
switching commands must carry this or that authorization.

> That's an interesting thought. I guess, a fully self-contained
> document could then look a bit like this:
>     Please register your resources with the resource
>     directory at <coap://>
>     * But I don't fully trust it, so better only
>       register your public resources
>       (will of the device owner)
>     * Also, the resource directory allows you to
>       register only resources related to
>       YetAnotherEcosystem
>       (will of the RD owner)
>     * To access the URI, you'll need to have an
>       OSCORE security association with
>         * has the RPK certificate h'...'
>           (certificate pinning)
>         * Please set up the security association
>           using EDHOC at <coap://>
>         * But I don't want you to use any ciphersuite
>           based on SHA-1
>     * To access the URI, you'll also need an
>       authorization (bearer) token
>         * Specifically, you need a token with the
>           scope "Register YetAnotherEcosystem
>           resources in a resource directory"
>         * You can obtain the token using ACE
>           from the authorization server at
>           <coap://as.example/>
>             * Please connect to as.example using DTLS
>             * Use these X.509 root certificates for
>               that: ...
>     * When you access the URI, you'll need to
>       understand the CoRAL vocabularies
>       '' and
>       ''

These are all good things to express. Most of these are all hint-level
-- it's good to have all these in advance (saving long back-and-forths),
but things should just as well work out if not (in the order as above,
not in the order in which it would fail):

* Trying to register anything outside of YetAnotherEcosystem would err
  with an understandable problem detail of "sorry wrong dictionary, use
* Accessing the RD without EDHOC-initiated OSCORE would be Unauthorized
  and contain a hint as to the EDHOC resource.
* Failure to use an ACE token (we don't have anything ACE+EDHOC yet, do
  we?) would result in 4.01 with an application/ace+cbor payload (which
  AFAIR can indicate the AS and necessary claims)
* The CoRAL vocabularies should be indicated in the message in some way
  (like content-formats are; if you request without Accept and get
  something you don't understand, better request again).

Of those that are not, I'm not sure they're best expressed here:

* the "better only register your public resources" could be grouped with
  "register your resources" command
* "No SHA-1" sounds like something decided per device, or part of the
  pinned certificate (we don't do hashes anyway without indicating the
  hash function).

* Certificate pinning: If we don't mean to mean "whoever has
  a good claim through DNSSec or PKI to", maybe we shouldn't
  say here, but use a named device identifier in the first
  place. (rdlink comes to mind, but so do all systems that influenced
  it, including Tor, IPFS and magnet URIs).

  Otherwise, what good is the URI in the first place? If it's only
  usable with metadata, we could just as well split it up into "contact
  the server resolved from, require RPK this-and-that, use
  path "/rd" -- the URI alone has no value then any more, and I'm not
  ready to concede that point yet. (In particular, if any input vector
  of URIs can make conflicting requirements on their authentication
  properties, this defeats collaboration between components inside a
  system, as the URI is no usable cache key any more).


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