[sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid

[Roman Danyliw <[e-mail]>]

Hi!

Thanks for -19 of draft-ietf-sacm-coswid.  Since the conclusion of IETF LC, I reviewed it based on the provided feedback.  I didn't see direct replies to the directorate reviews but from cross-walking their feedback against the -18-to-19 diff, I believe the following are still unresolved/undiscussed.

(1) Scott Bradner did an OPSDIR review -- https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-opsdir-lc-bradner-2021-08-07/.  The following feedback does not appear to be discussed or resolved:

> along the same line - it would seem to me that the IANA repository should be at
> https://www.iana.org/assignments/coswid  (or co_swid) not
> https://www.iana.org/assignments/swid

I believe the comment is about the following text in a few places in Section 6.2.*:

   [TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/swid]

Earlier in the text in Section 6.2:

"6.2.  Software Tag Values Registries

   The following IANA registries provide a mechanism for new values to
   be added over time to common enumerations used by SWID and CoSWID."

It would seem that if in fact things should stay in "assignments/swid", there is a missing registration procedure item -- nothing can be added if it isn't in the SWID specification.  I under the impression from earlier conversations that we wanted to provide flexibility for CoSWID to potentially extend it's own data model independent of SWID (i.e., there could be data elements in CoSWID that were not in SWID).  If so, this suggests that "assignment/coswid" should be used instead (as Scott was suggesting).

(2) Rich Salz did an ARTART review -- https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-artart-lc-salz-2021-08-02/.  The following feedback does not appear to be discussed or resolved:

> In 2.3, why are there three separate bools for corpus/patch/supplemental as opposed to a single enumeration? 

If this is a design choice, please answer Rich.

> Can the tag-id be a digest of the source file?

I think the answer is yes.  It might be worth saying so.

> What are the implications of it not being unique? That should be listed in the security considerations.

I see that this new text was added: "Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching and lookups".  To Rich's point, there are likely security implications to this collision.  Please explicitly describe those.

(3) Robert Sparks did a SECDIR review -- https://datatracker.ietf.org/doc/review-ietf-sacm-coswid-18-secdir-lc-sparks-2021-08-11/.  The following feedback does not appear to have been discussed or resolved:

> Consider RFC6648 (BCP 178) where you are reserving "x_" name prefixes for private use.

Section 4.2 says:

   The values above are registered in the IANA "Software Tag Entity Role
   Values" registry defined in Section 6.2.5.  Additional values will
   likely be registered over time.  Additionally, the index values 128
   through 255 and the name prefix "x_" have been reserved for private
   use.

Section 6.2.5 says:

                   +=========+=========================+
                   | Range   | Registration Procedures |
                   +=========+=========================+
                   | 0-127   | Standards Action        |
                   +---------+-------------------------+
                   | 128-255 | Specification Required  |
                   +---------+-------------------------+

               +=======+=================+=================+
               | Index | Role Name       | Specification   |
               +=======+=================+=================+
               | 0     | Reserved        |                 |
               +-------+-----------------+-----------------+
...
               +-------+-----------------+-----------------+
               | 7-255 | Unassigned      |                 |
               +-------+-----------------+-----------------+

>From the Sec 6.2.5 text, it looks like values 128 - 255 could in fact be assigned.  However, Sec 4.2 says they are reserved for private use.  There may other cases of this.

Thanks,
Roman