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

["Christian M. Amsüss" <[e-mail]>]

Hello,

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
resource).

> 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
"https://exmaple.com/logo.png" or "coap://example.com/logo.png", 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://example.org/rd>
>     * 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 example.org
>         * example.org has the RPK certificate h'...'
>           (certificate pinning)
>         * Please set up the security association
>           using EDHOC at <coap://example.org/edhoc>
>         * 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
>       'coreapps.org:resource-directory' and
>       'coreapps.org:problem-details'

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
  YetAnotherEcosystem"
* 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 example.org to mean "whoever has
  a good claim through DNSSec or PKI to example.org", maybe we shouldn't
  say example.org 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 example.org, 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).

BR
c

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