Subject: Re: [Suit] SUIT manifest: suit-parameter-uri ... reference?

From: Brendan Moran <[email-masked]>
Date: Mon, 12 Jul 2021 19:23:05 +0000

Hi Christian,

I understand what you’re trying to achieve here. But is it necessarily the right way to do things? SUIT has a mechanism for replacing URIs if and only if the manifest author permits it. Do you think that a URI Reference is necessarily a better choice than that here?

I have several concerns with URI References: 1) They leave the “relative to what” question very murky when a manifest is received via a push operation. 2) They could leave the recipient with no way to fetch the payload except, maybe, attempting to fetch it from the canonical manifest reference URI + URI Reference.

In the USB-Stick scenario, it seems better, but that leaves out the possibility of simply bundling the manifest with the payload in the envelope, which is preferred in filesystem-type deployments.

Best Regards,
Brendan

> On 23 Feb 2021, at 16:07, Christian M. Amsüss <[email-masked]> wrote:
>
> Hello SUIT authors,
>
> toying with the RIOT implementation of SUIT I was surprised it required
> the suit-parameter-uri that points from the manifest to the firmware to
> not support relative references, even though in their deployment the
> device obtains the manifest from the web.
>
> The current wording in suit-manifest is ambiguous to me: On the one hand
> it says "a URI" (and not "a URI reference"), on the other hand it
> compares it to Tag 32 (which is somewhat misleadingly named "URI" but
> described to match URI-reference), and makes rules about fragment-only
> references.
>
> Some clarification (saying "A URI reference from which" could suffice)
> would help here.
>
> If this is more than an editorial oversight (that is, if
> neither-full-nor-fragment references have not been considered), I hope
> that relative references stay allowed, as they are useful during ad-hoc
> network situations.
>
> Best regards
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 27 Jul 2021 00:45:32 +0200

Hello Brendan,

> I understand what you’re trying to achieve here. But is it necessarily
> the right way to do things? SUIT has a mechanism for replacing URIs if
> and only if the manifest author permits it. Do you think that a URI
> Reference is necessarily a better choice than that here?

There's two things to this really -- a) what I've been trying to do
(which is what RIOT does right now, and, with current knwoledge, may not
be ideal), and b) the ambiguity in the specification on what is
syntactically supposed to be here.

> I have several concerns with URI References: 1) They leave the
> “relative to what” question very murky when a manifest is received via
> a push operation. 2) They could leave the recipient with no way to
> fetch the payload except, maybe, attempting to fetch it from the
> canonical manifest reference URI + URI Reference.

For the "realtive to what" in ushes, RFC3986 has the default base URI,
which I suppose SUIT could define to be unusable. For not having a way
to fetch the payload ... well, in that there's no difference to the
application between a broken (because unresolvable because baseless)
relative reference and a URI of a scheme the device simply can't use.

Nevertheless, on a syntactic level, as long as both full URIs and
fragment-only references are accepted, what's in a suit-parameter-uri is
a URI reference, and should be labelled as such.

If, then, it is useful for SUIT to limit the usable references to the
shapes URI and "#" fragment, that's a valid choice, even if I may find
it oddly limiting.

It may instead make sense to state explicitly that there is no default
base URI, and that relative references that are neither URIs nor
fragment-only are only usable for manifests obtained through URI
dereferencing.

But at least that they are relative references IMO needs to be stated
clearly, for otherwise the mentions of fragment-only references in
section 7 make no sense.

BR
c

---

From: Brendan Moran <[email-masked]>
Date: Wed, 28 Jul 2021 23:15:58 +0000

Hi Christian,

In short, you’re correct and I’ll address this at the SUIT meeting. (See below)

Best Regards,
Brendan

> On 26 Jul 2021, at 23:45, Christian Amsüss <[email-masked]> wrote:
>
> Hello Brendan,
>

You are correct. I’m not sure why that didn’t stand out to me on the first reading through this, but we certainly do discuss fragment-only references. If we have fragment-only references, then the content of “suit-parameter-uri” MUST be a URI-Reference. I’ve got an item for discussion on this in the slides for this week!

> relative reference and a URI of a scheme the device simply can't use.

You’re correct. I’m inclined to make it “relative to the canonical URI"

> a URI reference, and should be labelled as such.

Agreed