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

Hi!

Checking in again.  What is the notional schedule to resolve this feedback?

Regards,
Roman

> -----Original Message-----
> From: Roman Danyliw <rdd@cert.org>
> Sent: Friday, December 3, 2021 1:40 PM
> To: Roman Danyliw <rdd@cert.org>rg>; <sacm@ietf.org> <sacm@ietf.org>
> Subject: RE: IETF LC Directorate reviews for draft-ietf-sacm-coswid
> 
> 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 <sacm-bounces@ietf.org> On Behalf Of Roman Danyliw
> > Sent: Thursday, October 21, 2021 10:16 AM
> > To: <sacm@ietf.org> <sacm@ietf.org>
> > 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
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm