draft-coffin-sacm-nea-swid-patnc-01.txt   draft-coffin-sacm-nea-swid-patnc-02.txt 
SACM C. Coffin SACM C. Coffin
Internet-Draft D. Haynes Internet-Draft D. Haynes
Intended status: Standards Track C. Schmidt Intended status: Standards Track C. Schmidt
Expires: December 10, 2016 The MITRE Corporation Expires: March 16, 2017 The MITRE Corporation
J. Fitzgerald-McKay J. Fitzgerald-McKay
Department of Defense Department of Defense
June 8, 2016 September 12, 2016
SWID Message and Attributes for PA-TNC Software Message and Attributes for PA-TNC
draft-coffin-sacm-nea-swid-patnc-01 draft-coffin-sacm-nea-swid-patnc-02
Abstract Abstract
This document specifies the SWID Message and Attributes for PA-TNC. This document specifies the Software Message and Attributes for PA-
It extends the PA-TNC specification [RFC5792] by providing specific TNC. It extends the PA-TNC specification [RFC5792] by providing
attributes and message exchanges to allow endpoints to report their specific attributes and message exchanges to allow endpoints to
software inventory information to a NEA server (as described in report their software inventory information to a NEA server (as
[RFC5209]) using SWID tags [SWID]. described in [RFC5209]).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2016. This Internet-Draft will expire on March 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4 1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4
1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Role of SWID Message and Attributes for PA-TNC . . . . . 8 2.1. Supported Use Cases . . . . . . . . . . . . . . . . . . . 7
2.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 9 2.1.1. Use Software Inventory as a Factor in Determining
2.2.1. Use Software Inventory as a Factor in Determining Endpoint Access . . . . . . . . . . . . . . . . . . . 8
Endpoint Access . . . . . . . . . . . . . . . . . . . 9 2.1.2. Maintain a Central Repository Reflecting an
2.2.2. Maintain a Central Repository Reflecting an Endpoint's Software Inventory . . . . . . . . . . . . 8
Endpoint's Software Inventory . . . . . . . . . . . . 9 2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 9
2.2.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10 2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 9
2.3. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10 2.3. Specification Requirements . . . . . . . . . . . . . . . 10
2.4. Specification Requirements . . . . . . . . . . . . . . . 11 2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 11
2.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 13 2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 12
2.7. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13 2.7. Software Message and Attributes for PA-TNC Diagram
2.8. SWID Message and Attributes for PA-TNC Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . 12
Conventions . . . . . . . . . . . . . . . . . . . . . . . 14 3. Software Message and Attributes for PA-TNC System
3. SWID Message and Attributes for PA-TNC System Requirements . 14 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 15 3.1. Basic Inventory Exchange . . . . . . . . . . . . . . . . 13
3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 15 3.2. Software Identifiers . . . . . . . . . . . . . . . . . . 14
3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . . . . 16 3.2.1. Record Identifiers . . . . . . . . . . . . . . . . . 15
3.3.1. Tag Identifier Data . . . . . . . . . . . . . . . . . 17 3.2.2. Using Software and Record Identifiers in SW
3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 18 Attributes . . . . . . . . . . . . . . . . . . . . . 16
3.3.3. Comparing Tag Identifiers and Tag Identifier 3.3. Targeted Requests . . . . . . . . . . . . . . . . . . . . 16
Instances . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Monitoring Changes in an Endpoint's Software Inventory
3.3.3.1. Matching Tag Identifiers Indicate the Same Evidence Collection . . . . . . . . . . . . . . . . . . . 17
Software Product . . . . . . . . . . . . . . . . 20 3.5. Reporting Change Events . . . . . . . . . . . . . . . . . 19
3.3.3.2. Matching Tag Identifiers DO NOT Necessarily 3.5.1. Change Event Records . . . . . . . . . . . . . . . . 20
Indicate Identical Tag Files . . . . . . . . . . 20 3.5.2. Updating Inventory Knowledge Based on Events . . . . 21
3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate 3.5.3. Using Event Records in SW Attributes . . . . . . . . 22
Identical Tag Files . . . . . . . . . . . . . . . 21 3.5.4. Partial and Complete Lists of Event Records in SW
3.3.3.4. Differing Tag Identifiers DO NOT Necessarily Attributes . . . . . . . . . . . . . . . . . . . . . 22
Indicate Different Software Products . . . . . . 21 3.5.5. Synchronizing Event Identifiers and Epochs . . . . . 24
3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 22 3.6. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Targeted Requests . . . . . . . . . . . . . . . . . . . . 22 3.6.1. Establishing Subscriptions . . . . . . . . . . . . . 26
3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 23 3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 27
3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 25 3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 27
3.6.1. Change Event Records . . . . . . . . . . . . . . . . 25 3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 28
3.6.2. Updating Inventory Knowledge Based on Events . . . . 27 3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 28
3.6.3. Using Event Records in SWID Attributes . . . . . . . 28 3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 30
3.6.4. Partial and Complete Lists of Event Records in SWID 3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 30
Attributes . . . . . . . . . . . . . . . . . . . . . 28 3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 31
3.6.5. Synchronizing Event Identifiers and Epochs . . . . . 30 3.6.5.4. No Subscription Consolidation . . . . . . . . . . 32
3.7. Supporting Multiple Instances of a Single Tag . . . . . . 32 3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 32
3.7.1. Inventory Reporting in the Presence of Multiply- 3.7. Multiple Sources of Software Inventory Evidence Records . 33
Instantiated Tags . . . . . . . . . . . . . . . . . . 32 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 34
3.7.2. Event Reporting in the Presence of Multiply 4. Software Message and Attributes for PA-TNC Protocol . . . . . 36
Instantiated Tags . . . . . . . . . . . . . . . . . . 32 4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 36
3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32 4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 36
3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 33 4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 37
3.8.2. Managing Subscriptions . . . . . . . . . . . . . . . 33 4.4. SW Attribute Overview . . . . . . . . . . . . . . . . . . 38
3.8.3. Terminating Subscriptions . . . . . . . . . . . . . . 34 4.5. SW Attribute Exchanges . . . . . . . . . . . . . . . . . 40
3.8.4. Subscription Status . . . . . . . . . . . . . . . . . 35 4.6. Software Message and Attributes for PA-TNC Attribute
3.8.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 35 Enumeration . . . . . . . . . . . . . . . . . . . . . . . 42
3.8.5.1. Subscriptions Reporting Inventories . . . . . . . 37 4.7. Normalization of Text Encoding . . . . . . . . . . . . . 43
3.8.5.2. Subscriptions Reporting Events . . . . . . . . . 37 4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 44
3.8.5.3. Targeted Subscriptions . . . . . . . . . . . . . 38 4.9. SW Request . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.5.4. No Subscription Consolidation . . . . . . . . . . 39 4.10. Software Identifier Inventory . . . . . . . . . . . . . . 48
3.8.5.5. Delayed Subscription Fulfillment . . . . . . . . 39 4.11. Software Identifier Events . . . . . . . . . . . . . . . 51
3.9. Multiple Sources of SWID Tags . . . . . . . . . . . . . . 40 4.12. Software Inventory . . . . . . . . . . . . . . . . . . . 56
3.10. Error Handling . . . . . . . . . . . . . . . . . . . . . 41 4.13. Software Events . . . . . . . . . . . . . . . . . . . . . 58
4. SWID Message and Attributes for PA-TNC Protocol . . . . . . . 43 4.14. Subscription Status Request . . . . . . . . . . . . . . . 62
4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 43 4.15. Subscription Status Response . . . . . . . . . . . . . . 62
4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 44 4.16. PA-TNC Error as Used by Software Message and Attributes
4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 44 for PA-TNC . . . . . . . . . . . . . . . . . . . . . . . 64
4.4. SWID Attribute Overview . . . . . . . . . . . . . . . . . 45 4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
4.5. SWID Attribute Exchanges . . . . . . . . . . . . . . . . 47 SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 66
4.6. SWID Message and Attributes for PA-TNC Attribute 4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 68
Enumeration . . . . . . . . . . . . . . . . . . . . . . . 49 4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 69
4.7. Normalization of Text Encoding . . . . . . . . . . . . . 50 5. Supported Data Models . . . . . . . . . . . . . . . . . . . . 71
4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 51 5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . . . . . 71
4.9. SWID Request . . . . . . . . . . . . . . . . . . . . . . 52 5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID
4.10. SWID Tag Identifier Inventory . . . . . . . . . . . . . . 56 Tags using XML . . . . . . . . . . . . . . . . . . . 72
4.11. SWID Tag Identifier Events . . . . . . . . . . . . . . . 59 5.1.2. Guidance on Creation of Software Identifiers from ISO
4.12. SWID Tag Inventory . . . . . . . . . . . . . . . . . . . 64 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 72
4.13. SWID Tag Events . . . . . . . . . . . . . . . . . . . . . 66 5.2. ISO 2009 SWID Tags using XML . . . . . . . . . . . . . . 72
4.14. Subscription Status Request . . . . . . . . . . . . . . . 70 5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID
4.15. Subscription Status Response . . . . . . . . . . . . . . 70 Tags using XML . . . . . . . . . . . . . . . . . . . 72
4.16. PA-TNC Error as Used by SWID Message and Attributes for 5.2.2. Guidance on Creation of Software Identifiers from ISO
PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 72 2015 SWID Tags . . . . . . . . . . . . . . . . . . . 73
4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73
and SWID_SUBSCRIPTION_ID_REUSE_ERROR 6.1. Evidentiary Value of Software Inventory Evidence Records 73
Information . . . . . . . . . . . . . . . . . . . . 74 6.2. Sensitivity of Collected Records . . . . . . . . . . . . 74
4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 75 6.3. Integrity of Endpoint Records . . . . . . . . . . . . . . 75
4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 77 6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 75
5. Security Considerations . . . . . . . . . . . . . . . . . . . 78 6.5. Sanitization of Record Fields . . . . . . . . . . . . . . 76
5.1. Evidentiary Value of SWID Tags . . . . . . . . . . . . . 79 6.6. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 76
5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 79 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 76
5.3. Sensitivity of Collected Tags . . . . . . . . . . . . . . 80 8. Relationship to Other Specifications . . . . . . . . . . . . 77
5.4. Integrity of Endpoint Records . . . . . . . . . . . . . . 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
5.5. SWID-PC Access Permissions . . . . . . . . . . . . . . . 82 9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 77
5.6. Sanitization of Tag Fields . . . . . . . . . . . . . . . 82 9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 78
5.7. Tag Library Poisoning . . . . . . . . . . . . . . . . . . 83 9.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 79
5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83 9.4. Registry for Software Data Models . . . . . . . . . . . . 80
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
7. Relationship to Other Specifications . . . . . . . . . . . . 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 80
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 10.2. Informative References . . . . . . . . . . . . . . . . . 80
8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
8.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 85
8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 86
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.1. Normative References . . . . . . . . . . . . . . . . . . 87
9.2. Informative References . . . . . . . . . . . . . . . . . 87
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 88
A.1. A Simple SWID Tag . . . . . . . . . . . . . . . . . . . . 88
A.2. SWID Request Attributes . . . . . . . . . . . . . . . . . 90
A.2.1. Simple Request . . . . . . . . . . . . . . . . . . . 90
A.2.2. Subscription Request for Events . . . . . . . . . . . 91
A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 91
A.3. SWID Response Attributes . . . . . . . . . . . . . . . . 93
A.3.1. SWID Tag Identifier Events Attribute . . . . . . . . 93
A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
1.1. Scope and Audience 1.1. Scope and Audience
The Network Endpoint Assessment (NEA) Working Group defines an open The Network Endpoint Assessment (NEA) Working Group defines an open
solution architecture that enables network operators to collect and solution architecture that enables network operators to collect and
utilize information about endpoint configuration and state. This utilize information about endpoint configuration and state. This
information can be used to enforce policies, monitor endpoint health, information can be used to enforce policies, monitor endpoint health,
and for many other activities. Information about the software and for many other activities. Information about the software
present on an endpoint is an important consideration for such present on an endpoint is an important consideration for such
activities. Software Identification tags (SWID tags) [SWID] are activities. Such information can come from multiple sources,
formatted records (usually XML documents) that identify a specific including tag files (such as ISO SWID tags [SWID], reports from third
software product. In this case, a "software product" can be a party inventory tools, output from package managers, and other
distinct release of some piece of software, such as an operating sources. The attributes defined in this document are used to
system, web browser, etc.; a patch or plug-in for such an communicate software inventory evidence, collected from a range of
application; or a suite of such applications. The SWID specification possible sources, from the posture collector on the endpoint to the
describes the format of these documents as well as rules governing posture validator on a NEA Server using the PA-TNC interface, as
their use on computer systems. In particular, software that supports shown in Figure 1 below.
SWID tags is expected to deposit an identifying tag on the endpoint
when the software is installed, modify or replace the tag as the
software is updated, and delete the tag when the software is
uninstalled. SWID tags can also be created and managed by third-
party tools or by local enterprises, allowing for tags to indicate
the presence of software even when that software's manufacturer has
not included SWID support. As such, by collecting a list of tags on
an endpoint, one receives evidence as to the software present on that
endpoint. The attributes defined in this document are used to
communicate software inventory evidence, in the form of SWID tags,
between the posture collector and posture validator using the PA-TNC
interface, as shown in Figure 1 below.
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | <--------PA--------> | Posture | | Posture | <--------PA--------> | Posture |
| Collectors | | Validators | | Collectors | | Validators |
| (1 .. N) | | (1 .. N) | | (1 .. N) | | (1 .. N) |
+-------------+ +--------------+ +-------------+ +--------------+
| | | |
| | | |
| | | |
+-------------+ +--------------+ +-------------+ +--------------+
skipping to change at page 5, line 38 skipping to change at page 5, line 30
+-------------+ +--------------+ +-------------+ +--------------+
| Posture | | Posture | | Posture | | Posture |
| Transport | <--------PT--------> | Transport | | Transport | <--------PT--------> | Transport |
| Client | | Server | | Client | | Server |
| (1 .. N) | | (1 .. N) | | (1 .. N) | | (1 .. N) |
+-------------+ +--------------+ +-------------+ +--------------+
NEA CLIENT NEA SERVER NEA CLIENT NEA SERVER
Figure 1: NEA Reference Model Figure 1: NEA Reference Model
The use of standard protocols and formats for conveying evidence
about endpoint state (in this case, endpoint inventory information)
has a number of benefits. The use of standard protocols and formats
facilitates interoperability between products developed by different
vendors. This allows consumers to select the product that has
features that best fit with the needs of their environment, with the
expectation that it will be able to interoperate with other parts of
their infrastructure (at least with regard to the aforementioned
protocols and formats). In addition, because a standard is expected
to be implemented by multiple independent parties, this means that
the standard protocols and formats receive more review than might be
expected in a proprietary solution. When the standard is managed by
a group that is responsive to feedback from such implementers, as is
the case with the IETF, this can lead to improvements in efficiency
and security of those protocols and formats. For these reasons, a
standard means of conveying endpoint inventory information such as
the one described in this document provides significant value to
users. Vendors benefit from utilizing SWIDs to serve as evidence of
software inventory because it reduces their need to develop remote
software inventory tools for the increasing variety of endpoint
platforms. If those endpoints support SWID Message and Attributes
for PA-TNC, vendors can use these protocols to gather software
inventory information remotely.
This specification defines a new set of PA-TNC attributes, carried This specification defines a new set of PA-TNC attributes, carried
over PA-TNC messages, which are used to communicate requests for SWID over PA-TNC messages, which are used to communicate requests for
tags and events surrounding those tags, and for conveying that software information and software events, and for conveying that
information back to a NEA Server. information back to a NEA Server.
Possession of a list of an endpoint's SWID tags is very useful in Possession of a list of an endpoint's installed software is very
understanding and maintaining the security state of an enterprise. useful in understanding and maintaining the security state of an
For example, if an enterprise policy requires the presence of certain enterprise. For example, if an enterprise policy requires the
pieces of software and/or prohibits the presence of other software, presence of certain pieces of software and/or prohibits the presence
SWID tags can be used to indicate compliance or non-compliance with of other software, reported software inventory lists can be used to
these requirements. SWID tags indicating software presence and the indicate compliance or non-compliance with these requirements.
patch level of that software can be compared to vulnerability or Software presence and the patch level of that software can be
threat alerts to determine an endpoint's exposure to attack. SWID compared to vulnerability or threat alerts to determine an endpoint's
tags provide a great deal of information about unfamiliar software exposure to attack. All of these uses make an understanding of an
products, including the software author and potentially including endpoint's software collection highly useful to NEA Servers and other
where the software is installed on the endpoint and what files on the enterprise security applications.
endpoint are associated with this installed software. All of these
uses make an understanding of an endpoint's SWID tag collection
highly useful to NEA Servers and other enterprise security
applications.
Before reading this specification any further, the reader should Before reading this specification any further, the reader should
review and understand the NEA reference architecture as described in review and understand the NEA reference architecture as described in
the Network Endpoint Assessment (NEA): Overview and Requirements the Network Endpoint Assessment (NEA): Overview and Requirements
[RFC5209]. The reader should also understand the capabilities and [RFC5209]. The reader should also understand the capabilities and
requirements common to PA-TNC interfaces as defined in RFC 5792 requirements common to PA-TNC interfaces as defined in RFC 5792
[RFC5792]. [RFC5792].
This document is based on standards published by the Trusted This document is based on standards published by the Trusted
Computing Group's Trusted Network Communications (TNC) workgroup. Computing Group's Trusted Network Communications (TNC) workgroup.
The TNC and NEA architectures are interoperable and the following The TNC and NEA architectures are interoperable and the following
components are equivalent: components are equivalent:
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
| TNC Component | NEA Component | | TNC Component | NEA Component |
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
| Integrity Measurement Verifier (IMV) | Posture Validator | | Integrity Measurement Verifier (IMV) | Posture Validator |
| | |
| Integrity Measurement Collector (IMC) | Posture Collector | | Integrity Measurement Collector (IMC) | Posture Collector |
| | |
| TNC Server (TNCS) | Posture Broker Server | | TNC Server (TNCS) | Posture Broker Server |
| | |
| TNC Client (TNCC) | Posture Broker Client | | TNC Client (TNCC) | Posture Broker Client |
+---------------------------------------+-----------------------+ +---------------------------------------+-----------------------+
Table 1: Equivalent components in TNC and NEA architectures Table 1: Equivalent components in TNC and NEA architectures
1.2. Keywords 1.2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in RFC 2119 specification are to be interpreted as described in RFC 2119
[RFC2119]. This specification does not distinguish blocks of [RFC2119]. This specification does not distinguish blocks of
informative comments and normative requirements. Therefore, for the informative comments and normative requirements. Therefore, for the
sake of clarity, note that lower case instances of must, should, etc. sake of clarity, note that lower case instances of must, should, etc.
do not indicate normative requirements. do not indicate normative requirements.
1.3. Definitions 1.3. Definitions
This section defines terms with special meaning within this document. This section defines terms with special meaning within this document.
SWID-PC - A Posture Collector (PC) that conforms to this SW-PC - A Posture Collector (PC) that conforms to this specification.
specification. Note that such a posture collector might also support Note that such a posture collector might also support other PA-TNC
other PA-TNC exchanges beyond SWID Message and Attributes for PA-TNC. exchanges beyond Software Message and Attributes for PA-TNC.
SWID-PV - A Posture Validator (PV) that conforms to this SW-PV - A Posture Validator (PV) that conforms to this specification.
specification. Note that such a posture verifier might also support Note that such a posture verifier might also support other PA-TNC
other PA-TNC exchanges beyond SWID Message and Attributes for PA-TNC. exchanges beyond Software Message and Attributes for PA-TNC.
Endpoint's SWID Tag Collection - The set of SWID tags installed and SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792
managed on an endpoint for software installed on that endpoint. An [RFC5792] extension for conveying software inventory information.
endpoint's SWID tag collection might include SWID tags from multiple This specification defines several new attribute types.
Endpoint's Software Inventory Evidence Collection - The set of
information regarding the set of software installed on an endpoint
and expressed using one of the Software Message and Attributes data
models, as described in the Software Data Model IANA table (see
Section 9.4. An endpoint's software inventory evidence collection
might include information created by or derived from multiple
sources, including but not limited to SWID tag files deposited on the sources, including but not limited to SWID tag files deposited on the
file system during software installation, SWID tags generated to file system during software installation, information generated to
report output from software discovery tools, and SWID tags report output from software discovery tools, and information
dynamically generated by a software or package management system on dynamically generated by a software or package management system on
an endpoint. an endpoint.
2. Background Software Inventory Evidence Record - The endpoint's Software
2.1. Role of SWID Message and Attributes for PA-TNC Inventory Evidence Collection is composed of "records". Each record
corresponds to one installed instance of a particular software
The International Organization for Standardization and the product as reported by some data source. It is possible for a single
International Electrotechnical Commission (ISO/IEC) published the installed instance to have multiple software inventory evidence
specification governing SWID tag construction and use in 2009. records in an endpoint's Software Inventory Evidence Collection -
[SWID] Since that time, a growing number of vendors have integrated this can happen if multiple sources all report the same software
SWID tags into their software products. Doing so significantly installation instance.
simplifies the task of identifying these pieces of software: instead
of relying on discovery processes that look for clues as to software
presence, such as the presence of particular files or registry keys,
a readily available list of SWID tags provides simple and immediate
evidence as to the presence of the given piece of software.
SWID tags can also be useful even when a piece of software does not
supply the tags itself. Discovery processes are permitted to express
their findings using SWID tags, place these in the endpoint's SWID
tag collection, and maintain them like vendor-created SWID tags.
This means that an endpoint's SWID tag collection is not necessarily
limited to containing SWID tags for software whose authors have taken
the time to integrate SWID maintenance into their installation and
update processes. Similarly, software and package managers on an
endpoint (such as RPM and YUM) keep records of installed software,
and these records can be exported as a series of SWID tags, allowing
these managers to expose their information about software inventories
in a standards-based manner. Finally, for organizations that
centrally manage the distribution of software, in-house-developed
SWID tags can be added to any software product that does not natively
support SWID tags allowing the organization to accurately identify
any software it has distributed.
The NEA Server needs access to this inventory evidence if it is to Software Identifier - A string associated with a specific version of
use this information to assess endpoint compliance with policy. The a specific software product. Each supported Software Message and
SWID Message and Attributes for PA-TNC specification has been created Attributes for PA-TNC data model has its own rules for how a Software
for this purpose. Specifically, the attributes defined in this Identifier (see Section 3.2) is derived from the representation of
specification allow a Posture Validator to request evidence of an the given software product using that data model, and different
endpoint's inventory in the form of SWID tags and allow the Posture sources for this information might populate relevant information
Collector to respond with the appropriate information. differently. As such, while each Software Identifier uniquely
identifies a specific software product, the same software product
might be associated with multiple Software Identifiers reflecting
differences between different information sources and supported data
models.
It is not necessary to understand the details of SWID tag 2. Background
construction and maintenance to understand the behaviors described in
the SWID Message and Attributes for PA-TNC specification, and it is
beyond the scope of this specification to discuss the details of the
SWID standard. Implementers, however, will likely need to be
familiar with the SWID tag format and how to locate tags on an
endpoint. The SWID specification is available from ISO/IEC at
http://www.iso.org/iso/catalogue_detail.htm?csnumber=53670. The XML
schema for a SWID tag file is available from ISO:
http://standards.iso.org/iso/19770/-2/2009/schema.xsd. The most
current working and production versions of the XML schema for SWID
tags can be found in the directory listing at
http://standards.iso.org/iso/19770/-2/. The US National Institute of
Standards and Technology (NIST) also has published guidelines for
SWID tag creation, which provide further guidance for those
interested in the use and best practices surrounding SWID tags.
[NIST-SWID]
2.2. Supported Use Cases 2.1. Supported Use Cases
This section describes the SWID Message and Attributes for PA-TNC use This section describes the Software Message and Attributes for PA-TNC
cases supported by this specification. The primary use of exchanging use cases supported by this specification. The primary use of
SWID tag information over the PA-TNC interface is to enable a exchanging software inventory information over the PA-TNC interface
challenger (e.g. NEA Server) to obtain inventory evidence about some is to enable a challenger (e.g. NEA Server) to obtain inventory
system in a way that conforms to NEA procedures while taking evidence about some system in a way that conforms to NEA procedures
advantage of the simplicity and precision of SWID tags. Collected and expressed using a standard format. Collected software
SWID tags can support a range of security activities including information can support a range of security activities including
determining whether an endpoint is permitted to connect to the determining whether an endpoint is permitted to connect to the
enterprise, determining which endpoints contain software that enterprise, determining which endpoints contain software that
requires patching, and similar activities. requires patching, and similar activities.
2.2.1. Use Software Inventory as a Factor in Determining Endpoint 2.1.1. Use Software Inventory as a Factor in Determining Endpoint
Access Access
Some enterprises might define security policies that require Some enterprises might define security policies that require
connected endpoints to have certain pieces of security software connected endpoints to have certain pieces of security software
installed. By contrast, some security policies might prevent access installed. By contrast, some security policies might prevent access
by endpoints that have certain prohibited pieces of software by endpoints that have certain prohibited pieces of software
installed, such as applications that pose known security risks. To installed, such as applications that pose known security risks. To
support such policies, the NEA Server needs to collect evidence support such policies, the NEA Server needs to collect evidence
indicating the software inventory of an endpoint that is seeking to indicating the software inventory of an endpoint that is seeking to
initiate or continue connectivity to the enterprise. initiate or continue connectivity to the enterprise.
SWID Message and Attributes for PA-TNC facilitates policy decisions Software Message and Attributes for PA-TNC facilitates policy
that consider an endpoint's software inventory by providing the NEA decisions that consider an endpoint's software inventory by providing
Server with a list of the SWID tags in the endpoint's SWID tag the NEA Server with software inventory information from the endpoint.
collection. The tags in this collection serve as evidence as to the The SW-PC can provide a complete or partial inventory to the SW-PV as
endpoint's installed software. The SWID-PC can provide a complete or required to determine policy compliance. The SW-PV can then use this
partial list of tags to the SWID-PV as required to determine policy as evidence of compliance or non-compliance with enterprise policy.
compliance. The SWID-PV can then use this as evidence of compliance
or non-compliance with enterprise policy.
2.2.2. Maintain a Central Repository Reflecting an Endpoint's Software 2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software
Inventory Inventory
Many tools can use information about an endpoint's software inventory Many tools can use information about an endpoint's software inventory
to monitor and enforce the security of an enterprise. For example, a to monitor and enforce the security of an enterprise. For example, a
software patching service can use an endpoint's software inventory to software patching service can use an endpoint's software inventory to
determine whether certain endpoints have software that requires determine whether certain endpoints have software that requires
patching. A vulnerability management tool might identify endpoints patching. A vulnerability management tool might identify endpoints
with known vulnerabilities (patched or otherwise) and use this to with known vulnerabilities (patched or otherwise) and use this to
gauge enterprise exposure to attack. A license management tool might gauge enterprise exposure to attack. A license management tool might
verify that all copies of a particular piece of software are verify that all copies of a particular piece of software are
accounted for within the enterprise. The presence of a central accounted for within the enterprise. The presence of a central
repository representing a real-time understanding of each endpoint's repository representing a real-time understanding of each endpoint's
software inventory facilitates all such activities. Using a central software inventory facilitates all such activities. Using a central
repository that can ensure the freshness of its collected information repository that can ensure the freshness of its collected information
is generally more efficient than having each tool collect the same is generally more efficient than having each tool collect the same
inventory information from each endpoint individually and leads to a inventory information from each endpoint individually and leads to a
more consistent understanding of enterprise state. more consistent understanding of enterprise state.
SWID Message and Attributes for PA-TNC supports this activity through Software Message and Attributes for PA-TNC supports this activity
a number of mechanisms. As noted above, it allows a SWID-PC to through a number of mechanisms. As noted above, it allows a SW-PC to
provide a complete list of the tags present in an endpoint's SWID tag provide a complete list of software present in an endpoint's Software
collection to the SWID-PV, which can then pass this information on to Inventory Evidence Collection to the SW-PV, which can then pass this
a central repository such as a Configuration Management Database information on to a central repository such as a Configuration
(CMDB) or similar application. In addition, SWID-PCs are required to Management Database (CMDB) or similar application. In addition, SW-
be able to monitor for changes to an endpoint's SWID tag collection PCs are required to be able to monitor for changes to an endpoint's
in near real-time and push reports of changes to the SWID-PV as soon Software Inventory Evidence Collection in near real-time and push
as those changes are detected. Thus any central repository fed by a reports of changes to the SW-PV as soon as those changes are
SWID-PV receiving such information can be updated soon after the detected. Thus any central repository fed by a SW-PV receiving such
change occurs. Keeping such a central repository synchronized with information can be updated soon after the change occurs. Keeping
the state of each endpoint's SWID tag collection allows tools that such a central repository synchronized with the state of each
endpoint's Software Inventory Evidence Collection allows tools that
use this information for their own security activities to make use this information for their own security activities to make
decisions in a consistent, efficient manner. decisions in a consistent, efficient manner.
2.2.3. PA-TNC Use Cases 2.1.3. PA-TNC Use Cases
SWID Message and Attributes for PA-TNC are intended to operate over Software Message and Attributes for PA-TNC are intended to operate
the PA-TNC interface and, as such, are intended to meet the use cases over the PA-TNC interface and, as such, are intended to meet the use
set out in the PA-TNC specification. cases set out in the PA-TNC specification.
2.3. Non-supported Use Cases 2.2. Non-supported Use Cases
Some use cases not covered by this version of SWID Message and Some use cases not covered by this version of Software Message and
Attributes for PA-TNC include: Attributes for PA-TNC include:
o This specification does not address how the endpoint's SWID tag o This specification does not address how the endpoint's Software
collection is populated. In particular, NEA components are not Inventory Evidence Collection is populated. In particular, NEA
expected to perform software discovery activities beyond compiling components are not expected to perform software discovery
the tags in an endpoint's SWID tag collection. This collection activities beyond compiling information in an endpoint's Software
might potentially come from multiple sources on the endpoint Inventory Evidence Collection. This collection might potentially
(e.g., SWID tags generated dynamically by package management tools come from multiple sources on the endpoint (e.g., information
or discovery tools, as well as SWID tag files discovered on the generated dynamically by package management tools or discovery
file system). While an enterprise might make use of software tools, as well as SWID tag files discovered on the file system).
discovery procedures to identify installed software, especially While an enterprise might make use of software discovery
software that does not install or manage its own SWID tag, such procedures to identify installed software such procedures are
procedures are outside the scope of this specification. outside the scope of this specification.
o This specification does not address converting inventory o This specification does not address converting inventory
information expressed in a proprietary format into the SWID tag information expressed in a proprietary format into the standard
format or converting a SWID tag into a proprietary format. format used in the messages described in this specification.
Instead, it focuses exclusively on defining interfaces for the Instead, it focuses exclusively on defining interfaces for the
transportation of SWID tags in the expectation that this is the transportation of software information in the expectation that
format around which reporting tools will converge. this is the format around which reporting tools will converge.
o This specification provides no mechanisms for a posture validator o This specification provides no mechanisms for a posture validator
to request a specific list of tags based on arbitrary tag to request a specific list of software information based on
properties from the endpoint. For example, requesting only tags arbitrary software properties. For example, requesting only
representing software from a particular vendor is not supported. information about software from a particular vendor is not
After the endpoint's SWID tag collection has been copied to some supported. After the endpoint's software inventory evidence
central location, such as the CMDB, processes there can perform collection has been copied to some central location, such as the
queries based on any criteria present in the collected SWID tags, CMDB, processes there can perform queries based on any criteria
but this specification does not address using such queries to present in the collected information, but this specification does
constrain the initial collection of this information from the not address using such queries to constrain the initial collection
endpoint. of this information from the endpoint.
o This specification does not address utilization of certain SWID o This specification does not address utilization of properties of
tag fields designed to facilitate local tests (i.e., on the certain sources of software information that might facilitate
endpoint) of endpoint state. For example, the optional local tests (i.e., on the endpoint) of endpoint state. For
package_footprint field of a SWID tag can contain a list of files example, the optional package_footprint field of an ISO SWID tag
and hash values associated with the software indicated by the tag. can contain a list of files and hash values associated with the
Tools on the endpoint can use the values in this field to test for software indicated by the tag. Tools on the endpoint can use the
the presence of the indicated files. Successful evaluation of values in this field to test for the presence of the indicated
such tests leads to greater assurance that the indicated software files. Successful evaluation of such tests leads to greater
is present on the endpoint. Currently, most SWID tag creators do assurance that the indicated software is present on the endpoint.
not provide values for tag fields that support local testing. For Currently, most SWID tag creators do not provide values for tag
this reason, the added complexity of supporting endpoint testing fields that support local testing. For this reason, the added
using these fields is out of scope for this specification. Future complexity of supporting endpoint testing using these fields is
versions of this specification might add support for such testing. out of scope for this specification. Future versions of this
specification might add support for such testing.
2.4. Specification Requirements 2.3. Specification Requirements
Below are the requirements that the SWID Message and Attributes for Below are the requirements that the Software Message and Attributes
PA-TNC specification is required to meet in order to successfully for PA-TNC specification is required to meet in order to successfully
play its role in the NEA architecture. play its role in the NEA architecture.
o Efficient o Efficient
The NEA architecture enables delay of network access until the The NEA architecture enables delay of network access until the
endpoint is determined not to pose a security threat to the network endpoint is determined not to pose a security threat to the network
based on its asserted integrity information. To minimize user based on its asserted integrity information. To minimize user
frustration, the SWID Message and Attributes for PA-TNC ought to frustration, the Software Message and Attributes for PA-TNC ought to
minimize overhead delays and make PA-TNC communications as rapid and minimize overhead delays and make PA-TNC communications as rapid and
efficient as possible. efficient as possible.
Efficiency is also important when one considers that some network Efficiency is also important when one considers that some network
endpoints are small and low powered, some networks are low bandwidth endpoints are small and low powered, some networks are low bandwidth
and/or high latency, and some transport protocols (such as PT-EAP, and/or high latency, and some transport protocols (such as PT-EAP,
Posture Transport (PT) Protocol for Extensible Authentication Posture Transport (PT) Protocol for Extensible Authentication
Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
protocol might allow only one packet in flight at a time or only one protocol might allow only one packet in flight at a time or only one
roundtrip. However, when the underlying PT protocol imposes fewer roundtrip. However, when the underlying PT protocol imposes fewer
constraints on communications, this protocol ought to be capable of constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using taking advantage of more robust communication channels (e.g. using
larger messages or multiple roundtrips). larger messages or multiple roundtrips).
o Loosely Coupled to the SWID Specification
Because the SWID specification is managed by ISO/IEC, the IETF has no
direct influence over this specification or any revisions made to it.
For this reason, the SWID Message and Attributes for PA-TNC
specification ought to minimize its requirements and assumptions with
regard to the structure and content of the SWID tags. While some
level of visibility into tag contents is required for certain
features of this specification, minimization of such dependencies is
necessary to improve compatibility with future revisions of the SWID
specification.
o Scalable o Scalable
SWID Message and Attributes for PA-TNC needs to be usable in Software Message and Attributes for PA-TNC needs to be usable in
enterprises that contain tens of thousands of endpoints or more. As enterprises that contain tens of thousands of endpoints or more. As
such, it needs to allow a security tools to make decisions based on such, it needs to allow a security tools to make decisions based on
up-to-date information about an endpoint's software inventory without up-to-date information about an endpoint's software inventory without
creating an excessive burden on the enterprise's network. creating an excessive burden on the enterprise's network.
o Interoperable o Interoperable
This specification defines the protocol for how PCs and PVs can This specification defines the protocol for how PCs and PVs can
exchange and use SWID tags to provide a NEA Server with information exchange and use software information to provide a NEA Server with
about an endpoint's software inventory. Therefore a key goal for information about an endpoint's software inventory. Therefore a key
this specification is ensuring that all SWID PCs and PVs, regardless goal for this specification is ensuring that all SW PCs and PVs,
of the vendor who created them, are able to interoperate in their regardless of the vendor who created them, are able to interoperate
performance of these duties. in their performance of these duties.
o Support precise and complete historical reporting o Support precise and complete historical reporting
This specification is expected to outline capabilities that support This specification outlines capabilities that support real-time
real-time understanding of the state of endpoint in a network in a understanding of the state of endpoint in a network in a way that can
way that can be used by other tools. One means of facilitating such be used by other tools. One means of facilitating such an outcome is
an outcome is for a Configuration Management Database (CMDB) to be for a Configuration Management Database (CMDB) to be able to contain
able to contain information about all endpoints connected to the information about all endpoints connected to the enterprise for all
enterprise for all points in time between the endpoint's first points in time between the endpoint's first connection and the
connection and the present. In such a scenario, it is necessary that present. In such a scenario, it is necessary that any PC be able to
any PC be able to report any changes to its SWID tag collection in report any changes to its software inventory evidence collection in
near real-time while connected and, upon reconnection to the near real-time while connected and, upon reconnection to the
enterprise, be able to update the NEA Server (and through it the enterprise, be able to update the NEA Server (and through it the
CMDB) with regard to the state of its SWID tag collection throughout CMDB) with regard to the state of its software inventory evidence
the entire interval when it was not connected. collection throughout the entire interval when it was not connected.
2.5. Non-Requirements 2.4. Non-Requirements
There are certain requirements that the SWID Message and Attributes There are certain requirements that the Software Message and
for PA-TNC specification explicitly is not required to meet. This Attributes for PA-TNC specification explicitly is not required to
list is not exhaustive. meet. This list is not exhaustive.
o End to End Confidentiality o End to End Confidentiality
SWID tags have no inherent mechanism for confidentiality, nor is this This specification does not define mechanism for confidentiality, nor
property automatically provided by PA-TNC interface use. is this property automatically provided by PA-TNC interface use.
Confidentiality is generally provided by the underlying transport Confidentiality is generally provided by the underlying transport
protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture protocols, such as the PT Binding to TLS [RFC6876] or PT-EAP Posture
Transport for Tunneled EAP Methods [RFC7171] - see Section 7 for more Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more
information on related standards. Should users wish confidentiality information on related standards. Should users wish confidentiality
protection of assessment instructions or results, this needs to be protection of assessment instructions or results, this needs to be
provided by parts of the NEA architecture other than this provided by parts of the NEA architecture other than this
specification. specification.
2.6. Assumptions 2.5. Assumptions
Here are the assumptions that SWID Message and Attributes for PA-TNC Here are the assumptions that Software Message and Attributes for PA-
makes about other components in the NEA architecture. TNC makes about other components in the NEA architecture.
o Reliable Message Delivery o Reliable Message Delivery
The Posture Broker Client and Posture Broker Server are assumed to The Posture Broker Client and Posture Broker Server are assumed to
provide reliable delivery for PA-TNC messages and therefore the SWID provide reliable delivery for PA-TNC messages and therefore the
Attributes sent between the SWID PCs and the PVs. In the event that Attributes sent between the SW PCs and the PVs. In the event that
reliable delivery cannot be provided, the Posture Collector or reliable delivery cannot be provided, the Posture Collector or
Posture Validator is expected to terminate the connection. Posture Validator is expected to terminate the connection.
2.7. Non-Assumptions 2.6. Non-Assumptions
The SWID Message and Attributes for PA-TNC specification explicitly The Software Message and Attributes for PA-TNC specification
does not assume: explicitly does not assume:
o Authenticity and Accuracy of SWID tags with Regard to Endpoint o Authenticity and Accuracy of the Software Inventory Evidence
Inventory Collection with Regard to Endpoint Inventory
This specification makes no assumption as to whether the SWID tags This specification makes no assumption as to whether the software
that it reports are authentic tags (rather than maliciously information that it reports correctly reflect the software state on
generated) or that these tags correctly reflect software state on the the endpoint. This specification does not attempt to detect when the
endpoint. This specification does not attempt to detect when the
endpoint is providing false information, either through malice or endpoint is providing false information, either through malice or
error, but instead focuses on correctly and reliably providing the error, but instead focuses on correctly and reliably providing the
existing SWID tags to the NEA Server. Similarly, this specification reported Software Inventory Evidence Collection to the NEA Server.
makes no assumption with regard to the completeness of the SWID tag Similarly, this specification makes no assumption with regard to the
collection's coverage of the total set of software installed on the completeness of the Software Inventory Evidence Collection's coverage
endpoint. It is possible, and even likely, that some installed of the total set of software installed on the endpoint. It is
software is not represented by a tag in an endpoints SWID tag possible, and even likely, that some installed software is not
collection. See Section 5 for more on this security consideration. represented by a record in an endpoints Software Inventory Evidence
Collection. See Section 6 for more on this security consideration.
2.8. SWID Message and Attributes for PA-TNC Diagram Conventions 2.7. Software Message and Attributes for PA-TNC Diagram Conventions
This specification defines the syntax of the SWID Message and This specification defines the syntax of the Software Message and
Attributes for PA-TNC using diagrams. Each diagram depicts the Attributes for PA-TNC using diagrams. Each diagram depicts the
format and size of each field in bits. Implementations MUST send the format and size of each field in bits. Implementations MUST send the
bits in each diagram as they are shown from left to right for each bits in each diagram as they are shown from left to right for each
32-bit quantity traversing the diagram from top to bottom. Multi- 32-bit quantity traversing the diagram from top to bottom. Multi-
octet fields representing numeric values MUST be sent in network (big octet fields representing numeric values MUST be sent in network (big
endian) byte order. endian) byte order.
Descriptions of bit fields (e.g. flags) values refer to the position Descriptions of bit fields (e.g. flags) values refer to the position
of the bit within the field. These bit positions are numbered from of the bit within the field. These bit positions are numbered from
the most significant bit through the least significant bit. As such, the most significant bit through the least significant bit. As such,
an octet with only bit 0 set would have a value of 0x80 (1000 0000), an octet with only bit 0 set would have a value of 0x80 (1000 0000),
an octet with only bit 1 set would have a value of 0x40 (0100 0000), an octet with only bit 1 set would have a value of 0x40 (0100 0000),
and an octet with only bit 7 set would have a value of 0x01 (0000 and an octet with only bit 7 set would have a value of 0x01 (0000
0001). 0001).
3. SWID Message and Attributes for PA-TNC System Requirements 3. Software Message and Attributes for PA-TNC System Requirements
The SWID Message and Attributes for PA-TNC specification facilitates
the exchange of SWID tag inventories and event information.
Specifically, each application supporting SWID Message and Attributes
for PA-TNC includes a component known as the SWID-PC that receives
messages sent with the SWID Attributes component type. The SWID-PC
is also responsible for sending appropriate SWID Attributes back to
the SWID-PV in response. Similarly, the SWID-PV exists on a NEA
Server and is responsible for interpreting responses, forwarding
information to a CMDB if desired, and making policy decisions based
upon the received information. This section outlines what a SWID tag
inventory is, important features of tags used by this specification,
and the requirements on SWID-PCs and SWID-PVs in order to support the
stated use cases of this specification.
3.1. SWID Tags as Inventory Evidence
As noted in Section 2.1, SWID tags are intended to be open, easily
accessible evidence indicating the presence of a particular piece of
software on an endpoint. A SWID tag contains multiple fields
intended to uniquely identify a single software product. Ideally, a
SWID tag is managed by the software that installs, modifies,
replaces, amends (e.g. patches, updates), and/or uninstalls the
product. Discovery processes, software package managers, and other
tools can also create and manage tags as a way to represent software
that they discover or manage on the endpoint.
It is important to note that, even in the ideal cases where a product The Software Message and Attributes for PA-TNC specification
manages its own SWID tag, a tag is inherently distinct from the facilitates the exchange of software inventory and event information.
product that it identifies. For this reason, a SWID tag needs to be Specifically, each application supporting Software Message and
treated as evidence of software presence, but cannot be treated as Attributes for PA-TNC includes a component known as the SW-PC that
proof of software presence. That noted, a standardized receives messages sent with the SW Attributes component type. The
representation of evidence indicative of an endpoint's software SW-PC is also responsible for sending appropriate SW Attributes back
inventory is a powerful tool in managing software within an to the SW-PV in response. This section outlines what software
enterprise. inventories and events are and the requirements on SW-PCs and SW-PVs
in order to support the stated use cases of this specification.
3.2. Basic SWID Tag Inventory Exchange 3.1. Basic Inventory Exchange
In the most basic exchange supported by this specification, a SWID-PV In the most basic exchange supported by this specification, a SW-PV
sends a request to the SWID-PC requesting a copy of all the SWID tags sends a request to the SW-PC requesting all inventory information in
in the endpoint's SWID tag collection. This simple exchange is shown the endpoint's Software Inventory Evidence Collection. This simple
in Figure 2. exchange is shown in Figure 2.
+-------------+ +--------------+ +-------------+ +--------------+
| SWID-PC | | SWID-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<-------------SWID Request---------------| | |<--------------SW Request----------------| |
| | | | | |
|--------------SWID Response------------->| | |---------------SW Response-------------->| |
| | V | | V
Figure 2: Basic SWID Message Exchange Figure 2: Basic SW Message Exchange
Upon receiving such a SWID Request from the SWID-PV, the SWID-PC is Upon receiving such a SW Request from the SW-PV, the SW-PC is
expected to locate the endpoint's SWID tags and then create copies of expected to collect all inventory information from the endpoint's
all identified SWID tags and place them within its response software evidence collection and place it within its response
attribute. attribute.
SWID-PVs MUST discard without error any SWID Response attributes that SW-PVs MUST discard without error any SW Response attributes that
they receive for which they do not know the SWID Request parameters they receive for which they do not know the SW Request parameters
that led to this SWID Response. This is due to the fact that the that led to this SW Response. This is due to the fact that the SW
SWID Request includes parameters that control the nature of the Request includes parameters that control the nature of the response
response (as will be described in the following sections) and without (as will be described in the following sections) and without knowing
knowing those parameters the SWID Response cannot be reliably those parameters the SW Response cannot be reliably interpreted.
interpreted. Most often receiving an unsolicited SWID Response Most often receiving an unsolicited SW Response attribute happens
attribute happens when a NEA Server has multiple SWID-PVs; one SWID- when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request
PV sends a SWID Request but, unless exclusive delivery is used by the but, unless exclusive delivery is used by the SW-PC in sending the
SWID-PC in sending the response, both SWID-PVs receive copies of the response, both SW-PVs receive copies of the resulting SW Response.
resulting SWID Response. In this case, the SWID-PV that didn't send In this case, the SW-PV that didn't send the SW Request would lack
the SWID Request would lack the context necessary to correctly the context necessary to correctly interpret the SW Response it
interpret the SWID Response it received and would simply discard it. received and would simply discard it. Note, however, that
Note, however, that proprietary measures might allow a SWID-PV to proprietary measures might allow a SW-PV to discover the SW Request
discover the SWID Request parameters for a SWID Response even if that parameters for a SW Response even if that SW-PV did not send the
SWID-PV did not send the given SWID Request. As such, there is no given SW Request. As such, there is no blanket requirement for a SW-
blanket requirement for a SWID-PV to discard all SWID Responses to PV to discard all SW Responses to SW Request the SW-PV did not
SWID Request the SWID-PV did not generate itself, only that SWID-PVs generate itself, only that SW-PVs are required to discard SW
are required to discard SWID Responses for which they cannot get the Responses for which they cannot get the necessary context to
necessary context to interpret. interpret.
In the case that it is possible to do so, the SWID-PC MAY send its
SWID Response attribute to the SWID-PV that requested it using
exclusive delivery as described in section 4.5 of RFC 5793 (PB-TNC)
[RFC5793]. Exclusive delivery ensures that only the sender of the
SWID Request receives the resulting SWID Response. However, SWID
Message and Attributes for PA-TNC does not require support for
exclusive delivery of attributes.
3.3. SWID Tag Identifiers
SWID tags can contain a great deal of information about a software
product. In addition to identifying name, manufacturer, and version
of a software product, SWID tags might contain references to related
products, associated files and libraries, dependencies on other
software, and many other details. Moreover, SWID tags might be
customized on the endpoint to indicate when the SWID tag was last
checked for accuracy relative to the endpoint's installed software
and other information about how the software was received. (This
document refers to this customized information as
"installationspecific" tag information.) For this reason, actual
possession of a SWID tag can be useful for reasoning about details of
an endpoint's software inventory. However, a SWID tag file that
contains all optional fields might be tens of KB in size. This means
that an endpoint's full SWID inventory, encompassing hundreds of
applications, can be quite large.
If bandwidth is a concern within an enterprise, there is a way to
identify a SWID tag without needing the complete tag. All tags
contain specific fields that can be used to distinguish a tag for a
particular piece of software from tags for different pieces of
software. The Tag Creator RegID is a string that uniquely identifies
the creator of this SWID tag (who might or might not be the same as
the entity who created the described software) while the Unique ID is
a string that uniquely identifies the described piece of software
according to that tag creator. These two pieces of information
together create a "tag identifier".
3.3.1. Tag Identifier Data
Some attributes defined in this specification contain fields to hold
tag identifiers rather than whole tags. When populating these
fields, both the Tag Creator RegID and the Unique ID values MUST be
copies of the values of fields within the SWID tag that is being
identified. The specific fields of a SWID tag that correspond to the
Tag Creator RegID and Unique ID values vary between the different
releases of the ISO SWID tag specification. It is important to note
that, in all other parts of this specification, the terms Tag Creator
RegID and Unique ID refer to the general field values defined above
rather to any term used in any specific release of the ISO SWID tag
specification.
To identify the SWID tag field corresponding to the Tag Creator
RegID, identify the field containing the regid value of the entity
that created the given SWID tag. Note that this might not be the
same entity that created the software. The Tag Creator RegID MUST be
the regid, rather than any prose name that might be associated with
the tag creator. The specific structure of a regid is defined in the
ISO/IEC SWID specification.
To identify the SWID tag field corresponding to the Unique ID, find
the field that contains a string that uniquely identifies a specific
product, version, edition, revision, etc. of a piece of software.
Note that this is a single field within the SWID tag, rather than a
concatenation of multiple fields. In particular, SWID tags often
contain designated fields for just the product name, product version,
product edition, etc., but these fields are not used to populate the
Unique ID. Instead, look for a single field that is designed to
uniquely identify a specific software product, version, etc. (and
thus uniquely identifies a specific tag, at least according to the
tag's creator).
Consult the ISO/IEC specification for the specific fields that
correspond to the requirements of the Tag Creator RegID and Unique
ID, as defined above. For example, in the 2009 version of the ISO/
IEC SWID specification [SWID], the Tag Creator RegID corresponds to
the value of the software_identification_tag/software_id/
tag_creator_regid field in a SWID tag. The Unique ID corresponds to
the value of the software_identification_tag/software_id/unique_id
field in a SWID tag. In subsequent releases of the ISO/IEC SWID
specification, different fields might be used to convey the same
information.
3.3.2. Tag Identifier Instances
A tag identifier (i.e., the combination of the Tag Creator RegID and
the Unique ID fields) uniquely identifies a particular SWID tag,
which corresponds to a single software product. Assuming that this
product manages its own SWID tag (i.e., creates the tag on
installation and deletes the tag when the product is uninstalled)
then every system with an instance of this software product installed
would also have a copy of this same SWID tag file with the same tag
identifier field values. (Presence of SWID tags managed by other
tools, such as discovery tools, would also depend on the presence of
those tools on the device.) In fact, if multiple instances of the
same software product are installed on a single device (i.e., it has
been installed twice in different locations) that device would have
two instances of the same SWID tag, one for each installation. Both
instances of the SWID tag would have the same tag identifier field
values. This is true even though the tags themselves might differ
with regard to their installation-specific tag fields. In many cases
it is important to distinguish between instances of a particular tag
on a particular endpoint. For example, if one is alerted to the
deletion of a particular SWID tag and there are multiple instances of
that SWID tag on the endpoint, one will likely wish to know which
instance was deleted.
Individual instances of SWID tags are distinguished by providing an
"Instance ID" value along with the tag identifier. An Instance ID is
a string that is uniquely associated with a particular instance of a
SWID tag on a particular endpoint. The exact nature of the Instance
ID depends on the source of the SWID tag. If the SWID tag is
represented as a file on disk, the Instance ID might be the full path
of the SWID tag file, including the name of the SWID tag file itself.
(Note that the SWID tag filename MUST be included in the tag file
path because it is possible for two SWID tags, each for different
instances of the same software product, to co-exist in the same
directory under different file names.) In the case that the SWID tag
is dynamically generated upon request by some source, such as an RPM
or YUM package manager, the generation process MUST create an
Instance ID to distinguish instances of a particular tag. Inclusion
of this Instance ID ensures each tag is uniquely identified on a
given endpoint.
To the extent that it is possible, the generation of Instance IDs
SHOULD be repeatable for a single installation of a single SWID tag.
In the case where a product is installed once, and then SWID tags are
generated upon request, each time the SWID tag is generated the tag
identifier instance SHOULD all have the same Instance ID value. For
example, if a package manager generates a SWID tag in response to a
request based on some record it possesses, and then later generates
the SWID tag again based on the same record of package installation,
then the same Instance ID value SHOULD be created both times. This
is necessary to allow remote parties to understand whether a reported
SWID tag instance is for the same product installation they saw
reported earlier or if it represents a new installation of the same
product. Note, however, that some exceptional situations might
result in the changing of a product's Instance ID. For example, it
is not explicitly prohibited by the SWID specification for tags to
move after installation, and thus have their tag file path change.
If the file path was used as the tag's Instance ID, subsequent tag
identifier instances for that same product might appear to be
different. Implementers and users need to be aware of this
possibility.
The combination of a tag identifier with an Instance ID is referred
to as a "tag identifier instance". A tag identifier instance
uniquely identifies a particular instance of a particular tag on a
given endpoint. Note that two endpoints might produce identical tag
identifier instances, but these do not mean that the tag files on the
two endpoints are identical - the tags in question indicate the same
software product on both endpoints (since the respective tag
identifiers are identical), but the tags might still differ in their
installation-specific fields. Therefore, it is important to remember
that tag identifier instances are only comparable in the scope of a
single endpoint; when comparing across different endpoints, only the
tag identifier fields (Tag Create RegID and Unique ID) can be
meaningfully compared - any Instance ID value will need to be
excluded from comparison.
3.3.3. Comparing Tag Identifiers and Tag Identifier Instances
Comparison of tag identifiers can be used to determine whether a In the case that it is possible to do so, the SW-PC SHOULD send its
particular SWID tag is present in an endpoint's SWID tag collection. SW Response attribute to the SW-PV that requested it using exclusive
A pair of SWID tag identifiers is said to "match" if their Tag delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793].
Creator RegID and Unique ID fields are identical. Similarly, a pair Exclusive delivery ensures that only the sender of the SW Request
of tag identifier instances is said to match if their Tag Creator receives the resulting SW Response.
RegID, Unique ID, and Instance ID fields are identical. Fields in
SWID Message and Attributes for PA-TNC attributes that contain tag
identifiers or tag identifier instances MUST always be normalized to
Network Unicode, so comparison between values transported in
attributes can be a simple string comparison. When comparing tag
identifiers and tag identifier instances from attributes with the
corresponding values from other sources (such as when comparing them
to a full SWID tag file or similar record), the relevant fields from
the latter need to undergo normalization prior to comparison. See
Section 4.7 for more on normalization of the encoding for these
fields. Comparisons are case-sensitive.
Matching tag identifiers and tag identifier instances indicate very 3.2. Software Identifiers
specific things about the respective tags. The following sections
describe what one can and cannot deduce based on matching tag
identifiers.
3.3.3.1. Matching Tag Identifiers Indicate the Same Software Product Software information records contain a large amount of descriptive
information about installed software products. However, in many
cases the complete level of detail in these records is not necessary.
For example, if one is simply tracking the installation or removal of
known software products, one only needs enough information to
recognize the software added or removed. To allow such uses to be
efficiently supported, Software Message and Attributes for PA-TNC
supports the use of Software Identifiers.
The Unique ID value of a tag identifier represents a value that the A Software Identifier uniquely identifies a specific version of a
given tag creator will only use to indicate a particular software specific software product. The Software Message and Attributes for
product (e.g., a particular release of a particular application). PA-TNC specification does not dictate the structure of a Software
The ISO SWID specification prohibits the tag creator from associating Identifier (beyond stating that it is a string) or define how it is
a Unique ID value with multiple, different software products. At the created. Instead, each data model described in the Software Data
same time, the Tag Creator RegID element value uniquely identifies a Model IANA table (Section 9.4 includes its own rules for how a
given tag creator. As such, even if two different tag creators were Software Identifier is created based on a record in the Endpoint's
to assign the same Unique ID value to two different software Software Inventory Evidence Collection expressed in that data model.
products, the Tag Creator RegID values will be different, and Within the Software Message and Attributes for PA-TNC specification,
therefore the tag identifiers will be different. For these reasons, the Software Identifier is simply an opaque string.
the expectation is that if one sees two tags with the same tag
identifiers, these tags are both associated with the same software
product (assuming the tag's fields are correctly populated).
3.3.3.2. Matching Tag Identifiers DO NOT Necessarily Indicate Identical Software Identifiers allow SW Response messages to identify software
Tag Files to a server at a fraction of the bandwidth that would be needed to
send the entire associated record. For some combinations of data
models and sources, the full record might never be necessary as the
identifier can be directly correlated to the contents of the full
record. This is possible with authoritative SWID tags, since these
tags always have the same contents and thus a Software Identifier
derived from these tags can be used as a lookup to a local copy of
the full tag. For other combinations of source and data model, a
server might not be able to determine the specific software product
and version associated with the identifier without requesting deliver
of the full record. In either case, however, a SW-PV can use
Software Identifiers to track the presence of specific software
products on an endpoint over time in a bandwidth-efficient manner.
Some optional fields in SWID tags can reflect installation-specific There are two important limitations of Software Identifiers to keep
information. As such, the SWID tags for a piece of software residing in mind:
on two different endpoints (or installed twice on a single endpoint)
will have the same tag identifier value (same tag creator with the
same Unique ID for the same software product) but might contain
different information in their installation-specific fields. For
this reason, one cannot assume that just because two endpoints
provide the same tag identifier value for their software inventories,
that the tags on those endpoints are identical in all their fields
(although one can deduce that the same software product was present
on both endpoints).
Informative note: Initial drafts of the revised ISO SWID The identifiers do not necessarily change when the associated
specification indicate that modification of SWID tags might no longer record changes. In some situations, a record in the endpoint's
be permitted by parties other than the original tag creator (usually Software Inventory Evidence Collection will change due to new
the vendor of the software identified by the tag). If this becomes information becoming available or in order to correct prior errors
part of the revised SWID specification, then for SWID tags that in that information. Such changes might or might not result in
conform to this revised specification, this will mean that matching changes to the Software Identifier, depending on the nature of the
tag identifiers do imply identical tag files. changes and the rules governing how Software Identifiers are
derived from records of the appropriate data model.
3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate Identical Tag It is possible that a single software product is installed on a
Files single endpoint multiple times. If both of these installation
instances are reported by the same source using the same data
format, then this will result in identical Software Identifiers
for each installation instances. In other words, Software
Identifiers do not uniquely identify installation instances; they
just uniquely identify software products (which might have more
than one installation instance). Instead, to distinguish between
multiple instances of a single software product, one needs to make
use of Record Identifiers, described in the following section.
For a single endpoint, matching tag identifier instance values might 3.2.1. Record Identifiers
indicate identical tag files, at least within a narrow time window.
Tag identifier instance values are unique to a specific SWID tag
record on that particular endpoint at a particular point in time.
The Instance ID in the tag identifier instance information ought to
be unique relative to any other instances of the same SWID tag
currently also on that endpoint. However, tag identifier instances
are still not guaranteed to be unique to a single SWID tag file over
a long period of time. Consider a piece of software that is
installed (adding a SWID tag), uninstalled (removing the SWID tag),
and then reinstalled (adding that SWID tag back but with a different
installation-specific field values). It is possible that the two
SWID tag files, present at different points in time, might have
identical tag identifier instance values even though the tag files
themselves were different.
As noted above, SWID tag identifier instances are only comparable A Record Identifier is a string generated by the SW-PC that is
within the context of a single endpoint. When SWID tag identifier uniquely associated with a specific record within the Endpoint's
instances are collected from multiple endpoints and then compared, Software Inventory Evidence Collection. The SW-PC MUST assign a
the Instance ID MUST be ignored in any comparison of tag identifiers unique identifier to each record when it is added to the Endpoint's
from different endpoints. Software Inventory Evidence Collection. The Record Identifier SHOULD
remain unchanged if that record is modified. The SWID-PC might wish
to assign Record Identifiers sequentially, but any scheme is
acceptable provided that no two records receive the same identifier.
3.3.3.4. Differing Tag Identifiers DO NOT Necessarily Indicate Servers can use Record Identifiers to distinguish between multiple
Different Software Products instances of a single software product installed on an endpoint.
Since each installation instance of a software product is associated
with a separate record, servers can use the record identifier to
distinguish between instances. For example, if an event is reported
(as described in Section 3.5), the record identifier will allow the
server to discern which instance of a software product is involved.
While a tag identifier uniquely identifies a software product (i.e., 3.2.2. Using Software and Record Identifiers in SW Attributes
that tag identifier cannot be associated with a different software
product), a single product might have more than one tag identifier.
This is because it is possible for more than one tag creator to
create a SWID tag for the same software product. Multiple tags for
the same software product but created by different tag creators will
have different Tag Creator RegID values and will also likely differ
in their Unique ID value. Thus, these two tags will have different
tag identifiers even though they were associated with the same
software product. In fact, in some circumstances, two parties might
create two different SWID tag records for a single instance of the
same software product. For example, when a product is installed, it
creates a SWID tag file on the file system, and a software discovery
tool also notes the installation of the product and generates its own
SWID tag record for the same installation. In this case, that single
installation is associated with two SWID tags with different SWID tag
identifiers. In short, identical tag identifiers always indicate the
same software product, but different tag identifiers do not
necessarily indicate different software products.
3.3.4. Using Tag Identifiers in SWID Attributes A SW Attribute reporting an endpoint's Software Inventory Evidence
Collection can contain Software Identifiers instead of copies of
software inventory evidence records. The message exchange is
identical to the diagram shown in Figure 2, but the contents of the
SW Response are Software Identifiers instead of evidence records.
The SW Request attribute indicates whether the response is required
to use full records or Software Identifiers. Using Software
Identifiers can reduce the attribute size of the response by multiple
orders of magnitude when compared to sending the same inventory using
full records. A SW-PC responds to a SW Request attribute requesting
Software Identifiers the same way it responds to a request for full
software records, except that instead of copying each record entirely
into the attribute body of the response, it provides the specific
values that comprise a Software Identifier for each record.
A SWID attribute reporting an endpoint's SWID tag collection can All SW Response attributes include Record Identifiers for each
contain SWID tag identifier instances instead of copies of SWID tag reported record. This is true regardless of whether the record is
files. The message exchange is identical to the diagram shown in delivered in full or represented by a Software Identifier.
Figure 2, but the contents of the SWID Response are SWID tag
identifier instances instead of tags. The SWID Request attribute
indicates whether the response is required to use full tags or tag
identifier instances. Using tag identifier instances can reduce the
attribute size of the response by multiple orders of magnitude when
compared to sending the same inventory using full tags. A SWID-PC
responds to a SWID Request attribute requesting SWID tag identifier
instances the same way it responds to a request for full SWID tags,
except that instead of copying each SWID tag entirely into the
attribute body of the response, it provides the specific values that
comprise a SWID tag identifier instance for each tag.
3.4. Targeted Requests 3.3. Targeted Requests
Sometimes a SWID-PV does not require information about every tag on Sometimes a SW-PV does not require information about every piece of
an endpoint but only needs to know about certain tags. For example, software on an endpoint but only needs to receive updates about
an endpoint might be required to have a particular patch installed. certain software instances. For example, enterprise endpoints might
In determining compliance with this policy, the SWID-PV is only be required to have certain software products installed and to keep
interested in the specific SWID tag associated with this patch. these updated. Instead of requesting a complete inventory just to
Instead of requesting a complete inventory just to see if the patch's see if these products are present, the SW-PV can make a "targeted
SWID tag is present, the SWID-PV can make a "targeted request" for request" for the software in question.
the tag in question.
Targeted requests follow the same message exchange described in Targeted requests follow the same message exchange described in
Figure 2. The SWID-PV targets its request by providing one or more Figure 2. The SW-PV targets its request by providing one or more
SWID tag identifiers in its SWID Request attribute. The SWID-PC MUST Software Identifiers in its SW Request attribute. The SW-PC MUST
then limit its response to contain only tags that match the indicated then limit its response to contain only records that match the
tag identifier(s). This allows the network exchange to exclude indicated Software Identifier(s). This allows the network exchange
information that is not relevant to a given policy question, thus to exclude information that is not relevant to a given policy
reducing unnecessary bandwidth consumption. The SWID-PC's response question, thus reducing unnecessary bandwidth consumption. The SW-
might consist of full tags or of tag identifier instances, depending PC's response might consist of full records or of Software
on the parameters of the SWID Request. Identifiers, depending on the parameters of the SW Request.
Targeted requests cannot target specific SWID tag instances; the SWID
Request does not include fields for Instance IDs. As a result, when
responding to a targeted request, a SWID-PC MUST return applicable
results for every instance of the identified tags.
Note that targeted requests identify the SWID tags relevant to the Note that targeted requests identify the software relevant to the
request only through SWID tag identifiers for those tags. This request only through Software Identifiers. This specification does
specification does not support arbitrary, parameterized querying of not support arbitrary, parameterized querying of records. For
tags. For example, one cannot request all tags from a certain example, one cannot request all records from a certain software
software publisher, or all tags created by a particular tag creator. publisher, or all records created by a particular record source.
Targeted requests only allow a requestor to request specific software
(as identified by their Software Identifiers) and receive a response
that is limited to the named software.
Targeted requests only allow a requestor to request specific tags (as There is no assumption that a SW-PC will recognize "synonymous
identified by their tag identifiers) and receive a response that is records" - that is, records from different sources for the same
limited to the named tags. There is also no assumption that a SWID- software. Recall that different sources and data models may use
PC will recognize "synonymous tags" - that is, tags by different tag different Software Identifier strings for the same software product.
creators for the same software product. The SWID-PC returns only The SW-PC returns only records that match the Software Identifiers in
tags that match the tag identifiers in the SWID Request, even if the SW Request, even if there might be other records in the
there might be other SWID tags in the endpoint's SWID tag collection endpoint's Software Inventory Evidence Collection for the same
for the same software product. software product. This is necessary because SW-PCs might not have
the ability to determine that two Software Identifiers refer to the
same product.
SWID-PCs MUST accept targeted requests and process them correctly as Targeted requests do not include Record Identifiers. The response to
described above. SWID-PVs MUST be capable of making targeted a targeted request MUST include all records associated with the named
requests and processing the responses thereto. Software Identifiers, including the case where there are multiple
records associated with a single Software Identifier.
3.5. Monitoring Changes in an Endpoint's SWID Tag Collection SW-PCs MUST accept targeted requests and process them correctly as
described above. SW-PVs MUST be capable of making targeted requests
and processing the responses thereto.
The SWID collection on an endpoint is not static. As software is 3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence
installed, uninstalled, patched, or updated, the SWID tag collection Collection
is expected to change to reflect the new software state on the
endpoint. For tags managed by an application's installer, tag
changes usually occur at the time of installation or update. For
tags added by discovery tools, software and package managers, and
other sources, changes to the endpoint's SWID tag collection occur
when some process discovers the new or altered software product,
which typically lags behind the actual installation or update time.
All SWID-PCs MUST be able to be able to detect changes to the SWID The software collection on an endpoint is not static. As software is
tag repositories on their endpoint. Specifically, SWID-PCs MUST be installed, uninstalled, patched, or updated, the Software Inventory
able to detect: Evidence Collection is expected to change to reflect the new software
state on the endpoint. Different record sources might update the
evidence collection at different rates. For example, a package
manager might update its records in the Software Inventory Evidence
Collection immediately whenever it is used to add or remove a
software product. By contrast, sources that perform periodic
examination of the endpoint would likely only update their records in
the Software Inventory Evidence Collection after each examination.
o The creation of tags All SW-PCs MUST be able to be able to detect changes to the Software
Inventory Evidence Collection. Specifically, SW-PCs MUST be able to
detect:
o The deletion of tags o The creation of records
o The alteration of tags o The deletion of records
An "alteration" is anything that modifies the contents of a SWID tag o The alteration of records
file (or would modify it, if the tag file is dynamically generated on An "alteration" is anything that modifies the contents of a record
(or would modify it, if the record is dynamically generated on
demand) in any way, regardless of whether the change is functionally demand) in any way, regardless of whether the change is functionally
meaningful. Changes MUST be monitored for all utilized sources of meaningful.
SWID tags. This includes, but is not limited to, monitoring sources
that dynamically generate SWID tags.
SWID-PCs MUST detect such changes to the endpoint's SWID tag SW-PCs MUST detect such changes to the endpoint's Software Inventory
collection in close to real-time (i.e., within seconds) when the Evidence Collection in close to real-time (i.e., within seconds) when
Posture Collector is operating. In addition, in the case where there the Posture Collector is operating. In addition, in the case where
is a period during which the SWID-PC is not operating, the SWID-PC there is a period during which the SW-PC is not operating, the SW-PC
MUST be able to determine the net change to the endpoint's SWID tag MUST be able to determine the net change to the endpoint's Software
collection over the period it was not operational. Specifically, the Inventory Evidence Collection over the period it was not operational.
"net change" represents the difference between the state of the Specifically, the "net change" represents the difference between the
endpoint's SWID tag collection when the SWID-PC was last operational state of the endpoint's Software Inventory Evidence Collection when
and monitoring its state, and the state of the endpoint's SWID tag the SW-PC was last operational and monitoring its state, and the
collection when the SWID-PC resumed operation. Note that a net state of the endpoint's software inventory evidence collection when
change might not reflect the total number of change events over this the SW-PC resumed operation. Note that a net change might not
interval. For example, if a SWID tag file was altered three times reflect the total number of change events over this interval. For
during a period when the SWID-PC was unable to monitor for changes, example, if a record was altered three times during a period when the
the net change of this interval might only note that there was an SW-PC was unable to monitor for changes, the net change of this
alteration to the file, but not how many individual alteration events interval might only note that there was an alteration to the record,
occurred. It is sufficient for a SWID-PC's determination of a net but not how many individual alteration events occurred. It is
change to note that there was a difference between the earlier and sufficient for a SW-PC's determination of a net change to note that
current state rather than enumerating all the individual events that there was a difference between the earlier and current state rather
allowed the current state to be reached. than enumerating all the individual events that allowed the current
state to be reached.
The SWID-PC MUST assign a time to each detected change in the The SW-PC MUST assign a time to each detected change in the
endpoint's SWID tag collection. These timestamps correspond to the endpoint's Software Inventory Evidence Collection. These timestamps
SWID-PC's best understanding as to when the detected change occurred. correspond to the SW-PC's best understanding as to when the detected
These timestamps MUST be as accurate as possible. For changes to the change occurred. These timestamps MUST be as accurate as possible.
endpoint's SWID tag collection that occur while the SWID-PC is For changes to the endpoint's Software Inventory Evidence Collection
operating, the SWID-PC ought to be able to assign a time to the event that occur while the SW-PC is operating, the SW-PC ought to be able
that is accurate to within a few seconds. For changes to the to assign a time to the event that is accurate to within a few
endpoint's SWID tag collection that occur while the SWID-PC is not seconds. For changes to the endpoint's Software Inventory Evidence
operational, upon becoming operational the SWID-PC needs to make a Collection that occur while the SW-PC is not operational, upon
best guess as to the time of the relevant events (possibly by looking becoming operational the SW-PC needs to make a best guess as to the
at timestamps on the files), but these values might be off. In the time of the relevant events (possibly by looking at timestamps on
case of dynamically generated SWID tags, the time of change is the files), but these values might be off. In the case of dynamically
time at which the data from which the SWID tags are generate changes, generated records, the time of change is the time at which the data
not the time at which a changed SWID tag is generated. For example, from which the records are generate changes, not the time at which a
if SWID tags are dynamically generated based on data in an RPM changed record is generated. For example, if records are dynamically
database, the time of change would be when the RPM record was generated based on data in an RPM database, the time of change would
changed. be when the RPM record was changed.
With regard to deletions of SWID tags, the SWID-PC needs to detect With regard to deletions of records, the SW-PC needs to detect the
the deletion and MUST retain a copy of the full deleted tag so that deletion and MUST retain a copy of the full deleted record along with
the tag itself can be provided to the SWID-PV upon request. This its Record Identifier so that the record itself can be provided to
copy of the SWID tag MUST be retained for a reasonable amount of the SW-PV upon request. This copy of the record MUST be retained for
time. Vendors and administrators determine what "reasonable" means, a reasonable amount of time. Vendors and administrators determine
but a copy of the tag SHOULD be retained for as long as the event what "reasonable" means, but a copy of the record SHOULD be retained
recording the deletion of the tag remains in the SWID-PC's records. for as long as the event recording the deletion of the record remains
This is recommended because, as long as the event is in the SWID-PC's in the SW-PC's event log (as described in Section 3.5). This is
records, the SWID-PC might send an event attribute (described in recommended because, as long as the event is in the SW-PC's change
Section 3.6) that references this tag, and a copy of the tag is logs, the SW-PC might send an event attribute (described in
needed if the SWID-PV wanted a full copy of the relevant tags. Section 3.5) that references this record, and a copy of the record is
needed if the SW-PV wanted a full copy of the relevant records.
With regard to alterations to a SWID tag file, SWID-PCs MUST detect With regard to alterations to a record, SW-PCs MUST detect any
any alterations to the contents of a tag file. Alterations need to alterations to the contents of a record. Alterations need to be
be detected even if they have no functional impact on the tag file. detected even if they have no functional impact on the record. A
For example, the addition of whitespace between XML attributes does good guideline is that any alteration to a record that might change
not have any impact on the meaning of the SWID tag file, but still the value of a hash taken on the record's contents needs to be
needs to be detected as a tag file alteration by a SWID-PC. A good detected by the SW-PC. A SW-PC might be unable to distinguish
guideline is that any alteration to a file that might change the modifications to the content of a record from modifications to the
value of a hash taken on the file's contents needs to be detected by metadata the file system associates with the record. For example, a
the SWID-PC. A SWID-PC might be unable to distinguish modifications SW-PC might use the "last modification" timestamp as an indication of
to the content of a tag file from modifications to the metadata the alteration to a given record, but a record's last modification time
file system associates with the tag file. For example, a SWID-PC can change for reasons other than modifications to the record
might use the "last modification" timestamp as an indication of contents. A SW-PC is still considered compliant with this
alteration to a given tag file, but a file's last modification time specification if it also reports metadata change events that do not
can change for reasons other than modifications to the file contents. change the record itself as alterations to the record. In other
A SWID-PC is still considered compliant with this specification if it words, while SW-PC authors are encouraged to exclude modifications
also reports metadata change events that do not change the SWID tag that do not affect the bytes within the record, discriminating
file itself as alterations to the SWID tag file. In other words, between modifications to file contents and changes to file metadata
while SWID-PC authors are encouraged to exclude modifications that do can be difficult and time consuming on some systems. As such, as
not affect the bytes within the tag file when detecting alterations long as the alterations detected by a SW-PC always cover all
to a SWID tag record, discriminating between modifications to file modifications to the contents of record, the SW-PC is considered
contents and changes to file metadata can be difficult and time compliant even if it also registers alterations that do not modify
consuming on some systems. As such, as long as the alterations the contents of a record as well. When recording an alteration to a
detected by a SWID-PC always cover all modifications to the contents record, the SW-PC is only required to note that an alteration
of tag files, the SWID-PC is considered compliant even if it also occurred. The SW-PC is not required to note or record how the record
registers alterations that do not modify the contents of a tag file altered, nor is it possible to include such details in SW Attributes
as well. When recording an alteration to a tag file, the SWID-PC is reporting the change to a SW-PV.
only required to note that an alteration occurred. The SWID-PC is
not required to note or record how the tag file altered, nor is it
possible to include such details in SWID Attributes reporting the
change to a SWID-PV.
3.6. Reporting Change Events 3.5. Reporting Change Events
As noted in the preceding section, SWID-PCs MUST be able to detect As noted in the preceding section, SW-PCs MUST be able to detect
changes to the SWID tag repositories (tag creation, tag removal, and changes to the endpoints software inventory evidence collection
tag alteration) in near real-time while the SWID-PC is operational, (creation, deletion, and alteration) in near real-time while the SW-
and MUST be able to account for any net change to the endpoint's SWID PC is operational, and MUST be able to account for any net change to
tag collection that occurs when the SWID-PC is not operational. the endpoint's Software Inventory Evidence Collection that occurs
However, to be of use to the enterprise, the NEA Server needs to be when the SW-PC is not operational. However, to be of use to the
able to receive these events and be able to understand how new enterprise, the NEA Server needs to be able to receive these events
changes relate to earlier changes. In SWID Message and Attributes and be able to understand how new changes relate to earlier changes.
for PA-TNC, this is facilitated by reporting change events. All In Software Message and Attributes for PA-TNC, this is facilitated by
SWID-PCs MUST be capable of receiving requests for change events and reporting change events. All SW-PCs MUST be capable of receiving
sending change event attributes. All SWID-PVs MUST be capable of requests for change events and sending change event attributes. All
requesting and receiving change event attributes. SW-PVs MUST be capable of requesting and receiving change event
attributes.
3.6.1. Change Event Records 3.5.1. Change Event Records
A change event record consists of either a complete SWID tag or SWID A change event record consists of either a complete record or
tag identifier instance along with the following pieces of Software Identifier from the changed record along with the following
information: pieces of information:
o The nature of the change (i.e., tag creation, tag deletion, or tag o The nature of the change (i.e., creation, deletion, or lteration)
alteration)
o An Event Identifier (EID) value o An Event Identifier (EID) value
o An EID Epoch value o An EID Epoch value
An EID is a 4-byte unsigned integer that the SWID-PC assigns An EID is a 4-byte unsigned integer that the SW-PC assigns
sequentially to each observed event (whether detected in real-time or sequentially to each observed event (whether detected in real-time or
deduced by looking for net changes over a period of SWID-PC deduced by looking for net changes over a period of SW-PC
inactivity). All EIDs exist within the context of some "EID Epoch", inactivity). All EIDs exist within the context of some "EID Epoch",
which is also represented as a 4- byte unsigned integer. EID Epochs which is also represented as a 4-byte unsigned integer. EID Epochs
are used to ensure synchronization between the SWID-PC and any SWID- are used to ensure synchronization between the SW-PC and any SW-PVs
PVs with which it communicates. EID Epoch values SHOULD be generated with which it communicates. EID Epoch values SHOULD be generated
randomly and in such a way that it is unlikely that the same EID randomly and in such a way that it is unlikely that the same EID
Epoch is generated twice, even if the SWID-PC reverted to an earlier Epoch is generated twice, even if the SW-PC reverted to an earlier
state (e.g., resetting it to factory defaults). In the case where a state (e.g., resetting it to factory defaults). In the case where a
SWID-PC needs to reset its EID counter, either because it has SW-PC needs to reset its EID counter, either because it has exhausted
exhausted all available EID values or because the SWID-PC's event log all available EID values or because the SW-PC's event log becomes
becomes corrupted, then a new EID Epoch MUST be selected. corrupted, then a new EID Epoch MUST be selected.
Within an Epoch, EIDs MUST be assigned sequentially, so that if a Within an Epoch, EIDs MUST be assigned sequentially, so that if a
particular event is assigned an EID of N, the next observed event is particular event is assigned an EID of N, the next observed event is
given an EID of N+1. In some cases, events might occur given an EID of N+1. In some cases, events might occur
simultaneously, or the SWID-PC might not otherwise be able to simultaneously, or the SW-PC might not otherwise be able to determine
determine an ordering for events. In these cases, the SWID-PC an ordering for events. In these cases, the SW-PC creates an
creates an arbitrary ordering of the events and assigns EIDs arbitrary ordering of the events and assigns EIDs according to this
according to this ordering. Two change events MUST NOT ever be ordering. Two change events MUST NOT ever be assigned the same EID
assigned the same EID within the same EID Epoch. No meaningful within the same EID Epoch. No meaningful comparison can be made
comparison can be made between EID values of different Epochs. between EID values of different Epochs.
The EID value of 0 is reserved and MUST NOT be associated with any The EID value of 0 is reserved and MUST NOT be associated with any
event. Specifically, an EID of 0 in a SWID Request attribute event. Specifically, an EID of 0 in a SW Request attribute indicates
indicates that a SWID-PV wants an inventory response rather than an that a SW-PV wants an inventory response rather than an event
event response, while an EID of 0 in a SWID Response is used to response, while an EID of 0 in a SW Response is used to indicate the
indicate the initial state of the endpoint's SWID tag collection initial state of the endpoint's Software Inventory Evidence
prior to the observation of any events. Thus the very first recorded Collection prior to the observation of any events. Thus the very
event in a SWID-PC's records within an EID Epoch MUST be assigned a first recorded event in a SW-PC's records within an EID Epoch MUST be
value of 1 or greater. Note that EID and EID Epoch values are assigned a value of 1 or greater. Note that EID and EID Epoch values
assigned by the SWID-PC without regard to whether events are being are assigned by the SW-PC without regard to whether events are being
reported to one or more SWID-PVs. The SWID-PC records events and reported to one or more SW-PVs. The SW-PC records events and assigns
assigns EIDs during its operation. Any and all SWID-PVs that request EIDs during its operation. Any and all SW-PVs that request event
event information from the SWID-PC will have those requests served information from the SW-PC will have those requests served from the
from the same records and thus will see the same EIDs and EID Epochs same event records and thus will see the same EIDs and EID Epochs for
for the same events. the same events.
The SWID-PC MUST ensure there is no coverage gap (i.e., change events The SW-PC MUST ensure there is no coverage gap (i.e., change events
that are not recorded in the SWID-PC's records) in its records of that are not recorded in the SW-PC's records) in its change event
change events. This is necessary because a coverage gap might give a records. This is necessary because a coverage gap might give a SW-PV
SWID-PV a false impression of the endpoint's state. For example, if a false impression of the endpoint's state. For example, if a SW-PV
a SWID-PV saw an event indicating that a particular SWID tag had been saw an event indicating that a particular record had been added to
installed, and saw no subsequent events indicating that tag had been the endpoint's software inventory evidence collection, and saw no
deleted, it might reasonably assume that this tag was still installed subsequent events indicating that record had been deleted, it might
(assuming the Epoch has not changed). If there is a coverage gap in reasonably assume that this record was still present and thus that
the SWID-PC's records, however, this assumption is false. For this the indicated software was still installed (assuming the Epoch has
reason, the SWID-PC's event records MUST NOT contain gaps. In the not changed). If there is a coverage gap in the SW-PC's event
case where there are periods where it is possible that changes records, however, this assumption is false. For this reason, the SW-
occurred without the SWID-PC detecting or recording them, the SWID-PC PC's event records MUST NOT contain gaps. In the case where there
MUST either compute a net change and update its records are periods where it is possible that changes occurred without the
appropriately, or pick a new EID Epoch to indicate a discontinuity SW-PC detecting or recording them, the SW-PC MUST either compute a
with previous event records. net change and update its event records appropriately, or pick a new
EID Epoch to indicate a discontinuity with previous event records.
Within a given Epoch, once a particular event has been assigned an Within a given Epoch, once a particular event has been assigned an
EID, this association MUST NOT be changed. That is, within an Epoch, EID, this association MUST NOT be changed. That is, within an Epoch,
once an EID is assigned to an event, that EID cannot be reassigned to once an EID is assigned to an event, that EID cannot be reassigned to
a different event, and the event cannot be assigned a different EID. a different event, and the event cannot be assigned a different EID.
When the SWID-PC's Epoch changes, all of these associations between When the SW-PC's Epoch changes, all of these associations between
EIDs and events are cancelled, and EID values once again become free EIDs and events are cancelled, and EID values once again become free
for assignment. for assignment.
3.6.2. Updating Inventory Knowledge Based on Events 3.5.2. Updating Inventory Knowledge Based on Events
Modern endpoints can have hundreds of software products installed, Modern endpoints can have hundreds of software products installed,
most of which are unlikely to change from one day to the next. As most of which are unlikely to change from one day to the next. As
such, instead of exchanging a complete list of an endpoint's such, instead of exchanging a complete list of an endpoint's
inventory on a regular basis, one might wish to only identify changes inventory on a regular basis, one might wish to only identify changes
since some earlier known state of this inventory. This is readily since some earlier known state of this inventory. This is readily
facilitated by the use of EIDs to place change events in a context facilitated by the use of EIDs to place change events in a context
relative to earlier state. relative to earlier state.
Every inventory sent by a SWID-PC to a SWID-PV (as described in Every inventory sent by a SW-PC to a SW-PV (as described in
Section 3.2 through Section 3.4) includes the EID Epoch and EID of Section 3.1 through Section 3.3) includes the EID Epoch and EID of
the last event recorded prior to that inventory being compiled. This the last event recorded prior to that inventory being compiled. This
allows the SWID-PV to place all subsequently received event records allows the SW-PV to place all subsequently received event records in
in context relative to this inventory (since the EIDs represent a context relative to this inventory (since the EIDs represent a total
total ordering of all changes to the endpoint's SWID tag collection). ordering of all changes to the endpoint's software inventory evidence
Specifically, a SWID-PV (or, more likely, a database that collects collection). Specifically, a SW-PV (or, more likely, a database that
and records its findings) can record an endpoint's full inventory and collects and records its findings) can record an endpoint's full
also the EID and Epoch of the most recent event reflected in that inventory and also the EID and Epoch of the most recent event
state. From that point on, if change events are observed, the reflected in that state. From that point on, if change events are
attribute describing these events indicates the nature of the change, observed, the attribute describing these events indicates the nature
the affected SWID tags, and the order in which these events occurred of the change, the affected records, and the order in which these
(as indicated by the sequential EIDs). Using this information, any events occurred (as indicated by the sequential EIDs). Using this
remote record of the endpoint's SWID tag collection can be updated information, any remote record of the endpoint's Software Inventory
appropriately. Evidence Collection can be updated appropriately.
3.6.3. Using Event Records in SWID Attributes 3.5.3. Using Event Records in SW Attributes
A SWID-PV MUST be able to request a list of event records instead of A SW-PV MUST be able to request a list of event records instead of an
an inventory. The message flow in such an exchange looks the same as inventory. The message flow in such an exchange looks the same as
the basic flow shown in Figure 2. The only difference is that, in the basic flow shown in Figure 2. The only difference is that, in
the SWID Request attribute, the SWID-PV provides an EID other than 0. the SW Request attribute, the SW-PV provides an EID other than 0. (A
(A value of 0 in these fields represents a request for an inventory.) value of 0 in these fields represents a request for an inventory.)
When the SWID-PC receives such a request, instead of identifying SWID When the SW-PC receives such a request, instead of identifying
tags in the endpoint's SWID tag collection, it consults its record of records from the endpoint's Software Inventory Evidence Collection,
detected changes. The SWID-PC MUST add an event record to the SWID it consults its list of detected changes. The SW-PC MUST add an
Response attribute for each recorded change event with an EID greater event record to the SW Response attribute for each recorded change
than or equal to the EID in the SWID Request attribute (although event with an EID greater than or equal to the EID in the SW Request
targeting of requests, as described in the next paragraph, may limit attribute (although targeting of requests, as described in the next
this list). A list of event records MUST only contain events with paragraph, might limit this list). A list of event records MUST only
EIDs that all come from the current Epoch. contain events with EIDs that all come from the current Epoch.
SWID-PVs can target requests for event records by including one or SW-PVs can target requests for event records by including one or more
more tag identifiers, as described in Section 3.4, in the SWID Software Identifiers, as described in Section 3.3, in the SW Request
Request that requests an event record list. A targeted request for that requests an event record list. A targeted request for event
event records is used to indicate that only events affecting SWID records is used to indicate that only events affecting software that
tags that match the provided SWID tag identifiers are to be returned. match the provided Software Identifiers are to be returned.
Specifically, in response to a targeted request for event records, Specifically, in response to a targeted request for event records,
the SWID-PC MUST exclude any event records that are less than the the SW-PC MUST exclude any event records that are less than the
indicated EID (within the current EID Epoch) and exclude any event indicated EID (within the current EID Epoch) and exclude any event
records where the affected SWID tag does not match one of the records where the affected software does not match one of the
provided SWID tag identifiers. This might mean that the resulting provided Software Identifiers. This might mean that the resulting
list of event records sent in the response attribute does not provide list of event records sent in the response attribute does not provide
a continuous sequence of EIDs. Both SWID-PCs and SWIC-PVs MUST a continuous sequence of EIDs. Both SW-PCs and SWIC-PVs MUST support
support targeted request for event records. targeted request for event records.
3.6.4. Partial and Complete Lists of Event Records in SWID Attributes 3.5.4. Partial and Complete Lists of Event Records in SW Attributes
Over time, a SWID-PC might record a large number of change events. Over time, a SW-PC might record a large number of change events. If
If a SWID-PV requests all change events covering a large period of a SW-PV requests all change events covering a large period of time,
time, the resulting SWID Response attribute might be extremely large, the resulting SW Response attribute might be extremely large,
especially if the SWID-PV is requesting the use of full SWID tags especially if the SW-PV is requesting the use of full records instead
instead of the use of SWID Identifier instances (as described in of the use of Software Identifiers (as described in Section 3.2.2).
Section 3.3.4). In the case that the resulting attribute is too In the case that the resulting attribute is too large to send (either
large to send (either because it exceeds the 4GB attribute size limit because it exceeds the 4GB attribute size limit imposed by the PA-TNC
imposed by the PA-TNC specification, or because it exceeds some specification, or because it exceeds some smaller size limit imposed
smaller size limit imposed on the SWID-PC) the SWID-PC MAY send a on the SW-PC) the SW-PC MAY send a partial list of event records back
partial list of events back to the SWID-PV. to the SW-PV.
Generation of a partial list of events in a SWID Response attribute Generation of a partial list of events in a SW Response attribute
requires the SWID-PC to identify a "consulted range" of EIDs. A requires the SW-PC to identify a "consulted range" of EIDs. A
consulted range is the set of event records that are examined for consulted range is the set of event records that are examined for
inclusion in the SWID Response attribute and that are included in inclusion in the SW Response attribute and that are included in that
that attribute if applicable. Recall that, if a SWID Request is attribute if applicable. Recall that, if a SW Request is targeted,
targeted, only event records that involve the indicated SWID tags only event records that involve the indicated software would be
would be applicable. (See Section 3.4 for more on Targeted Request.) applicable. (See Section 3.3 for more on Targeted Request.) If a
If a request is not targeted, all event records in the considered request is not targeted, all event records in the considered range
range are applicable and included in the SWID Response attribute. are applicable and included in the SW Response attribute.
The lower bound of the consulted range MUST be the EID provided in The lower bound of the consulted range MUST be the EID provided in
the SWID Request. (Recall that a SWID Request indicates a request the SW Request. (Recall that a SW Request indicates a request for
for event records by providing a non-0 EID value in the SWID Request. event records by providing a non-0 EID value in the SW Request. See
See Section 3.6.3.) The upper bound of the consulted range is the Section 3.5.3.) The upper bound of the consulted range is the EID of
EID of the latest event record (as ordered by EID values) that is the latest event record (as ordered by EID values) that is included
included in the SWID Response attribute if it is applicable to the in the SW Response attribute if it is applicable to the request. The
request. The EID of this last event record is called the "Last EID of this last event record is called the "Last Consulted EID".
Consulted EID". The SWID-PC chooses this Last Consulted EID based on The SW-PC chooses this Last Consulted EID based on the size of the
the size of the event record list it is willing to provide to the event record list it is willing to provide to the SW-PV.
SWID-PV.
A partial result list MUST include all applicable event records A partial result list MUST include all applicable event records
within the consulted range. This means that for any applicable event within the consulted range. This means that for any applicable event
record whose EID is greater than or equal to the EID provided in the record (i.e., any event record in an un-targeted request, or an event
SWID Request and whose EID is less than or equal to the Last record associated with software matching a requested Software
Consulted EID, that event record MUST be included in the SWID Identifier in a targeted request) whose EID is greater than or equal
Response conveying this partial list of event records. This ensures to the EID provided in the SW Request and whose EID is less than or
that every partial list of event records is always complete within equal to the Last Consulted EID, that event record MUST be included
its indicated range. in the SW Response conveying this partial list of event records.
This ensures that every partial list of event records is always
complete within its indicated range.
All SWID Response attributes that convey event records (either using All SW Response attributes that convey event records (either using
full SWID tags or using SWID tag identifier instances) include an full records or using Software Identifiers) include an Epoch, Last
Epoch, Last EID, and Last Consulted EID field. The Last EID contains EID, and Last Consulted EID field. The Last EID contains the EID of
the EID of the last event record known to the SWID-PC at the time the last event record known to the SW-PC at the time that the SW
that the SWID Response attribute was generated. The Last EID might Response attribute was generated. The Last EID might or might not be
or might not be part of the consulted range. As noted above, the part of the consulted range. As noted above, the Last Consulted EID
Last Consulted EID field contains the EID of the last event record in field contains the EID of the last event record in the consulted
the consulted range. The Epoch field contains the EID Epoch range. The Epoch field contains the EID Epoch associated with the
associated with the Last EID and Last Consulted EID fields as well as Last EID and Last Consulted EID fields as well as all the EIDs in
all the EIDs in event records contained within the SWID Response event records contained within the SW Response attribute. Note that,
attribute. Note that, if responding to a targeted SWID Request, the if responding to a targeted SW Request, the SW Response attribute
SWID Response attribute might not contain the event record whose EID might not contain the event record whose EID matches the Last
matches the Last Consulted EID value. For example, the last Consulted EID value. For example, the last consulted EID record
consulted EID record might have been deemed inapplicable because it might have been deemed inapplicable because it did not match the
did not match the specified list of SWID tag identifiers in the SWID specified list of Software Identifiers in the SW Request.
Request.
If a SWID-PV receives a SWID Response attribute where the Last EID If a SW-PV receives a SW Response attribute where the Last EID and
and Last Consulted EID fields are identical, the SWID-PV knows that Last Consulted EID fields are identical, the SW-PV knows that it has
it has received a result list that is complete, given the parameters received a result list that is complete, given the parameters of the
of the request, up to the present time. On the other hand, if the request, up to the present time. On the other hand, if the Last EID
Last EID and Last Consulted EID values differ, the SWID-PV has and Last Consulted EID values differ, the SW-PV has received a
received a partial result list. In the latter case, if the SWID-PV partial result list. In the latter case, if the SW-PV wishes to try
wishes to try to collect the rest of the partially delivered result to collect the rest of the partially delivered result list it then
list it then sends a new SWID Request whose EID is one greater than sends a new SW Request whose EID is one greater than the Last
the Last Consulted EID in the preceding response. Doing this causes Consulted EID in the preceding response. Doing this causes the SW-PC
the SWID-PC to generate another SWID Response attribute containing to generate another SW Response attribute containing event records
event records where the earliest reported event record is the one where the earliest reported event record is the one immediately after
immediately after the event record with the Last Consulted EID (since the event record with the Last Consulted EID (since EIDs are assigned
EIDs are assigned sequentially). By repeating this process until it sequentially). By repeating this process until it receives a SW
receives a SWID Response where the Last EID and Last Consulted EID Response where the Last EID and Last Consulted EID are equal, the SW-
are equal, the SWID-PV is able to collect all event records over a PV is able to collect all event records over a given range, even if
given range, even if the complete set of event records would be too the complete set of event records would be too large to deliver via a
large to deliver via a single attribute. single attribute.
Implementers need to be aware that a SWID Request might specify an Implementers need to be aware that a SW Request might specify an EID
EID that is greater than the EID of the last event recorded by a that is greater than the EID of the last event recorded by a SW-PC.
SWID-PC. In accordance with the behaviors described in In accordance with the behaviors described in Section 3.5.3, a SW-PC
Section 3.6.3, a SWID-PC MUST respond to such a request with a SWID MUST respond to such a request with a SW Response attribute of the
Response attribute of the appropriate type (using SWID tags or SWID appropriate type (using full records or Software Identifiers as
tag identifier instances as specified in the SWID Request) that specified in the SW Request) that contains zero event records. This
contains zero event records. This is because the SWID-PC has is because the SW-PC has recorded no event records with EIDs greater
recorded no event records with EIDs greater than or equal to the EID than or equal to the EID in the SW Request. In such a case, the Last
in the SWID Request. In such a case, the Last Consulted EID field Consulted EID field MUST be set to the same value as the Last EID
MUST be set to the same value as the Last EID field in this SWID field in this SW Response attribute. This case is called out because
response attribute. This case is called out because consulted range the consulted range on a SW-PC in such a situation is a negative
on a SWID-PC in such a situation is a negative range, where the range, where the "first" EID in the range (provided in the SW
"first" EID in the range (provided in the SWID Request) is greater Request) is greater than the "last" EID in the range (this being the
than the "last" EID in the range (this being the EID of the last EID of the last recorded event on the SW-PC). Implementers need to
recorded event on the SWID-PC). Implementers need to ensure that ensure that SW-PCs do not experience problems in such a circumstance.
SWID-PCs do not experience problems in such a circumstance.
Note that this specification only supports the returning of partial Note that this specification only supports the returning of partial
results when returning event records. There is no way to return a results when returning event records. There is no way to return a
partial inventory list under this specification. partial inventory list under this specification.
3.6.5. Synchronizing Event Identifiers and Epochs 3.5.5. Synchronizing Event Identifiers and Epochs
Since EIDs are sequential within an Epoch, if a SWID-PV's list of Since EIDs are sequential within an Epoch, if a SW-PV's list of event
event records contains gaps in the EID values within a single Epoch, records contains gaps in the EID values within a single Epoch, the
the SWID-PV knows that there are events that have not been accounted SW-PV knows that there are events that have not been accounted for.
for. The SWID-PV can either request a new event list to collect the The SW-PV can either request a new event list to collect the missing
missing events or request a full inventory to re-sync its events or request a full inventory to re-sync its understanding of
understanding of the state of the SWID tags on the endpoint. In the state of the Endpoint's Software Inventory Evidence Collection.
either case, after the SWID-PV's record of the endpoint's SWID tag In either case, after the SW-PV's record of the endpoint's Software
collection has been updated, the SWID-PV records the new latest EID Inventory Evidence Collection has been updated, the SW-PV can record
value and tracks events normally from that point on. the new latest EID value and track events normally from that point
on.
If the SWID-PV receives any attribute from a SWID-PC where the EID If the SW-PV receives any attribute from a SW-PC where the EID Epoch
Epoch differs from the EID Epoch that was used previously, then SWID- differs from the EID Epoch that was used previously, then SW-PV or
PV or any entity using this information to track the endpoint's SWID any entity using this information to track the endpoint's Software
tag collection knows that there is a discontinuity in their Inventory Evidence Collection knows that there is a discontinuity in
understanding of the endpoint's state. To move past this their understanding of the endpoint's state. To move past this
discontinuity and reestablish a current understanding of the state of discontinuity and reestablish a current understanding of the state of
the endpoint's SWID tag collection, the SWID-PV needs to receive a the endpoint's Software Inventory Evidence Collection, the SW-PV
full inventory from the endpoint. This is because it is not possible needs to receive a full inventory from the endpoint. The SW-PV
to account for all events on the SWID-PC over the interval since the cannot be brought in sync with the endpoint's state through the
previous Epoch was used, because there is no way to query for EIDs collection of any set of event records in this situation. This is
from a previous Epoch. Once the SWID-PV has received a full because it is not possible to account for all events on the SW-PC
inventory for the new Epoch, the SWID-PV records the latest EID over the interval since the previous Epoch was used, because there is
reported in this new Epoch and can track further events normally. no way to query for EIDs from a previous Epoch. Once the SW-PV has
received a full inventory for the new Epoch, the SW-PV records the
latest EID reported in this new Epoch and can track further events
normally.
A SWID-PC MUST NOT report events with EIDs from any Epoch other than A SW-PC MUST NOT report events with EIDs from any Epoch other than
the current EID Epoch. The SWID-PC MAY choose to purge all event the current EID Epoch. The SW-PC MAY choose to purge all event
records from a previous Epoch from memory after an Epoch change. records from a previous Epoch from memory after an Epoch change.
Alternately, the SWID-PC MAY choose to retain some event records from Alternately, the SW-PC MAY choose to retain some event records from a
a previous EID Epoch and assign them new EIDs in the current Epoch. previous EID Epoch and assign them new EIDs in the current Epoch.
However, in the case where a SWID-PC chooses the latter option it However, in the case where a SW-PC chooses the latter option it MUST
MUST ensure that the order of events according to their EIDs is ensure that the order of events according to their EIDs is unchanged
unchanged and that there is no coverage gap between the first and that there is no coverage gap between the first retained event
retained event recorded during the previous Epoch (now reassigned recorded during the previous Epoch (now reassigned with an EID in the
with an EID in the current Epoch) and the first event recorded during current Epoch) and the first event recorded during the current Epoch.
the current Epoch. In particular, the SWID-PC MUST ensure that all In particular, the SW-PC MUST ensure that all change events that
change events that occurred after the last recorded event from the occurred after the last recorded event from the previous Epoch are
previous Epoch are known and recorded. (This might not be possible known and recorded. (This might not be possible if the Epoch change
if the Epoch change is due to state corruption on the SWID-PC.) A is due to state corruption on the SW-PC.) A SW-PC might choose to
SWID-PC might choose to reassign EIDs to records from a preceding reassign EIDs to records from a preceding Epoch to create a "sliding
Epoch to create a "sliding window" of events, where each Epoch change window" of events, where each Epoch change represents a shift in the
represents a shift in the window of available events. window of available events.
In the case where a SWID-PC suffers a crash and loses track of its In the case where a SW-PC suffers a crash and loses track of its
current EID Epoch or current EID, then it MUST generate a new EID current EID Epoch or current EID, then it MUST generate a new EID
Epoch value and begin assigning EIDs within that Epoch. In this Epoch value and begin assigning EIDs within that Epoch. In this
case, the SWID-PC MUST purge all event records from before the crash case, the SW-PC MUST purge all event records from before the crash as
as it cannot ensure that there is not a gap between the last of those it cannot ensure that there is not a gap between the last of those
records and the next detected event. The process for generating a records and the next detected event. The process for generating a
new EID Epoch MUST minimize the possibility that the newly generated new EID Epoch MUST minimize the possibility that the newly generated
EID Epoch is the same as a previously used EID Epoch. EID Epoch is the same as a previously used EID Epoch.
The SWID-PV will normally never receive an attribute indicating that The SW-PV will normally never receive an attribute indicating that
the latest EID is less than the latest EID reported in a previous the latest EID is less than the latest EID reported in a previous
attribute within the same EID Epoch. If this occurs, the SWID-PC has attribute within the same EID Epoch. If this occurs, the SW-PC has
suffered an error of some kind, possibly indicative of at least suffered an error of some kind, possibly indicative of at least
partial corruption of its event log. In this case, the SWID-PV partial corruption of its event log. In this case, the SW-PV SHOULD
SHOULD treat the situation as if there was a change in Epoch and treat the situation as if there was a change in Epoch and treat any
treat any local copy of the endpoint's SWID tag collection as out-of- local copy of the endpoint's Software Inventory Evidence Collection
sync until a full inventory can be reported by the SWID-PC. In this as out-of-sync until a full inventory can be reported by the SW-PC.
case, the SWID-PV SHOULD flag the event so it can be examined to In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can
ensure it is now operating properly. be examined to ensure it is now operating properly.
3.7. Supporting Multiple Instances of a Single Tag
One important consideration is that it is possible for multiple
instances of a SWID tag to be present on an endpoint. (I.e.,
multiple SWID tag files whose tag identifiers are the same.) This
can happen if there are multiple instances of the indicated software
product installed on the endpoint. In order to account for the
possibility, all SWID-PCs MUST follow specific rules, outlined below.
3.7.1. Inventory Reporting in the Presence of Multiply-Instantiated
Tags
When sending an inventory, either full or based on a targeted
request, the SWID-PC MUST include one entry for each instance of a
relevant tag. (All tags are relevant in a full inventory. In a
targeted request for an inventory, only tags that match the tag
identifiers provided by the SWID-PV are considered relevant.) For
example, if a particular piece of software is installed twice on an
endpoint, and thus there are two instances of its SWID tag present in
the endpoint's SWID tag collection, an inventory for which this tag
is relevant will contain at least two records for this piece of
software, one for each tag instance. (It might contain more if
multiple tag creators each created tags for the same piece of
installed software.) In the case where the SWID-PC's response is
expressed using full tags, the response MUST contain one copy of each
instance of the given tag. In other words, the SWID-PC MUST send one
copy of each tag instance, rather than send multiple copies of one
tag instance. In the case where the SWID-PC's response is expressed
using tag identifiers, the response MUST include the tag identifier
instance for each instance of the given tag.
3.7.2. Event Reporting in the Presence of Multiply Instantiated Tags
When reporting events, the specific tags that were added, deleted, or
changed MUST be indicated. For example, in the case where tags A and
B are two instances of the same SWID tag, each for separate
installations of the same software product, and tag A changes in the
endpoint's SWID tag collection, the SWID-PC MUST report the event
using tag A (rather than reporting it using B). This means that the
report MUST contain the tag file or the tag identifier instance for
the affected tag.
3.8. Subscriptions 3.6. Subscriptions
Thus far, all message exchanges discussed assume that a SWID-PV sent Thus far, all message exchanges discussed assume that a SW-PV sent an
an SWID Request attribute and the SWID-PC is providing a direct SW Request attribute and the SW-PC is providing a direct response to
response to that request. The SWID Message and Attributes for PA-TNC that request. The Software Message and Attributes for PA-TNC
specification also supports the ability for a SWID-PC to send a specification also supports the ability for a SW-PC to send a message
message with a SWID Attribute to the SWID-PV in response to observed with a SW Attribute to the SW-PV in response to observed changes in
changes in the endpoint's SWID tag collection, instead of in direct the endpoint's software inventory evidence collection, instead of in
response to a SWID Request. An agreement by a SWID-PC to send direct response to a SW Request. An agreement by a SW-PC to send
content when certain changes are detected to the endpoint's SWID tag content when certain changes are detected to the endpoint's Software
collection is referred to in this specification as a "subscription", Inventory Evidence Collection is referred to in this specification as
and the SWID-PV that receives this content is said to be "subscribed a "subscription", and the SW-PV that receives this content is said to
to" the given SWID-PC. All SWID-PCs and SWID-PVs MUST support the be "subscribed to" the given SW-PC. All SW-PCs and SW-PVs MUST
use of subscriptions. support the use of subscriptions.
3.8.1. Establishing Subscriptions 3.6.1. Establishing Subscriptions
A SWID-PV establishes a subscription on a particular SWID-PC by A SW-PV establishes a subscription on a particular SW-PC by sending a
sending a SWID Request attribute with the Subscription flag set. The SW Request attribute with the Subscription flag set. The SW Request
SWID Request attribute is otherwise identical to the SWID Requests attribute is otherwise identical to the SW Requests discussed in
discussed in previous sections. Specifically, such a SWID Request previous sections. Specifically, such a SW Request might request
might request full tags or tag identifier instances, might be full records or Software Identifiers, might be targeted, and might
targeted, and might request change event records or endpoint request change event records or endpoint inventory. Assuming no
inventory. Assuming no error is encountered, a SWID-PC MUST send a error is encountered, a SW-PC MUST send a SW Response attribute in
SWID Response attribute in direct response to this SWID Request direct response to this SW Request attribute, just as if the
attribute, just as if the Subscription flag was not set. As such, Subscription flag was not set. As such, the message exchange that
the message exchange that establishes a new subscription in a SWID-PC establishes a new subscription in a SW-PC has the same flow seen in
has the same flow seen in the previous message exchanges, as depicted the previous message exchanges, as depicted in Figure 2. If the SW-
in Figure 2. If the SWID-PV does not receive a PA-TNC Error PV does not receive a PA-TNC Error attribute (as described in
attribute (as described in Section 3.10 and Section 4.16) in response Section 3.8 and Section 4.16) in response to their subscription
to their subscription request, the subscription has been successfully request, the subscription has been successfully established on the
established on the SWID-PC. The SWID Request attribute that SW-PC. The SW Request attribute that establishes a new subscription
establishes a new subscription is referred to as the "establishing is referred to as the "establishing request" for that subscription.
request" for that subscription.
When a subscription is established it is assigned a Subscription ID When a subscription is established it is assigned a Subscription ID
value. The Subscription ID is equal to the value of the Request ID value. The Subscription ID is equal to the value of the Request ID
of the establishing request. (For more about Request IDs, see of the establishing request. (For more about Request IDs, see
Section 4.8.) Section 4.8.)
A SWID-PC MUST have the ability to record and support multiple A SW-PC MUST have the ability to record and support multiple
simultaneous subscriptions from a single party and subscriptions from simultaneous subscriptions from a single party and from multiple
multiple parties. A SWID-PV MUST have the ability to record and parties. A SW-PV MUST have the ability to record and support
support multiple simultaneous subscriptions to a single party and multiple simultaneous subscriptions to a single party and
subscriptions to multiple parties. subscriptions to multiple parties.
3.8.2. Managing Subscriptions 3.6.2. Managing Subscriptions
The SWID-PC MUST record each accepted subscription along with the The SW-PC MUST record each accepted subscription along with the
identity of the party to whom attributes are to be pushed in identity of the party to whom attributes are to be pushed in
compliance with the subscription. This identity includes both the compliance with the subscription. This identity includes both the
NEA Server's connection ID and the Posture Validator Identifier from NEA Server's connection ID and the Posture Validator Identifier from
the PB-PA message that delivered the request. the PB-PA message that delivered the request.
Likewise, SWID-PVs MUST record each accepted subscription for which Likewise, SW-PVs MUST record each accepted subscription for which
they are the subscribing party along with the associated Subscription they are the subscribing party along with the associated Subscription
ID and the identity of the SWID-PC that will be fulfilling the ID and the identity of the SW-PC that will be fulfilling the
subscription. The SWID-PV needs to retain this information in order subscription. The SW-PV needs to retain this information in order to
to correctly interpret pushed SWID Response attributes sent in correctly interpret pushed SW Response attributes sent in fulfillment
fulfillment of the subscription. The identity of the SWID-PC is of the subscription. The identity of the SW-PC is given in the
given in the Posture Collector Identifier of the PB-PA message header Posture Collector Identifier of the PB-PA message header in all
in all messages from that SWID-PC. messages from that SW-PC.
3.8.3. Terminating Subscriptions 3.6.3. Terminating Subscriptions
Subscriptions MAY be terminated at any time by the subscribing SWID- Subscriptions MAY be terminated at any time by the subscribing SW-PV
PV by setting the Clear Subscriptions flag in a SWID Request. (See by setting the Clear Subscriptions flag in a SW Request. (See
Section 4.9 for more on using this flag.) In the case that the SWID- Section 4.9 for more on using this flag.) In the case that a SW
PC receives both the connection ID and the Posture Validator ID of Request with the Clear Subscriptions flag set is received the SW-PC
the SWID-PV requesting that subscriptions be cleared (i.e., the clear MUST only clear subscriptions that match both the NEA server
subscription request is received via a TNC_IMC_ReceiveMessageLong connection ID and the SW-PV ID for this SW Request, and MUST clear
function) and the SWID-PC has been recording PV IDs associated with all such subscriptions.
subscriptions when available, the SWID-PC MUST only clear
subscriptions that match both the connection ID and the PV ID, and
MUST clear all such subscriptions. In the case that the SWID-PC only
has the connection ID of the party requesting that subscriptions be
cleared or the SWID-PC has not been recording Posture Validator IDs
associated with subscriptions even when available, it MUST only clear
subscriptions that match the connection ID and that have no
associated Posture Validator ID, and MUST clear all such
subscriptions.
This specification does not give the SWID-PV the ability to terminate This specification does not give the SW-PV the ability to terminate
subscriptions individually - all subscriptions to the SWID-PV are subscriptions individually - all subscriptions to the SW-PV are
cleared when the Clear Subscriptions flag is set. cleared when the Clear Subscriptions flag is set.
This specification does not give the SWID-PC the ability to This specification does not give the SW-PC the ability to
unilaterally terminate a subscription. However, if the SWID-PC unilaterally terminate a subscription. However, if the SW-PC
experiences a fatal error fulfilling a subscription, resulting in experiences a fatal error fulfilling a subscription, resulting in
sending a PA-TNC Error attribute of type sending a PA-TNC Error attribute of type
SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose
fulfillment led to the error MUST be treated as terminated by both fulfillment led to the error MUST be treated as terminated by both
the SWID-PC and the SWID-PV. Only the subscription experiencing the the SW-PC and the SW-PV. Only the subscription experiencing the
error is cancelled and other subscriptions are unaffected. See error is cancelled and other subscriptions are unaffected. See
Section 3.10 for more on this error condition. Section 3.8 for more on this error condition.
Finally, a subscription is terminated if the connection between the Finally, a subscription is terminated if the connection between the
SWID-PC and SWID-PV is deleted. This occurs when the connection ID SW-PC and SW-PV is deleted. This occurs when the connection ID used
used in the messages between the SWID-PC and the SWID-PV becomes in the messages between the SW-PC and the SW-PV becomes unbound.
unbound. Loss of this connection ID would prevent the SWID-PC from Loss of this connection ID would prevent the SW-PC from sending
sending messages in fulfillment of this subscription. As such, loss messages in fulfillment of this subscription. As such, loss of the
of the connection ID necessarily forces subscription termination connection ID necessarily forces subscription termination between the
between the affected parties. affected parties.
3.8.4. Subscription Status 3.6.4. Subscription Status
A SWID-PV can request that a SWID-PC report the list of active A SW-PV can request that a SW-PC report the list of active
subscriptions where the SWID-PV is the subscriber. A SWID-PV can use subscriptions where the SW-PV is the subscriber. A SW-PV can use
this to recover lost information about active subscriptions. A SWID- this to recover lost information about active subscriptions. A SW-PV
PV can also use this capability to verify that a SWID-PC has not can also use this capability to verify that a SW-PC has not forgotten
forgotten any of its subscriptions. The latter is especially useful any of its subscriptions. The latter is especially useful where a
where a SWID-PC does not send any attributes in fulfillment of a SW-PC does not send any attributes in fulfillment of a given
given subscription for a long period of time. The SWID-PV can check subscription for a long period of time. The SW-PV can check the list
the list of active subscriptions on the SWID-PC and verify whether of active subscriptions on the SW-PC and verify whether the
the inactivity is due to a lack of reportable events, or due to the inactivity is due to a lack of reportable events, or due to the SW-PC
SWID-PC forgetting its obligations to fulfill a given subscription. forgetting its obligations to fulfill a given subscription.
A SWID-PV requests a list of its subscriptions on a given SWID-PC by A SW-PV requests a list of its subscriptions on a given SW-PC by
sending that SWID-PC a Subscription Status Request. The SWID-PC MUST sending that SW-PC a Subscription Status Request. The SW-PC MUST
then respond with a Subscription Status Response (or a PA-TNC Error then respond with a Subscription Status Response (or a PA-TNC Error
if an error condition is experienced). The Subscription Status if an error condition is experienced). The Subscription Status
Response contains one subscription record for each of the active Response MUST contain one subscription record for each of the active
subscriptions for which the SWID-PV is the subscribing party. subscriptions for which the SW-PV is the subscribing party.
Specifically, in the case that the Subscription Status Request
arrives with both a connection ID and a Posture Validator ID and the
SWID-PC has been recording Posture Validator IDs associated with
subscriptions when available, the SWID-PC MUST include only
subscription records associated with both the given connection ID and
Posture Validator ID, and MUST include all such records. In the case
that the Subscription Status Request arrives with only a connection
ID or the SWID-PC has not been recording Posture Validator IDs
associated with subscriptions even when available, the SWID-PC MUST
include only subscription records associated with the given
connection ID and that have no associated Posture Validator ID, and
MUST include all such records.
3.8.5. Fulfilling Subscriptions 3.6.5. Fulfilling Subscriptions
As noted in Section 3.5 SWID-PCs MUST have the ability to As noted in Section 3.4 SW-PCs MUST have the ability to automatically
automatically detect changes to an endpoint's SWID tag collection in detect changes to an endpoint's Software Inventory Evidence
near real-time. For every active subscription, the SWID-PC MUST send Collection in near real-time. For every active subscription, the SW-
an attribute to the subscribed SWID-PV whenever a change is detected PC MUST send an attribute to the subscribed SW-PV whenever a change
to relevant tags within the endpoint's SWID tag collection. The is detected to relevant records within the endpoint's Software
SWID-PC MAY choose to exclusively deliver this attribute. (See Inventory Evidence Collection. Such an attribute is said to be sent
section 4.5 of RFC 5793 (PB-TNC) [RFC5793] for more on exclusive "in fulfillment of" the given subscription and any such attribute
delivery.) Such an attribute is said to be sent "in fulfillment of" MUST include that subscription's Subscription ID. If the
the given subscription and any such attribute MUST include that establishing request for that subscription was a targeted request,
subscription's Subscription ID. If the establishing request for that then only records that match the Software Identifiers provided in
subscription was a targeted request, then only tags that match the that establishing request are considered relevant. Otherwise, (i.e.,
SWID tag identifiers provided in that establishing request are for non-targeted requests) any record is considered relevant for this
considered relevant. Otherwise, (i.e., for non-targeted requests) purpose. Figure 3 shows a sample message exchange where a
any tag is considered relevant for this purpose. Figure 3 shows a subscription is established and then later messages are sent from the
sample message exchange where a subscription is established and then SW-PC in fulfillment of the established subscription.
later messages are sent from the SWID-PC in fulfillment of the
established subscription.
+-------------+ +--------------+ +-------------+ +--------------+
| SWID-PC | | SWID-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<----------SWID Request------------| | |<-----------SW Request-------------| |
| | | | | |
|-----------SWID Response---------->| | |------------SW Response----------->| |
| | | | | |
. . . . . .
. . . . . .
. . . . . .
<Change Event>| | | <Change Event>| | |
|-----------SWID Response---------->| | |------------SW Response----------->| |
| | | | | |
. . . . . .
. . . . . .
. . . . . .
<Change Event>| | | <Change Event>| | |
|-----------SWID Response---------->| | |------------SW Response----------->| |
| | V | | V
Figure 3: Subscription Establishment and Fulfillment Figure 3: Subscription Establishment and Fulfillment
The contents of an attribute sent in fulfillment of a subscription The contents of an attribute sent in fulfillment of a subscription
depend on the parameters provided in the establishing request for depend on the parameters provided in the establishing request for
that subscription. Specifically, the contents of an attribute sent that subscription. Specifically, the contents of an attribute sent
in fulfillment of a subscription have the same format as would a in fulfillment of a subscription have the same format as would a
direct response to the establishing request. For example, if the direct response to the establishing request. For example, if the
establishing request stipulated a response that contained an event establishing request stipulated a response that contained an event
record list wherein affected SWID tags were indicated using SWID tag record list wherein affected software indicated using Software
identifier instances, all attributes sent in fulfillment of this Identifiers, all attributes sent in fulfillment of this subscription
subscription will also consist of event record lists expressed using will also consist of event record lists expressed using Software
SWID tag identifier instances. As such, all SWID Responses displayed Identifiers. As such, all SW Responses displayed in the exchange
in the exchange depicted in Figure 3 have the same format. A SWID depicted in Figure 3 have the same format. A SW Response generated
Response generated in fulfillment of an active subscription MUST be a in fulfillment of an active subscription MUST be a valid SW Response
valid SWID Response attribute according to all the rules outlined in attribute according to all the rules outlined in the preceding
the preceding sections. In other words, an attribute constructed in sections. In other words, an attribute constructed in fulfillment of
fulfillment of a subscription will look the same as an attribute sent a subscription will look the same as an attribute sent in direct
in direct response to an explicit request from a SWID-PV that had the response to an explicit request from a SW-PV that had the same
same request parameters and which arrived immediately after the given request parameters and which arrived immediately after the given
change event. There are a few special rules that expand on this change event. There are a few special rules that expand on this
guideline: guideline:
3.8.5.1. Subscriptions Reporting Inventories 3.6.5.1. Subscriptions Reporting Inventories
In the case that a SWID-PV subscribes to a SWID-PC requesting an In the case that a SW-PV subscribes to a SW-PC requesting an
inventory attribute whenever changes are detected (i.e. the EID in inventory attribute whenever changes are detected (i.e. the EID in
the establishing request is 0), then the SWID-PC MUST send the the establishing request is 0), then the SW-PC MUST send the
requested inventory whenever a relevant change is detected. (A requested inventory whenever a relevant change is detected. (A
"relevant change" is any change for untargeted requests, or a change "relevant change" is any change for untargeted requests, or a change
to an indicated SWID tag in a targeted request.) Upon detection of a to an indicated record in a targeted request.) Upon detection of a
relevant change for an active subscription, the SWID-PC sends the relevant change for an active subscription, the SW-PC sends the
appropriate inventory information as if it had just received the appropriate inventory information as if it had just received the
establishing request. Attributes sent in fulfillment of this establishing request. Attributes sent in fulfillment of this
subscription will probably have a large amount of redundancy, as the subscription will probably have a large amount of redundancy, as the
same tags are likely to be present in each of these SWID Attributes. same records are likely to be present in each of these SW Attributes.
The role of an inventory subscription is not to report tags just for The role of an inventory subscription is not to report records just
the items that changed - that is the role of a subscription that for the items that changed - that is the role of a subscription that
reports events (see Section 3.8.5.2). A SWID-PC MUST NOT exclude a reports events (see Section 3.6.5.2). A SW-PC MUST NOT exclude a
tag from an attribute sent in fulfillment of an inventory record from an attribute sent in fulfillment of an inventory
subscription simply because that tag was not involved in the subscription simply because that record was not involved in the
triggering event (although the tag might be excluded for other triggering event (although a record might be excluded for other
reasons, such as if the subscription is targeted - see reasons, such as if the subscription is targeted - see
Section 3.8.5.3). Section 3.6.5.3).
3.8.5.2. Subscriptions Reporting Events 3.6.5.2. Subscriptions Reporting Events
The way in which a SWID-PV indicates it wishes to establish a The way in which a SW-PV indicates it wishes to establish a
subscription requesting event records is by providing a non-zero EID subscription requesting event records is by providing a non-zero EID
in the SWID Request establishing the subscription (see in the SW Request establishing the subscription (see Section 3.5.1).
Section 3.6.1). However, when the SWID-PC constructs an attribute in However, when the SW-PC constructs an attribute in fulfillment of the
fulfillment of the subscription (other than the direct response to subscription (other than the direct response to the establishing
the establishing request), it MUST only include event records for the request), it MUST only include event records for the detected
detected change(s) that precipitated this response attribute. In change(s) that precipitated this response attribute. In other words,
other words, it MUST NOT send a complete list of all changes starting it MUST NOT send a complete list of all changes starting with the
with the indicated EID, up through the latest change, every time a indicated EID, up through the latest change, every time a new event
new event is detected. In effect, the EID in the establishing is detected. In effect, the EID in the establishing request is
request is treated as being updated every time an attribute is sent treated as being updated every time an attribute is sent in
in fulfillment of this subscription, such that a single event is not fulfillment of this subscription, such that a single event is not
reported twice in fulfillment of a single subscription. As such, reported twice in fulfillment of a single subscription. As such,
every SWID-PC MUST track the EID of the last event that triggered an every SW-PC MUST track the EID of the last event that triggered an
attribute for the given subscription. When the next event (or set of attribute for the given subscription. When the next event (or set of
events) is detected, the SWID-PC MUST only report events with later events) is detected, the SW-PC MUST only report events with EIDs
EIDs. In the case that the EID Epoch of the SWID-PC changes, the after the last reported event. In the case that the EID Epoch of the
SWID-PC MUST treat EID values in the new Epoch as being after all SW-PC changes, the SW-PC MUST treat EID values in the new Epoch as
EIDs assigned in the previous Epoch regardless of the relative being after all EIDs assigned in the previous Epoch regardless of the
numeric values of these EIDs. relative numeric values of these EIDs.
Note that while a subscription is active, the subscribing SWID-PV MAY Note that while a subscription is active, the subscribing SW-PV MAY
make other requests for event records that overlap with events that make other requests for event records that overlap with events that
are reported due to a subscription. Such requests are unaffected by are reported in fulfillment of a subscription. Such requests are
the presence of the subscription, nor is the subscription affected by unaffected by the presence of the subscription, nor is the
such requests. In other words, a given request will get the same subscription affected by such requests. In other words, a given
results back whether or not there was a subscription. Likewise, an request will get the same results back whether or not there was a
attribute sent in fulfillment of a subscription will contain the same subscription. Likewise, an attribute sent in fulfillment of a
information whether or not other requests had been received from the subscription will contain the same information whether or not other
SWID-PV. requests had been received from the SW-PV.
A SWID-PV needs to pay attention to the EID Epoch in these messages, A SW-PV needs to pay attention to the EID Epoch in these messages, as
as changes in the Epoch might create discontinuities in the SWID-PV's changes in the Epoch might create discontinuities in the SW-PV's
understanding of the endpoint's SWID tag collection state, as understanding of the endpoint's Software Inventory Evidence
discussed in Section 3.6.5. In particular, once the EID Epoch Collection state, as discussed in Section 3.5.5. In particular, once
changes, a SWID-PV is unable have confidence that it has a correct the EID Epoch changes, a SW-PV is unable have confidence that it has
understanding of the state of an endpoint's SWID tag collection until a correct understanding of the state of an endpoint's Software
after the SWID-PV collects a complete inventory. Inventory Evidence Collection until after the SW-PV collects a
complete inventory.
SWID-PCs MAY send partial lists of event records in fulfillment of a SW-PCs MAY send partial lists of event records in fulfillment of a
subscription. (See Section 3.6.4 for more on partial list of event subscription. (See Section 3.5.4 for more on partial list of event
records.) In the case that a SWID-PC sends a partial list of event records.) In the case that a SW-PC sends a partial list of event
records, it MUST immediately send the next consecutive partial list, records, it MUST immediately send the next consecutive partial list,
and continue doing so until it has sent the equivalent of the and continue doing so until it has sent the equivalent of the
complete list of event records. In other words, if the SWID-PC sends complete list of event records. In other words, if the SW-PC sends a
a partial list it does not wait for another change event to send partial list it does not wait for another change event to send
another SWID Response, but continues sending SWID Responses until it another SW Response, but continues sending SW Responses until it has
has sent all event records that would have been included in a sent all event records that would have been included in a complete
complete fulfillment of the subscription. fulfillment of the subscription.
3.8.5.3. Targeted Subscriptions 3.6.5.3. Targeted Subscriptions
Subscriptions MAY be targeted to only apply to tags that match a Subscriptions MAY be targeted to only apply to records that match a
given set of tag identifiers. In the case where changes are detected given set of Software Identifiers. In the case where changes are
that affect multiple tags, some matching the establishing request's detected that affect multiple records, some matching the establishing
tag identifiers and some not, the attribute sent in fulfillment of request's Software Identifiers and some not, the attribute sent in
the subscription MUST only include inventory or events (as fulfillment of the subscription MUST only include inventory or events
appropriate) for tags that match the establishing request's tag (as appropriate) for records that match the establishing request's
identifiers. The SWID-PC MUST NOT include non-matching tags in the Software Identifiers. The SW-PC MUST NOT include non-matching
attribute, even if those non-matching tags experienced change events records in the attribute, even if those non-matching records
that were co-temporal with change events on the matching tags. experienced change events that were co-temporal with change events on
the matching records.
In addition, a SWID-PC MUST send an attribute in fulfillment of a In addition, a SW-PC MUST send an attribute in fulfillment of a
targeted subscription only when changes to the endpoint's SWID tag targeted subscription only when changes to the endpoint's Software
collection impact one or more tags matching the subscription's Inventory Evidence Collection impact one or more records matching the
establishing request's tag identifiers. A SWID-PC MUST NOT send any subscription's establishing request's Software Identifiers. A SW-PC
attribute in fulfillment of a targeted subscription based on detected MUST NOT send any attribute in fulfillment of a targeted subscription
change to the endpoint's SWID tag collection that did not involve any based on detected change to the endpoint's Software Inventory
of the tags targeted by that subscription. Evidence Collection that did not involve any of the records targeted
by that subscription.
3.8.5.4. No Subscription Consolidation 3.6.5.4. No Subscription Consolidation
A SWID-PV MAY establish multiple subscriptions to a given SWID-PC. A SW-PV MAY establish multiple subscriptions to a given SW-PC. If
If this is the case, it is possible that a single change event on the this is the case, it is possible that a single change event on the
endpoint might require fulfillment by multiple subscriptions, and endpoint might require fulfillment by multiple subscriptions, and
that the information included in attributes that fulfill each of that the information included in attributes that fulfill each of
these subscriptions might overlap. The SWID-PC MUST send separate these subscriptions might overlap. The SW-PC MUST send separate
attributes for each established subscription that requires a response attributes for each established subscription that requires a response
due to the given event. Each of these attributes MUST contain all due to the given event. Each of these attributes MUST contain all
information required to fulfill that individual subscription, even if information required to fulfill that individual subscription, even if
that information is also sent in other attributes sent in fulfillment that information is also sent in other attributes sent in fulfillment
of other subscriptions at the same time. In other words, SWID-PCs of other subscriptions at the same time. In other words, SW-PCs MUST
MUST NOT attempt to combine information when fulfilling multiple NOT attempt to combine information when fulfilling multiple
subscriptions simultaneously, even if this results in some redundancy subscriptions simultaneously, even if this results in some redundancy
in the attributes sent to the SWID-PV. in the attributes sent to the SW-PV.
3.8.5.5. Delayed Subscription Fulfillment 3.6.5.5. Delayed Subscription Fulfillment
A SWID-PC MAY delay the fulfillment of a subscription following a A SW-PC MAY delay the fulfillment of a subscription following a
change event in the interest of waiting to see if additional change change event in the interest of waiting to see if additional change
events are forthcoming and, if so, conveying the relevant records events are forthcoming and, if so, conveying the relevant records
back to the SWID-PV in a single SWID Response attribute. This can back to the SW-PV in a single SW Response attribute. This can help
help reduce network bandwidth consumption between the SWID-PC and the reduce network bandwidth consumption between the SW-PC and the SW-PV.
SWID-PV. For example, consider a situation where 10 changes occur a For example, consider a situation where 10 changes occur a tenth of a
tenth of a second apart. If the SWID-PC does not delay in assembling second apart. If the SW-PC does not delay in assembling and sending
and sending SWID Response attributes, the SWID-PV will received 10 SW Response attributes, the SW-PV will receive 10 separate SW
separate SWID Response attributes over a period of 1 second. Response attributes over a period of 1 second. However, if the SW-PC
However, if the SWID-PC waits half a second after the initial event waits half a second after the initial event before assembling a SW
before assembling a SWID Response, the SWID-PV only receives two SWID Response, the SW-PV only receives two SW Response attributes over the
Response attributes over the same period of time. same period of time.
Note that the ability to consolidate events for a single subscription Note that the ability to consolidate events for a single subscription
over a given period of time does not contradict the rules in over a given period of time does not contradict the rules in
Section 3.8.5.4 prohibiting consolidation across multiple Section 3.6.5.4 prohibiting consolidation across multiple
subscriptions. When delaying fulfillment of subscriptions, SWID-PCs subscriptions. When delaying fulfillment of subscriptions, SW-PCs
are still required to fulfill each individual subscription are still required to fulfill each individual subscription
separately. Moreover, in the case that change events within the separately. Moreover, in the case that change events within the
delay window cancel each other out (e.g., a SWID tag is deleted and delay window cancel each other out (e.g., a record is deleted and
then re-added), the SWID-PC MUST still report each change event then re-added), the SW-PC MUST still report each change event rather
rather than just reporting the net effect of changes over the delay than just reporting the net effect of changes over the delay period.
period. In other words, delayed fulfillment can decrease the number In other words, delayed fulfillment can decrease the number of
of attributes send by the SWID-PC, but it does not reduce the total attributes send by the SW-PC, but it does not reduce the total number
number of change events reported. of change events reported.
SWID-PCs are not required to support delayed fulfillment of SW-PCs are not required to support delayed fulfillment of
subscriptions. However, in the case that the SWID-PC does support subscriptions. However, in the case that the SW-PC does support
delayed subscription fulfillment, it MUST be possible to configure delayed subscription fulfillment, it MUST be possible to configure
the SWID-PC to disable delayed fulfillment. In other words, parties the SW-PC to disable delayed fulfillment. In other words, parties
deploying SWID-PCs need to be allowed to disable delayed subscription deploying SW-PCs need to be allowed to disable delayed subscription
fulfillment in their SWID-PCs. The manner in which such fulfillment in their SW-PCs. The manner in which such configuration
configuration occurs is left to the discretion of implementers, occurs is left to the discretion of implementers, although
although implementers MUST protect the configuration procedure from implementers MUST protect the configuration procedure from
unauthorized tampering. In other words, there needs to be some unauthorized tampering. In other words, there needs to be some
assurance that unauthorized individuals are not able to introduce assurance that unauthorized individuals are not able to introduce
long delays in subscription fulfillment. long delays in subscription fulfillment.
3.9. Multiple Sources of SWID Tags 3.7. Multiple Sources of Software Inventory Evidence Records
As noted in Section 2.1, the SWID tags in an endpoint's SWID tag The records in an endpoint's software inventory evidence collection
collection might potentially come from multiple sources. For might potentially come from multiple sources. For example, records
example, SWID tags might be deposited on the file system and might be derived from ISO SWID tags deposited on the file system and
collected therefrom. SWID tags might also be dynamically generated collected therefrom. Records might also be generated by tools such
by tools such as software and package managers (e.g., RPM or YUM) or as software and package managers (e.g., RPM or YUM) or might be
might be dynamically translated from software discovery reports translated from software discovery reports.
expressed in some non-SWID format.
A SWID-PC is not required to identify every possible source of SWID A SW-PC is not required to identify every possible source of software
tags on its endpoint. Some SWID-PCs might be explicitly tied only to information on its endpoint. Some SW-PCs might be explicitly tied
one or a handful of SWID tag sources. SWID-PCs are not required to only to one or a handful of software inventory sources. For all
be aware of SWID tags that come from sources other than those that software inventory evidence sources that a particular SW-PC supports,
they specifically support. In particular, if an endpoint has 3 it MUST completely support all requirements of this specification
sources of SWID tags, and a SWID-PC supports collecting SWID tags with regard to those sources. In other words, for supported sources,
from two of those sources, not only is that SWID-PC only responsible the SW-PC is required to be capable of providing a complete set of
for reporting tags that come from its two supported sources, but it the provided software inventory evidence records; monitoring for
is also only responsible for monitoring for change events from those changes in the records reported by those sources, correctly providing
two sources. This noted, for all of the SWID tag sources that a responses for both full and targeted requests that include records
particular SWID-PC supports, it MUST completely support all from those sources, and providing either complete records or Software
requirements of this specification with regard to its supported Identifiers as appropriate. If the source's output is not in one of
sources. In other words, for supported sources, the SWID-PC is the data models identified in the Software Data Model IANA table (see
required to be capable of providing complete inventories of SWID Section 9.4), the SW-PC MUST be capable of converting that output
tags; monitoring for changes in the SWID collections reported by into one of the supported data models. In all cases, the SW-PC MUST
those sources, correctly providing responses for both full and also be capable of deriving a Software Identifier from the resulting
targeted requests, and providing either complete SWID tag files or record and also assigning that record a unique Record Identifier.
SWID identifier instances as appropriate. The SWID-PC MUST NOT The SW-PC MUST NOT provide any inventory or event information from
provide any inventory or event information from SWID tag sources for software inventory sources for which it cannot provide this full
which it cannot provide this full support. support.
The SWID Response attributes provide no way of distinguishing as to When providing a SW Response (either in direct response to a SW
which SWID tags, identifier instances, or event records are Request or in fulfillment of a subscription) the SW-PC MUST include
associated with specific sources. The SWID-PC MUST include the the complete set of relevant data from all supported sources of
complete set of relevant data from all supported sources of SWID tags software inventory evidence. In other words, a full inventory is
in every SWID Response. In other words, a full inventory is required required to contain all records from all supported sources, a
to contain all the SWID tags from all supported sources, a targeted targeted inventory is required to contain all relevant records from
inventory is required to contain all relevant tags from all sources, all sources, and event tracking is required to cover all events from
and event tracking is required to cover all events from both sources. all sources. With regard to events, a SW-PC's assignment of EIDs
With regard to events, a SWID-PC's assignment of EIDs MUST reflect MUST reflect the presence and order of all events on the endpoint (at
the presence and order of all events on the endpoint (at least for least for supported sources) regardless of the source. This means
supported sources) regardless of the source. This means that if that if source A experiences an event, and then source B experiences
source A experiences an event, and then source B experiences two two events, and then source A experiences another two events, the SW-
events, and then source A experiences another two events, the SWID-PC PC is required to capture five events with consecutive EID values
is required to capture five events with consecutive EID values
reflecting the order in which the events occur. reflecting the order in which the events occur.
Note that, if a SWID-PC collects data from multiple sources, it is Note that, if a SW-PC collects data from multiple sources, it is
possible that some software products might be "double counted". This possible that some software products might be "double counted". This
can happen if both sources of SWID tags provide a SWID tag for a can happen if both sources of inventory evidence provide a record for
single instance of a software product. Moreover, each of these a single installation of a software product. Moreover, each of these
provided tags will probably have different SWID tag identifier provided records might have different Software Identifiers. When a
instances, since Instance IDs are managed by the process that SW-PC reports information or records events from multiple inventory
extracts the SWID tags from the individual sources, and such evidence sources, it MUST use the information those sources provide,
processes are under no obligation to coordinate with each other as to rather than attempting to perform some form of reduction. In other
the Instance ID value. When a SWID-PC reports information or records words, if multiple sources report records corresponding to a single
events from multiple SWID tag sources, it MUST use the information installation of a software product, all such records from each source
those sources provide, rather than attempting to perform some form of are required to be part of the SW-PC's processing even if this might
reduction. In other words, if multiple sources report a particular lead to multiple reporting, and the SW-PC is not to ignore some
SWID tag corresponding to a single installation of a software records to avoid such multiple reporting. Similarly, in the case
product, all such tags from each source are required to be part of that multiple sources report an event, the SW-PC MUST create separate
the SWID-PC's processing even if this might lead to multiple event records with separate EIDs for each of these, even if there is
reporting, and the SWID-PC is not to ignore some tags to avoid such the chance that they represent the two sources reporting the same
multiple reporting. Similarly, in the case that multiple sources action on the endpoint. Entities tracking software inventory
report an event, the SWID-PC MUST create separate event records with information collected via SW-PCs and SW-PVs need to be aware that
separate EIDs for each of these, even if there is the chance that such double-reporting might occur. How (or if) such occurrences are
they represent the two sources reporting the same action on the detected and resolved is up to the implementers of those entities.
endpoint. Entities tracking SWID tags collected via SWID-PCs and
SWID-PVs need to be aware that such double-reporting might occur.
How (or if) such occurrences are detected and resolved is up to the
implementers of those entities.
3.10. Error Handling 3.8. Error Handling
In the case where the SWID-PC detects an error in a SWID Request In the case where the SW-PC detects an error in a SW Request
attribute that it receives it MUST respond with a PA-TNC Error attribute that it receives it MUST respond with a PA-TNC Error
attribute with an error code appropriate to the nature of the error. attribute with an error code appropriate to the nature of the error.
(See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC
Error attributes and error codes as well as Section 4.16 in this Error attributes and error codes as well as Section 4.16 in this
specification for error codes specific to SWID attributes.) In the specification for error codes specific to SW Attributes.) In the
cast that an error is detected in a SWID Request the SWID-PC MUST NOT case that an error is detected in a SW Request the SW-PC MUST NOT
take any action requested by this SWID Request, even if some take any action requested by this SW Request, even if partial
requested action can be completed successfully despite the error in completion of the SW is possible. In other words, a SW Request that
the attribute. In other words, a SWID Request that contains an error contains an error is completely ignored by the SW-PC (beyond sending
is ignored by the SWID-PC beyond sending a PA-TNC Error attribute, a PA-TNC Error attribute, and possibly logging the error locally)
and possibly logging the error locally. rather than being partially executed.
In the case where the SWID-PC receives a valid SWID Request attribute In the case where the SW-PC receives a valid SW Request attribute but
but experiences an error during the process of responding to that experiences an error during the process of responding to that
attribute's instructions where that error prevents the SWID-PC from attribute's instructions where that error prevents the SW-PC from
properly or completely fulfilling that request, the SWID-PC MUST send properly or completely fulfilling that request, the SW-PC MUST send a
a PA-TNC Error attribute with an error code appropriate to the nature PA-TNC Error attribute with an error code appropriate to the nature
of the error. In the case where a PA-TNC Error attribute is sent, of the error. In the case where a PA-TNC Error attribute is sent,
the SWID-PC MUST NOT take any of the actions requested by the SWID the SW-PC MUST NOT take any of the actions requested by the SW
Request attribute which led to the detected error. This is the case Request attribute which led to the detected error. This is the case
even if some actions can be completed successfully, and might even even if some actions could have been completed successfully, and
require the SWID-PC to reverse some successful actions already taken might even require the SW-PC to reverse some successful actions
before the error condition was detected. In other words, either all already taken before the error condition was detected. In other
aspects of a SWID Request complete fully and successfully (in which words, either all aspects of a SW Request complete fully and
case the SWID-PC sends a SWID Response attribute), or no aspects of successfully (in which case the SW-PC sends a SW Response attribute),
the SWID Request occur (in which case the SWID-PC sends a PA-TNC or no aspects of the SW Request occur (in which case the SW-PC sends
Error attribute). In the case that a SWID-PC sends a PA-TNC Error a PA-TNC Error attribute). In the case that a SW-PC sends a PA-TNC
attribute in response to a SWID Request then the SWID-PC MUST NOT Error attribute in response to a SW Request then the SW-PC MUST NOT
also send any SWID Response attribute in response to the same SWID also send any SW Response attribute in response to the same SW
Request. For this reason, the sending of a SWID Response attribute Request. For this reason, the sending of a SW Response attribute
MUST be the last action taken by a SWID-PC in response to a SWID MUST be the last action taken by a SW-PC in response to a SW Request
Request to avoid the possibility of a processing error occurring to avoid the possibility of a processing error occurring after that
after that SWID Response attribute is sent. SW Response attribute is sent.
In the case that the SWID-PC detects an error that prevents it from In the case that the SW-PC detects an error that prevents it from
properly or completely fulfilling its obligations under an active properly or completely fulfilling its obligations under an active
subscription, the SWID-PC MUST send a PA-TNC Error attribute of type subscription, the SW-PC MUST send a PA-TNC Error attribute of type
SWID_SUBSCRIPTION_FULFILLMENT_ERROR to the SWID-PV that established SW_SUBSCRIPTION_FULFILLMENT_ERROR to the SW-PV that established this
this subscription. This type of PA-TNC Error attribute identifies subscription. This type of PA-TNC Error attribute identifies the
the specific subscription that cannot be adequately honored due to specific subscription that cannot be adequately honored due to the
the error condition as well as an error "sub-type". The error sub- error condition as well as an error "sub-type". The error sub-type
type is used to indicate the type of error condition the SWID-PC is used to indicate the type of error condition the SW-PC experienced
experienced that prevented it from honoring the given subscription. that prevented it from honoring the given subscription. In the case
In the case that the error condition cannot be identified or does not that the error condition cannot be identified or does not align with
align with any of the defined error codes, the SWID_ERROR error code any of the defined error codes, the SW_ERROR error code SHOULD be
SHOULD be used in the sub-type. In the case that a used in the sub-type. In the case that a
SWID_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated SW_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated
subscription MUST be treated as cancelled by both the SWID-PC and subscription MUST be treated as cancelled by both the SW-PC and SW-
SWID-PV. PV.
The SWID-PV MUST NOT send any PA-TNC Error attributes to SWID-PCs. The SW-PV MUST NOT send any PA-TNC Error attributes to SW-PCs. In
In the case that a SWID-PV detects an error condition, it SHOULD log the case that a SW-PV detects an error condition, it SHOULD log this
this error but does not inform any SWID-PC's of this event. Errors error but does not inform any SW-PC's of this event. Errors might
might include, but are not limited to, detection of malformed SWID include, but are not limited to, detection of malformed SW Response
Response attributes sent from a given SWID-PC, as well as detection attributes sent from a given SW-PC, as well as detection of error
of error conditions when the SWID-PV processes SWID Responses. conditions when the SW-PV processes SW Responses.
Both SWID-PCs and SWID-PVs SHOULD log errors so that administrators Both SW-PCs and SW-PVs SHOULD log errors so that administrators can
can trace the causes of errors. Log messages SHOULD include the type trace the causes of errors. Log messages SHOULD include the type of
of the error, the time it was detected, and additional descriptive the error, the time it was detected, and additional descriptive
information to aid in understanding the nature and cause of the information to aid in understanding the nature and cause of the
error. error.
4. SWID Message and Attributes for PA-TNC Protocol 4. Software Message and Attributes for PA-TNC Protocol
This section describes the format and semantics of the SWID Message This section describes the format and semantics of the Software
and Attributes for PA-TNC protocol leveraging the existing SWID tag Message and Attributes for PA-TNC protocol. Software Message and
format. SWID Message and Attributes for PA-TNC uses the standard PA- Attributes for PA-TNC uses the standard PA-TNC message header format.
TNC message header format. See the PA-TNC specification [RFC5792] See the PA-TNC specification [RFC5792] for information on this header
for information on this header format. format.
4.1. PA Subtype (AKA PA-TNC Component Type) 4.1. PA Subtype (AKA PA-TNC Component Type)
The NEA PB-TNC interface provides a general message-batching protocol The NEA PB-TNC interface provides a general message-batching protocol
capable of carrying one or more PA-TNC messages between the Posture capable of carrying one or more PA-TNC messages between the Posture
Broker Client and Posture Broker Server. When PB-TNC is carrying a Broker Client and Posture Broker Server. When PB-TNC is carrying a
PA-TNC message, the PB-TNC message headers contain a 32 bit PA-TNC message, the PB-TNC message headers contain a 32 bit
identifier called the PA Subtype. The PA Subtype field indicates the identifier called the PA Subtype. The PA Subtype field indicates the
type of component associated with all of the PA-TNC attributes type of component associated with all of the PA-TNC attributes
carried by the PB-TNC message. The core set of PA Subtypes is carried by the PB-TNC message. The core set of PA Subtypes is
defined in the PA-TNC specification. In order for the NEA protocols defined in the PA-TNC specification. This specification adds the
to carry SWID tags, this specification adds the following enumeration following enumeration element to the table in section 7.2 of the PA-
element to the table in section 7.2 of the PA-TNC specification TNC specification [RFC5792] using the IETF Standard name space (SMI
[RFC5792] using the IETF Standard name space (SMI Private Enterprise Private Enterprise Number 0x000000):
Number 0x000000):
+-----+---------+----------------+----------------------------------+ +-----+---------+-------------+-------------------------------------+
| PEN | Integer | Name | Defining Specification | | PEN | Integer | Name | Defining Specification |
+-----+---------+----------------+----------------------------------+ +-----+---------+-------------+-------------------------------------+
| 0 | 9 | SWID | SWID Message and Attributes for | | 0 | 9 | SW | Software Message and Attributes for |
| | | Attributes | PA-TNC | | | | Attributes | PA-TNC |
+-----+---------+----------------+----------------------------------+ +-----+---------+-------------+-------------------------------------+
Table 2: PA Subtype Table 2: PA Subtype
Each PA-TNC attribute described in this specification is intended to Each PA-TNC attribute described in this specification is intended to
be sent between the SWID-PC and SWID-PV, so will be carried in a PB- be sent between the SW-PC and SW-PV, so will be carried in a PB-TNC
TNC message indicating a PA Subtype of SWID Attributes. Note that message indicating a PA Subtype of SW Attributes. Note that although
although the PA-TNC Error attribute is defined in the PA-TNC the PA-TNC Error attribute is defined in the PA-TNC specification,
specification, when it is used in a SWID Attribute exchange, it uses when it is used in a SW Attribute exchange, it uses the SW Attributes
the SWID Attributes Component Definition Value, as described in Component Definition Value, as described in Section 4.2.8 of the PA-
Section 4.2.8 of the PA-TNC specification [RFC5792]. PB-TNC messages TNC specification [RFC5792]. PB-TNC messages MUST always include the
MUST always include the SWID Attributes Subtype defined in this SW Attributes Subtype defined in this section when carrying SW
section when carrying SWID Attributes over PA-TNC. Attributes over PA-TNC.
4.2. PB-TNC and PA-TNC Messages 4.2. PB-TNC and PA-TNC Messages
A PA-TNC message is wrapped within a PB-TNC message. A single PA-TNC A PA-TNC message is wrapped within a PB-TNC message. A single PA-TNC
message might contain one or more PA-TNC attributes. All of these message might contain one or more PA-TNC attributes. All of these
attributes within a single PA-TNC message use the same PA Subtype attributes within a single PA-TNC message use the same PA Subtype
value. As such, SWID Attributes are never sent with attributes value. As such, SW Attributes are never sent in the same PA-TNC
defined in other PA-TNC binding specifications in a single PA-TNC message as attributes defined in other PA-TNC binding specifications.
message. Note, however, that a single PB-TNC batch might contain
multiple PB-TNC and PA-TNC messages, and each of those messages might Note, however, that a single PB-TNC batch might contain multiple PB-
use different PA Subtypes. TNC and PA-TNC messages, and each of those messages might use
different PA Subtypes.
For more information on PB-TNC and PA-TNC messages and message For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively. specifications, respectively.
4.3. PA-TNC Attribute Header 4.3. PA-TNC Attribute Header
The SWID Message and Attributes for PA-TNC protocol described in this The Software Message and Attributes for PA-TNC protocol described in
specification is an extension of the PA-TNC protocol described in the this specification is an extension of the PA-TNC protocol described
NEA Architecture. PA-TNC was designed to be very flexible in order in the NEA Architecture. PA-TNC was designed to be very flexible in
to carry many types of PA-TNC attributes that pertain to an order to carry many types of PA-TNC attributes that pertain to an
enumerated set of component types (e.g. Table 2). PA-TNC attributes enumerated set of component types (e.g. Table 2). PA-TNC attributes
might be carried from Posture Collector to Posture Validator or vice might be carried from Posture Collector to Posture Validator or vice
versa and might carry information about endpoint state or other versa and might carry information about endpoint state or other
information to be sent between a Posture Validator and a Posture information to be sent between a Posture Validator and a Posture
Collector. Therefore the SWID Message and Attributes for PA-TNC Collector. Therefore, the Software Message and Attributes for PA-TNC
specification defines a collection of PA-TNC attributes relevant to specification defines a collection of PA-TNC attributes relevant to
the collection and transmission of SWID tag inventories. the collection and transmission of software inventories and
associated events.
Figure 4, reproduced from the PA-TNC specification, shows the format Figure 4, reproduced from the PA-TNC specification, shows the format
of a PA-TNC attribute. Multiple PA-TNC attributes can be sent in a of a PA-TNC attribute. Multiple PA-TNC attributes can be sent in a
single PB-TNC message, each housed within an attribute structure as single PB-TNC message, each housed within an attribute structure as
described below. described below.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID | | Flags | PA-TNC Attribute Vendor ID |
skipping to change at page 45, line 23 skipping to change at page 38, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) | | Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PA-TNC Header and Attribute Format Figure 4: PA-TNC Header and Attribute Format
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Field | Description | | Field | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Flags | This field defines flags affecting the processing of | | Flags | This field defines flags affecting the processing of |
| | the SWID Message and Attributes for PA-TNC. | | | the Software Message and Attributes for PA-TNC. |
| | Permissible flags are given in the PA-TNC | | | Permissible flags are given in the PA-TNC |
| | specification. [RFC5792] | | | specification. [RFC5792] |
| | |
| Attribute | This field indicates the owner of the name space | | Attribute | This field indicates the owner of the name space |
| Type | associated with the Attribute Type. Attributes | | Type | associated with the Attribute Type. Attributes |
| Vendor ID | defined in the SWID Message and Attributes for PA-TNC | | Vendor ID | defined in the Software Message and Attributes for |
| | specification have a value corresponding to the IETF | | | PA-TNC specification have a value corresponding to |
| | SMI Private Enterprise Number value (0x000000). The | | | the IETF SMI Private Enterprise Number value |
| | PA-TNC Error attribute is defined in the PA-TNC | | | (0x000000). The PA-TNC Error attribute is defined in |
| | specification [RFC5792] and also uses the IETF SMI | | | the PA-TNC specification [RFC5792] and also uses the |
| | Private Enterprise Number Value (0x000000). See Table | | | IETF SMI Private Enterprise Number Value (0x000000). |
| | 4 for more information. | | | See Table 4 for more information. |
| | |
| Attribute | This field defines the type of the Attribute. The | | Attribute | This field defines the type of the Attribute. The |
| Type | values corresponding to SWID Attributes are given in | | Type | values corresponding to SW Attributes are given in |
| | Table 4. | | | Table 4. |
| | |
| Attribute | This field contains the length in octets of the | | Attribute | This field contains the length in octets of the |
| Length | entire Attribute, including the Attribute's header. | | Length | entire Attribute, including the Attribute's header. |
| Attribute | This field contains the SWID Attribute. | | | |
| Attribute | This field contains the SW Attribute. |
| Value | | | Value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 3: Fields of the PA-TNC Attribute Format Table 3: Fields of the PA-TNC Attribute Format
4.4. SWID Attribute Overview 4.4. SW Attribute Overview
The attributes defined in this specification appear below with a The attributes defined in this specification appear below with a
short summary of their purposes. Each attribute is described in short summary of their purposes. Each attribute is described in
greater detail in subsequent sections. greater detail in subsequent sections.
o SWID Request - This attribute is used to request a SWID tag o SW Request - This attribute is used to request a software
inventory or SWID event list from an endpoint. This attribute inventory or software event list from an endpoint. This attribute
might also establish a subscription on the recipient SWID-PC. A might also establish a subscription on the recipient SW-PC. A SW-
SWID-PC MUST NOT send this attribute. PC MUST NOT send this attribute.
o SWID Tag Identifier Inventory - This attribute is used to convey
an inventory expressed using SWID tag identifier instances
(instead of full tags). When a SWID-PC receives a SWID Request
attribute requesting an inventory using SWID tag identifier
instances, the SWID-PC MUST send a SWID Tag Identifier Inventory
attribute (or a PA-TNC Error) in response. This attribute also
MAY be sent by the SWID-PC in fulfillment of an active
subscription. A SWID-PV MUST NOT send this attribute.
o SWID Tag Identifier Events - This attribute is used to convey a o Software Identifier Inventory - This attribute is used to convey
list of events concerning changes to an endpoint's collection of an inventory expressed using Software Identifiers (instead of full
SWID tags. Affected SWID tags are indicated using SWID tag records). When a SW-PC receives a SW Request attribute requesting
identifier instances (instead of full tags). When a SWID-PC an inventory using Software Identifiers, the SW-PC MUST send a
receives a SWID Request attribute requesting an event collection Software Identifier Inventory attribute (or a PA-TNC Error) in
using with SWID tag identifier instances, the SWID-PC MUST send a response. This attribute also MAY be sent by the SW-PC in
SWID Tag Identifier Events attribute (or a PA-TNC Error) in fulfillment of an active subscription. A SW-PV MUST NOT send this
response. This attribute also MAY be sent by the SWID-PC in attribute.
fulfillment of an active subscription. A SWID-PV MUST NOT send
this attribute.
o SWID Tag Inventory - This attribute is used to convey an inventory o Software Identifier Events - This attribute is used to convey a
expressed using full SWID tags (instead of SWID tag identifier list of events concerning changes to an endpoint's Software
instances). When a SWID-PC receives a SWID Request attribute Inventory Evidence Collection. Affected software inventory
requesting an inventory using full SWID tags, the SWID-PC MUST evidence records are indicated using Software Identifiers (instead
send a SWID Tag Inventory attribute (or a PA-TNC Error) in of full records). When a SW-PC receives a SW Request attribute
response. This attribute also MAY be sent by the SWID-PC in requesting an event collection using Software Identifiers, the SW-
fulfillment of an active subscription. A SWID-PV MUST NOT send PC MUST send a Software Identifier Events attribute (or a PA-TNC
Error) in response. This attribute also MAY be sent by the SW-PC
in fulfillment of an active subscription. A SW-PV MUST NOT send
this attribute. this attribute.
o SWID Tag Events - This attribute is used to convey a list of o Software Inventory - This attribute is used to convey an inventory
events concerning changes to an endpoint's collection of SWID expressed using full software inventory evidence records (instead
tags. Affected SWID tags are indicated using full SWID tags of Software Identifiers). When a SW-PC receives a SW Request
(instead of SWID tag identifier instances). When a SWID-PC attribute requesting an inventory using full software inventory
receives a SWID Request attribute requesting an event collection evidence records, the SW-PC MUST send a Software Inventory
using full SWID tags, the SWID-PC MUST send a SWID Tag Events
attribute (or a PA-TNC Error) in response. This attribute also attribute (or a PA-TNC Error) in response. This attribute also
MAY be sent by the SWID-PC in fulfillment of an active MAY be sent by the SW-PC in fulfillment of an active subscription.
subscription. A SWID-PV MUST NOT send this attribute. A SW-PV MUST NOT send this attribute.
o Software Events - This attribute is used to convey a list of
events concerning changes to an endpoint's inventory evidence
collection. Affected software inventory evidence records are
indicated using full records (instead of Software Identifiers).
When a SW-PC receives a SW Request attribute requesting an event
collection using full records, the SW-PC MUST send a Software
Events attribute (or a PA-TNC Error) in response. This attribute
also MAY be sent by the SW-PC in fulfillment of an active
subscription. A SW-PV MUST NOT send this attribute.
o Subscription Status Request - This attribute is used to request a o Subscription Status Request - This attribute is used to request a
SWID-PC send a summary of all the active subscriptions it has SW-PC send a summary of all the active subscriptions it has where
where the requesting party is the subscriber. The SWID-PC MUST the requesting party is the subscriber. The SW-PC MUST respond
respond with a Subscription Status Response (or a PA-TNC Error). with a Subscription Status Response (or a PA-TNC Error). A SW-PC
A SWID-PC MUST NOT send this attribute. MUST NOT send this attribute.
o Subscription Status Response - This attribute is used to convey o Subscription Status Response - This attribute is used to convey
information about the active subscriptions that a SWID-PC has for information about the active subscriptions that a SW-PC has for a
a given subscriber. A SWID-PV MUST NOT send this attribute. given subscriber. A SW-PV MUST NOT send this attribute.
o PA-TNC Error - This is the standard PA-TNC Error attribute as o PA-TNC Error - This is the standard PA-TNC Error attribute as
defined in PA-TNC [RFC5792] and is used to indicate that an error defined in PA-TNC [RFC5792] and is used to indicate that an error
was encountered during a SWID Attribute exchange. It MUST be sent was encountered during a SW Attribute exchange. It MUST be sent
by a SWID-PC in response to a SWID Request in the case where the by a SW-PC in response to a SW Request in the case where the SW-PC
SWID-PC encounters a fatal error (i.e., an error that prevents encounters a fatal error (i.e., an error that prevents further
further processing of an exchange) relating to the attribute processing of an exchange) relating to the attribute exchange. A
exchange. A SWID-PV MUST NOT send this attribute. The SWID-PC SW-PV MUST NOT send this attribute. The SW-PC MUST then ignore
MUST then ignore the erroneous attribute after a PA-TNC Error the erroneous attribute after a PA-TNC Error attribute is sent
attribute is sent (i.e., do not attempt to act on an attribute (i.e., do not attempt to act on an attribute that generated a PA-
that generated a PA-TNC Error beyond sending the PA-TNC Error). TNC Error beyond sending the PA-TNC Error). In the case where the
In the case where the SWID-PV experiences a fatal error, it MUST SW-PV experiences a fatal error, it MUST ignore the erroneous
ignore the erroneous attribute without sending a PA-TNC Error attribute without sending a PA-TNC Error attribute. It MAY take
attribute. It MAY take other actions in response to the error, other actions in response to the error, such as logging the cause
such as logging the cause of the error, or even taking actions to of the error, or even taking actions to isolate the endpoint
isolate the endpoint
Because one of the SWID Tag Identifier Inventory, SWID Tag Identifier Because one of the Software Identifier Inventory, Software Identifier
Events, SWID Tag Inventory, or SWID Tag Events attributes is expected Events, Software Inventory, or Software Events attributes is expected
to be sent to a SWID-PV in direct response to a SWID Request to be sent to a SW-PV in direct response to a SW Request attribute or
attribute or in fulfillment of an active subscription, those four in fulfillment of an active subscription, those four attribute types
attribute types are frequently referred to collectively in this are referred to collectively in this document as "SW Response"
document as "SWID Response" attributes. attributes.
All SWID-PVs MUST be capable of sending SWID Requests and be capable All SW-PVs MUST be capable of sending SW Requests and be capable of
of receiving and processing all SWID Response attributes as well as receiving and processing all SW Response attributes as well as PA-TNC
PA-TNC Error attributes. All SWID-PCs MUST be capable of receiving Error attributes. All SW-PCs MUST be capable of receiving and
and processing SWID Requests and be capable of sending all types of processing SW Requests and be capable of sending all types of SW
SWID Response attributes as well as PA-TNC Error attributes. In Response attributes as well as PA-TNC Error attributes. In other
other words, both SWID-PVs and SWID-PCs are required to support their words, both SW-PVs and SW-PCs are required to support their role in
role in exchanges using any of the attribute types defined in this exchanges using any of the attribute types defined in this section.
section. SWID-PVs MUST ignore any SWID Request attributes that they SW-PVs MUST ignore any SW Request attributes that they receive. SW-
receive. SWID-PCs MUST ignore any SWID Response attributes or PA-TNC PCs MUST ignore any SW Response attributes or PA-TNC Error attributes
Error attributes that they receive. that they receive.
4.5. SWID Attribute Exchanges 4.5. SW Attribute Exchanges
A SWID Attribute Exchange is used to provide the SWID-PV with a SWID A SW Attribute Exchange is used to provide the SW-PV with a software
tag inventory or event collection from the queried endpoint. inventory or event collection from the queried endpoint.
+-------------+ +--------------+ +-------------+ +--------------+
| SWID-PC | | SWID-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
|<-----------SWID Request-------------| | |<------------SW Request--------------| |
| | | | | |
| SWID Response* | | | SW Response* | |
|-----------------or----------------->| | |-----------------or----------------->| |
| PA-TNC Error | | | PA-TNC Error | |
| | V | | V
*SWID Response is one of the following: SWID Tag Identifier *SW Response is one of the following: Software Identifier
Inventory, SWID Tag Identifier Events, SWID Tag Inventory, Inventory, Software Identifier Events, Software Inventory,
or SWID Tag Events. or Software Events.
Figure 5: SWID Attribute Exchange (Direct Response to SWID Request) Figure 5: SW Attribute Exchange (Direct Response to SW Request)
In this exchange, the SWID-PV indicates to the SWID-PC, via a SWID In this exchange, the SW-PV indicates to the SW-PC, via a SW Request,
Request, the nature of the information it wishes to receive the nature of the information it wishes to receive (inventory vs.
(inventory vs. events, full or targeted) and how it wishes the events, full or targeted) and how it wishes the returned inventory to
returned inventory to be expressed (full tags or tag identifier be expressed (full records or Software Identifiers). The SW-PC
instances). The SWID-PC responds with the requested information responds with the requested information using the appropriate
using the appropriate attribute type. A single SWID Request MUST attribute type. A single SW Request MUST only lead to a single SW
only lead to a single SWID Response or PA-TNC Error that is in direct Response or PA-TNC Error that is in direct response to that request.
response to that request.
In addition, if there is an active subscription on the endpoint, the In addition, if there is an active subscription on the endpoint, the
SWID-PC sends a SWID Response to the SWID-PV following a change event SW-PC sends a SW Response to the SW-PV following a change event on
on the endpoint in fulfillment of that subscription. Such an the endpoint in fulfillment of that subscription. Such an exchange
exchange is shown in Figure 6. is shown in Figure 6.
+-------------+ +--------------+ +-------------+ +--------------+
| SWID-PC | | SWID-PV | Time | SW-PC | | SW-PV | Time
+-------------+ +--------------+ | +-------------+ +--------------+ |
| | | | | |
<Change Event>| | | <Change Event>| | |
|-------SWID Response(s)*------>| | |--------SW Response(s)*------->| |
| | | | | |
*SWID Response is one of the following: SWID Tag Identifier *SW Response is one of the following: Software Identifier
Inventory, SWID Tag Identifier Events, SWID Tag Inventory, Inventory, Software Identifier Events, Software Inventory,
or SWID Tag Events. or Software Events.
Figure 6: SWID Attribute Exchange (In Fulfillment of an Active Figure 6: SW Attribute Exchange (In Fulfillment of an Active
Subscription) Subscription)
Note that, unlike direct responses to a SWID Request, a single change Note that, unlike direct responses to a SW Request, a single change
event can precipitate multiple SWID Responses, but only if all but event can precipitate multiple SW Responses for a single
the last of those SWID Responses convey partial lists of event subscription, but only if all but the last of those SW Responses
records, and the last of those SWID Responses conveys a complete list convey partial lists of event records, and the last of those SW
of event records. (That is, the initial responses are partial lists Responses conveys a complete list of event records. (That is, the
and the last response is the remainder of the relevant event records, initial responses are partial lists and the last response is the
completing the delivery of all relevant events at the time of the remainder of the relevant event records, completing the delivery of
change event.) A single Change Event MUST NOT be followed by all relevant events at the time of the change event.) A single
multiple SWID Response or PA-TNC Error attributes in any combination Change Event MUST NOT be followed by multiple SW Response or PA-TNC
except as noted earlier in this paragraph. Error attributes in any combination except as noted earlier in this
paragraph.
All SWID-PVs and SWID-PCs MUST support both exchanges. In All SW-PVs and SW-PCs MUST support both types of exchanges. In
particular, SWID-PCs MUST be capable of pushing a SWID Response to a particular, SW-PCs MUST be capable of pushing a SW Response to a SW-
SWID-PV immediately upon detection of a change to the endpoint's SWID PV immediately upon detection of a change to the endpoint's Software
tag collection in fulfillment of established SWID-PV subscriptions, Inventory Evidence Collection in fulfillment of established SW-PV
as described in Section 3.8. subscriptions, as described in Section 3.6.
4.6. SWID Message and Attributes for PA-TNC Attribute Enumeration 4.6. Software Message and Attributes for PA-TNC Attribute Enumeration
PA-TNC attribute types are identified in the PA-TNC Attribute Header PA-TNC attribute types are identified in the PA-TNC Attribute Header
(see Section 4.2) via the Attribute Type Vendor ID and Attribute Type (see Section 4.2) via the Attribute Type Vendor ID and Attribute Type
fields. Table 4 identifies the appropriate values for these fields fields. Table 4 identifies the appropriate values for these fields
for each attribute type used within the SWID Message and Attributes for each attribute type used within the Software Message and
for PA-TNC protocol. Attributes for PA-TNC protocol.
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
| Attribute | PEN | Integer | Description | | Attribute | PEN | Integer | Description |
| Name | | | | | Name | | | |
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
| SWID Request | 0x000000 | 0x00000011 | Request from a SWID-PV to | | SW Request | 0x000000 | 0x00000011 | Request from a SW-PV to a |
| | | | a SWID-PC for the SWID-PC | | | | | SW-PC for the SW-PC to |
| | | | to provide a SWID tag | | | | | provide a software |
| | | | inventory or event list | | | | | inventory or event list |
| SWID Tag | 0x000000 | 0x00000012 | A collection of SWID tag | | | | | |
| Identifier | | | identifier instances sent | | Software | 0x000000 | 0x00000012 | A collection of Software |
| Inventory | | | from a SWID-PC. | | Identifier | | | Identifiers sent from a |
| SWID Tag | 0x000000 | 0x00000013 | A collection of events | | Inventory | | | SW-PC. |
| | | | |
| Software | 0x000000 | 0x00000013 | A collection of events |
| Identifier | | | impacting the endpoint's | | Identifier | | | impacting the endpoint's |
| Events | | | SWID tag collection, where | | Events | | | Software Inventory |
| | | | impacted SWID tags are | | | | | Evidence Collection, where |
| | | | indicated using SWID tag | | | | | impacted software |
| | | | identifier instances. | | | | | inventory evidence records |
| SWID Tag | 0x000000 | 0x00000014 | A collection of SWID tags | | | | | are indicated using |
| Inventory | | | sent from a SWID-PC. | | | | | Software Identifiers. |
| SWID Tag | 0x000000 | 0x00000015 | A collection of events | | | | | |
| Software | 0x000000 | 0x00000014 | A collection of software |
| Inventory | | | inventory evidence records |
| | | | sent from a SW-PC. |
| | | | |
| Software | 0x000000 | 0x00000015 | A collection of events |
| Events | | | impacting the endpoint's | | Events | | | impacting the endpoint's |
| | | | SWID tag collection, where | | | | | Software Inventory |
| | | | impacted SWID tags are | | | | | Evidence Collection, where |
| | | | indicated using full SWID | | | | | impacted software |
| | | | tags. | | | | | inventory evidence records |
| | | | are indicated using full |
| | | | records. |
| | | | |
| Subscription | 0x000000 | 0x00000016 | A request for a list of a | | Subscription | 0x000000 | 0x00000016 | A request for a list of a |
| Status | | | SWID-PV's active | | Status | | | SW-PV's active |
| Request | | | subscription. | | Request | | | subscription. |
| Subscription | 0x000000 | 0x00000017 | A list of a SWID-PV's | | | | | |
| Status | | | active subscriptions. | | Subscription | 0x000000 | 0x00000017 | A list of a SW-PV's active |
| Status | | | subscriptions. |
| Response | | | | | Response | | | |
| | | | |
| Reserved | 0x000000 | 0x00000018 | These attribute types are | | Reserved | 0x000000 | 0x00000018 | These attribute types are |
| | | - | reserved for future use in | | | | - | reserved for future use in |
| | | 0x0000001F | revisions to SWID Message | | | | 0x0000001F | revisions to Software |
| | | | and Attributes for PA-TNC. | | | | | Message and Attributes for |
| | | | PA-TNC. |
| | | | |
| PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as | | PA-TNC Error | 0x000000 | 0x00000008 | An error attribute as |
| | | | defined in the PA-TNC | | | | | defined in the PA-TNC |
| | | | specification [RFC5792]. | | | | | specification [RFC5792]. |
+--------------+----------+------------+----------------------------+ +--------------+----------+------------+----------------------------+
Table 4: SWID Attribute Enumeration Table 4: SW Attribute Enumeration
4.7. Normalization of Text Encoding 4.7. Normalization of Text Encoding
SWID tags do not have a required encoding format. The 2009 ISO SWID
specification states that "For encoding purposes, the use of utf-8 is
the suggested methodology for software identification tags...", but
leaves implementers free to use different encodings if this makes
sense in their local environment. As such, implementers of the SWID
Message and Attributes for PA-TNC specification cannot assume any
specific encoding of SWID tag fields (although, in most current
examples of SWID tags, SWID tag creators have followed the suggestion
of using UTF-8 encodings). Similarly, sometimes the SWID Message and
Attributes for PA-TNC specification requires the use of data taken
from other sources, such a path from the endpoint's file system, and
different platforms might use different encodings for this
information. In order to ensure the ability to consistently and
reliably compare information sent using the SWID Message and
Attributes for PA-TNC exchange, certain field values (identified
explicitly in the attribute definitions in the following sections)
are required to undergo normalization prior to their inclusion in an
attribute.
In order to ensure consistency of transmitted attributes, a field In order to ensure consistency of transmitted attributes, a field
requiring normalization, as indicated in its description, and only requiring normalization, as indicated in its description, MUST be
such fields MUST be normalized to Network Unicode format as defined normalized to Network Unicode format as defined in RFC 5198
in RFC 5198 [RFC5198]. Network Unicode format defines a refinement [RFC5198]. Network Unicode format defines a refinement of UTF-8 that
of UTF-8 that ensures a normalized expression of characters. SWID- ensures a normalized expression of characters. SW-PCs and SW-PVs
PCs and SWID-PVs MUST NOT perform conversion and normalization on any MUST NOT perform conversion and normalization on any field values
field values except those specifically identified in the following except those specifically identified as requiring normalization in
sections. the following sections. Note, however, that some data models require
additional normalization before source information is added to an
Endpoint's Inventory Evidence Collection as a record. The references
from the Software Data Model IANA table (see section Section 9.4 will
note where this is necessary.
4.8. Request IDs 4.8. Request IDs
All SWID Request attributes MUST include a Request ID value. The All SW Request attributes MUST include a Request ID value. The
Request ID field provides a value that identifies a given request Request ID field provides a value that identifies a given request
relative to other requests between a SWID-PV and the receiving SWID- relative to other requests between a SW-PV and the receiving SW-PC.
PC. Specifically, the SWID-PV assigns each SWID Request attribute a Specifically, the SW-PV assigns each SW Request attribute a Request
Request ID value that is intended to be unique within the lifetime of ID value that is intended to be unique within the lifetime of a given
a given network connection ID as assigned by the SWID-PV's Posture network connection ID as assigned by the SW-PV's Posture Broker
Broker Server. In the case where all possible Request ID values have Server. In the case where all possible Request ID values have been
been exhausted within the lifetime of a single network connection ID, exhausted within the lifetime of a single network connection ID, the
the sender MAY reuse previously used Request IDs within the same sender MAY reuse previously used Request IDs within the same network
network connection that are not being used as Subscription IDs. (See connection that are not being used as Subscription IDs. (See below
below in this section for an explanation of Subscription ID in this section for an explanation of Subscription ID assignment.)
assignment.) In this case of Request ID reuse, Request IDs SHOULD be In this case of Request ID reuse, Request IDs SHOULD be reused in the
reused in the order of their original use. For example, if a Request order of their original use. For example, if a Request ID of X was
ID of X was the first Request ID used within a particular network the first Request ID used within a particular network connection and
connection and if the Request IDs are exhausted, X will be the first if the Request IDs are exhausted, X will be the first reused Request
reused Request ID. In other words, a SWID-PC SHOULD NOT use a given ID. In other words, a SW-PC SHOULD NOT use a given Request ID value
Request ID value more than once within a persistent connection more than once within a persistent connection between a given Posture
between a given Posture Broker Client-Posture Broker Server pair, Broker Client-Posture Broker Server pair, but, in the case where
but, in the case where reuse is necessary due to exhaustion of reuse is necessary due to exhaustion of possible ID values, the SW-PC
possible ID values, the SWID-PC SHOULD structure the reuse to SHOULD structure the reuse to maximize the time between original and
maximize the time between original and subsequent use. The Request subsequent use. The Request ID value is included in a SW Response
ID value is included in a response attribute directly responding to attribute directly responding to this SW Request to indicate which SW
this SWID Request to indicate which SWID Request was received and Request was received and caused the response. Request IDs can be
caused the response. Request IDs can be randomly generated or randomly generated or sequential, as long as values are not repeated
sequential, as long as values are not repeated per the rules in this per the rules in this paragraph. SW-PCs are not required to check
paragraph. SWID-PCs are not required to check for duplicate Request for duplicate Request IDs.
IDs.
In the case that a SWID Request requests the establishment of a In the case that a SW Request requests the establishment of a
subscription and the receiving SWID-PC agrees to that subscription, subscription and the receiving SW-PC agrees to that subscription, the
the Request ID of that SWID Request (i.e., the establishing request Request ID of that SW Request (i.e., the establishing request of the
of the subscription) becomes that subscription's Subscription ID. subscription) becomes that subscription's Subscription ID. All
All attributes sent in fulfillment of this subscription include a attributes sent in fulfillment of this subscription include a flag
flag indicating that the attribute fulfills a subscription and the indicating that the attribute fulfills a subscription and the
subscription's Subscription ID. A SWID-PV MUST NOT reuse a Request subscription's Subscription ID. A SW-PV MUST NOT reuse a Request ID
ID value in communicating to a given SWID-PC while that Request ID is value in communicating to a given SW-PC while that Request ID is also
also serving as a Subscription ID for an active subscription with serving as a Subscription ID for an active subscription with that SW-
that SWID-PC. In the case where a SWID-PC receives a SWID Request PC. In the case where a SW-PC receives a SW Request from a given SW-
from a given SWID-PV where that Request ID is also the Subscription PV where that Request ID is also the Subscription ID of an active
ID of an active subscription with that SWID-PV, the SWID-PC MUST subscription with that SW-PV, the SW-PC MUST respond with a PA-TNC
respond with a PA-TNC Error attribute with an error code of Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR.
SWID_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not Note that this error does not cancel the indicated subscription.
cancel the indicated subscription.
Subscription Status Requests and Subscription Status Responses do not Subscription Status Requests and Subscription Status Responses do not
include Request IDs. include Request IDs.
4.9. SWID Request 4.9. SW Request
A SWID-PV sends this attribute to a SWID-PC to request that the SWID- A SW-PV sends this attribute to a SW-PC to request that the SW-PC
PC send SWID tag-based information to the SWID-PV. A SWID-PC MUST send software inventory information to the SW-PV. A SW-PC MUST NOT
NOT send this attribute. send this attribute.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tag ID Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID | | Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Creator Length | Tag Creator (variable length) | | Software Identifier Length | Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SWID Request Attribute Figure 7: SW Request Attribute
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Field | Description | | Field | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), the SWID-PC MUST delete all | | Flags: Bit 0 | If set (1), the SW-PC MUST delete all |
| - Clear | subscriptions established by the requesting SWID- | | - Clear | subscriptions established by the requesting SW-PV |
| Subscriptions | PV (barring any errors). | | Subscriptions | (barring any errors). |
| | |
| Flags: Bit 1 | If set (1), in addition to responding to the | | Flags: Bit 1 | If set (1), in addition to responding to the |
| - Subscribe | request as described, the SWID-PC MUST establish | | - Subscribe | request as described, the SW-PC MUST establish a |
| | a subscription with parameters matching those in | | | subscription with parameters matching those in |
| | the request attribute (barring any errors). | | | the request attribute (barring any errors). |
| Flags: Bit 2 | If unset (0), the SWID-PC's response MUST consist | | | |
| - Result Type | of complete SWID tags and thus the response MUST | | Flags: Bit 2 | If unset (0), the SW-PC's response MUST consist |
| | be a SWID Tag Inventory, a SWID Tag Events, or a | | - Result Type | of complete software inventory evidence records |
| | PA-TNC Error attribute. If set (1), the response | | | and thus the response MUST be a Software |
| | MUST consist of SWID tag identifier instances and | | | Inventory, a Software Events, or a PA-TNC Error |
| | thus the response MUST be a SWID Tag Identifier | | | attribute. If set (1), the response MUST consist |
| | Inventory, a SWID Tag Identifier Events, or a PA- | | | of Software Identifiers and thus the response |
| | TNC Error attribute. | | | MUST be a Software Identifier Inventory, a |
| | Software Identifier Events, or a PA-TNC Error |
| | attribute. |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set | | Flags: Bit | Reserved for future use. This field MUST be set |
| 3-7 - | to zero on transmission and ignored upon | | 3-7 - | to zero on transmission and ignored upon |
| Reserved | reception. | | Reserved | reception. |
| Tag ID Count | A 3-byte unsigned integer indicating the number | | | |
| | of tag identifiers that follow. If this value is | | Software | A 3-byte unsigned integer indicating the number |
| | non-zero, this is a targeted request, as | | Identifier | of Software Identifiers that follow. If this |
| | described in Section 3.4. This field is a 3-byte | | Count | value is non-zero, this is a targeted request, as |
| | unsigned integer. The Tag Creator Length, Tag | | | described in Section 3.3. The Software |
| | Creator, Unique Software ID Length, and Unique | | | Identifier Length and Software ID fields are |
| | Software ID fields are repeated, in order, the | | | repeated, in order, the number of times indicated |
| | number of times indicated in this field. In the | | | in this field. In the case where Software |
| | case where tag identifiers are present, the SWID- | | | Identifiers are present, the SW-PC MUST only |
| | PC MUST only respond with SWID tags or tag | | | respond with software inventory evidence records |
| | identifier instances that correspond to the | | | or Software Identifiers that correspond to the |
| | identifiers the SWID-PV provided in this | | | identifiers the SW-PV provided in this attribute |
| | attribute (or with a PA-TNC Error attribute). | | | (or with a PA-TNC Error attribute). This field |
| | This field value MAY be 0, in which case there | | | value MAY be 0, in which case there are no |
| | are no instances of the Tag Creator Length, Tag | | | instances of the Software Identifier Length and |
| | Creator, Unique Software ID Length, and Unique | | | Software ID fields. In this case, the SW-PV is |
| | Software ID fields. In this case, the SWID-PV is | | | indicating an interest in all software inventory |
| | indicating an interest in all SWID tags on the | | | evidence records on the endpoint (i.e., this is |
| | endpoint (i.e., this is not a targeted request). | | | not a targeted request). |
| Request ID | A value that uniquely identifies this SWID | | | |
| | Request from a particular SWID-PV. | | Request ID | A value that uniquely identifies this SW Request |
| Earliest EID | In the case where the SWID-PV is requesting SWID | | | from a particular SW-PV. |
| | events, this field contains the EID value of the | | | |
| | earliest event the SWID-PV wishes to have | | Earliest EID | In the case where the SW-PV is requesting |
| | reported. (Note - the report will be inclusive of | | | software events, this field contains the EID |
| | the event with this EID value.) In the case where | | | value of the earliest event the SW-PV wishes to |
| | the SWID-PV is requesting an inventory, then this | | | have reported. (Note - the report will be |
| | field MUST be 0. (0x00000000) In the case where | | | inclusive of the event with this EID value.) In |
| | this field is non-zero, the SWID-PV is requesting | | | the case where the SW-PV is requesting an |
| | events and the SWID-PC MUST respond using a SWID | | | inventory, then this field MUST be 0. |
| | Tag Events, SWID Tag Identifier Events, or a PA- | | | (0x00000000) In the case where this field is non- |
| | TNC Error attribute. In the case where this field | | | zero, the SW-PV is requesting events and the SW- |
| | is zero, the SWID-PV is requesting an inventory | | | PC MUST respond using a Software Events, Software |
| | and the SWID-PC MUST respond using a SWID Tag | | | Identifier Events, or a PA-TNC Error attribute. |
| | Inventory, a SWID Tag Identifier Inventory, or a | | | In the case where this field is zero, the SW-PV |
| | PA-TNC Error attribute. | | | is requesting an inventory and the SW-PC MUST |
| Tag Creator | A 2-byte unsigned integer indicating the length | | | respond using a Software Inventory, a Software |
| Length | in bytes of the Tag Creator field. | | | Identifier Inventory, or a PA-TNC Error |
| Tag Creator | A string containing the Tag Creator RegID value | | | attribute. |
| | from within a SWID tag. This field value MUST be | | | |
| | normalized to Network Unicode format, as | | Software | A 2-byte unsigned integer indicating the length |
| | described in Section 4.7. This string MUST NOT | | Identifier | in bytes of the Software ID field. |
| | be NULL terminated. |
| Unique | A 2-byte unsigned integer indicating the length |
| Software ID | in bytes of the Unique Software ID field. |
| Length | | | Length | |
| Unique | A string containing the Unique ID value from | | | |
| Software ID | within a SWID tag. This field value MUST be | | Software ID | A string containing the Software Identifier value |
| | normalized to Network Unicode format, as | | | from a software inventory evidence record. This |
| | described in Section 4.7. This string MUST NOT be | | | field value MUST be normalized to Network Unicode |
| | NULL terminated. | | | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
Table 5: SWID Request Attribute Fields Table 5: SW Request Attribute Fields
The SWID-PV sends the SWID Request attribute to a SWID-PC to request The SW-PV sends the SW Request attribute to a SW-PC to request the
the indicated information. Note that between the Result Type flag indicated information. Note that between the Result Type flag and
and the Earliest EID field, the SWID-PC is constrained to a single the Earliest EID field, the SW-PC is constrained to a single possible
possible SWID Response attribute type (or a PA-TNC Error attribute) SW Response attribute type (or a PA-TNC Error attribute) in its
in its response to the request. response to the request.
The Subscribe and Clear Subscription flags are used to manage The Subscribe and Clear Subscription flags are used to manage
subscriptions for the requesting SWID-PV on the receiving SWID-PC. subscriptions for the requesting SW-PV on the receiving SW-PC.
Specifically, an attribute with the Subscribe flag set seeks to Specifically, an attribute with the Subscribe flag set seeks to
establish a new subscription by the requesting SWID-PV to the given establish a new subscription by the requesting SW-PV to the given SW-
SWID-PC, while an attribute with the Clear Subscription flag seeks to PC, while an attribute with the Clear Subscription flag seeks to
delete all existing subscriptions by the requesting SWID-PV on the delete all existing subscriptions by the requesting SW-PV on the
given SWID-PC. Note that, in the latter case, only the subscriptions given SW-PC. Note that, in the latter case, only the subscriptions
associated with the Connection ID and, if available, the Posture associated with the Connection ID and the Posture Validator ID of the
Validator ID of the requester are deleted as described in requester are deleted as described in Section 3.6.3. A newly
Section 3.8.3. A newly established subscription has the parameters established subscription has the parameters outlined in the Request
outlined in the Request attribute. Specifically, the Result Type attribute. Specifically, the Result Type flag indicates the type of
flag indicates the type of result to send in fulfillment of the result to send in fulfillment of the subscription, the value of the
subscription, the value of the Earliest EID field indicates whether Earliest EID field indicates whether the fulfillment attributes list
the fulfillment attributes list inventories or events, and the fields inventories or events, and the fields describing Software Identifiers
describing tag identifiers (if present) indicate if and how a (if present) indicate if and how a subscription is targeted. In the
subscription is targeted. In the case that the SWID-PC is unable or case that the SW-PC is unable or unwilling to comply with the SW-PV's
unwilling to comply with the SWID-PV's request to establish or clear request to establish or clear subscriptions, the SW-PC MUST respond
subscriptions, the SWID-PC MUST respond with a PA-TNC Error attribute with a PA-TNC Error attribute with the SW_SUBSCRIPTION_DENIED_ERROR
with the SWID_SUBSCRIPTION_DENIED_ERROR error code. (Note that if error code. (Note that if the SW-PV requests that subscriptions be
the SWID-PV requests that subscriptions be cleared but has no cleared but has no existing subscriptions, this is not an error.)
existing subscriptions, this is not an error.)
An attribute requesting the establishment of a subscription is An attribute requesting the establishment of a subscription is
effectively doing double-duty, as it is a request for an immediate effectively doing double-duty, as it is a request for an immediate
response from the SWID-PC in addition to setting up the subscription. response from the SW-PC in addition to setting up the subscription.
A SWID-PC MUST send an appropriate response attribute to a request Assuming the SW-PC is willing to comply with the subscription it MUST
with the Subscribe flag set containing all requested information. send an appropriate response attribute to a request with the
The same is true of the Clear Subscription flag - the SWID-PC MUST Subscribe flag set containing all requested information. The same is
generate a response attribute without regard to the presence of this true of the Clear Subscription flag - assuming there is no error the
flag in addition to clearing its subscription list. SW-PC MUST generate a response attribute without regard to the
presence of this flag in addition to clearing its subscription list.
Both the Subscribe and Clear Subscription flags MAY be set in a Both the Subscribe and Clear Subscription flags MAY be set in a
single SWID Request attribute. In the case where this request is single SW Request attribute. In the case where this request is
successful, the end result MUST be equivalent to the SWID-PC clearing successful, the end result MUST be equivalent to the SW-PC clearing
its subscription list for the given SWID-PV first and then creating a its subscription list for the given SW-PV first and then creating a
new subscription in accordance with the request parameters. (In new subscription in accordance with the request parameters. (In
other words, do not first create the new subscription and then clear other words, do not first create the new subscription and then clear
all the subscriptions including the one that was just created.) In all the subscriptions including the one that was just created.) In
the case that the requested actions are successfully completed, the the case that the requested actions are successfully completed, the
SWID-PC MUST respond with a SWID Response attribute. (The specific SW-PC MUST respond with a SW Response attribute. (The specific type
type of SWID Response attribute depends on the Result Type and of SW Response attribute depends on the Result Type and Earliest EID
Earliest EID fields, as described above.) In the case where there is fields, as described above.) In the case where there is a failure
a failure that prevents some part this request from completing, the that prevents some part this request from completing, the SW-PC MUST
SWID-PC MUST NOT add a new subscription, MUST NOT clear the old NOT add a new subscription, MUST NOT clear the old subscriptions, and
subscriptions, and the SWID-PC MUST respond with a PA-TNC Error the SW-PC MUST respond with a PA-TNC Error attribute. In other
attribute. In other words, the SWID-PC MUST NOT partially succeed at words, the SW-PC MUST NOT partially succeed at implementing such a
implementing such a request; either both actions succeed, or neither request; either both actions succeed, or neither succeed.
succeed.
The Earliest EID field is used to indicate whether the SWID-PV is The Earliest EID field is used to indicate whether the SW-PV is
requesting an inventory or event list from the SWID-PC. A value of 0 requesting an inventory or event list from the SW-PC. A value of 0
(0x00000000) represents a request for inventory information. (0x00000000) represents a request for inventory information.
Otherwise, the SWID-PV is requesting event information. For Earliest Otherwise, the SW-PV is requesting event information. For Earliest
EID values other than 0, the SWID-PC's response MUST respond with EID values other than 0, the SW-PC's response MUST respond with event
event records, as described in Section 3.6. Note that the request records, as described in Section 3.5. Note that the request does not
does not identify a particular EID Epoch, since responses can only identify a particular EID Epoch, since responses can only include
include events in the SWID-PC's current EID Epoch. events in the SW-PC's current EID Epoch.
The Tag ID Count indicates the number of tag identifiers in the The Software Identifier Count indicates the number of Software
attribute. This number might be any value between 0 and 16,777,216, Identifiers in the attribute. This number might be any value between
inclusive. A single tag identifier is represented by four fields: 0 and 16,777,216, inclusive. A single Software Identifier is
Tag Creator Length, Tag Creator, Unique Software ID Length, and represented by fields: Software Identifier Length and Software ID.
Unique Software ID. The two length fields are used to indicate the The Software Identifier Length field indicates the number of bytes
number of bytes allocated to their corresponding string field. The allocated to Software ID field. The Software Identifier field
two string fields, Tag Creator and Unique Software ID, contain copies contains a Software Identifier as describe in Section 3.2. The
of the SWID tag's Tag Creator RegID and Unique ID values, presence of one or more Software Identifiers is used by the SW-PV to
respectively, converted and normalized to Network Unicode format, as indicate a targeted request, which seeks only inventories of or
described in Section 4.7. Note that there is no field to indicate a events affecting software corresponding to the given identifiers.
particular Instance ID. Thus, targeted requests request all The SW-PC MUST only respond with records that match the Software
instances of the indicated SWID tags. The presence of one or more Identifiers provided in the SW-PVs SW Request attribute.
tag identifiers is used by the SWID-PV to indicate a targeted
request, which seeks only inventories of or events affecting SWID
tags corresponding to the given identifiers. The SWID-PC MUST only
respond with tags that match the tag identifier structures provided
in the SWID-PVs SWID Request attribute (as described in
Section 3.3.3) and MUST include all instances of matching tags in its
response.
4.10. SWID Tag Identifier Inventory 4.10. Software Identifier Inventory
A SWID-PC sends this attribute to a SWID-PV to convey a list of the A SW-PC sends this attribute to a SW-PV to convey the inventory of
endpoint's SWID tags expressed using SWID tag identifier instances. the endpoint's Software Inventory Evidence Collection expressed using
This list might represent a complete inventory or a targeted list of Software Identifiers. This list might represent a complete inventory
tags, depending on the parameters in the SWID-PV's request. A SWID- or a targeted list of records, depending on the parameters in the SW-
PV MUST NOT send this attribute. The SWID-PC either sends this PV's request. A SW-PV MUST NOT send this attribute. The SW-PC
attribute in fulfillment of an existing subscription where the either sends this attribute in fulfillment of an existing
establishing request has a Result Type of 1 and the Earliest EID is subscription where the establishing request has a Result Type of 1
zero, or in direct response to a SWID Request attribute where the and the Earliest EID is zero, or in direct response to a SW Request
Result Type is 1 and the Earliest EID is zero. attribute where the Result Type is 1 and the Earliest EID is zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tag ID Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Creator Length | Tag Creator (variable length) | |Data Model Type| Software IdentifierLength |SW ID (var len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length | Instance ID (var length) | | Record ID Length | Record ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SWID Tag Identifier Inventory Attribute Figure 8: Software Identifier Inventory Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SWID Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| Tag ID Count | The number of tag identifier instances that | | | |
| | follow. This field is an unsigned integer. The Tag | | Software | The number of Software Identifiers that follow. |
| | Creator Length, Tag Creator, Unique Software ID | | Identifier | This field is an unsigned integer. The Data Model |
| | Length, Unique Software ID, Instance ID Length, | | Count | Type, Software Identifier Length, SW ID, Record ID |
| | and Instance ID fields are repeated, in order, the | | | Length, and Record ID fields are repeated, in |
| | number of times indicated in this field. This | | | order, the number of times indicated in this |
| | field value MAY be 0, in which case there are no | | | field. This field value MAY be 0, in which case |
| | instances of these fields. | | | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWID Request attribute from a SWID- | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | PV, this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SWID Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| Last EID | The EID of the last event recorded by the SWID-PC, | | | |
| | or 0 if the SWID-PC has no recorded events. This | | Last EID | The EID of the last event recorded by the SW-PC, |
| | or 0 if the SW-PC has no recorded events. This |
| | field is an unsigned 4-byte integer. | | | field is an unsigned 4-byte integer. |
| Tag Creator | A 2-byte unsigned integer indicating the length in | | | |
| Length | bytes of the Tag Creator field. | | Data Model | A 1-byte unsigned integer containing an identifier |
| Tag Creator | A string containing the Tag Creator RegID value | | Type | number from the Software Data Model IANA table |
| | from within a SWID tag. This field value MUST be | | | that identifies the data model of the reported |
| | normalized to Network Unicode format, as described | | | record. |
| | in Section 4.7. This string MUST NOT be NULL | | | |
| | terminated. | | Software | A 2-byte unsigned integer indicating the length in |
| Unique | A 2-byte unsigned integer indicating the length in | | Identifier | bytes of the SW ID field. |
| Software ID | bytes of the Unique Software ID field. |
| Length | | | Length | |
| Unique | A string containing the Unique ID value from | | | |
| Software ID | within a SWID tag. This field value MUST be | | SW ID | A string containing the Software Identifier value |
| | normalized to Network Unicode format, as described | | | from a software inventory evidence record. This |
| | in Section 4.7. This string MUST NOT be NULL | | | field value MUST be normalized to Network Unicode |
| | terminated. | | | format, as described in Section 4.7. This string |
| Instance ID | A 2-byte unsigned integer indicating the length in | | | MUST NOT be NULL terminated. |
| Length | bytes of the Instance ID field. | | | |
| Instance ID | A string containing the Instance ID of a given tag | | Record ID | A 2-byte unsigned integer indicating the length in |
| | instance. The exact value of this field depends on | | Length | bytes of the Record ID field. |
| | the party that provides this SWID tag. This field | | | |
| | value MUST be normalized to Network Unicode | | Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 6: SWID Tag Identifier Inventory Attribute Fields Table 6: Software Identifier Inventory Attribute Fields
In the case that this attribute is sent in fulfillment of a In the case that this attribute is sent in fulfillment of a
subscription, the Subscription Fulfillment bit MUST be set (1). In subscription, the Subscription Fulfillment bit MUST be set (1). In
the case that this attribute is sent in direct response to a SWID the case that this attribute is sent in direct response to a SW
Request, the Subscription Fulfillment bit MUST be unset (0). Note Request, the Subscription Fulfillment bit MUST be unset (0). Note
that the SWID response attribute sent in direct response to a SWID that the SW Response attribute sent in direct response to a SW
Request that establishes a subscription (i.e., a subscription's Request that establishes a subscription (i.e., a subscription's
establishing request) MUST be treated as a direct response to that establishing request) MUST be treated as a direct response to that SW
SWID Request (and thus the Subscription Fulfillment bit is unset). Request (and thus the Subscription Fulfillment bit is unset). SW
SWID Response attributes are only treated as being in fulfillment of Response attributes are only treated as being in fulfillment of a
a subscription (i.e., Subscription Fulfillment bit set) if they are subscription (i.e., Subscription Fulfillment bit set) if they are
sent following a change event, as shown in Figure 3. sent following a change event, as shown in Figure 3.
The Tag ID Count field indicates the number of tag identifier The Software Identifier Count field indicates the number of Software
instances present in this inventory. Each tag identifier instance is Identifiers present in this inventory. Each Software Identifier is
represented by a set of six fields: Tag Creator Length, Tag Creator, represented by a set of five fields: Data Model Type, Software
Unique Software ID Length, Unique Software ID, Instance ID Length, Identifier Length, SW ID, Record ID Length, and Record ID. These
and Instance ID. These six fields, collectively referred to as the fields will appear once for each reported record.
"Tag ID Fields", will appear once for each reported tag instance.
Note that an endpoint's SWID tag collection might contain multiple
instances of a single tag (i.e., multiple tag files with the same tag
identifier value). When this occurs, in the case where that tag is
reported, then the response MUST contain a set of Tag ID Fields for
each instance of that tag. (The tag might not be reported if the
SWID-PV made a targeted request that does not match that tag's tag
identifier.) For example, if an endpoint has three copies of tag X,
and the SWID-PV requests a full inventory, then the response is
required to include three sets of Tag ID Fields corresponding to the
three instances of that tag. Only the Instance ID fields are
different between these three instances.
When responding directly to a SWID Request attribute, the Request ID When responding directly to a SW Request attribute, the Request ID
Copy / Subscription ID field MUST contain an exact copy of the Copy / Subscription ID field MUST contain an exact copy of the
Request ID field from that SWID Request. When this attribute is sent Request ID field from that SW Request. When this attribute is sent
in fulfillment of an existing subscription on this Posture Collector, in fulfillment of an existing subscription on this Posture Collector,
then this field MUST contain the Subscription ID of the fulfilled then this field MUST contain the Subscription ID of the fulfilled
subscription. subscription.
The EID Epoch field indicates the EID Epoch of the Last EID value. The EID Epoch field indicates the EID Epoch of the Last EID value.
The Last EID field MUST contain the EID of the last recorded change The Last EID field MUST contain the EID of the last recorded change
event (see Section 3.6 for more about EIDs and recorded events) at event (see Section 3.5 for more about EIDs and recorded events) at
the time this inventory was collected. In the case where there are the time this inventory was collected. In the case where there are
no recorded change events at the time that this inventory was no recorded change events at the time that this inventory was
collected, this field MUST contain 0. These fields can be collected, this field MUST contain 0. These fields can be
interpreted to indicate that the provided inventory (be it full or interpreted to indicate that the provided inventory (be it full or
targeted) reflects the record of events on the endpoint after all targeted) reflects the record of events on the endpoint after all
changes up to and including this last event have been accounted for. changes up to and including this last event have been accounted for.
4.11. SWID Tag Identifier Events 4.11. Software Identifier Events
A SWID-PC sends this attribute to a SWID-PV to convey events where A SW-PC sends this attribute to a SW-PV to convey events where the
the affected SWID tags are expressed using SWID tag identifier affected records are expressed using Software Identifiers. A SW-PV
instances. A SWID-PV MUST NOT send this attribute. The SWID-PC MUST NOT send this attribute. The SW-PC either sends this attribute
either sends this attribute in fulfillment of an existing in fulfillment of an existing subscription where the establishing
subscription where the establishing request has a Result Type is 1 request has a Result Type is 1 and the Earliest EID is non-zero, or
and the Earliest EID is non-zero, or in direct response to a SWID in direct response to a SW Request attribute where the Result Type is
Request attribute where the Result Type is 1 and the Earliest EID is 1 and the Earliest EID is non-zero.
non-zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count | | Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 60, line 30 skipping to change at page 52, line 30
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Tag Creator Length |Tag Creator (v)| | Action |Data Model Type| Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length | Instance ID (var length) | |SW ID (var len)| Record ID Length |Record ID (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SWID Tag Identifier Events Attribute Figure 9: Software Identifier Events Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SWID Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | |
| Event Count | The number of events that are reported in this | | Event Count | The number of events that are reported in this |
| | attribute. This field is a 3-byte unsigned | | | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Tag Creator | | | integer. The EID, Timestamp, Action, Data Model |
| | Length, Tag Creator, Unique Software ID Length, | | | Type, Software Identifier Length, SW ID, Record ID |
| | Unique Software ID, Instance ID Length, and | | | Length, and Record ID fields are repeated, in |
| | Instance ID fields are repeated, in order, the | | | order, the number of times indicated in this |
| | number of times indicated in this field. (An | | | field. (An instance of these fields is referred to |
| | instance of these nine fields is referred to as an | | | as an "event record" in this attribute. Thus the |
| | "event record" in this attribute. Thus the Event | | | Event Count field indicates the number of event |
| | Count field indicates the number of event |
| | records.) This field value MAY be 0, in which case | | | records.) This field value MAY be 0, in which case |
| | there are no instances of these fields. | | | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWID Request attribute from a SWID- | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | PV, this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SWID Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| Last EID | The EID of the last event recorded by the SWID-PC, | | | |
| | or 0 if the SWID-PC has no recorded events. This | | Last EID | The EID of the last event recorded by the SW-PC, |
| | field contains the EID of the SWID-PC's last | | | or 0 if the SW-PC has no recorded events. This |
| | field contains the EID of the SW-PC's last |
| | recorded change event (which might or might not be | | | recorded change event (which might or might not be |
| | included as an event record in this attribute). | | | included as an event record in this attribute). |
| | |
| Last | The EID of the last event record that was | | Last | The EID of the last event record that was |
| Consulted | consulted when generating the event record list | | Consulted | consulted when generating the event record list |
| EID | included in this attribute. This is different from | | EID | included in this attribute. This is different from |
| | the Last EID field value if and only if this | | | the Last EID field value if and only if this |
| | attribute is conveying a partial list of event | | | attribute is conveying a partial list of event |
| | records. See Section 3.6.4 for more on partial | | | records. See Section 3.5.4 for more on partial |
| | list of event records. | | | list of event records. |
| | |
| EID | The EID of the event in this event record. | | EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this | | Timestamp | The timestamp associated with the event in this |
| | event record. This timestamps is the SWID-PC's | | | event record. This timestamps is the SW-PC's best |
| | best understanding of when the given event | | | understanding of when the given event occurred. |
| | occurred. Note that this timestamp might be an | | | Note that this timestamp might be an estimate. |
| | estimate. The Timestamp date and time MUST be | | | The Timestamp date and time MUST be represented as |
| | represented as an RFC 3339 [5] compliant ASCII | | | an RFC 3339 [5] compliant ASCII string in |
| | string in Coordinated Universal Time (UTC) time | | | Coordinated Universal Time (UTC) time with the |
| | with the additional restrictions that the 'T' | | | additional restrictions that the 'T' delimiter and |
| | delimiter and the 'Z' suffix MUST be capitalized | | | the 'Z' suffix MUST be capitalized and fractional |
| | and fractional seconds (time-secfrac) MUST NOT be | | | seconds (time-secfrac) MUST NOT be included. This |
| | included. This field conforms to the date-time | | | field conforms to the date-time ABNF production |
| | ABNF production from section 5.6 of RFC 3339 | | | from section 5.6 of RFC 3339 [RFC3339] with the |
| | [RFC3339] with the above restrictions. Leap | | | above restrictions. Leap seconds are permitted |
| | seconds are permitted and SWID-PVs MUST support | | | and SW-PVs MUST support them. The Timestamp |
| | them. The Timestamp string MUST NOT be NULL | | | string MUST NOT be NULL terminated or padded in |
| | terminated or padded in any way. The length of | | | any way. The length of this field is always 20 |
| | this field is always 20 octets. | | | octets. |
| | |
| Action | The type of event that is recorded in this event | | Action | The type of event that is recorded in this event |
| | record. Possible values are: 1 = CREATION - the | | | record. Possible values are: 1 = CREATION - the |
| | addition of a tag to the endpoint's SWID tag | | | addition of a record to the endpoint's Software |
| | collection; 2 = DELETION - the removal of a tag | | | Inventory Evidence Collection; 2 = DELETION - the |
| | from the endpoint's SWID tag collection; 3 = | | | removal of a record from the endpoint's Software |
| | ALTERATION - There was an alteration to a tag file | | | Inventory Evidence Collection; 3 = ALTERATION - |
| | within the endpoint's tag collection. All other | | | There was an alteration to a record within the |
| | values are reserved for future use and MUST NOT be | | | endpoint's Software Inventory Evidence Collection. |
| | used when sending attributes. In the case where a | | | All other values are reserved for future use and |
| | SWID-PV receives an event record that uses an | | | MUST NOT be used when sending attributes. In the |
| | action value other than the ones defined here, it | | | case where a SW-PV receives an event record that |
| | MUST ignore that event record but SHOULD process | | | uses an action value other than the ones defined |
| | other event records in this attribute as normal. | | | here, it MUST ignore that event record but SHOULD |
| Tag Creator | A 2-byte unsigned integer indicating the length in | | | process other event records in this attribute as |
| Length | bytes of the Tag Creator field of the tag affected | | | normal. |
| | by the described event. | | | |
| Tag Creator | A string containing the Tag Creator RegID value | | Data Model | A 1-byte unsigned integer containing an identifier |
| | from within the SWID tag affected by the described | | Type | number from the Software Data Model IANA table |
| | event. This field value MUST be normalized to | | | that identifies the data model of the reported |
| | Network Unicode format, as described in Section | | | record. |
| | 4.7. This string MUST NOT be NULL terminated. | | | |
| Unique | A 2-byte unsigned integer indicating the length in | | Software | A 2-byte unsigned integer indicating the length in |
| Software ID | bytes of the Unique Software ID field of the tag | | Identifier | bytes of the SW ID field. |
| Length | affected by the described event. | | Length | |
| Unique | A string containing the Unique ID value from | | | |
| Software ID | within the SWID tag affected by the described | | SW ID | A string containing the Software Identifier value |
| | event. This field value MUST be normalized to | | | from a software inventory evidence record. This |
| | Network Unicode format, as described in Section | | | field value MUST be normalized to Network Unicode |
| | 4.7. This string MUST NOT be NULL terminated. | | | format, as described in Section 4.7. This string |
| Instance ID | A 2-byte unsigned integer indicating the length in | | | MUST NOT be NULL terminated. |
| Length | bytes of the Instance ID field. | | | |
| Instance ID | A string containing the Instance ID of a given tag | | Record ID | A 2-byte unsigned integer indicating the length in |
| | instance. The exact value of this field depends on | | Length | bytes of the Record ID field. |
| | the party that provides this SWID tag. This field | | | |
| | value MUST be normalized to Network Unicode | | Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 7: Software Identifier Events Attribute Fields
Table 7: SWID Tag Identifier Events Attribute Fields The first few fields in the Software Identifier Events attribute
mirror those in the Software Identifier Inventory attribute. The
The first few fields in the SWID Tag Identifier Events attribute
mirror those in the SWID Tag Identifier Inventory attribute. The
primary difference is that, instead of conveying an inventory using primary difference is that, instead of conveying an inventory using
tag identifier instances, the attribute conveys zero or more event Software Identifiers, the attribute conveys zero or more event
records, including the EID, timestamp, action type, and tag records, consisting of the EID, timestamp, action type, data model
identifier instance of the affected tag. type, Software Identifier, and Record Identifier of the affected
software inventory evidence record.
With regard to the Timestamp field, it is important to note that With regard to the Timestamp field, it is important to note that
clock skew between the SWID-PC and SWID-PV as well as between clock skew between the SW-PC and SW-PV as well as between different
different SWID-PCs within an enterprise might make correlation of SW-PCs within an enterprise might make correlation of timestamp
timestamp values difficult. This specification does not attempt to values difficult. This specification does not attempt to resolve
resolve clock skew issues, although other mechanisms outside of this clock skew issues, although other mechanisms outside of this
specification do exist to reduce the impact of clock skew and make specification do exist to reduce the impact of clock skew and make
the timestamp more useful for such correlation. Instead, SWID the timestamp more useful for such correlation. Instead, Software
Message and Attributes for PA-TNC uses Timestamp value primarily as a Message and Attributes for PA-TNC uses Timestamp value primarily as a
means to indicate the amount of time between two events on a single means to indicate the amount of time between two events on a single
endpoint. For example, by taking the difference of the times for endpoint. For example, by taking the difference of the times for
when a SWID tag was removed and then subsequently re-added, one can when a record was removed and then subsequently re-added, one can get
get an indication as to how long the system was without the given tag an indication as to how long the system was without the given record
(and, thus without the associated software). Since this will involve (and, thus without the associated software). Since this will involve
comparison of timestamp values all originating on the same system, comparison of timestamp values all originating on the same system,
clock skew between the SWID-PC and SWID-PV is not an issue. However, clock skew between the SW-PC and SW-PV is not an issue. However, if
if the SWID-PC's clock was adjusted between two recorded events, it the SW-PC's clock was adjusted between two recorded events, it is
is possible for such a calculation to lead to incorrect possible for such a calculation to lead to incorrect understandings
understandings of the temporal distance between events. Users of of the temporal distance between events. Users of this field need to
this field need to be aware of the possibility for such occurrences. be aware of the possibility for such occurrences. In the case where
In the case where the Timestamp values of two events appear to the Timestamp values of two events appear to contradict the EID
contradict the EID ordering of those events (i.e., the later EID has ordering of those events (i.e., the later EID has an earlier
an earlier timestamp) the recipient MUST treat the EID ordering as timestamp) the recipient MUST treat the EID ordering as correct.
correct.
All event records in a Tag Identifier Events Attribute are required All event records in a Software Identifier Events Attribute are
to be part of the same EID Epoch. Specifically, all reported events required to be part of the same EID Epoch. Specifically, all
MUST have an EID from the same EID Epoch as each other, and which is reported events MUST have an EID from the same EID Epoch as each
the same as the EID Epoch of the Last EID and Last Consulted EID other, and which is the same as the EID Epoch of the Last EID and
values. The SWID-PC MUST NOT report events with EIDs from different Last Consulted EID values. The SW-PC MUST NOT report events with
EID Epochs. EIDs from different EID Epochs.
The Last Consulted EID field contains the EID of the last event The Last Consulted EID field contains the EID of the last event
record considered for inclusion in this attribute. If this attribute record considered for inclusion in this attribute. If this attribute
contains a partial event set (as described in Section 3.6.4) this contains a partial event set (as described in Section 3.5.4) this
field value will differ from that of the Last EID field; if this field value will differ from that of the Last EID field; if this
attribute contains a complete event set, the Last EID and Last attribute contains a complete event set, the Last EID and Last
Consulted EID values are identical. Consulted EID values are identical.
If multiple events are sent in a SWID Tag Identifier Events If multiple events are sent in a Software Identifier Events
attribute, the order in which they appear within the attribute is not attribute, the order in which they appear within the attribute is not
significant. The EIDs associated with them are used for ordering the significant. The EIDs associated with them are used for ordering the
indicated events appropriately. Also note that a single tag indicated events appropriately. Also note that a single Software
identifier instance might appear multiple times in an attribute, such Identifier might appear multiple times in an attribute, such as if
as if multiple events involving the associated tag were being multiple events involving the associated record were being reported.
reported.
4.12. SWID Tag Inventory 4.12. Software Inventory
A SWID-PC sends this attribute to a SWID-PV to convey a list of SWID A SW-PC sends this attribute to a SW-PV to convey a list of inventory
tags. A SWID-PV MUST NOT send this attribute. The SWID-PC either records. A SW-PV MUST NOT send this attribute. The SW-PC either
sends this attribute in fulfillment of an existing subscription where sends this attribute in fulfillment of an existing subscription where
the establishing request had a Result Type of 0 and the Earliest EID the establishing request had a Result Type of 0 and the Earliest EID
is zero, or in direct response to a SWID Request attribute where the is zero, or in direct response to a SW Request attribute where the
Result Type is 0 and the Earliest EID is zero. Result Type is 0 and the Earliest EID is zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tag Count | | Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID | | Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length | Instance ID (var length) | |Data Model Type| Record ID Length |Record ID (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Length | | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (Variable) | | Record (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SWID Tag Inventory Attribute Figure 10: Software Inventory Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SWID Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| Tag ID Count | The number of tags that follow. This field is a | | | |
| | 3-byte unsigned integer. The Instance ID Length, | | Record Count | The number of records that follow. This field is a |
| | Instance ID, Tag Length, and Tag fields are | | | 3-byte unsigned integer. The Data Model Type, |
| | repeated, in order, the number of times indicated | | | Record Identifier Length, Record ID, Record |
| | in this field. This field value MAY be 0 in which | | | Length, and Record fields are repeated, in order, |
| | case there are no instances of these fields. | | | the number of times indicated in this field. This |
| | field value MAY be 0 in which case there are no |
| | instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWID Request attribute from a SWID- | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | PV, this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SWID Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| Last EID | The EID of the last event recorded by the SWID-PC, | | | |
| | or 0 if the SWID-PC has no recorded events. This | | Last EID | The EID of the last event recorded by the SW-PC, |
| | or 0 if the SW-PC has no recorded events. This |
| | field is an unsigned 4-byte integer. | | | field is an unsigned 4-byte integer. |
| Instance ID | A 2-byte unsigned integer indicating the length in | | | |
| Length | bytes of the Instance ID field. | | Data Model | A 1-byte unsigned integer containing an identifier |
| Instance ID | A string containing the Instance ID of a given tag | | Type | number from the Software Data Model IANA table |
| | instance. The exact value of this field depends on | | | that identifies the data model of the reported |
| | the party that provides this SWID tag. This field | | | record. |
| | value MUST be normalized to Network Unicode | | | |
| Record ID | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Record ID field. |
| | |
| Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| Tag Len | This is a 4-byte unsigned integer indicating the | | | |
| | length of the following SWID tag in bytes. | | Record Len | This is a 4-byte unsigned integer indicating the |
| Tag | A SWID tag as a string. In the case where the | | | length of the following software inventory |
| | original SWID tag is not expressed using UTF-8 | | | evidence record in bytes. |
| | encoding, it MUST be converted and normalized to | | | |
| Record | A software inventory evidence record as a string. |
| | The record MUST be converted and normalized to |
| | Network Unicode format, as described in Section | | | Network Unicode format, as described in Section |
| | 4.7. However, in the case where the original SWID | | | 4.7. This string MUST NOT be NULL terminated. |
| | tag is expressed using UTF-8 encoding, the SWID |
| | tag MUST be copied to this field without |
| | modification, even if the original SWID tag does |
| | not conform fully to Network Unicode format. This |
| | string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 8: SWID Tag Inventory Attribute Fields Table 8: Software Inventory Attribute Fields
The SWID Tag Inventory attribute contains some number of SWID tags. The Software Inventory attribute contains some number of software
Given that the size of tags can vary considerably, the length of this inventory evidence records. Given that the size of records can vary
attribute is highly variable and, if transmitting a complete considerably, the length of this attribute is highly variable and, if
inventory, can be extremely large. Enterprises might wish to transmitting a complete inventory, can be extremely large.
constrain the use of SWID Tag Inventory attributes to targeted Enterprises might wish to constrain the use of Software Inventory
requests to avoid over-burdening the network unnecessarily. attributes to targeted requests to avoid over-burdening the network
unnecessarily.
Note that the Instance ID is included in this attribute along with When copying a software inventory evidence record into the Record
the tag. This is because, unlike the Tag Creator RegID and Unique ID field, the record MUST be converted and normalized to use Network
fields that make up the tag identifier, the Instance ID cannot always Unicode format prior to its inclusion in the record field.
be extracted from fields within a SWID tag. As such, in order to be
able to associate a tag file with a given tag identifier instance, it
is necessary to include the Instance ID value in the attribute.
When copying a SWID tag into the Tag field, conversion and 4.13. Software Events
normalization of the character encoding happens if and only if the
source SWID tag does not use UTF-8 encoding. In the case where the
source SWID tag is expressed using an encoding other than UTF-8, then
that tag MUST be converted and normalized to use Network Unicode
format prior to its inclusion in the tag field. However, in the case
where the source SWID tag is expressed in UTF-8, the source tag MUST
be copied to the Tag field without conversion or normalization. This
is true even if the source SWID tag uses UTF-8 but is not fully
conformant with Network Unicode format. This is done because any
conversion or normalization of a full SWID tag is likely to break any
cryptographic signatures included in the SWID tag. As such,
conversion only happens to ensure a SWID tag is readable for the
recipient (by ensuring it always uses UTF-8), but is otherwise
avoided if possible. Recipients of this attribute can always be
assured that the Tag field uses UTF-8 format, but cannot depend on
full Network Unicode format compliance.
4.13. SWID Tag Events A SW-PC sends this attribute to a SW-PV to convey a list of events
where the affected software inventory evidence records are expressed
using full records. A SW-PV MUST NOT send this attribute. The SW-PC
either sends this attribute in fulfillment of an existing
subscription where the establishing request has a Result Type of 0
and the Earliest EID is non-zero, or in direct response to a SW
Request attribute where the Result Type is 0 and the Earliest EID is
non-zero.
A SWID-PC sends this attribute to a SWID-PV to convey a list of Note that each record is reported along with its Record Identifier.
events where the affected SWID tags are expressed using full tags. A This can be used to link reported records to reported Software
SWID-PV MUST NOT send this attribute. The SWID-PC either sends this Identifier + Record Identifier pairs.
attribute in fulfillment of an existing subscription where the
establishing request has a Result Type of 0 and the Earliest EID is
non-zero, or in direct response to a SWID Request attribute where the
Result Type is 0 and the Earliest EID is non-zero.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count | | Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID | | Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | | EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 67, line 30 skipping to change at page 59, line 30
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Instance ID Length |Instance ID (v)| | Action |Data Model Type| Record ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Len | | Record Identifier (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (Variable) | | Record Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SWID Tag Events Attribute Figure 11: Software Events Attribute
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that this attribute is sent in | | Flags: Bit 0 | In the case that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set | | - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct | | Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SWID Request, this bit MUST be unset | | Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). | | | (0). |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set to | | Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. | | 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | | | Reserved | |
| | |
| Event Count | The number of events being reported in this | | Event Count | The number of events being reported in this |
| | attribute. This field is a 3-byte unsigned | | | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Instance ID | | | integer. The EID, Timestamp, Action, Data Model |
| | Length, Instance ID, Tag Length, and Tag fields | | | Type, Record Identifier Length, Record Identifier, |
| | are repeated, in order, the number of times | | | Record Length, and Record fields are repeated, in |
| | indicated in this field. (An instance of these | | | order, the number of times indicated in this |
| | five fields is referred to as an "event record" in | | | field. (An instance of these fields is referred to |
| | this attribute. Thus the Event Count field | | | as an "event record" in this attribute. Thus the |
| | indicates the number of event records.) This field | | | Event Count field indicates the number of event |
| | value MAY be 0, in which case there are no | | | records.) This field value MAY be 0, in which case |
| | instances of these fields. | | | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct | | Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWID Request attribute from a SWID- | | Copy / | response to a SW Request attribute from a SW-PV, |
| Subscription | PV, this field MUST contain an exact copy of the | | Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field from that SWID Request. In the | | ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment | | | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain | | | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being | | | the Subscription ID of the subscription being |
| | fulfilled by this attribute. | | | fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field is | | EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. | | | an unsigned 4-byte integer. |
| Last EID | The EID of the last event recorded by the SWID-PC, | | | |
| | or 0 if the SWID-PC has no recorded events. This | | Last EID | The EID of the last event recorded by the SW-PC, |
| | field contains the EID of the SWID-PC's last | | | or 0 if the SW-PC has no recorded events. This |
| | field contains the EID of the SW-PC's last |
| | recorded change event (which might or might not be | | | recorded change event (which might or might not be |
| | included as an event record in this attribute). | | | included as an event record in this attribute). |
| | |
| Last | The EID of the last event record that was | | Last | The EID of the last event record that was |
| Consulted | consulted when generating the event record list | | Consulted | consulted when generating the event record list |
| EID | included in this attribute. This is different from | | EID | included in this attribute. This is different from |
| | the Last EID field value if and only if this | | | the Last EID field value if and only if this |
| | attribute is conveying a partial list of event | | | attribute is conveying a partial list of event |
| | records. See Section 3.6.4 for more on partial | | | records. See Section 3.5.4 for more on partial |
| | list of event records. | | | list of event records. |
| | |
| EID | The EID of the event in this event record. | | EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this | | Timestamp | The timestamp associated with the event in this |
| | event record. This timestamps is the SWID-PC's | | | event record. This timestamp is the SW-PC's best |
| | best understanding of when the given event | | | understanding of when the given event occurred. |
| | occurred. Note that this timestamp might be an | | | Note that this timestamp might be an estimate. |
| | estimate. The Timestamp date and time MUST be | | | The Timestamp date and time MUST be represented as |
| | represented as an RFC 3339 [5] compliant ASCII | | | an RFC 3339 [5] compliant ASCII string in |
| | string in Coordinated Universal Time (UTC) time | | | Coordinated Universal Time (UTC) time with the |
| | with the additional restrictions that the 'T' | | | additional restrictions that the 'T' delimiter and |
| | delimiter and the 'Z' suffix MUST be capitalized | | | the 'Z' suffix MUST be capitalized and fractional |
| | and fractional seconds (time-secfrac) MUST NOT be | | | seconds (time-secfrac) MUST NOT be included. This |
| | included. This field conforms to the date-time | | | field conforms to the date-time ABNF production |
| | ABNF production from section 5.6 of RFC 3339 | | | from section 5.6 of RFC 3339 [RFC3339] with the |
| | [RFC3339] with the above restrictions. Leap | | | above restrictions. Leap seconds are permitted |
| | seconds are permitted and SWID-PVs MUST support | | | and SW-PVs MUST support them. The Timestamp |
| | them. The Timestamp string MUST NOT be NULL | | | string MUST NOT be NULL terminated or padded in |
| | terminated or padded in any way. The length of | | | any way. The length of this field is always 20 |
| | this field is always 20 octets. | | | octets. |
| | |
| Action | The type of event that is recorded in this event | | Action | The type of event that is recorded in this event |
| | record. Possible values are: 1 = CREATION - the | | | record. Possible values are: 1 = CREATION - the |
| | addition of a tag to the endpoint's SWID tag | | | addition of a record to the endpoint's Software |
| | collection; 2 = DELETION - the removal of a tag | | | Inventory Evidence Collection; 2 = DELETION - the |
| | from the endpoint's SWID tag collection; 3 = | | | removal of a record from the endpoint's Software |
| | ALTERATION - There was an alteration to a tag file | | | Inventory Evidence Collection; 3 = ALTERATION - |
| | within the endpoint's tag collection. All other | | | There was an alteration to a record within the |
| | values are reserved for future use and MUST NOT be | | | endpoint's Software Inventory Evidence Collection. |
| | used when sending attributes. In the case where a | | | All other values are reserved for future use and |
| | SWID-PV receives an event record that uses an | | | MUST NOT be used when sending attributes. In the |
| | action value other than the ones defined here, it | | | case where a SW-PV receives an event record that |
| | MUST ignore that event record but SHOULD process | | | uses an action value other than the ones defined |
| | other event records in this attribute as normal. | | | here, it MUST ignore that event record but SHOULD |
| Instance ID | A 2-byte unsigned integer indicating the length in | | | process other event records in this attribute as |
| Length | bytes of the Instance ID field. | | | normal. |
| Instance ID | A string containing the Instance ID of a given tag | | | |
| | instance. The exact value of this field depends on | | Data Model | A 1-byte unsigned integer containing an identifier |
| | the party that provides this SWID tag. This field | | Type | number from the Software Data Model IANA table |
| | value MUST be normalized to Network Unicode | | | that identifies the data model of the reported |
| | record. |
| | |
| Record ID | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Record ID field. |
| | |
| Record ID | A string containing the Record Identifier value |
| | from a software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string | | | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. | | | MUST NOT be NULL terminated. |
| Tag Len | This is a 4-byte unsigned integer indicating the | | | |
| | length of the following SWID tag in bytes. | | Record Len | This is a 4-byte unsigned integer indicating the |
| Tag | A SWID tag as a string. In the case where the | | | length of the following record in bytes. |
| | original SWID tag is not expressed using UTF-8 | | | |
| | encoding, it MUST be converted and normalized to | | Record | A software inventory evidence record as a string. |
| | The record MUST be converted and normalized to |
| | Network Unicode format, as described in Section | | | Network Unicode format, as described in Section |
| | 4.7. However, in the case where the original SWID | | | 4.7. This string MUST NOT be NULL terminated. |
| | tag is expressed using UTF-8 encoding, the SWID |
| | tag MUST be copied to this field without |
| | modification, even if the original SWID tag does |
| | not conform fully to Network Unicode format. This |
| | string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 9: SWID Tag Events Attribute Fields Table 9: Software Events Attribute Fields
The fields of this attribute are used in the same way as the The fields of this attribute are used in the same way as the
corresponding fields of the previous attributes. As with the SWID corresponding fields of the previous attributes. As with the
Tag Inventory attribute, a SWID Tag Events attribute can be quite Software Inventory attribute, a Software Events attribute can be
large if many events have occurred following the event indicated by a quite large if many events have occurred following the event
request's Earliest EID. As such, it is recommended that the SWID indicated by a request's Earliest EID. As such, it is recommended
Request attributes only request full tags be sent (Result Type set to that the SW Request attributes only request full records be sent
0) in a targeted request, thus constraining the response just to tags (Result Type set to 0) in a targeted request, thus constraining the
that match a given set of tag identifiers. response just to records that match a given set of Software
Identifiers.
As with the SWID Tag Identifier Events Attribute, this attribute MUST As with the Software Identifier Events Attribute, this attribute MUST
only contain event records with EIDs coming from the current EID only contain event records with EIDs coming from the current EID
Epoch of the SWID-PC. Epoch of the SW-PC.
As with the SWID Tag Inventory Attribute, the SWID-PC MUST perform As with the Software Inventory Attribute, the SW-PC MUST perform
conversion and normalization of the SWID tag itself in the case where conversion and normalization of the record.
the source SWID tag is expressed using an encoding other than UTF-8,
and MUST NOT perform conversion or normalization of the SWID tag
itself in the case where the source SWID tag is expressed using UTF-
8.
4.14. Subscription Status Request 4.14. Subscription Status Request
A SWID-PV sends this attribute to a SWID-PC to request a list of A SW-PV sends this attribute to a SW-PC to request a list of active
active subscriptions for which the requesting SWID-PV is the subscriptions for which the requesting SW-PV is the subscriber. A
subscriber. A SWID-PC MUST NOT send this attribute. SW-PC MUST NOT send this attribute.
This attribute has no fields. This attribute has no fields.
A SWID-PC MUST respond to this attribute by sending a Subscription A SW-PC MUST respond to this attribute by sending a Subscription
Status Response attribute (or a PA-TNC Error attribute if it is Status Response attribute (or a PA-TNC Error attribute if it is
unable to correctly provide a response). unable to correctly provide a response).
4.15. Subscription Status Response 4.15. Subscription Status Response
A SWID-PC sends this attribute to a SWID-P to report the list of A SW-PC sends this attribute to a SW-PV to report the list of active
active subscriptions for which the receiving SWID-PV is the subscriptions for which the receiving SW-PV is the subscriber. A SW-
subscriber. A SWID-PV MUST NOT send this attribute. PV MUST NOT send this attribute.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count | | Status Flags | Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tag ID Count | | Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID | | Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Creator Length | Tag Creator (variable length) | | Software Identifier Length | Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Subscription Status Response Attribute Figure 12: Subscription Status Response Attribute
+------------------+------------------------------------------------+ +-----------------+-------------------------------------------------+
| Field | Description | | Field | Description |
+------------------+------------------------------------------------+ +-----------------+-------------------------------------------------+
| Flags: Bit 0-7 - | Reserved for future use. This field MUST be | | Flags: Bit 0-7 | Reserved for future use. This field MUST be set |
| Reserved | set to zero on transmission and ignored upon | | - Reserved | to zero on transmission and ignored upon |
| | reception. | | | reception. |
| Subscription | The number of subscription records that | | | |
| Record Count | follow. This field is a 3-byte unsigned | | Subscription | The number of subscription records that follow. |
| | integer. The Flags, Tag ID Count, Request ID, | | Record Count | This field is a 3-byte unsigned integer. The |
| | Earliest EID, Tag Creator Length, Tag Creator, | | | Flags, Software Identifier Count, Request ID, |
| | Unique Software ID Length, and Unique Software | | | Earliest EID, Software Identifier Length, and |
| | ID fields are repeated, in order, the number | | | Software ID fields are repeated, in order, the |
| | of times indicated in this field. This field | | | number of times indicated in this field. This |
| | value MAY be 0 in which case there are no | | | field value MAY be 0 in which case there are no |
| | instances of these fields. | | | instances of these fields. |
| Flags, Tag ID | For each active subscription, these fields | | | |
| Count, Request | contain an exact copy of the fields with the | | Flags, Software | For each active subscription, these fields |
| ID, Earliest | same name as provided in the subscription's | | Identifier | contain an exact copy of the fields with the |
| EID, Tag Creator | establishing request. | | Count, Request | same name as provided in the subscription's |
| Length, Tag | | | ID, Earliest | establishing request. |
| Creator, Unique | | | EID, Software | |
| Software ID | | | Identifier | |
| Length, and | | | Length, and | |
| Unique Software | | | Software ID | |
| ID | | +-----------------+-------------------------------------------------+
+------------------+------------------------------------------------+
Table 10: Subscription Status Response Fields Table 10: Subscription Status Response Fields
A Subscription Status Response contains zero or more subscription A Subscription Status Response contains zero or more subscription
records. Specifically, it MUST contain one subscription record for records. Specifically, it MUST contain one subscription record for
each active subscription associated with the party that sent the each active subscription associated with the party that sent the
Subscription Status Request to which this attribute is a response. Subscription Status Request to which this attribute is a response.
As described in Section 3.8.2, the SWID-PC MUST use the requester's As described in Section 3.6.2, the SW-PC MUST use the requester's
Connection ID and, if available, its Posture Validator ID to Connection ID and its Posture Validator ID to determine which
determine which subscriptions are associated with the requester. subscriptions are associated with the requester.
A SWID-PC MUST send a Subscription Status Response attribute in A SW-PC MUST send a Subscription Status Response attribute in
response to a Subscription Status Request attribute. The only response to a Subscription Status Request attribute. The only
exception to this is if the SWID-PC experiences an error condition exception to this is if the SW-PC experiences an error condition that
that prevents it from correctly populating the Subscription Status prevents it from correctly populating the Subscription Status
Response attribute, in which case it MUST respond with a PA-TNC Error Response attribute, in which case it MUST respond with a PA-TNC Error
attribute appropriate to the type of error experienced. If there are attribute appropriate to the type of error experienced. If there are
no active subscriptions associated with the requesting party, the no active subscriptions associated with the requesting party, the
Subscription Status Response attribute will consist of its Status Subscription Status Response attribute will consist of its Status
Flags field, a Subscription Record Count field with a value of 0, and Flags field, a Subscription Record Count field with a value of 0, and
no additional fields. no additional fields.
Each subscription record included in a Subscription Status Response Each subscription record included in a Subscription Status Response
attribute duplicates the fields of a SWID Request attribute that was attribute duplicates the fields of a SW Request attribute that was
the establishing request of a subscription. Note that the Request ID the establishing request of a subscription. Note that the Request ID
field in the record captures the Subscription ID associated with the field in the record captures the Subscription ID associated with the
given subscription record (since the Subscription ID is the same as given subscription record (since the Subscription ID is the same as
the Request ID of the establishing request). Note also that if the the Request ID of the establishing request). Note also that if the
establishing request is targeted, then its Tag ID Count field will be establishing request is targeted, then its Record Count field will be
non-zero and, within that subscription record, the Tag Creator non-zero and, within that subscription record, the Record Namespace
Length, Tag Creator, Unique Software ID Length, and Unique Software Length, Record Namespace, Record ID Length, and Record ID fields are
ID fields are repeated, in order, the number of times indicated in repeated, in order, the number of times indicated in the Record Count
the Tag ID Count field. As such, each subscription record can be field. As such, each subscription record can be different sizes. If
different sizes. Likewise, if the establishing request is not the establishing request is not targeted (Record Count field is 0),
targeted (Tag ID Count field is 0), the subscription record has no the subscription record has no Record Namespace Length, Record
Tag Creator Length, Tag Creator, Unique Software ID Length, or Unique Namespace, Record ID Length, or Record ID fields.
Software ID fields.
When a SWID-PV compares the information received in a Subscription When a SW-PV compares the information received in a Subscription
Status Response to its own records of active subscriptions it should Status Response to its own records of active subscriptions it should
be aware that the SWID-PC might be unable to distinguish this SWID-PV be aware that the SW-PC might be unable to distinguish this SW-PV
from other SWID-PVs on the same NEA Server. As a result, it is from other SW-PVs on the same NEA Server. As a result, it is
possible that the SWID-PC will report more subscription records than possible that the SW-PC will report more subscription records than
the SWID-PV recognizes. For this reason, SWID-PVs SHOULD NOT the SW-PV recognizes. For this reason, SW-PVs SHOULD NOT
automatically assume that extra subscriptions reported in a automatically assume that extra subscriptions reported in a
Subscription Status Response indicate a problem. Subscription Status Response indicate a problem.
4.16. PA-TNC Error as Used by SWID Message and Attributes for PA-TNC 4.16. PA-TNC Error as Used by Software Message and Attributes for PA-
TNC
The PA-TNC Error attribute is defined in the PA-TNC specification The PA-TNC Error attribute is defined in the PA-TNC specification
[RFC5792], and its use here conforms to that specification. A PA-TNC [RFC5792], and its use here conforms to that specification. A PA-TNC
Error can be sent due to any error in the PA-TNC exchange and might Error can be sent due to any error in the PA-TNC exchange and might
also be sent in response to error conditions specific to the SWID also be sent in response to error conditions specific to the Software
Message and Attributes for PA-TNC exchange. The latter case utilizes Message and Attributes for PA-TNC exchange. The latter case utilizes
error codes defined below. error codes defined below.
A PA-TNC Error attribute is sent instead of a SWID Response attribute A PA-TNC Error attribute is sent instead of a SW Response attribute
due to factors that prevent the reliable creation of a SWID Response. due to factors that prevent the reliable creation of a SW Response.
As such, a SWID-PC MUST NOT send both a PA-TNC Error attribute and a As such, a SW-PC MUST NOT send both a PA-TNC Error attribute and a SW
SWID Response attribute in response to a single SWID Request Response attribute in response to a single SW Request attribute.
attribute.
Table 11 lists the Error Code values for the PA-TNC Error attribute Table 11 lists the Error Code values for the PA-TNC Error attribute
specific to the SWID Message and Attributes for PA-TNC exchange. In specific to the Software Message and Attributes for PA-TNC exchange.
all of these cases, the Error Code Vendor ID field MUST be set to In all of these cases, the Error Code Vendor ID field MUST be set to
0x000000, corresponding to the IETF SMI Private Enterprise Number. 0x000000, corresponding to the IETF SMI Private Enterprise Number.
The Error Information structures for each error type are described in The Error Information structures for each error type are described in
the following subsections. the following subsections.
Note that a message with a SWID Message and Attributes for PA-TNC Note that a message with a Software Message and Attributes for PA-TNC
attribute might also result in an error condition covered by the attribute might also result in an error condition covered by the
Standard PA-TNC Error Codes defined in PA-TNC. For example, the SWID Standard PA-TNC Error Codes defined in PA-TNC. For example, a SW
Attribute might have an invalid parameter, leading to an error code Attribute might have an invalid parameter, leading to an error code
of "Invalid Parameter". In this case, the SWID-PC MUST use the of "Invalid Parameter". In this case, the SW-PC MUST use the
appropriate PA-TNC Error Code value as defined in Section 4.2.8 of appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
PA-TNC specification. PA-TNC specification.
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Error Code Value | Description | | Error Code Value | Description |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| 0x00000020 | SWID_ERROR. This indicates a fatal error | | 0x00000020 | SW_ERROR. This indicates a fatal error |
| | (i.e., an error that precludes the | | | (i.e., an error that precludes the |
| | creation of a suitable response | | | creation of a suitable response |
| | attribute) other than the errors | | | attribute) other than the errors |
| | described below but still specific to the | | | described below but still specific to the |
| | processing of SWID Attributes. The | | | processing of SW Attributes. The |
| | Description field SHOULD contain | | | Description field SHOULD contain |
| | additional diagnostic information. | | | additional diagnostic information. |
| 0x00000021 | SWID_SUBSCRIPTION_DENIED_ERROR. This | | | |
| | indicates that the SWID-PC denied the | | 0x00000021 | SW_SUBSCRIPTION_DENIED_ERROR. This |
| | SWID-PV's request to establish a | | | indicates that the SW-PC denied the SW- |
| | subscription. The Description field | | | PV's request to establish a subscription. |
| | SHOULD contain additional diagnostic | | | The Description field SHOULD contain |
| | information. | | | additional diagnostic information. |
| 0x00000022 | SWID_RESPONSE_TOO_LARGE_ERROR. This | | | |
| | indicates that the SWID-PC's response to | | 0x00000022 | SW_RESPONSE_TOO_LARGE_ERROR. This |
| | the SWID-PV's request was too large to be | | | indicates that the SW-PC's response to |
| | the SW-PV's request was too large to be |
| | serviced. The error information structure | | | serviced. The error information structure |
| | indicates the largest possible size of a | | | indicates the largest possible size of a |
| | response supported by the SWID-PC (see | | | response supported by the SW-PC (see |
| | Section 4.16.2). The Description field | | | Section 4.16.2). The Description field |
| | SHOULD contain additional diagnostic | | | SHOULD contain additional diagnostic |
| | information. | | | information. |
| 0x00000023 | SWID_SUBSCRIPTION_FULFILLMENT_ERROR. This | | | |
| | indicates that the SWID-PC experienced an | | 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | indicates that the SW-PC experienced an |
| | error fulfilling a given subscription. | | | error fulfilling a given subscription. |
| | The error information includes the | | | The error information includes the |
| | Subscription ID of the relevant | | | Subscription ID of the relevant |
| | subscription, as well as a sub-error that | | | subscription, as well as a sub-error that |
| | describes the nature of the error the | | | describes the nature of the error the SW- |
| | SWID-PC experienced. The SWID-PC and | | | PC experienced. The SW-PC and SW-PV MUST |
| | SWID-PV MUST treat the identified | | | treat the identified subscription as |
| | subscription as cancelled. | | | cancelled. |
| 0x00000024 | SWID_SUBSCRIPTION_ID_REUSE_ERROR. This | | | |
| | indicates that the SWID-PC received a | | 0x00000024 | SW_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | SWID Request from a given SWID-PV where | | | indicates that the SW-PC received a SW |
| | the Request ID of that SWID Request is | | | Request from a given SW-PV where the |
| | Request ID of that SW Request is |
| | currently used as the Subscription ID of | | | currently used as the Subscription ID of |
| | an active subscription with that SWID-PV. | | | an active subscription with that SW-PV. |
| | This error does not cancel the identified | | | This error does not cancel the identified |
| | subscription. | | | subscription. |
| | |
| 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved | | 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved |
| | for use by future revisions of the SWID | | | for use by future revisions of the |
| | Message and Attributes for PA-TNC | | | Software Message and Attributes for PA- |
| | specification. Any PA-TNC Error attribute | | | TNC specification. Any PA-TNC Error |
| | using one of these Error Codes MUST be | | | attribute using one of these Error Codes |
| | treated as indicating a fatal error on | | | MUST be treated as indicating a fatal |
| | the sender without further | | | error on the sender without further |
| | interpretation. | | | interpretation. |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 11: PA-TNC Error Codes for SWID Message and Attributes for PA- Table 11: PA-TNC Error Codes for Software Message and Attributes for
TNC PA-TNC
The following subsections describe the structures present in the The following subsections describe the structures present in the
Error Information fields. Error Information fields.
4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR and 4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
SWID_SUBSCRIPTION_ID_REUSE_ERROR Information SW_SUBSCRIPTION_ID_REUSE_ERROR Information
The SWID_ERROR error code indicates that the sender (the SWID-PC) has The SW_ERROR error code indicates that the sender (the SW-PC) has
encountered an error related to the processing of a SWID Request encountered an error related to the processing of a SW Request
attribute but which is not covered by more specific SWID error codes. attribute but which is not covered by more specific SW error codes.
The SWID_SUBSCRIPTION_DENIED_ERROR is used when the SWID-PV requests The SW_SUBSCRIPTION_DENIED_ERROR is used when the SW-PV requests to
to establish a subscription or clear all subscriptions from the given establish a subscription or clear all subscriptions from the given
SWID-PV, but the SWID-PC is unable or unwilling to comply with this SW-PV, but the SW-PC is unable or unwilling to comply with this
request. The SWID_SUBSCRIPTION_ID_REUSE_ERROR is used when the SWID- request. The SW_SUBSCRIPTION_ID_REUSE_ERROR is used when the SW-PC
PC receives a SWID Request whose Request ID duplicates a Subscription receives a SW Request whose Request ID duplicates a Subscription ID
ID of an active subscription with the request's sender. All of these of an active subscription with the request's sender. All of these
error codes use the following error information structure. error codes use the following error information structure.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID | | Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) | | Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SWID Error, Subscription Error, and Subscription ID Reuse Figure 13: SW Error, Subscription Error, and Subscription ID Reuse
Information Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Copy of | In the case that this error condition is generated | | Copy of | In the case that this error condition is generated |
| Request ID / | in direct response to a SWID Request attribute, | | Request ID / | in direct response to a SW Request attribute, this |
| Subscription | this field MUST contain an exact copy of the | | Subscription | field MUST contain an exact copy of the Request ID |
| ID | Request ID field in the SWID Request attribute | | ID | field in the SW Request attribute that caused this |
| | that caused this error. In the case that the | | | error. In the case that the attribute in question |
| | attribute in question is generated in fulfillment | | | is generated in fulfillment of an active |
| | of an active subscription, this field MUST contain | | | subscription, this field MUST contain the |
| | the Subscription ID of the subscription for which | | | Subscription ID of the subscription for which the |
| | the attribute was generated. (This is only | | | attribute was generated. (This is only possible |
| | possible if the error code is SWID_ERROR as the | | | if the error code is SW_ERROR as the other errors |
| | other errors are not generated by subscription | | | are not generated by subscription fulfillment.) |
| | fulfillment.) Note that, in this case, the | | | Note that, in this case, the indicated error |
| | indicated error appears as a sub-error for a | | | appears as a sub-error for a |
| | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described | | | SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in |
| | in Section 4.16.3. | | | Section 4.16.3. |
| | |
| Description | A UTF-8 string describing the condition that | | Description | A UTF-8 string describing the condition that |
| | caused this error. This field MAY be 0-length. | | | caused this error. This field MAY be 0-length. |
| | However, senders SHOULD include some description | | | However, senders SHOULD include some description |
| | in all PA-TNC Error attributes of these types. | | | in all PA-TNC Error attributes of these types. |
| | This field MUST NOT be NULL terminated. | | | This field MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 12: SWID Error, Subscription Error, and Subscription ID Reuse Table 12: SW Error, Subscription Error, and Subscription ID Reuse
Information Fields Information Fields
This error information structure is used with SWID_ERROR, This error information structure is used with SW_ERROR,
SWID_SUBSCRIPTION_DENIED_ERROR, and SWID_SUBSCRIPTION_ID_REUSE_ERROR SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR
status codes to identify the SWID Request attribute that precipitated status codes to identify the SW Request attribute that precipitated
the error condition and to describe the error. The Description field the error condition and to describe the error. The Description field
contains text describing the error. The SWID-PC MAY encode machine- contains text describing the error. The SW-PC MAY encode machine-
interpretable information in this field, but SHOULD also include a interpretable information in this field, but SHOULD also include a
human-readable description of the error, since the receiving SWID-PV human-readable description of the error, since the receiving SW-PV
might not recognize the SWID-PC's encoded information. might not recognize the SW-PC's encoded information.
4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information 4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information
The SWID_RESPONSE_TOO_LARGE_ERROR error code indicates that a The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response
response generated by a SWID-PC in response to a SWID-PV's SWID generated by a SW-PC in response to a SW-PV's SW Request attribute
Request attribute was too large to send. was too large to send.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription I | | Copy of Request ID / Subscription I |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size | | Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) | | Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SWID Response Too Large Error Information Figure 14: SW Response Too Large Error Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Copy of | In the case that the attribute in question is | | Copy of | In the case that the attribute in question is |
| Request ID / | generated in direct response to a SWID Request, | | Request ID / | generated in direct response to a SW Request, this |
| Subscription | this field MUST contain an exact copy of the | | Subscription | field MUST contain an exact copy of the Request ID |
| ID | Request ID field in the SWID Request attribute | | ID | field in the SW Request attribute that caused this |
| | that caused this error. In the case that the | | | error. In the case that the attribute in question |
| | attribute in question is generated in fulfillment | | | is generated in fulfillment of an active |
| | of an active subscription, this field MUST contain | | | subscription, this field MUST contain the |
| | the Subscription ID of the subscription for which | | | Subscription ID of the subscription for which the |
| | the attribute was generated. Note that, in this | | | attribute was generated. Note that, in the latter |
| | case, the SWID_RESPONSE_TOO_LARGE_ERROR appears as | | | case, the SW_RESPONSE_TOO_LARGE_ERROR appears as a |
| | a sub-error for a | | | sub-error for a SW_SUBSCRIPTION_FULFILLMENT_ERROR, |
| | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described | | | as described in Section 4.16.3. |
| | in Section 4.16.3. | | | |
| Maximum | This field MUST contain an unsigned integer | | Maximum | This field MUST contain an unsigned integer |
| Allowed Size | indicating the largest permissible size, in bytes, | | Allowed Size | indicating the largest permissible size, in bytes, |
| | of SWID Attribute that the SWID-PC is currently | | | of SW Attribute that the SW-PC is currently |
| | willing to send in response to a SWID Request | | | willing to send in response to a SW Request |
| | attribute. | | | attribute. |
| | |
| Description | A UTF-8 string describing the condition that | | Description | A UTF-8 string describing the condition that |
| | caused this error. This field MAY be 0-length. | | | caused this error. This field MAY be 0-length. |
| | However, senders SHOULD include some description | | | However, senders SHOULD include some description |
| | in all PA-TNC Error attributes of these types. | | | in all PA-TNC Error attributes of these types. |
| | This field MUST NOT be NULL terminated. | | | This field MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 13: SWID Response Too Large Error Information Fields Table 13: SW Response Too Large Error Information Fields
This error structure is used with the SWID_RESPONSE_TOO_LARGE_ERROR This error structure is used with the SW_RESPONSE_TOO_LARGE_ERROR
status code to identify the SWID Request attribute that precipitated status code to identify the SW Request attribute that precipitated
the error condition and to describe the error. The Maximum Allowed the error condition and to describe the error. The Maximum Allowed
Size field indicates the largest attribute the SWID-PC is willing to Size field indicates the largest attribute the SW-PC is willing to
send in response to a SWID Request under the current circumstances. send in response to a SW Request under the current circumstances.
Note that under other circumstances, the SW-PC might be willing to
Note that under other circumstances, the SWID-PC might be willing to return larger or smaller responses than indicated (such as if the
return larger responses than indicated (such as if the endpoint endpoint connects to the NEA Server using a different network
connects to the NEA Server using a different network protocol). The protocol). The other fields in this error information structure have
other fields in this error information structure have the same the same meanings as corresponding fields in the SW_ERROR and
meanings as corresponding fields in the SWID_ERROR and SW_SUBSCRIPTION_DENIED_ERROR information structure.
SWID_SUBSCRIPTION_DENIED_ERROR information structure.
4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information 4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information
The SWID_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the The SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the
SWID-PC encountered an error while fulfilling a subscription. The SW-PC encountered an error while fulfilling a subscription. The
bytes after the first 4 octets duplicate a PA-TNC Error attribute (as bytes after the first 4 octets duplicate a PA-TNC Error attribute (as
described in Section 4.2.8 of PA-TNC) that is used to identify the described in Section 4.2.8 of PA-TNC) that is used to identify the
nature of the encountered error. nature of the encountered error.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID | | Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub Error Code Vendor ID | | Reserved | Sub Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Code | | Sub Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Information (Variable Length) | | Sub Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: SWID Subscription Fulfillment Error Information Figure 15: SW Subscription Fulfillment Error Information
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Description | | Field | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Subscription | This field MUST contain the Subscription ID of the | | Subscription | This field MUST contain the Subscription ID of the |
| ID | subscription whose fulfillment caused this error. | | ID | subscription whose fulfillment caused this error. |
| | |
| Reserved | This field MUST contain the value of the Reserved | | Reserved | This field MUST contain the value of the Reserved |
| | field of a PA-TNC Error attribute that describes | | | field of a PA-TNC Error attribute that describes |
| | the error condition encountered during | | | the error condition encountered during |
| | subscription processing. | | | subscription processing. |
| | |
| Sub Error | This field MUST contain the value of the Error | | Sub Error | This field MUST contain the value of the Error |
| Code Vendor | Code Vendor ID field of a PA-TNC Error attribute | | Code Vendor | Code Vendor ID field of a PA-TNC Error attribute |
| ID | that describes the error condition encountered | | ID | that describes the error condition encountered |
| | during subscription processing. | | | during subscription processing. |
| | |
| Sub Error | This field MUST contain the value of the Error | | Sub Error | This field MUST contain the value of the Error |
| Code | Code field of a PA-TNC Error attribute that | | Code | Code field of a PA-TNC Error attribute that |
| | describes the error condition encountered during | | | describes the error condition encountered during |
| | subscription processing. | | | subscription processing. |
| | |
| Sub Error | This field MUST contain the value of the Error | | Sub Error | This field MUST contain the value of the Error |
| Information | Information field of a PA-TNC Error attribute that | | Information | Information field of a PA-TNC Error attribute that |
| | describes the error condition encountered during | | | describes the error condition encountered during |
| | subscription processing. | | | subscription processing. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 14: SWID Subscription Fulfillment Error Information Fields Table 14: SW Subscription Fulfillment Error Information Fields
This error structure is used with the This error structure is used with the
SWID_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets SW_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of
of this error structure contain the Subscription ID of the this error structure contain the Subscription ID of the subscription
subscription that was being fulfilled when the error occurred. The that was being fulfilled when the error occurred. The remaining
remaining fields of this error structure duplicate the fields of a fields of this error structure duplicate the fields of a PA-TNC Error
PA-TNC Error attribute, referred to as the "sub-error". The error attribute, referred to as the "sub-error". The error code of the
code of the sub-error corresponds to the type of error that the SWID- sub-error corresponds to the type of error that the SW-PC encountered
PC encountered while fulfilling the given subscription. The sub- while fulfilling the given subscription. The sub-error MUST NOT have
error MUST NOT have an error code of an error code of SW_SUBSCRIPTION_FULFILLMENT_ERROR.
SWID_SUBSCRIPTION_FULFILLMENT_ERROR.
The SWID-PC sending a PA-TNC Error attribute with this error code, The SW-PC sending a PA-TNC Error attribute with this error code, and
and the SWID-PV receiving it, MUST treat the subscription identified the SW-PV receiving it, MUST treat the subscription identified by the
by the Subscription ID field as cancelled. All other subscriptions Subscription ID field as cancelled. All other subscriptions are
are unaffected. unaffected.
5. Security Considerations 5. Supported Data Models
Software Message and Attributes for PA-TNC supports an extensible
list of data models for representing and transmitting software
inventory information. This list of data models appears in the
Software Data Model IANA table (see Section 9.4). This document
provides guidance for an initial set of data models. Other documents
might provide guidance on the use of new data models by Software
Message and Attributes for PA-TNC, and will be referenced by
extensions to the Software Data Model IANA table.
5.1. ISO 2015 SWID Tags using XML
The International Organization for Standardization and the
International Electrotechnical Commission (ISO/IEC) published the
specification governing SWID tag construction and use in 2009 with a
revised version published in 2015. [SWID] Since that time, a growing
number of vendors have integrated SWID tags into their software
products. Doing so significantly simplifies the task of identifying
these pieces of software: instead of relying on discovery processes
that look for clues as to software presence, such as the presence of
particular files or registry keys, a readily available list of SWID
tags provides simple and immediate evidence as to the presence of the
given piece of software.
SWID Message and Attributes for PA-TNC has no reliance on the
presence or management of SWID tags on an endpoint as described in
the ISO specification. However, the data model for describing
software that is presented in the ISO specification provides a robust
and comprehensive way of describing software and is adopted here as a
means of representing and transmitting software information. It
should be emphasized, the use of the ISO SWID tag data model makes no
assumption as to whether the source of the recorded information was,
in fact, an ISO SWID tag harvested from the endpoint or whether the
information was created using some other source and normalized to the
SWID format.
5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using
XML
TBD
Don't violate the specification
Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do
not use some other party's RegID, especially not the RegID of the
software author if you are not the author.
5.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID
Tags
TBD
Use combination of Tag Creator RegID and Unique ID fields.
Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest
of the Software Identifier MUST be the concatination of the Tag
Creator RegID and the Unique ID from the tag, without any connecting
character or whitespace.
5.2. ISO 2009 SWID Tags using XML
As noted above, ISO's SWID tag specification provides a useful data
model for representation of software information. As of the writing
of this specification, while the 2015 specification is considered
more comprehensive and addresses some issues with the 2009
specification, 2009-format SWID tags remain far more common in
deployments. For this reason, ISO 2009 SWID tags are included in the
Software Data Model IANA table.
5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags using
XML
TBD
Don't violate the specification
Use your own Tag Creator RegID or the Unknown Tag Creator RegID. Do
not use some other party's RegID, especially not the RegID of the
software author if you are not the author.
5.2.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID
Tags
TBD
Use combination of Tag Creator RegID and Unique ID fields.
Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
where NUMBER is the length of TAG_CREATOR_REGID in bytes. The rest
of the Software Identifier MUST be the concatination of the Tag
Creator RegID and the Unique ID from the tag, without any connecting
character or whitespace.
6. Security Considerations
This section discusses some of the security threats facing Posture This section discusses some of the security threats facing Posture
Collectors and Posture Validators that implement the SWID Message and Collectors and Posture Validators that implement the Software Message
Attributes for PA-TNC protocol. This section primarily notes and Attributes for PA-TNC protocol. This section primarily notes
potential issues for implementers to consider, although it does potential issues for implementers to consider, although it does
contain a handful of normative requirements to address certain contain a handful of normative requirements to address certain
security issues. Implementers need to make the final decision as to security issues. Implementers need to make the final decision as to
how their implementations address the given issues. The issues how their implementations address the given issues. The issues
identified below focus on capabilities specific to this document. identified below focus on capabilities specific to this document.
Implementers are advised to consult other relevant NEA specifications Implementers are advised to consult other relevant NEA specifications
for security issues that are applicable to such components in for security issues that are applicable to such components in
general. general.
Reading the Security Considerations section of any well-written Reading the Security Considerations section of any well-written
specification can be discouraging, as a long list of possible threats specification can be discouraging, as a long list of possible threats
is catalogued. Keep in mind that no security measure is absolute, is catalogued. Keep in mind that no security measure is absolute,
but each one can be beneficial. By understanding the weaknesses of but each one can be beneficial. By understanding the weaknesses of
each security measure, we can put in place countermeasures to protect each security measure, we can put in place countermeasures to protect
against exploitation of these weaknesses. against exploitation of these weaknesses.
5.1. Evidentiary Value of SWID Tags 6.1. Evidentiary Value of Software Inventory Evidence Records
A SWID tag is only indirect evidence as to the installation of a
piece of software on an endpoint. While the ideal is for the
presence of a tag to correspond to the presence of the corresponding
software, such a correlation hinges on software that accurately
manages individual tags as software is added and removed.
Utilization of the tests included in a tag's package_footprint and/or
validation elements can provide more direct evidence of software
presence, but this information might not be present in many tags and,
because of its limited support, this version of the SWID Message and
Attributes for PA-TNC specification does not support use of these
flags. Tags can include cryptographic signatures of some or all of
their fields, which can enable detection of field modification. This
is extremely useful in ensuring that sensitive fields are not
modified maliciously. However, the use of cryptographic signatures
is not required in SWID tags, and even when utilized, not all fields
will necessarily be protected by signatures. For these reasons, it
is important to treat SWID tags as evidence rather than proof of
software presence.
5.2. Integrity of the SWID Tag Collection