Re: [Suit] A few comments on draft-ietf-suit-manifest-02

[Brendan Moran <[e-mail]>]

Hi Russ,

Thank you for your review. I’ll address these comments shortly.

Brendan

> On 20 Jan 2020, at 21:32, Russ Housley <[e-mail]> wrote:
>
> I have a few comment on draft-ietf-suit-manifest-02:
>
> General: The RFC Style Guide says to use American English spelling. Please change it now to avoid confusion later (e.g., Behaviour --> Behavior).
>
> Section 2: Please add a sentence before all fo the definitions.  Otherwise, the "as shown here" from the RFC 8174 citation is easy to read incorrectly.
>
> Section 2: The last 4 paragraphs are not really about conventions or terminology at the same level as the rest of the section.  They are CBOR specific, and I wonder if they would bit better toward the end of Section 4 or the beginning of Section 5 in a subsection of their own.
>
> Section 4: The bullets and numbered items in 4.1 end with periods, but the ones in 4.2 and 4.3 do not.  Please pick one style and use it everywhere.
>
> Section 4.2: In the five steps, is there a problem if an implementations swaps steps 1 and 2?  If so, please explain.  If not, the document should say that conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. That is, any algorithm may be used by a particular implementation so long as it produces the correct result.
>
> Section 4.2 says: "If verification and running is implemented in bootloader, then the".  Please complete the thought.
>
> Section 4.4: I think that "specifies behaviours in a linearised form" can simply be "specifies linear behavior".
>
> Section 4.4: I wonder if "authenticated by the appropriate identity have access to operate" is the right concept.  I think the point is that the process will reject software that is not authenticated to an identity on the ACL.
>
> Section 5.1: RFC 4108 includes the concept of a "stale version".  Please see Section 1.2.3.2 of RFC 4108.  Do we want a capability to prevent roll-back to a previous version that has a disastrous flaw?
>
> Section 7: I find the numbering confusing.  the is a top-level "1" without a "2".  Perhaps typical outline numbering would be more clear.
>
> Section 7 and 11: We need to come up with a presentation that will keep the line length under 73 characters.  Maybe something like:
>
>   SUIT_Common = {
>       ? suit-dependencies
>             => bstr .cbor [ + SUIT_Dependency ],
>       ? suit-components
>             => bstr .cbor [ + SUIT_Component_Identifier ],
>       ? suit-dependency-components
>             => bstr .cbor [ + SUIT_Component_Reference ],
>       ? suit-common-sequence
>             => bstr .cbor SUIT_Command_Sequence,
>   }
>
>
> Section 12: Please say in the introduction what one-way hash function is used.
>
> Section 13: Please provide the rules for additions to each of the IANA registries that are identified.
>
> Russ
>
>
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit

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