Re: [Suit] Murray Kucherawy's Discuss on draft-ietf-suit-manifest-25: (with DISCUSS and COMMENT)

[Orie Steele <[e-mail]>]

Apologies for my somewhat vague i18n concerns.

Regarding "8.4.8.2.  Constructing UUIDs"

Are these identifiers computed over U-Labels or A-Labels in the context of
IDNA DNS Prefixes?

Similar comment for URIs, I would prefer an explicit IDNA statement
regarding URIs, so that implementers know which names contain unicode
characters such as emojis "☕" or "ß", etc...

A citation to "RFC5890" or "RFC8266" would probably resolve my concerns.

Without more precise guidance regarding unicode and i18n, I fear that
identifiers will be computed differently by implementations, which
might lead to dereferencing manifests for servers that were not intended.

OS

On Thu, Feb 29, 2024 at 9:04 AM Murray Kucherawy via Datatracker <
[e-mail]> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-suit-manifest-25: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Holding a DISCUSS position on behalf of IANA to ensure the issue they
> raised
> (currently shown in the tracker) is resolved.
>
> I'm a little puzzled by the use of "nint" as a placeholder in some of the
> registries.  I don't understand what's going on there, and 8.4.8 (where
> it's
> apparently defined) didn't make it any clearer to me.  Can I get a little
> clarification?
>
> ===
>
> >From Orie Steele, incoming ART Area Director:
>
> I have concerns with how i18n and unicode may interact with suite text
> strings
> and suite URIs.  Particularly in the case of fetching remote content.
>
> I am also concerned about the potential IDNA issues with how UUIDs are
> constructed per Section 8.4.8.2.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The shepherd writeup doesn't include the reason that PS is the right status
> here.
>
> ===
>
> >From Orie Steele, incoming ART Area Director:
>
> In the abstract:
>
> This would be clearer if the first use of "IoT" were
> expanded.  (https://www.rfc-editor.org/materials/abbrev.expansion.txt
> does not mark either as "well-known".)
>
> Side note, is "Internet of Things Software Update (IoTSU)" a relevant /
> useful
> acronym here?
>
> In Section 4.2 consider defining "pull parser", prior to using the term.
>
> "The bootloader may add its own authentication, e.g. a Message
> Authentication
> Code (MAC), to the manifest in order to prevent further verifications."
>
> Why?
>
> In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference.
>
> Section 5.4
>
> Comment: "Severable Elements", seems similar to selective disclosure and
> elision, you might want to relate your definitions to other industry
> terminology.
>
> Section 6.2
>
> """
> If a Recipient supports groups of interdependent components (a Component
> Set),
> then it SHOULD verify that all Components in the Component Set are
> specified by
> one update, """
>
> Under what circumstances can a recipient benefit from not verifying all
> components in the component set are specified by one update? (Why not MUST)
>
> Noting Section 8.4.3 and Section 8.4.4 have internationalization
> considerations.
>
> Section 8.4.8.10
>
> '""
> A URI Reference RFC3986 from which to fetch a resource, encoded as a text
> string. """
>
> I believe this precludes URI's that contain unicode, you might consider
> borrowing some language from
>
> https://datatracker.ietf.org/doc/html/rfc9525#name-identifying-application-ser
>
> """
> The information used to create the class-id condition (see
> {{uuid-identifiers)
> """
>
> Reference typo.
>
> Section "8.4.5.1. SUIT_Component_Identifier"
>
> I'd prefer to see unicode considerations in this section.
>
> in Section 11.8
>
> Are expired Internet drafts considered acceptable "stable references" for
> "standards track range of point assignment"... If not, please give concrete
> guidance to the experts regarding managing registrations of references that
> expire.
>
> """
> When specifications are not provided, the description provided needs to
> have
> sufficient information to identify what the point is being used for. """
>
> Sounds like you are asking for registries that are "Expert Review" not
> "Specification Required", please confirm after reading:
>
> https://datatracker.ietf.org/doc/html/rfc8126#section-4.6
>
> Extra text in each registry section, would make all this a lot clearer, as
> I
> noted in the beginning of my comments.
>
> In Section 11.9
>
> Why not "application/suit-envelope+cose", under what circumstances can a
> suite
> envelope be transmitted as application/cose ?
>
> If there will never be other expressions that are not COSE,
> "application/suit-envelope" seems fine.
>
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>