[Suit] draft-ietf-suit-architecture-00.txt

[Carsten Bormann <[e-mail]>]

I had a quick look at this while preparing for the Interop.

Summary: needs work.

The sections are rather inhomogeneous.  The introduction seems to believe this is all about authentication, while Section 3.9 onwards and 4 seem to know that this is really all about authorization.  The introduction claims to be done with just three players, while it later becomes clear there are so many more. etc.  We probably need to make up our minds which of these are part of the “architecture” and which ones are just enabled by the architecture (which may not need to describe every single step of validating an authorization).

The term “claim” is heavily misused.  A claim is just that, a claim.  An instruction to a device to do something is not a claim (at least not without the information what the audience of this instruction is — “all X are instructed to…” is indeed a claim).  In any case, claims (containing instructions or not) always need to be evaluated in the authorization framework of the entity trying to make use of the claim.

Another example of the seeming naiveté of the introduction: Rollback needs to be properly authorized, not summarily prevented.
(Like any other firmware state change, a.k.a. “upgrade”.)

Most importantly, we need to be very clear what expressions such as “signing the manifest” actually mean, i.e., what exactly is the claim that is signed by that signature.

I also have some editorial comments I’ll send directly to the authors.

Grüße, Carsten