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

[Henk Birkholz <[e-mail]>]

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.*:
> 
>     [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).

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?
> 
> If this is a design choice, please answer Rich.

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.


> 
>> Can the tag-id be a digest of the source file?
> 
> 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:
> 
>     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.

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


> 
> Thanks,
> Roman
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm