wdiff draft-coffin-sacm-nea-swid-patnc-01.txt draft-coffin-sacm-nea-swid-patnc-02.txt

SACM C. Coffin
Internet-Draft D. Haynes
Intended status: Standards Track C. Schmidt
Expires: December 10, 2016 March 16, 2017 The MITRE Corporation
J. Fitzgerald-McKay
Department of Defense
June 8,
September 12, 2016

SWID

Software Message and Attributes for PA-TNC
draft-coffin-sacm-nea-swid-patnc-01
draft-coffin-sacm-nea-swid-patnc-02

Abstract

This document specifies the SWID Software Message and Attributes for PA-TNC. PA-
TNC. It extends the PA-TNC specification [RFC5792] by providing
specific attributes and message exchanges to allow endpoints to
report their software inventory information to a NEA server (as
described in
[RFC5209]) using SWID tags [SWID]. [RFC5209]).

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 10, 2016. March 16, 2017.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope and Audience . . . . . . . . . . . . . . . . . . . 4
1.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 7 6
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Role of SWID Message and Attributes for PA-TNC . . . . . 8
2.2. Supported Use Cases . . . . . . . . . . . . . . . . . . . 9
2.2.1. 7
2.1.1. Use Software Inventory as a Factor in Determining
Endpoint Access . . . . . . . . . . . . . . . . . . . 9
2.2.2. 8
2.1.2. Maintain a Central Repository Reflecting an
Endpoint's Software Inventory . . . . . . . . . . . . 9
2.2.3. 8
2.1.3. PA-TNC Use Cases . . . . . . . . . . . . . . . . . . 10
2.3. 9
2.2. Non-supported Use Cases . . . . . . . . . . . . . . . . . 10
2.4. 9
2.3. Specification Requirements . . . . . . . . . . . . . . . 11
2.5. 10
2.4. Non-Requirements . . . . . . . . . . . . . . . . . . . . 13
2.6. 11
2.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. 11
2.6. Non-Assumptions . . . . . . . . . . . . . . . . . . . . . 13
2.8. SWID 12
2.7. Software Message and Attributes for PA-TNC Diagram
Conventions . . . . . . . . . . . . . . . . . . . . . . . 14 12
3. SWID Software Message and Attributes for PA-TNC System
Requirements . 14
3.1. SWID Tags as Inventory Evidence . . . . . . . . . . . . . 15
3.2. Basic SWID Tag Inventory Exchange . . . . . . . . . . . . 15
3.3. SWID Tag Identifiers . . . . . . . . . . . . . . . 13
3.1. Basic Inventory Exchange . . . 16
3.3.1. Tag Identifier Data . . . . . . . . . . . . . 13
3.2. Software Identifiers . . . . 17
3.3.2. Tag Identifier Instances . . . . . . . . . . . . . . 18
3.3.3. Comparing Tag 14
3.2.1. Record Identifiers and Tag Identifier
Instances . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3.1. Matching Tag Identifiers Indicate the Same 15
3.2.2. Using Software Product . . . . . . . . . . . . and Record Identifiers in SW
Attributes . . . . 20
3.3.3.2. Matching Tag Identifiers DO NOT Necessarily
Indicate Identical Tag Files . . . . . . . . . . 20
3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate
Identical Tag Files . . . . . . . 16
3.3. Targeted Requests . . . . . . . . 21
3.3.3.4. Differing Tag Identifiers DO NOT Necessarily
Indicate Different Software Products . . . . . . 21
3.3.4. Using Tag Identifiers in SWID Attributes . . . . . . 22 16
3.4. Targeted Requests . Monitoring Changes in an Endpoint's Software Inventory
Evidence Collection . . . . . . . . . . . . . . . . . . . 22 17
3.5. Monitoring Changes in an Endpoint's SWID Tag Collection . 23
3.6. Reporting Change Events . . . . . . . . . . . . . . . . . 25
3.6.1. 19
3.5.1. Change Event Records . . . . . . . . . . . . . . . . 25
3.6.2. 20
3.5.2. Updating Inventory Knowledge Based on Events . . . . 27
3.6.3. 21
3.5.3. Using Event Records in SWID SW Attributes . . . . . . . 28
3.6.4. . 22
3.5.4. Partial and Complete Lists of Event Records in SWID SW
Attributes . . . . . . . . . . . . . . . . . . . . . 28
3.6.5. 22
3.5.5. Synchronizing Event Identifiers and Epochs . . . . . 30
3.7. Supporting Multiple Instances of a Single Tag . 24
3.6. Subscriptions . . . . . 32
3.7.1. Inventory Reporting in the Presence of Multiply-
Instantiated Tags . . . . . . . . . . . . . . . . . 26
3.6.1. Establishing Subscriptions . 32
3.7.2. Event Reporting in the Presence of Multiply
Instantiated Tags . . . . . . . . . . . . . . . . . . 32
3.8. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 32
3.8.1. Establishing Subscriptions . . . . . . . . . . . . . 33
3.8.2. 26
3.6.2. Managing Subscriptions . . . . . . . . . . . . . . . 33
3.8.3. 27
3.6.3. Terminating Subscriptions . . . . . . . . . . . . . . 34
3.8.4. 27
3.6.4. Subscription Status . . . . . . . . . . . . . . . . . 35
3.8.5. 28
3.6.5. Fulfilling Subscriptions . . . . . . . . . . . . . . 35
3.8.5.1. 28
3.6.5.1. Subscriptions Reporting Inventories . . . . . . . 37
3.8.5.2. 30
3.6.5.2. Subscriptions Reporting Events . . . . . . . . . 37
3.8.5.3. 30
3.6.5.3. Targeted Subscriptions . . . . . . . . . . . . . 38
3.8.5.4. 31
3.6.5.4. No Subscription Consolidation . . . . . . . . . . 39
3.8.5.5. 32
3.6.5.5. Delayed Subscription Fulfillment . . . . . . . . 39
3.9. 32
3.7. Multiple Sources of SWID Tags . . . . . . . . . . . . . Software Inventory Evidence Records . 40
3.10. 33
3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 41 34
4. SWID Software Message and Attributes for PA-TNC Protocol . . . . . . . 43 36
4.1. PA Subtype (AKA PA-TNC Component Type) . . . . . . . . . 43 36
4.2. PB-TNC and PA-TNC Messages . . . . . . . . . . . . . . . 44 36
4.3. PA-TNC Attribute Header . . . . . . . . . . . . . . . . . 44 37
4.4. SWID SW Attribute Overview . . . . . . . . . . . . . . . . . 45 . 38
4.5. SWID SW Attribute Exchanges . . . . . . . . . . . . . . . . 47 . 40
4.6. SWID Software Message and Attributes for PA-TNC Attribute
Enumeration . . . . . . . . . . . . . . . . . . . . . . . 49 42
4.7. Normalization of Text Encoding . . . . . . . . . . . . . 50 43
4.8. Request IDs . . . . . . . . . . . . . . . . . . . . . . . 51 44
4.9. SWID SW Request . . . . . . . . . . . . . . . . . . . . . . 52 . 45
4.10. SWID Tag Software Identifier Inventory . . . . . . . . . . . . . . 56 48
4.11. SWID Tag Software Identifier Events . . . . . . . . . . . . . . . 59 51
4.12. SWID Tag Software Inventory . . . . . . . . . . . . . . . . . . . 64 56
4.13. SWID Tag Software Events . . . . . . . . . . . . . . . . . . . . . 66 58
4.14. Subscription Status Request . . . . . . . . . . . . . . . 70 62
4.15. Subscription Status Response . . . . . . . . . . . . . . 70 62
4.16. PA-TNC Error as Used by SWID Software Message and Attributes
for PA-TNC . . . . . . . . . . . . . . . . . . . . . . . . . 72 64
4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and SWID_SUBSCRIPTION_ID_REUSE_ERROR
SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . . 66
4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information . . . . . . 68
4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information . . . 69
5. Supported Data Models . . . . . . 74
4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information . . . . . 75
4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . . 77
5. Security Considerations . . . . . . . . . 71
5.1. ISO 2015 SWID Tags using XML . . . . . . . . . . 78
5.1. Evidentiary Value of SWID Tags . . . . 71
5.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID
Tags using XML . . . . . . . . . 79
5.2. Integrity of the SWID Tag Collection . . . . . . . . . . 79
5.3. Sensitivity 72
5.1.2. Guidance on Creation of Collected Software Identifiers from ISO
2015 SWID Tags . . . . . . . . . . . . . . 80
5.4. Integrity of Endpoint Records . . . . . 72
5.2. ISO 2009 SWID Tags using XML . . . . . . . . . 81
5.5. SWID-PC Access Permissions . . . . . 72
5.2.1. Guidance on Normalizing Source Data to ISO 2015 SWID
Tags using XML . . . . . . . . . . 82
5.6. Sanitization of Tag Fields . . . . . . . . . 72
5.2.2. Guidance on Creation of Software Identifiers from ISO
2015 SWID Tags . . . . . . 82
5.7. Tag Library Poisoning . . . . . . . . . . . . . 73
6. Security Considerations . . . . . 83
5.8. PA-TNC Security Threats . . . . . . . . . . . . . . . . . 83
6. Privacy Considerations . . . . . . . 73
6.1. Evidentiary Value of Software Inventory Evidence Records 73
6.2. Sensitivity of Collected Records . . . . . . . . . . . . 83
7. Relationship to Other Specifications 74
6.3. Integrity of Endpoint Records . . . . . . . . . . . . 84
8. IANA Considerations . . 75
6.4. SW-PC Access Permissions . . . . . . . . . . . . . . . . 75
6.5. Sanitization of Record Fields . . . 84
8.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 85
8.2. Registry for 76
6.6. PA-TNC Error Codes . . . . . . . . . . . . . 85
8.3. Registry for PA Subtypes . . . . . . . . . . . . . . . . 86
9. References . . . . . . . . . . . . . . . . . . . . . . Security Threats . . . 86
9.1. Normative References . . . . . . . . . . . . . . 76
7. Privacy Considerations . . . . 87
9.2. Informative References . . . . . . . . . . . . . . . 76
8. Relationship to Other Specifications . . 87
Appendix A. Examples . . . . . . . . . . 77
9. IANA Considerations . . . . . . . . . . . . 88
A.1. A Simple SWID Tag . . . . . . . . . 77
9.1. Registry for PA-TNC Attribute Types . . . . . . . . . . . 88
A.2. SWID Request Attributes 77
9.2. Registry for PA-TNC Error Codes . . . . . . . . . . . . . 78
9.3. Registry for PA Subtypes . . . . 90
A.2.1. Simple Request . . . . . . . . . . . . 79
9.4. Registry for Software Data Models . . . . . . . 90
A.2.2. Subscription Request for Events . . . . . 80
10. References . . . . . . 91
A.2.3. Targeted Request . . . . . . . . . . . . . . . . . . 91
A.3. SWID Response Attributes . 80
10.1. Normative References . . . . . . . . . . . . . . . 93
A.3.1. SWID Tag Identifier Events Attribute . . . 80
10.2. Informative References . . . . . 93
A.3.2. SWID Tag Inventory Attribute . . . . . . . . . . . . 95 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 81

1. Introduction

1.1. Scope and Audience

The Network Endpoint Assessment (NEA) Working Group defines an open
solution architecture that enables network operators to collect and
utilize information about endpoint configuration and state. This
information can be used to enforce policies, monitor endpoint health,
and for many other activities. Information about the software
present on an endpoint is an important consideration for such
activities. Software Identification Such information can come from multiple sources,
including tag files (such as ISO SWID tags (SWID tags) [SWID] [SWID], reports from third
party inventory tools, output from package managers, and other
sources. The attributes defined in this document are
formatted records (usually XML documents) that identify a specific used to
communicate software product. In this case, a "software product" can be inventory evidence, collected from a
distinct release of some piece range of software, such as an operating
system, web browser, etc.; a patch or plug-in for such an
application; or a suite of such applications. The SWID specification
describes
possible sources, from the format of these documents as well as rules governing
their use on computer systems. In particular, software that supports
SWID tags is expected to deposit an identifying tag posture collector 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 on a NEA Server using the PA-TNC interface, as
shown in Figure 1 below.

+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER

Figure 1: NEA Reference Model

The use

This specification defines a new set of standard protocols PA-TNC attributes, carried
over PA-TNC messages, which are used to communicate requests for
software information and software events, and formats for conveying evidence
about endpoint state (in this case, endpoint inventory information)
has that
information back to a number NEA Server.

Possession of benefits. The use a list of standard protocols an endpoint's installed software is very
useful in understanding and formats
facilitates interoperability between products developed by different
vendors. This allows consumers to select the product that has
features that best fit with maintaining the needs security state of their environment, with an
enterprise. For example, if an enterprise policy requires 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
over PA-TNC messages, which are used to communicate requests for SWID
tags and events surrounding those tags, and for conveying that
information back to a NEA Server.

Possession of a list of an endpoint's SWID tags is very useful in
understanding and maintaining the security state of an enterprise.
For example, if an enterprise policy requires the presence
presence of certain pieces of software and/or prohibits the presence
of other software,
SWID tags reported software inventory lists can be used to
indicate compliance or non-compliance with these requirements. SWID tags indicating software
Software presence and the patch level of that software can be
compared to vulnerability or threat alerts to determine an endpoint's
exposure to attack. SWID
tags provide a great deal of information about unfamiliar software
products, including the software author and potentially including
where the software is installed on the endpoint and what files on the
endpoint are associated with this installed software. All of these uses make an understanding of an
endpoint's SWID tag software collection highly useful to NEA Servers and other
enterprise security applications.

Before reading this specification any further, the reader should
review and understand the NEA reference architecture as described in
the Network Endpoint Assessment (NEA): Overview and Requirements
[RFC5209]. The reader should also understand the capabilities and
requirements common to PA-TNC interfaces as defined in RFC 5792
[RFC5792].

This document is based on standards published by the Trusted
Computing Group's Trusted Network Communications (TNC) workgroup.
The TNC and NEA architectures are interoperable and the following
components are equivalent:

Table 1: Equivalent components in TNC and NEA architectures

1.2. Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in RFC 2119
[RFC2119]. This specification does not distinguish blocks of
informative comments and normative requirements. Therefore, for the
sake of clarity, note that lower case instances of must, should, etc.
do not indicate normative requirements.

1.3. Definitions

This section defines terms with special meaning within this document.

SWID-PC

SW-PC - A Posture Collector (PC) that conforms to this specification.
Note that such a posture collector might also support other PA-TNC
exchanges beyond SWID Software Message and Attributes for PA-TNC.

SWID-PV

SW-PV - A Posture Validator (PV) that conforms to this specification.
Note that such a posture verifier might also support other PA-TNC
exchanges beyond SWID Software Message and Attributes for PA-TNC.

SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792
[RFC5792] extension for conveying software inventory information.
This specification defines several new attribute types.

Endpoint's SWID Tag Software Inventory Evidence Collection - The set of SWID tags
information regarding the set of software installed and
managed on an endpoint for software installed on that 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 SWID tag software inventory evidence collection
might include SWID tags information created by or derived from multiple
sources, including but not limited to SWID tag files deposited on the
file system during software installation, SWID tags information generated to
report output from software discovery tools, and SWID tags information
dynamically generated by a software or package management system on
an endpoint.

2. Background
2.1. Role

Software Inventory Evidence Record - The endpoint's Software
Inventory Evidence Collection is composed of SWID "records". Each record
corresponds to one installed instance of a particular software
product as reported by some data source. It is possible for a single
installed instance to have multiple software inventory evidence
records in an endpoint's Software Inventory Evidence Collection -
this can happen if multiple sources all report the same software
installation instance.

Software Identifier - A string associated with a specific version of
a specific software product. Each supported Software Message and
Attributes for PA-TNC

The International Organization data model has its own rules for Standardization and how a Software
Identifier (see Section 3.2) is derived from the
International Electrotechnical Commission (ISO/IEC) published representation of
the
specification governing SWID tag construction and use in 2009.
[SWID] Since given software product using that time, data model, and different
sources for this information might populate relevant information
differently. As such, while each Software Identifier uniquely
identifies a growing number of vendors have integrated
SWID tags into their specific software products. Doing so significantly
simplifies product, the task of identifying these pieces of software: instead
of relying on discovery processes that look for clues as to same 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 product
might 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, associated with multiple Software Identifiers reflecting
differences between different information sources and maintain them like vendor-created SWID tags. supported data
models.

2. Background

2.1. Supported Use Cases

This means that an endpoint's SWID tag collection is not necessarily
limited to containing SWID tags section describes the Software Message and Attributes for PA-TNC
use cases supported by this specification. The primary use of
exchanging software whose authors have taken inventory information over the time PA-TNC interface
is 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 enable a series of SWID tags, allowing
these managers challenger (e.g. NEA Server) to expose their information obtain inventory
evidence about software inventories some system in a standards-based manner. Finally, for organizations way that
centrally manage the distribution of software, in-house-developed
SWID tags can be added conforms to any NEA procedures
and expressed using a standard format. Collected software product that does not natively
information can support SWID tags allowing the organization a range of security activities including
determining whether an endpoint is permitted to accurately identify
any connect to the
enterprise, determining which endpoints contain software it has distributed.

The that
requires patching, and similar activities.

2.1.1. Use Software Inventory as a Factor in Determining Endpoint
Access

Some enterprises might define security policies that require
connected endpoints to have certain pieces of security software
installed. By contrast, some security policies might prevent access
by endpoints that have certain prohibited pieces of software
installed, such as applications that pose known security risks. To
support such policies, the NEA Server needs access to this inventory collect evidence if it
indicating the software inventory of an endpoint that is seeking to
use this information
initiate or continue connectivity to assess endpoint compliance with policy. The
SWID the enterprise.

Software Message and Attributes for PA-TNC specification has been created
for this purpose. Specifically, the attributes defined in this
specification allow a Posture Validator to request evidence of facilitates policy
decisions that consider an endpoint's software inventory in the form of SWID tags and allow by providing
the Posture
Collector to respond NEA Server with software inventory information from the appropriate information.

It is not necessary endpoint.
The SW-PC can provide a complete or partial inventory to understand the details of SWID tag
construction and maintenance SW-PV as
required to understand the behaviors described in
the SWID Message and Attributes for PA-TNC specification, and it is
beyond the scope of determine policy compliance. The SW-PV can then use this specification to discuss the details
as evidence of the
SWID standard. Implementers, however, will likely need to be
familiar compliance or non-compliance with the SWID tag format and how enterprise policy.

2.1.2. Maintain a Central Repository Reflecting an Endpoint's Software
Inventory

Many tools can use information about an endpoint's software inventory
to locate tags on monitor and enforce the security of 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 enterprise. For example, a SWID tag file is available from ISO:
http://standards.iso.org/iso/19770/-2/2009/schema.xsd. The most
current working
software patching service can use an endpoint's software inventory to
determine whether certain endpoints have software that requires
patching. A vulnerability management tool might identify endpoints
with known vulnerabilities (patched or otherwise) and production versions use this to
gauge enterprise exposure to attack. A license management tool might
verify that all copies of the XML schema a particular piece of software are
accounted for SWID
tags can be found in within the directory listing at
http://standards.iso.org/iso/19770/-2/. enterprise. The US National Institute presence of
Standards and Technology (NIST) also has published guidelines for
SWID tag creation, which provide further guidance for those
interested in a central
repository representing a real-time understanding of each endpoint's
software inventory facilitates all such activities. Using a central
repository that can ensure the use and best practices surrounding SWID tags.
[NIST-SWID]

2.2. Supported Use Cases

This section describes freshness of its collected information
is generally more efficient than having each tool collect the SWID same
inventory information from each endpoint individually and leads to a
more consistent understanding of enterprise state.

Software Message and Attributes for PA-TNC use
cases supported by supports this specification. The primary use activity
through a number of exchanging
SWID tag information over the PA-TNC interface is to enable mechanisms. As noted above, it allows a
challenger (e.g. NEA Server) SW-PC to obtain inventory evidence about some
system in
provide a way that conforms to NEA procedures while taking
advantage complete list of software present in an endpoint's Software
Inventory Evidence Collection to the simplicity and precision of SWID tags. Collected
SWID tags SW-PV, which can support then pass this
information on to a range of security activities including
determining whether an endpoint is permitted central repository such as a Configuration
Management Database (CMDB) or similar application. In addition, SW-
PCs are required to connect be able to the
enterprise, determining which endpoints contain software that
requires patching, and similar activities.

2.2.1. Use monitor for changes to an endpoint's
Software Inventory as a Factor Evidence Collection in Determining Endpoint
Access

Some enterprises might define security policies that require
connected endpoints to have certain pieces of security software
installed. By contrast, some security policies might prevent access
by endpoints that have certain prohibited pieces near real-time and push
reports of software
installed, such changes to the SW-PV as applications that pose known security risks. To
support soon as those changes are
detected. Thus any central repository fed by a SW-PV receiving such policies,
information can be updated soon after the NEA Server needs to collect evidence
indicating change occurs. Keeping
such a central repository synchronized with the software inventory state of an endpoint each
endpoint's Software Inventory Evidence Collection allows tools that is seeking to
initiate or continue connectivity
use this information for their own security activities to the enterprise.

SWID make
decisions in a consistent, efficient manner.

2.1.3. PA-TNC Use Cases

Software Message and Attributes for PA-TNC facilitates policy decisions
that consider an endpoint's software inventory by providing the NEA
Server with a list of the SWID tags in are intended to operate
over the endpoint's SWID tag
collection. The tags in this collection serve as evidence PA-TNC interface and, as such, are intended to meet the
endpoint's installed software. The SWID-PC can provide a complete or
partial list of tags to use
cases set out in the SWID-PV as required to determine policy
compliance. The SWID-PV can then PA-TNC specification.

2.2. Non-supported Use Cases

Some use cases not covered by this as evidence version of compliance
or non-compliance with enterprise policy.

2.2.2. Maintain a Central Repository Reflecting an Endpoint's Software
Inventory

Many tools can use information about an endpoint's software inventory
to monitor Message and enforce
Attributes for PA-TNC include:

o This specification does not address how the security of an enterprise. For example, a
software patching service can use an endpoint's software inventory Software
Inventory Evidence Collection is populated. In particular, NEA
components are not expected to
determine whether certain endpoints have perform software that requires
patching. A vulnerability management tool discovery
activities beyond compiling information in an endpoint's Software
Inventory Evidence Collection. This collection might identify endpoints
with known vulnerabilities (patched potentially
come from multiple sources on the endpoint (e.g., information
generated dynamically by package management tools or otherwise) and use this to
gauge discovery
tools, as well as SWID tag files discovered on the file system).
While an enterprise exposure to attack. A license management tool might
verify that all copies of a particular piece make use of software discovery
procedures to identify installed software such procedures are
accounted for within
outside the enterprise. The presence of a central
repository representing a real-time understanding scope of each endpoint's
software this specification.

o This specification does not address converting inventory facilitates all such activities. Using
information expressed in a central
repository that can ensure proprietary format into the freshness standard
format used in the messages described in this specification.
Instead, it focuses exclusively on defining interfaces for the
transportation of its collected software information in the expectation that
this is generally more efficient than having each tool collect the same
inventory information from each endpoint individually and leads to a
more consistent understanding of enterprise state.

SWID Message and Attributes format around which reporting tools will converge.

o This specification provides no mechanisms for PA-TNC supports this activity through
a number of mechanisms. As noted above, it allows a SWID-PC posture validator
to
provide request a complete specific list of software information based on
arbitrary software properties. For example, requesting only
information about software from a particular vendor is not
supported. After the tags present in an endpoint's SWID tag software inventory evidence
collection has been copied to some central location, such as the SWID-PV, which
CMDB, processes there can then pass this information perform queries based on to
a central repository any criteria
present in the collected information, but this specification does
not address using such as a Configuration Management Database
(CMDB) or similar application. In addition, SWID-PCs are required to
be able to monitor for changes queries to an endpoint's SWID tag constrain the initial collection
in near real-time and push reports
of changes to this information from the SWID-PV as soon
as those changes are detected. Thus any central repository fed by a
SWID-PV receiving such endpoint.

o This specification does not address utilization of properties of
certain sources of software information can be updated soon after that might facilitate
local tests (i.e., on the
change occurs. Keeping such a central repository synchronized with endpoint) of endpoint state. For
example, the state optional package_footprint field of each endpoint's an ISO SWID tag collection allows tools that
use this information for their own security activities to make
decisions in
can contain a consistent, efficient manner.

2.2.3. PA-TNC Use Cases

SWID Message list of files and Attributes for PA-TNC are intended to operate over hash values associated with the PA-TNC interface and, as such, are intended to meet
software indicated by the tag. Tools on the endpoint can use cases
set out the
values in this field to test for the PA-TNC specification.

2.3. Non-supported Use Cases

Some use cases presence of the indicated
files. Successful evaluation of such tests leads to greater
assurance that the indicated software is present on the endpoint.
Currently, most SWID tag creators do not covered by provide values for tag
fields that support local testing. For this version reason, the added
complexity of SWID supporting endpoint testing using these fields is
out of scope for this specification. Future versions of this
specification might add support for such testing.

2.3. Specification Requirements

Below are the requirements that the Software Message and Attributes
for PA-TNC include:

o This specification does not address how the endpoint's SWID tag
collection is populated. In particular, required to meet in order to successfully
play its role in the NEA components are architecture.

o Efficient

The NEA architecture enables delay of network access until the
endpoint is determined not
expected to perform software discovery activities beyond compiling pose a security threat to the tags in an endpoint's SWID tag collection. This collection
might potentially come from multiple sources network
based on its asserted integrity information. To minimize user
frustration, the endpoint
(e.g., SWID tags generated dynamically by package management tools
or discovery tools, Software Message and Attributes for PA-TNC ought to
minimize overhead delays and make PA-TNC communications as well rapid and
efficient as SWID tag files discovered on the
file system). While an enterprise might make use of software
discovery procedures to identify installed software, especially
software possible.

Efficiency is also important when one considers that does not install or manage its own SWID tag, such
procedures some network
endpoints are outside the scope of this specification.

o This specification does not address converting inventory
information expressed small and low powered, some networks are low bandwidth
and/or high latency, and some transport protocols (such as PT-EAP,
Posture Transport (PT) Protocol for Extensible Authentication
Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
protocol might allow only one packet in flight at a proprietary format into the SWID tag
format time or converting a SWID tag into a proprietary format.
Instead, it focuses exclusively on defining interfaces for only one
roundtrip. However, when the
transportation underlying PT protocol imposes fewer
constraints on communications, this protocol ought to be capable of SWID tags
taking advantage of more robust communication channels (e.g. using
larger messages or multiple roundtrips).

o Scalable

Software Message and Attributes for PA-TNC needs to be usable in the expectation
enterprises that this is the
format around which reporting contain tens of thousands of endpoints or more. As
such, it needs to allow a security tools will converge. to make decisions based on
up-to-date information about an endpoint's software inventory without
creating an excessive burden on the enterprise's network.

o Interoperable

This specification provides no mechanisms defines the protocol for a posture validator how PCs and PVs can
exchange and use software information to request provide a specific list of tags based on arbitrary tag
properties from the endpoint. For example, requesting only tags
representing NEA Server with
information about an endpoint's software from inventory. Therefore a particular vendor key
goal for this specification is not supported.
After ensuring that all SW PCs and PVs,
regardless of the endpoint's SWID tag collection has been copied vendor who created them, are able to some
central location, such as the CMDB, processes there can perform
queries based on any criteria present interoperate
in the collected SWID tags,
but this specification does not address using such queries to
constrain the initial collection their performance of this information from the
endpoint. these duties.

o Support precise and complete historical reporting

This specification does not address utilization outlines capabilities that support real-time
understanding of certain SWID
tag fields designed to facilitate local tests (i.e., on the
endpoint) state of endpoint state. For example, the optional
package_footprint field of in a SWID tag can contain network in a list way that can
be used by other tools. One means of files facilitating such an outcome is
for a Configuration Management Database (CMDB) to be able to contain
information about all endpoints connected to the enterprise for all
points in time between the endpoint's first connection and hash values associated with the
present. In such a scenario, it is necessary that any PC be able to
report any changes to its software indicated by inventory evidence collection in
near real-time while connected and, upon reconnection to the tag.
Tools on
enterprise, be able to update the endpoint can use NEA Server (and through it the values in this field
CMDB) with regard to test for the presence state of its software inventory evidence
collection throughout the indicated files. Successful evaluation of
such tests leads to greater assurance that the indicated software
is present on the endpoint. Currently, most SWID tag creators do entire interval when it was not provide values for tag fields that support local testing. For
this reason, the added complexity of supporting endpoint testing
using these fields is out of scope for this specification. Future
versions of this specification might add support for such testing. connected.

2.4. Specification Requirements

Below Non-Requirements

There are the certain requirements that the SWID Software Message and
Attributes for PA-TNC specification explicitly is not required to meet in order
meet. This list is not exhaustive.

o End to successfully
play its role in End Confidentiality

This specification does not define mechanism for confidentiality, nor
is this property automatically provided by PA-TNC interface use.
Confidentiality is generally provided by the NEA architecture.

o Efficient

The NEA architecture enables delay of network access until underlying transport
protocols, such as the
endpoint is determined not PT Binding to pose a security threat TLS [RFC6876] or PT-EAP Posture
Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more
information on related standards. Should users wish confidentiality
protection of assessment instructions or results, this needs to be
provided by parts of the network
based on its asserted integrity information. To minimize user
frustration, NEA architecture other than this
specification.

2.5. Assumptions

Here are the SWID assumptions that Software Message and Attributes for PA-TNC ought to
minimize overhead delays PA-
TNC makes about other components in the NEA architecture.

o Reliable Message Delivery
The Posture Broker Client and make Posture Broker Server are assumed to
provide reliable delivery for PA-TNC communications as rapid messages and
efficient as possible.

Efficiency is also important when one considers that some network
endpoints are small and low powered, some networks are low bandwidth
and/or high latency, and some transport protocols (such as PT-EAP,
Posture Transport (PT) Protocol for Extensible Authentication
Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
protocol might allow only one packet in flight at a time or only one
roundtrip. However, when therefore the underlying PT protocol imposes fewer
constraints on communications, this protocol ought to be capable of
taking advantage of more robust communication channels (e.g. using
larger messages or multiple roundtrips).

o Loosely Coupled to
Attributes sent between the SWID Specification

Because SW PCs and the SWID specification is managed by ISO/IEC, PVs. In the IETF has no
direct influence over this specification event that
reliable delivery cannot be provided, the Posture Collector or any revisions made
Posture Validator is expected to it.
For this reason, terminate the SWID connection.

2.6. Non-Assumptions

The Software Message and Attributes for PA-TNC specification ought to minimize its requirements and assumptions with
regard to the structure
explicitly does not assume:

o Authenticity and content Accuracy 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 Software Inventory Evidence
Collection with future revisions of the SWID
specification.

o Scalable

SWID Message and Attributes for PA-TNC needs to be usable in
enterprises that contain tens of thousands of endpoints or more. As
such, it needs Regard to allow a security tools Endpoint Inventory

This specification makes no assumption as to make decisions based on
up-to-date whether the software
information about an endpoint's that it reports correctly reflect the software inventory without
creating an excessive burden state on
the enterprise's network.

o Interoperable endpoint. This specification defines does not attempt to detect when the protocol for how PCs and PVs can
exchange
endpoint is providing false information, either through malice or
error, but instead focuses on correctly and use SWID tags reliably providing the
reported Software Inventory Evidence Collection to provide a the NEA Server with information
about an endpoint's software inventory. Therefore a key goal for Server.
Similarly, this specification is ensuring that all SWID PCs and PVs, regardless
of the vendor who created them, are able makes no assumption with regard to interoperate in their
performance the
completeness of these duties.

o Support precise and complete historical reporting

This specification is expected to outline capabilities that support
real-time understanding the Software Inventory Evidence Collection's coverage
of the state total set of endpoint in a network in a
way software installed on the endpoint. It is
possible, and even likely, that can be used by other tools. One means of facilitating such
an outcome some installed software is for not
represented by a Configuration Management Database (CMDB) to be
able to contain information about all record in an endpoints connected to the
enterprise Software Inventory Evidence
Collection. See Section 6 for all points in time between more on this security consideration.

2.7. Software Message and Attributes for PA-TNC Diagram Conventions

This specification defines the endpoint's first
connection syntax of the Software Message and
Attributes for PA-TNC using diagrams. Each diagram depicts the present. In such a scenario, it is necessary that
any PC be able to report any changes to its SWID tag collection
format and size of each field in
near real-time while connected and, upon reconnection to bits. Implementations MUST send the
enterprise, be able
bits in each diagram as they are shown from left to update the NEA Server (and through it right for each
32-bit quantity traversing the
CMDB) with regard diagram from top to bottom. Multi-
octet fields representing numeric values MUST be sent in network (big
endian) byte order.

Descriptions of bit fields (e.g. flags) values refer to the state position
of its SWID tag collection throughout the entire interval when it was not connected.

2.5. Non-Requirements

There bit within the field. These bit positions are certain requirements that numbered from
the SWID 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 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
0001).

3. Software Message and Attributes for PA-TNC System Requirements

The Software Message and Attributes for PA-TNC specification explicitly is not required to meet. This
list is not exhaustive.

o End to End Confidentiality

SWID tags have no inherent mechanism
facilitates the exchange of software inventory and event information.
Specifically, each application supporting Software Message and
Attributes for confidentiality, nor is this
property automatically provided by PA-TNC interface use.
Confidentiality includes a component known as the SW-PC that
receives messages sent with the SW Attributes component type. The
SW-PC is generally provided by also responsible for sending appropriate SW Attributes back
to the underlying transport
protocols, such as SW-PV in response. This section outlines what software
inventories and events are and the PT Binding requirements on SW-PCs and SW-PVs
in order to TLS [RFC6876] or PT-EAP Posture
Transport for Tunneled EAP Methods [RFC7171] - see Section 7 for more
information on related standards. Should users wish confidentiality
protection support the stated use cases of assessment instructions or results, this needs to be
provided by parts of specification.

3.1. Basic Inventory Exchange

In the NEA architecture other than most basic exchange supported by this
specification.

2.6. Assumptions

Here are specification, a SW-PV
sends a request to the assumptions that SWID Message and Attributes for PA-TNC
makes about other components SW-PC requesting all inventory information in
the NEA architecture.

o Reliable endpoint's Software Inventory Evidence Collection. This simple
exchange is shown in Figure 2.

+-------------+ +--------------+
| SW-PC | | SW-PV | Time
+-------------+ +--------------+ |
| | |
|<--------------SW Request----------------| |
| | |
|---------------SW Response-------------->| |
| | V

Figure 2: Basic SW Message Delivery

The Posture Broker Client and Posture Broker Server are assumed to
provide reliable delivery for PA-TNC messages and therefore the SWID
Attributes sent between the SWID PCs and the PVs. In Exchange

Upon receiving such a SW Request from the event that
reliable delivery cannot be provided, SW-PV, the Posture Collector or
Posture Validator SW-PC is
expected to terminate collect all inventory information from the connection.

2.7. Non-Assumptions

The SWID Message endpoint's
software evidence collection and Attributes place it within its response
attribute.

SW-PVs MUST discard without error any SW Response attributes that
they receive for PA-TNC specification explicitly
does which they do not assume:

o Authenticity and Accuracy of SWID tags with Regard know the SW Request parameters
that led to Endpoint
Inventory this SW Response. This specification makes no assumption as is due to whether the SWID tags fact that it reports are authentic tags (rather than maliciously
generated) or the SW
Request includes parameters that these tags correctly reflect software state on control the
endpoint. This specification does not attempt to detect when nature of the
endpoint is providing false information, either through malice or
error, but instead focuses on correctly response
(as will be described in the following sections) and without knowing
those parameters the SW Response cannot be reliably providing interpreted.
Most often receiving an unsolicited SW Response attribute happens
when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request
but, unless exclusive delivery is used by the
existing SWID tags to SW-PC in sending the NEA Server. Similarly,
response, both SW-PVs receive copies of the resulting SW Response.
In this specification
makes no assumption with regard to case, the completeness of SW-PV that didn't send the SWID tag
collection's coverage of SW Request would lack
the total set of software installed on context necessary to correctly interpret the
endpoint. It is possible, SW Response it
received and even likely, would simply discard it. Note, however, that some installed
software is not represented by
proprietary measures might allow a tag in an endpoints SWID tag
collection. See Section 5 for more on this security consideration.

2.8. SWID Message and Attributes for PA-TNC Diagram Conventions

This specification defines the syntax of SW-PV to discover the SWID Message and
Attributes SW Request
parameters for PA-TNC using diagrams. Each diagram depicts the
format and size of each field in bits. Implementations MUST a SW Response even if that SW-PV did not send the
bits in each diagram as they
given SW Request. As such, there is no blanket requirement for a SW-
PV to discard all SW Responses to SW Request the SW-PV did not
generate itself, only that SW-PVs are shown from left required to right discard SW
Responses for each
32-bit quantity traversing the diagram from top which they cannot get the necessary context to bottom. Multi-
octet fields representing numeric values MUST be sent in network (big
endian) byte order.

Descriptions of bit fields (e.g. flags) values refer
interpret.

In the case that it is possible to do so, the position
of SW-PC SHOULD send its
SW Response attribute to the bit within SW-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 field. These bit positions are numbered from sender of the most significant bit through SW Request
receives the least significant bit. As such,
an octet with only bit 0 set would have resulting SW Response.

3.2. Software Identifiers

Software information records contain a value large amount of 0x80 (1000 0000),
an octet with only bit 1 set would have a value descriptive
information about installed software products. However, in many
cases the complete level of 0x40 (0100 0000),
and an octet with only bit 7 set would have a value detail in these records is not necessary.
For example, if one is simply tracking the installation or removal of 0x01 (0000
0001).

3. SWID
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 System Requirements
supports the use of Software Identifiers.

A Software Identifier uniquely identifies a specific version of a
specific software product. The SWID Software Message and Attributes for
PA-TNC specification facilitates does not dictate the exchange structure 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 Software
Identifier (beyond stating that receives
messages sent with the SWID Attributes component type. The SWID-PC it 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 string) or define how it is responsible
created. Instead, each data model described in the Software Data
Model IANA table (Section 9.4 includes its own rules for interpreting responses, forwarding
information to how a CMDB if desired, and making policy decisions
Software Identifier is created 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 a record in order to support the
stated use cases of this specification.

3.1. SWID Tags as Endpoint's
Software Inventory Evidence

As noted Collection expressed in Section 2.1, SWID tags are intended to be open, easily
accessible evidence indicating that data model.
Within the presence of a particular piece of
software on Software Message and Attributes for PA-TNC specification,
the Software Identifier is simply an endpoint. A SWID tag contains multiple fields
intended opaque string.

Software Identifiers allow SW Response messages to uniquely identify a single software product. Ideally,
to a
SWID tag is managed by server at a fraction of the software bandwidth that installs, modifies,
replaces, amends (e.g. patches, updates), and/or uninstalls would be needed to
send the
product. Discovery processes, software package managers, and other
tools can also create entire associated record. For some combinations of data
models and manage tags sources, the full record might never be necessary as a way to represent software
that they discover or manage on the endpoint.

It is important
identifier can be directly correlated to note that, even in the ideal cases where a product
manages its own contents of the full
record. This is possible with authoritative SWID tag, tags, since these
tags always have the same contents and thus a tag is inherently distinct Software Identifier
derived from the
product that it identifies. For this reason, a SWID tag needs to be
treated as evidence of software presence, but cannot these tags can be treated used as
proof of software presence. That noted, a standardized
representation lookup to a local copy of evidence indicative
the full tag. For other combinations of an endpoint's software
inventory is source and data model, a powerful tool in managing
server might not be able to determine the specific software within an
enterprise.

3.2. Basic SWID Tag Inventory Exchange

In product
and version associated with the most basic exchange supported by this specification, a SWID-PV
sends identifier without requesting deliver
of the full record. In either case, however, a request SW-PV can use
Software Identifiers to track the SWID-PC requesting presence of specific software
products on an endpoint over time in a copy bandwidth-efficient manner.

There are two important limitations of all Software Identifiers to keep
in mind:

The identifiers do not necessarily change when the SWID tags associated
record changes. In some situations, a record in the endpoint's SWID tag collection. This simple exchange is shown
Software Inventory Evidence Collection will change due to new
information becoming available or in Figure 2.

+-------------+ +--------------+
| SWID-PC | | SWID-PV | Time
+-------------+ +--------------+ |
| | |
|<-------------SWID Request---------------| |
| | |
|--------------SWID Response------------->| |
| | V

Figure 2: Basic SWID Message Exchange

Upon receiving such a SWID Request from order to correct prior errors
in that information. Such changes might or might not result in
changes to the SWID-PV, Software Identifier, depending on the SWID-PC is
expected to locate nature of the endpoint's SWID tags
changes and then create copies the rules governing how Software Identifiers are
derived from records of
all identified SWID tags and place them within its response
attribute.

SWID-PVs MUST discard without error any SWID Response attributes the appropriate data model.

It is possible that
they receive a single software product is installed on a
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 which they each installation instances. In other words, Software
Identifiers do not know the SWID Request parameters
that led uniquely identify installation instances; they
just uniquely identify software products (which might have more
than one installation instance). Instead, to this SWID Response. This is due distinguish between
multiple instances of a single software product, one needs to the fact that the
SWID Request includes parameters that control the nature make
use of the
response (as will be Record Identifiers, described in the following sections) and without
knowing those parameters the SWID Response cannot be reliably
interpreted. Most often receiving an unsolicited SWID Response
attribute happens when a NEA Server has multiple SWID-PVs; one SWID-
PV sends a SWID Request but, unless exclusive delivery section.

3.2.1. Record Identifiers

A Record Identifier is used a string generated by the
SWID-PC in sending the response, both SWID-PVs receive copies of the
resulting SWID Response. In this case, the SWID-PV SW-PC that didn't send
the SWID Request would lack is
uniquely associated with a specific record within the context necessary Endpoint's
Software Inventory Evidence Collection. The SW-PC MUST assign a
unique identifier to correctly
interpret the SWID Response each record when it received and would simply discard it.
Note, however, is added to the Endpoint's
Software Inventory Evidence Collection. The Record Identifier SHOULD
remain unchanged if that proprietary measures record is modified. The SWID-PC might allow a SWID-PV wish
to
discover the SWID Request parameters for a SWID Response even if assign Record Identifiers sequentially, but any scheme is
acceptable provided that
SWID-PV did not send no two records receive the given SWID Request. As such, there same identifier.

Servers can use Record Identifiers to distinguish between multiple
instances of a single software product installed on an endpoint.
Since each installation instance of a software product is no
blanket requirement for associated
with a SWID-PV to discard all SWID Responses to
SWID Request separate record, servers can use the SWID-PV did not generate itself, only that SWID-PVs
are required record identifier to discard SWID Responses for which they cannot get
distinguish between instances. For example, if an event is reported
(as described in Section 3.5), the
necessary context to interpret.

In record identifier will allow the case that it
server to discern which instance of a software product is possible involved.

3.2.2. Using Software and Record Identifiers in SW 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 do so, the SWID-PC MAY send its
SWID 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 SWID-PV that requested it using
exclusive delivery as described in section 4.5 attribute size of RFC 5793 (PB-TNC)
[RFC5793]. Exclusive delivery ensures that only the sender response by multiple
orders of magnitude when compared to sending the
SWID same inventory using
full records. A SW-PC responds to a SW Request receives attribute requesting
Software Identifiers the resulting SWID Response. However, SWID
Message and Attributes same way it responds to a request for PA-TNC does not require support 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
exclusive delivery each record.

All SW Response attributes include Record Identifiers for each
reported record. This is true regardless of attributes. whether the record is
delivered in full or represented by a Software Identifier.

3.3. SWID Tag Identifiers

SWID tags can contain Targeted Requests

Sometimes a great deal of SW-PV does not require information about a software
product. In addition to identifying name, manufacturer, and version every piece 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 an endpoint but only needs to indicate when the SWID tag was last
checked for accuracy relative receive updates about
certain software instances. For example, enterprise endpoints might
be required to the endpoint's installed have certain software products installed 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 keep
these updated. Instead of requesting a SWID tag complete inventory just to
see if these products are present, the SW-PV can be useful make a "targeted
request" for reasoning about details of
an endpoint's the 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 question.

Targeted requests follow the complete tag. All tags same message exchange described in
Figure 2. The SW-PV targets its request by providing one or more
Software Identifiers in its SW Request attribute. The SW-PC MUST
then limit its response to contain specific fields only records that can be used match the
indicated Software Identifier(s). This allows the network exchange
to distinguish a tag for a
particular piece of software from tags for different pieces of
software. The Tag Creator RegID exclude information that is not relevant to a string that uniquely identifies
the creator of this SWID tag (who given policy
question, thus reducing unnecessary bandwidth consumption. The SW-
PC's response might consist of full records or might not be the same as
the entity who created of Software
Identifiers, depending on the described software) while parameters of the Unique ID is
a string SW Request.

Note that uniquely identifies targeted requests identify the described piece of software
according relevant to that tag creator. These two pieces the
request only through Software Identifiers. This specification does
not support arbitrary, parameterized querying of information
together create records. For
example, one cannot request all records from a "tag identifier".

3.3.1. Tag Identifier Data

Some attributes defined in this specification contain fields certain software
publisher, or all records created by a particular record source.
Targeted requests only allow a requestor 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 request specific fields of software
(as identified by their Software Identifiers) and receive a SWID tag response
that correspond is limited to the
Tag Creator RegID and Unique ID values vary between the different
releases of the ISO SWID tag specification. It named software.

There is important to note
that, in all other parts of this specification, no assumption that a SW-PC will recognize "synonymous
records" - that is, records from different sources for the terms Tag Creator
RegID same
software. Recall that different sources 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 data models may use
different Software Identifier strings for the Tag Creator
RegID, identify same software product.
The SW-PC returns only records that match the field containing Software Identifiers in
the regid value of SW Request, even if there might be other records in the entity
that created
endpoint's Software Inventory Evidence Collection for the given SWID tag. Note that this same
software product. This is necessary because SW-PCs might not be have
the
same entity ability to determine that created two Software Identifiers refer to the software.
same product.

Targeted requests do not include Record Identifiers. The Tag Creator RegID response to
a targeted request MUST be
the regid, rather than any prose name that might be include all records 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 named
Software Identifiers, including 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 case where there are multiple
records associated with a single field within the SWID tag, rather than a
concatenation Software Identifier.

SW-PCs MUST accept targeted requests and process them correctly as
described above. SW-PVs MUST be capable of multiple fields. In particular, SWID tags often
contain designated fields for just making targeted requests
and processing the product name, product version,
product edition, etc., but these fields are responses thereto.

3.4. Monitoring Changes in an Endpoint's Software Inventory Evidence
Collection

The software collection on an endpoint is not used to populate static. As software is
installed, uninstalled, patched, or updated, the
Unique ID. Instead, look for a single field that Software Inventory
Evidence Collection is designed expected to
uniquely identify a specific software product, version, etc. (and
thus uniquely identifies a specific tag, at least according change to reflect the
tag's creator).

Consult the ISO/IEC specification for the specific fields that
correspond to new software
state on the requirements of endpoint. Different record sources might update the Tag Creator RegID and Unique
ID, as defined above.
evidence collection at different rates. For example, a package
manager might update its records in the 2009 version 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 ISO/
IEC SWID specification [SWID], endpoint would likely only update their records in
the Tag Creator RegID corresponds Software Inventory Evidence Collection after each examination.

All SW-PCs MUST be able to be able to detect changes to the value Software
Inventory Evidence Collection. Specifically, SW-PCs MUST be able to
detect:

o The creation of the software_identification_tag/software_id/
tag_creator_regid field in a SWID tag. records

o The Unique ID corresponds to deletion of records

o The alteration of records
An "alteration" is anything that modifies the value contents of a record
(or would modify it, if the software_identification_tag/software_id/unique_id
field record is dynamically generated on
demand) in a SWID tag. In subsequent releases any way, regardless of whether the ISO/IEC SWID
specification, different fields might be used to convey change is functionally
meaningful.

SW-PCs MUST detect such changes to the same
information.

3.3.2. Tag Identifier Instances

A tag identifier endpoint's Software Inventory
Evidence Collection in close to real-time (i.e., within seconds) when
the combination of the Tag Creator RegID and Posture Collector is operating. In addition, in the Unique ID fields) uniquely identifies case where
there is a particular SWID tag, period during which corresponds the SW-PC is not operating, the SW-PC
MUST be able to a single software product. Assuming that this
product manages its own SWID tag (i.e., creates determine the tag on
installation and deletes net change to the tag when endpoint's Software
Inventory Evidence Collection over 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 period it was not operational.
Specifically, the same tag
identifier field values. (Presence of SWID tags managed by other
tools, such as discovery tools, would also depend on "net change" represents the presence difference between the
state of
those tools on the device.) In fact, if multiple instances endpoint's Software Inventory Evidence Collection when
the SW-PC was last operational and monitoring its state, and the
state of the
same endpoint's software product are installed on a single device (i.e., it has
been installed twice in different locations) inventory evidence collection when
the SW-PC resumed operation. Note that device would have
two instances of a net change might not
reflect the same SWID tag, one for each installation. Both
instances total number of change events over this interval. For
example, if a record was altered three times during a period when the SWID tag would have
SW-PC was unable to monitor for changes, the same tag identifier field
values. This is true even though the tags themselves net change of this
interval might differ
with regard only note that there was an alteration to their installation-specific tag fields. In the record,
but not how many cases
it individual alteration events occurred. It is important to distinguish between instances of
sufficient for a particular tag
on SW-PC's determination of a particular endpoint. For example, if one is alerted net change to the
deletion of note that
there was a particular SWID tag difference between the earlier and there are multiple instances of current state rather
than enumerating all the individual events that SWID tag on allowed the endpoint, one will likely wish current
state 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. be reached.

The exact nature of the Instance
ID depends on the source of SW-PC MUST assign a time to each detected change in the SWID tag. If
endpoint's Software Inventory Evidence Collection. These timestamps
correspond to the SWID tag is
represented SW-PC's best understanding as a file on disk, to when the Instance ID might detected
change occurred. These timestamps MUST be as accurate as possible.
For changes to the full path
of endpoint's Software Inventory Evidence Collection
that occur while the SWID tag file, including SW-PC is operating, the name of SW-PC ought to be able
to assign a time to the SWID tag file itself.
(Note event that is accurate to within a few
seconds. For changes to the SWID tag filename MUST be included in endpoint's Software Inventory Evidence
Collection that occur while the tag file
path because it SW-PC is possible for two SWID tags, each for different
instances of not operational, upon
becoming operational the same software product, SW-PC needs to make a best guess as to co-exist in the same
directory under different file names.)
time of the relevant events (possibly by looking at timestamps on
files), but these values might be off. In the case that the SWID tag
is of dynamically
generated upon request by some source, such as an RPM
or YUM package manager, records, the generation process MUST create an
Instance ID to distinguish instances of a particular tag. Inclusion time of this Instance ID ensures each tag change is uniquely identified on a
given endpoint.

To the extent that it is possible, time at which the generation of Instance IDs
SHOULD be repeatable for a single installation of a single SWID tag.

In data
from which the case where a product is installed once, and then SWID tags records are
generated upon request, each time generate changes, not the SWID tag time at which a
changed record is generated the tag
identifier instance SHOULD all have the same Instance ID value. generated. For example, if a package manager generates a SWID tag in response to a
request records are dynamically
generated based on some record it possesses, and then later generates data in an RPM database, the SWID tag again based on time of change would
be when the same RPM record was changed.

With regard to deletions of package installation,
then records, the same Instance ID value SHOULD be created both times. This
is necessary to allow remote parties SW-PC needs to understand whether a reported
SWID tag instance is for detect the same product installation they saw
reported earlier or if it represents
deletion and MUST retain a new installation copy of the same
product. Note, however, that some exceptional situations might
result in full deleted record along with
its Record Identifier so that the record itself can be provided to
the changing SW-PV upon request. This copy of a product's Instance ID. For example, it
is not explicitly prohibited by the SWID specification record MUST be retained for tags to
move after installation,
a reasonable amount of time. Vendors and thus have their tag file path change.
If administrators determine
what "reasonable" means, but a copy of the file path was used record SHOULD be retained
for as long 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 event recording the deletion of the record remains
in the SW-PC's event log (as described in Section 3.5). This is
recommended because, as long as the event is in the SW-PC's change
logs, the SW-PC might send an event attribute (described in
Section 3.5) that references this
possibility.

The combination of record, and a tag identifier with an Instance ID copy of the record is referred
to as
needed if the SW-PV wanted a "tag identifier instance". A tag identifier instance
uniquely identifies full copy of the relevant records.

With regard to alterations to a particular instance record, SW-PCs MUST detect any
alterations to the contents of a particular tag record. Alterations need to be
detected even if they have no functional impact on the record. A
good guideline is that any alteration to a
given endpoint. Note record that two endpoints might produce identical tag
identifier instances, but these do not mean that change
the tag files value of a hash taken on the
two endpoints are identical - record's contents needs to be
detected by the tags in question indicate SW-PC. A SW-PC might be unable to distinguish
modifications to the same
software product on both endpoints (since content of a record from modifications to the respective tag
identifiers are identical), but
metadata the tags file system associates with the record. For example, a
SW-PC might use the "last modification" timestamp as an indication of
alteration to a given record, but a record's last modification time
can change for reasons other than modifications to the record
contents. A SW-PC is still differ in their
installation-specific fields. Therefore, considered compliant with this
specification if it is important to remember also reports metadata change events that tag identifier instances do not
change the record itself as alterations to the record. In other
words, while SW-PC authors are only comparable in encouraged to exclude modifications
that do not affect the scope of a
single endpoint; when comparing across different endpoints, only bytes within the
tag identifier fields (Tag Create RegID record, discriminating
between modifications to file contents and Unique ID) can be
meaningfully compared - any Instance ID value will need changes to file metadata
can be
excluded from comparison.

3.3.3. Comparing Tag Identifiers difficult and Tag Identifier Instances

Comparison time consuming on some systems. As such, as
long as the alterations detected by a SW-PC always cover all
modifications to the contents of tag identifiers can be used record, the SW-PC is considered
compliant even if it also registers alterations that do not modify
the contents of a record as well. When recording an alteration to determine whether a
particular SWID tag
record, the SW-PC is present in only required to note that an endpoint's SWID tag collection.
A pair of SWID tag identifiers alteration
occurred. The SW-PC is said not required to "match" if their Tag
Creator RegID and Unique ID fields are identical. Similarly, a pair
of tag identifier instances note or record how the record
altered, nor is said it possible to match if their Tag Creator
RegID, Unique ID, and Instance ID fields are identical. Fields include such details in
SWID Message and SW 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
reporting the
corresponding values from other sources (such as when comparing them change to a full SWID tag file or similar record), the relevant fields from SW-PV.

3.5. Reporting Change Events

As noted in the latter need preceding section, SW-PCs MUST be able to undergo normalization prior detect
changes to comparison. See
Section 4.7 for more on normalization of the encoding for these
fields. Comparisons are case-sensitive.

Matching tag identifiers endpoints software inventory evidence collection
(creation, deletion, and tag identifier instances indicate very
specific things about alteration) in near real-time while the respective tags. The following sections
describe what one can SW-
PC is operational, and cannot deduce based on matching tag
identifiers.

3.3.3.1. Matching Tag Identifiers Indicate MUST be able to account for any net change to
the Same endpoint's Software Product

The Unique ID value of a tag identifier represents a value Inventory Evidence Collection that occurs
when the
given tag creator will only use SW-PC is not operational. However, to indicate a particular software
product (e.g., a particular release be of a particular application).
The ISO SWID specification prohibits the tag creator from associating
a Unique ID value with multiple, different software products. At use to the
same time,
enterprise, the Tag Creator RegID element value uniquely identifies a
given tag creator. As such, even if two different tag creators were NEA Server needs to assign the same Unique ID value be able to two different software
products, the Tag Creator RegID values will receive these events
and be different, able to understand how new changes relate to earlier changes.
In Software Message and
therefore the tag identifiers will Attributes for PA-TNC, this is facilitated by
reporting change events. All SW-PCs MUST be different. For these reasons, capable of receiving
requests for change events and sending change event attributes. All
SW-PVs MUST be capable of requesting and receiving change event
attributes.

3.5.1. Change Event Records

A change event record consists of either a complete record or
Software Identifier from the expectation is that if one sees two tags changed record along with the same tag
identifiers, these tags are both associated with following
pieces of information:

o The nature of the same software
product (assuming change (i.e., creation, deletion, or lteration)

o An Event Identifier (EID) value

o An EID Epoch value

An EID is a 4-byte unsigned integer that the tag's fields are correctly populated).

3.3.3.2. Matching Tag Identifiers DO NOT Necessarily Indicate Identical
Tag Files

Some optional fields SW-PC assigns
sequentially to each observed event (whether detected in SWID tags can reflect installation-specific
information. As such, the SWID tags real-time or
deduced by looking for net changes over a piece period of software residing
on two different endpoints (or installed twice on SW-PC
inactivity). All EIDs exist within the context of some "EID Epoch",
which is also represented as a single endpoint)
will have 4-byte unsigned integer. EID Epochs
are used to ensure synchronization between the same tag identifier value (same tag creator SW-PC and any SW-PVs
with which it communicates. EID Epoch values SHOULD be generated
randomly and in such a way that it is unlikely that the same Unique ID for EID
Epoch is generated twice, even if 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 SW-PC reverted to an earlier
state (e.g., resetting it to factory defaults). In the tags on those endpoints are identical in case where a
SW-PC needs to reset its EID counter, either because it has exhausted
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
specification indicate that modification of SWID tags might no longer
be permitted by parties other than the original tag creator (usually
the vendor of the software identified by available EID values or because the tag). If this SW-PC's event log becomes
part of the revised SWID specification,
corrupted, then for SWID tags that
conform to this revised specification, this will mean that matching
tag identifiers do imply identical tag files.

3.3.3.3. Matching Tag Identifier Instances MIGHT Indicate Identical Tag
Files

For a single endpoint, matching tag identifier instance values might
indicate identical tag files, at least within a narrow time window.
Tag identifier instance values are unique to a specific SWID tag
record on new EID Epoch MUST be selected.

Within an Epoch, EIDs MUST be assigned sequentially, so that particular endpoint at if a
particular point in time.
The Instance ID in event is assigned an EID of N, the tag identifier instance information ought to
be unique relative to any other instances next observed event is
given an EID of N+1. In some cases, events might occur
simultaneously, or the same SWID tag
currently also on that endpoint. However, tag identifier instances
are still SW-PC might not guaranteed to otherwise be unique able to a single SWID tag file over
a long period of time. Consider a piece determine
an ordering for events. In these cases, the SW-PC creates an
arbitrary ordering of software that is
installed (adding a SWID tag), uninstalled (removing the SWID tag), events 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 assigns EIDs according to this
ordering. Two change events MUST NOT ever be assigned the tag files
themselves were different.

As noted above, SWID tag identifier instances are only comparable same EID
within the context of a single endpoint. When SWID tag identifier
instances are collected from multiple endpoints and then compared,
the Instance ID MUST be ignored in any same EID Epoch. No meaningful comparison can be made
between EID values of tag identifiers
from different endpoints.

3.3.3.4. Differing Tag Identifiers DO Epochs.

The EID value of 0 is reserved and MUST NOT Necessarily Indicate
Different Software Products

While a tag identifier uniquely identifies a software product (i.e.,
that tag identifier cannot be associated with any
event. Specifically, an EID of 0 in a different software
product), SW Request attribute indicates
that a single product might have more SW-PV wants an inventory response rather than one tag identifier.
This is because it an event
response, while an EID of 0 in a SW Response is possible for more than one tag creator used to
create a SWID tag for indicate the same software product. Multiple tags for
initial state of 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 endpoint's Software Inventory Evidence
Collection prior to the same
software product. In fact, in some circumstances, two parties might
create two different SWID tag records for a single instance observation of any events. Thus the
same software product. For example, when very
first recorded event in a product is installed, it
creates SW-PC's records within an EID Epoch MUST be
assigned a SWID tag file on value of 1 or greater. Note that EID and EID Epoch values
are assigned by the file system, SW-PC without regard to whether events are being
reported to one or more SW-PVs. The SW-PC records events and a software discovery
tool also notes assigns
EIDs during its operation. Any and all SW-PVs that request event
information from the installation of SW-PC will have those requests served from the product
same event records and generates its own
SWID tag record for thus will see 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 EIDs and EID Epochs for
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 SWID attribute reporting an endpoint's SWID tag collection can
contain SWID tag identifier instances instead of copies of SWID tag
files. events.

The message exchange SW-PC MUST ensure there is identical to the diagram shown no coverage gap (i.e., change events
that are not recorded in
Figure 2, but the contents SW-PC's records) in its change event
records. This is necessary because a coverage gap might give a SW-PV
a false impression 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 endpoint's state. For example, if a SW-PV
saw an event indicating that a particular record had been added to sending
the same endpoint's software 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 evidence collection, and saw no
subsequent events indicating that instead of copying each SWID tag entirely into the
attribute body of the response, record had been deleted, it provides the specific values that
comprise a SWID tag identifier instance for each tag.

3.4. Targeted Requests

Sometimes a SWID-PV does not require information about every tag on
an endpoint but only needs to know about certain tags. For example,
an endpoint might be required to have a particular patch installed.
In determining compliance with
reasonably assume that this policy, record was still present and thus that
the indicated software was still installed (assuming the SWID-PV Epoch has
not changed). If there is only
interested a coverage gap in the specific SWID tag associated with SW-PC's event
records, however, this patch.
Instead of requesting a complete inventory just to see if the patch's
SWID tag assumption is present, false. For this reason, the SWID-PV can make a "targeted request" for SW-
PC's event records MUST NOT contain gaps. In the tag in question.

Targeted requests follow case where there
are periods where it is possible that changes occurred without the same message exchange described in
Figure 2. The SWID-PV targets its request by providing one
SW-PC detecting or more
SWID tag identifiers in its SWID Request attribute. The SWID-PC recording them, the SW-PC MUST
then limit either compute a
net change and update its response event records appropriately, or pick a new
EID Epoch to contain only tags that match the indicated
tag identifier(s). This allows the network exchange indicate a discontinuity with previous event records.

Within a given Epoch, once a particular event has been assigned an
EID, this association MUST NOT be changed. That is, within an Epoch,
once an EID is assigned to exclude
information an event, that is not relevant EID cannot be reassigned to
a given policy question, thus
reducing unnecessary bandwidth consumption. The SWID-PC's response
might consist of full tags or of tag identifier instances, depending
on the parameters of different event, and the SWID Request.

Targeted requests event cannot target specific SWID tag instances; be assigned a different EID.
When the SWID
Request does not include fields SW-PC's Epoch changes, all of these associations between
EIDs and events are cancelled, and EID values once again become free
for Instance IDs. As a result, when
responding assignment.

3.5.2. Updating Inventory Knowledge Based on Events

Modern endpoints can have hundreds of software products installed,
most of which are unlikely to change from one day to the next. As
such, instead of exchanging a targeted request, a SWID-PC MUST return applicable
results for every instance complete list of the identified tags.

Note that targeted requests identify the SWID tags relevant an endpoint's
inventory on a regular basis, one might wish to the
request only through SWID tag identifiers for those tags. This
specification does not support arbitrary, parameterized querying identify changes
since some earlier known state of
tags. For example, one cannot request all tags from a certain
software publisher, or all tags created this inventory. This is readily
facilitated by the use of EIDs to place change events in a particular tag creator.

Targeted requests only allow context
relative to earlier state.

Every inventory sent by a requestor SW-PC to request specific tags a SW-PV (as
identified by their tag identifiers) described in
Section 3.1 through Section 3.3) includes the EID Epoch and receive a response EID of
the last event recorded prior to that is
limited inventory being compiled. This
allows the SW-PV to place all subsequently received event records in
context relative to this inventory (since the named tags. There is also no assumption that EIDs represent a SWID-
PC will recognize "synonymous tags" - that is, tags by different tag
creators for total
ordering of all changes to the same endpoint's software product. The SWID-PC returns only
tags inventory evidence
collection). Specifically, a SW-PV (or, more likely, a database that match
collects and records its findings) can record an endpoint's full
inventory and also the tag identifiers in EID and Epoch of the SWID Request, even if
there might be other SWID tags most recent event
reflected in that state. From that point on, if change events are
observed, the endpoint's SWID tag collection
for attribute describing these events indicates the same software product.

SWID-PCs MUST accept targeted requests and process them correctly as
described above. SWID-PVs MUST be capable nature
of making targeted
requests the change, the affected records, and processing the responses thereto.

3.5. Monitoring Changes order in an Endpoint's SWID Tag Collection

The SWID collection on an endpoint is not static. As software is
installed, uninstalled, patched, or updated, the SWID tag collection
is expected to change to reflect the new software state on the
endpoint. For tags managed which these
events occurred (as indicated by an application's installer, tag
changes usually occur at the time sequential EIDs). Using this
information, any remote record 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 Software Inventory
Evidence Collection can be able to detect changes to the SWID
tag repositories on their endpoint. Specifically, SWID-PCs updated appropriately.

3.5.3. Using Event Records in SW Attributes

A SW-PV MUST be able to detect:

o The creation request a list of tags

o The deletion event records instead of tags

o an
inventory. The alteration of tags

An "alteration" is anything that modifies message flow in such an exchange looks the contents of a SWID tag
file (or would modify it, if same as
the tag file basic flow shown in Figure 2. The only difference is dynamically generated on
demand) that, in any way, regardless of whether
the change is functionally
meaningful. Changes MUST be monitored for all utilized sources SW Request attribute, the SW-PV provides an EID other than 0. (A
value of
SWID tags. This includes, but is not limited to, monitoring sources
that dynamically generate SWID tags.

SWID-PCs MUST detect 0 in these fields represents a request for an inventory.)
When the SW-PC receives such changes to a request, instead of identifying
records from the endpoint's SWID tag
collection in close to real-time (i.e., within seconds) when the
Posture Collector is operating. In addition, in the case where there
is a period during which the SWID-PC is not operating, the SWID-PC Software Inventory Evidence Collection,
it consults its list of detected changes. The SW-PC MUST be able add an
event record to determine the net SW Response attribute for each recorded change
event with an EID greater than or equal to the endpoint's SWID tag
collection over the period it was not operational. Specifically, the
"net change" represents the difference between the state of the
endpoint's SWID tag collection when the SWID-PC was last operational
and monitoring its state, and EID in the state SW Request
attribute (although targeting of requests, as described in the endpoint's SWID tag
collection when the SWID-PC resumed operation. Note that a net
change next
paragraph, might not reflect the total number limit this list). A list of change event records MUST only
contain events over this
interval. For example, if a SWID tag file was altered three times
during a period when with EIDs that all come from the SWID-PC was unable to monitor current Epoch.

SW-PVs can target requests for changes, event records by including one or more
Software Identifiers, as described in Section 3.3, in the net change of this interval might only note SW Request
that there was requests an
alteration to the file, but not how many individual alteration events
occurred. It is sufficient event record list. A targeted request for a SWID-PC's determination of a net
change event
records is used to note indicate that there was a difference between the earlier and
current state rather than enumerating all the individual only events affecting software that
allowed
match the current state provided Software Identifiers are to be reached.

The SWID-PC MUST assign a time to each detected change returned.
Specifically, in the
endpoint's SWID tag collection. These timestamps correspond to the
SWID-PC's best understanding as response to when a targeted request for event records,
the detected change occurred.
These timestamps SW-PC MUST be as accurate as possible. For changes to the
endpoint's SWID tag collection exclude any event records that occur while the SWID-PC is
operating, are less than the SWID-PC ought to be able to assign a time to
indicated EID (within the current EID Epoch) and exclude any event
that is accurate to within a few seconds. For changes to the
endpoint's SWID tag collection that occur while
records where the SWID-PC is affected software does not
operational, upon becoming operational match one of the SWID-PC needs to make a
best guess as to
provided Software Identifiers. This might mean that the time resulting
list of event records sent in the relevant response attribute does not provide
a continuous sequence of EIDs. Both SW-PCs and SWIC-PVs MUST support
targeted request for event records.

3.5.4. Partial and Complete Lists of Event Records in SW Attributes

Over time, a SW-PC might record a large number of change events. If
a SW-PV requests all change events (possibly by looking
at timestamps on covering a large period of time,
the files), but these values resulting SW Response attribute might be off. In extremely large,
especially if the
case SW-PV is requesting the use of full records instead
of dynamically generated SWID tags, the time use of change is Software Identifiers (as described in Section 3.2.2).
In the
time at which case that the data from which resulting attribute is too large to send (either
because it exceeds the SWID tags are generate changes,
not 4GB attribute size limit imposed by the time at which a changed SWID tag is generated. For example,
if SWID tags are dynamically generated based PA-TNC
specification, or because it exceeds some smaller size limit imposed
on data in an RPM
database, the time of change would be when SW-PC) the RPM record was
changed.

With regard to deletions SW-PC MAY send a partial list of SWID tags, the SWID-PC needs event records back
to detect the deletion and MUST retain SW-PV.

Generation of a copy partial list of events in a SW Response attribute
requires the full deleted tag so that
the tag itself can be provided SW-PC to identify a "consulted range" of EIDs. A
consulted range is the SWID-PV upon request. This
copy set of event records that are examined for
inclusion in the SWID tag MUST SW Response attribute and that are included in that
attribute if applicable. Recall that, if a SW Request is targeted,
only event records that involve the indicated software would be retained
applicable. (See Section 3.3 for more on Targeted Request.) If a reasonable amount of
time. Vendors
request is not targeted, all event records in the considered range
are applicable and administrators determine what "reasonable" means,
but a copy included in the SW Response attribute.

The lower bound of the tag SHOULD consulted range MUST be retained for as long as the EID provided in
the SW Request. (Recall that a SW Request indicates a request for
event
recording records by providing a non-0 EID value in the deletion SW Request. See
Section 3.5.3.) The upper bound of the tag remains in the SWID-PC's records.
This consulted range is recommended because, as long as the EID of
the latest event record (as ordered by EID values) that is included
in the SWID-PC's
records, the SWID-PC might send an event SW Response attribute (described in
Section 3.6) that references this tag, and a copy of the tag is
needed if the SWID-PV wanted a full copy of the relevant tags.

With regard to alterations to a SWID tag file, SWID-PCs MUST detect
any alterations it is applicable to the contents request. The
EID of a tag file. Alterations need to
be detected even if they have no functional impact on the tag file.
For example, this last event record is called the addition of whitespace between XML attributes does
not have any impact "Last Consulted EID".
The SW-PC chooses this Last Consulted EID based on the meaning size of the SWID tag file, but still
needs to be detected as a tag file alteration by a SWID-PC. A good
guideline
event record list it is that any alteration willing to a file that might change the
value of a hash taken on the file's contents needs provide to be detected by the SWID-PC. SW-PV.

A SWID-PC might be unable to distinguish modifications
to the content of a tag file from modifications to the metadata the
file system associates with the tag file. For example, a SWID-PC
might use partial result list MUST include all applicable event records
within the "last modification" timestamp as consulted range. This means that for any applicable event
record (i.e., any event record in an indication of
alteration to un-targeted request, or an event
record associated with software matching a given tag file, but requested Software
Identifier in a file's last modification time
can change for reasons other targeted request) whose EID is greater than modifications or equal
to the file contents.
A SWID-PC EID provided in the SW Request and whose EID is still considered compliant with this specification if it
also reports metadata change events that do not change the SWID tag
file itself as alterations less than or
equal to the SWID tag file. In other words,
while SWID-PC authors are encouraged to exclude modifications Last Consulted EID, that do
not affect the bytes within the tag file when detecting alterations
to a SWID tag record, discriminating between modifications to file
contents and changes to file metadata can event record MUST be difficult and time
consuming on some systems. As such, as long as the alterations
detected by a SWID-PC always cover all modifications to included
in the contents SW Response conveying this partial list of tag files, the SWID-PC event records.
This ensures that every partial list of event records is considered compliant even if it also
registers alterations always
complete within its indicated range.

All SW Response attributes that do not modify convey event records (either using
full records or using Software Identifiers) include an Epoch, Last
EID, and Last Consulted EID field. The Last EID contains the contents EID of a tag file
as well. When recording an alteration to a tag file,
the SWID-PC is
only required last event record known to note the SW-PC at the time that an alteration occurred. the SW
Response attribute was generated. The SWID-PC is
not required to note Last EID might or record how the tag file altered, nor is it
possible to include such details in SWID Attributes reporting might not be
part of the
change to a SWID-PV.

3.6. Reporting Change Events consulted range. As noted in above, the preceding section, SWID-PCs MUST be able to detect
changes to Last Consulted EID
field contains the SWID tag repositories (tag creation, tag removal, and
tag alteration) EID of the last event record in near real-time while the SWID-PC is operational, consulted
range. The Epoch field contains the EID Epoch associated with the
Last EID and MUST be able to account for any net change to Last Consulted EID fields as well as all the endpoint's SWID
tag collection that occurs when EIDs in
event records contained within the SWID-PC is not operational.
However, to be of use SW Response attribute. Note that,
if responding to a targeted SW Request, the enterprise, SW Response attribute
might not contain the NEA Server needs to be
able to receive these events and be able to understand how new
changes relate to earlier changes. In SWID Message and Attributes
for PA-TNC, this is facilitated by reporting change events. All
SWID-PCs MUST be capable of receiving requests for change events and
sending change event attributes. All SWID-PVs MUST be capable of
requesting and receiving change event attributes.

3.6.1. Change Event Records

A change event record consists of either a complete SWID tag or SWID
tag identifier instance along with whose EID matches the following pieces of
information:

o The nature Last
Consulted EID value. For example, the last consulted EID record
might have been deemed inapplicable because it did not match the
specified list of Software Identifiers in the change (i.e., tag creation, tag deletion, or tag
alteration)

o An Event Identifier (EID) value

o An SW Request.

If a SW-PV receives a SW Response attribute where the Last EID Epoch value

An and
Last Consulted EID is fields are identical, the SW-PV knows that it has
received a 4-byte unsigned integer result list that is complete, given the SWID-PC assigns
sequentially to each observed event (whether detected in real-time or
deduced by looking for net changes over a period parameters of SWID-PC
inactivity). All EIDs exist within the context of some "EID Epoch",
which is also represented as a 4- byte unsigned integer. EID Epochs
are used
request, up to ensure synchronization between the SWID-PC present time. On the other hand, if the Last EID
and any SWID-
PVs with which it communicates. Last Consulted EID Epoch values SHOULD be generated
randomly and in such differ, the SW-PV has received a way that it is unlikely that
partial result list. In the same EID
Epoch is generated twice, even latter case, if the SWID-PC reverted SW-PV wishes to an earlier
state (e.g., resetting it try
to factory defaults). In collect the case where a
SWID-PC needs to reset its EID counter, either because it has
exhausted all available EID values or because rest of the SWID-PC's event log
becomes corrupted, partially delivered result list it then
sends a new SW Request whose EID Epoch MUST be selected.

Within an Epoch, EIDs MUST be assigned sequentially, so that if a
particular event is assigned an one greater than the Last
Consulted EID of N, in the next observed preceding response. Doing this causes the SW-PC
to generate another SW Response attribute containing event records
where the earliest reported event record is
given an EID of N+1. In some cases, events might occur
simultaneously, or the SWID-PC might not otherwise be able to
determine an ordering for events. In these cases, one immediately after
the SWID-PC
creates an arbitrary ordering of event record with the events and assigns Last Consulted EID (since EIDs
according to are assigned
sequentially). By repeating this ordering. Two change events MUST NOT ever be
assigned the same EID within process until it receives a SW
Response where the same EID Epoch. No meaningful
comparison can be made between EID values of different Epochs.

The Last EID value of 0 is reserved and MUST NOT be associated with any
event. Specifically, an Last Consulted EID are equal, the SW-
PV is able to collect all event records over a given range, even if
the complete set of 0 in event records would be too large to deliver via a SWID Request attribute
indicates
single attribute.

Implementers need to be aware that a SWID-PV wants SW Request might specify an inventory response rather EID
that is greater than an
event response, while an the EID of 0 the last event recorded by a SW-PC.
In accordance with the behaviors described in Section 3.5.3, a SWID Response is used SW-PC
MUST respond to
indicate the initial state such a request with a SW Response attribute of the endpoint's SWID tag collection
prior to
appropriate type (using full records or Software Identifiers as
specified in the observation of any events. Thus SW Request) that contains zero event records. This
is because the very first SW-PC has recorded no event records with EIDs greater
than or equal to the EID in the SW Request. In such a SWID-PC's records within an case, the Last
Consulted EID Epoch field MUST be assigned a set to the same value of 1 or greater. Note that as the Last EID and
field in this SW Response attribute. This case is called out because
the consulted range on a SW-PC in such a situation is a negative
range, where the "first" EID Epoch values are
assigned by in the SWID-PC without regard to whether events are being
reported to one or more SWID-PVs. The SWID-PC records events and
assigns EIDs during its operation. Any and all SWID-PVs that request
event information from range (provided in the SWID-PC will have those requests served
from SW
Request) is greater than the same records and thus will see "last" EID in the range (this being the same EIDs and
EID Epochs
for of the same events.

The SWID-PC MUST last recorded event on the SW-PC). Implementers need to
ensure there is no coverage gap (i.e., change events that are SW-PCs do not recorded experience problems in such a circumstance.

Note that this specification only supports the SWID-PC's records) in its records returning of
change events. This partial
results when returning event records. There is necessary because a coverage gap might give no way to return a
SWID-PV
partial inventory list under this specification.

3.5.5. Synchronizing Event Identifiers and Epochs

Since EIDs are sequential within an Epoch, if a false impression SW-PV's list of event
records contains gaps in the endpoint's state. For example, if EID values within a SWID-PV saw an event indicating single Epoch, the
SW-PV knows that a particular SWID tag had been
installed, and saw no subsequent there are events indicating that tag had have not been
deleted, it might reasonably assume that this tag was still installed
(assuming accounted for.
The SW-PV can either request a new event list to collect the Epoch has not changed). If there is missing
events or request a coverage gap in full inventory to re-sync its understanding of
the SWID-PC's records, however, this assumption is false. For this
reason, state of the SWID-PC's event records MUST NOT contain gaps. Endpoint's Software Inventory Evidence Collection.
In either case, after the
case where there are periods where it is possible that changes
occurred without SW-PV's record of the SWID-PC detecting or recording them, endpoint's Software
Inventory Evidence Collection has been updated, the SWID-PC
MUST either compute a net change SW-PV can record
the new latest EID value and update its records
appropriately, or pick track events normally from that point
on.

If the SW-PV receives any attribute from a new SW-PC where the EID Epoch to indicate a discontinuity
with previous event records.

Within a given Epoch, once a particular event has been assigned an
EID, this association MUST NOT be changed. That is, within an Epoch,
once an
differs from the EID is assigned to an event, Epoch that EID cannot be reassigned was used previously, then SW-PV or
any entity using this information to
a different event, and track the event cannot be assigned endpoint's Software
Inventory Evidence Collection knows that there is a different EID.
When the SWID-PC's Epoch changes, all discontinuity in
their understanding of these associations between
EIDs and events are cancelled, the endpoint's state. To move past this
discontinuity and EID values once again become free
for assignment.

3.6.2. Updating Inventory Knowledge Based on Events

Modern endpoints can have hundreds reestablish a current understanding of software products installed,
most the state of which are unlikely
the endpoint's Software Inventory Evidence Collection, the SW-PV
needs to change receive a full inventory from one day to the next. As
such, instead of exchanging a complete list of an endpoint. The SW-PV
cannot be brought in sync with the endpoint's
inventory on a regular basis, one might wish to only identify changes
since some earlier known state through the
collection of any set of event records in this inventory. situation. This is readily
facilitated by the use of EIDs
because it is not possible to place change account for all events in a context
relative on the SW-PC
over the interval since the previous Epoch was used, because there is
no way to earlier state.

Every inventory sent by query for EIDs from a SWID-PC to previous Epoch. Once the SW-PV has
received a SWID-PV (as described in
Section 3.2 through Section 3.4) includes full inventory for the new Epoch, the SW-PV records the
latest EID reported in this new Epoch and EID of can track further events
normally.

A SW-PC MUST NOT report events with EIDs from any Epoch other than
the last event recorded prior current EID Epoch. The SW-PC MAY choose to that inventory being compiled. This
allows purge all event
records from a previous Epoch from memory after an Epoch change.
Alternately, the SWID-PV SW-PC MAY choose to place all subsequently received retain some event records from a
previous EID Epoch and assign them new EIDs in context relative to this inventory (since the EIDs represent a
total ordering of all changes to current Epoch.
However, in the endpoint's SWID tag collection).
Specifically, a SWID-PV (or, more likely, case where a database SW-PC chooses the latter option it MUST
ensure that collects
and records its findings) can record an endpoint's full inventory the order of events according to their EIDs is unchanged
and
also that there is no coverage gap between the first retained event
recorded during the previous Epoch (now reassigned with an EID in the
current Epoch) and Epoch of the most recent first event reflected in that
state. From recorded during the current Epoch.
In particular, the SW-PC MUST ensure that point on, if all change events are observed, the
attribute describing these events indicates that
occurred after the nature of the change, last recorded event from the affected SWID tags, previous Epoch are
known and recorded. (This might not be possible if the order Epoch change
is due to state corruption on the SW-PC.) A SW-PC might choose to
reassign EIDs to records from a preceding Epoch to create a "sliding
window" of events, where each Epoch change represents a shift in which these events occurred
(as indicated by the sequential EIDs). Using this information, any
remote record
window of available events.

In the endpoint's SWID tag collection can be updated
appropriately.

3.6.3. Using Event Records in SWID Attributes

A SWID-PV MUST be able to request case where a list SW-PC suffers a crash and loses track of its
current EID Epoch or current EID, then it MUST generate a new EID
Epoch value and begin assigning EIDs within that Epoch. In this
case, the SW-PC MUST purge all event records instead of
an inventory. The message flow in such an exchange looks from before the same crash as
the basic flow shown in Figure 2. The only difference
it cannot ensure that there is that, in
the SWID Request attribute, the SWID-PV provides an EID other than 0.
(A value of 0 in these fields represents not a request for an inventory.)
When gap between the SWID-PC receives such a request, instead last of identifying SWID
tags in those
records and the endpoint's SWID tag collection, it consults its record of next detected changes. event. The SWID-PC MUST add an event record to the SWID
Response attribute process for each recorded change event with an generating a
new EID greater
than or equal to Epoch MUST minimize the EID in possibility that the SWID Request attribute (although
targeting of requests, newly generated
EID Epoch is the same as described a previously used EID Epoch.

The SW-PV will normally never receive an attribute indicating that
the latest EID is less than the latest EID reported in a previous
attribute within the next paragraph, may limit same EID Epoch. If this list). A list occurs, the SW-PC has
suffered an error of some kind, possibly indicative of at least
partial corruption of its event records MUST only contain events with
EIDs that all come from log. In this case, the current Epoch.

SWID-PVs can target requests for event records by including one or
more tag identifiers, SW-PV SHOULD
treat the situation as described in Section 3.4, if there was a change in Epoch and treat any
local copy of the SWID
Request endpoint's Software Inventory Evidence Collection
as out-of-sync until a full inventory can be reported by the SW-PC.
In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can
be examined to ensure it is now operating properly.

3.6. Subscriptions

Thus far, all message exchanges discussed assume that requests a SW-PV sent an event record list. A targeted request for
event records
SW Request attribute and the SW-PC is used providing a direct response to indicate
that only events affecting SWID
tags that match request. The Software Message and Attributes for PA-TNC
specification also supports the provided SWID tag identifiers are ability for a SW-PC to be returned.
Specifically, send a message
with a SW Attribute to the SW-PV in response to observed changes in
the endpoint's software inventory evidence collection, instead of in
direct response to a targeted request for event records, SW Request. An agreement by a SW-PC to send
content when certain changes are detected to the SWID-PC MUST exclude any event records that are less than endpoint's Software
Inventory Evidence Collection is referred to in this specification as
a "subscription", and the
indicated EID (within SW-PV that receives this content is said to
be "subscribed to" the current EID Epoch) given SW-PC. All SW-PCs and exclude any event
records where SW-PVs MUST
support the affected SWID tag does not match one use of subscriptions.

3.6.1. Establishing Subscriptions

A SW-PV establishes a subscription on a particular SW-PC by sending a
SW Request attribute with the
provided SWID tag identifiers. This might mean that Subscription flag set. The SW Request
attribute is otherwise identical to the resulting
list of event records sent SW Requests discussed in the response attribute does not provide
previous sections. Specifically, such a continuous sequence of EIDs. Both SWID-PCs and SWIC-PVs MUST
support targeted SW Request might request for event records.

3.6.4. Partial
full records or Software Identifiers, might be targeted, and Complete Lists of Event Records in SWID Attributes

Over time, a SWID-PC might record a large number of
request change events.
If event records or endpoint inventory. Assuming no
error is encountered, a SWID-PV requests all change events covering SW-PC MUST send a large period of
time, the resulting SWID SW Response attribute might be extremely large,
especially in
direct response to this SW Request attribute, just as if the SWID-PV is requesting
Subscription flag was not set. As such, the use of full SWID tags
instead of message exchange that
establishes a new subscription in a SW-PC has the use of SWID Identifier instances same flow seen in
the previous message exchanges, as depicted in Figure 2. If the SW-
PV does not receive a PA-TNC Error attribute (as described in
Section 3.3.4). In 3.8 and Section 4.16) in response to their subscription
request, the case that subscription has been successfully established on the resulting
SW-PC. The SW Request attribute that establishes a new subscription
is too
large referred to send (either because it exceeds the 4GB attribute size limit
imposed by as the PA-TNC specification, or because "establishing request" for that subscription.

When a subscription is established it exceeds some
smaller size limit imposed on the SWID-PC) the SWID-PC MAY send is assigned a
partial list of events back Subscription ID
value. The Subscription ID is equal to the SWID-PV.

Generation value of a partial list the Request ID
of events in a SWID Response attribute
requires the SWID-PC establishing request. (For more about Request IDs, see
Section 4.8.)

A SW-PC MUST have the ability to identify record and support multiple
simultaneous subscriptions from a "consulted range" of EIDs. single party and from multiple
parties. A
consulted range is the set of event records that are examined for
inclusion in SW-PV MUST have the SWID Response attribute ability to record and that are included in
that attribute if applicable. Recall that, if support
multiple simultaneous subscriptions to a SWID Request is
targeted, only event records that involve single party and
subscriptions to multiple parties.

3.6.2. Managing Subscriptions

The SW-PC MUST record each accepted subscription along with the indicated SWID tags
would be applicable. (See Section 3.4 for more on Targeted Request.)
If a request is not targeted, all event records in
identity of the considered
range party to whom attributes are applicable and included to be pushed in
compliance with the SWID Response attribute.

The lower bound of subscription. This identity includes both the consulted range MUST be
NEA Server's connection ID and the EID provided in Posture Validator Identifier from
the SWID Request. (Recall PB-PA message that a SWID Request indicates a request delivered the request.

Likewise, SW-PVs MUST record each accepted subscription for event records by providing a non-0 EID value in which
they are the SWID Request.
See Section 3.6.3.) The upper bound of subscribing party along with the consulted range is associated Subscription
ID and the
EID identity of the latest event record (as ordered by EID values) SW-PC that is
included in the SWID Response attribute if it is applicable to will be fulfilling the
request.
subscription. The EID of SW-PV needs to retain this last event record is called information in order to
correctly interpret pushed SW Response attributes sent in fulfillment
of the "Last
Consulted EID". subscription. The SWID-PC chooses this Last Consulted EID based on
the size identity of the event record list it SW-PC is willing to provide to given in the
SWID-PV.

A partial result list MUST include all applicable event records
within
Posture Collector Identifier of the consulted range. This means PB-PA message header in all
messages from that for SW-PC.

3.6.3. Terminating Subscriptions

Subscriptions MAY be terminated at any applicable event
record whose EID is greater than or equal to time by the EID provided subscribing SW-PV
by setting the Clear Subscriptions flag in a SW Request. (See
Section 4.9 for more on using this flag.) In the
SWID case that a SW
Request and whose EID with the Clear Subscriptions flag set is less than or equal to received the Last
Consulted EID, that event record SW-PC
MUST be included in only clear subscriptions that match both the SWID
Response conveying NEA server
connection ID and the SW-PV ID for this partial list of event records. SW Request, and MUST clear
all such subscriptions.

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
full SWID tags or using SWID tag identifier instances) include an
Epoch, Last EID, and Last Consulted EID field. The Last EID contains specification does not give the EID of SW-PV the last event record known ability to terminate
subscriptions individually - all subscriptions to the SWID-PC at the time
that SW-PV are
cleared when the SWID Response attribute was generated. The Last EID might
or might Clear Subscriptions flag is set.

This specification does not be part of the consulted range. As noted above, give the
Last Consulted EID field contains SW-PC the EID of ability to
unilaterally terminate a subscription. However, if the last event record SW-PC
experiences a fatal error fulfilling a subscription, resulting in
sending a PA-TNC Error attribute of type
SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the consulted range. The Epoch field contains the EID Epoch
associated with subscription whose
fulfillment led to the Last EID and Last Consulted EID fields as well error MUST be treated as
all terminated by both
the EIDs in event records contained within SW-PC and the SWID Response
attribute. Note that, if responding to a targeted SWID Request, SW-PV. Only the
SWID Response attribute might not contain subscription experiencing the event record whose EID
matches
error is cancelled and other subscriptions are unaffected. See
Section 3.8 for more on this error condition.

Finally, a subscription is terminated if the Last Consulted EID value. For example, connection between the last
consulted EID record might have been deemed inapplicable because it
did not match
SW-PC and SW-PV is deleted. This occurs when the specified list of SWID tag identifiers connection ID used
in the SWID
Request.

If a SWID-PV receives a SWID Response attribute where messages between the Last EID SW-PC and Last Consulted EID fields are identical, the SWID-PV knows SW-PV becomes unbound.
Loss of this connection ID would prevent the SW-PC from sending
messages in fulfillment of this subscription. As such, loss of the
connection ID necessarily forces subscription termination between the
affected parties.

3.6.4. Subscription Status

A SW-PV can request that
it has received a result SW-PC report the list of active
subscriptions where the SW-PV is the subscriber. A SW-PV can use
this to recover lost information about active subscriptions. A SW-PV
can also use this capability to verify that a SW-PC has not forgotten
any of its subscriptions. The latter is complete, especially useful where a
SW-PC does not send any attributes in fulfillment of a given the parameters
subscription for a long period of the request, up to the present time. On The SW-PV can check the other hand, if list
of active subscriptions on the
Last EID SW-PC and Last Consulted EID values differ, the SWID-PV has
received a partial result list. In the latter case, if verify whether the SWID-PV
wishes to try
inactivity is due to collect the rest a lack of reportable events, or due to the partially delivered result SW-PC
forgetting its obligations to fulfill a given subscription.

A SW-PV requests a list it of its subscriptions on a given SW-PC by
sending that SW-PC a Subscription Status Request. The SW-PC MUST
then sends respond with a new SWID Request whose EID Subscription Status Response (or a PA-TNC Error
if an error condition is experienced). The Subscription Status
Response MUST contain one greater than subscription record for each of the Last Consulted EID in active
subscriptions for which the preceding response. Doing this causes SW-PV is the SWID-PC to generate another SWID Response attribute containing
event records where the earliest reported event record is subscribing party.

3.6.5. Fulfilling Subscriptions

As noted in Section 3.4 SW-PCs MUST have the one
immediately after ability to automatically
detect changes to an endpoint's Software Inventory Evidence
Collection in near real-time. For every active subscription, the event record with SW-
PC MUST send an attribute to the Last Consulted EID (since
EIDs are assigned sequentially). By repeating this process until it
receives subscribed SW-PV whenever a SWID Response where the Last EID and Last Consulted EID
are equal, the SWID-PV change
is able detected to collect all event relevant records over a
given range, even if within the complete set of event records would be too
large to deliver via a single attribute.

Implementers need to be aware that a SWID Request might specify endpoint's Software
Inventory Evidence Collection. Such an
EID that attribute is greater than said to be sent
"in fulfillment of" the EID of given subscription and any such attribute
MUST include that subscription's Subscription ID. If the last event recorded by
establishing request for that subscription was a
SWID-PC. In accordance with targeted request,
then only records that match the behaviors described Software Identifiers provided in
Section 3.6.3, a SWID-PC MUST respond to such a
that establishing request with are considered relevant. Otherwise, (i.e.,
for non-targeted requests) any record is considered relevant for this
purpose. Figure 3 shows a SWID
Response attribute of sample message exchange where a
subscription is established and then later messages are sent from the appropriate type (using SWID tags or SWID
tag identifier instances as specified
SW-PC in fulfillment of the SWID Request) that
contains zero event records. This is because the SWID-PC has
recorded no event records with EIDs greater than or equal to established subscription.

+-------------+ +--------------+
| SW-PC | | SW-PV | Time
+-------------+ +--------------+ |
| | |
|<-----------SW Request-------------| |
| | |
|------------SW Response----------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|------------SW Response----------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|------------SW Response----------->| |
| | V

Figure 3: Subscription Establishment and Fulfillment

The contents of an attribute sent in fulfillment of a subscription
depend on the EID parameters provided in the SWID Request. In such a case, establishing request for
that subscription. Specifically, the Last Consulted EID field
MUST be set to contents of an attribute sent
in fulfillment of a subscription have the same value format as the Last EID field in this SWID would a
direct response attribute. This case is called out because consulted range
on to the establishing request. For example, if the
establishing request stipulated a SWID-PC response that contained an event
record list wherein affected software indicated using Software
Identifiers, all attributes sent in such a situation is a negative range, where the
"first" EID fulfillment of this subscription
will also consist of event record lists expressed using Software
Identifiers. As such, all SW Responses displayed in the range (provided exchange
depicted in Figure 3 have the SWID Request) is greater
than the "last" EID same format. A SW Response generated
in the range (this being the EID fulfillment of an active subscription MUST be a valid SW Response
attribute according to all the last
recorded event on rules outlined in the SWID-PC). Implementers need preceding
sections. In other words, an attribute constructed in fulfillment of
a subscription will look the same as an attribute sent in direct
response to ensure an explicit request from a SW-PV that
SWID-PCs do not experience problems in such had the same
request parameters and which arrived immediately after the given
change event. There are a circumstance.

Note few special rules that expand on this specification only supports
guideline:

3.6.5.1. Subscriptions Reporting Inventories

In the returning of partial
results when returning event records. There is no way case that a SW-PV subscribes to return a
partial SW-PC requesting an
inventory list under this specification.

3.6.5. Synchronizing Event Identifiers and Epochs

Since EIDs attribute whenever changes are sequential within an Epoch, if a SWID-PV's list of
event records contains gaps in detected (i.e. the EID values within a single Epoch, in
the SWID-PV knows that there are events that have not been accounted
for. The SWID-PV can either establishing request a new event list to collect is 0), then the
missing events SW-PC MUST send the
requested inventory whenever a relevant change is detected. (A
"relevant change" is any change for untargeted requests, or request a full inventory change
to re-sync its
understanding of the state an indicated record in a targeted request.) Upon detection of a
relevant change for an active subscription, the SWID tags on SW-PC sends the endpoint. In
either case, after
appropriate inventory information as if it had just received the SWID-PV's record
establishing request. Attributes sent in fulfillment of this
subscription will probably have a large amount of redundancy, as the endpoint's SWID tag
collection has been updated, the SWID-PV
same records the new latest EID
value and tracks events normally from that point on.

If the SWID-PV receives any attribute from a SWID-PC where the EID
Epoch differs from the EID Epoch that was used previously, then SWID-
PV or any entity using this information are likely to track the endpoint's SWID
tag collection knows that there is a discontinuity be present in their
understanding of the endpoint's state. To move past this
discontinuity and reestablish a current understanding each of the state these SW Attributes.
The role of
the endpoint's SWID tag collection, the SWID-PV needs to receive a
full an inventory from the endpoint. This is because it subscription is not possible to account report records just
for all events on the SWID-PC over the interval since the
previous Epoch was used, because there items that changed - that is no way to query for EIDs
from a previous Epoch. Once the SWID-PV has received role of a full
inventory for the new Epoch, the SWID-PV records the latest EID
reported in this new Epoch and can track further subscription that
reports events normally. (see Section 3.6.5.2). A SWID-PC SW-PC MUST NOT report events with EIDs exclude a
record from any Epoch other than an attribute sent in fulfillment of an inventory
subscription simply because that record was not involved in the current EID Epoch. The SWID-PC MAY choose to purge all
triggering event
records from (although a previous Epoch from memory after an Epoch change.
Alternately, record might be excluded for other
reasons, such as if the SWID-PC MAY choose subscription is targeted - see
Section 3.6.5.3).

3.6.5.2. Subscriptions Reporting Events

The way in which a SW-PV indicates it wishes to retain some establish a
subscription requesting event records from is by providing a previous non-zero EID Epoch and assign them new EIDs in the current Epoch.
However,
in the case where a SWID-PC chooses SW Request establishing the latter option it
MUST ensure that subscription (see Section 3.5.1).
However, when the order SW-PC constructs an attribute in fulfillment of events according the
subscription (other than the direct response to their EIDs is
unchanged and that there is no coverage gap between the first
retained establishing
request), it MUST only include event recorded during records for the previous Epoch (now reassigned detected
change(s) that precipitated this response attribute. In other words,
it MUST NOT send a complete list of all changes starting with an EID in the current Epoch) and
indicated EID, up through the first latest change, every time a new event recorded during
the current Epoch.
is detected. In particular, effect, the SWID-PC MUST ensure that all
change events EID in the establishing request is
treated as being updated every time an attribute is sent in
fulfillment of this subscription, such that occurred after a single event is not
reported twice in fulfillment of a single subscription. As such,
every SW-PC MUST track the EID of the last recorded event from that triggered an
attribute for the
previous Epoch are known and recorded. (This might not be possible
if given subscription. When the Epoch change next event (or set of
events) is due to state corruption on detected, the SWID-PC.) A
SWID-PC might choose to reassign SW-PC MUST only report events with EIDs to records from a preceding
Epoch to create a "sliding window" of events, where each Epoch change
represents a shift in
after the window of available events. last reported event. In the case where a SWID-PC suffers a crash and loses track of its
current that the EID Epoch or current EID, then it MUST generate a new of the
SW-PC changes, the SW-PC MUST treat EID values in the new Epoch value and begin assigning as
being after all EIDs within that Epoch. In this
case, assigned in the SWID-PC MUST purge all event records from before previous Epoch regardless of the crash
as it cannot ensure
relative numeric values of these EIDs.

Note that there is not while a gap between the last of those
records and subscription is active, the next detected event. The process subscribing SW-PV MAY
make other requests for generating event records that overlap with events that
are reported in fulfillment of a
new EID Epoch MUST minimize subscription. Such requests are
unaffected by the possibility that presence of the newly generated
EID Epoch subscription, nor is the same as
subscription affected by such requests. In other words, a previously used EID Epoch.

The SWID-PV given
request will normally never receive get the same results back whether or not there was a
subscription. Likewise, an attribute indicating that
the latest EID is less than the latest EID reported sent in fulfillment of a previous
attribute within
subscription will contain the same EID Epoch. If this occurs, the SWID-PC has
suffered an error of some kind, possibly indicative of at least
partial corruption of its event log. In this case, information whether or not other
requests had been received from the SWID-PV
SHOULD treat SW-PV.

A SW-PV needs to pay attention to the situation EID Epoch in these messages, as if there was a change
changes in the Epoch and
treat any local copy might create discontinuities in the SW-PV's
understanding of the endpoint's SWID tag collection Software Inventory Evidence
Collection state, as out-of-
sync until discussed in Section 3.5.5. In particular, once
the EID Epoch changes, a full inventory can be reported by the SWID-PC. In this
case, the SWID-PV SHOULD flag the event so it can be examined to
ensure it is now operating properly.

3.7. Supporting Multiple Instances of a Single Tag

One important consideration SW-PV is unable have confidence that it is possible for multiple
instances of has
a SWID tag to be present on an endpoint. (I.e.,
multiple SWID tag files whose tag identifiers are correct understanding of the same.) This
can happen if there are multiple instances state of an endpoint's Software
Inventory Evidence Collection until after the indicated software
product installed SW-PV collects a
complete inventory.

SW-PCs MAY send partial lists of event records in fulfillment of a
subscription. (See Section 3.5.4 for more on the endpoint. partial list of event
records.) In order to account for the
possibility, all SWID-PCs case that a SW-PC sends a partial list of event
records, it MUST follow specific rules, outlined below.

3.7.1. Inventory Reporting in immediately send the next consecutive partial list,
and continue doing so until it has sent the Presence equivalent 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
complete list of event records. In other words, if the SW-PC sends a
relevant tag. (All tags are relevant
partial list it does not wait for another change event to send
another SW Response, but continues sending SW Responses until it has
sent all event records that would have been included in a full inventory. In a complete
fulfillment of the subscription.

3.6.5.3. Targeted Subscriptions

Subscriptions MAY be targeted request for an inventory, to only tags apply to records that match the tag
identifiers provided by the SWID-PV are considered relevant.) For
example, if a particular piece
given set 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.) Software Identifiers. 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 changes are
detected that affect multiple copies of one
tag instance. In records, some matching the case where establishing
request's Software Identifiers and some not, the SWID-PC's response is expressed
using tag identifiers, attribute sent in
fulfillment of the response subscription MUST only include the tag identifier
instance inventory or events
(as appropriate) for each instance of records that match the given tag.

3.7.2. Event Reporting establishing request's
Software Identifiers. The SW-PC MUST NOT include non-matching
records in the Presence of Multiply Instantiated Tags

When reporting events, the specific tags attribute, even if those non-matching records
experienced change events that were added, deleted, or
changed co-temporal with change events on
the matching records.

In addition, a SW-PC MUST be indicated. For example, send an attribute in the case where tags A and
B are two instances of the same SWID tag, each for separate
installations fulfillment of the same software product, and tag A a
targeted subscription only when changes in to the endpoint's SWID tag collection, Software
Inventory Evidence Collection impact one or more records matching the SWID-PC
subscription's establishing request's Software Identifiers. A SW-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 NOT send any attribute in fulfillment of a targeted subscription
based on detected change to the tag identifier instance for endpoint's Software Inventory
Evidence Collection that did not involve any of the affected tag.

3.8. Subscriptions

Thus far, all message exchanges discussed assume records targeted
by that subscription.

3.6.5.4. No Subscription Consolidation

A SW-PV MAY establish multiple subscriptions to a SWID-PV sent
an SWID Request attribute and given SW-PC. If
this is the SWID-PC case, it is providing a direct
response to possible that request. The SWID Message a single change event on the
endpoint might require fulfillment by multiple subscriptions, and Attributes for PA-TNC
specification also supports
that the ability for a SWID-PC to information included in attributes that fulfill each of
these subscriptions might overlap. The SW-PC MUST send separate
attributes for each established subscription that requires a
message with a SWID Attribute to the SWID-PV in response
due to observed
changes in the endpoint's SWID tag collection, instead given event. Each of in direct
response to a SWID Request. An agreement by a SWID-PC to send
content when certain changes are detected these attributes MUST contain all
information required to the endpoint's SWID tag
collection fulfill that individual subscription, even if
that information is referred to also sent in this specification as a "subscription",
and other attributes sent in fulfillment
of other subscriptions at the SWID-PV that receives same time. In other words, SW-PCs MUST
NOT attempt to combine information when fulfilling multiple
subscriptions simultaneously, even if this content is said results in some redundancy
in the attributes sent to be "subscribed
to" the given SWID-PC. All SWID-PCs and SWID-PVs MUST support SW-PV.

3.6.5.5. Delayed Subscription Fulfillment

A SW-PC MAY delay the
use fulfillment of subscriptions.

3.8.1. Establishing Subscriptions

A SWID-PV establishes a subscription on a particular SWID-PC by
sending a SWID Request attribute with the Subscription flag set. The
SWID Request attribute is otherwise identical to the SWID Requests
discussed in previous sections. Specifically, such following a SWID Request
might request full tags or tag identifier instances, might be
targeted, and might request
change event records or endpoint
inventory. Assuming no error is encountered, a SWID-PC MUST send a
SWID Response attribute in direct response the interest of waiting to this SWID Request
attribute, just as see if additional change
events are forthcoming and, if so, conveying the Subscription flag was not set. As such, relevant records
back to the message exchange that establishes a new subscription SW-PV in a SWID-PC
has single SW Response attribute. This can help
reduce network bandwidth consumption between the same flow seen in SW-PC and the previous message exchanges, as depicted
in Figure 2. SW-PV.
For example, consider a situation where 10 changes occur a tenth of a
second apart. If the SWID-PV SW-PC does not receive a PA-TNC Error
attribute (as described delay in Section 3.10 assembling and Section 4.16) in response
to their subscription request, sending
SW Response attributes, the subscription has been successfully
established on SW-PV will receive 10 separate SW
Response attributes over a period of 1 second. However, if the SWID-PC. The SWID Request attribute that
establishes SW-PC
waits half a new subscription is referred to as second after the "establishing
request" for initial event before assembling a SW
Response, the SW-PV only receives two SW Response attributes over the
same period of time.

Note that subscription.

When the ability to consolidate events for a single subscription is established it is assigned
over a Subscription ID
value. The Subscription ID is equal to the value of the Request ID given period of time does not contradict the establishing request. (For more about Request IDs, see rules in
Section 4.8.)

A SWID-PC MUST have the ability to record and support multiple
simultaneous subscriptions from a single party and subscriptions from
multiple parties. A SWID-PV MUST have the ability to record and
support multiple simultaneous subscriptions to a single party and
subscriptions to 3.6.5.4 prohibiting consolidation across multiple parties.

3.8.2. Managing Subscriptions

The SWID-PC MUST record each accepted subscription along with the
identity
subscriptions. When delaying fulfillment of the party to whom attributes subscriptions, SW-PCs
are still required to be pushed fulfill each individual subscription
separately. Moreover, in
compliance with the subscription. This identity includes both case that change events within the
NEA Server's connection ID
delay window cancel each other out (e.g., a record is deleted and
then re-added), the Posture Validator Identifier from
the PB-PA message that delivered the request.

Likewise, SWID-PVs SW-PC MUST record still report each accepted subscription for which
they are change event rather
than just reporting the subscribing party along with net effect of changes over the associated Subscription
ID and delay period.
In other words, delayed fulfillment can decrease the identity number of
attributes send by the SWID-PC that will be fulfilling SW-PC, but it does not reduce the
subscription. The SWID-PV needs to retain this information in order total number
of change events reported.

SW-PCs are not required to correctly interpret pushed SWID Response attributes sent in support delayed fulfillment of the subscription. The identity of the SWID-PC is
given
subscriptions. However, in the Posture Collector Identifier of the PB-PA message header
in all messages from case that SWID-PC.

3.8.3. Terminating Subscriptions

Subscriptions MAY be terminated at any time by the subscribing SWID-
PV by setting SW-PC does support
delayed subscription fulfillment, it MUST be possible to configure
the Clear Subscriptions flag in a SWID Request. (See
Section 4.9 for more on using this flag.) SW-PC to disable delayed fulfillment. In the case that the SWID-
PC receives both the connection ID and the Posture Validator ID of
the SWID-PV requesting that subscriptions other words, parties
deploying SW-PCs need to be cleared (i.e., the clear allowed to disable delayed subscription request
fulfillment in their SW-PCs. The manner in which such configuration
occurs is received via a TNC_IMC_ReceiveMessageLong
function) and the SWID-PC has been recording PV IDs associated with
subscriptions when available, left to the SWID-PC discretion of implementers, although
implementers MUST only clear
subscriptions that match both the connection ID and protect the PV ID, and
MUST clear all such subscriptions. configuration procedure from
unauthorized tampering. In the case that the SWID-PC only
has the connection ID of the party requesting that subscriptions other words, there needs to 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 some
assurance 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
subscriptions individually - all subscriptions to the SWID-PV unauthorized individuals are
cleared when the Clear Subscriptions flag is set.

This specification does not give the SWID-PC the ability able to
unilaterally terminate a subscription. However, if the SWID-PC
experiences a fatal error fulfilling a subscription, resulting introduce
long delays in
sending a PA-TNC Error attribute of type
SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose
fulfillment led to fulfillment.

3.7. Multiple Sources of Software Inventory Evidence Records

The records in an endpoint's software inventory evidence collection
might potentially come from multiple sources. For example, records
might be derived from ISO SWID tags deposited on the error MUST file system and
collected therefrom. Records might also be treated as terminated generated by both
the SWID-PC tools such
as software and the SWID-PV. Only the subscription experiencing the
error package managers (e.g., RPM or YUM) or might be
translated from software discovery reports.

A SW-PC is cancelled and other subscriptions are unaffected. See
Section 3.10 for more not required to identify every possible source of software
information on this error condition.

Finally, its endpoint. Some SW-PCs might be explicitly tied
only to one or a subscription is terminated if the connection between handful of software inventory sources. For all
software inventory evidence sources that a particular SW-PC supports,
it MUST completely support all requirements of this specification
with regard to those sources. In other words, for supported sources,
the
SWID-PC and SWID-PV SW-PC is deleted. This occurs when required to be capable of providing a complete set of
the connection ID
used provided software inventory evidence records; monitoring for
changes in the messages between the SWID-PC records reported by those sources, correctly providing
responses for both full and targeted requests that include records
from those sources, and providing either complete records or Software
Identifiers as appropriate. If the SWID-PV becomes
unbound. Loss source's output is not in one of this connection ID would prevent
the SWID-PC from
sending messages data models identified in fulfillment of this subscription. As such, loss
of the connection ID necessarily forces subscription termination
between Software Data Model IANA table (see
Section 9.4), the affected parties.

3.8.4. Subscription Status

A SWID-PV can request SW-PC MUST be capable of converting that a SWID-PC report the list output
into one of active
subscriptions where the SWID-PV is supported data models. In all cases, the subscriber. A SWID-PV can use
this to recover lost information about active subscriptions. A SWID-
PV can SW-PC MUST
also use this capability to verify be capable of deriving a Software Identifier from the resulting
record and also assigning that record a SWID-PC has not
forgotten any of its subscriptions. unique Record Identifier.
The latter is especially useful
where a SWID-PC does not send SW-PC MUST NOT provide any attributes inventory or event information from
software inventory sources for which it cannot provide this full
support.

When providing a SW Response (either in direct response to a SW
Request or in fulfillment of a
given subscription for a long period of time. The SWID-PV can check
the list of active subscriptions on subscription) the SWID-PC and verify whether SW-PC MUST include
the inactivity complete set of relevant data from all supported sources of
software inventory evidence. In other words, a full inventory is due
required to contain all records from all supported sources, a lack of reportable events, or due
targeted inventory is required to the
SWID-PC forgetting its obligations contain all relevant records from
all sources, and event tracking is required to fulfill a given subscription.

A SWID-PV requests cover all events from
all sources. With regard to events, a list SW-PC's assignment of its subscriptions EIDs
MUST reflect the presence and order of all events on a given SWID-PC by
sending the endpoint (at
least for supported sources) regardless of the source. This means
that SWID-PC a Subscription Status Request. The SWID-PC MUST
then respond with a Subscription Status Response (or a PA-TNC Error if source A experiences an error condition is experienced). The Subscription Status
Response contains one subscription record for each of the active
subscriptions for which event, and then source B experiences
two events, and then source A experiences another two events, the SWID-PV SW-
PC is required to capture five events with consecutive EID values
reflecting the subscribing party.
Specifically, order in which the case events occur.

Note that, if a SW-PC collects data from multiple sources, it is
possible that the Subscription Status Request
arrives with some software products might be "double counted". This
can happen if both sources of inventory evidence provide a connection ID and record for
a Posture Validator ID and the
SWID-PC has been recording Posture Validator IDs associated with
subscriptions when available, the SWID-PC single installation of a software product. Moreover, each of these
provided records might have different Software Identifiers. When a
SW-PC reports information or records events from multiple inventory
evidence sources, it MUST include only
subscription use the information those sources provide,
rather than attempting to perform some form of reduction. In other
words, if multiple sources report records associated with both corresponding to a single
installation of a software product, all such records from each source
are required to be part of the given connection ID and
Posture Validator ID, SW-PC's processing even if this might
lead to multiple reporting, and MUST include all the SW-PC is not to ignore some
records to avoid such records. In multiple reporting. Similarly, in the case
that multiple sources report an event, the Subscription Status Request arrives SW-PC MUST create separate
event records with only a connection
ID or the SWID-PC has not been recording Posture Validator IDs
associated with subscriptions separate EIDs for each of these, even when available, if there is
the SWID-PC MUST
include only subscription records associated with chance that they represent the given
connection ID two sources reporting the same
action on the endpoint. Entities tracking software inventory
information collected via SW-PCs and SW-PVs need to be aware that have no associated Posture Validator ID, and
MUST include all
such records.

3.8.5. Fulfilling Subscriptions

As noted in Section 3.5 SWID-PCs MUST have the ability to
automatically detect changes double-reporting might occur. How (or if) such occurrences are
detected and resolved is up to the implementers of those entities.

3.8. Error Handling

In the case where the SW-PC detects an endpoint's SWID tag collection error in
near real-time. For every active subscription, the SWID-PC a SW Request
attribute that it receives it MUST send
an respond with a PA-TNC Error
attribute with an error code appropriate to the subscribed SWID-PV whenever a change is detected
to relevant tags within nature of the endpoint's SWID tag collection. The
SWID-PC MAY choose to exclusively deliver this attribute. error.
(See
section 4.5 Section 4.2.8 of RFC 5793 (PB-TNC) [RFC5793] PA-TNC [RFC5792] for more on exclusive
delivery.) Such an attribute is said to be sent "in fulfillment of"
the given subscription details about PA-TNC
Error attributes and any such attribute MUST include that
subscription's Subscription ID. If the establishing request error codes as well as Section 4.16 in this
specification for error codes specific to SW Attributes.) In the
case that
subscription was an error is detected in a targeted request, then only tags that match SW Request the
SWID tag identifiers provided in that establishing request are
considered relevant. Otherwise, (i.e., for non-targeted requests) SW-PC MUST NOT
take any tag is considered relevant for action requested by this purpose. Figure 3 shows a
sample message exchange where SW Request, even if partial
completion of the SW is possible. In other words, a subscription SW Request that
contains an error is established completely ignored by the SW-PC (beyond sending
a PA-TNC Error attribute, and then
later messages are sent from possibly logging the SWID-PC in fulfillment of error locally)
rather than being partially executed.

In the
established subscription.

+-------------+ +--------------+
| SWID-PC | | SWID-PV | Time
+-------------+ +--------------+ |
| | |
|<----------SWID Request------------| |
| | |
|-----------SWID Response---------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|-----------SWID Response---------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|-----------SWID Response---------->| |
| | V

Figure 3: Subscription Establishment and Fulfillment

The contents of an attribute sent in fulfillment of case where the SW-PC receives a subscription
depend on valid SW Request attribute but
experiences an error during the parameters provided in process of responding to that
attribute's instructions where that error prevents the establishing request for SW-PC from
properly or completely fulfilling that subscription. Specifically, request, the contents of an SW-PC MUST send a
PA-TNC Error attribute sent
in fulfillment with an error code appropriate to the nature
of a subscription have the same format as would error. In the case where a
direct response PA-TNC Error attribute is sent,
the SW-PC MUST NOT take any of the actions requested by the SW
Request attribute which led to the establishing request. For example, if detected error. This is the
establishing request stipulated a response that contained an event
record list wherein affected SWID tags were indicated using SWID tag
identifier instances, all attributes sent in fulfillment of this
subscription will also consist of event record lists expressed using
SWID tag identifier instances. As such, all SWID Responses displayed
in the exchange depicted in Figure 3 case
even if some actions could have been completed successfully, and
might even require the same format. A SWID
Response generated in fulfillment of an active subscription MUST be a
valid SWID Response attribute according SW-PC to all the rules outlined in reverse some successful actions
already taken before the preceding sections. error condition was detected. In other
words, an attribute constructed in
fulfillment either all aspects of a subscription will look SW Request complete fully and
successfully (in which case the same as an attribute sent
in direct response to an explicit request from SW-PC sends a SWID-PV that had SW Response attribute),
or no aspects of the
same request parameters and SW Request occur (in which arrived immediately after case the given
change event. There are SW-PC sends
a few special rules that expand on this
guideline:

3.8.5.1. Subscriptions Reporting Inventories PA-TNC Error attribute). In the case that a SWID-PV subscribes to SW-PC sends a SWID-PC requesting an
inventory PA-TNC
Error attribute whenever changes are detected (i.e. the EID in
the establishing request is 0), response to a SW Request then the SWID-PC SW-PC MUST NOT
also send any SW Response attribute in response to the
requested inventory whenever same SW
Request. For this reason, the sending of a relevant change is detected. (A
"relevant change" is any change for untargeted requests, or SW Response attribute
MUST be the last action taken by a change
to an indicated SWID tag SW-PC in response to a targeted request.) Upon detection SW Request
to avoid the possibility of a
relevant change for an active subscription, processing error occurring after that
SW Response attribute is sent.

In the SWID-PC sends case that the
appropriate inventory information as if SW-PC detects an error that prevents it had just received from
properly or completely fulfilling its obligations under an active
subscription, the
establishing request. Attributes sent in fulfillment of this
subscription will probably have SW-PC MUST send a large amount PA-TNC Error attribute of redundancy, as the
same tags are likely type
SW_SUBSCRIPTION_FULFILLMENT_ERROR to be present in each of these SWID Attributes.
The role the SW-PV that established this
subscription. This type of an inventory PA-TNC Error attribute identifies the
specific subscription is not that cannot be adequately honored due to report tags just for the items that changed - that
error condition as well as an error "sub-type". The error sub-type
is used to indicate the role type of a subscription error condition the SW-PC experienced
that
reports events (see Section 3.8.5.2). A SWID-PC MUST NOT exclude a
tag prevented it from an attribute sent in fulfillment of an inventory
subscription simply because honoring the given subscription. In the case
that tag was the error condition cannot be identified or does not involved in align with
any of the
triggering event (although defined error codes, the tag might SW_ERROR error code SHOULD be excluded for other
reasons, such as if the subscription is targeted - see
Section 3.8.5.3).

3.8.5.2. Subscriptions Reporting Events

The way
used in which a SWID-PV indicates it wishes to establish the sub-type. In the case that a
subscription requesting event records
SW_SUBSCRIPTION_FULFILLMENT_ERROR is by providing a non-zero EID
in the SWID Request establishing sent, the associated
subscription (see
Section 3.6.1). However, when MUST be treated as cancelled by both the SWID-PC constructs an attribute in
fulfillment of the subscription (other than the direct response to
the establishing request), it MUST only include event records for the
detected change(s) that precipitated this response attribute. In
other words, it SW-PC and SW-
PV.

The SW-PV MUST NOT send a complete list of all changes starting
with the indicated EID, up through the latest change, every time a
new event is detected. any PA-TNC Error attributes to SW-PCs. In effect, the EID in
the establishing
request is treated as being updated every time case that a SW-PV detects an attribute is sent
in fulfillment error condition, it SHOULD log this
error but does not inform any SW-PC's of this subscription, such that a single event is event. Errors might
include, but are not
reported twice in fulfillment limited to, detection of malformed SW Response
attributes sent from a single subscription. As such,
every SWID-PC MUST track the EID of the last event that triggered an
attribute for the given subscription. When the next event (or set SW-PC, as well as detection of
events) is detected, the SWID-PC MUST only report events with later
EIDs. In error
conditions when the case SW-PV processes SW Responses.

Both SW-PCs and SW-PVs SHOULD log errors so that administrators can
trace the EID Epoch causes of errors. Log messages SHOULD include the SWID-PC changes, type of
the
SWID-PC MUST treat EID values in error, the new Epoch as being after all
EIDs assigned time it was detected, and additional descriptive
information to aid in understanding the previous Epoch regardless nature and cause of the relative
numeric values
error.

4. Software Message and Attributes for PA-TNC Protocol

This section describes the format and semantics of these EIDs.

Note that while a subscription is active, the subscribing SWID-PV MAY
make other requests Software
Message and Attributes for event records that overlap with events that
are reported due to a subscription. Such requests are unaffected by PA-TNC protocol. Software Message and
Attributes for PA-TNC uses the presence standard PA-TNC message header format.
See the PA-TNC specification [RFC5792] for information on this header
format.

4.1. PA Subtype (AKA PA-TNC Component Type)

The NEA PB-TNC interface provides a general message-batching protocol
capable of carrying one or more PA-TNC messages between the subscription, nor Posture
Broker Client and Posture Broker Server. When PB-TNC is the subscription affected by
such requests. In other words, carrying a given request will get
PA-TNC message, the same
results back whether or not there was a subscription. Likewise, an
attribute sent in fulfillment of a subscription will PB-TNC message headers contain a 32 bit
identifier called the same
information whether or not other requests had been received from the
SWID-PV.

A SWID-PV needs to pay attention to PA Subtype. The PA Subtype field indicates the EID Epoch in these messages,
as changes in
type of component associated with all of the Epoch might create discontinuities in PA-TNC attributes
carried by the SWID-PV's
understanding PB-TNC message. The core set of the endpoint's SWID tag collection state, as
discussed PA Subtypes is
defined in Section 3.6.5. In particular, once the EID Epoch
changes, a SWID-PV is unable have confidence that it has a correct
understanding of PA-TNC specification. This specification adds the state of an endpoint's SWID tag collection until
after
following enumeration element to the SWID-PV collects a complete inventory.

SWID-PCs MAY send partial lists of event records table in fulfillment section 7.2 of a
subscription. (See Section 3.6.4 for more on partial list of event
records.) In the case that a SWID-PC sends a partial list of event
records, it MUST immediately send PA-
TNC specification [RFC5792] using the next consecutive partial list, IETF Standard name space (SMI
Private Enterprise Number 0x000000):

+-----+---------+-------------+-------------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+-------------+-------------------------------------+
| 0 | 9 | SW | Software Message 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
a partial list it does not wait Attributes for another change event |
| | | Attributes | PA-TNC |
+-----+---------+-------------+-------------------------------------+

Table 2: PA Subtype

Each PA-TNC attribute described in this specification is intended to send
another SWID Response, but continues sending SWID Responses until it
has
be sent all event records that would have been included in a
complete fulfillment of between the subscription.

3.8.5.3. Targeted Subscriptions

Subscriptions MAY SW-PC and SW-PV, so will be targeted to only apply to tags that match carried in a
given set PB-TNC
message indicating a PA Subtype of tag identifiers. In the case where changes are detected SW Attributes. Note that affect multiple tags, some matching the establishing request's
tag identifiers and some not, although
the PA-TNC Error attribute sent is defined in fulfillment the PA-TNC specification,
when it is used in a SW Attribute exchange, it uses the SW Attributes
Component Definition Value, as described in Section 4.2.8 of the subscription PA-
TNC specification [RFC5792]. PB-TNC messages MUST only always include inventory or events (as
appropriate) for tags that match the establishing request's tag
identifiers. The SWID-PC MUST NOT include non-matching tags
SW Attributes Subtype defined in the
attribute, even if those non-matching tags experienced change events
that were co-temporal with change events on the matching tags.

In addition, a SWID-PC MUST send an attribute in fulfillment of a
targeted subscription only this section when changes to the endpoint's SWID tag
collection impact carrying SW
Attributes over PA-TNC.

4.2. PB-TNC and PA-TNC Messages

A PA-TNC message is wrapped within a PB-TNC message. A single PA-TNC
message might contain one or more tags matching the subscription's
establishing request's tag identifiers. A SWID-PC MUST NOT send any
attribute in fulfillment PA-TNC attributes. All of these
attributes within a targeted subscription based on detected
change to the endpoint's SWID tag collection that did not involve any
of single PA-TNC message use the tags targeted by that subscription.

3.8.5.4. No Subscription Consolidation

A SWID-PV MAY establish multiple subscriptions to a given SWID-PC.
If this is same PA Subtype
value. As such, SW Attributes are never sent in the case, it is possible same PA-TNC
message as attributes defined in other PA-TNC binding specifications.

Note, however, that a single change event on the
endpoint PB-TNC batch might require fulfillment by contain multiple subscriptions, PB-
TNC and PA-TNC messages, and
that the information included in attributes that fulfill each of
these subscriptions those messages might overlap. use
different PA Subtypes.

For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively.

4.3. PA-TNC Attribute Header

The SWID-PC MUST send separate
attributes Software Message and Attributes for each established subscription that requires a response
due to the given event. Each of these attributes MUST contain all
information required to fulfill that individual subscription, even if
that information is also sent PA-TNC protocol described in other attributes sent in fulfillment
this specification is an extension of other subscriptions at the same time. In other words, SWID-PCs
MUST NOT attempt to combine information when fulfilling multiple
subscriptions simultaneously, even if this results in some redundancy PA-TNC protocol described
in the attributes sent NEA Architecture. PA-TNC was designed to the SWID-PV.

3.8.5.5. Delayed Subscription Fulfillment

A SWID-PC MAY delay the fulfillment of a subscription following a
change event be very flexible in the interest
order to carry many types of waiting PA-TNC attributes that pertain to see if additional change
events are forthcoming and, if so, conveying the relevant records
back an
enumerated set of component types (e.g. Table 2). PA-TNC attributes
might be carried from Posture Collector to the SWID-PV in a single SWID Response attribute. This can
help reduce network bandwidth consumption between the SWID-PC Posture Validator or vice
versa and the
SWID-PV. For example, consider a situation where 10 changes occur might carry information about endpoint state or other
information to be sent between a
tenth of Posture Validator and a second apart. If Posture
Collector. Therefore, the SWID-PC does not delay in assembling Software Message and sending SWID Response attributes, the SWID-PV will received 10
separate SWID Response attributes over Attributes for PA-TNC
specification defines a period collection of 1 second.
However, if the SWID-PC waits half a second after the initial event
before assembling a SWID Response, the SWID-PV only receives two SWID
Response PA-TNC attributes over relevant to
the same period collection and transmission of time.

Note that software inventories and
associated events.

Figure 4, reproduced from the ability to consolidate events for a single subscription
over PA-TNC specification, shows the format
of a given period of time does not contradict the rules PA-TNC attribute. Multiple PA-TNC attributes can be sent in
Section 3.8.5.4 prohibiting consolidation across multiple
subscriptions. When delaying fulfillment of subscriptions, SWID-PCs
are still required to fulfill a
single PB-TNC message, each individual subscription
separately. Moreover, in the case that change events housed within the
delay window cancel each other out (e.g., a SWID tag is deleted an attribute structure as
described below.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: PA-TNC Header and
then re-added), the SWID-PC MUST still report each change event
rather than just reporting Attribute Format

+-----------+-------------------------------------------------------+
| Field | Description |
+-----------+-------------------------------------------------------+
| Flags | This field defines flags affecting the net effect processing of changes over |
| | the delay
period. In other words, delayed fulfillment can decrease Software Message and Attributes for PA-TNC. |
| | Permissible flags are given in the number PA-TNC |
| | specification. [RFC5792] |
| | |
| Attribute | This field indicates the owner of attributes send by the SWID-PC, but it does not reduce name space |
| Type | associated with the total
number of change events reported.

SWID-PCs are not required to support delayed fulfillment of
subscriptions. However, Attribute Type. Attributes |
| Vendor ID | defined in the case that the SWID-PC does support
delayed subscription fulfillment, it MUST be possible Software Message and Attributes for |
| | PA-TNC specification have a value corresponding to configure |
| | the SWID-PC to disable delayed fulfillment. In other words, parties
deploying SWID-PCs need to be allowed to disable delayed subscription
fulfillment in their SWID-PCs. IETF SMI Private Enterprise Number value |
| | (0x000000). The manner in which such
configuration occurs PA-TNC Error attribute is left to defined in |
| | the discretion PA-TNC specification [RFC5792] and also uses the |
| | IETF SMI Private Enterprise Number Value (0x000000). |
| | See Table 4 for more information. |
| | |
| Attribute | This field defines the type of implementers,
although implementers MUST protect the configuration procedure from
unauthorized tampering. In other words, there needs Attribute. The |
| Type | values corresponding to be some
assurance that unauthorized individuals SW Attributes are not able to introduce
long delays in subscription fulfillment.

3.9. Multiple Sources of SWID Tags

As noted in Section 2.1, the SWID tags given in an endpoint's SWID tag
collection might potentially come from multiple sources. For
example, SWID tags might be deposited on |
| | Table 4. |
| | |
| Attribute | This field contains the file system and
collected therefrom. SWID tags might also be dynamically generated
by tools such as software and package managers (e.g., RPM or YUM) or
might be dynamically translated from software discovery reports
expressed length in some non-SWID format.

A SWID-PC is not required to identify every possible source octets of SWID
tags on its endpoint. Some SWID-PCs might be explicitly tied only to
one or a handful of SWID tag sources. SWID-PCs are not required to
be aware of SWID tags that come from sources other than those that
they specifically support. In particular, if an endpoint has 3
sources the |
| Length | entire Attribute, including the Attribute's header. |
| | |
| Attribute | This field contains the SW Attribute. |
| Value | |
+-----------+-------------------------------------------------------+

Table 3: Fields of SWID tags, and the PA-TNC Attribute Format

4.4. SW Attribute Overview

The attributes defined in this specification appear below with a SWID-PC supports collecting SWID tags
from two
short summary of those sources, not only their purposes. Each attribute is that SWID-PC only responsible
for reporting tags that come from its two supported sources, but it described in
greater detail in subsequent sections.

o SW Request - This attribute is also only responsible for monitoring for change events used to request a software
inventory or software event list from those
two sources. an endpoint. This noted, for all of the SWID tag sources that attribute
might also establish a
particular SWID-PC supports, it subscription on the recipient SW-PC. A SW-
PC MUST completely support all
requirements of NOT send this specification with regard to its supported
sources. In other words, for supported sources, the SWID-PC attribute.

o Software Identifier Inventory - This attribute is
required used to be capable of providing complete inventories convey
an inventory expressed using Software Identifiers (instead of SWID
tags; monitoring for changes in the SWID collections reported by
those sources, correctly providing responses for both full and
targeted requests, and providing either complete SWID tag files or
SWID identifier instances as appropriate. The SWID-PC
records). When a SW-PC receives a SW Request attribute requesting
an inventory using Software Identifiers, the SW-PC MUST send a
Software Identifier Inventory 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
provide any inventory or event information from SWID tag sources for
which it cannot provide send this full support.

The SWID Response attributes provide no way
attribute.

o Software Identifier Events - This attribute is used to convey a
list of distinguishing as events concerning changes to
which SWID tags, identifier instances, or event an endpoint's Software
Inventory Evidence Collection. Affected software inventory
evidence records are
associated with specific sources. The SWID-PC MUST include the
complete set of relevant data from all supported sources indicated using Software Identifiers (instead
of SWID tags
in every SWID Response. In other words, a full inventory is required
to contain all the SWID tags from all supported sources, records). When a targeted
inventory is required to contain all relevant tags from all sources,
and event tracking is required to cover all events from both sources.
With regard to events, SW-PC receives a SWID-PC's assignment of EIDs MUST reflect SW Request attribute
requesting an event collection using Software Identifiers, the presence and order of all events on SW-
PC MUST send a Software Identifier Events attribute (or a PA-TNC
Error) in response. This attribute also MAY be sent by the endpoint (at least for
supported sources) regardless SW-PC
in fulfillment of the source. This means that if
source A experiences an event, and then source B experiences two
events, and then source active subscription. A experiences another two events, the SWID-PC SW-PV MUST NOT send
this attribute.

o Software Inventory - This attribute is required used to capture five events with consecutive EID values
reflecting the order in which the events occur.

Note that, if a SWID-PC collects data from multiple sources, it is
possible that some convey an inventory
expressed using full software products might be "double counted". This
can happen if both sources inventory evidence records (instead
of SWID tags provide a SWID tag for Software Identifiers). When a
single instance of SW-PC receives a SW Request
attribute requesting an inventory using full software product. Moreover, each of these
provided tags will probably have different SWID tag identifier
instances, since Instance IDs are managed by the process that
extracts the SWID tags from the individual sources, and such
processes are under no obligation to coordinate with each other as to inventory
evidence records, the Instance ID value. When a SWID-PC reports information or records
events from multiple SWID tag sources, it SW-PC MUST use send a Software Inventory
attribute (or a PA-TNC Error) in response. This attribute also
MAY be sent by the information
those sources provide, rather than attempting to perform some form SW-PC in fulfillment of
reduction. In other words, if multiple sources report a particular
SWID tag corresponding an active subscription.
A SW-PV MUST NOT send this attribute.

o Software Events - This attribute is used to convey a single installation list of a
events concerning changes to an endpoint's inventory evidence
collection. Affected software
product, all such tags from each source inventory evidence records are required to be part
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 SWID-PC's processing even if this might lead to multiple
reporting, and the SWID-PC is not to ignore some tags to avoid such
multiple reporting. Similarly, SW-PC MUST send a Software
Events attribute (or a PA-TNC Error) in response. This attribute
also MAY be sent by the case that multiple sources
report SW-PC in fulfillment of an event, the SWID-PC active
subscription. A SW-PV MUST create separate event records with
separate EIDs for each of these, even if there is the chance that
they represent the two sources reporting the same action on the
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 NOT send this attribute.

o Subscription Status Request - This attribute is up used to the
implementers request a
SW-PC send a summary of those entities.

3.10. Error Handling

In all the case active subscriptions it has where
the SWID-PC detects an error in a SWID Request
attribute that it receives it requesting party is the subscriber. The SW-PC MUST respond
with a Subscription Status Response (or a PA-TNC Error Error). A SW-PC
MUST NOT send this attribute.

o Subscription Status Response - This attribute with an error code appropriate is used to convey
information about the nature of the error.
(See Section 4.2.8 of PA-TNC [RFC5792] active subscriptions that a SW-PC has for more details about a
given subscriber. A SW-PV MUST NOT send this attribute.

o PA-TNC Error attributes and error codes as well - This is the standard PA-TNC Error attribute as Section 4.16
defined in this
specification for error codes specific PA-TNC [RFC5792] and is used to SWID attributes.) In the
cast indicate that an error is detected in
was encountered during a SWID Request the SWID-PC SW Attribute exchange. It MUST NOT
take any action requested by this SWID Request, even if some
requested action can be completed successfully despite the error sent
by a SW-PC in
the attribute. In other words, response to a SWID SW Request that contains an error
is ignored by the SWID-PC beyond sending a PA-TNC Error attribute,
and possibly logging the error locally.

In in the case where the SWID-PC receives SW-PC
encounters a valid SWID Request attribute
but experiences fatal error (i.e., an error during the process of responding to that
attribute's instructions where that error prevents further
processing of an exchange) relating to the SWID-PC from
properly or completely fulfilling that request, the SWID-PC attribute exchange. A
SW-PV MUST NOT send this attribute. The SW-PC MUST then ignore
the erroneous attribute after a PA-TNC Error attribute with an error code appropriate is sent
(i.e., do not attempt to act on an attribute that generated a PA-
TNC Error beyond sending the nature
of the error. PA-TNC Error). In the case where the
SW-PV experiences a fatal error, it MUST ignore the erroneous
attribute without sending a PA-TNC Error attribute is sent,
the SWID-PC MUST NOT attribute. It MAY take any of the
other actions requested by the SWID
Request attribute which led in response to the detected error. This is error, such as logging the case cause
of the error, or even if some taking actions can be completed successfully, and might even
require the SWID-PC to reverse some successful actions already taken
before isolate the error condition was detected. In other words, either all
aspects endpoint

Because one of a SWID Request complete fully and successfully (in which
case the SWID-PC sends a SWID Response attribute), Software Identifier Inventory, Software Identifier
Events, Software Inventory, or no aspects of
the SWID Request occur (in which case the SWID-PC sends a PA-TNC
Error attribute). In the case that a SWID-PC sends Software Events attributes is expected
to be sent to a PA-TNC Error
attribute SW-PV in direct response to a SWID SW Request then the SWID-PC MUST NOT
also send any SWID Response attribute or
in response fulfillment of an active subscription, those four attribute types
are referred to the same SWID
Request. For collectively in this reason, the document as "SW Response"
attributes.

All SW-PVs MUST be capable of sending SW Requests and be capable of a SWID
receiving and processing all SW Response attribute attributes as well as PA-TNC
Error attributes. All SW-PCs MUST be the last action taken by a SWID-PC in response to a SWID
Request to avoid the possibility capable of a receiving and
processing error occurring
after that SWID SW Requests and be capable of sending all types of SW
Response attribute is sent.

In the case that the SWID-PC detects an error that prevents it from
properly or completely fulfilling its obligations under an active
subscription, the SWID-PC MUST send a attributes as well as PA-TNC Error attribute of type
SWID_SUBSCRIPTION_FULFILLMENT_ERROR attributes. In other
words, both SW-PVs and SW-PCs are required to support their role in
exchanges using any of the SWID-PV that established attribute types defined in this subscription. This type of section.
SW-PVs MUST ignore any SW Request attributes that they receive. SW-
PCs MUST ignore any SW Response attributes or PA-TNC Error attribute identifies
the specific subscription attributes
that cannot be adequately honored due to
the error condition as well as an error "sub-type". The error sub-
type they receive.

4.5. SW Attribute Exchanges

A SW Attribute Exchange is used to indicate provide the type of error condition SW-PV with a software
inventory or event collection from the SWID-PC
experienced that prevented it from honoring queried endpoint.

+-------------+ +--------------+
| SW-PC | | SW-PV | Time
+-------------+ +--------------+ |
| | |
|<------------SW Request--------------| |
| | |
| SW Response* | |
|-----------------or----------------->| |
| PA-TNC Error | |
| | V

*SW Response is one of the given subscription. following: Software Identifier
Inventory, Software Identifier Events, Software Inventory,
or Software Events.

Figure 5: SW Attribute Exchange (Direct Response to SW Request)

In this exchange, the case that SW-PV indicates to the error condition cannot be identified or does not
align with any SW-PC, via a SW Request,
the nature of the defined error codes, information it wishes to receive (inventory vs.
events, full or targeted) and how it wishes the SWID_ERROR error code
SHOULD returned inventory to
be used in the sub-type. In the case that a
SWID_SUBSCRIPTION_FULFILLMENT_ERROR is sent, expressed (full records or Software Identifiers). The SW-PC
responds with the associated
subscription MUST be treated as cancelled by both requested information using the SWID-PC and
SWID-PV.

The SWID-PV appropriate
attribute type. A single SW Request MUST NOT send any only lead to a single SW
Response or PA-TNC Error attributes that is in direct response to SWID-PCs. that request.

In addition, if there is an active subscription on the case that endpoint, the
SW-PC sends a SWID-PV detects an error condition, it SHOULD log
this error but does not inform any SWID-PC's of this event. Errors
might include, but are not limited to, detection of malformed SWID SW Response attributes sent from a given SWID-PC, as well as detection
of error conditions when the SWID-PV processes SWID Responses.

Both SWID-PCs and SWID-PVs SHOULD log errors so that administrators
can trace to the causes of errors. Log messages SHOULD include SW-PV following a change event on
the type endpoint in fulfillment of the error, the time it was detected, and additional descriptive
information to aid that subscription. Such an exchange
is shown in understanding the nature and cause Figure 6.

*SW Response is one of the
error.

4. SWID Message and Attributes for PA-TNC Protocol

This section describes the format and semantics following: Software Identifier
Inventory, Software Identifier Events, Software Inventory,
or Software Events.

Figure 6: SW Attribute Exchange (In Fulfillment of the SWID Message
and Attributes an Active
Subscription)

Note that, unlike direct responses to a SW Request, a single change
event can precipitate multiple SW Responses for PA-TNC protocol leveraging a single
subscription, but only if all but the existing SWID tag
format. SWID Message last of those SW Responses
convey partial lists of event records, and Attributes for PA-TNC uses the standard PA-
TNC message header format. See the PA-TNC specification [RFC5792]
for information on this header format.

4.1. PA Subtype (AKA PA-TNC Component Type)

The NEA PB-TNC interface provides last of those SW
Responses conveys a general message-batching protocol
capable complete list of carrying one or more PA-TNC messages between event records. (That is, the Posture
Broker Client
initial responses are partial lists and Posture Broker Server. When PB-TNC the last response is carrying a
PA-TNC message, the PB-TNC message headers contain a 32 bit
identifier called
remainder of the PA Subtype. The PA Subtype field indicates relevant event records, completing the
type delivery of component associated with
all relevant events at the time of the change event.) A single
Change Event MUST NOT be followed by multiple SW Response or PA-TNC
Error attributes
carried by the PB-TNC message. The core set of PA Subtypes is
defined in the PA-TNC specification. any combination except as noted earlier in this
paragraph.

All SW-PVs and SW-PCs MUST support both types of exchanges. In order for the NEA protocols
particular, SW-PCs MUST be capable of pushing a SW Response to carry SWID tags, this specification adds the following enumeration
element a SW-
PV immediately upon detection of a change to the table endpoint's Software
Inventory Evidence Collection in section 7.2 fulfillment of established SW-PV
subscriptions, as described in Section 3.6.

4.6. Software Message and Attributes for PA-TNC Attribute Enumeration

PA-TNC attribute types are identified in the PA-TNC specification
[RFC5792] using Attribute Header
(see Section 4.2) via the IETF Standard name space (SMI Private Enterprise
Number 0x000000):

+-----+---------+----------------+----------------------------------+ Attribute Type Vendor ID and Attribute Type
fields. Table 4 identifies the appropriate values for these fields
for each attribute type used within the Software Message and
Attributes for PA-TNC protocol.

+--------------+----------+------------+----------------------------+
| Attribute | PEN | Integer | Description |
| Name | Defining Specification |
+-----+---------+----------------+----------------------------------+ | 0 | 9
+--------------+----------+------------+----------------------------+
| SWID SW Request | SWID Message and Attributes for 0x000000 | 0x00000011 | Request from a SW-PV to a |
| Attributes | PA-TNC |
+-----+---------+----------------+----------------------------------+

Table 2: PA Subtype

Each PA-TNC attribute described in this specification is intended to
be sent between | SW-PC for the SWID-PC and SWID-PV, so will be carried in a PB-
TNC message indicating SW-PC to |
| | | | provide a PA Subtype software |
| | | | inventory or event list |
| | | | |
| Software | 0x000000 | 0x00000012 | A collection of SWID Attributes. Note that
although the PA-TNC Error attribute is defined in the PA-TNC
specification, when it is used in a SWID Attribute exchange, it uses
the SWID Attributes Component Definition Value, as described in
Section 4.2.8 of the PA-TNC specification [RFC5792]. PB-TNC messages
MUST always include the SWID Attributes Subtype defined in this
section when carrying SWID Attributes over PA-TNC.

4.2. PB-TNC and PA-TNC Messages

For more information on PB-TNC and PA-TNC messages and message
headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
specifications, respectively.

4.3. PA-TNC Attribute Header

The SWID Message and Attributes for PA-TNC protocol described in this
specification is an extension of the PA-TNC protocol described in the
NEA Architecture. PA-TNC was designed to be very flexible in 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
might be carried from Posture Collector to Posture Validator or vice
versa and might carry information about endpoint state or other
information to be sent between a Posture Validator and a Posture
Collector. Therefore the SWID Message and Attributes for PA-TNC
specification defines a collection of PA-TNC attributes relevant to
the collection and transmission of SWID tag inventories.

Figure 4, reproduced from the PA-TNC specification, shows events |
| Events | | | impacting the format
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
described below.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ endpoint's | Flags
| PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Software Inventory | PA-TNC Attribute Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: PA-TNC Header and Attribute Format

Table 3: Fields of the PA-TNC Attribute Format

4.4. SWID Attribute Overview

The attributes Error | 0x000000 | 0x00000008 | An error attribute as |
| | | | defined in this the PA-TNC |
| | | | specification appear below with a
short summary [RFC5792]. |
+--------------+----------+------------+----------------------------+

Table 4: SW Attribute Enumeration

4.7. Normalization of their purposes. Each attribute is described in
greater detail Text Encoding

In order to ensure consistency of transmitted attributes, a field
requiring normalization, as indicated in subsequent sections.

o SWID Request - This attribute is used its description, MUST be
normalized to request Network Unicode format as defined in RFC 5198
[RFC5198]. Network Unicode format defines a SWID tag
inventory or SWID event list from an endpoint. This attribute
might also establish refinement of UTF-8 that
ensures a subscription on the recipient SWID-PC. A
SWID-PC normalized expression of characters. SW-PCs and SW-PVs
MUST NOT send this attribute.

o SWID Tag Identifier Inventory - This attribute perform conversion and normalization on any field values
except those specifically identified as requiring normalization in
the following sections. Note, however, that some data models require
additional normalization before source information is used added to convey an inventory expressed using SWID tag identifier instances
(instead of full tags). When a SWID-PC receives
Endpoint's Inventory Evidence Collection as a SWID Request
attribute requesting an inventory using SWID tag identifier
instances, record. The references
from the SWID-PC Software Data Model IANA table (see section Section 9.4 will
note where this is necessary.

4.8. Request IDs

All SW Request attributes MUST send include a SWID Tag Identifier Inventory
attribute (or Request ID value. The
Request ID field provides a PA-TNC Error) in response. This attribute also
MAY be sent by value that identifies a given request
relative to other requests between a SW-PV and the SWID-PC in fulfillment of an active
subscription. A SWID-PV MUST NOT send this attribute.

o SWID Tag Identifier Events - This receiving SW-PC.
Specifically, the SW-PV assigns each SW Request attribute a Request
ID value that is used intended to convey a
list of events concerning changes to an endpoint's collection of
SWID tags. Affected SWID tags are indicated using SWID tag
identifier instances (instead be unique within the lifetime of full tags). When a SWID-PC
receives a SWID given
network connection ID as assigned by the SW-PV's Posture Broker
Server. In the case where all possible Request attribute requesting an event collection
using with SWID tag identifier instances, ID values have been
exhausted within the SWID-PC MUST send a
SWID Tag Identifier Events attribute (or lifetime of a PA-TNC Error) in
response. This attribute also single network connection ID, the
sender MAY be sent by reuse previously used Request IDs within the SWID-PC same network
connection that are not being used as Subscription IDs. (See below
in
fulfillment of an active subscription. A SWID-PV MUST NOT send this attribute.

o SWID Tag Inventory - This attribute is used to convey section for an inventory
expressed using full SWID tags (instead explanation of Subscription ID assignment.)
In this case of SWID tag identifier
instances). When a SWID-PC receives a SWID Request attribute
requesting an inventory using full SWID tags, ID reuse, Request IDs SHOULD be reused in the SWID-PC MUST
send
order of their original use. For example, if a SWID Tag Inventory attribute (or Request ID of X was
the first Request ID used within a PA-TNC Error) in
response. This attribute also MAY particular network connection and
if the Request IDs are exhausted, X will be sent by the SWID-PC in
fulfillment of an active subscription. A SWID-PV MUST first reused Request
ID. In other words, a SW-PC SHOULD NOT send
this attribute.

o SWID Tag Events - This attribute is used to convey a list of
events concerning changes to an endpoint's collection of SWID
tags. Affected SWID tags are indicated using full SWID tags
(instead of SWID tag identifier instances). When a SWID-PC
receives use a SWID given Request attribute requesting an event collection
using full SWID tags, the SWID-PC MUST send ID value
more than once within a SWID Tag Events
attribute (or persistent connection between a PA-TNC Error) given Posture
Broker Client-Posture Broker Server pair, but, 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 Subscription Status Request - This attribute case where
reuse is used necessary due to request a
SWID-PC send a summary exhaustion of all possible ID values, the active subscriptions it has
where SW-PC
SHOULD structure the requesting party is reuse to maximize the subscriber. time between original and
subsequent use. The SWID-PC MUST
respond with a Subscription Status Response (or Request ID value is included in a PA-TNC Error).
A SWID-PC MUST NOT send this attribute.

o Subscription Status SW Response - This
attribute is used directly responding to convey
information about the active subscriptions that a SWID-PC has for
a given subscriber. A SWID-PV MUST NOT send this attribute.

o PA-TNC Error - This is the standard PA-TNC Error attribute as
defined in PA-TNC [RFC5792] and is used SW Request to indicate that an error which SW
Request was encountered during a SWID Attribute exchange. It MUST received and caused the response. Request IDs can be sent
by a SWID-PC
randomly generated or sequential, as long as values are not repeated
per the rules in response this paragraph. SW-PCs are not required to a SWID check
for duplicate Request in IDs.

In the case where that a SW Request requests the
SWID-PC encounters establishment of a fatal error
subscription and the receiving SW-PC agrees to that subscription, the
Request ID of that SW Request (i.e., an error the establishing request of the
subscription) becomes that prevents
further processing subscription's Subscription ID. All
attributes sent in fulfillment of an exchange) relating to this subscription include a flag
indicating that the attribute
exchange. fulfills a subscription and the
subscription's Subscription ID. A SWID-PV SW-PV MUST NOT send this attribute. The SWID-PC
MUST then ignore the erroneous attribute after reuse a PA-TNC Error
attribute is sent (i.e., do not attempt Request ID
value in communicating to act on an attribute a given SW-PC while that generated Request ID is also
serving as a PA-TNC Error beyond sending the PA-TNC Error). Subscription ID for an active subscription with that SW-
PC. In the case where the SWID-PV experiences a fatal error, it MUST
ignore the erroneous attribute without sending SW-PC receives a PA-TNC Error
attribute. It MAY take other actions in response to the error,
such as logging SW Request from a given SW-
PV where that Request ID is also the cause Subscription ID of an active
subscription with that SW-PV, the error, or even taking actions to
isolate the endpoint

Because one SW-PC MUST respond with a PA-TNC
Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR.
Note that this error does not cancel the SWID Tag Identifier Inventory, SWID Tag Identifier
Events, SWID Tag Inventory, or SWID Tag Events attributes is expected
to be sent indicated subscription.

Subscription Status Requests and Subscription Status Responses do not
include Request IDs.

4.9. SW Request

A SW-PV sends this attribute to a SWID-PV in direct response SW-PC to a SWID Request
attribute or in fulfillment of an active subscription, those four
attribute types are frequently referred to collectively in this
document as "SWID Response" attributes.

All SWID-PVs MUST be capable of sending SWID Requests and be capable
of receiving and processing all SWID Response attributes as well as
PA-TNC Error attributes. All SWID-PCs MUST be capable of receiving
and processing SWID Requests and be capable of sending all types of
SWID Response attributes as well as PA-TNC Error attributes. In
other words, both SWID-PVs and SWID-PCs are required to support their
role in exchanges using any of the attribute types defined in this
section. SWID-PVs MUST ignore any SWID Request attributes that they
receive. SWID-PCs MUST ignore any SWID Response attributes or PA-TNC
Error attributes request that they receive.

4.5. SWID Attribute Exchanges

A SWID Attribute Exchange is used to provide the SWID-PV with a SWID
tag SW-PC
send software inventory or event collection from information to the queried endpoint.

+-------------+ +--------------+ SW-PV. A SW-PC MUST NOT
send this attribute.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SWID-PC Flags | Software Identifier Count | SWID-PV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time
+-------------+ +--------------+ Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|<-----------SWID Request-------------| Software Identifier Length | Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: SW Request Attribute

*SWID Response is one of the following: SWID Tag Identifier
Inventory, SWID Tag Identifier Events, SWID Tag Inventory,
or SWID Tag Events.

Figure 5: SWID Attribute Exchange (Direct Response (barring any errors). |
| | |
| Flags: Bit 1 | If set (1), in addition to SWID Request)

In this exchange, the SWID-PV indicates responding to the SWID-PC, via a SWID
Request, |
| - Subscribe | request as described, the nature of SW-PC MUST establish a |
| | subscription with parameters matching those in |
| | the information it wishes to receive
(inventory vs. events, full or targeted) and how it wishes request attribute (barring any errors). |
| | |
| Flags: Bit 2 | If unset (0), the
returned SW-PC's response MUST consist |
| - Result Type | of complete software inventory to be expressed (full tags or tag identifier
instances). The SWID-PC responds with the requested information
using evidence records |
| | and thus the appropriate attribute type. A single SWID Request response MUST
only lead to be a single SWID Response Software |
| | Inventory, a Software Events, or a PA-TNC Error that is in direct
response to that request.

In addition, if there is an active subscription on |
| | attribute. If set (1), the endpoint, response MUST consist |
| | of Software Identifiers and thus the
SWID-PC sends response |
| | MUST be a SWID Response to the SWID-PV following Software Identifier Inventory, a change event
on the endpoint in fulfillment of that subscription. Such an
exchange is shown in Figure 6.

*SWID Response is one of the following: SWID Tag Identifier
Inventory, SWID Tag Identifier Events, SWID Tag Inventory,
or SWID Tag Events.

Figure 6: SWID Attribute Exchange (In Fulfillment of an Active
Subscription)

Note that, unlike direct responses 3-7 - | to a SWID Request, a single change
event can precipitate multiple SWID Responses, but only if all but
the last of those SWID Responses convey partial lists of event
records, zero on transmission and ignored upon |
| Reserved | reception. |
| | |
| Software | A 3-byte unsigned integer indicating the last of those SWID Responses conveys a complete list number |
| Identifier | of event records. (That is, the initial responses are partial lists
and the last response Software Identifiers that follow. If this |
| Count | value is the remainder of the relevant event records,
completing the delivery of all relevant events at the time of the
change event.) A single Change Event MUST NOT be followed by
multiple SWID Response or PA-TNC Error attributes in any combination
except as noted earlier in non-zero, this paragraph.

All SWID-PVs and SWID-PCs MUST support both exchanges. In
particular, SWID-PCs MUST be capable of pushing a SWID Response to a
SWID-PV immediately upon detection of is a change to the endpoint's SWID
tag collection in fulfillment of established SWID-PV subscriptions, targeted request, as |
| | described in Section 3.8.

4.6. SWID Message 3.3. The Software |
| | Identifier Length and Attributes for PA-TNC Attribute Enumeration

PA-TNC attribute types Software ID fields are identified |
| | repeated, in order, the PA-TNC Attribute Header
(see Section 4.2) via the Attribute Type Vendor ID and Attribute Type
fields. Table 4 identifies the appropriate values for these fields
for each attribute type used within the SWID Message and Attributes
for PA-TNC protocol.

Table 4: SWID 5: SW Request Attribute Enumeration

4.7. Normalization of Text Encoding

SWID tags do not have a required encoding format. Fields

The 2009 ISO SWID
specification states SW-PV sends the SW Request attribute to a SW-PC to request the
indicated information. Note that "For encoding purposes, between the use of utf-8 is Result Type flag and
the suggested methodology for software identification tags...", but
leaves implementers free Earliest EID field, the SW-PC is constrained to use different encodings if this makes
sense a single possible
SW Response attribute type (or a PA-TNC Error attribute) in their local environment. As such, implementers of its
response to the SWID
Message request.

The Subscribe and Attributes Clear Subscription flags are used to manage
subscriptions 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 requesting SW-PV on the SWID Message and
Attributes for PA-TNC specification requires receiving SW-PC.
Specifically, an attribute with the use of data taken
from other sources, such Subscribe flag set seeks to
establish a path from new subscription by the endpoint's file system, and
different platforms might use different encodings for this
information. In order requesting SW-PV to ensure the ability given SW-
PC, while an attribute with the Clear Subscription flag seeks to consistently and
reliably compare information sent using
delete all existing subscriptions by the SWID Message and
Attributes for PA-TNC exchange, certain field values (identified
explicitly in requesting SW-PV on the attribute definitions
given SW-PC. Note that, in the following sections) latter case, only the subscriptions
associated with the Connection ID and the Posture Validator ID of the
requester are required to undergo normalization prior to their inclusion deleted as described in an Section 3.6.3. A newly
established subscription has the parameters outlined in the Request
attribute.

In order Specifically, the Result Type flag indicates the type of
result to ensure consistency send in fulfillment of transmitted attributes, a field
requiring normalization, as indicated in its description, and only
such fields MUST be normalized to Network Unicode format as defined
in RFC 5198 [RFC5198]. Network Unicode format defines a refinement
of UTF-8 that ensures a normalized expression the subscription, the value of characters. SWID-
PCs and SWID-PVs MUST NOT perform conversion and normalization on any the
Earliest EID field values except those specifically identified in indicates whether the following
sections.

4.8. Request IDs

All SWID Request fulfillment attributes MUST include a Request ID value. The
Request ID field provides list
inventories or events, and the fields describing Software Identifiers
(if present) indicate if and how a value subscription is targeted. In the
case that identifies a given the SW-PC is unable or unwilling to comply with the SW-PV's
request
relative to other requests between establish or clear subscriptions, the SW-PC MUST respond
with a SWID-PV and PA-TNC Error attribute with the receiving SWID-
PC. Specifically, SW_SUBSCRIPTION_DENIED_ERROR
error code. (Note that if the SWID-PV assigns each SWID Request attribute a
Request ID value SW-PV requests that is intended to subscriptions be unique within
cleared but has no existing subscriptions, this is not an error.)

An attribute requesting the lifetime establishment of a given network connection ID subscription is
effectively doing double-duty, as assigned by it is a request for an immediate
response from the SWID-PV's Posture
Broker Server. In SW-PC in addition to setting up the case where all possible Request ID values have
been exhausted within subscription.
Assuming the lifetime of a single network connection ID, SW-PC is willing to comply with the sender MAY reuse previously used Request IDs within subscription it MUST
send an appropriate response attribute to a request with the same
network connection that are not being used as Subscription IDs. (See
below in this section for an explanation
Subscribe flag set containing all requested information. The same is
true of the Clear Subscription ID
assignment.) In this case of Request ID reuse, Request IDs SHOULD be
reused in flag - assuming there is no error the order of their original use. For example, if
SW-PC MUST generate a Request
ID response attribute without regard to the
presence of X was this flag in addition to clearing its subscription list.

Both the first Request ID used within a particular network
connection Subscribe and if the Request IDs are exhausted, X will Clear Subscription flags MAY be the first
reused Request ID. In other words, a SWID-PC SHOULD NOT use set in a given
single SW Request ID value more than once within a persistent connection
between a given Posture Broker Client-Posture Broker Server pair,
but, in attribute. In the case where reuse this request is necessary due to exhaustion of
possible ID values, the SWID-PC SHOULD structure
successful, the reuse end result MUST be equivalent to
maximize the time between original SW-PC clearing
its subscription list for the given SW-PV first and subsequent use. The Request
ID value is included in then creating a response attribute directly responding to
this SWID Request to indicate which SWID Request was received and
caused
new subscription in accordance with the response. Request IDs can be randomly generated or
sequential, as long as values are request parameters. (In
other words, do not repeated per first create the rules in this
paragraph. SWID-PCs are not required to check for duplicate Request
IDs.

In new subscription and then clear
all the case subscriptions including the one that a SWID Request requests the establishment of a
subscription and the receiving SWID-PC agrees to that subscription, was just created.) In
the Request ID of case that SWID Request (i.e., the establishing request
of requested actions are successfully completed, the subscription) becomes that subscription's Subscription ID.
All attributes sent in fulfillment of this subscription include
SW-PC MUST respond with a
flag indicating that the SW Response attribute. (The specific type
of SW Response attribute fulfills a subscription and depends on the
subscription's Subscription ID. A SWID-PV MUST NOT reuse a Request
ID value in communicating to a given SWID-PC while that Request ID is
also serving Result Type and Earliest EID
fields, as a Subscription ID for an active subscription with
that SWID-PC. described above.) In the case where there is a SWID-PC receives a SWID Request failure
that prevents some part this request from completing, the SW-PC MUST
NOT add a given SWID-PV where that Request ID is also new subscription, MUST NOT clear the Subscription
ID of an active subscription with that SWID-PV, old subscriptions, and
the SWID-PC SW-PC MUST respond with a PA-TNC Error attribute with an error code of
SWID_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not
cancel attribute. In other
words, the indicated subscription.

Subscription Status Requests and Subscription Status Responses do not
include Request IDs.

4.9. SWID Request

A SWID-PV sends this attribute to SW-PC MUST NOT partially succeed at implementing such a SWID-PC
request; either both actions succeed, or neither succeed.

The Earliest EID field is used to request that indicate whether the SWID-
PC send SWID tag-based information to SW-PV is
requesting an inventory or event list from the SWID-PV. SW-PC. A SWID-PC MUST
NOT send this attribute.

1 2 3
0 1 2 3 4 5 6 7 8 9 value of 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
(0x00000000) represents a request for inventory information.
Otherwise, the SW-PV is requesting event information. For Earliest
EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Creator Length | Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: SWID Request Attribute

+---------------+---------------------------------------------------+
| Field | Description |
+---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), values other than 0, the SWID-PC SW-PC's response MUST delete all |
| - Clear | subscriptions established by the requesting SWID- |
| Subscriptions | PV (barring any errors). |
| Flags: Bit 1 | If set (1), respond with event
records, as described in addition to responding to Section 3.5. Note that the |
| - Subscribe | request as described, the SWID-PC MUST establish |
| | does not
identify a subscription with parameters matching those particular EID Epoch, since responses can only include
events in |
| | the request attribute (barring any errors). |
| Flags: Bit 2 | If unset (0), SW-PC's current EID Epoch.

The Software Identifier Count indicates the SWID-PC's response MUST consist |
| - Result Type | number of complete SWID tags and thus Software
Identifiers in the response MUST |
| | be a SWID Tag Inventory, a SWID Tag Events, or a |
| | PA-TNC Error attribute. If set (1), the response |
| | MUST consist of SWID tag identifier instances and |
| | thus the response MUST be a SWID Tag Identifier |
| | Inventory, a SWID Tag Identifier Events, or a PA- |
| | TNC Error attribute. |
| Flags: Bit | Reserved for future use. This field MUST number might be set |
| 3-7 - | to zero on transmission any value between
0 and ignored upon |
| Reserved | reception. |
| Tag ID Count | 16,777,216, inclusive. A 3-byte unsigned integer indicating single Software Identifier is
represented by fields: Software Identifier Length and Software ID.
The Software Identifier Length field indicates the number |
| | of tag identifiers that follow. If this value is |
| | non-zero, this is bytes
allocated to Software ID field. The Software Identifier field
contains a targeted request, Software Identifier as |
| | described describe in Section 3.4. This field is a 3-byte |
| | unsigned integer. 3.2. The Tag Creator Length, Tag |
| | Creator, Unique Software ID Length, and Unique |
| |
presence of one or more Software ID fields are repeated, in order, Identifiers is used by the |
| | number SW-PV to
indicate a targeted request, which seeks only inventories of times indicated in this field. In the |
| | case where tag identifiers are present, or
events affecting software corresponding to the SWID- |
| | PC given identifiers.
The SW-PC MUST only respond with SWID tags or tag |
| | identifier instances records that correspond to the |
| | identifiers match the SWID-PV Software
Identifiers provided in the SW-PVs SW Request attribute.

4.10. Software Identifier Inventory

A SW-PC sends this |
| | attribute (or with to a PA-TNC Error attribute). |
| | This field value MAY be 0, SW-PV to convey the inventory of
the endpoint's Software Inventory Evidence Collection expressed using
Software Identifiers. This list might represent a complete inventory
or a targeted list of records, depending on the parameters in which case there |
| | are no instances the SW-
PV's request. A SW-PV MUST NOT send this attribute. The SW-PC
either sends this attribute in fulfillment of an existing
subscription where the Tag Creator Length, Tag | establishing request has a Result Type of 1
and the Earliest EID is zero, or in direct response to a SW Request
attribute where the Result Type is 1 and the Earliest EID is zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Creator, Unique Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Length, and Unique Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data Model Type| Software IdentifierLength |SW ID fields. In this case, the SWID-PV is | (var len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record ID Length | indicating an interest in all SWID tags on the Record ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Software Identifier Inventory Attribute

Table 5: SWID Request Attribute Fields

Table 6: Software Identifier Inventory Attribute Fields

In the indicated information. Note case that between the Result Type flag
and the Earliest EID field, the SWID-PC this attribute is constrained to sent in fulfillment of a single
possible SWID Response
subscription, the Subscription Fulfillment bit MUST be set (1). In
the case that this attribute type (or a PA-TNC Error attribute) is sent in its direct response to a SW
Request, the request.

The Subscribe and Clear Subscription flags are used to manage
subscriptions for the requesting SWID-PV on Fulfillment bit MUST be unset (0). Note
that the receiving SWID-PC.
Specifically, an SW Response attribute with the Subscribe flag set seeks sent in direct response to
establish a new SW
Request that establishes a subscription by the requesting SWID-PV (i.e., a subscription's
establishing request) MUST be treated as a direct response to that SW
Request (and thus the given
SWID-PC, while an attribute with the Clear Subscription flag seeks to
delete all existing subscriptions by the requesting SWID-PV on the
given SWID-PC. Note that, in the latter case, Fulfillment bit is unset). SW
Response attributes are only the subscriptions
associated with the Connection ID and, if available, the Posture
Validator ID of the requester are deleted treated as described being in
Section 3.8.3. A newly established fulfillment of a
subscription has the parameters
outlined (i.e., Subscription Fulfillment bit set) if they are
sent following a change event, as shown in the Request attribute. Specifically, the Result Type
flag Figure 3.

The Software Identifier Count field indicates the type number of result Software
Identifiers present in this inventory. Each Software Identifier is
represented by a set of five fields: Data Model Type, Software
Identifier Length, SW ID, Record ID Length, and Record ID. These
fields will appear once for each reported record.

When responding directly to send a SW Request attribute, the Request ID
Copy / Subscription ID field MUST contain an exact copy of the
Request ID field from that SW Request. When this attribute is sent
in fulfillment of an existing subscription on this Posture Collector,
then this field MUST contain the
subscription, the value Subscription ID of the Earliest fulfilled
subscription.

The EID Epoch field indicates whether the fulfillment attributes list inventories or events, and EID Epoch of the fields
describing tag identifiers (if present) indicate if Last EID value.
The Last EID field MUST contain the EID of the last recorded change
event (see Section 3.5 for more about EIDs and how a
subscription is targeted. recorded events) at
the time this inventory was collected. In the case that where there are
no recorded change events at the SWID-PC is unable or
unwilling time that this inventory was
collected, this field MUST contain 0. These fields can be
interpreted to comply with indicate that the SWID-PV's request to establish provided inventory (be it full or clear
subscriptions, the SWID-PC MUST respond with a PA-TNC Error attribute
with
targeted) reflects the SWID_SUBSCRIPTION_DENIED_ERROR error code. (Note that if record of events on the SWID-PV requests that subscriptions be cleared but has no
existing subscriptions, endpoint after all
changes up to and including this last event have been accounted for.

4.11. Software Identifier Events

A SW-PC sends this is not an error.)

An attribute requesting the establishment of a subscription is
effectively doing double-duty, as it is to a request for an immediate
response from the SWID-PC in addition SW-PV to setting up convey events where the subscription.
affected records are expressed using Software Identifiers. A SWID-PC SW-PV
MUST NOT send an appropriate response attribute to a request
with the Subscribe flag set containing all requested information. this attribute. The same is true of the Clear Subscription flag - the SWID-PC MUST
generate a response attribute without regard to the presence of SW-PC either sends this
flag attribute
in addition to clearing its fulfillment of an existing subscription list.

Both the Subscribe and Clear Subscription flags MAY be set in a
single SWID Request attribute. In the case where this request is
successful, the end result MUST be equivalent to the SWID-PC clearing
its subscription list for the given SWID-PV first and then creating a
new subscription in accordance with the establishing
request parameters. (In
other words, do not first create the new subscription has a Result Type is 1 and then clear
all the subscriptions including the one that was just created.) In
the case that the requested actions are successfully completed, the
SWID-PC MUST respond with Earliest EID is non-zero, or
in direct response to a SWID Response attribute. (The specific
type of SWID Response SW Request attribute depends on where the Result Type is
1 and the Earliest EID fields, as described above.) is non-zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Data Model Type| Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SW ID (var len)| Record ID Length |Record ID (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Software Identifier Events Attribute

+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case where there is
a failure that prevents some part this request from completing, the
SWID-PC MUST NOT add attribute is sent in |
| - | fulfillment of a new subscription, MUST NOT clear the old
subscriptions, and the SWID-PC subscription this bit MUST respond with a PA-TNC Error
attribute. be set |
| Subscription | (1). In other words, the SWID-PC MUST NOT partially succeed at
implementing such a request; either both actions succeed, or neither
succeed.

The Earliest EID field case that this attribute is used a direct |
| Fulfillment | response to indicate whether the SWID-PV is
requesting an inventory or event list from the SWID-PC. A value of 0
(0x00000000) represents a request SW Request, this bit MUST be unset |
| | (0). |
| | |
| Flags: Bit | Reserved for inventory information.
Otherwise, the SWID-PV is requesting event information. For Earliest
EID values other than 0, the SWID-PC's response future use. This field MUST respond with
event records, as described in Section 3.6. Note that the request
does not identify a particular EID Epoch, since responses can only
include events in the SWID-PC's current EID Epoch.

The Tag ID be set to |
| 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | |
| | |
| Event Count indicates the | The number of tag identifiers events that are reported in the this |
| | attribute. This number might be any value between 0 and 16,777,216,
inclusive. A single tag identifier field is represented by four fields:
Tag Creator Length, Tag Creator, Unique a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Data Model |
| | Type, Software Identifier Length, SW ID, Record ID |
| | Length, and
Unique Software ID. The two length Record ID fields are used to indicate repeated, in |
| | order, the number of bytes allocated to their corresponding string times indicated in this |
| | field. The
two string fields, Tag Creator and Unique Software ID, contain copies (An instance of the SWID tag's Tag Creator RegID and Unique ID values,
respectively, converted and normalized these fields is referred to Network Unicode format, |
| | as
described an "event record" in Section 4.7. Note that there is no this attribute. Thus the |
| | Event Count field to indicate a
particular Instance ID. Thus, targeted requests request all
instances of indicates the indicated SWID tags. The presence number of one or more
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 event |
| | records.) This field value MAY be 0, in
Section 3.3.3) and MUST include all which case |
| | there are no instances of matching tags in its
response.

4.10. SWID Tag Identifier Inventory

A SWID-PC sends this attribute to a SWID-PV to convey a list of the
endpoint's SWID tags expressed using SWID tag identifier instances.
This list might represent a complete inventory or a targeted list of
tags, depending on the parameters in these fields. |
| | |
| Request ID | In the SWID-PV's request. A SWID-
PV MUST NOT send this attribute. The SWID-PC either sends case where this attribute in fulfillment of an existing subscription where the
establishing request has a Result Type of 1 and the Earliest EID is
zero, or in direct |
| Copy / | response to a SWID SW Request attribute where the
Result Type is 1 and from a SW-PV, |
| Subscription | this field MUST contain an exact copy of the Earliest EID is zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags
| Tag ID Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID Copy / Subscription ID field from that SW Request. In the |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ case where this attribute is sent in fulfillment | Last EID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Creator Length | Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length of an active subscription, this field MUST contain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length | Instance the Subscription ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: SWID Tag Identifier Inventory Attribute

+--------------+----------------------------------------------------+
| Field | Description of the subscription being |
+--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case that fulfilled by this attribute is sent in attribute. |
| - | fulfillment of a subscription this bit MUST be set |
| Subscription EID Epoch | (1). In The EID Epoch of the case that this attribute Last EID value. This field is a direct |
| Fulfillment | response to a SWID Request, this bit MUST be unset an unsigned 4-byte integer. |
| | (0). |
| Flags: Bit Last EID | Reserved for future use. This field MUST be set to The EID of the last event recorded by the SW-PC, |
| 1-7 - | zero on transmission and ignored upon reception. or 0 if the SW-PC has no recorded events. This |
| Reserved | field contains the EID of the SW-PC's last |
| Tag ID Count | The number of tag identifier instances that recorded change event (which might or might not be |
| | follow. This field is included as an unsigned integer. The Tag event record in this attribute). |
| | Creator Length, Tag Creator, Unique Software ID |
| Last | Length, Unique Software ID, Instance ID Length, The EID of the last event record that was |
| Consulted | and Instance ID fields are repeated, in order, consulted when generating the event record list |
| EID | number of times indicated included in this field. attribute. This is different from |
| | the Last EID field value MAY be 0, in which case there are no |
| | instances of these fields. |
| Request ID | In the case where if and only if this attribute is in direct |
| Copy / | response to a SWID Request attribute from is conveying a SWID- |
| Subscription | PV, this field MUST contain an exact copy partial list of the event |
| ID | Request ID field from that SWID Request. In the records. See Section 3.5.4 for more on partial |
| | case where this attribute is sent in fulfillment list of event records. |
| | of an active subscription, this field MUST contain |
| EID | the Subscription ID The EID of the subscription being event in this event record. |
| | fulfilled by this attribute. |
| EID Epoch Timestamp | The EID Epoch of timestamp associated with the Last EID value. This field is event in this |
| | an unsigned 4-byte integer. event record. This timestamps is the SW-PC's best |
| Last EID | The EID understanding of when the last given event recorded by the SWID-PC, occurred. |
| | or 0 if the SWID-PC has no recorded events. This Note that this timestamp might be an estimate. |
| | field is an unsigned 4-byte integer. The Timestamp date and time MUST be represented as |
| Tag Creator | A 2-byte unsigned integer indicating the length an RFC 3339 [5] compliant ASCII string in |
| Length | bytes of Coordinated Universal Time (UTC) time with the Tag Creator field. |
| Tag Creator | A string containing additional restrictions that the Tag Creator RegID value 'T' delimiter and |
| | from within a SWID tag. This field value the 'Z' suffix MUST be capitalized and fractional |
| | normalized to Network Unicode format, as described |
| | in Section 4.7. This string seconds (time-secfrac) MUST NOT be NULL |
| included. This | terminated.
| | Unique | A 2-byte unsigned integer indicating field conforms to the length in date-time ABNF production |
| Software ID | bytes from section 5.6 of RFC 3339 [RFC3339] with the Unique Software ID field. |
| Length | above restrictions. Leap seconds are permitted |
| Unique | A string containing the Unique ID value from and SW-PVs MUST support them. The Timestamp |
| Software ID | within a SWID tag. This field value string MUST NOT be NULL terminated or padded in |
| | normalized to Network Unicode format, as described any way. The length of this field is always 20 |
| | in Section 4.7. This string MUST NOT be NULL octets. |
| | terminated. |
| Instance ID Action | A 2-byte unsigned integer indicating the length The type of event that is recorded in this event |
| Length | bytes record. Possible values are: 1 = CREATION - the |
| | addition of a record to the Instance ID field. endpoint's Software |
| Instance ID | A string containing Inventory Evidence Collection; 2 = DELETION - the Instance ID |
| | removal of a given tag record from the endpoint's Software |
| | instance. The exact value of this field depends on Inventory Evidence Collection; 3 = ALTERATION - |
| | There was an alteration to a record within the party that provides this SWID tag. This field |
| | value MUST be normalized to Network Unicode endpoint's Software Inventory Evidence Collection. |
| | format, as described in Section 4.7. This string All other values are reserved for future use and |
| | MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+

Table 6: SWID Tag Identifier Inventory Attribute Fields used when sending attributes. In the |
| | case that this attribute is sent in fulfillment of where a
subscription, the Subscription Fulfillment bit MUST be set (1). In
the case SW-PV receives an event record that this attribute is sent in direct response to a SWID
Request, |
| | uses an action value other than the Subscription Fulfillment bit ones defined |
| | here, it MUST be unset (0). Note ignore that the SWID response attribute sent event record but SHOULD |
| | process other event records in direct response to a SWID
Request that establishes a subscription (i.e., a subscription's
establishing request) MUST be treated this attribute as a direct response to |
| | normal. |
| | |
| Data Model | A 1-byte unsigned integer containing an identifier |
| Type | number from the Software Data Model IANA table |
| | that
SWID Request (and thus identifies the Subscription Fulfillment bit is unset).
SWID Response attributes are only treated as being in fulfillment data model of
a subscription (i.e., Subscription Fulfillment bit set) if they are
sent following a change event, as shown in Figure 3.

The Tag ID Count field indicates the number of tag identifier
instances present reported |
| | record. |
| | |
| Software | A 2-byte unsigned integer indicating the length in this inventory. Each tag identifier instance is
represented by a set |
| Identifier | bytes of six fields: Tag Creator Length, Tag Creator,
Unique Software the SW ID Length, Unique Software ID, Instance field. |
| Length | |
| | |
| SW ID Length,
and Instance ID. These six fields, collectively referred to as | A string containing the
"Tag ID Fields", will appear once for each reported tag instance.
Note that an endpoint's SWID tag collection might contain multiple
instances of Software Identifier value |
| | from a single tag (i.e., multiple tag files with software inventory evidence record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
| | |
| Record ID | A 2-byte unsigned integer indicating the same tag
identifier value). When this occurs, length in |
| Length | bytes of the case where that tag is
reported, then Record ID field. |
| | |
| Record ID | A string containing the response MUST contain Record Identifier value |
| | from a set of Tag ID Fields for
each instance of that tag. (The tag might not software inventory evidence record. This |
| | field value MUST be reported if normalized to Network Unicode |
| | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+
Table 7: Software Identifier Events Attribute Fields

The first few fields in the
SWID-PV made a targeted request that does not match that tag's tag
identifier.) For example, if Software Identifier Events attribute
mirror those in the Software Identifier Inventory attribute. The
primary difference is that, instead of conveying an endpoint has three copies inventory using
Software Identifiers, the attribute conveys zero or more event
records, consisting of tag X, the EID, timestamp, action type, data model
type, Software Identifier, and Record Identifier of the SWID-PV requests a full inventory, then affected
software inventory evidence record.

With regard to the response Timestamp field, it is
required important to include three sets of Tag ID Fields corresponding to the
three instances of note that tag. Only the Instance ID fields are
different
clock skew between these three instances.

When responding directly to a SWID Request attribute, the Request ID
Copy / Subscription ID field MUST contain SW-PC and SW-PV as well as between different
SW-PCs within an exact copy enterprise might make correlation of the
Request ID field from that SWID Request. When this attribute is sent
in fulfillment timestamp
values difficult. This specification does not attempt to resolve
clock skew issues, although other mechanisms outside of an existing subscription on this Posture Collector,
then this field MUST contain the Subscription ID of the fulfilled
subscription.

The EID Epoch field indicates the EID Epoch of the Last EID value.
The Last EID field MUST contain
specification do exist to reduce the EID impact of clock skew and make
the last recorded change
event (see Section 3.6 for timestamp more about EIDs useful for such correlation. Instead, Software
Message and recorded events) at Attributes for PA-TNC uses Timestamp value primarily as a
means to indicate the amount of time this inventory was collected. In the case where there are
no recorded change between two events at on a single
endpoint. For example, by taking the time that this inventory difference of the times for
when a record was
collected, this field MUST contain 0. These fields removed and then subsequently re-added, one can be
interpreted get
an indication as to indicate that how long the provided inventory (be it full or
targeted) reflects system was without the given record
(and, thus without the associated software). Since this will involve
comparison of events timestamp values all originating on the endpoint after all
changes up to same system,
clock skew between the SW-PC and including this last event have been accounted for.

4.11. SWID Tag Identifier Events

A SWID-PC sends this attribute to SW-PV is not an issue. However, if
the SW-PC's clock was adjusted between two recorded events, it is
possible for such a SWID-PV calculation to convey events where lead to incorrect understandings
of the affected SWID tags are expressed using SWID tag identifier
instances. A SWID-PV MUST NOT send this attribute. The SWID-PC
either sends temporal distance between events. Users of this attribute in fulfillment field need to
be aware of an existing
subscription the possibility for such occurrences. In the case where
the establishing request Timestamp values of two events appear to contradict the EID
ordering of those events (i.e., the later EID has a Result Type is 1
and an earlier
timestamp) the recipient MUST treat the Earliest EID is non-zero, or ordering as correct.

All event records in direct response to a SWID
Request attribute where Software Identifier Events Attribute are
required to be part of the Result Type is 1 and same EID Epoch. Specifically, all
reported events MUST have an EID from the Earliest same EID Epoch as each
other, and which is
non-zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| the same as the EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| of the Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| and
Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| values. The SW-PC MUST NOT report events with
EIDs from different EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Tag Creator Length |Tag Creator (v)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length | Instance ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: SWID Tag Identifier Events Attribute

The Last Consulted EID field contains the case that EID of the last event
record considered for inclusion in this attribute. If this attribute is sent in |
| - | fulfillment of
contains a subscription this bit MUST be partial event set |
| Subscription | (1). In the case (as described in Section 3.5.4) this
field value will differ from that of the Last EID field; if this
attribute is a direct |
| Fulfillment | response to contains a SWID Request, this bit MUST be unset |
| | (0). |
| Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission complete event set, the Last EID and ignored upon reception. |
| Reserved | |
| Event Count | The number of Last
Consulted EID values are identical.

If multiple events that are reported sent in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Action, Tag Creator |
| | Length, Tag Creator, Unique Software ID Length, |
| | Unique Software ID, Instance ID Length, and |
| | Instance ID fields are repeated, Identifier Events
attribute, the order in order, which they appear within the attribute is not
significant. The EIDs associated with them are used for ordering the |
| | number of times
indicated events appropriately. Also note that a single Software
Identifier might appear multiple times in an attribute, such as if
multiple events involving the associated record were being reported.

4.12. Software Inventory

A SW-PC sends this field. (An |
| | instance attribute to a SW-PV to convey a list of these nine fields inventory
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 had a Result Type of 0 and the Earliest EID
is referred zero, or in direct response to as an a SW Request attribute where the
Result Type is 0 and the Earliest EID is zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "event record" in this attribute. Thus the Event Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch | Count field indicates the number of event
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data Model Type| Record ID Length |Record ID (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| records.) This field value MAY be 0, in which case Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (Variable) | there are no instances of these fields.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Software Inventory Attribute

+--------------+----------------------------------------------------+
| Field | Description | Request ID
+--------------+----------------------------------------------------+
| Flags: Bit 0 | In the case where that this attribute is sent in |
| - | fulfillment of a subscription this bit MUST be set |
| Subscription | (1). In the case that this attribute is a direct |
| Fulfillment | response to a SW Request, this bit MUST be unset |
| | (0). |
| | |
| Flags: Bit | Reserved for future use. This field MUST be set to |
| 1-7 - | zero on transmission and ignored upon reception. |
| Reserved | |
| | |
| Record Count | The number of records that follow. This field is a |
| | 3-byte unsigned integer. The Data Model Type, |
| | Record Identifier Length, Record ID, Record |
| | Length, and Record fields are repeated, in order, |
| | 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 |
| Copy / | response to a SWID SW Request attribute from a SWID- SW-PV, |
| Subscription | PV, this field MUST contain an exact copy of the |
| ID | Request ID field from that SWID SW Request. In the |
| | case where this attribute is sent in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription being |
| | fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field is |
| | an unsigned 4-byte integer. |
| | |
| Last EID | The EID of the last event recorded by the SWID-PC, SW-PC, |
| | or 0 if the SWID-PC SW-PC has no recorded events. This |
| | field contains the EID of the SWID-PC's last is an unsigned 4-byte integer. |
| | recorded change event (which might or might not be |
| Data Model | included as A 1-byte unsigned integer containing an event record in this attribute). identifier |
| Last Type | The EID of number from the last event record that was Software Data Model IANA table |
| Consulted | consulted when generating that identifies the event record list data model of the reported |
| EID | included in this attribute. This is different from |
| | the Last EID field value if and only if this |
| | attribute is conveying a partial list of event |
| | records. See Section 3.6.4 for more on partial record. |
| | list of event records. |
| EID Record ID | The EID of A 2-byte unsigned integer indicating the event length in this event record. |
| Timestamp Length | The timestamp associated with bytes of the event in this Record ID field. |
| | event record. This timestamps is the SWID-PC's |
| Record ID | best understanding of when A string containing the given event Record Identifier value |
| | occurred. Note that this timestamp might be an from a software inventory evidence record. This |
| | estimate. The Timestamp date and time field value MUST be normalized to Network Unicode |
| | represented format, as an RFC 3339 [5] compliant ASCII |
| | string described in Coordinated Universal Time (UTC) time |
| | with the additional restrictions that the 'T' Section 4.7. This string |
| | delimiter and the 'Z' suffix MUST NOT be capitalized NULL terminated. |
| | and fractional seconds (time-secfrac) MUST NOT be |
| Record Len | included. This field conforms to is a 4-byte unsigned integer indicating the date-time |
| | ABNF production from section 5.6 length of RFC 3339 the following software inventory |
| | [RFC3339] with the above restrictions. Leap evidence record in bytes. |
| | seconds are permitted and SWID-PVs MUST support |
| Record | A software inventory evidence record as a string. |
| | them. The Timestamp string record MUST NOT be NULL converted and normalized to |
| | terminated or padded Network Unicode format, as described in any way. The length of Section |
| | this field is always 20 octets. |
| Action 4.7. This string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+

Table 8: Software Inventory Attribute Fields

The type Software Inventory attribute contains some number of event software
inventory evidence records. Given that is recorded in this event |
| | record. Possible values are: 1 = CREATION - the |
| | addition size of a tag to the endpoint's SWID tag |
| | collection; 2 = DELETION - records can vary
considerably, the removal length of this attribute is highly variable and, if
transmitting a tag |
| | from the endpoint's SWID tag collection; 3 = |
| | ALTERATION - There was an alteration complete inventory, can be extremely large.
Enterprises might wish to a tag file |
| | within constrain the endpoint's tag collection. All other |
| | values are reserved for future use and MUST NOT be |
| | used when sending attributes. In of Software Inventory
attributes to targeted requests to avoid over-burdening the case where network
unnecessarily.

When copying a |
| | SWID-PV receives an event software inventory evidence record that uses an |
| | action value other than into the Record
field, the ones defined here, it |
| | MUST ignore that event record but SHOULD process |
| | other event records MUST be converted and normalized to use Network
Unicode format prior to its inclusion in the record field.

4.13. Software Events

A SW-PC sends this attribute as normal. |
| Tag Creator | A 2-byte unsigned integer indicating the length in |
| Length | bytes of the Tag Creator field to a SW-PV to convey a list of events
where the tag affected |
| | by the described event. |
| Tag Creator | software inventory evidence records are expressed
using full records. A string containing SW-PV MUST NOT send this attribute. The SW-PC
either sends this attribute in fulfillment of an existing
subscription where the Tag Creator RegID value |
| | from within establishing request has a Result Type of 0
and the SWID tag affected by Earliest EID is non-zero, or in direct response to a SW
Request attribute where the described |
| | event. Result Type is 0 and the Earliest EID is
non-zero.

Note that each record is reported along with its Record Identifier.
This field value MUST can be normalized used to link reported records to reported Software
Identifier + Record Identifier pairs.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count | Network Unicode format, as described in Section
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4.7. This string MUST NOT be NULL terminated. EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Last EID | A 2-byte unsigned integer indicating the length in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID | Software ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bytes of the Unique Software ID field of the tag EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Timestamp | affected by the described event.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | Unique
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A string containing the Unique ID value from Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software ID Timestamp | within the SWID tag affected by the described
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event. This field value MUST be normalized to Action |Data Model Type| Record ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier (Variable Length) | Network Unicode format, as described in Section
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4.7. This string MUST NOT be NULL terminated. Record (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Software Events Attribute

+--------------+----------------------------------------------------+
| Instance ID Field | A 2-byte unsigned integer indicating Description |
+--------------+----------------------------------------------------+
| Flags: Bit 0 | In the length case that this attribute is sent in |
| Length - | bytes fulfillment of the Instance ID field. a subscription this bit MUST be set |
| Instance ID Subscription | A string containing (1). In the Instance ID of case that this attribute is a given tag direct |
| Fulfillment | instance. The exact value of response to a SW Request, this field depends on bit MUST be unset |
| | the party that provides this SWID tag. This field (0). |
| | value |
| Flags: Bit | Reserved for future use. This field MUST be normalized set to Network Unicode |
| 1-7 - | format, as described zero on transmission and ignored upon reception. |
| Reserved | |
| | |
| Event Count | The number of events being reported in Section 4.7. this |
| | attribute. This string field is a 3-byte unsigned |
| | MUST NOT be NULL terminated. integer. The EID, Timestamp, Action, Data Model |
+--------------+----------------------------------------------------+

Table 7: SWID Tag
| | Type, Record Identifier Events Attribute Fields

The first few Length, Record Identifier, |
| | Record Length, and Record fields are repeated, in |
| | order, the SWID Tag Identifier Events attribute
mirror those number of times indicated in the SWID Tag Identifier Inventory attribute. The
primary difference is that, instead this |
| | field. (An instance of conveying these fields is referred to |
| | as an inventory using
tag identifier instances, the attribute conveys zero or more event
records, including "event record" in this attribute. Thus the EID, timestamp, action type, and tag
identifier instance of |
| | Event Count field indicates the affected tag.

With regard to number of event |
| | records.) This field value MAY be 0, in which case |
| | there are no instances of these fields. |
| | |
| Request ID | In the Timestamp field, it case where this attribute is important in direct |
| Copy / | response to note that
clock skew between the SWID-PC and SWID-PV as well as between
different SWID-PCs within a SW Request attribute from a SW-PV, |
| Subscription | this field MUST contain an enterprise might make correlation exact copy of
timestamp values difficult. This specification does not attempt to
resolve clock skew issues, although other mechanisms outside the |
| ID | Request ID field from that SW Request. In the |
| | case where this attribute is sent in fulfillment |
| | of an active subscription, this
specification do exist to reduce field MUST contain |
| | the impact Subscription ID of clock skew and make
the timestamp more useful for such correlation. Instead, SWID
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
endpoint. For example, subscription being |
| | fulfilled by taking the difference this attribute. |
| | |
| EID Epoch | The EID Epoch of the times for
when a SWID tag was removed and then subsequently re-added, one can
get an indication as to how long the system was without the given tag
(and, thus without the associated software). Since this will involve
comparison Last EID value. This field is |
| | an unsigned 4-byte integer. |
| | |
| Last EID | The EID of timestamp values all originating on the same system,
clock skew between last event recorded by the SWID-PC and SWID-PV is not an issue. However, SW-PC, |
| | or 0 if the SWID-PC's clock was adjusted between two SW-PC has no recorded events, it
is possible for such a calculation to lead to incorrect
understandings of the temporal distance between events. Users of
this This |
| | field need to be aware of the possibility for such occurrences.
In the case where the Timestamp values of two events appear to
contradict contains the EID ordering of those events (i.e., the later EID has
an earlier timestamp) the recipient MUST treat the EID ordering SW-PC's last |
| | recorded change event (which might or might not be |
| | included as
correct.

All an event records record in a Tag Identifier Events Attribute are required
to be part this attribute). |
| | |
| Last | The EID of the same EID Epoch. Specifically, all reported events
MUST have an EID from last event record that was |
| Consulted | consulted when generating the same event record list |
| EID Epoch as each other, and which | included in this attribute. This is
the same as the EID Epoch of different from |
| | the Last EID field value if and Last Consulted EID
values. The SWID-PC MUST NOT report events with EIDs from different
EID Epochs.

The Last Consulted EID field contains the EID of the last event
record considered for inclusion in this attribute. If only if this |
| | attribute
contains is conveying a partial list of event set (as described in |
| | records. See Section 3.6.4) this
field value will differ from that 3.5.4 for more on partial |
| | list of the Last EID field; if this
attribute contains a complete event set, the Last records. |
| | |
| EID and Last
Consulted | The EID values are identical.

If multiple events are sent in a SWID Tag Identifier Events
attribute, of the order event in which they appear within the attribute is not
significant. this event record. |
| | |
| Timestamp | The EIDs timestamp associated with them are used for ordering the
indicated events appropriately. Also note that a single tag
identifier instance might appear multiple times event in an attribute, such
as if multiple events involving the associated tag were being
reported.

4.12. SWID Tag Inventory

A SWID-PC sends this attribute to a SWID-PV to convey a list |
| | event record. This timestamp is the SW-PC's best |
| | understanding of SWID
tags. A SWID-PV MUST NOT send this attribute. The SWID-PC either
sends when the given event occurred. |
| | Note that this attribute in fulfillment of timestamp might be an existing subscription where
the establishing request had a Result Type of 0 estimate. |
| | The Timestamp date and the Earliest EID
is zero, or time MUST be represented as |
| | an RFC 3339 [5] compliant ASCII string in direct response to a SWID Request attribute where the
Result Type is 0 and the Earliest EID is zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tag Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coordinated Universal Time (UTC) time with the | Instance ID Length
| Instance ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ additional restrictions that the 'T' delimiter and | Tag Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (Variable) the 'Z' suffix MUST be capitalized and fractional |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: SWID Tag Inventory Attribute

+--------------+----------------------------------------------------+
| Field | Description seconds (time-secfrac) MUST NOT be included. This |
+--------------+----------------------------------------------------+
| Flags: Bit 0 | In field conforms to the case that this attribute is sent in date-time ABNF production |
| - | fulfillment from section 5.6 of a subscription this bit MUST be set RFC 3339 [RFC3339] with the |
| Subscription | (1). In the case that this attribute is a direct above restrictions. Leap seconds are permitted |
| Fulfillment | response to a SWID Request, this bit and SW-PVs MUST be unset support them. The Timestamp |
| | (0). string MUST NOT be NULL terminated or padded in |
| Flags: Bit | Reserved for future use. This any way. The length of this field MUST be set to is always 20 |
| 1-7 - | zero on transmission and ignored upon reception. octets. |
| Reserved | |
| Tag ID Count Action | The number type of tags event that follow. This field is a |
| recorded in this event | 3-byte unsigned integer. The Instance ID Length,
| | | Instance ID, Tag Length, and Tag fields are |
| | repeated, in order, record. Possible values are: 1 = CREATION - the number of times indicated |
| | in this field. This field value MAY be 0 in which |
| | case there are no instances addition of these fields. a record to the endpoint's Software |
| Request ID | In Inventory Evidence Collection; 2 = DELETION - the case where this attribute is in direct |
| Copy / | response to removal of a SWID Request attribute record from a SWID- the endpoint's Software |
| Subscription | PV, this field MUST contain an exact copy of the Inventory Evidence Collection; 3 = ALTERATION - |
| ID | Request ID field from that SWID Request. In There was an alteration to a record within the |
| | case where this attribute is sent in fulfillment endpoint's Software Inventory Evidence Collection. |
| | of an active subscription, this field MUST contain All other values are reserved for future use and |
| | MUST NOT be used when sending attributes. In the Subscription ID of the subscription being |
| | fulfilled by this attribute. case where a SW-PV receives an event record that |
| EID Epoch | The EID Epoch of uses an action value other than the Last EID value. This field is ones defined |
| | an unsigned 4-byte integer. here, it MUST ignore that event record but SHOULD |
| Last EID | The EID of the last process other event recorded by the SWID-PC, records in this attribute as |
| | or 0 if the SWID-PC has no recorded events. This normal. |
| | field is an unsigned 4-byte integer. |
| Instance ID Data Model | A 2-byte 1-byte unsigned integer indicating the length in containing an identifier |
| Length Type | bytes of number from the Instance ID field. Software Data Model IANA table |
| | that identifies the data model of the reported |
| | record. |
| | | Instance
| Record ID | A string containing 2-byte unsigned integer indicating the Instance ID of a given tag length in |
| Length | instance. The exact value bytes of this field depends on the Record ID field. |
| | |
| Record ID | A string containing the party that provides this SWID tag. Record Identifier value |
| | from a software inventory evidence record. This field |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
| Tag | |
| Record Len | This is a 4-byte unsigned integer indicating the |
| | length of the following SWID tag record in bytes. |
| Tag | |
| Record | A SWID tag software inventory evidence record as a string. In the case where the |
| | original SWID tag is not expressed using UTF-8 |
| | encoding, it The record MUST be converted and normalized to |
| | Network Unicode format, as described in Section |
| | 4.7. However, in the case where the original SWID |
| | 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 9: Software Events Attribute Fields

The SWID Tag Inventory attribute contains some number of SWID tags.
Given that the size of tags can vary considerably, the length fields of this attribute is highly variable and, if transmitting a complete
inventory, can be extremely large. Enterprises might wish to
constrain are used in the use of SWID Tag Inventory attributes to targeted
requests to avoid over-burdening same way as the network unnecessarily.

Note that
corresponding fields of the Instance ID is included in this attribute along previous attributes. As with the tag. This is because, unlike the Tag Creator RegID and Unique ID
fields that make up the tag identifier, the Instance ID cannot always
Software Inventory attribute, a Software Events attribute can be extracted from fields within
quite large if many events have occurred following the event
indicated by a SWID tag. request's Earliest EID. As such, in order to be
able to associate a tag file with a given tag identifier instance, it is necessary to include recommended
that the Instance ID value SW Request attributes only request full records be sent
(Result Type set to 0) in the attribute.

When copying a SWID tag into targeted request, thus constraining the Tag field, conversion and
normalization
response just to records that match a given set of Software
Identifiers.

As with the character encoding happens if and Software Identifier Events Attribute, this attribute MUST
only if contain event records with EIDs coming from the
source SWID tag does not use UTF-8 encoding. In current EID
Epoch of the case where SW-PC.

As with the
source SWID tag is expressed using an encoding other than UTF-8, then
that tag Software Inventory Attribute, the SW-PC MUST be converted perform
conversion and normalized normalization of the record.

4.14. Subscription Status Request

A SW-PV sends this attribute to use Network Unicode
format prior a SW-PC to its inclusion in the tag field. However, in the case
where request a list of active
subscriptions for which the source SWID tag requesting SW-PV is expressed in UTF-8, the source tag subscriber. A
SW-PC MUST
be copied to the Tag field without conversion or normalization. NOT send this attribute.

This
is true even attribute has no fields.

A SW-PC MUST respond to this attribute by sending a Subscription
Status Response attribute (or a PA-TNC Error attribute 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 it is likely to break any
cryptographic signatures included in the SWID tag. As such,
conversion only happens
unable to ensure correctly provide 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 response).

4.15. Subscription Status Response

A SWID-PC SW-PC sends this attribute to a SWID-PV SW-PV to convey a report the list of
events where active
subscriptions for which the affected SWID tags are expressed using full tags. receiving SW-PV is the subscriber. A
SWID-PV SW-
PV MUST NOT send this attribute. The SWID-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 SWID Request attribute where the
Result Type is 0 and the Earliest EID is non-zero.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Event Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags | EID Epoch Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Software Identifier Length | Timestamp Software ID (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Subscription Status Response Attribute

+-----------------+-------------------------------------------------+
| Timestamp Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description | Timestamp
+-----------------+-------------------------------------------------+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: Bit 0-7 | Timestamp Reserved for future use. This field MUST be set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp - Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to zero on transmission and ignored upon | Action
| Instance ID Length |Instance ID (v)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Len reception. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: SWID Tag Events Attribute

Table 10: Subscription Status Response Fields

A Subscription Status Response contains the EID of the SWID-PC's last |
| | recorded change event (which might zero or might not be |
| | included as an event more subscription
records. Specifically, it MUST contain one subscription record in this attribute). |
| Last | The EID of for
each active subscription associated with the last event record party that was |
| Consulted | consulted when generating the event record list |
| EID | included in this attribute. This is different from |
| | sent the Last EID field value if and only if
Subscription Status Request to which this |
| | attribute is conveying a partial list of event |
| | records. See response.
As described in Section 3.6.4 for more on partial |
| | list of event records. |
| EID | The EID of 3.6.2, the event in this event record. |
| Timestamp | The timestamp SW-PC MUST use the requester's
Connection ID and its Posture Validator ID to determine which
subscriptions are associated with the event requester.

A SW-PC MUST send a Subscription Status Response attribute in
response to a Subscription Status Request attribute. The only
exception to this |
| | event record. This timestamps is if the SWID-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as SW-PC experiences an RFC 3339 [5] compliant ASCII |
| | string in Coordinated Universal Time (UTC) time |
| | with the additional restrictions error condition that
prevents it from correctly populating the 'T' |
| | delimiter and the 'Z' suffix MUST be capitalized |
| | and fractional seconds (time-secfrac) Subscription Status
Response attribute, in which case it MUST NOT be |
| | included. This field conforms respond with a PA-TNC Error
attribute appropriate to the date-time |
| | ABNF production from section 5.6 type of RFC 3339 |
| | [RFC3339] error experienced. If there are
no active subscriptions associated with the above restrictions. Leap |
| | seconds are permitted and SWID-PVs MUST support |
| | them. The Timestamp string MUST NOT be NULL |
| | terminated or padded in any way. The length requesting party, the
Subscription Status Response attribute will consist of |
| | this its Status
Flags field, a Subscription Record Count field is always 20 octets. |
| Action | The type with a value of event that is recorded 0, and
no additional fields.

Each subscription record included in this event |
| | record. Possible values are: 1 = CREATION - a Subscription Status Response
attribute duplicates the |
| | addition fields of a tag to SW Request attribute that was
the endpoint's SWID tag |
| | collection; 2 = DELETION - the removal establishing request of a tag |
| | from the endpoint's SWID tag collection; 3 = |
| | ALTERATION - There was an alteration to a tag file |
| | within subscription. Note that the endpoint's tag collection. All other |
| | values are reserved for future use and MUST NOT be |
| | used when sending attributes. In Request ID
field in the case where a |
| | SWID-PV receives an event record that uses an |
| | action value other than captures the ones defined here, it |
| | MUST ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| Instance Subscription ID | A 2-byte unsigned integer indicating associated with the length in |
| Length | bytes of
given subscription record (since the Instance ID field. |
| Instance Subscription ID | A string containing is the same as
the Instance Request ID of a given tag |
| | instance. The exact value of this field depends on |
| | the party establishing request). Note also that provides this SWID tag. This if the
establishing request is targeted, then its Record Count field |
| | value MUST will be normalized to Network Unicode |
| | format, as described
non-zero and, within that subscription record, the Record Namespace
Length, Record Namespace, Record ID Length, and Record ID fields are
repeated, in Section 4.7. This string |
| | MUST NOT be NULL terminated. |
| Tag Len | This is a 4-byte unsigned integer indicating order, the |
| | length number of the following SWID tag times indicated in bytes. |
| Tag | A SWID tag as a string. In the case where Record Count
field. As such, each subscription record can be different sizes. If
the |
| | original SWID tag establishing request is not expressed using UTF-8 |
| | encoding, it MUST be converted and normalized to |
| | Network Unicode format, as described in Section |
| | 4.7. However, in the case where the original SWID |
| | tag targeted (Record Count field is expressed using UTF-8 encoding, 0),
the SWID |
| | tag MUST be copied to this field without |
| | modification, even if subscription record has no Record Namespace Length, Record
Namespace, Record ID Length, or Record ID fields.

When a SW-PV compares the original SWID tag does |
| | not conform fully information received in a Subscription
Status Response to Network Unicode format. This |
| | string MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+

Table 9: SWID Tag Events Attribute Fields

The fields its own records of active subscriptions it should
be aware that the SW-PC might be unable to distinguish this attribute are used in SW-PV
from other SW-PVs on the same way as the
corresponding fields of the previous attributes. NEA Server. As with the SWID
Tag Inventory attribute, a SWID Tag Events attribute can be quite
large if many events have occurred following the event indicated by a
request's Earliest EID. As such, result, it is recommended
possible that the SWID
Request attributes only request full tags be sent (Result Type set to
0) in a targeted request, thus constraining SW-PC will report more subscription records than
the response just to tags SW-PV recognizes. For this reason, SW-PVs SHOULD NOT
automatically assume that match extra subscriptions reported in a given set of tag identifiers.

As with the SWID Tag Identifier Events Attribute, this
Subscription Status Response indicate a problem.

4.16. PA-TNC Error as Used by Software Message and Attributes for PA-
TNC

The PA-TNC Error attribute MUST
only contain event records with EIDs coming from the current EID
Epoch of the SWID-PC.

As with the SWID Tag Inventory Attribute, is defined in the SWID-PC MUST perform
conversion PA-TNC specification
[RFC5792], and normalization of the SWID tag itself its use here conforms to that specification. A PA-TNC
Error can be sent due to any error in the case where
the source SWID tag is expressed using an encoding other than UTF-8, PA-TNC exchange and MUST NOT perform conversion or normalization of the SWID tag
itself might
also be sent in response to error conditions specific to the Software
Message and Attributes for PA-TNC exchange. The latter case where the source SWID tag is expressed using UTF-
8.

4.14. Subscription Status Request utilizes
error codes defined below.

A SWID-PV sends this PA-TNC Error attribute to is sent instead of a SWID-PC SW Response attribute
due to request a list of
active subscriptions for which the requesting SWID-PV is factors that prevent the
subscriber. A SWID-PC reliable creation of a SW Response.
As such, a SW-PC MUST NOT send this attribute.

This attribute has no fields.

A SWID-PC MUST respond to this attribute by sending a Subscription
Status Response attribute (or both a PA-TNC Error attribute if it is
unable to correctly provide and a response).

4.15. Subscription Status SW
Response

A SWID-PC sends this attribute in response to a SWID-P to report single SW Request attribute.

Table 11 lists the list of
active subscriptions Error Code values for which the receiving SWID-PV is PA-TNC Error attribute
specific to the
subscriber. A SWID-PV Software Message and Attributes for PA-TNC exchange.
In all of these cases, the Error Code Vendor ID field MUST NOT send be set to
0x000000, corresponding to the IETF SMI Private Enterprise Number.
The Error Information structures for each error type are described in
the following subsections.

Note that a message with a Software Message and Attributes for PA-TNC
attribute might also result in an error condition covered by the
Standard PA-TNC Error Codes defined in PA-TNC. For example, a SW
Attribute might have an invalid parameter, leading to an error code
of "Invalid Parameter". In this attribute.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count case, the SW-PC MUST use the
appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
PA-TNC specification.

+-----------------------+-------------------------------------------+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Value | Flags Description | Tag ID Count
+-----------------------+-------------------------------------------+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x00000020 | Request ID SW_ERROR. This indicates a fatal error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (i.e., an error that precludes the | Tag Creator Length
| Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ creation of a suitable response | Unique Software ID Length |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Subscription Status Response Attribute

+------------------+------------------------------------------------+
| Field | Description attribute) other than the errors |
+------------------+------------------------------------------------+
| Flags: Bit 0-7 - | Reserved for future use. This field MUST be described below but still specific to the |
| Reserved | set to zero on transmission and ignored upon processing of SW Attributes. The |
| | reception. Description field SHOULD contain |
| Subscription | The number of subscription records that additional diagnostic information. |
| Record Count | follow. |
| 0x00000021 | SW_SUBSCRIPTION_DENIED_ERROR. This field is |
| | indicates that the SW-PC denied the SW- |
| | PV's request to establish a 3-byte unsigned subscription. |
| | integer. The Flags, Tag ID Count, Request ID, Description field SHOULD contain |
| | Earliest EID, Tag Creator Length, Tag Creator, additional diagnostic information. |
| | Unique Software ID Length, and Unique Software |
| 0x00000022 | ID fields are repeated, in order, the number SW_RESPONSE_TOO_LARGE_ERROR. This |
| | of times indicated in this field. This field indicates that the SW-PC's response to |
| | value MAY the SW-PV's request was too large to be 0 in which case there are no |
| | instances of these fields. serviced. The error information structure |
| Flags, Tag ID | For each active subscription, these fields indicates the largest possible size of a |
| Count, Request | contain an exact copy of the fields with response supported by the SW-PC (see |
| ID, Earliest | same name as provided in the subscription's Section 4.16.2). The Description field |
| EID, Tag Creator | establishing request. SHOULD contain additional diagnostic |
| Length, Tag | information. |
| Creator, Unique | |
| Software ID 0x00000023 | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | Length, and indicates that the SW-PC experienced an |
| | Unique Software error fulfilling a given subscription. |
| | ID The error information includes the |
| |
+------------------+------------------------------------------------+

Table 10: Subscription Status Response Fields

A Subscription Status Response contains zero or more subscription
records. Specifically, it MUST contain one subscription record for
each active subscription associated with ID of the party relevant |
| | subscription, as well as a sub-error that sent |
| | describes the
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
Connection ID and, if available, its Posture Validator ID to
determine which subscriptions are associated with the requester.

A SWID-PC MUST send a Subscription Status Response attribute in
response to a Subscription Status Request attribute. The only
exception to this is if nature of the SWID-PC experiences an error condition
that prevents it from correctly populating the Subscription Status
Response attribute, in which case it MUST respond with a PA-TNC Error
attribute appropriate to the type of error SW- |
| | PC experienced. If there are
no active subscriptions associated with the requesting party, the
Subscription Status Response attribute will consist of its Status
Flags field, a Subscription Record Count field with a value of 0, The SW-PC and
no additional fields.

Each subscription record included in a Subscription Status Response
attribute duplicates SW-PV MUST |
| | treat the fields of a SWID Request attribute identified subscription as |
| | cancelled. |
| | |
| 0x00000024 | SW_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | indicates that was the establishing request of SW-PC received a subscription. Note that the SW |
| | Request ID
field in the record captures the Subscription ID associated with the from a given subscription record (since SW-PV where the Subscription |
| | Request ID of that SW Request is the same |
| | currently used as the Request Subscription ID of the establishing request). Note also |
| | an active subscription with that if SW-PV. |
| | This error does not cancel the
establishing request is targeted, then its Tag ID Count field will be
non-zero and, within that subscription record, identified |
| | subscription. |
| | |
| 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved |
| | for use by future revisions of the Tag Creator
Length, Tag Creator, Unique |
| | Software ID Length, Message and Unique Attributes for PA- |
| | TNC specification. Any PA-TNC Error |
| | attribute using one of these Error Codes |
| | MUST be treated as indicating a fatal |
| | error on the sender without further |
| | interpretation. |
+-----------------------+-------------------------------------------+

Table 11: PA-TNC Error Codes for Software
ID fields are repeated, in order, Message and Attributes for
PA-TNC

The following subsections describe the number of times indicated structures present in the Tag ID Count field. As such, each subscription record can be
different sizes. Likewise, if
Error Information fields.

4.16.1. SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
SW_SUBSCRIPTION_ID_REUSE_ERROR Information

The SW_ERROR error code indicates that the establishing request sender (the SW-PC) has
encountered an error related to the processing of a SW Request
attribute but which is not
targeted (Tag ID Count field covered by more specific SW error codes.
The SW_SUBSCRIPTION_DENIED_ERROR is 0), used when the SW-PV requests to
establish a subscription record has no
Tag Creator Length, Tag Creator, Unique Software ID Length, or Unique
Software ID fields.

When a SWID-PV compares the information received in a Subscription
Status Response to its own records of active clear all subscriptions it should
be aware that from the SWID-PC might be given
SW-PV, but the SW-PC is unable or unwilling to distinguish comply with this SWID-PV
from other SWID-PVs on the same NEA Server. As a result, it
request. The SW_SUBSCRIPTION_ID_REUSE_ERROR is
possible that used when the SWID-PC will report more subscription records than
the SWID-PV recognizes. For this reason, SWID-PVs SHOULD NOT
automatically assume that extra subscriptions reported in SW-PC
receives a
Subscription Status Response indicate SW Request whose Request ID duplicates a problem.

4.16. PA-TNC Error as Used by SWID Message and Attributes for PA-TNC

The PA-TNC Error attribute is defined in Subscription ID
of an active subscription with the PA-TNC specification
[RFC5792], and its use here conforms to that specification. A PA-TNC
Error can be sent due to any request's sender. All of these
error in codes use the PA-TNC exchange and might
also be sent in response to following error conditions specific to the SWID
Message information structure.

Figure 13: SW Error, Subscription Error, and Attributes for PA-TNC exchange. The latter Subscription ID Reuse
Information

A PA-TNC Error attribute condition is sent instead of a SWID Response attribute
due to factors that prevent the reliable creation of a SWID Response.
As such, a SWID-PC MUST NOT send both a PA-TNC Error attribute and a
SWID Response attribute generated |
| Request ID / | in direct response to a single SWID SW Request
attribute.

Table 11 lists attribute, this |
| Subscription | field MUST contain an exact copy of the Error Code values for the PA-TNC Error attribute
specific to the SWID Message and Attributes for PA-TNC exchange. In
all of these cases, the Error Code Vendor Request ID |
| ID | field MUST be set to
0x000000, corresponding to the IETF SMI Private Enterprise Number.
The Error Information structures for each error type are described in the following subsections.

Note that a message with a SWID Message and Attributes for PA-TNC SW Request attribute might also result in an error condition covered by the
Standard PA-TNC Error Codes defined in PA-TNC. For example, the SWID
Attribute might have an invalid parameter, leading to an error code
of "Invalid Parameter". In that caused this case, the SWID-PC MUST use the
appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
PA-TNC specification.

+-----------------------+-------------------------------------------+
| Error Code Value | Description |
+-----------------------+-------------------------------------------+
| 0x00000020 | SWID_ERROR. This indicates a fatal error |
| | (i.e., an error error. In the case that precludes the attribute in question |
| | creation is generated in fulfillment of a suitable response |
| | attribute) other than the errors an active |
| | described below but still specific to subscription, this field MUST contain the |
| | processing Subscription ID of SWID Attributes. The the subscription for which the |
| | Description field SHOULD contain attribute was generated. (This is only possible |
| | additional diagnostic information. if the error code is SW_ERROR as the other errors |
| 0x00000021 | SWID_SUBSCRIPTION_DENIED_ERROR. This are not generated by subscription fulfillment.) |
| | indicates that the SWID-PC denied Note that, in this case, the indicated error |
| | SWID-PV's request to establish appears as a sub-error for a |
| | subscription. The Description field SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in |
| | SHOULD contain additional diagnostic Section 4.16.3. |
| | information. |
| 0x00000022 | SWID_RESPONSE_TOO_LARGE_ERROR. This |
| Description | indicates that A UTF-8 string describing the SWID-PC's response to condition that |
| | the SWID-PV's request was too large to caused this error. This field MAY be 0-length. |
| | serviced. The error information structure However, senders SHOULD include some description |
| | indicates the largest possible size in all PA-TNC Error attributes of a |
| these types. | response supported by the SWID-PC (see
| | This field MUST NOT be NULL terminated. | Section 4.16.2).
+--------------+----------------------------------------------------+

Table 12: SW Error, Subscription Error, and Subscription ID Reuse
Information Fields

This error information structure is used with SW_ERROR,
SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR
status codes to identify the SW Request attribute that precipitated
the error condition and to describe the error. The Description field
contains text describing the error. The SW-PC MAY encode machine-
interpretable information in this field, but SHOULD also include a
human-readable description of the error, since the receiving SW-PV
might not recognize the SW-PC's encoded information.

4.16.2. SW_RESPONSE_TOO_LARGE_ERROR Information

The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response
generated by a SW-PC in response to a SW-PV's SW Request attribute
was too large to send.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription I |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHOULD contain additional diagnostic | Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information. Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: SW Response Too Large Error Information

+--------------+----------------------------------------------------+
| 0x00000023 Field | SWID_SUBSCRIPTION_FULFILLMENT_ERROR. This Description |
+--------------+----------------------------------------------------+
| Copy of | indicates In the case that the SWID-PC experienced an | attribute in question is |
| error fulfilling a given subscription. |
| | The error information includes the Request ID / | generated in direct response to a SW Request, this |
| Subscription ID | field MUST contain an exact copy of the relevant Request ID |
| ID | subscription, as well as a sub-error field in the SW Request attribute that caused this |
| | describes the nature of error. In the error case that the attribute in question |
| | SWID-PC experienced. The SWID-PC and is generated in fulfillment of an active |
| | SWID-PV subscription, this field MUST treat contain the identified |
| | Subscription ID of the subscription as cancelled. for which the |
| 0x00000024 | SWID_SUBSCRIPTION_ID_REUSE_ERROR. This attribute was generated. Note that, in the latter |
| | indicates that case, the SWID-PC received SW_RESPONSE_TOO_LARGE_ERROR appears as a |
| | SWID Request from sub-error for a given SWID-PV where SW_SUBSCRIPTION_FULFILLMENT_ERROR, |
| | the Request ID of that SWID Request is as described in Section 4.16.3. |
| | currently used as the Subscription ID of |
| Maximum | This field MUST contain an active subscription with that SWID-PV. unsigned integer |
| Allowed Size | This error does not cancel indicating the identified largest permissible size, in bytes, |
| | subscription. of SW Attribute that the SW-PC is currently |
| 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved willing to send in response to a SW Request |
| | for use by future revisions of the SWID attribute. |
| | Message and Attributes for PA-TNC |
| Description | specification. Any PA-TNC Error attribute A UTF-8 string describing the condition that |
| | using one of these Error Codes MUST caused this error. This field MAY be 0-length. |
| | treated as indicating a fatal error on However, senders SHOULD include some description |
| | the sender without further in all PA-TNC Error attributes of these types. |
| | interpretation. This field MUST NOT be NULL terminated. |
+-----------------------+-------------------------------------------+
+--------------+----------------------------------------------------+

Table 11: PA-TNC Error Codes for SWID Message and Attributes for PA-
TNC

The following subsections describe the structures present in the 13: SW Response Too Large Error Information fields.

4.16.1. SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR and
SWID_SUBSCRIPTION_ID_REUSE_ERROR Information

The SWID_ERROR Fields

This error code indicates that structure is used with the sender (the SWID-PC) has
encountered an error related SW_RESPONSE_TOO_LARGE_ERROR
status code to identify the processing of a SWID SW Request attribute but which is not covered by more specific SWID that precipitated
the error codes. condition and to describe the error. The SWID_SUBSCRIPTION_DENIED_ERROR is used when Maximum Allowed
Size field indicates the SWID-PV requests largest attribute the SW-PC is willing to
send in response to establish a subscription or clear all subscriptions from SW Request under the given
SWID-PV, but current circumstances.
Note that under other circumstances, the SWID-PC is unable SW-PC might be willing to
return larger or unwilling smaller responses than indicated (such as if the
endpoint connects to comply with the NEA Server using a different network
protocol). The other fields in this
request. error information structure have
the same meanings as corresponding fields in the SW_ERROR and
SW_SUBSCRIPTION_DENIED_ERROR information structure.

4.16.3. SW_SUBSCRIPTION_FULFILLMENT_ERROR Information

The SWID_SUBSCRIPTION_ID_REUSE_ERROR is used when SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the SWID-
PC receives
SW-PC encountered an error while fulfilling a SWID Request whose Request ID duplicates subscription. The
bytes after the first 4 octets duplicate a Subscription
ID PA-TNC Error attribute (as
described in Section 4.2.8 of an active subscription with PA-TNC) that is used to identify the request's sender. All
nature of these
error codes use the following error information structure. encountered error.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) Reserved | Sub Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: SWID Error, Subscription Error, and 15: SW Subscription ID Reuse Fulfillment Error Information

+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of Subscription | In This field MUST contain the Subscription ID of the case that this error condition is generated |
| Request ID / | in direct response to a SWID Request attribute, subscription whose fulfillment caused this error. |
| Subscription | this |
| Reserved | This field MUST contain an exact copy the value of the Reserved |
| ID | Request ID field in the SWID Request of a PA-TNC Error attribute that describes |
| | that caused this error. In the case that the error condition encountered during |
| | attribute in question is generated in fulfillment subscription processing. |
| | of an active subscription, this field MUST contain |
| Sub Error | This field MUST contain the Subscription ID value of the subscription for which Error |
| Code Vendor | the Code Vendor ID field of a PA-TNC Error attribute was generated. (This is only |
| ID | possible if that describes the error code is SWID_ERROR as the condition encountered |
| | other errors are not generated by during subscription processing. |
| | fulfillment.) Note that, in this case, |
| Sub Error | This field MUST contain the value of the Error |
| Code | indicated error appears as a sub-error for Code field of a PA-TNC Error attribute that |
| | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described describes the error condition encountered during |
| | in Section 4.16.3. subscription processing. |
| Description | A UTF-8 string describing the condition that |
| Sub Error | caused this error. This field MAY be 0-length. MUST contain the value of the Error |
| Information | However, senders SHOULD include some description Information field of a PA-TNC Error attribute that |
| | in all PA-TNC Error attributes of these types. describes the error condition encountered during |
| | This field MUST NOT be NULL terminated. subscription processing. |
+--------------+----------------------------------------------------+

Table 12: SWID Error, Subscription Error, and 14: SW Subscription ID Reuse Fulfillment Error Information Fields

This error information structure is used with SWID_ERROR,
SWID_SUBSCRIPTION_DENIED_ERROR, and SWID_SUBSCRIPTION_ID_REUSE_ERROR the
SW_SUBSCRIPTION_FULFILLMENT_ERROR status codes to identify code. The first 4 octets of
this error structure contain the SWID Request attribute Subscription ID of the subscription
that precipitated was being fulfilled when the error condition and to describe the error. The Description field
contains text describing the error. occurred. The SWID-PC MAY encode machine-
interpretable information in remaining
fields of this field, but SHOULD also include error structure duplicate the fields of a
human-readable description PA-TNC Error
attribute, referred to as the "sub-error". The error code of the error, since
sub-error corresponds to the receiving SWID-PV
might not recognize type of error that the SWID-PC's encoded information.

4.16.2. SWID_RESPONSE_TOO_LARGE_ERROR Information SW-PC encountered
while fulfilling the given subscription. The SWID_RESPONSE_TOO_LARGE_ERROR sub-error MUST NOT have
an error code indicates that a
response generated by a SWID-PC in response to a SWID-PV's SWID
Request attribute was too large to send.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription I |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: SWID Response Too Large SW_SUBSCRIPTION_FULFILLMENT_ERROR.

The SW-PC sending a PA-TNC Error Information

5. Supported Data Models

Software Message and Attributes for PA-TNC supports an active subscription, this field MUST contain |
| | the Subscription ID extensible
list of the subscription data models for which |
| | the attribute was generated. Note that, in this |
| | case, the SWID_RESPONSE_TOO_LARGE_ERROR representing and transmitting software
inventory information. This list of data models appears as |
| | a sub-error for a |
| | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in the
Software Data Model IANA table (see Section 4.16.3. |
| Maximum | 9.4). This field MUST contain document
provides guidance for an unsigned integer |
| Allowed Size | indicating initial set of data models. Other documents
might provide guidance on the largest permissible size, in bytes, |
| | 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 Attribute that Tags using XML

The International Organization for Standardization and the SWID-PC is currently |
| | willing to send
International Electrotechnical Commission (ISO/IEC) published the
specification governing SWID tag construction and use in response to 2009 with a
revised version published in 2015. [SWID] Since that time, a growing
number of vendors have integrated SWID Request |
| | attribute. |
| Description | A UTF-8 string describing tags into their software
products. Doing so significantly simplifies the condition that |
| | caused this error. This field MAY be 0-length. |
| | However, senders SHOULD include some description |
| | in all PA-TNC Error attributes task of identifying
these types. |
| | This field MUST NOT be NULL terminated. |
+--------------+----------------------------------------------------+

Table 13: SWID Response Too Large Error Information Fields

This error structure is used with the SWID_RESPONSE_TOO_LARGE_ERROR
status code pieces of software: instead of relying on discovery processes
that look for clues as to identify software presence, such as the presence of
particular files or registry keys, a readily available list of SWID Request attribute that precipitated
the error condition
tags provides simple and immediate evidence as to describe the error. The Maximum Allowed
Size field indicates presence of the largest attribute
given piece of software.

SWID Message and Attributes for PA-TNC has no reliance on the SWID-PC is willing to
send in response to a
presence or management of SWID Request under tags on an endpoint as described in
the current circumstances.

Note ISO specification. However, the data model for describing
software that under other circumstances, is presented in the SWID-PC might be willing to
return larger responses than indicated (such ISO specification provides a robust
and comprehensive way of describing software and is adopted here as if a
means of representing and transmitting software information. It
should be emphasized, the endpoint
connects use of the ISO SWID tag data model makes no
assumption as to whether the NEA Server using a different network protocol). The
other fields in this error information structure have source of the same
meanings as corresponding fields recorded information was,
in fact, an ISO SWID tag harvested from the endpoint or whether the SWID_ERROR and
SWID_SUBSCRIPTION_DENIED_ERROR
information structure.

4.16.3. SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information

The SWID_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the
SWID-PC encountered an error while fulfilling a subscription. The
bytes after was created using some other source and normalized to the first 4 octets duplicate a PA-TNC Error attribute (as
described in Section 4.2.8 of PA-TNC) that is used
SWID format.

5.1.1. Guidance on Normalizing Source Data to identify ISO 2015 SWID Tags using
XML

TBD

Don't violate the
nature of specification

Use your own Tag Creator RegID or the encountered error.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 15: SWID Subscription Fulfillment Error Information

+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Subscription | This field MUST contain Unknown Tag Creator RegID. Do
not use some other party's RegID, especially not the Subscription ID RegID of the |
| ID | subscription whose fulfillment caused this error. |
| Reserved | This field MUST contain
software author if you are not the value 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 Reserved |
| | field length of TAG_CREATOR_REGID in bytes. The rest
of a PA-TNC Error attribute that describes |
| | the error condition encountered during |
| | subscription processing. |
| Sub Error | This field Software Identifier MUST contain be the value concatination of the Error |
| Code Vendor | Code Vendor ID field of a PA-TNC Error attribute |
| ID | that describes the error condition encountered |
| | during subscription processing. |
| Sub Error | This field MUST contain Tag
Creator RegID and the value of Unique ID from the Error |
| Code | Code field of 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 PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
| Sub Error | This field MUST contain the value useful data
model for representation of the Error |
| Information | Information field software information. As of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
+--------------+----------------------------------------------------+

Table 14: SWID Subscription Fulfillment Error Information Fields

This error structure is used with the
SWID_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets writing
of this error structure contain the Subscription ID of specification, while the
subscription that was being fulfilled when 2015 specification is considered
more comprehensive and addresses some issues with the error occurred. The
remaining fields of 2009
specification, 2009-format SWID tags remain far more common in
deployments. For this error structure duplicate reason, ISO 2009 SWID tags are included in the fields of a
PA-TNC Error attribute, referred
Software Data Model IANA table.

5.2.1. Guidance on Normalizing Source Data to as ISO 2015 SWID Tags using
XML

TBD

Don't violate the "sub-error". The error
code of specification

Use your own Tag Creator RegID or the sub-error corresponds to Unknown Tag Creator RegID. Do
not use some other party's RegID, especially not the type RegID of error that the SWID-
PC encountered while fulfilling
software author if you are not the given subscription. The sub-
error MUST NOT have an error code author.

5.2.2. Guidance on Creation of
SWID_SUBSCRIPTION_FULFILLMENT_ERROR.

The SWID-PC sending a PA-TNC Error attribute with this error code, 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 SWID-PV receiving it, length of TAG_CREATOR_REGID in bytes. The rest
of the Software Identifier MUST treat be the subscription identified
by concatination of the Subscription Tag
Creator RegID and the Unique ID field as cancelled. All other subscriptions
are unaffected.

5. from the tag, without any connecting
character or whitespace.

6. Security Considerations

This section discusses some of the security threats facing Posture
Collectors and Posture Validators that implement the SWID Software Message
and Attributes for PA-TNC protocol. This section primarily notes
potential issues for implementers to consider, although it does
contain a handful of normative requirements to address certain
security issues. Implementers need to make the final decision as to
how their implementations address the given issues. The issues
identified below focus on capabilities specific to this document.
Implementers are advised to consult other relevant NEA specifications
for security issues that are applicable to such components in
general.

Reading the Security Considerations section of any well-written
specification can be discouraging, as a long list of possible threats
is catalogued. Keep in mind that no security measure is absolute,
but each one can be beneficial. By understanding the weaknesses of
each security measure, we can put in place countermeasures to protect
against exploitation of these weaknesses.

5.1.

6.1. Evidentiary Value of SWID Tags

A SWID tag is only indirect evidence as to Software Inventory Evidence Records

It must be remembered that the installation of a
piece accuracy of software on an endpoint. While the ideal is for the
presence of a tag to correspond to the presence endpoints Software
Inventory Evidence Collection as an indicator of the corresponding
software, such a correlation hinges on software that accurately
manages individual tags as endpoints
software load and changes thereon is added only as accurate as the tools
that populate and removed.
Utilization of manage the tests included in a tag's package_footprint and/or
validation elements can provide more direct evidence of software
presence, but inventory evidence records in
this information collection. Some tools might not be present designed to update records
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 Software Inventory Evidence Collection in ensuring real time resulting
in a collection 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 out-of-step with actual system state.
Moreover, tools might inaccurately characterize software, or fail to
properly record its removal. Finally, it is likely that there will necessarily
be protected software on the endpoint that is not tracked by signatures. For these reasons, it any source and
thus is important to treat SWID tags as evidence rather than proof not reflected in the Software Inventory Evidence Collection.
Users of collected software presence.

5.2. Integrity of inventory evidence records need to
understand that the SWID Tag Collection

On a related note, while some systems might protect SWID tags against
modification, on others there might information provided by the Software Message and
Attributes for PA-TNC capability cannot be very few restrictions on who
can add or delete tags on an endpoint. This treated as completely
accurate. Nonetheless, having endpoints report this information can mean that a
malicious party has relatively free rein to add and remove tags with
still provide useful insights into the goal state of obscuring the actual endpoint's
software inventory load, and can alert administrators and policy tools of the endpoint.
As noted above, signatures
situations that require remediation.

6.2. Sensitivity of Collected Records

Software records on tag files can keep tag modification
from going undetected, but an attacker endpoint are generally not considered to be
sensitive, although there can simply delete the signed
tag and replace it with a modified tag that lacks be exceptions to this generalization as
noted in the associated
signature. section on Privacy Considerations. In fact, even a signed tag general, an
endpoint's Software Inventory Evidence Collection can be added by an adversary browsed and go undetected if
individual records read by any party with access to the tag does endpoint.
This is generally not include fields considered to verify
software presence, such be problematic, as the package_footprint or validation
element

There is little a SWID-PC can do to prevent unauthorized
modifications of the endpoint's SWID tag from occurring if the local
system does not provide protections for tags. Instead, the SWID-PV
and NEA Server need to operate with an awareness that this type of
modification can occur. The use of mechanisms to corroborate
software inventories can help detect malicious modification of an
endpoint's SWID tag collection. Likewise, the SWID-PV can look for
odd behavior such as the deletion and rapid re-installation of a
particular tag, especially the replacement of a signed tag with an
unsigned one. Parties that use SWID tags as evidence of compliance
with security policies need to be aware of the possible risks of
corruption of an endpoint's SWID tag collection.

5.3. Sensitivity of Collected Tags

Tags on an endpoint are generally not considered to be sensitive,
although there can be exceptions to this generalization as noted in
the section on Privacy Considerations. In general, an endpoint's
SWID tag collection can be browsed and individual tags read by any
party with access to the endpoint. This is generally not considered
to be problematic, as those with access to those with
access to the endpoint can usually learn of everything disclosed by
that endpoint's tags records simply by inspecting other parts of the
endpoint.

The situation changes when an endpoint's SWID tags inventory records are
collected and stored off of the endpoint itself, such as on a NEA
Server or CMDB.
Tags Inventory records represent a wealth of information
about the endpoint in question and, for an adversary who does not
already have access to the endpoint, a collection of the endpoint's tags
inventory records might provide many details that are useful for
mounting an attack. A list of the tags inventory records associated with
an endpoint reveals a list of software installed on the endpoint.
This list is can be very detailed, generally noting specific versions and even
patch levels, which an adversary can use to identify vulnerable
software and design efficacious attacks.

In addition, other information might also be gleaned from a
collection of SWID tags: software inventory records:

o A SWID tag An inventory record might include information about where the
product was installed on a given endpoint. This can reveal
details about the file organization of that endpoint that an
attacker can utilize.

o A SWID tag An inventory record might include information about how the
software was provided to the endpoint, who in an organization
signs off on the package release, and who packaged the product for
installation. This information might be used as a starting point
for the development of supply chain attacks.

o Events affecting SWID tags inventory records are reported with timestamps
indicating when each given event occurred. This can give the
attacker an indication of how quickly an organization distributes
patches and updates, helping the attacker determine how long an
attack window might remain open.

Any consolidated software inventory is a potential risk, because such
an inventory can provide an adversary an insight into the
enterprise's configuration and management process. It is recommended
that a centralized tag software inventory record collection be protected
against unauthorized access. Mechanisms to accomplish this can
include encrypting the data at rest, ensuring that access to the data
is limited only to necessary individuals and processes, and other
basic security precautions.

5.4.

6.3. Integrity of Endpoint Records

SWID-PCs

SW-PCs maintain records of detected changes to the endpoint's SWID
tag collection.
Software Inventory Evidence Collection. These records are used to
respond to a SWID-PV's SW-PV's request for change events. The SWID-PV SW-PV might use
a list of reported events to update its understanding of the
endpoint's SWID tag
collection Software Inventory Evidence Collection without needing to
receive a full inventory report from the SWID-PC. SW-PC. For this reason,
preserving the integrity of the SWID-
PC's SW-PC's record of events is extremely
important. If an attacker modifies the SWID-PC's SW-PC's record of changes to
the endpoint's SWID tag
collection, Software Inventory Evidence Collection, this might
cause the SWID-PV's SW-PV's understanding of the endpoint's SWID tag collection Software Inventory
Evidence Collection to differ from its actual state. Results might
include leading the SWID-PV SW-PV to believe that absent software was
present, that present software was absent, that patches have been
installed even if this is not the case, or to be unaware of other
changes to SWID tags. Software Inventory Evidence Records. As such, the SWID-PC SW-PC
MUST take steps to protect the integrity of its event record. records.

In addition, sometimes a SWID-PC captures metadata about existing
tags or even creates copies of whole tags. Metadata might include
hash values of tag files or records of the last time a particular tag
file was modified, while whole tags might be preserved to record tags
that were deleted from the endpoint's SWID tag collection. If an
attacker is able to corrupt or modify this information, they might
cause a SWID-PC to fail to detect certain change events, incorrectly
report information, or otherwise fail to correctly fulfill SWID-PV
requests. As such, this additional information about SWID tags, if
collected, MUST be integrity protected.

Finally, records of established SWID-PV SW-PV subscriptions also require
protection against manipulation or corruption. If an attacker is
able to modify or delete records of an established subscription by a
SWID-PV,
SW-PV, the SWID-PC SW-PC might fail to correctly fulfill this subscription.
The SWID-PV SW-PV would not be aware that its subscription was not being
correctly fulfilled unless it received additional information that
indicated a discrepancy. For example, the SWID-PV SW-PV might collect a full
inventory and realize from this that certain events had not been
correctly reported in accordance with an established subscription.
For this reason, the SWID-PC SW-PC MUST protect the integrity of subscription
records.

5.5. SWID-PC

6.4. SW-PC Access Permissions

A SWID-PC SW-PC requires sufficient permissions to locate and read SWID
tags on the endpoint that constitute the endpoint's SWID tag
collection, and collect Software Inventory
Evidence Records from all of its supported sources, as well as
sufficient permissions to interact with the endpoint's Posture Broker
Client. With regard to the former, this might require permissions to
read the contents of directories throughout the file system.
Depending on the operating environment and other activities
undertaken by a SWID-PC SW-PC (or software that incorporates a SWID-PC SW-PC as one
of its capabilities) additional permissions might be required by the SWID-PC
SW-PC software. The SWID-PC SW-PC SHOULD NOT be granted permissions beyond
what it needs in order to fulfill its duties.

5.6.

6.5. Sanitization of Tag Record Fields

In most cases there is no constraint on an endpoint as to who can add
tags. This open model allows applications that run in user space to
register tags as easily as more privileged applications. However,
this also means

Not all sources of software inventory evidence are necessarily
tightly controlled. For example, consider a source that any tool reading an gathers
.swid files from the endpoint's tags needs to
treat these tags as un-vetted input file system. Any party could create
a new .swid file that could be collected and employ appropriate
safeguards. turned into a Software
Inventory Evidence Record. As a result, it is important that the
contents of source information not be automatically trusted. In
particular, tools that read SWID tags, source information and the Software
Inventory Evidence Records derived therefrom, including
SWID-PCs, SW-PCs, need
to be careful to sanitize input to prevent buffer overflow attacks,
encoding attacks, and other weaknesses that might be exploited by an
adversary who can control the contents of a tag.

Fields of a SWID tag that change the SWID-PC's behavior, alter system
state, or execute code need to be handled with special care. record.

6.6. PA-TNC Security Threats

In
particular, addition to the validation element, which provides a command line
that can nominally be executed to validate the tag's correctness, can
be utilized by an attacker to point to a malicious executable. To
defend against this, SWID-PCs MUST NOT execute an application
indicated by a validation element unless the element is signed and
the SWID-PC has determined that aforementioned considerations the signature is intact Software Message
and trusted.

5.7. Tag Library Poisoning

It can be useful Attributes for a SWID-PV to have access PA-TNC protocol is subject to a library of tags.
If the SWID-PV receives a list same security
threats as other PA-TNC transactions, as noted in Section 5.2 of tag identifier instances, it can
consult this library PA-
TNC [RFC5792]. These include, but are not limited to, attribute
theft, message fabrication, attribute modification, attribute replay,
attribute insertion, and collect full tags corresponding denial of service. Implementers are advised
to those
identifiers. Assuming it does not need access consult the PA-TNC specification to installation-
specific information, it can perform calculations on better understand these full tags
as
security issues.

7. Privacy Considerations

As noted in Section 6.2, if it had received them from a SWID-PC. For example, it an adversary can use gain an understanding of
the software installed on an endpoint, they can utilize this library to derive software names, publishers,
launch attacks and version by
finding maintain footholds on this endpoint. For this
reason, the tag that corresponds NEA Server needs to the given tag identifier value.

If the SWID-PV keeps a collection of full SWID tags for matching
against tag identifiers, there might be a temptation ensure adequate safeguards are in
place to add any
previously unknown tags prevent exposure of collected inventory records. For
similar reasons, it is advisable that an endpoint only send records
to a SWID-PC might report NEA Server that is authorized to receive this library
automatically. In fact, this behavior information and
that can pose a security risk. If
the endpoint has been compromised and the tag manipulated on that
endpoint, the tag that it provides to the SWID-PV might be misleading
with regard trusted to the software associated with this tag. If the SWID-PV
automatically adds safeguard this corrupted tag information after collection.

8. Relationship to its library, not only will
the computations with the compromised endpoint be affected, but
computations with other endpoints that provide tag identifier
instances that map Other Specifications

This specification makes frequent reference to the corrupted tag will also be affected.
Instead, if the SWID-PV does make and use of other
specifications. This section describes these relationships.

This specification is expected to participate in a tag library, standard NEA
architecture. As such, it is
recommended expected to only populate that library be used in conjunction with tags retrieved from a
trusted source, or at least to segregate collections of reported tags
by endpoint, so corrupted tags on one endpoint will not affect tag
computations involving
the other endpoints. In general, tags retrieved
from a trusted source and signed by a trusted authority are likely be
safe for inclusion protocols used in a tag library.

5.8. PA-TNC Security Threats NEA exchange. In addition to the aforementioned considerations the SWID Message and particular, SW
Attributes for PA-TNC protocol are conveyed over PB-TNC [RFC5793], which is subject to the same security
threats as other PA-TNC transactions, as noted in Section 5.2 turn
conveyed over some variant of PA-
TNC [RFC5792]. PT (either PT-TLS [RFC6876] or PT-EAP
[RFC7171]). These include, but protocols have an especially important role, as
they are not limited to, attribute
theft, message fabrication, attribute modification, attribute replay,
attribute insertion, and denial of service. Implementers responsible for ensuring that attributes defined under this
specification are advised delivered reliably, securely, and to consult the PA-TNC specification to better understand these
security issues.

6. Privacy Considerations

As noted in Section 5.3, if an adversary can gain an understanding of
the software installed on an endpoint, they can utilize this to
launch attacks and maintain footholds on this endpoint. For this
reason, the NEA Server needs to ensure adequate safeguards are in
place to prevent exposure of collected tags. For similar reasons, it
is advisable that an endpoint only send tags to a NEA Server that is
authorized to receive this information and that can be trusted to
safeguard this information after collection.

7. Relationship to Other Specifications

This specification makes frequent reference to and use of other
specifications. This section describes these relationships.

This specification is expected to participate in a standard NEA
architecture. As such, it is expected to be used in conjunction with
the other protocols used in a NEA exchange. In particular, SWID
Attributes are conveyed over PB-TNC [RFC5793], which is in turn
conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP
[RFC7171]). These protocols have an especially important role, as
they are responsible for ensuring that attributes defined under this
specification are delivered reliably, securely, and to the
appropriate party.

It is important
appropriate party.

It is important to note that the Product Information, Numeric
Version, and String Version attributes defined in the PA-TNC
specification [RFC5792] are also meant to convey information about
installed applications and the versions thereof. As such, there is
some conceptual overlap between those attributes and the intent of
this specification. However, PA-TNC was designed to respond to very
specific queries about specific classes of products, while the SWID
Software Message and Attributes for PA-TNC specification is able to
convey a broader query, resulting in a more comprehensive set of
evidence regarding an endpoint's installed software. Moreover, because this
specification makes use of the well-defined structures in SWID tags,
it is able to convey information that is more concise (by making use
of specific identifier fields instead of sending the whole SWID tag)
and/or more comprehensive (as the SWID structures contain many more
fields than expressible in PA-TNC). As such, this
specification provides important capabilities not present in the PA-TNC PA-
TNC specification.

9. IANA Considerations

This section extends multiple existing IANA registries.
Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error
Codes defined in the PA-TNC specification [RFC5792] and the PA-
Subtypes registry defined in the PB-TNC specification [RFC5793] and
extended in PA-TNC. This specification only adds values to these
registries and does not alter how these registries work or are
maintained. Consult the appropriate specifications for details on
the operations and maintenance of these registries.

8.1.

9.1. Registry for PA-TNC Attribute Types

Section 4.6 of this specification defines several new PA-TNC
attributes. The following values are added to the registry for PA-
TNC Attribute Types defined in the PA-TNC specification. Note that
Table 4 in Section 4.6 lists these attributes but uses a hexadecimal
value to identify their associated integer. The integer values given
in that table are identical to those provided here. Note also that
Table 4 includes an entry for PA-TNC Error attributes, but the IANA
information associated with that attribute is already defined in the
PA-TNC specification and is not reproduced here.

+-----+---------+----------------------+----------------------------+

8.2.
+-----+---------+---------------------+-----------------------------+

9.2. Registry for PA-TNC Error Codes

Section 4.16 of this specification defines several new PA-TNC Error
Codes. The following values are added to the registry for PA-TNC
Error Codes defined in the PA-TNC specification. Note that Table 11
in Section 4.16 lists these attributes codes but uses a hexadecimal value to
identify their associated integer. The integer values given in that
table are identical to those provided here.

+----+---------+------------------------------------+---------------+

8.3.
+-----+---------+-----------------------------------+---------------+

9.3. Registry for PA Subtypes

Section 4.1 of this specification defines one new PA Subtype. The
following value is added to the registry for PA Subtypes defined in
the PB-TNC specification.

+-----+---------+----------------+----------------------------------+

+-----+---------+-------------+-------------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+----------------+----------------------------------+
+-----+---------+-------------+-------------------------------------+
| 0 | 9 | SWID SW | SWID Software Message and Attributes for |
| | | Attributes | PA-TNC |
+-----+---------+----------------+----------------------------------+

9.
+-----+---------+-------------+-------------------------------------+

9.4. Registry for Software Data Models

TBD

10. References
9.1.

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.

[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>.

[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>.

[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect
(TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010,
<http://www.rfc-editor.org/info/rfc5792>.

[SWID] The International Organization for Standardization/
International Electrotechnical Commission, "Information
Technology - Software Asset Management - Part 2: Software
Identification Tag, ISO/IEC 19770-2", November 2009.

9.2.

10.2. Informative References

[NIST-SWID]
The National Institute of Standards and Technology and The
MITRE Corporation, "Guidelines for the Creation of
Interoperable Software Identification (SWID) Tags", August
2013.

[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793,
March 2010, <http://www.rfc-editor.org/info/rfc5793>.

[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876,
DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>.

[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>.

Appendix A. Examples

This appendix includes examples of a SWID tag file and SWID
attributes. All examples represent fictional content. Examples are
provided using the 2009 release of the ISO/IEC SWID specification.

A.1. A Simple SWID Tag

Figure 16 shows an example SWID tag for a fictional software product
called SomeApp created by Vendor Inc. This example includes only the
required SWID tag fields. This tag is for version 2.3, build 12 of
the product.

1]<?xml version="1.0" encoding="UTF-8"?>
2]<swid:software_identification_tag
3] xmlns:swid="http://standards.iso.org/iso/19770/-2/2009/schema.xsd"
4] xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
5] <swid:entitlement_required_indicator>
6] true
7] </swid:entitlement_required_indicator>
8] <swid:product_title>SomeApp</swid:product_title>
9] <swid:product_version>
10] <swid:name>2.3 r12</swid:name>
11] <swid:numeric>
12] <swid:major>2</swid:major>
13] <swid:minor>3</swid:minor>
14] <swid:build>12</swid:build>
15] <swid:review>0</swid:review>
16] </swid:numeric>
17] </swid:product_version>
18] <swid:software_creator>
19] <swid:name>Vendor Inc.</swid:name>
20] <swid:regid>regid.2013-06.com.vendor</swid:regid>
21] </swid:software_creator>
22] <swid:software_licensor>
23] <swid:name>Vendor Inc.</swid:name>
24] <swid:regid>regid.2013-06.com.vendor</swid:regid>
25] </swid:software_licensor>
26] <swid:software_id>
27] <swid:unique_id>
28] someapp-21ec2020-3aea-1069-a2dd-08002b30309d
29] </swid:unique_id>
30] <swid:tag_creator_regid>
31] regid.2013-06.com.vendor
32] </swid:tag_creator_regid>
33] </swid:software_id>
34] <swid:tag_creator>
35] <swid:name>Vendor Inc.</swid:name>
36] <swid:regid>regid.2013-06.com.vendor</swid:regid>
37] </swid:tag_creator>
38]</swid:software_identification_tag>

Figure 16: A Simple SWID Tag

The SWID tag described in Figure 16 is limited to only the
information required by the SWID specification [SWID]. This
information includes the following:

o Lines 5-7: Entitlement requirement indicator. This indicates
whether some sort of entitlement (e.g., a license) is required in
order to install and/or use the software.

o Line 8: Prose name of the product

o Lines 9-17: Product version. This includes both a prose
expression of the full product version and the version information
broken down into distinct fields.

o Lines 18-21: Software creator identification. This identifies the
party that created the software. This includes both a prose name
of the software creator and their "regid" value.

o Lines 22-25: Software licensor identification. This identifies
the party that holds the rights to license others to use the
software.

o Lines 26-33: Software unique identifier. This structure contains
the regid for the party that created this tag and a value that
party uses to uniquely identify the named software product. The
SWID Message and Attributes for PA-TNC specification uses the
values of these fields when constructing a SWID tag identifier, as
described in Section 3.3.

o Lines 34-37: Tag creator identification. This identifies the
party that created the tag.

Assume the SWID tag file is installed on the file system in the
following location:

C:\ProgramData\Vendor\regid.2013-06.com.vendor_someapp-21ec2020-3aea-
1069.swidtag

A.2. SWID Request Attributes

Below are hexadecimal dumps of example SWID Request attributes. SWID
Request attributes are described in more detail in Section 4.7.

A.2.1. Simple Request

This is a basic SWID request for inventory information - the request
is not targeted nor does the request establish a subscription on the
endpoint. The SWID Request dictates that the response be expressed
using SWID tag identifier instances.

+-------------+-----------------------------------------------------+
| 20 00 00 00 | Clear Subscriptions = 0 (don't clear |
| | subscriptions), Subscribe = 0 (don't establish a |
| | new subscription), Result Type = 1 (respond using |
| | SWID tag identifier instances), Tag ID Count = 0 |
| | (non-targeted request) |
| ----------- | |
| 00 00 3a 76 | Request ID = 14966 |
| ----------- | |
| 00 00 00 00 | Earliest EID = 0 (respond with inventory rather |
| | than event records) |
+-------------+-----------------------------------------------------+

Note that this attribute does not contain any Tag Creator Length, Tag
Creator, Unique Software ID Length, or Unique Software ID fields
because the Tag ID Count field is 0.

A.2.2. Subscription Request for Events

This attribute establishes a request for a new subscription that will
report new SWID change events as they occur.

+-------------+-----------------------------------------------------+
| 60 00 00 00 | Clear Subscriptions = 0 (don't clear |
| | subscriptions), Subscribe = 1 (establish a new |
| | subscription), Result Type = 1 (respond using SWID |
| | tag identifier instances), Tag ID Count = 0 (non- |
| | targeted request) |
| ----------- | |
| 00 00 3a 76 | Request ID = 14967 |
| ----------- | |
| 00 02 cc 3a | Earliest EID = 183354 |
+-------------+-----------------------------------------------------+

As before, this attribute does not contain any Tag Creator Length,
Tag Creator, Unique Software ID Length, or Unique Software ID fields
because the Tag ID Count field is 0. The immediate response to this
message (assuming no errors are encountered) will be a list of events
with EIDs that are greater than or equal to 183354. Thereafter, if
any new events are recorded, those events (and only those events)
will be sent back to the SWID-PV in fulfillment of this subscription.
(See Section 3.8.2 for more on subscription fulfillment.)

A.2.3. Targeted Request

This example shows a targeted request. Specifically, the request
includes two SWID tag identifiers. The attribute requests that the
corresponding full SWID tags be returned.

+-----------------+-------------------------------------------------+
| 00 00 00 02 | Clear Subscriptions = 0 (don't clear |
| | subscriptions), Subscribe = 0 (don't establish |
| | a new subscription), Result Type = 0 (respond |
| | using full SWID tags), Tag ID Count = 2 |
| | (targeted request identifying two SWID tags) |
| ----------- | |
| 00 00 3a 76 | Request ID = 14968 |
| ----------- | |
| 00 00 00 00 | Earliest EID = 0 (respond with inventory rather |
| | than event records) |
| =========== | START TAG IDENTIFIER 1 |
| 00 18 | Tag Creator Length = 24 |
| ----------- | |
| 72 65 67 69 64 | Tag Creator = regid.2013-06.com.vendor |
| 2e 32 30 31 33 | |
| 2d 30 36 2e 63 | |
| 6f 6d 2e 76 65 | |
| 6e 64 6f 72 | |
| ----------- | |
| 00 2c | Unique Software ID Length = 44 |
| ----------- | |
| 73 6f 6d 65 61 | Unique Software ID = |
| 70 70 2d 32 31 | someapp-21ec2020-3aea-1069-a2dd-08002b30309d |
| 65 63 32 30 32 | |
| 30 2d 33 61 65 | |
| 61 2d 31 30 36 | |
| 39 2d 61 32 64 | |
| 64 2d 30 38 30 | |
| 30 32 62 33 30 | |
| 33 30 39 64 | |
| =========== | START TAG IDENTIFIER 2 |
| 00 18 | Tag Creator Length = 24 |
| ----------- | |
| 72 65 67 69 64 | Tag Creator = regid.2013-06.com.vendor |
| 2e 32 30 31 33 | |
| 2d 30 36 2e 63 | |
| 6f 6d 2e 76 65 | |
| 6e 64 6f 72 | |
| ----------- | |
| 00 2f | Unique Software ID Length = 47 |
| ----------- | |
| 61 6e 6f 74 68 | Unique Software ID = |
| 65 72 61 70 70 | anotherapp-23a52020-3aea-1069-a2dd-0800884d4e21 |
| 2d 32 33 61 35 | |
| 32 30 32 30 2d | |
| 33 61 65 61 2d | |
| 31 30 36 39 2d | |
| 61 32 64 64 2d | |
| 30 38 30 30 38 | |
| 38 34 64 34 65 | |
| 32 31 | |
+-----------------+-------------------------------------------------+

This message contains SWID tag identifiers for two SWID tags. The
first of these tags is the example SWID tag described in
Appendix A.1. The second tag is created by the same tag creator, but
indicates a different software product.

A.3. SWID Response Attributes

This section contains examples of SWID response attributes.

A.3.1. SWID Tag Identifier Events Attribute

This shows an example of a SWID Tag Identifier Events attribute. In
this case, this attribute is sent in fulfillment of an established
subscription rather than in direct response to a SWID Request
attribute. (This is indicated by setting the Subscription
Fulfillment flag.) The SWID Request attribute shown in
Appendix A.2.2 established this subscription (as indicated by the
Subscription ID field).

This response contains two event records.

+-------------------+-----------------------------------------------+
| 80 00 00 02 | Subscription Fulfillment = 1, Event Count = 2 |
| ----------- | |
| 00 00 3a 76 | Subscription ID = 14968 |
| ----------- | |
| 7e 82 1c aa | EID Epoch = 2122456234 |
| ----------- | |
| 00 02 cc 84 | Last EID = 183428 |
| ----------- | |
| 00 02 cc 84 | Last Consulted EID = 183428 (Same as Last EID |
| | so this is a complete result) |
| =========== | START EVENT RECORD 1 |
| 00 02 cc 83 | EID = 183427 |
| ----------- | |
| 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:16Z |
| 37 2d 32 31 54 30 | |
| 34 3a 33 32 3a 31 | |
| 36 5a | |
| ----------- | |
| 01 | Action = 1 (CREATION) |
| ----------- | |
| 00 18 | Tag Creator Length = 24 |
| ----------- | |
| 72 65 67 69 64 2e | Tag Creator = regid.2013-06.com.vendor |
| 32 30 31 33 2d 30 | |
| 36 2e 63 6f 6d 2e | |
| 76 65 6e 64 6f 72 | |
| ----------- | |
| 00 2c | Unique Software ID Length = 44 |
| ----------- | |
| 73 6f 6d 65 61 70 | Unique Software ID = |
| 70 2d 32 31 65 63 | someapp-21ec2020-3aea-1069-a2dd-08002b30309d |
| 32 30 32 30 2d 33 | |
| 61 65 61 2d 31 30 | |
| 36 39 2d 61 32 64 | |
| 64 2d 30 38 30 30 | |
| 32 62 33 30 33 30 | |
| 39 64 | |
| ----------- | |
| 00 51 | Instance ID Length = 81 |
| ----------- | |
| 43 3a 5c 50 72 6f | Instance ID = |
| 67 72 61 6d 44 61 | C:\ProgramData\Vendor\regid.2013-06. |
| 74 61 5c 56 65 6e | com.vendor_someapp-21ec2020-3aea-1069.swidtag |
| 64 6f 72 5c 72 65 | |
| 67 69 64 2e 32 30 | |
| 31 33 2d 30 36 2e | |
| 63 6f 6d 2e 76 65 | |
| 6e 64 6f 72 5f 73 | |
| 6f 6d 65 61 70 70 | |
| 2d 32 31 65 63 32 | |
| 30 32 30 2d 33 61 | |
| 65 61 2d 31 30 36 | |
| 39 2e 73 77 69 64 | |
| 74 61 67 | |
| ============ | START EVENT RECORD 2 |
| 00 02 cc 84 | EID = 183428 |
| ----------- | |
| 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:22Z |
| 37 2d 32 31 54 30 | |
| 34 3a 33 32 3a 32 | |
| 32 5a | |
| ----------- | |
| 02 | Action = 2 (DELETED) |
| ----------- | |
| 00 18 | Tag Creator Length = 24 |
| ----------- | |
| 72 65 67 69 64 2e | Tag Creator = regid.2009-08.com.company |
| 32 30 30 39 2d 30 | |
| 38 2e 63 6f 6d 2e | |
| 63 6f 6d 70 61 6e | |
| 79 | |
| ----------- | |
| 00 24 | Unique Software ID Length = 36 |
| ----------- | |
| 32 34 38 35 34 39 | Unique Software ID = |
| 37 35 2d 31 32 35 | 24854975-125e-ee3e-98ac-45684248eefa |
| 65 2d 65 65 33 65 | |
| 2d 39 38 61 63 2d | |
| 34 35 36 38 34 32 | |
| 34 38 65 65 66 61 | |
| ----------- | |
| 00 47 | Instance ID Length = 71 |
| ----------- | |
| 43 3a 5c 50 72 6f | Instance ID = C:\Program |
| 67 72 61 6d 20 46 | Files\Company\OurProduct\ |
| 69 6c 65 73 5c 43 | OurProduct_8749-84789200-02.swidtag |
| 6f 6d 70 61 6e 79 | |
| 5c 4f 75 72 50 72 | |
| 6f 64 75 63 74 5c | |
| 4f 75 72 50 72 6f | |
| 64 75 63 74 5f 38 | |
| 37 34 39 2d 38 34 | |
| 37 38 39 32 30 30 | |
| 2d 30 32 2e 73 77 | |
| 69 64 74 61 67 | |
+-------------------+-----------------------------------------------+

This response contains two event records. Note that their timestamps
indicate that they occurred a few seconds apart - some SWID-PCs might
choose to wait a brief time before sending messages in fulfillment of
subscriptions so as to send multiple event records in a single
attribute. The first event record indicates the creation of the SWID
tag shown in Appendix A.1. The second event record indicates the
deletion of a different SWID tag. Finally, note that since the Last
EID field is equal to the EID of one of the reported event records,
this indicates that the SWID-PC has no later recorded events.

A.3.2. SWID Tag Inventory Attribute

This shows an example of a SWID Tag Inventory attribute. In this
case, this attribute is being sent in direct response to a SWID
Request attribute, as indicated by the Subscription Fulfillment flag
being unset. (Specifically, it is being sent in response to the SWID
Request shown in Appendix A.2.3, as can be shown by comparing the
Request ID and Request ID Copy fields.) The result includes a single
tag entry.

+-----------------------+-------------------------------------------+
| 00 00 00 01 | Subscription Fulfillment = 0, Tag Count = |
| | 1 |
| ----------- | |
| 00 00 3a 76 | Request ID Copy = 14968 |
| ----------- | |
| 7e 82 1c aa | EID Epoch = 2122456234 |
| ----------- | |
| 00 02 cc 84 | Last EID = 183428 |
| =========== | BEGIN TAG ENTRY |
| 00 51 | Instance ID Length = 81 |
| ----------- | |
| 43 3a 5c 50 72 6f 67 | Instance ID = |
| 72 61 6d 44 61 74 61 | C:\ProgramData\Vendor\regid.2013-06.com. |
| 5c 56 65 6e 64 6f 72 | vendor_someapp-21ec2020-3aea-1069.swidtag |
| 5c 72 65 67 69 64 2e | |
| 32 30 31 33 2d 30 36 | |
| 2e 63 6f 6d 2e 76 65 | |
| 6e 64 6f 72 5f 73 6f | |
| 6d 65 61 70 70 2d 32 | |
| 31 65 63 32 30 32 30 | |
| 2d 33 61 65 61 2d 31 | |
| 30 36 39 2e 73 77 69 | |
| 64 74 61 67 | |
| ----------- | |
| 05 ac | Tag Length = 1452 |
| ----------- | |
| 3c 3f 78 6d 6c 20 76 | The Tag field is equal to the SWID tag |
| ... 69 6f 6e 5f 74 | shown in Figure 16. Note that since the |
| 61 67 3e | original tag used UTF-8 encoding, the tag |
| | is copied without undergoing any |
| | conversion or normalization. |
+-----------------------+-------------------------------------------+

This attribute contains a single SWID tag. As a response to the
targeted SWID Request in Appendix A.2.3, this indicates a single
instance of the first requested SWID tag and no instances of the
second requested tag were present in the endpoint's SWID tag
collection. Moreover, if the same party receives both this attribute
and the attribute in Appendix A.3.1, one can tell that there have
been no change events recorded since the preceding message, because
the EID Epoch and Last EID values are unchanged.

Authors' Addresses

Chris Coffin
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA

Email: ccoffin@mitre.org

Daniel Haynes
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA

Email: dhaynes@mitre.org

Charles Schmidt
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730
USA

Email: cmschmidt@mitre.org

Jessica Fitzgerald-McKay
Department of Defense
9800 Savage Road
Ft. Meade, Maryland
USA

Email: jmfitz2@nsa.gov