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

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jan 2022 21:56:15 +0000

Hi!

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

Regards,
Roman

> -----Original Message-----
> From: Roman Danyliw <[email-masked]>
> Sent: Friday, December 3, 2021 1:40 PM
> To: Roman Danyliw <[email-masked]>; <[email-masked]> <[email-masked]>
> 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 <[email-masked]> On Behalf Of Roman Danyliw
> > Sent: Thursday, October 21, 2021 10:16 AM
> > To: <[email-masked]> <[email-masked]>
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sacm

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 24 Jan 2022 12:26:01 +0100

And here are the corresponding responses. Scott, Rich, and Robert are 
included to the TO, analogously.

On 21.10.21 16:16, Roman Danyliw wrote:
> 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.*:
> 
> 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).

This seems to be a misunderstanding that we did not capture well. The 
registry we are looking for must serve both the SWID space and the CoSWID.
While these are fueled by two documents - namely from ISO-IEC and IETF - 
it is beneficial for interoperoperabitly to align them. Now - we 
understand that SWID is not CoSWID and that the IETF is not responsible 
in any way how ISO operates. Yet, IETF will be in charge of the registry 
from now on - and ISO action will have to work throgh the IETF process 
as defined in the I-D. And that is a decision made in consensus with the 
ISO authors and the SACM WG.

There is no requirement in CoSWID or the registration procedures that 
require anything added to a registery must first exist in the ISO-IEC 
SWID specification.

In summary, that is why it is okay to do the registry under 'swid'. This 
is also why the name 'swid' was chosen as a neutral name for software 
identification that can serve both uses for the registered values.

> 
> (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?
> 

This was a design decision to keep CoSWID in sync with ISO-IEC SWID, 
which has 3 separate bools. This allows interoperability between SWID 
and CoSWID which is a design requirement.

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

Yes. There are few requirements on how to structure the tag-id. It is 
treated as a simple string, which allows a digest to be used. This would 
only be practical if the SWID tags is for software that is a single 
file. That is fringe case.

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

Addressing missing statements for clarifications in the Security 
Consideration Section via 
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/45

NEW:
Since the tag-id of a CoSWID tag can be used as a global index value,
failure to ensure the tag-id's uniqueness can cause collisions or
ambiguity in CoSWID tags that are retrieved or processed using this
identifier. CoSWID is designed to not require a registry of identifiers.
As a result, CoSWID requires the tag creator employ a method of
generating a unique tag identifier. Specific methods of generating a
unique identifier are beyond the scope of this specification. A
collision in tag-ids may result in false positives/negatives in software
integrity checks or mis-identification of installed software,
undermining CoSWID use cases such as vulnerability identification,
software inventory, etc. If such a collision is detected, then the tag
consumer should contact the maintainer of the CoSWID to have them issue
a correction addressing the collision.

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

The text around 'x_' was an actually an artifact and has been removed.

---

From: Scott Bradner <[email-masked]>
Date: Mon, 24 Jan 2022 06:32:49 -0500

> On Jan 24, 2022, at 6:26 AM, Henk Birkholz <[email-masked]> wrote:
> 
> And here are the corresponding responses. Scott, Rich, and Robert are included to the TO, analogously.
> 
> This seems to be a misunderstanding that we did not capture well. The registry we are looking for must serve both the SWID space and the CoSWID.
> While these are fueled by two documents - namely from ISO-IEC and IETF - it is beneficial for interoperoperabitly to align them. Now - we understand that SWID is not CoSWID and that the IETF is not responsible in any way how ISO operates. Yet, IETF will be in charge of the registry from now on - and ISO action will have to work throgh the IETF process as defined in the I-D. And that is a decision made in consensus with the ISO authors and the SACM WG.
> 
> There is no requirement in CoSWID or the registration procedures that require anything added to a registery must first exist in the ISO-IEC SWID specification.
> 
> In summary, that is why it is okay to do the registry under 'swid'. This is also why the name 'swid' was chosen as a neutral name for software identification that can serve both uses for the registered values.

OK - is that going to be clarified in the document?

Scott

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 24 Jan 2022 12:38:14 +0100

Hi Roman,
hi list,

the editors finally managed to find joint work time to address the 
remaining issues! To retain some readability, the corresponding 
responses are included in the previous message as a reply to your 
initial email (which actually should have been a following message, but 
I messed that sequence up :-)

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 25 Jan 2022 21:53:42 +0100

Hi Scott,

yes, we added some clarifying text to section 6.2.

Does that address your open issue appropriately?

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 25 Jan 2022 21:55:02 +0100

And we create the proposal here:

> https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/46

:-)

On 25.01.22 21:53, Henk Birkholz wrote:
>>>> 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:
>>>>> should be at
>>>> Section 6.2.*:
>>>> "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).
>>>
>>> While these are fueled by two documents - namely from ISO-IEC and 
>>> IETF - it is beneficial for interoperoperabitly to align them. Now - 
>>> we understand that SWID is not CoSWID and that the IETF is not 
>>> responsible in any way how ISO operates. Yet, IETF will be in charge 
>>> of the registry from now on - and ISO action will have to work throgh 
>>> the IETF process as defined in the I-D. And that is a decision made 
>>> in consensus with the ISO authors and the SACM WG.
>>>
>>> In summary, that is why it is okay to do the registry under 'swid'. 
>>> This is also why the name 'swid' was chosen as a neutral name for 
>>> software identification that can serve both uses for the registered 
>>> values.
>>

---

From: Scott Bradner <[email-masked]>
Date: Tue, 25 Jan 2022 15:55:31 -0500

yup - tnx

Scott

> On Jan 25, 2022, at 3:53 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Scott,
>

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 25 Jan 2022 21:42:35 +0000

Hi!

> From: Henk Birkholz <[email-masked]>
> Sent: Tuesday, January 25, 2022 3:54 PM
> To: Scott Bradner <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked]; Salz, Rich
> <[email-masked]>; Robert Sparks <[email-masked]>
> Subject: Re: [sacm] IETF LC Directorate reviews for draft-ietf-sacm-coswid
> 
> Hi Scott,
> 
> 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:
> >>> 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
> >> While these are fueled by two documents - namely from ISO-IEC and IETF - it
> is beneficial for interoperoperabitly to align them. Now - we understand that
> SWID is not CoSWID and that the IETF is not responsible in any way how ISO
> operates. Yet, IETF will be in charge of the registry from now on - and ISO
> action will have to work throgh the IETF process as defined in the I-D. And that
> is a decision made in consensus with the ISO authors and the SACM WG.
> >>
> require anything added to a registery must first exist in the ISO-IEC SWID
> specification.
> >>
> >> In summary, that is why it is okay to do the registry under 'swid'. This is also
> why the name 'swid' was chosen as a neutral name for software identification
> that can serve both uses for the registered values.
> >

Has something changed?  During the AD review (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/):

==[ snip ]==
** There are a number of places in the text where normative guidance is framed as "SWID/CoSWID".  Is this document suggesting any behavior of SWID, or is that just a short-hand because this CoSWID is just a different representation of the SWID information (?) /data(?) model?  What is the SWID behavior relative to the IANA registries?

** In the long term, will SWID and CoSWID diverge and how should this be handled? This spec seems to defined a number of helpful extension points.  Does SWID have to use those? It might be helpful to clarify that in the text.  Section 2.2 (i.e., "The inclusion of extension points ...") and Section 2.3 ("... references to the IANA registries will be added to the next revision of [SWID]")hints that only future version of SWID might pick up these extensions.  The Section 5 IANA registrations call the registries "SWID/CoSWID" which seems confusing since SWID doesn't use them now.  Can you help me understand the state of play with SWID.  Without the background, it seems like a big leap that we're going to make registries for future work in another SDO (if they haven't already asked).
==[ snip ]==

I posed a similar question but the answer was different.  In these earlier discussions I walked away understanding that CoSWID was a fork of SWID and it was acceptable that minor inconsistencies.  The abstract even says " CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information."  For this reason, the IANA registry text present in -15 was even renamed from "SWID/CoSWID" to "CoSWID".

If I understand the explanation above correctly, now it seems that SWID is going to be using the CoSWID registries.  Does that imply some new co-evolution strategy?  Did something change from Fall 2021?

In rechecking the language in Section 6.* around which ranges have which registration procedures (standards action vs. specification required), I wanted to raise a two new points:

** (Based on unrelated discussions around the CWT registry that encountered a similar situation)  This document provides crisp guidance for the DE.  Should this DE guidance be applied for both "standards action" and "specification required" registry entries. I ask because per RFC8126, only "specification required" required applies DE review.  If you want DE review for all registrations s/standards action/standards action with expert review/.

** If SWID and CoSWID is going to be using these registries, does ISO understanding and it is intentional that SWID/ISO will not be able to register values in the lower/smaller "standards action" range?

Regards,
Roman

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 26 Jan 2022 00:41:20 +0100

Hi Roman,

replies to your two new points in-line below:

On 25.01.22 22:42, Roman Danyliw wrote:
>> Hi Scott,Einverstanden. Wenn man erst mal ein Team ist und sich versteht dan
>>

DE review is essential here, I think, and it would be useful to make use 
of that even in standards actions. Unless, you think that might impose 
an artificial bureaucratic disincentive for standards actions (which I 
personally do not think it does).

> ** If SWID and CoSWID is going to be using these registries, does ISO understanding and it is intentional that SWID/ISO will not be able to register values in the lower/smaller "standards action" r…

Yes, there is awareness about that outcome and it actually sets these 
registry actions a bit apart, which is not bad.

Viele Grüße,

Henk

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 26 Jan 2022 14:08:32 +0000

Hi Henk!

> From: sacm <[email-masked]> On Behalf Of Henk Birkholz
> Sent: Tuesday, January 25, 2022 6:41 PM
> To: Roman Danyliw <[email-masked]>; Scott Bradner <[email-masked]>
> Cc: Salz, Rich <[email-masked]>; [email-masked]; Robert Sparks
> <[email-masked]>
> >> 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.*:
> >>>>> "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).
> >>>>
> >>>> IETF - it
> >> is beneficial for interoperoperabitly to align them. Now - we
> >> understand that SWID is not CoSWID and that the IETF is not
> >> the IETF process as defined in the I-D. And that is a decision made in
> consensus with the ISO authors and the SACM WG.
> >>>>
> >>>> This is also
> >> why the name 'swid' was chosen as a neutral name for software
> > Has something changed?  During the AD review
> (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-
> WKPxgQAYLfBzDdE/):
> >
> > ==[ snip ]==
> > ** There are a number of places in the text where normative guidance is
> framed as "SWID/CoSWID".  Is this document suggesting any behavior of SWID,
> or is that just a short-hand because this CoSWID is just a different
> representation of the SWID information (?) /data(?) model?  What is the SWID
> behavior relative to the IANA registries?
> >
> > ** In the long term, will SWID and CoSWID diverge and how should this be
> handled? This spec seems to defined a number of helpful extension points.
> Does SWID have to use those? It might be helpful to clarify that in the text.
> Section 2.2 (i.e., "The inclusion of extension points ...") and Section 2.3 ("...
> references to the IANA registries will be added to the next revision of
> [SWID]")hints that only future version of SWID might pick up these extensions.
> The Section 5 IANA registrations call the registries "SWID/CoSWID" which
> seems confusing since SWID doesn't use them now.  Can you help me
> understand the state of play with SWID.  Without the background, it seems like
> a big leap that we're going to make registries for future work in another SDO (if
> they haven't already asked).
> > ==[ snip ]==
> >
> > I posed a similar question but the answer was different.  In these earlier
> discussions I walked away understanding that CoSWID was a fork of SWID and
> it was acceptable that minor inconsistencies.  The abstract even says " CoSWID
> supports a similar set of semantics and features as SWID tags, as well as new
> semantics that allow CoSWIDs to describe additional types of information."  For
> this reason, the IANA registry text present in -15 was even renamed from
> "SWID/CoSWID" to "CoSWID".
> >
> > If I understand the explanation above correctly, now it seems that SWID is
> going to be using the CoSWID registries.  Does that imply some new co-
> evolution strategy?  Did something change from Fall 2021?
> >
> > In rechecking the language in Section 6.* around which ranges have which
> registration procedures (standards action vs. specification required), I wanted
> to raise a two new points:
> >
> > ** (Based on unrelated discussions around the CWT registry that encountered
> a similar situation)  This document provides crisp guidance for the DE.  Should
> this DE guidance be applied for both "standards action" and "specification
> required" registry entries. I ask because per RFC8126, only "specification
> required" required applies DE review.  If you want DE review for all
> registrations s/standards action/standards action with expert review/.
> 
> DE review is essential here, I think, and it would be useful to make use of that
> even in standards actions. Unless, you think that might impose an artificial
> bureaucratic disincentive for standards actions (which I personally do not think
> it does).

(Personal view) I agree with you -- the DE and related DE criteria should be used for all registrations (whether they fall into "specification required" or "standards action").  To make that the case, the text and tables which say a particular range is restricted to "standards action" need to read "standards action with expert review".

> >
> > ** If SWID and CoSWID is going to be using these registries, does ISO
> understanding and it is intentional that SWID/ISO will not be able to register
> values in the lower/smaller "standards action" range?
> 

Understood.

To my earlier question above, did something change with how SWID would be managed?

Documenting the situation as discussed with Scott makes sense.

Thanks,
Roman

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 26 Jan 2022 15:18:21 +0100

Hi Roman,

again, please find replies way down in the tail of this message.

Viele Grüße,

Henk

> (Personal view) I agree with you -- the DE and related DE criteria should be used for all registrations (whether they fall into "specification required" or "standards action").  To make that the ca…

Will address that in a tiny PR. Thanks!

> Documenting the situation as discussed with Scott makes sense.

To my understanding this is then resolved, as Scott ack'ed the proposed 
changes and I pulled them into the current editor's version already.

Viele Grüße,

Henk