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

[Roman Danyliw <[e-mail]>]

Hi!

I wanted to check in on the progress of addressing this IETF LC feedback.  At IETF 112, we had discussed and agreed that these would be responded to by the week after the meeting (Friday, Nov 19).

Thanks,
Roman

> -----Original Message-----
> From: sacm <[e-mail]> On Behalf Of Roman Danyliw
> Sent: Thursday, October 21, 2021 10:16 AM
> To: <[e-mail]> <[e-mail]>
> Subject: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
> 
> 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
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm