Subject: [sacm] Proto consensus: Tag versions

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 19 May 2016 18:36:41 +0000

Hello all,

Between the discussions at IETF 95 and the virtual interim yesterday, there
appears to be "in room" consensus on a few proposed updates and expansions
to SWID M&A. As no IETF consensus is complete without mailing-list
consensus, I'm sending out messages on each point of proto-consensus.  

The subject of tag versions was discussed both at IETF 95 and at the virtual
interim. Briefly, tag versions are fields within SWID tags that are
incremented when there is a change to that SWID tag but no change to the
accompanying software. A SWID tag might be changed to add new optional
fields that were omitted in a previous version of that tag, or to correct an
error in a previous version of the SWID tag. To be clear: tag version has
nothing to do with the version of the software product associated with the
tag. If a software product is changed, this MUST (according to the ISO
specification) be associated with a new SWID tag, rather than a revision of
an old SWID tag. As such, SWID tag versions do not play any role in one's
understanding of what software is installed on an endpoint.

However, sometimes a policy server might like to make use of the metadata
encapsulated in a SWID tag. For example, some SWID tags contain Payload
fields with hash measurements for important files in an application.
Moreover, in some situations an enterprise's endpoints could be a policy
server's best source for gathering this metadata. While ideally vendors
would have a public repository from which authoritative SWID tags could be
collected, such repositories do not exist today. Given this, a policy server
would need to turn to its endpoints as sources for this metadata through
their SWID tags. 

Under such circumstances, a policy server would want to know whether a
particular SWID tag on a particular endpoint was of a later version than the
corresponding SWID tag in the server's tag collection. While the server
could readily detect that a SWID tag changed (and therefore had a new
version number) using Event monitoring and messages in SWID M&A, the server
would not know the versions of SWID tags for inventory items if those change
events occurred outside the range of time the server was monitoring (or if
they occurred in a preceding epoch). 

To support such circumstances, it was proposed, and the in-room consensus
was to support, the addition of a field to all SWID tag identifier records
to represent the tag version of the associated SWID tag. (Since tag version
is a field of the SWID tag itself, such a field would not need to be added
to messages where the actual tags were transported.) While the ISO SWID
specification does not specify any upper limit for a tag version, it seems
reasonable that a single byte field should be more than sufficient to
reflect the number of revisions a tag is likely to undergo without any
change in the associated software product. Thus this proposal would add one
byte to each SWID tag identifier record, or around 150 bytes to the size of
a typical inventory message, assuming a comprehensive SWID tag coverage of
installed products.

Are there any questions or concerns about the addition of a SWID Tag Version
field to SWID M&A messages as described above?

Thanks,
Charles

---

From: Adam Montville <[email-masked]>
Date: Thu, 19 May 2016 19:22:22 -0500

Thanks for following up on this, Charles.

I’m in agreement (part of the in-room, but now on-list party).

> On May 19, 2016, at 1:36 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hello all,
> 
> Between the discussions at IETF 95 and the virtual interim yesterday, there appears to be "in room" consensus on a few proposed updates and expansions to SWID M&A. As no IETF consensus is complete without mailing-list consensus, I'm sending out messages on each point of proto-consensus.
> 
> 
> The subject of tag versions was discussed both at IETF 95 and at the virtual interim. Briefly, tag versions are fields within SWID tags that are incremented when there is a change to that SWID tag but no change to the accompanying software. A SWID tag might be changed to add new optional fields that were omitted in a previous version of that tag, or to correct an error in a previous version of the SWID tag. To be clear: tag version has nothing to do with the version of the software product associated with the tag. If a software product is changed, this MUST (according to the ISO specification) be associated with a new SWID tag, rather than a revision of an old SWID tag. As such, SWID tag versions do not play any role in one's understanding of what software is installed on an endpoint.
> 
> 
> However, sometimes a policy server might like to make use of the metadata encapsulated in a SWID tag. For example, some SWID tags contain Payload fields with hash measurements for important files in an application. Moreover, in some situations an enterprise's endpoints could be a policy server's best source for gathering this metadata. While ideally vendors would have a public repository from which authoritative SWID tags could be collected, such repositories do not exist today. Given this, a policy server would need to turn to its endpoints as sources for this metadata through their SWID tags.
> 
> 
> Under such circumstances, a policy server would want to know whether a particular SWID tag on a particular endpoint was of a later version than the corresponding SWID tag in the server's tag collection. While the server could readily detect that a SWID tag changed (and therefore had a new version number) using Event monitoring and messages in SWID M&A, the server would not know the versions of SWID tags for inventory items if those change events occurred outside the range of time the server was monitoring (or if they occurred in a preceding epoch).
> 
> To support such circumstances, it was proposed, and the in-room consensus was to support, the addition of a field to all SWID tag identifier records to represent the tag version of the associated SWID tag. (Since tag version is a field of the SWID tag itself, such a field would not need to be added to messages where the actual tags were transported.) While the ISO SWID specification does not specify any upper limit for a tag version, it seems reasonable that a single byte field should be more than sufficient to reflect the number of revisions a tag is likely to undergo without any change in the associated software product. Thus this proposal would add one byte to each SWID tag identifier record, or around 150 bytes to the size of a typical inventory message, assuming a comprehensive SWID tag coverage of installed products.
> 
> 
> Are there any questions or concerns about the addition of a SWID Tag Version field to SWID M&A messages as described above?
> 
> Thanks,
> 
> Charles
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm