<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 09/27/22 -->

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 2.5.1) -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-sacm-coswid-22" number="9393" submissionType="IETF" category="std"
consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes=""
xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 2.46.0 -->
  <front>
    <title abbrev="CoSWID">Concise Software Identification Tags</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-coswid-22"/> name="RFC" value="9393"/>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzgerald-McKay">
      <organization>National Security Agency</organization>
      <address>
        <postal>
          <street>9800 Savage Road</street>
          <city>Ft. Meade</city>
          <code>20755</code>
          <region>Maryland</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jmfitz2@cyber.nsa.gov</email>
      </address>
    </author>
    <author initials="C." surname="Schmidt" fullname="Charles Schmidt">
      <organization>The MITRE Corporation</organization>
      <address>
        <postal>
          <street>202 Burlington Road</street>
          <city>Bedford</city>
          <region>Massachusetts</region>
          <code>01730</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>cmschmidt@mitre.org</email>
      </address>
    </author>
    <author initials="D." surname="Waltermire" fullname="David Waltermire">
      <organization abbrev="NIST">National Institute of Standards and Technology</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>Maryland</region>
          <code>20877</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>david.waltermire@nist.gov</email>
      </address>
    </author>
    <date year="2022" month="July" day="19"/>
    <area>Security</area>
    <workgroup>SACM Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2023" month="June"/>

    <area>sec</area>
    <workgroup>sacm</workgroup>

    <abstract>
      <t>ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of semantics and features as that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory efficient memory-efficient format.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>SWID tags, as defined in ISO-19770-2:2015 <xref target="SWID"/>, provide a standardized
XML-based record format that identifies and describes a specific release of
software, a patch, or an installation bundle, which are referred to as software components in this document. Different software components, and even different releases of a
particular software component, each have a different SWID tag record associated
with them. SWID tags are meant to be flexible and able to express a broad set of metadata
about a software component.</t>
      <t>SWID tags are used to support a number of processes processes, including but not limited to:</t>
      <ul spacing="normal">
        <li>Software Inventory Management, representing a part of a Software Asset Management process <xref target="SAM"/>
process, target="SAM"/>,
which requires an accurate list of discernible deployed software
components.</li>
        <li>Vulnerability Assessment, which requires a semantic link between standardized
vulnerability descriptions and software components installed on IT-assets IT assets <xref target="X.1520"/>.</li>
        <li>Remote Attestation, which requires a link between reference integrity
measurements (RIM) Reference Integrity Manifests (RIMs) and Attester-produced event logs that complement attestation evidence <xref target="I-D.ietf-rats-architecture"/>.</li> target="RFC9334"/>.</li>
      </ul>
      <t>While there are very few required fields in SWID tags, there are many optional
fields that support different uses. A
SWID tag consisting of only required fields might be a few hundred bytes in
size; however, a tag containing many of the optional fields can be many orders of
magnitude larger. Thus, real-world instances of SWID tags can be fairly large, and the communication of
SWID tags in usage scenarios, such as those described earlier, can cause a large
amount of data to be transported. This can be larger than acceptable for
constrained devices and networks. Concise SWID (CoSWID) tags significantly reduce the amount of
data transported as compared to a typical SWID tag
through the use of the Concise
Binary Object Representation (CBOR) <xref target="RFC8949"/>.</t>
      <t>Size comparisons between XML SWID and CoSWID mainly depend on domain-specific applications and the complexity of attributes used in instances.
While the values stored in CoSWID are often unchanged and therefore not reduced in size compared to an XML SWID, the scaffolding that the CoSWID encoding represents is significantly smaller by taking up 10 percent or less in size.
This effect is visible in representation sizes, which in early experiments benefited from a 50 percent to 85 percent reduction in generic usage scenarios.
Additional size reduction is enabled with respect to the memory footprint of XML parsing/validation.</t>
      <t>In a CoSWID, the human-readable labels of SWID data items are replaced with
more concise integer labels (indices). This approach allows SWID and CoSWID to share a common implicit information model, with CoSWID providing an alternate data model <xref target="RFC3444"/>. While SWID and CoSWID are intended to share the same implicit information model, this specification does not define this information model, model or a mapping between the two data formats. While an attempt to align SWID and CoSWID tags has been made here, future revisions of ISO/IEC 19770-2:2015 or this specification might cause this implicit information model to diverge, since these specifications are maintained by different standards groups.</t>
      <t>The use of CBOR to express SWID information in CoSWID tags allows both CoSWID and SWID tags to be part of an
enterprise security solution for a wider range of endpoints and environments.</t>
      <section anchor="intro-lifecycle">
        <name>The SWID and CoSWID Tag Lifecycle</name>
        <t>In addition to defining the format of a SWID tag record, ISO/IEC 19770-2:2015
defines requirements concerning the SWID tag lifecycle. Specifically, when a
software component is installed on an endpoint, that software component's SWID tag is also
installed. Likewise, when the software component is uninstalled or replaced, the SWID tag
is deleted or replaced, as appropriate. As a result, ISO/IEC 19770-2:2015 describes
a system wherein there is a correspondence between the set of installed software
components on an endpoint, endpoint and the presence of the corresponding SWID tags
for these components on that endpoint. CoSWIDs share the same lifecycle requirements
as a SWID tag.</t>
        <t>The SWID specification and supporting guidance provided in NIST Internal Report (NISTIR) 8060: Guidelines 8060 ("Guidelines for the Creation of Interoperable SWID Tags Software
Identification (SWID) Tags") <xref target="SWID-GUIDANCE"/> defines define four types of SWID tags: primary, patch, corpus, and supplemental. The following text is paraphrased from these sources.</t>
        <ol spacing="normal" type="1">
          <li>Primary Tag - A
     <dl newline="false" spacing="normal">
          <dt>Primary Tag:</dt><dd>A SWID or CoSWID tag that identifies and describes an installed software component on an endpoint. A primary tag is intended to be installed on an endpoint along with the corresponding software component.</li>
          <li>Patch Tag - A component.</dd>
          <dt>Patch Tag:</dt><dd>A SWID or CoSWID tag that identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. A patch tag is intended to be installed on an endpoint along with the corresponding software component patch.</li>
          <li>Corpus Tag - A patch.</dd>
          <dt>Corpus Tag:</dt><dd>A SWID or CoSWID tag that identifies and describes an installable software component in its pre-installation state. A corpus tag can be used to represent metadata about an installation package or installer for a software component, a software update, or a patch.</li>
          <li>Supplemental Tag - A patch.</dd>
          <dt>Supplemental Tag:</dt><dd>A SWID or CoSWID tag that allows additional information to be associated with a referenced SWID tag. This allows tools and users to record their own metadata about a software component without modifying CoSWID primary or patch tags created by a software provider.</li>
        </ol> provider.</dd>
     </dl>
        <t>The type of a tag is determined by specific data elements, which are discussed in <xref target="semantics-tag-type"/>, which target="semantics-tag-type"/>. <xref target="semantics-tag-type"/> also provides normative language for CoSWID semantics that implement this lifecycle. The following information helps to explain how these semantics apply to the use of a CoSWID tag.</t>
        <ul empty="true">
          <li>
            <t>Corpus, primary, and patch tags have similar functions in that they describe the existence and/or presence of different types of software components (e.g., software installers, software installations, software patches), patches) and, potentially, different states of these software components. Supplemental tags have the same structure as other tags, tags but are used to provide information not contained in the referenced corpus, primary, and patch tags. All four tag types come into play at various points in the software lifecycle and support software management processes that depend on the ability to accurately determine where each software component is in its lifecycle.</t>
          </li>
        </ul>
        <figure anchor="fig-lifecycle">
          <name>Use of Tag Types in the Software Lifecycle</name>
          <artwork><![CDATA[
                                  +------------+
                                  v            |
Software      Software        Software     Software      Software
Deployment -> Installation -> Patching  -> Upgrading  -> Removal

Corpus        Primary         Primary      xPrimary      xPrimary
Supplemental  Supplemental    Supplemental xSupplemental xSupplemental
                              Patch        xPatch
                                           Primary
                                           Supplemental
]]></artwork>
        </figure>
        <ul empty="true">
          <li>
            <t><xref target="fig-lifecycle"/> illustrates the steps in the software lifecycle and the relationships among those lifecycle events supported by the four types of SWID and CoSWID tags. A detailed description of the four tags tag types is provided in <xref target="model-concise-swid-tag"/>. The figure identifies the types of tags that are used in each lifecycle event.</t>
          </li>
        </ul>
        <t>There are many ways in which software tags might be managed for the host the software is installed on. For example, software tags could be made available on the host or to an external software manager when storage is limited on the host.</t>
        <t>In these cases cases, the host or external software manager is responsible for management of the tags, including deployment and removal of the tags as indicated by the above lifecycle. Tags are deployed deployed, and previously deployed tags that are typically removed (indicated by an "x" prefix) at each lifecycle stage, stage as follows:</t>
        <ul empty="true">
          <li>
            <ul
            <dl newline="false" spacing="normal">
              <li>Software Deployment. Before
              <dt>Software Deployment:</dt><dd>Before the software component is installed (i.e., pre-installation), and while the product is being deployed, a corpus tag provides information about the installation files and distribution media (e.g., CD/DVD, distribution package).</li>
            </ul> package).</dd>
	    </dl>
	  </li>
	</ul>
            <t>Corpus tags are not actually deployed on the target system but are intended to support deployment procedures and their dependencies at install-time, install time, such as to verify the installation media.</t>
        <ul empty="true">
          <li>
            <ul
            <dl newline="false" spacing="normal">
              <li>Software Installation. A
              <dt>Software Installation:</dt><dd>A primary tag will be installed with the software component (or subsequently created) to uniquely identify and describe the software component. Supplemental tags are created to augment primary tags with additional site-specific or extended information. While not illustrated in the figure, patch tags can also be installed during software installation to provide information about software fixes deployed along with the base software installation.</li>
              <li>Software Patching. A new patch tag is provided, when installation.</dd>
              <dt>Software Patching:</dt><dd>When a patch is applied to the software component, a new patch tag is provided, supplying details about the patch and its dependencies. While not illustrated in the figure, a corpus tag can also provide information about the patch installer and patching dependencies that need to be installed before the patch.</li>
              <li>Software Upgrading. As patch.</dd>
              <dt>Software Upgrading:</dt><dd><t>As a software component is upgraded to a new version, new primary and supplemental tags replace existing tags, enabling timely and accurate tracking of updates to software inventory. While not illustrated in the figure, a corpus tag can also provide information about the upgrade installer and dependencies that need to be installed before the upgrade.</li>
            </ul>
          </li>
        </ul>
        <t>Note: upgrade.</t>
       <aside><t>Note: In the context of software tagging tagging, software patching and updating differ in an important way. When installing a patch, a set of file modifications are made to pre-installed software which software; these modifications do not alter the version number or the descriptive metadata of an installed software component. An update can also make a set of file modifications, but modifications; in that case, the version number or  the descriptive metadata of an installed software component are changed.</t>
        <ul empty="true">
          <li>
            <ul spacing="normal">
              <li>Software Removal. Upon is changed.</t></aside>
</dd>
              <dt>Software Removal:</dt><dd>Upon removal of the software component, relevant SWID tags are removed. This removal event can trigger timely updates to software inventory reflecting the removal of the product and any associated patch or supplemental tags.</li>
            </ul> tags.</dd>
	    </dl>
          </li>
        </ul>
        <t>As illustrated in the figure, supplemental tags can be associated with any corpus, primary, or patch tag to provide additional metadata about an installer, installed software, or installed patch patch, respectively.</t>
        <t>Understanding the use of CoSWIDs in the software lifecycle provides a basis for understanding the information provided in a CoSWID and the associated semantics of this information. Each of the different SWID and CoSWID tag types provide type provides different sets of
information. For example, a "corpus tag" is used to
describe a software component's installation image on an installation media, medium, while a
"patch tag" is meant to describe a patch that modifies some other software component.</t>
      </section>
      <section anchor="concise-swid-format">
        <name>Concise SWID Format</name>
        <t>This document defines the CoSWID tag format, which is based on CBOR. CBOR-based CoSWID tags offer a more concise representation of SWID information as compared to the XML-based SWID tag representation in ISO-19770-2:2015. The structure of a CoSWID is described via the Concise
Data Definition Language (CDDL) <xref target="RFC8610"/>. The resulting CoSWID data
definition is aligned to with the information able to be expressed with the XML schema Schema definition of ISO-19770-2:2015
<xref target="SWID"/>. This alignment allows both SWID and CoSWID tags to represent a common set of software component information and allows CoSWID tags to support the same uses as a SWID tag.</t>
        <t>The vocabulary, i.e., vocabulary (i.e., the CDDL names of the types and members used in
the CoSWID CDDL specification, are specification) is mapped to more concise labels represented as
small integer values (indices). The names used in the CDDL specification and the mapping to
the CBOR representation using integer indices is are based on the vocabulary of the
XML attribute and element names defined in ISO/IEC 19770-2:2015.</t>
      </section>
      <section anchor="requirements-notation">
        <name>Requirements Notation</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="data-def">
      <name>Concise SWID Data Definition</name>
      <t>The following describes the general rules and processes for encoding data using CDDL representation. Prior familiarity with CBOR and CDDL concepts will be helpful in understanding this CoSWID specification.</t>
      <t>This section describes the conventions by which a CoSWID is represented in the CDDL structure. The CamelCase notation <xref target="CamelCase"/> notation used in the XML schema Schema definition is changed to a hyphen-separated
notation <xref target="KebabCase"/> (e.g., ResourceCollection "ResourceCollection" is named resource-collection) "resource-collection") in the CoSWID CDDL specification.
This deviation from the original notation used in the XML representation reduces ambiguity when referencing
certain attributes in corresponding textual descriptions. An attribute referred to by its name in CamelCase
notation explicitly relates to XML SWID tags; an attribute referred to by its name in
KebabCase notation explicitly relates to CBOR CoSWID tags. This approach simplifies the
composition of further work that will reference both XML SWID and CBOR CoSWID documents.</t>
      <t>In most cases, mapping attribute names between SWID and CoSWID can be done automatically by converting between CamelCase and KebabCase attribute names. However, some CoSWID CDDL attribute names show greater variation relative to their corresponding SWID XML Schema attributes. This is done when the change improves clarity in the CoSWID specification. For example, the "name" and "version" SWID fields corresponds correspond to the "software-name" and "software-version" CoSWID fields, respectively. As such, it is not always possible to mechanically translate between corresponding attribute names in the two formats. In such cases, a manual mapping will need to be used.  XPath expressions <xref target="W3C.REC-xpath20-20101214"/> need to use SWID names, names; see <xref target="uri-scheme-swidpath"/>.</t>
      <t>The 57 human-readable text labels of the CDDL-based CoSWID vocabulary are mapped to integer indices via a block of rules at the bottom of the definition. This allows a more concise integer-based form to be stored or transported, as compared to the less efficient text-based form of the original vocabulary.</t>
      <t>Through the use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see <xref target="model-extension"/>). New constructs can be associated with a new integer index. A deprecated construct can be replaced by a new construct with a new integer index. An implementation can use these integer indexes indices to identify the construct to parse. The CoSWID Items "CoSWID Items" registry, defined in <xref target="iana-coswid-items"/>, is used to ensure that new constructs are assigned a unique index value. This approach avoids the need to have an explicit CoSWID version.</t>
      <t>In a number of places, the value encoding admits both integer values and text strings.
The integer values are defined in a registry specific to the kind of value; the text values are not intended for interchange and are exclusively meant for private use as defined in <xref target="iana-private-use"/>. Encoders <bcp14>SHOULD NOT</bcp14> use string values based on the names registered in the registry, as these values are less concise than their index value equivalent; a decoder <bcp14>MUST</bcp14> however <bcp14>MUST</bcp14>, however, be prepared to accept text strings that are not specified in this document (and ignore the construct if that a string is unknown).
In the rest of the this document, we call this an "integer label with text escape".</t>
      <t>The root of the CDDL specification provided by this document is the
rule <tt>coswid</tt> (as defined in <xref target="tagged"/>):</t>

      <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
start = coswid
</sourcecode>
      <t>In CBOR, an array is encoded using bytes that identify the array, and the array's length or stop point (see <xref target="RFC8949"/>). To make items that support 1 one or more values, the following CDDL notation is used.</t>
      <sourcecode type="CDDL;example"> type="cddl" name="coswid-exposition.cddl">
_name_ = (_label_ =&gt; _data_ / [ 2* _data_ ])
</sourcecode>
      <t>The CDDL rule above allows either a single data item or an array of 2 two or more data values to be provided. When a singleton data value is provided, the CBOR markers for the array, array length, and stop point are not needed, saving bytes. When two or more data values are provided, these values are encoded as an array. This modeling pattern is used frequently in the CoSWID CDDL specification to allow for more efficient encoding of singleton values.</t>
      <t>Usage of this construct can be simplified using</t>
      <sourcecode type="CDDL;example"> type="cddl" name="coswid-exposition.cddl">
one-or-more&lt;T&gt; = T / [ 2* T ]
</sourcecode>
      <!-- Hmm, duplicate detection doesn't work in CDDL tool here. -->

<t>simplifying the above example to</t>
      <sourcecode type="CDDL;example"> type="cddl" name="coswid-exposition.cddl">
_name_ = (_label_ =&gt; one-or-more&lt;_data_&gt;)
</sourcecode>
      <t>The following subsections describe the different parts of the CoSWID model.</t>
      <section anchor="character-encoding">
        <name>Character Encoding</name>
        <t>The CDDL "text" type is represented in CBOR as a major type 3, which represents "a a string of Unicode characters that [are] are encoded as UTF-8 <xref target="RFC3629"/>" target="RFC3629"/> (see <xref section="3.1" sectionFormat="of" target="RFC8949"/>). Thus
Thus, both SWID and CoSWID use UTF-8 for the encoding of characters in text strings.</t>

        <t>To ensure that UTF-8 character strings are able to be encoded/decoded and exchanged interoperably, text strings in CoSWID <bcp14>MUST</bcp14> be encoded in a way that is consistent with the Net-Unicode definition defined provided in <xref target="RFC5198"/>.</t>
        <t>All names registered with IANA according to the requirements in <xref target="iana-value-registries"/> also <bcp14>MUST</bcp14> be valid according to the XML Schema NMTOKEN data type (see <xref target="W3C.REC-xmlschema-2-20041028"/>, Section 3.3.4) to ensure compatibility with the SWID specification where these names are used.</t>
      </section>
      <section anchor="model-extension">
        <name>Concise SWID Extensions</name>
        <t>The CoSWID specification contains two features that are not included in the SWID specification on which it is based. These features are:</t>
        <ul spacing="normal">
          <li>The explicit definition of types for some attributes in the ISO-19770-2:2015 XML representation that are typically represented by
the "any attribute" any-attribute item in the SWID model. These are
covered in <xref target="model-global-attributes"/>.</li>
          <li>The inclusion of extension points in the CoSWID specification using CDDL sockets (see <xref section="3.9" sectionFormat="of" target="RFC8610"/>). The use of CDDL sockets allow allows for well-formed extensions to be defined in supplementary CDDL descriptions that support additional uses of CoSWID tags that go beyond the original scope of ISO-19770-2:2015 tags.</li>
        </ul>
        <t>The following CDDL sockets (extension points) are defined in this document, which document; they allow the addition of new information structures to their respective CDDL groups.</t>
        <table anchor="tbl-model-extension-group-sockets">
          <name>CoSWID CDDL Group Extension Points</name>
          <thead>
            <tr>
              <th align="left">Map Name</th>
              <th align="left">CDDL Socket</th>
              <th align="left">Defined in</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">concise-swid-tag</td>
              <td align="left">$$coswid-extension</td>
              <td align="left">
                <xref target="model-concise-swid-tag"/></td>
            </tr>
            <tr>
              <td align="left">entity-entry</td>
              <td align="left">$$entity-extension</td>
              <td align="left">
                <xref target="model-entity"/></td>
            </tr>
            <tr>
              <td align="left">link-entry</td>
              <td align="left">$$link-extension</td>
              <td align="left">
                <xref target="model-link"/></td>
            </tr>
            <tr>
              <td align="left">software-meta-entry</td>
              <td align="left">$$software-meta-extension</td>
              <td align="left">
                <xref target="model-software-meta"/></td>
            </tr>
            <tr>
              <td align="left">resource-collection</td>
              <td align="left">$$resource-collection-extension</td>
              <td align="left">
                <xref target="model-resource-collection"/></td>
            </tr>
            <tr>
              <td align="left">file-entry</td>
              <td align="left">$$file-extension</td>
              <td align="left">
                <xref target="model-resource-collection"/></td>
            </tr>
            <tr>
              <td align="left">directory-entry</td>
              <td align="left">$$directory-extension</td>
              <td align="left">
                <xref target="model-resource-collection"/></td>
            </tr>
            <tr>
              <td align="left">process-entry</td>
              <td align="left">$$process-extension</td>
              <td align="left">
                <xref target="model-resource-collection"/></td>
            </tr>
            <tr>
              <td align="left">resource-entry</td>
              <td align="left">$$resource-extension</td>
              <td align="left">
                <xref target="model-resource-collection"/></td>
            </tr>
            <tr>
              <td align="left">payload-entry</td>
              <td align="left">$$payload-extension</td>
              <td align="left">
                <xref target="model-payload"/></td>
            </tr>
            <tr>
              <td align="left">evidence-entry</td>
              <td align="left">$$evidence-extension</td>
              <td align="left">
                <xref target="model-evidence"/></td>
            </tr>
          </tbody>
        </table>
        <t>The CoSWID Items Registry "CoSWID Items" registry, defined in <xref target="iana-coswid-items"/> target="iana-coswid-items"/>, provides a registration mechanism allowing new items, and their associated index values, to be added to the CoSWID model through the use of the CDDL sockets described in the table above. This registration mechanism provides for well-known index values for data items in CoSWID extensions, allowing these index values to be recognized by implementations supporting a given extension.</t>
        <t>The following additional CDDL sockets are defined in this document to allow for adding new values to corresponding type-choices (i.e. type choices (i.e., to represent enumerations) via custom CDDL specifications.</t>
        <table anchor="tbl-model-extension-enum-sockets">
          <name>CoSWID CDDL Enumeration Extension Points</name>
          <thead>
            <tr>
              <th align="left">Enumeration Name</th>
              <th align="left">CDDL Socket</th>
              <th align="left">Defined in</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">version-scheme</td>
              <td align="left">$version-scheme</td>
              <td align="left">
                <xref target="indexed-version-scheme"/></td>
            </tr>
            <tr>
              <td align="left">role</td>
              <td align="left">$role</td>
              <td align="left">
                <xref target="indexed-entity-role"/></td>
            </tr>
            <tr>
              <td align="left">ownership</td>
              <td align="left">$ownership</td>
              <td align="left">
                <xref target="indexed-link-ownership"/></td>
            </tr>
            <tr>
              <td align="left">rel</td>
              <td align="left">$rel</td>
              <td align="left">
                <xref target="indexed-link-rel"/></td>
            </tr>
            <tr>
              <td align="left">use</td>
              <td align="left">$use</td>
              <td align="left">
                <xref target="indexed-link-use"/></td>
            </tr>
          </tbody>
        </table>
        <t>A number of CoSWID value IANA registries for CoSWID values are also defined in <xref target="iana-value-registries"/> that target="iana-value-registries"/>; these registries allow new values to be registered with IANA for the enumerations above. This registration mechanism supports the definition of new well-known index values and names for new enumeration values used by CoSWID, which can also be used by other software tagging specifications. This registration mechanism allows new standardized enumerated values to be shared between multiple tagging specifications (and associated implementations) over time.</t>
      </section>
      <section anchor="model-concise-swid-tag">
        <name>The concise-swid-tag Map</name>
        <t>The CDDL specification for the root concise-swid-tag map is as follows and this follows. This rule and its constraints <bcp14>MUST</bcp14> be followed when creating or validating a CoSWID tag:</t>
        <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
concise-swid-tag = {
  tag-id =&gt; text / bstr .size 16,
  tag-version =&gt; integer,
  ? corpus =&gt; bool,
  ? patch =&gt; bool,
  ? supplemental =&gt; bool,
  software-name =&gt; text,
  ? software-version =&gt; text,
  ? version-scheme =&gt; $version-scheme,
  ? media =&gt; text,
  ? software-meta =&gt; one-or-more&lt;software-meta-entry&gt;,
  entity =&gt; one-or-more&lt;entity-entry&gt;,
  ? link =&gt; one-or-more&lt;link-entry&gt;,
  ? payload-or-evidence,
  * $$coswid-extension,
  global-attributes,
}

payload-or-evidence //= ( payload =&gt; payload-entry )
payload-or-evidence //= ( evidence =&gt; evidence-entry )

tag-id = 0
software-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14

$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= int / text
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
</sourcecode>
        <t>The following list describes each member of the concise-swid-tag root map.</t>
        <ul
        <dl newline="false" spacing="normal">
          <li>global-attributes: A
          <dt>global-attributes:</dt><dd>A list of items items, including an optional language definition to support the
processing of text-string values and an unbounded set of any-attribute items. Described in <xref target="model-global-attributes"/>.</li>
          <li>tag-id target="model-global-attributes"/>.</dd>
          <dt>tag-id (index 0): A 0):</dt><dd>A 16-byte binary string, or a textual identifier, uniquely referencing a software component. The tag
identifier <bcp14>MUST</bcp14> be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use use, since the tag-id serves as the global key for matching and lookups. If represented as a 16-byte binary string, the identifier <bcp14>MUST</bcp14> be a valid universally unique identifier Universally Unique Identifier (UUID) as defined by <xref target="RFC4122"/>. There are no strict guidelines on
how the identifier is structured, but examples include a 16-byte GUID Globally Unique Identifier (GUID) (e.g.,
class 4 UUID) <xref target="RFC4122"/>, or a DNS domain name followed by a "/" and a text string, where the domain name serves to ensure uniqueness across organizations.
A textual tag-id value <bcp14>MUST NOT</bcp14> contain a sequence of two underscores ("__", see ("__"). This is because a sequence of two underscores is used to separate the TAG_CREATOR_REGID value and UNIQUE_ID value in a Software Identifier and a sequence of two underscores in a tag-id value could create ambiguity when parsing this identifier. See <xref target="sec-swima"/>).</li>
          <li>tag-version target="sec-swima"/>.</dd>
          <dt>software-name (index 12): An integer value 1):</dt><dd>A textual item that indicate provides the specific release revision of software component's name. This name is likely the same name that would appear in a package management tool. This item maps to '/SoftwareIdentity/@name' in <xref target="SWID"/>.</dd>
          <dt>entity (index 2):</dt><dd>Provides information about one or more organizations responsible for producing the CoSWID tag, and producing or releasing the software component referenced by this
CoSWID tag. Typically, Described in <xref target="model-entity"/>.</dd>
          <dt>evidence (index 3):</dt><dd>Can be used to record the initial value results of this field a software discovery process used to identify untagged software on an endpoint or to represent indicators for why software is set believed to 0 and be installed on the value endpoint. In either case, a CoSWID tag can be created by the tool performing an analysis of the software components installed on the endpoint. This item is increased for subsequent mutually exclusive to payload, as evidence is always generated on the target device ad hoc. Described in <xref target="model-evidence"/>.</dd>
          <dt>link (index 4):</dt><dd>Provides a means to establish relationship arcs between the tag and another item. A given link can be used to establish the relationship between tags produced for or to reference another resource that is related to the same
CoSWID tag, e.g.,
vulnerability database association, Resource-Oriented Lightweight Information Exchange (ROLIE) Feed <xref target="RFC8322"/>, Manufacturer Usage Description (MUD) resource <xref target="RFC8520"/>, software component release. download location, etc.).
This value is modeled after the HTML "link" element.  Described in <xref target="model-link"/>.</dd>
          <dt>software-meta (index 5):</dt><dd>An open-ended map of key/value data pairs.
A number of predefined keys can be used within this item providing for
common usage and semantics across the industry.  The use of this map allows a CoSWID tag producer any additional
attribute to correct an incorrect tag previously released without indicating be included in the tag. It is expected that industry groups will use a change common set of attribute names to the underlying allow for interoperability within their communities. Described in <xref target="model-software-meta"/>. This item maps to '/SoftwareIdentity/Meta' in <xref target="SWID"/>.</dd>
          <dt>payload (index 6):</dt><dd>Represents a collection of software component artifacts (described by child items) that compose the tag represents. target software. For example, the tag version these artifacts could be changed to add new metadata, to correct the files included with an installer for a broken link, to add corpus tag or installed on an endpoint when the software component
is installed for a primary or patch tag. The artifacts listed in a missing payload entry, etc. When producing may be a revised tag, superset of the new tag-version value <bcp14>MUST</bcp14> software artifacts that are actually installed. Based on user selections at install time,
an installation might not include every artifact that could be greater than created or executed on the old tag-version value.</li>
          <li>corpus
endpoint when the software component is installed or run. This item is mutually exclusive to evidence, as payload can only be provided by an external entity. Described in <xref target="model-payload"/>.</dd>
          <dt>corpus (index 8): A 8):</dt><dd>A boolean value that indicates if the tag identifies and describes an installable software component in its pre-installation state. Installable software includes an installation package or installer for a software component, a software update, or a patch. If the CoSWID tag represents installable software, the corpus item <bcp14>MUST</bcp14> be set to "true". If not provided, the default value <bcp14>MUST</bcp14> be considered "false".</li>
          <li>patch "false".</dd>
          <dt>patch (index 9): A 9):</dt><dd>A boolean value that indicates if the tag identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. If a CoSWID tag is for a patch, the patch item <bcp14>MUST</bcp14> be set to "true". If not provided, the default value <bcp14>MUST</bcp14> be considered "false". A patch item's value <bcp14>MUST NOT</bcp14> be set to "true" if the installation of the associated software package changes the version of a software component.</li>
          <li>supplemental component.</dd>
          <dt>media (index 11): A 10):</dt><dd>A text value that provides a hint to the tag consumer to understand what target platform this tag
applies to. This item <bcp14>MUST</bcp14> be formatted as a
query as defined by the W3C "Media Queries Level 3" Recommendation (see <xref target="W3C.REC-mediaqueries-3-20220405"/>). Support for media queries is included here for interoperability with <xref target="SWID"/>, which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used for a CoSWID.</dd>
          <dt>supplemental (index 11):</dt><dd>A boolean value that indicates if the tag is providing additional information to be associated with another referenced SWID or CoSWID tag. This allows tools and users to record their own metadata about a software component without modifying SWID primary or patch tags created by a software provider. If a CoSWID tag is a supplemental tag, the supplemental item <bcp14>MUST</bcp14> be set to "true". If not provided, the default value <bcp14>MUST</bcp14> be considered "false".</li>
          <li>software-name "false".</dd>
          <dt>tag-version (index 1): This textual item provides 12):</dt><dd>An integer value that indicates the software component's name. This name specific release revision of the tag. Typically, the initial value of this field is likely set to 0 and the value is increased for subsequent tags produced for the same name that would appear in a package management tool. software component release. This item maps value allows a CoSWID tag producer to '/SoftwareIdentity/@name' in <xref target="SWID"/>.</li>
          <li>software-version correct an incorrect tag previously released without indicating a change to the underlying software component the tag represents. For example, the tag-version could be changed to add new metadata, to correct a broken link, to add a missing payload entry, etc. When producing a revised tag, the new tag-version value <bcp14>MUST</bcp14> be greater than the old tag-version value.</dd>
          <dt>software-version (index 13): A 13):</dt><dd>A textual value representing the specific release or development version of the software component. This item maps to '/SoftwareIdentity/@version' in <xref target="SWID"/>.</li>
          <li>version-scheme target="SWID"/>.</dd>
          <dt>version-scheme (index 14): An 14):</dt><dd>An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape (<xref target="data-def"/>, for escape. For the "Version Scheme" registry values, see <xref target="indexed-version-scheme"/>). target="indexed-version-scheme"/>.
If an integer value is used used, it <bcp14>MUST</bcp14> be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see <xref target="iana-private-use"/>). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Version Scheme Values" registry (see <xref target="iana-version-scheme"/>).</li>
          <li>media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag
applies to. This item <bcp14>MUST</bcp14> be formatted as a
query as defined by the W3C Media Queries Recommendation (see <xref target="W3C.REC-css3-mediaqueries-20120619"/>). Support for media queries are included here for interoperability with <xref target="SWID"/>, which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used for a CoSWID.</li>
          <li>software-meta (index 5): An open-ended map of key/value data pairs.
A number of predefined keys can be used within this item providing for
common usage and semantics across the industry.  Use of this map allows any additional
attribute to be included in the tag. It is expected that industry groups will use a common set of attribute names to allow for interoperability within their communities. Described in <xref target="model-software-meta"/>. This item maps to '/SoftwareIdentity/Meta' in <xref target="SWID"/>.</li>
          <li>entity (index 2): Provides information about one or more organizations responsible for producing the CoSWID tag, and producing or releasing the software component referenced by this
CoSWID tag. Described in <xref target="model-entity"/>.</li>
          <li>link (index 4): Provides a means to establish relationship arcs between the tag and another items. A given link can be used to establish the relationship between tags or to reference another resource that is related to the
CoSWID tag, e.g.,
vulnerability database association, ROLIE feed <xref target="RFC8322"/>, MUD resource <xref target="RFC8520"/>, software download location, etc).
This is modeled after the HTML "link" element.  Described in <xref target="model-link"/>.</li>
          <li>payload (index 6): This item represents a collection of software artifacts (described by child items) that compose the target software. For example, these artifacts could be the files included with an installer for a corpus tag or installed on an endpoint when the software component
is installed for a primary or patch tag. The artifacts listed in a payload may be a superset of the software artifacts that are actually installed. Based on user selections at install time,
an installation might not include every artifact that could be created or executed on the
endpoint when the software component is installed or run. This item is mutually exclusive to evidence, as payload can only be provided by an external entity. Described in <xref target="model-payload"/>.</li>
          <li>evidence (index 3): This item can be used to record the results of a software discovery process used to identify untagged software on an endpoint or to represent indicators for why software is believed to be installed on the endpoint. In either case, a CoSWID tag can be created by the tool performing an analysis of the software components installed on the endpoint. This item is mutually exclusive to payload, as evidence is always generated on the target device ad-hoc. Described in <xref target="model-evidence"/>.</li>
          <li>$$coswid-extension: This target="iana-version-scheme"/>).</dd>
          <dt>$$coswid-extension:</dt><dd>A CDDL socket that is used to add new information structures to the concise-swid-tag root map. See <xref target="model-extension"/>.</li>
        </ul> target="model-extension"/>.</dd>
	</dl>
      </section>
      <section anchor="concise-swid-tag-co-constraints">
        <name>concise-swid-tag Co-Constraints</name> Co-constraints</name>
        <t>The following co-constraints apply to the information provided in the concise-swid-tag group.</t>
        <ul spacing="normal">
          <li>The patch and supplemental items <bcp14>MUST NOT</bcp14> both be set to "true".</li>
          <li>If the patch item is set to "true", the tag <bcp14>MUST</bcp14> contain at least one link item (see <xref target="model-link"/>) with both the rel item value of "patches" and an href item specifying an association with the software that was patched. Without at least one link item item, the target of the patch cannot be identified and the patch tag cannot be applied without external context.</li>
          <li>If all of the corpus, patch, and supplemental items are "false", "false" or if the corpus item is set to "true", then a software-version item <bcp14>MUST</bcp14> be included with a value set to the version of the software component. This ensures that primary and corpus tags have an identifiable software version.</li> component.</li>
        </ul>
      </section>
      <section anchor="model-global-attributes">
        <name>The global-attributes Group</name>
        <t>The global-attributes group provides a list of items, including an optional
language definition to support the processing of text-string values, and an
unbounded set of any-attribute items allowing for additional items to be
provided as a general point of extension in the model.</t>
        <t>The CDDL for the global-attributes group follows:</t>
        <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
global-attributes = (
  ? lang =&gt; text,
  * any-attribute,
)

any-attribute = (
  label =&gt; one-or-more&lt;text&gt; / one-or-more&lt;int&gt;
)

label = text / int
</sourcecode>
        <t>The following list describes each child item of this group.</t>
        <ul
         <dl newline="false" spacing="normal">
          <li>lang
          <dt>lang (index 15): A 15):</dt><dd>A textual language tag that
conforms with the IANA "Language Subtag Registry" <xref target="RFC5646"/>. The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context <bcp14>MUST</bcp14> be considered expressed in the specified language.</li>
          <li>any-attribute: This language.</dd>
          <dt>any-attribute:</dt><dd>A sub-group that provides a means to include arbitrary information
via label/index ("key") value pairs. Labels can be either a single integer or text string. Values can be a single integer, a text string, or an array of integers or text strings.</li>
        </ul> strings.</dd>
	 </dl>
      </section>
      <section anchor="model-entity">
        <name>The entity-entry Map</name>
        <t>The CDDL for the entity-entry map follows:</t>
        <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
entity-entry = {
  entity-name =&gt; text,
  ? reg-id =&gt; any-uri,
  role =&gt; one-or-more&lt;$role&gt;,
  ? thumbprint =&gt; hash-entry,
  * $$entity-extension,
  global-attributes,
}

entity-name = 31
reg-id = 32
role = 33
thumbprint = 34

$role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= maintainer
$role /= int / text
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
maintainer=6
</sourcecode>
        <t>The following list describes each child item of this group.</t>
        <ul
         <dl newline="false" spacing="normal">
          <li>global-attributes: The
          <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
          <li>entity-name target="model-global-attributes"/>.</dd>
          <dt>entity-name (index 31): The 31):</dt><dd>The textual name of the organizational entity claiming the roles specified by the role item for the CoSWID tag. This item maps to '/SoftwareIdentity/Entity/@name' in <xref target="SWID"/>.</li>
          <li>reg-id target="SWID"/>.</dd>
          <dt>reg-id (index 32): The registration id 32):</dt><dd>Registration ID. This value is intended to uniquely identify a naming authority in a
given scope (e.g., global, organization, vendor, customer, administrative domain,
etc.) for the referenced entity. The value of a
registration ID <bcp14>MUST</bcp14> be a RFC 3986 URI; URI as defined in <xref target="RFC3986"/>; it is not intended to be dereferenced. The scope will usually be the scope of an organization.</li>
          <li>
            <t>role organization.</dd>
            <dt>role (index 33): An 33):</dt><dd><t>An integer or textual value (integer label with text escape, escape; see <xref target="data-def"/>) representing the relationship(s) between the entity, entity and this tag or the referenced software component. If an integer value is used used, it <bcp14>MUST</bcp14> be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see <xref target="iana-private-use"/>). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software ID Entity Role Values" registry (see <xref target="iana-entity-role"/>).  </t>
            <t>
The target="iana-entity-role"/>).</t>
      <t>The following additional requirements exist for the use of the "role" item:  </t> role item:</t>
            <ul spacing="normal">
              <li>An entity item <bcp14>MUST</bcp14> be provided with the role of "tag-creator" for every CoSWID tag. This indicates the organization that created the CoSWID tag.</li>
              <li>An entity item <bcp14>SHOULD</bcp14> be provided with the role of "software-creator" for every CoSWID tag, if this information is known to the tag creator. This indicates the organization that created the referenced software component.</li>
            </ul>
          </li>
          <li>thumbprint
	  </dd>
	  </dl>
     <dl newline="false" spacing="normal">
          <dt>thumbprint (index 34): The value of the thumbprint item 34):</dt><dd>Value that provides a hash (i.e. (i.e., the thumbprint) of the signing entity's public key certificate. This item provides an indicator of which entity signed the CoSWID tag, which will typically be the tag creator.  See <xref target="model-hash-entry"/> for more details on the use of the hash-entry data structure.</li>
          <li>$$entity-extension: This structure.</dd>
          <dt>$$entity-extension:</dt><dd>A CDDL socket that can be used to extend the entity-entry group model. See <xref target="model-extension"/>.</li>
        </ul> target="model-extension"/>.</dd>
     </dl>
      </section>
      <section anchor="model-link">
        <name>The link-entry Map</name>
        <t>The CDDL for the link-entry map follows:</t>
        <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
link-entry = {
  ? artifact =&gt; text,
  href =&gt; any-uri,
  ? media =&gt; text,
  ? ownership =&gt; $ownership,
  rel =&gt; $rel,
  ? media-type =&gt; text,
  ? use =&gt; $use,
  * $$link-extension,
  global-attributes,
}

media = 10
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42

$ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= int / text
abandon=1
private=2
shared=3

$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= supplemental
$rel /= -356..65536 -256..65536 / text
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
supplemental=11

$use /= optional
$use /= required
$use /= recommended
$use /= int / text
optional=1
required=2
recommended=3
</sourcecode>
        <t>The following list describes each member of this map.</t>
        <ul
         <dl newline="false" spacing="normal">
          <li>global-attributes: The
          <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
          <li>artifact target="model-global-attributes"/>.</dd>
          <dt>media (index 37): To 10):</dt><dd>A value that provides a hint to the consumer of the link so that the consumer understands what target platform the link is applicable to. This item represents a
query as defined by the W3C "Media Queries Level 3" Recommendation (see <xref target="W3C.REC-mediaqueries-3-20220405"/>). As highlighted in the definition of the media item provided in <xref target="model-concise-swid-tag"/>, support for media queries is included here for interoperability with <xref target="SWID"/>, which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used for a CoSWID.</dd>
          <dt>artifact (index 37):</dt><dd>To be used with rel="installationmedia", this rel="installationmedia". This item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation.  Links with the same artifact name <bcp14>MUST</bcp14> be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources.</li>
          <li>
            <t>href sources.</dd>
            <dt>href (index 38): A 38):</dt><dd><t>A URI-reference <xref target="RFC3986"/> for the referenced resource. The "href" href item's value can be, but is not limited to, the following (which is a slightly modified excerpt from <xref target="SWID"/>):
            </t>
            <ul spacing="normal">
              <li>If no URI scheme is provided, then the URI-reference is a relative reference relative to the base URI of the CoSWID tag, i.e., the URI under which the CoSWID tag was provided. For provided -- for example, "./folder/supplemental.coswid".</li>
              <li>a
              <li>This item can be a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://)</li>
              <li>a URI &lt;file://&gt;, &lt;http://&gt;, &lt;https://&gt;, &lt;ftp://&gt;).</li>
              <li>A URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This
URI
expression needs to be resolved in the context of the endpoint by software
that can lookup look up other SWID or CoSWID tags. For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".</li>
              <li>a URI "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". See <xref target="uri-scheme-swid"/> for guidance on the "swid" expressions.</li>
              <li>This item can be a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an
XPATH
XPath query <xref target="W3C.REC-xpath20-20101214"/> that matches items in that tag (<xref target="uri-scheme-swidpath"/>). This scheme is provided for compatibility with <xref target="SWID"/>. This specification does not define how to resolve an XPATH XPath query in the context of CBOR, see <xref target="uri-scheme-swidpath"/>.</li>
            </ul>
          </li>
          <li>media (index 10): A hint to the consumer of the link to what target platform the link is applicable to. This item represents a
query as defined by the W3C Media Queries Recommendation (see <xref target="W3C.REC-css3-mediaqueries-20120619"/>). As highlighted in media defined in <xref target="model-concise-swid-tag"/>, support for media queries are included here for interoperability with CBOR. See <xref target="SWID"/>, which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used target="uri-scheme-swidpath"/> for a CoSWID.</li>
          <li>ownership guidance on the "swidpath" expressions.</li>
            </ul>
          </dd>
          <dt>ownership (index 39): An 39):</dt><dd>An integer or textual value (integer label with text escape, escape; see <xref target="data-def"/>, target="data-def"/>). See <xref target="indexed-link-ownership"/> for the "Software ID Link Ownership Values" registry <xref target="indexed-link-ownership"/>) list of values available for this item. This item is used when the "href" href item references another software component to indicate the degree of ownership between the software component referenced by the CoSWID tag and the software component referenced by the link. If an integer value is used used, it <bcp14>MUST</bcp14> be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see <xref target="iana-private-use"/>). Integer values in the range 0 to 255 correspond to registered entries in the "Software ID Link Ownership Values" registry.</li>
          <li>rel registry.</dd>
          <dt>rel (index 40): An 40):</dt><dd>An integer or textual value that (integer label with text escape, escape; see <xref target="data-def"/>, target="data-def"/>). See <xref target="indexed-link-rel"/> for the "Software ID Link Link Relationship Values" registry <xref target="indexed-link-ownership"/>) list of values available for this item. This item identifies the relationship between this CoSWID and the target resource identified by the "href" href item. If an integer value is used used, it <bcp14>MUST</bcp14> be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see <xref target="iana-private-use"/>). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Link Relationship Values" registry (see <xref target="iana-link-rel"/>). If a string value is used used, it <bcp14>MUST</bcp14> be either a private use name as defined in <xref target="iana-private-use"/> or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml registry (see <eref target="https://www.iana.org/assignments/link-relations/" brackets="angle"/>) as defined by <xref target="RFC8288"/>. When a string value defined in the IANA "Software ID Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software ID Link Relationship Values" registry <bcp14>MUST</bcp14> be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag. String values correspond to registered entries in the "Software ID Link Relationship Values" registry.</li>
          <li>media-type registry.</dd>
          <dt>media-type (index 41): 41):</dt><dd>Supplies the resource consumer with a hint regarding what type of resource to expect. A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item. Use of this item supplies the resource consumer with a hint of what type of resource to expect. (This is a <em>hint</em>: There there
is no obligation for the server hosting the target of the URI to use the
indicated media type when the URI is dereferenced.)
Media types are identified by referencing a "Name" from the IANA "Media Types" registry: http://www.iana.org/assignments/media-types/media-types.xhtml. registry (see <eref target="https://www.iana.org/assignments/media-types/" brackets="angle"/>). This item maps to '/SoftwareIdentity/Link/@type' in <xref target="SWID"/>.</li>
          <li>use target="SWID"/>.</dd>
          <dt>use (index 42): An 42):</dt><dd>An integer or textual value (integer label with text escape, escape; see <xref target="data-def"/>, target="data-def"/>). See <xref target="indexed-link-use"/> for the "Software ID Link Link Relationship Values" registry <xref target="indexed-link-ownership"/>) list of values available for this item. This item is used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID CoSWID tag. If an integer value is used used, it <bcp14>MUST</bcp14> be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see <xref target="iana-private-use"/>). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link "Software ID Link Use Values" registry (see <xref target="iana-link-use"/>). If a string value is used used, it <bcp14>MUST</bcp14> be a private use name as defined in <xref target="iana-private-use"/>. String values correspond to registered entries in the "Software ID Link Use Values" registry.</li>
          <li>$$link-extension: This registry.</dd>
          <dt>$$link-extension:</dt><dd>A CDDL socket that can be used to extend the link-entry map model. See <xref target="model-extension"/>.</li>
        </ul> target="model-extension"/>.</dd>
	 </dl>
      </section>
      <section anchor="model-software-meta">
        <name>The software-meta-entry Map</name>
        <t>The CDDL for the software-meta-entry map follows:</t>
        <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
software-meta-entry = {
  ? activation-status =&gt; text,
  ? channel-type =&gt; text,
  ? colloquial-version =&gt; text,
  ? description =&gt; text,
  ? edition =&gt; text,
  ? entitlement-data-required =&gt; bool,
  ? entitlement-key =&gt; text,
  ? generator =&gt; text / bstr .size 16,
  ? persistent-id =&gt; text,
  ? product =&gt; text,
  ? product-family =&gt; text,
  ? revision =&gt; text,
  ? summary =&gt; text,
  ? unspsc-code =&gt; text,
  ? unspsc-version =&gt; text,
  * $$software-meta-extension,
  global-attributes,
}

activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57
</sourcecode>
        <t>The following list describes each child item of this group.</t>
        <ul
        <dl newline="false" spacing="normal">
          <li>global-attributes: The
          <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
          <li>activation-status target="model-global-attributes"/>.</dd>
          <dt>activation-status (index 43): A 43):</dt><dd>A textual value that identifies how the software component has been activated, which might relate to specific terms and conditions for its use (e.g., Trial, Serialized, Licensed, Unlicensed, etc) trial, serialized, licensed, unlicensed, etc.) and relate to an entitlement.  This attribute is typically used in supplemental tags tags, as it contains information that might be selected during a specific install.</li>
          <li>channel-type install.</dd>
          <dt>channel-type (index 44): A 44):</dt><dd>A textual value that identifies which sales, licensing, or marketing channel the software component has been targeted for (e.g., Volume, Retail, OEM, Academic, etc). volume, retail, original equipment manufacturer (OEM), academic, etc.). This attribute is typically used in supplemental tags tags, as it contains information that might be selected during a specific install.</li>
          <li>colloquial-version install.</dd>
          <dt>colloquial-version (index 45): A 45):</dt><dd>A textual value for the software component's informal or colloquial version. Examples may include a year value, a major version number, or a similar value that are used to identify a group of specific software component releases that are part of the same release/support cycle. This version can be the same through multiple releases of a software component, while the software-version specified in the concise-swid-tag group is much more specific and will change for each software component release. This version is intended to be used for string comparison (byte-by-byte) (byte by byte) only and is not intended to be used to determine if a specific value is earlier or later in a sequence.</li>
          <li>description sequence.</dd>
          <dt>description (index 46): A 46):</dt><dd>A textual value that provides a detailed description of the software component. This value <bcp14>MAY</bcp14> be multiple paragraphs separated by CR LF characters as described by <xref target="RFC5198"/>.</li>
          <li>edition target="RFC5198"/>.</dd>
          <dt>edition (index 47): A 47):</dt><dd>A textual value indicating that the software component represents a functional variation of the code base used to support multiple software components. For example, this item can be used to differentiate enterprise, standard, or professional variants of a software component.</li>
          <li>entitlement-data-required component.</dd>
          <dt>entitlement-data-required (index 48): A 48):</dt><dd>A boolean value that can be used to determine if accompanying proof of entitlement is needed when a software license reconciliation process is performed.</li>
          <li>entitlement-key performed.</dd>
          <dt>entitlement-key (index 49): A 49):</dt><dd>A vendor-specific textual key that can be used to identify and establish a relationship to an entitlement. Examples of an entitlement-key might include a serial number, product key, or license key. For values that relate to a given software component install (i.e., (e.g., license key), a supplemental tag will typically contain this information. In other cases, where a general-purpose key can be provided that applies to all possible installs of the software component on different endpoints, a primary tag will typically contain this information.
Since CoSWID tags are not intended to contain confidential information, tag authors are advised not to record unprotected, private software license keys in this field.</li>
          <li>generator field.</dd>
          <dt>generator (index 50): The 50):</dt><dd>The name (or tag-id) of the software component that created the CoSWID tag. If the generating software component has a SWID or CoSWID tag, then the tag-id for the generating software component <bcp14>SHOULD</bcp14> be provided.</li>
          <li>persistent-id provided.</dd>
          <dt>persistent-id (index 51): A 51):</dt><dd>A globally unique identifier used to identify a set of software components that are related. Software components sharing the same persistent-id can be different versions. This item can be used to relate software components, released at different points in time or through different release channels, that may not be able to be related through the use of the link item.</li>
          <li>product item.</dd>
          <dt>product (index 52): A 52):</dt><dd>A basic name for the software component that can be common across multiple tagged software components (e.g., Apache HTTPD).</li>
          <li>product-family HTTP daemon (HTTPD)).</dd>
          <dt>product-family (index 53): A 53):</dt><dd>A textual value indicating the software components components' overall product family.  This should be used when multiple related software components form a larger capability that is installed on multiple different endpoints. For example, some software families may consist of a server, a client, and shared service components that are part of a larger capability. Email systems, enterprise applications, backup services, web conferencing, and similar capabilities are examples of families. Use The use of this item is not intended to represent groups of software that are bundled or installed together. The persistent-id or link items <bcp14>SHOULD</bcp14> be used to relate bundled software components.</li>
          <li>revision components.</dd>
          <dt>revision (index 54): A 54):</dt><dd>A string value indicating an informal or colloquial release version of the software. This value can provide a different version value as compared to the software-version specified in the concise-swid-tag group. This is useful when one or more releases need to have an informal version label that differs from the specific exact version value specified by software-version. Examples can include SP1, RC1, Beta, etc.</li>
          <li>summary etc.</dd>
          <dt>summary (index 55): A 55):</dt><dd>A short description of the software component. This <bcp14>MUST</bcp14> be a single sentence suitable for display in a user interface.</li>
          <li>unspsc-code interface.</dd>
          <dt>unspsc-code (index 56): An 8 digit UNSPSC 56):</dt><dd>An 8-digit United Nations Standard Products and Services Code (UNSPSC) classification code for the software component as defined by the United Nations Standard Products and Services Code (UNSPSC, UNSPSC <xref target="UNSPSC"/>).</li>
          <li>unspsc-version target="UNSPSC"/>.</dd>
          <dt>unspsc-version (index 57): The version of 57):</dt><dd>The UNSPSC version used to define the unspsc-code value.</li>
          <li>$$meta-extension: This value.</dd>
          <dt>$$software-meta-extension:</dt><dd>A CDDL socket that can be used to extend the software-meta-entry group model. See <xref target="model-extension"/>.</li>
        </ul> target="model-extension"/>.</dd>
	</dl>
      </section>
      <section anchor="the-resource-collection-definition">
        <name>The Resource Collection Definition</name>
        <section anchor="model-hash-entry">
          <name>The hash-entry Array</name>
          <t>CoSWID adds explicit support for the representation of hash entries using algorithms that are
registered in the IANA "Named Information Hash Algorithm Registry" <xref target="IANA.named-information"/> using target="IANA.named-information"/>. This array is used by both the hash member (index 7) and the corresponding hash-entry type. thumbprint (index 34) values. This is the equivalent of the namespace qualified "hash" attribute in <xref target="SWID"/>.</t>
          <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
hash-entry = [
  hash-alg-id: int,
  hash-value: bytes,
]
</sourcecode>
          <t>The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's whose value <bcp14>MUST</bcp14> refer to an ID in the IANA "Named Information Hash Algorithm Registry" <xref target="IANA.named-information"/> with a Status of "current" (at the time the generator software was built or later); other hash algorithms <bcp14>MUST NOT</bcp14> be used. If the hash-alg-id is not known, then the integer value "0" <bcp14>MUST</bcp14> be used. This allows for conversion from ISO SWID tags <xref target="SWID"/>, which do not allow an algorithm to be identified for this field.</t>
          <t>The hash-value <bcp14>MUST</bcp14> represent the raw hash value as a byte string (as opposed to, e.g., for example, base64 encoded) generated from the representation of the resource using the hash algorithm indicated by hash-alg-id.</t>
        </section>
        <section anchor="model-resource-collection">
          <name>The resource-collection Group</name>
          <t>A
          <t>The resource-collection group provides a list of items both used in both evidence (created by a software discovery process) and
payload (installed in an endpoint) content of a CoSWID tag document to
structure and differentiate the content of specific CoSWID tag types. Potential
content includes directories, files, processes, or resources.</t>
          <t>The CDDL for the resource-collection group follows:</t>
          <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
path-elements-group = ( ? directory =&gt; one-or-more&lt;directory-entry&gt;,
                        ? file =&gt; one-or-more&lt;file-entry&gt;,
                      )

resource-collection = (
  path-elements-group,
  ? process =&gt; one-or-more&lt;process-entry&gt;,
  ? resource =&gt; one-or-more&lt;resource-entry&gt;,
  * $$resource-collection-extension,
)

filesystem-item = (
  ? key =&gt; bool,
  ? location =&gt; text,
  fs-name =&gt; text,
  ? root =&gt; text,
)

file-entry = {
  filesystem-item,
  ? size =&gt; uint,
  ? file-version =&gt; text,
  ? hash =&gt; hash-entry,
  * $$file-extension,
  global-attributes,
}

directory-entry = {
  filesystem-item,
  ? path-elements =&gt; { path-elements-group },
  * $$directory-extension,
  global-attributes,
}

process-entry = {
  process-name =&gt; text,
  ? pid =&gt; integer,
  * $$process-extension,
  global-attributes,
}

resource-entry = {
  type =&gt; text,
  * $$resource-extension,
  global-attributes,
}

hash = 7
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
</sourcecode>
          <t>The following list describes each member of the groups and maps illustrated above.</t>
          <ul
           <dl newline="false" spacing="normal">
            <li>filesystem-item: A
            <dt>filesystem-item:</dt><dd>A list of common items used for representing the filesystem root, relative location, name, and significance of a file or directory item.</li>
            <li>global-attributes: The item.</dd>
            <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
            <li>directory target="model-global-attributes"/>.</dd>
            <dt>hash (index 16): A directory 7):</dt><dd>Value that provides a hash of a file. This item provides an integrity measurement with respect to a specific file. See <xref target="model-hash-entry"/> for more details on the use of the hash-entry data structure.</dd>
            <dt>directory (index 16):</dt><dd>Item that allows child directory and file items to be defined within a directory hierarchy for the software component.</li>
            <li>file component.</dd>
            <dt>file (index 17): A file item 17):</dt><dd>Item that allows details about a file to be provided for the software component.</li>
            <li>process component.</dd>
            <dt>process (index 18): A process item 18):</dt><dd>Item that allows details to be provided about the runtime behavior of the software component, such as information that will appear in a process listing on an endpoint.</li>
            <li>resource endpoint.</dd>
            <dt>resource (index 19): A resource item 19):</dt><dd>Item that can be used to provide details about an artifact or capability expected to be found on an endpoint or evidence collected related to the software component. This can be used to represent concepts not addressed directly by the directory, file, or process items. Examples include: include registry keys, bound ports, etc. The equivalent construct in <xref target="SWID"/> is currently under specified. underspecified. As a result, this item might be further defined through extension extensions in the future.</li>
            <li>size future.</dd>
            <dt>size (index 20): The 20):</dt><dd>The file's size in bytes.</li>
            <li>file-version bytes.</dd>
            <dt>file-version (index 21): The 21):</dt><dd>The file's version as reported by querying information on the file from the operating system (if available). This item maps to '/SoftwareIdentity/(Payload|Evidence)/File/@version' in <xref target="SWID"/>.</li>
            <li>hash (index 7): A hash of the file as described in <xref target="model-hash-entry"/>.</li>
            <li>key target="SWID"/>.</dd>
            <dt>key (index 22): A 22):</dt><dd>A boolean value indicating if a file or directory is significant or required for the software component to execute or function properly. These are files or directories that can be used to affirmatively determine if the software component is installed on an endpoint.</li>
            <li>location endpoint.</dd>
            <dt>location (index 23): The 23):</dt><dd>The filesystem path where a file is expected to be located when installed or copied. The location <bcp14>MUST</bcp14> be either an absolute path, a path relative to the location of path value included in the parent directory item (preferred), or a path relative to the location of the CoSWID tag (as indicated in the location value in the evidence entry map) if no parent is defined. The location <bcp14>MUST NOT</bcp14> include a file's name, which is provided by the fs-name item.</li>
            <li>fs-name item.</dd>
            <dt>fs-name (index 24): The 24):</dt><dd>The name of the directory or file without any path information. This aligns with a file "name" in <xref target="SWID"/>. This item maps to '/SoftwareIdentity/(Payload|Evidence)/(File|Directory)/@name' in <xref target="SWID"/>.</li>
            <li>root target="SWID"/>.</dd>
            <dt>root (index 25): A 25):</dt><dd>A host-specific name for the root of the filesystem. The location item is considered relative to this location if specified. If not provided, the value provided by the location item is expected to be relative to its parent or the location of the CoSWID tag if no parent is provided.</li>
            <li>path-elements provided.</dd>
            <dt>path-elements (index 26): This group 26):</dt><dd>Group that allows a hierarchy of directory and file items to be defined in payload or evidence items. This is a construction within the CDDL definition of CoSWID to support shared syntax and does not appear in <xref target="SWID"/>.</li>
            <li>process-name target="SWID"/>.</dd>
            <dt>process-name (index 27): The 27):</dt><dd>The software component's process name as it will appear in an endpoint's process list. This aligns with a process "name" in <xref target="SWID"/>. This item maps to '/SoftwareIdentity/(Payload|Evidence)/Process/@name' in <xref target="SWID"/>.</li>
            <li>pid target="SWID"/>.</dd>
            <dt>pid (index 28): The 28):</dt><dd>The process ID identified for a running instance of the software component in the endpoint's process list. This is used as part of the evidence item.</li>
            <li>type item.</dd>
            <dt>type (index 29): A 29):</dt><dd>A human-readable string indicating the type of resource.</li>
            <li>$$resource-collection-extension: This resource.</dd>
            <dt>$$resource-collection-extension:</dt><dd>A CDDL socket that can be used to extend the resource-collection group model. This can be used to add new specialized types of resources. See <xref target="model-extension"/>.</li>
            <li>$$file-extension: This target="model-extension"/>.</dd>
            <dt>$$file-extension:</dt><dd>A CDDL socket that can be used to extend the file-entry group model. See <xref target="model-extension"/>.</li>
            <li>$$directory-extension: This target="model-extension"/>.</dd>
            <dt>$$directory-extension:</dt><dd>A CDDL socket that can be used to extend the directory-entry group model. See <xref target="model-extension"/>.</li>
            <li>$$process-extension: This target="model-extension"/>.</dd>
            <dt>$$process-extension:</dt><dd>A CDDL socket that can be used to extend the process-entry group model. See <xref target="model-extension"/>.</li>
            <li>$$resource-extension: This target="model-extension"/>.</dd>
            <dt>$$resource-extension:</dt><dd>A CDDL socket that can be used to extend the resource-entry group model. See <xref target="model-extension"/>.</li>
          </ul> target="model-extension"/>.</dd>
	   </dl>
        </section>
        <section anchor="model-payload">
          <name>The payload-entry Map</name>
          <t>The CDDL for the payload-entry map follows:</t>
          <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
payload-entry = {
  resource-collection,
  * $$payload-extension,
  global-attributes,
}
</sourcecode>
          <t>The following list describes each child item of this group.</t>
          <ul
           <dl newline="false" spacing="normal">
            <li>global-attributes: The
            <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
            <li>resource-collection: The target="model-global-attributes"/>.</dd>
            <dt>resource-collection:</dt><dd>The resource-collection group as described in <xref target="model-resource-collection"/>.</li>
            <li>$$payload-extension: This target="model-resource-collection"/>.</dd>
            <dt>$$payload-extension:</dt><dd>A CDDL socket that can be used to extend the payload-entry group model. See <xref target="model-extension"/>.</li>
          </ul> target="model-extension"/>.</dd>
	   </dl>
        </section>
        <section anchor="model-evidence">
          <name>The evidence-entry Map</name>
          <t>The CDDL for the evidence-entry map follows:</t>
          <sourcecode type="CDDL"> type="cddl" name="coswid-exposition.cddl">
evidence-entry = {
  resource-collection,
  ? date =&gt; integer-time,
  ? device-id =&gt; text,
  ? location =&gt; text,
  * $$evidence-extension,
  global-attributes,
}

date = 35
device-id = 36
</sourcecode>
          <t>The following list describes each child item of this group.</t>
          <ul
           <dl newline="false" spacing="normal">
            <li>global-attributes: The
            <dt>global-attributes:</dt><dd>The global-attributes group as described in <xref target="model-global-attributes"/>.</li>
            <li>resource-collection: The target="model-global-attributes"/>.</dd>
            <dt>resource-collection:</dt><dd>The resource-collection group as described in <xref target="model-resource-collection"/>.</li>
            <li>date target="model-resource-collection"/>.</dd>
            <dt>location (index 35): The 23):</dt><dd>The filesystem path of the location of the CoSWID tag generated as evidence. This path is always an absolute file path (unlike the value of a location item found within a filesystem-item as described
in <xref target="model-resource-collection"/>, which can be either a relative path or an absolute path).</dd>
            <dt>date (index 35):</dt><dd>The date and time the information was collected pertaining to the evidence item in Epoch-Based Date/Time epoch-based date/time format as specified in <xref section="3.4.2" sectionFormat="of" target="RFC8949"/>.</li>
            <li>device-id target="RFC8949"/>.</dd>
            <dt>device-id (index 36): The 36):</dt><dd>The endpoint's string identifier from which the evidence was collected.</li>
            <li>location (index 23): The absolute filepath of the location of the CoSWID tag generated as evidence.
(Location values in filesystem-items in the payload can be expressed relative to this location.)</li>
            <li>$$evidence-extension:  This collected.</dd>
            <dt>$$evidence-extension:</dt><dd> A CDDL socket that can be used to extend the evidence-entry group model. See <xref target="model-extension"/>.</li>
          </ul> target="model-extension"/>.</dd>
	   </dl>
        </section>
      </section>
      <section anchor="full-cddl-specification">
        <name>Full CDDL Specification</name>
        <t>In order to create a valid CoSWID document document, the structure of the corresponding CBOR message <bcp14>MUST</bcp14>
adhere to the following CDDL specification.</t>
        <sourcecode type="CDDL" type="cddl" name="concise-swid-tag.cddl" markers="true">
concise-swid-tag = {
  tag-id =&gt; text / bstr .size 16,
  tag-version =&gt; integer,
  ? corpus =&gt; bool,
  ? patch =&gt; bool,
  ? supplemental =&gt; bool,
  software-name =&gt; text,
  ? software-version =&gt; text,
  ? version-scheme =&gt; $version-scheme,
  ? media =&gt; text,
  ? software-meta =&gt; one-or-more&lt;software-meta-entry&gt;,
  entity =&gt; one-or-more&lt;entity-entry&gt;,
  ? link =&gt; one-or-more&lt;link-entry&gt;,
  ? payload-or-evidence,
  * $$coswid-extension,
  global-attributes,
}

payload-or-evidence //= ( payload =&gt; payload-entry )
payload-or-evidence //= ( evidence =&gt; evidence-entry )

any-uri = uri
label = text / int

$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= int / text

any-attribute = (
  label =&gt; one-or-more&lt;text&gt; / one-or-more&lt;int&gt;
)

one-or-more&lt;T&gt; = T / [ 2* T ]

global-attributes = (
  ? lang =&gt; text,
  * any-attribute,
)

hash-entry = [
  hash-alg-id: int,
  hash-value: bytes,
]

entity-entry = {
  entity-name =&gt; text,
  ? reg-id =&gt; any-uri,
  role =&gt; one-or-more&lt;$role&gt;,
  ? thumbprint =&gt; hash-entry,
  * $$entity-extension,
  global-attributes,
}

$role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= maintainer
$role /= int / text

link-entry = {
  ? artifact =&gt; text,
  href =&gt; any-uri,
  ? media =&gt; text,
  ? ownership =&gt; $ownership,
  rel =&gt; $rel,
  ? media-type =&gt; text,
  ? use =&gt; $use,
  * $$link-extension,
  global-attributes,
}

$ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= int / text

$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= supplemental
$rel /= -256..64436 -256..65536 / text

$use /= optional
$use /= required
$use /= recommended
$use /= int / text

software-meta-entry = {
  ? activation-status =&gt; text,
  ? channel-type =&gt; text,
  ? colloquial-version =&gt; text,
  ? description =&gt; text,
  ? edition =&gt; text,
  ? entitlement-data-required =&gt; bool,
  ? entitlement-key =&gt; text,
  ? generator =&gt; text / bstr .size 16,
  ? persistent-id =&gt; text,
  ? product =&gt; text,
  ? product-family =&gt; text,
  ? revision =&gt; text,
  ? summary =&gt; text,
  ? unspsc-code =&gt; text,
  ? unspsc-version =&gt; text,
  * $$software-meta-extension,
  global-attributes,
}

path-elements-group = ( ? directory =&gt; one-or-more&lt;directory-entry&gt;,
                        ? file =&gt; one-or-more&lt;file-entry&gt;,
                      )

resource-collection = (
  path-elements-group,
  ? process =&gt; one-or-more&lt;process-entry&gt;,
  ? resource =&gt; one-or-more&lt;resource-entry&gt;,
  * $$resource-collection-extension,
)

file-entry = {
  filesystem-item,
  ? size =&gt; uint,
  ? file-version =&gt; text,
  ? hash =&gt; hash-entry,
  * $$file-extension,
  global-attributes,
}

directory-entry = {
  filesystem-item,
  ? path-elements =&gt; { path-elements-group },
  * $$directory-extension,
  global-attributes,
}

process-entry = {
  process-name =&gt; text,
  ? pid =&gt; integer,
  * $$process-extension,
  global-attributes,
}

resource-entry = {
  type =&gt; text,
  * $$resource-extension,
  global-attributes,
}

filesystem-item = (
  ? key =&gt; bool,
  ? location =&gt; text,
  fs-name =&gt; text,
  ? root =&gt; text,
)

payload-entry = {
  resource-collection,
  * $$payload-extension,
  global-attributes,
}

evidence-entry = {
  resource-collection,
  ? date =&gt; integer-time,
  ? device-id =&gt; text,
  ? location =&gt; text,
  * $$evidence-extension,
  global-attributes,
}

integer-time = #6.1(int)

; "global map member" integer indexes indices
tag-id = 0
software-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
hash = 7
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14
lang = 15
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
entity-name = 31
reg-id = 32
role = 33
thumbprint = 34
date = 35
device-id = 36
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42
activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57

; "version-scheme" integer indexes indices
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384

; "role" integer indexes indices
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
maintainer=6

; "ownership" integer indexes indices
abandon=1
private=2
shared=3

; "rel" integer indexes indices
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
; supplemental=11 ; this is already defined earlier

; "use" integer indexes indices
optional=1
required=2
recommended=3
</sourcecode>
      </section>
    </section>
    <section anchor="semantics-tag-type">
      <name>Determining the Type of CoSWID</name>
      <t>The operational model for SWID and CoSWID tags was introduced in <xref target="intro-lifecycle"/>, which described four different CoSWID tag types. The following additional rules apply to the use of CoSWID tags to ensure that created tags properly identify the tag type.</t>
      <t>The first matching rule <bcp14>MUST</bcp14> determine the type of the CoSWID tag.</t>
      <ol spacing="normal" type="1">
        <li>Primary Tag: A
      <dl newline="false" spacing="normal">
        <dt>Primary Tag:</dt><dd>A CoSWID tag <bcp14>MUST</bcp14> be considered a primary tag if the corpus, patch, and supplemental items are "false".</li>
        <li>Supplemental Tag: A "false".</dd>
        <dt>Supplemental Tag:</dt><dd>A CoSWID tag <bcp14>MUST</bcp14> be considered a supplemental tag if the supplemental item is set to "true".</li>
        <li>Corpus Tag: A "true".</dd>
        <dt>Corpus Tag:</dt><dd>A CoSWID tag <bcp14>MUST</bcp14> be considered a corpus tag if the corpus item is "true".</li>
        <li>Patch Tag: A "true".</dd>
        <dt>Patch Tag:</dt><dd>A CoSWID tag <bcp14>MUST</bcp14> be considered a patch tag if the patch item is "true".</li>
      </ol>
      <t>Note: Multiple "true".</dd>
      </dl>
      <aside><t>Note: It is possible for some or all of the corpus, patch, and supplemental items can to simultaneously have values set as "true". The rules above provide a means to determine the tag's type in such a case. For example, a SWID or CoSWID tag for a patch installer might have both corpus and patch items set to "true". In such a case, the tag is a "Corpus Tag". "corpus tag". The tag installed by this installer would have only the patch item set to "true", making the installed tag type a "Patch Tag".</t> "patch tag".</t></aside>
    </section>
    <section anchor="coswid-indexed-label-values">
      <name>CoSWID Indexed Label Values</name>
      <t>This section defines a number of multiple kinds of indexed label values that are maintained in a registry each (<xref target="iana"/>). several IANA registries. See <xref target="iana"/> for details.
These values are represented as positive integers.  In each registry, the value 0 is marked as Reserved.</t>
      <section anchor="indexed-version-scheme">
        <name>Version Scheme</name>
        <t>The following table contains a set of values for use in the concise-swid-tag group's version-scheme item. Version Scheme Name strings match the version schemes defined in the ISO/IEC 19770-2:2015 <xref target="SWID"/> specification. Index The "Index" value indicates the value to use as the version-scheme item's value. The Version Strings in the "Version Scheme Name provides Name" column provide human-readable text for the value. value and match the version schemes defined in the ISO/IEC 19770-2:2015 specification <xref target="SWID"/>. The Definition "Definition" column describes the syntax of allowed values for each entry.</t>

        <table anchor="tbl-indexed-version-scheme-values">
          <name>Version Scheme Values</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Version Scheme Name</th>
              <th align="left">Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">multipartnumeric</td>
              <td align="left">Numbers separated by dots, where the numbers are interpreted as decimal integers (e.g., 1.2.3, 1.2.3.4.5.6.7, 1.4.5, 1.21)</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">multipartnumeric+suffix</td>
              <td align="left">Numbers separated by dots, where the numbers are interpreted as decimal integers with an additional textual suffix (e.g., 1.2.3a)</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">alphanumeric</td>
              <td align="left">Strictly a string, no interpretation as number</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">decimal</td>
              <td align="left">A single decimal floating point floating-point number</td>
            </tr>
            <tr>
              <td align="left">16384</td>
              <td align="left">semver</td>
              <td align="left">A semantic version as defined by <xref target="SWID"/>. Also see the <xref target="SEMVER"/> specification for more information</td>
            </tr>
          </tbody>
        </table>
        <t>multipartnumeric
        <t>"multipartnumeric" and the numbers part of multipartnumeric+suffix "multipartnumeric+suffix" are interpreted as a sequence of numbers and are sorted in lexicographical order by these numbers (i.e., not by the digits in the numbers) and then the textual suffix (for multipartnumeric+suffix).  Alphanumeric "multipartnumeric+suffix").  "alphanumeric" strings are sorted lexicographically as character strings.  Decimal  "decimal" version numbers are interpreted as a single floating point number floating-point numbers (e.g., 1.25 is less than 1.3).</t>
        <t>The values above are registered in the IANA "Software ID Version Scheme Values" registry registry, defined in <xref target="iana-version-scheme"/>. Additional entries will likely be registered over time in this registry.</t>
        <t>A CoSWID producer that is aware of the version scheme that has been used to select the version value, value <bcp14>SHOULD</bcp14> include the optional version-scheme item to avoid semantic ambiguity.
If the CoSWID producer does not have this information, it <bcp14>SHOULD</bcp14> omit the version-scheme item.
The following heuristics can be used by a CoSWID consumer, based on the version schemes' partially overlapping value spaces:</t>
        <ul spacing="normal">
          <li>"decimal" and "multipartnumeric" partially overlap in their value space when a value matches a decimal number. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the "decimal" version scheme is used.</li>
          <li>"multipartnumeric" and "semver" partially overlap in their value space when a "multipartnumeric" value matches the semantic versioning syntax. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the "semver" version scheme is used.</li>
          <li>"alphanumeric" and other version schemes might overlap in their value space. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the other version scheme is used and "alphanumeric" is not used.</li>
        </ul>
        <t>Note that these heuristics are imperfect and can guess wrong, which is the reason the version-scheme item <bcp14>SHOULD</bcp14> be included by the producer.</t>
      </section>
      <section anchor="indexed-entity-role">
        <name>Entity Role Values</name>
        <t>The following table indicates the index value to use for the entity-entry group's role item (see <xref target="model-entity"/>). These values match the entity roles defined in the ISO/IEC 19770-2:2015 specification <xref target="SWID"/> specification. target="SWID"/>. The "Index" value indicates the value to use as the role item's value. The Items in the "Role Name" provides column provide human-readable text for the value. The "Definition" column describes the semantic meaning of each entry.</t>

        <table anchor="tbl-indexed-entity-role-values">
          <name>Entity Role Values</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Role Name</th>
              <th align="left">Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">tagCreator</td>
              <td align="left">The person or organization that created the containing SWID or CoSWID tag</td> tag.</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">softwareCreator</td>
              <td align="left">The person or organization entity that created the software component.</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">aggregator</td>
              <td align="left">From <xref target="SWID"/>, "An organization or system that encapsulates software from their own and/or other organizations into a different distribution process (as in the case of virtualization), or as a completed system to accomplish a specific task (as in the case of a value added reseller)."</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">distributor</td>
              <td align="left">From <xref target="SWID"/>, "An entity that furthers the marketing, selling and/or distribution of software from the original place of manufacture to the ultimate user without modifying the software, its packaging or its labelling."</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">licensor</td>
              <td align="left">From <xref target="SAM"/> target="SAM"/>, as a "software licensor", a "person or organization who owns or holds the rights to issue a software license for a specific software [component]"</td> [component]."</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">maintainer</td>
              <td align="left">The person or organization that is responsible for coordinating and making updates to the source code for the software component. This <bcp14>SHOULD</bcp14> be used when the "maintainer" is a different person or organization than the original "softwareCreator".</td>
            </tr>
          </tbody>
        </table>

	<t>The values above are registered in the IANA "Software ID Entity Role Values" registry registry, defined in <xref target="iana-entity-role"/>. Additional values will likely be registered over time.</t>
      </section>
      <section anchor="indexed-link-ownership">
        <name>Link Ownership Values</name>
        <t>The following table indicates the index value to use for the link-entry group's ownership item (see <xref target="model-link"/>). These values match the link ownership values defined in the ISO/IEC 19770-2:2015 specification <xref target="SWID"/> specification. target="SWID"/>. The "Index" value indicates the value to use as the link-entry group ownership item's value. The Items in the "Ownership Type" provides column provide human-readable text for the value. The "Definition" column describes the semantic meaning of each entry.</t>
        <table anchor="tbl-indexed-link-ownership-values">
          <name>Link Ownership Values</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Ownership Type</th>
              <th align="left">Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">abandon</td>
              <td align="left">If the software component referenced by the CoSWID tag is uninstalled, then the referenced software <bcp14>SHOULD NOT</bcp14> be uninstalled</td> uninstalled.</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">private</td>
              <td align="left">If the software component referenced by the CoSWID tag is uninstalled, then the referenced software <bcp14>SHOULD</bcp14> be uninstalled as well.</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">shared</td>
              <td align="left">If the software component referenced by the CoSWID tag is uninstalled, then the referenced software <bcp14>SHOULD</bcp14> be uninstalled if no other components are sharing the software.</td>
            </tr>
          </tbody>
        </table>
        <t>The values above are registered in the IANA "Software ID Link Ownership Values" registry registry, defined in <xref target="iana-link-ownership"/>. Additional values will likely be registered over time.</t>
      </section>
      <section anchor="indexed-link-rel">
        <name>Link Rel Values</name>
        <t>The following table indicates the index value to use for the link-entry group's rel item (see <xref target="model-link"/>). These values match the link rel values defined in the ISO/IEC 19770-2:2015 specification <xref target="SWID"/> specification. target="SWID"/>. The "Index" value indicates the value to use as the link-entry group ownership item's value. The Items in the "Relationship Type" provides column provide human-readable text for the value. The "Definition" column describes the semantic meaning of each entry.</t>
        <table anchor="tbl-indexed-link-rel-values">
          <name>Link Relationship Values</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Relationship Type</th>
              <th align="left">Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">ancestor</td>
              <td align="left">The link references a software tag for a previous release of this software. This can be useful to define an upgrade path.</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">component</td>
              <td align="left">The link references a software tag for a separate component of this software.</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">feature</td>
              <td align="left">The link references a configurable feature of this software that can be enabled or disabled without changing the installed files.</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">installationmedia</td>
              <td align="left">The link references the installation package that can be used to install this software.</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">packageinstaller</td>
              <td align="left">The link references the installation software needed to install this software.</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">parent</td>
              <td align="left">The link references a software tag that is the parent of the referencing tag. This relationship can be used when multiple software components are part of a software bundle, where the "parent" is the software tag for the bundle, bundle and each child is a "component". In such a case, each child component can provide a "parent" link relationship to the bundle's software tag, and the bundle can provide a "component" link relationship to each child software component.</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">patches</td>
              <td align="left">The link references a software tag that the referencing software patches. Typically only used for patch tags (see <xref target="intro-lifecycle"/>).</td>
            </tr>
            <tr>
              <td align="left">8</td>
              <td align="left">requires</td>
              <td align="left">The link references a prerequisite for installing this software. A patch tag (see <xref target="intro-lifecycle"/>) can use this to represent base software or another patch that needs to be installed first.</td>
            </tr>
            <tr>
              <td align="left">9</td>
              <td align="left">see-also</td>
              <td align="left">The link references other software that may be of interest that relates to this software.</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">supersedes</td>
              <td align="left">The link references another other software (e.g., an older software version) that this software replaces. A patch tag (see <xref target="intro-lifecycle"/>) can use this to represent another patch that this patch incorporates or replaces.</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">supplemental</td>
              <td align="left">The link references a software tag that the referencing tag supplements. Used on supplemental tags (see <xref target="intro-lifecycle"/>).</td>
            </tr>
          </tbody>
        </table>
        <t>The values above are registered in the IANA "Software ID Link Relationship Values" registry registry, defined in <xref target="iana-link-rel"/>. Additional values will likely be registered over time.</t>
      </section>
      <section anchor="indexed-link-use">
        <name>Link Use Values</name>
        <t>The following table indicates the index value to use for the link-entry group's use item (see <xref target="model-link"/>). These values match the link use values defined in the ISO/IEC 19770-2:2015 specification <xref target="SWID"/> specification. target="SWID"/>. The "Index" value indicates the value to use as the link-entry group use item's value. The Items in the "Use Type" provides column provide human-readable text for the value. The "Definition" column describes the semantic meaning of each entry.</t>

        <table anchor="tbl-indexed-link-use-values">
          <name>Link Use Values</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Use Type</th>
              <th align="left">Definition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">optional</td>
              <td align="left">From <xref target="SWID"/>, "Not absolutely required; the [Link]'d software is installed only when specified."</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">required</td>
              <td align="left">From <xref target="SWID"/>, "The [Link]'d software is absolutely required for an operation software installation."</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">recommended</td>
              <td align="left">From <xref target="SWID"/>, "Not absolutely required; the [Link]'d software is installed unless specified otherwise."</td>
            </tr>
          </tbody>
        </table>
        <t>The values above are registered in the IANA "Software ID Link Use Values" registry registry, defined in <xref target="iana-link-use"/>. Additional values will likely be registered over time.</t>
      </section>
    </section>
    <section anchor="uri-schemes">
      <name>URI Schemes</name>
      <name>"swid" and "swidpath" Expressions</name>
      <t>This specification defines the following URI schemes scheme names for use in CoSWID and to provide interoperability with schemes scheme names used in <xref target="SWID"/>.</t>
      <t>Note: These URI schemes target="SWID"/>.
Because both the "swid" and "swidpath" scheme names are used to be interpreted within a local (rather than a global) context, neither of these are technically URI scheme names as defined in <xref target="SWID"/> without an target="RFC3986"/>.
For this reason, the "swid" and "swidpath" scheme names are registered with IANA registration.
The present specification as provisional, rather than permanent, scheme names.
However, registering these scheme names as provisional ensures that these URI schemes the scheme names are reserved and that they are properly defined going forward.</t>
      <t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please replace
RFC-AAAA with the RFC number of this specification
      <t>The swid and remove this
note.</cref></t>
      <section anchor="uri-scheme-swid">
        <name>"swid" URI Scheme</name>
        <t>There is a need swidpath expressions conform to all rules for URI syntax.
All uses of these expressions encountered within a scheme name that can be used in URIs that point CoSWID are to a specific software tag by that tag's tag-id, such as the use of the link entry be interpreted as described in <xref target="model-link"/>. Since this scheme is used both in a standards track document and an ISO standard, this scheme needs to be used without fear of conflicts with current or future actual schemes.  In <xref target="swid-reg"/>, the scheme "swid" is registered as a 'permanent' scheme for that purpose.</t>
        <t>URIs section.</t>
      <section anchor="uri-scheme-swid">
        <name>"swid" Expressions</name>
        <t>Expressions specifying the "swid" scheme are used to reference a software tag by its tag-id. A tag-id referenced in this way can be used to identify the tag resource in the context of where it is referenced from. For example, when a tag is installed on a given device, that tag can reference related tags on the same device using URIs expressions with this scheme.</t>
        <t>For URIs expressions that use the "swid" scheme, the scheme specific scheme-specific part <bcp14>MUST</bcp14> consist of a referenced software tag's tag-id. This tag-id <bcp14>MUST</bcp14> be URI encoded according to <xref section="2.1" sectionFormat="of" target="RFC3986"/>.</t>
        <t>The following expression is a valid example:</t>
        <artwork><![CDATA[
swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c
]]></artwork>
      </section>
      <section anchor="uri-scheme-swidpath">
        <name>"swidpath" URI Scheme</name>
        <t>There is a need for a scheme name that can be used in URIs to identify a collection of specific software tags with data elements that match an XPath expression, such as the use of the link entry as described in <xref target="model-link"/>.
The scheme named "swidpath" is used for this purpose in <xref target="SWID"/>, but not registered.
To enable usage without fear of conflicts with current or future actual schemes, the present document registers it as a
'permanent' scheme for that purpose (see <xref target="swidpath-reg"/>).</t>
        <t>URIs Expressions</name>
        <t>Expressions specifying the "swidpath" scheme are used to filter tags out of a base collection, so that matching tags are included in the identified tag collection.
The XPath expression <xref target="W3C.REC-xpath20-20101214"/> references the data that must be found in a given software tag out of the base collection for that tag to be considered a matching tag.
Tags to be evaluated (the base collection) include all tags in the context of where the "swidpath URI" "swidpath" expression is referenced from.
For example, when a tag is installed on a given device, that tag can reference related tags on the same device using a URI an expression with this scheme.</t>
        <t>For URIs that use the "swidpath" scheme, the following requirements apply:</t>
        <ul spacing="normal">
          <li>The scheme specific scheme-specific part <bcp14>MUST</bcp14> be an XPath expression as defined by <xref target="W3C.REC-xpath20-20101214"/>. The included XPath expression will be URI encoded according to <xref section="2.1" sectionFormat="of" target="RFC3986"/>.</li>
          <li>This XPath is evaluated over SWID tags, or COSWID CoSWID tags transformed into SWID tags, found on a system. A given tag <bcp14>MUST</bcp14> be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to <xref target="W3C.REC-xpath20-20101214"/>, Section 2.4.3.</li>
        </ul>
        <!-- In other words: If SWID tags were cars, the XPath says "automatic
transmission" and yields a set of cars. -->
</section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has a number of IANA considerations, as described in
the following subsections. In summary, 6 six new registries are established with by this request, document, with initial entries provided for each registry. New values for 5 five other registries are also requested.</t> defined.</t>
      <section anchor="iana-coswid-items">
        <name>CoSWID Items Registry</name>
        <t>This document defines a new registry titled
"CoSWID Items". This registry uses integer values as index values in CBOR maps.</t>
        <t>This document defines a new registry titled
"CoSWID Items". maps. Future registrations for this registry are to be made based on <xref target="BCP26"/> target="RFC8126"/> as follows:</t>
        <table anchor="tbl-iana-coswid-items-reg-procedures">
          <name>CoSWID Items Registration Procedures</name>
          <thead>
            <tr>
              <th align="left">Range</th>
              <th align="left">Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0-32767</td>
              <td align="left">Standards Action with Expert Review</td>
            </tr>
            <tr>
              <td align="left">32768-4294967295</td>
              <td align="left">Specification Required</td>
            </tr>
          </tbody>
        </table>
        <t>All negative values are reserved for Private Use.</t> private use.</t>
        <t>Initial registrations for the "CoSWID Items" registry
are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification.</t>
        <table anchor="tbl-iana-coswid-items-values">
          <name>CoSWID Items Initial Registrations</name>
          <thead>
            <tr>
              <th align="left">Index</th>
              <th align="left">Item Name</th>
              <th align="left">Specification</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">tag-id</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">software-name</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">entity</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">evidence</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">link</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">software-meta</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">payload</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">hash</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">8</td>
              <td align="left">corpus</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">9</td>
              <td align="left">patch</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">media</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">supplemental</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">12</td>
              <td align="left">tag-version</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">13</td>
              <td align="left">software-version</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">14</td>
              <td align="left">version-scheme</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">15</td>
              <td align="left">lang</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">16</td>
              <td align="left">directory</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">17</td>
              <td align="left">file</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">18</td>
              <td align="left">process</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">19</td>
              <td align="left">resource</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">20</td>
              <td align="left">size</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">21</td>
              <td align="left">file-version</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">22</td>
              <td align="left">key</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">23</td>
              <td align="left">location</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">24</td>
              <td align="left">fs-name</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">25</td>
              <td align="left">root</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">26</td>
              <td align="left">path-elements</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">27</td>
              <td align="left">process-name</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">28</td>
              <td align="left">pid</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">29</td>
              <td align="left">type</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">30</td>
              <td align="left">Unassigned</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">31</td>
              <td align="left">entity-name</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">32</td>
              <td align="left">reg-id</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">33</td>
              <td align="left">role</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">34</td>
              <td align="left">thumbprint</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">35</td>
              <td align="left">date</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">36</td>
              <td align="left">device-id</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">37</td>
              <td align="left">artifact</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">38</td>
              <td align="left">href</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">39</td>
              <td align="left">ownership</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">40</td>
              <td align="left">rel</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">41</td>
              <td align="left">media-type</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">42</td>
              <td align="left">use</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">43</td>
              <td align="left">activation-status</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">44</td>
              <td align="left">channel-type</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">45</td>
              <td align="left">colloquial-version</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">46</td>
              <td align="left">description</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">47</td>
              <td align="left">edition</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">48</td>
              <td align="left">entitlement-data-required</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">49</td>
              <td align="left">entitlement-key</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">50</td>
              <td align="left">generator</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">51</td>
              <td align="left">persistent-id</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">52</td>
              <td align="left">product</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">53</td>
              <td align="left">product-family</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">54</td>
              <td align="left">revision</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">55</td>
              <td align="left">summary</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">56</td>
              <td align="left">unspsc-code</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">57</td>
              <td align="left">unspsc-version</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
            <tr>
              <td align="left">58-4294967295</td>
              <td align="left">Unassigned</td>
              <td align="left">&nbsp;</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="iana-value-registries">
        <name>Software
        <name>Registries for Software ID Values Registries</name> Values</name>
        <t>The following IANA registries provide a mechanism for new values to be added over time to common enumerations used by SWID and CoSWID. While neither the CoSWID specification nor the SWID specification is subordinate to the other and will evolve as their respective standards group chooses, there is value in supporting alignment between the two standards. Shared use of common code points, as spelled out in these registries, will facilitate this alignment, alignment -- hence the intent for shared use of these registries and the decision to use "swidsoftware-id" (rather than "swid" or "coswid") in registry names.</t>
        <section anchor="iana-registration-procedures">
          <name>Registration Procedures</name>
          <t>The following registries allow for the registration of index values and names. New registrations will be permitted through either a Standards Action with Expert Review policy or a Specification Required policy <xref target="BCP26"/>.</t> target="RFC8126"/>.</t>
          <t>The following registries also reserve the integer-based index values in the range of -1 to -256 for private use as defined by <xref section="4.1" sectionFormat="of" target="BCP26"/>. target="RFC8126"/>. This allows values -1 to -24 to be expressed as a single uint_8t uint8_t in CBOR, CBOR and values -25 to -256 to be expressed using an additional uint_8t uint8_t in CBOR.</t>
        </section>
        <section anchor="iana-private-use">
          <name>Private Use of Index and Name Values</name>
          <t>The integer-based index values in the private use range (-1 to -256) are intended for testing purposes and closed environments; values in other ranges <bcp14>SHOULD NOT</bcp14> be assigned for testing.</t>
          <t>For names that correspond to private use index values, an Internationalized Domain Name prefix <bcp14>MUST</bcp14> be used to prevent name conflicts using the form:</t> form</t>
          <artwork><![CDATA[
domainprefix/name
]]></artwork>
          <t>Where
          <t>where both "domainprefix" and "name" <bcp14>MUST</bcp14> each be either an NR-LDH a Non-Reserved LDH (NR-LDH) label or a U-label as defined by <xref target="RFC5890"/>, and "name" also <bcp14>MUST</bcp14> be a unique name within the namespace defined by the "domainprefix". Use of ("LDH" is an abbreviation for "letters, digits, hyphen".) Using a prefix in this way allows for a name to be used in the private use range. This is consistent with the guidance in <xref target="BCP178"/>.</t> target="RFC6648"/>.</t>
        </section>
        <section anchor="iana-review-criteria">
          <name>Expert Review Criteria</name>
          <t>Designated experts <bcp14>MUST</bcp14> ensure that new registration requests meet the following additional criteria:</t>
          <ul spacing="normal">
            <li>The requesting specification <bcp14>MUST</bcp14> provide a clear semantic definition for the new entry. This definition <bcp14>MUST</bcp14> clearly differentiate the requested entry from other previously registered entries.</li>
            <li>The requesting specification <bcp14>MUST</bcp14> describe the intended use of the entry, including any co-constraints that exist between the (1)&nbsp;the use of the entry's index value or name, name and other (2)&nbsp;other values defined within the SWID/CoSWID model.</li>
            <li>Index values and names outside the private use space <bcp14>MUST NOT</bcp14> be used without registration. This is considered squatting "squatting" and <bcp14>MUST</bcp14> be avoided. Designated experts <bcp14>MUST</bcp14> ensure that reviewed specifications register all appropriate index values and names.</li>
            <li>Standards track Track documents <bcp14>MAY</bcp14> include entries registered in the range reserved for entries under the Specification Required policy. This can occur when a standards track Standards Track document provides further guidance on the use of index values and names that are in common use, use but were not registered with IANA. This situation <bcp14>SHOULD</bcp14> be avoided.</li>
            <li>All registered names <bcp14>MUST</bcp14> be valid according to the XML Schema NMTOKEN data type (see <xref target="W3C.REC-xmlschema-2-20041028"/>, Section 3.3.4). This ensures that registered names are compatible with the SWID format <xref target="SWID"/> where they are used.</li>
            <li>Registration of vanity names <bcp14>SHOULD</bcp14> be discouraged. The requesting specification <bcp14>MUST</bcp14> provide a description of how a requested name will allow for use by multiple stakeholders.</li>
          </ul>
        </section>
        <section anchor="iana-version-scheme">
          <name>Software ID Version Scheme Values Registry</name>
          <t>This document establishes a new registry titled
"Software ID Version Scheme Values". This registry provides index values for use as version-scheme item values in this document and version scheme names Version Scheme Names for use in <xref target="SWID"/>.</t>
          <t>[TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/software-id]</t>
          <t>This registry uses the registration procedures defined in <xref target="iana-registration-procedures"/> target="iana-registration-procedures"/>, with the following associated ranges:</t>
          <table anchor="tbl-iana-version-scheme-reg-procedures">
            <name>Software ID Version Scheme Registration Procedures</name>
            <thead>
              <tr>
                <th align="left">Range</th>
                <th align="left">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0-16383</td>
                <td align="left">Standards Action with Expert Review</td>
              </tr>
              <tr>
                <td align="left">16384-65535</td>
                <td align="left">Specification Required</td>
              </tr>
            </tbody>
          </table>
          <t>Assignments <bcp14>MUST</bcp14> consist of an integer Index index value, the Version Scheme Name, and a reference to the defining specification.</t>
          <t>Initial registrations for the "Software ID Version Scheme Values" registry
are provided below, which below and are derived from the textual version scheme names Version Scheme Names
defined in <xref target="SWID"/>.</t>
          <table anchor="tbl-iana-version-scheme-values">
            <name>Software ID Version Scheme Initial Registrations</name>
            <thead>
              <tr>
                <th align="left">Index</th>
                <th align="left">Version Scheme Name</th>
                <th align="left">Specification</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">Reserved</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">multipartnumeric</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-version-scheme"/></td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">multipartnumeric+suffix</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-version-scheme"/></td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">alphanumeric</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-version-scheme"/></td>
              </tr>
              <tr>
                <td align="left">4</td>
                <td align="left">decimal</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-version-scheme"/></td>
              </tr>
              <tr>
                <td align="left">5-16383</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">16384</td>
                <td align="left">semver</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-version-scheme"/></td>
              </tr>
              <tr>
                <td align="left">16385-65535</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
          <t>Registrations <bcp14>MUST</bcp14> conform to the expert review criteria defined in <xref target="iana-review-criteria"/>.</t>
          <t>Designated experts <bcp14>MUST</bcp14> also ensure that newly requested entries define a value space for the corresponding version software-version item that is unique from other previously registered entries. entries.</t>

<aside><t> Note: The initial registrations violate this requirement, requirement but are included for backwards compatibility with <xref target="SWID"/>. See also <xref target="indexed-version-scheme"/>.</t> target="indexed-version-scheme"/>.</t></aside>
        </section>
        <section anchor="iana-entity-role">
          <name>Software ID Entity Role Values Registry</name>
          <t>This document establishes a new registry titled
"Software ID Entity Role Values". This registry provides index values for use as entity-entry role item values in this document and entity role names for use in <xref target="SWID"/>.</t>
          <t>[TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/software-id]</t>
          <t>This registry uses the registration procedures defined in <xref target="iana-registration-procedures"/> target="iana-registration-procedures"/>, with the following associated ranges:</t>
          <table anchor="tbl-iana-entity-role-reg-procedures">
            <name>Software ID Entity Role Registration Procedures</name>
            <thead>
              <tr>
                <th align="left">Range</th>
                <th align="left">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0-127</td>
                <td align="left">Standards Action with Expert Review</td>
              </tr>
              <tr>
                <td align="left">128-255</td>
                <td align="left">Specification Required</td>
              </tr>
            </tbody>
          </table>
          <t>Assignments consist of an integer Index index value, a Role Name, role name, and a reference to the defining specification.</t>
          <t>Initial registrations for the "Software ID Entity Role Values" registry
are provided below, which below and are derived from the textual entity role names
defined in <xref target="SWID"/>.</t>
          <table anchor="tbl-iana-entity-role-values">
            <name>Software ID Entity Role Initial Registrations</name>
            <thead>
              <tr>
                <th align="left">Index</th>
                <th align="left">Role Name</th>
                <th align="left">Specification</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">Reserved</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">tagCreator</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">softwareCreator</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">aggregator</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">4</td>
                <td align="left">distributor</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">5</td>
                <td align="left">licensor</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">6</td>
                <td align="left">maintainer</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-entity-role"/></td>
              </tr>
              <tr>
                <td align="left">7-255</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
          <t>Registrations <bcp14>MUST</bcp14> conform to the expert review criteria defined in <xref target="iana-review-criteria"/>.</t>
        </section>
        <section anchor="iana-link-ownership">
          <name>Software ID Link Ownership Values Registry</name>
          <t>This document establishes a new registry titled
"Software ID Link Ownership Values". This registry provides index values for use as link-entry ownership item values in this document and link ownership names for use in <xref target="SWID"/>.</t>
          <t>[TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/software-id]</t>
          <t>This registry uses the registration procedures defined in <xref target="iana-registration-procedures"/> target="iana-registration-procedures"/>, with the following associated ranges:</t>
          <table anchor="tbl-iana-link-ownership-reg-procedures">
            <name>Software ID Link Ownership Registration Procedures</name>
            <thead>
              <tr>
                <th align="left">Range</th>
                <th align="left">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0-127</td>
                <td align="left">Standards Action with Expert Review</td>
              </tr>
              <tr>
                <td align="left">128-255</td>
                <td align="left">Specification Required</td>
              </tr>
            </tbody>
          </table>
          <t>Assignments consist of an integer Index index value, an Ownership Type Name, ownership type name, and a reference to the defining specification.</t>
          <t>Initial registrations for the "Software ID Link Ownership Values" registry
are provided below, which below and are derived from the textual entity role names
defined in <xref target="SWID"/>.</t>
          <table anchor="tbl-iana-link-ownership-values">
            <name>Software ID Link Ownership Inital Initial Registrations</name>
            <thead>
              <tr>
                <th align="left">Index</th>
                <th align="left">Ownership Type Name</th>
                <th align="left">Definition</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">Reserved</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">abandon</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-ownership"/></td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">private</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-ownership"/></td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">shared</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-ownership"/></td>
              </tr>
              <tr>
                <td align="left">4-255</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
          <t>Registrations <bcp14>MUST</bcp14> conform to the expert review criteria defined in <xref target="iana-review-criteria"/>.</t>
        </section>
        <section anchor="iana-link-rel">
          <name>Software ID Link Relationship Values Registry</name>
          <t>This document establishes a new registry titled
"Software ID Link Relationship Values". This registry provides index values for use as link-entry rel item values in this document and link ownership names for use in <xref target="SWID"/>.</t>
          <t>[TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/software-id]</t>
          <t>This registry uses the registration procedures defined in <xref target="iana-registration-procedures"/> target="iana-registration-procedures"/>, with the following associated ranges:</t>
          <table anchor="tbl-iana-link-rel-reg-procedures">
            <name>Software ID Link Relationship Registration Procedures</name>
            <thead>
              <tr>
                <th align="left">Range</th>
                <th align="left">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0-32767</td>
                <td align="left">Standards Action with Expert Review</td>
              </tr>
              <tr>
                <td align="left">32768-65535</td>
                <td align="left">Specification Required</td>
              </tr>
            </tbody>
          </table>
          <t>Assignments consist of an integer Index index value, the Relationship Type Name, relationship type name, and a reference to the defining specification.</t>
          <t>Initial registrations for the "Software ID Link Relationship Values" registry are provided below, which below and are derived from the link relationship values
defined in <xref target="SWID"/>.</t>
          <table anchor="tbl-iana-link-rel-values">
            <name>Software ID Link Relationship Initial Registrations</name>
            <thead>
              <tr>
                <th align="left">Index</th>
                <th align="left">Relationship Type Name</th>
                <th align="left">Specification</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">Reserved</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">ancestor</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">component</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">feature</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">4</td>
                <td align="left">installationmedia</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">5</td>
                <td align="left">packageinstaller</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">6</td>
                <td align="left">parent</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">7</td>
                <td align="left">patches</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">8</td>
                <td align="left">requires</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">9</td>
                <td align="left">see-also</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">10</td>
                <td align="left">supersedes</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">11</td>
                <td align="left">supplemental</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-rel"/></td>
              </tr>
              <tr>
                <td align="left">12-65535</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
          <t>Registrations <bcp14>MUST</bcp14> conform to the expert review criteria defined in <xref target="iana-review-criteria"/>.</t>
          <t>Designated experts <bcp14>MUST</bcp14> also ensure that a newly requested entry documents the URI schemes allowed to be used in an href associated with the link relationship and the expected resolution behavior of these URI schemes. This will help to ensure that applications processing software tags are able to interoperate when resolving resources referenced by a link of a given type.</t>
        </section>
        <section anchor="iana-link-use">
          <name>Software ID Link Use Values Registry</name>
          <t>This document establishes a new registry titled
"Software ID Link Use Values". This registry provides index values for use as link-entry use item values in this document and link use names for use in <xref target="SWID"/>.</t>
          <t>[TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/software-id]</t>
          <t>This registry uses the registration procedures defined in <xref target="iana-registration-procedures"/> target="iana-registration-procedures"/>, with the following associated ranges:</t>
          <table anchor="tbl-iana-link-use-reg-procedures">
            <name>Software ID Link Use Registration Procedures</name>
            <thead>
              <tr>
                <th align="left">Range</th>
                <th align="left">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0-127</td>
                <td align="left">Standards Action with Expert Review</td>
              </tr>
              <tr>
                <td align="left">128-255</td>
                <td align="left">Specification Required</td>
              </tr>
            </tbody>
          </table>
          <t>Assignments consist of an integer Index index value, the Link Use Type Name, link use type name, and a reference to the defining specification.</t>
          <t>Initial registrations for the "Software ID Link Use Values" registry
are provided below, which below and are derived from the link relationship values
defined in <xref target="SWID"/>.</t>
          <table anchor="tbl-iana-link-use-values">
            <name>Software ID Link Use Initial Registrations</name>
            <thead>
              <tr>
                <th align="left">Index</th>
                <th align="left">Link Use Type Name</th>
                <th align="left">Specification</th> align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">0</td>
                <td align="left">Reserved</td>
                <td align="left">&nbsp;</td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">optional</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-use"/></td>
              </tr>
              <tr>
                <td align="left">2</td>
                <td align="left">required</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-use"/></td>
              </tr>
              <tr>
                <td align="left">3</td>
                <td align="left">recommended</td>
                <td align="left">See align="left">RFC 9393, <xref target="indexed-link-use"/></td>
              </tr>
              <tr>
                <td align="left">4-255</td>
                <td align="left">Unassigned</td>
                <td align="left">&nbsp;</td>
              </tr>
            </tbody>
          </table>
          <t>Registrations <bcp14>MUST</bcp14> conform to the expert review criteria defined in <xref target="iana-review-criteria"/>.</t>
        </section>
      </section>
      <section anchor="swidcbor-media-type-registration">
        <name>swid+cbor Media Type Registration</name>
        <t>IANA is requested to add has added the following to the IANA "Media Types" registry <xref target="IANA.media-types"/>.</t>
        <t>Type name: application</t>
        <t>Subtype name: swid+cbor</t>
        <t>Required parameters: none</t>
        <t>Optional parameters: none</t>
        <t>Encoding considerations: Binary
        <dl newline="false" spacing="normal">
        <dt>Type name:</dt><dd>application</dd>
        <dt>Subtype name:</dt><dd>swid+cbor</dd>
        <dt>Required parameters:</dt><dd>none</dd>
        <dt>Optional parameters:</dt><dd>none</dd>
        <dt>Encoding considerations:</dt><dd>Binary (encoded as CBOR <xref target="RFC8949"/>).
See RFC-AAAA RFC 9393 for details.</t>
        <t>Security considerations: See details.</dd>
        <dt>Security considerations:</dt><dd>See <xref target="sec-sec"/> of RFC-AAAA.</t>
        <t>Interoperability considerations: Applications RFC 9393.</dd>
        <dt>Interoperability considerations:</dt><dd>Applications <bcp14>MAY</bcp14> ignore any key
value pairs that they do not understand. This allows
backwards compatible
backwards-compatible extensions to this specification.</t>
        <t>Published specification: RFC-AAAA</t>
        <t>Applications specification.</dd>
        <dt>Published specification:</dt><dd>RFC 9393</dd>
        <dt>Applications that use this media type: The type:</dt><dd>The type is used by software
asset management systems, systems and vulnerability assessment systems, systems and is used in
applications that use remote integrity verification.</t>
        <t>Fragment verification.</dd>
        <dt>Fragment Identifier Considerations: Considerations:</dt><dd> The syntax and semantics of
fragment identifiers specified for "application/swid+cbor" are as specified
for "application/cbor".  (At publication of RFC-AAAA, RFC 9393, there is no
fragment identification syntax defined for "application/cbor".)</t>
        <t>Additional information:</t>
        <t>Magic number(s): if "application/cbor".)</dd>
	</dl>
        <dl newline="true" spacing="normal">
        <dt>Additional information:</dt>
         <dd>
          <dl newline="false" spacing="compact">
        <dt>Magic number(s):</dt><dd>If tagged, the first five bytes in hex: da 53 57 49 44 (see <xref target="tagged"/> in RFC-AAAA)</t>
        <t>File extension(s): coswid</t>
        <t>Macintosh of RFC 9393).</dd>
        <dt>File extension(s):</dt><dd>coswid</dd>
        <dt>Macintosh file type code(s): none</t>
        <t>Macintosh code(s):</dt><dd>none</dd>
        <dt>Macintosh Universal Type Identifier code: org.ietf.coswid code:</dt><dd>org.ietf.coswid
conforms to public.data</t>
        <t>Person public.data.</dd>
             </dl>
           </dd>
        </dl>
        <dl newline="false" spacing="normal">
        <dt>Person &amp; email address to contact for further information:
IESG &lt;iesg@ietf.org&gt;</t>
        <t>Intended usage: COMMON</t>
        <t>Restrictions information:</dt><dd><br/>IESG &lt;iesg@ietf.org&gt;</dd>
        <dt>Intended usage:</dt><dd>COMMON</dd>
        <dt>Restrictions on usage: None</t>
        <t>Author: Henk usage:</dt><dd>none</dd>
        <dt>Author:</dt><dd>Henk Birkholz &lt;henk.birkholz@sit.fraunhofer.de&gt;</t>
        <t>Change controller: IESG</t> &lt;henk.birkholz@sit.fraunhofer.de&gt;</dd>
        <dt>Change controller:</dt><dd>IESG</dd>
	</dl>
      </section>
      <section anchor="coap-content-format-registration">
        <name>CoAP Content-Format Registration</name>
        <t>IANA is requested to assign has assigned a CoAP Content-Format ID for the CoSWID
media type in the "CoAP Content-Formats" sub-registry, subregistry, from the "IETF
Review or IESG Approval" space (256..999), within the "CoRE
Parameters" registry <xref target="RFC7252"/> <xref target="IANA.core-parameters"/>:</t>
        <table anchor="tbl-coap-content-formats">
          <name>CoAP Content-Format IDs</name>
          <thead>
            <tr>
              <th align="left">Media type</th> align="left">Content Type</th>
              <th align="left">Encoding</th> align="left">Content Coding</th>
              <th align="left">ID</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">application/swid+cbor</td>
              <td align="left">-</td>
              <td align="left">TBD1</td> align="left">258</td>
              <td align="left">RFC-AAAA</td> align="left">RFC 9393</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="cbor-tag-registration">
        <name>CBOR Tag Registration</name>
        <t>IANA is requested to allocate has allocated a tag in the "CBOR Tags" registry <xref target="IANA.cbor-tags"/>,
preferably with the specific value requested:</t> target="IANA.cbor-tags"/>:</t>
        <table anchor="tbl-cbor-tag">
          <name>CoSWID CBOR Tag</name>
          <thead>
            <tr>
              <th align="left">Tag</th>
              <th align="left">Data Item</th>
              <th align="left">Semantics</th>
	      <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1398229316</td>
              <td align="left">map</td>
              <td align="left">Concise Software Identifier (CoSWID) [RFC-AAAA]</td> (CoSWID)</td>
	      <td align="left">RFC 9393</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="uri-scheme-registrations">
        <name>URI Scheme Registrations</name>
        <t>The ISO 19770-2:2015 SWID specification <xref target="SWID"/> describes the use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations. This document continues this use for CoSWID. The following subsections provide registrations for these schemes in to ensure that a permanent registration exists for these schemes exists that is suitable for use in the SWID and CoSWID specifications.</t>
        <t>URI schemes are registered within the "Uniform Resource Identifier (URI)
Schemes" registry maintained at <xref target="IANA.uri-schemes"/>.</t>

        <section anchor="swid-reg">
          <name>URI-scheme swid</name>
          <name>URI Scheme &quot;swid&quot;</name>
          <t>IANA is requested to register has registered the URI scheme "swid".
This registration request complies with <xref target="RFC7595"/>.</t>
          <dl newline="true"> newline="false">
            <dt>Scheme name:</dt>
            <dd>
              <t>swid</t>
            </dd>
            <dd>swid</dd>
            <dt>Status:</dt>
            <dd>
              <t>Permanent</t>
            </dd>
            <dd>Provisional</dd>
            <dt>Applications/protocols that use this scheme name:</dt>
            <dd>
              <t>Applications
            <dd>Applications that require Software-IDs Software IDs (SWIDs) or Concise
Software-IDs
Software IDs (CoSWIDs); see <xref target="uri-scheme-swid"/> of RFC-AAAA.</t>
            </dd> RFC 9393.</dd>
            <dt>Contact:</dt>
            <dd>
              <t>IETF
            <dd>IETF Chair &lt;chair@ietf.org&gt;</t>
            </dd> &lt;chair@ietf.org&gt;</dd>
            <dt>Change controller:</dt>
            <dd>
              <t>IESG &lt;iesg@ietf.org&gt;</t>
            </dd>
            <dd>IESG &lt;iesg@ietf.org&gt;</dd>
            <dt>Reference:</dt>
            <dd>
              <t><xref
            <dd><xref target="uri-scheme-swid"/> in RFC-AAAA</t>
            </dd> of RFC 9393</dd>
          </dl>
        <aside><t>Note: This scheme has been documented by an IETF working
        group and is mentioned in an IETF Standard specification. However, as it
        describes a locally scoped, limited-purpose form of identification, it
        does not fully meet the requirements for permanent registration.</t>
        <t>As long as this specification (or any successors that
        describe this scheme) is a current IETF specification, this scheme should
        be considered to be "in use" and not considered for removal from the
        registry.</t></aside>
        </section>
        <section anchor="swidpath-reg">
          <name>URI-scheme swidpath</name>
          <name>URI Scheme &quot;swidpath&quot;</name>
          <t>IANA is requested to register has registered the URI scheme "swidpath". This registration
request
complies with <xref target="RFC7595"/>.</t>
          <dl newline="true"> newline="false">
            <dt>Scheme name:</dt>
            <dd>
              <t>swidpath</t>
            </dd>
            <dd>swidpath</dd>
            <dt>Status:</dt>
            <dd>
              <t>Permanent</t>
            </dd>
            <dd>Provisional</dd>
            <dt>Applications/protocols that use this scheme name:</dt>
            <dd>
              <t>Applications
            <dd>Applications that require Software-IDs Software IDs (SWIDs) or Concise
Software-IDs
Software IDs (CoSWIDs); see <xref target="uri-scheme-swidpath"/> of RFC-AAAA.</t>
            </dd> RFC 9393.</dd>
            <dt>Contact:</dt>
            <dd>
              <t>IETF
            <dd>IETF Chair &lt;chair@ietf.org&gt;</t>
            </dd> &lt;chair@ietf.org&gt;</dd>
            <dt>Change controller:</dt>
            <dd>
              <t>IESG &lt;iesg@ietf.org&gt;</t>
            </dd>
            <dd>IESG &lt;iesg@ietf.org&gt;</dd>
            <dt>Reference:</dt>
            <dd>
              <t><xref
            <dd><xref target="uri-scheme-swidpath"/> in RFC-AAAA</t>
            </dd> of RFC 9393</dd>
          </dl>
        <aside><t>Note: This scheme has been documented by an IETF working
        group and is mentioned in an IETF Standard specification. However, as it
        describes a locally scoped, limited-purpose form of identification, it
        does not fully meet the requirements for permanent registration.</t>
        <t>As long as this specification (or any successors that
        describe this scheme) is a current IETF specification, this scheme should
        be considered to be "in use" and not considered for removal from the
        registry.</t></aside>
        </section>
      </section>
      <section anchor="sec-swima">
        <name>CoSWID Model for use Use in SWIMA Registration</name>
        <t>The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification
        <t>"<xref target="RFC8412" format="title"/>" <xref target="RFC8412"/> target="RFC8412" format="default"/> defines a standardized method for collecting an endpoint device's software inventory. A CoSWID can provide evidence of software installation which that can then be used and exchanged with SWIMA. This registration adds a new entry to the IANA "Software Data Model Types" registry defined by <xref target="RFC8412"/> and <xref target="IANA.pa-tnc-parameters"/> to support CoSWID use in SWIMA as follows:</t>
        <t>Pen: 0</t>
        <t>Integer: TBD2</t>
        <t>Name: Concise

	<dl newline="false" spacing="normal">
        <dt>Pen:</dt><dd>0</dd>
        <dt>Integer:</dt><dd>2</dd>
        <dt>Name:</dt><dd>Concise Software Identifier (CoSWID)</t>
        <t>Reference: RFC-AAAA</t>
        <t>Deriving (CoSWID)</dd>
        <dt>Reference:</dt><dd>RFC 9393</dd>
        <dt>Deriving Software Identifiers:</t>
        <t>A Identifiers:</dt>
        <dd><t>A Software Identifier generated from a CoSWID tag is expressed as a concatenation of the form used in <xref target="RFC5234"/> as follows:</t>
        <artwork><![CDATA[ follows --
      </t>
<sourcecode name="" type="abnf"><![CDATA[
TAG_CREATOR_REGID "_" "_" UNIQUE_ID
]]></artwork>
        <t>Where
]]></sourcecode>
        <t>where TAG_CREATOR_REGID is the reg-id item value of the tag's entity item having the role value of 1 (corresponding to "tag creator"), "tag-creator"), and the UNIQUE_ID is the same tag's tag-id item. If the tag-id item's value is expressed as a 16-byte binary string, the UNIQUE_ID <bcp14>MUST</bcp14> be represented using the UUID string representation defined in <xref target="RFC4122"/> target="RFC4122"/>, including the "urn:uuid:" prefix.</t>
        <t>The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double underscore (_), without any other connecting character or whitespace.</t>
      </dd>
	</dl>
      </section>
    </section>
    <section anchor="coswid-cose">
      <name>Signed CoSWID Tags</name>
      <t>SWID tags, as defined in the ISO-19770-2:2015 XML schema, Schema, can include cryptographic signatures to protect the integrity of the SWID tag.
In general, tags are signed by the tag creator (typically, although not exclusively, the vendor of the software component that the SWID tag identifies).
Cryptographic signatures can make any modification of the tag detectable, which is especially important if the integrity of the tag is important, such as when the tag is providing reference integrity measurements RIMs for files.
The ISO-19770-2:2015 XML schema Schema uses XML DSIG Digital Signatures (XMLDSIG) to support cryptographic signatures.</t>
      <t>Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption (COSE) <xref target="I-D.ietf-cose-rfc8152bis-struct"/>. target="RFC9052"/>. A CoSWID tag <bcp14>MUST</bcp14> be wrapped in a COSE Signature structure, either COSE_Sign1 or COSE_Sign.
In the first case, a Single Signer Data Object (COSE_Sign1) contains a single signature and <bcp14>MUST</bcp14> be signed by the tag creator. The following CDDL specification defines a restrictive subset of COSE header parameters that <bcp14>MUST</bcp14> be used in the protected header in this case.</t>
      <sourcecode type="CDDL" type="cddl" name="sign1.cddl" markers="true">
COSE-Sign1-coswid&lt;payload&gt;
COSE_Sign1-coswid&lt;payload&gt; = [
    protected: bstr .cbor protected-signed-coswid-header,
    unprotected: unprotected-signed-coswid-header,
    payload: bstr .cbor payload,
    signature: bstr,
]

cose-label = int / tstr
cose-values = any

protected-signed-coswid-header = {
    1 =&gt; int,                      ; algorithm identifier
    3 =&gt; "application/swid+cbor",
    * cose-label =&gt; cose-values,
}

unprotected-signed-coswid-header = {
    * cose-label =&gt; cose-values,
}
</sourcecode>
      <t>The COSE_Sign structure allows for more than one signature, one of which <bcp14>MUST</bcp14> be issued by the tag creator, to be applied to a CoSWID tag and <bcp14>MAY</bcp14> be used. The corresponding usage scenarios are domain-specific domain specific and require well-specified application guidance.</t>
      <sourcecode type="CDDL" type="cddl" name="sign.cddl" markers="true">
COSE-Sign-coswid&lt;payload&gt;
COSE_Sign-coswid&lt;payload&gt; = [
    protected: bstr .cbor protected-signed-coswid-header1,
    unprotected: unprotected-signed-coswid-header,
    payload: bstr .cbor payload,
    signature: [ * COSE_Signature ],
]

protected-signed-coswid-header1 = {
    3 =&gt; "application/swid+cbor",
    * cose-label =&gt; cose-values,
}

protected-signature-coswid-header = {
    1 =&gt; int,                      ; algorithm identifier
    * cose-label =&gt; cose-values,
}

unprotected-sign-coswid-header

unprotected-signed-coswid-header = {
    * cose-label =&gt; cose-values,
}

COSE_Signature =  [
    protected: bstr .cbor protected-signature-coswid-header,
    unprotected: unprotected-sign-coswid-header,
    signature : unprotected-signed-coswid-header,
    signature: bstr
]
</sourcecode>
      <t>Additionally, the COSE Header counter signature header countersignature <bcp14>MAY</bcp14> be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID <xref target="I-D.ietf-cose-countersign"/>. target="RFC9338"/>.
The application of counter signing countersigning enables second parties to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp).</t>
      <t>A CoSWID <bcp14>MUST</bcp14> be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in <xref target="sec-sec"/>) target="sec-sec"/> ("<xref target="sec-sec" format="title"/>") for more information on why a signed CoSWID is valuable in most cases.</t>
    </section>
    <section anchor="tagged">
      <name>CBOR-Tagged CoSWID Tags</name>
      <t>This specification allows for tagged and untagged CBOR data items that are CoSWID tags.
Consecutively,
Consequently, the CBOR tag defined by this document (<xref target="tbl-cbor-tag"/>) for CoSWID tags defined in <xref target="tbl-cbor-tag"/> <bcp14>SHOULD</bcp14> be used in conjunction with CBOR data items that are a CoSWID tags.
Other CBOR tags <bcp14>MUST NOT</bcp14> be used with a CBOR data item that is a CoSWID tag.
If tagged, both signed and unsigned CoSWID tags <bcp14>MUST</bcp14> use the CoSWID CBOR tag.
In case
If a signed CoSWID is tagged, a CoSWID CBOR tag <bcp14>MUST</bcp14> be appended before the COSE envelope envelope, whether it is a COSE_Untagged_Message or a COSE_Tagged_Message.
In case
If an unsigned CoSWID is tagged, a CoSWID CBOR tag <bcp14>MUST</bcp14> be appended before the CBOR data item that is the CoSWID tag.</t>
      <sourcecode type="CDDL" type="cddl" name="tags.cddl" markers="true">
coswid = unsigned-coswid / signed-coswid
unsigned-coswid = concise-swid-tag / tagged-coswid&lt;concise-swid-tag&gt;
signed-coswid1 = signed-coswid-for&lt;unsigned-coswid&gt;
signed-coswid = signed-coswid1 / tagged-coswid&lt;signed-coswid1&gt;

tagged-coswid&lt;T&gt; = #6.1398229316(T)

signed-coswid-for&lt;payload&gt; = #6.18(COSE-Sign1-coswid&lt;payload&gt;) #6.18(COSE_Sign1-coswid&lt;payload&gt;)
    / #6.98(COSE-Sign-coswid&lt;payload&gt;) #6.98(COSE_Sign-coswid&lt;payload&gt;)
</sourcecode>
      <t>This specification allows for a tagged CBOR-tagged CoSWID tag to reside in a COSE envelope that is also tagged with a CoSWID CBOR tag. In cases where a tag creator is not a signer (e.g., hand-offs between entities in a trusted portion of a supply-chain), supply chain), retaining CBOR tags attached to unsigned CoSWID tags can be of great use. Nevertheless, redundant use of tags <bcp14>SHOULD</bcp14> be avoided when possible.</t>
    </section>
    <section anchor="sec-sec">
      <name>Security Considerations</name>
      <t>The following security considerations for the use of CoSWID tags focus on:</t>
      <ul spacing="normal">
        <li>ensuring the integrity and authenticity of a CoSWID tag</li>
        <li>the application of CoSWID tags to address security challenges related to unmanaged or unpatched software</li>
        <li>reducing the potential for unintended disclosure of a device's software load</li>
      </ul>
      <t>A tag is considered "authoritative" if the CoSWID tag was created by the
software provider. An authoritative CoSWID tag contains information about a software component provided by the supplier of the software component, who is expected to be an expert in their own software. Thus, authoritative CoSWID tags can represent authoritative information about the software component. The degree to which this information can be trusted depends on the tag's chain of custody and the ability to verify a signature provided by the supplier if present in the CoSWID tag. The provisioning and validation of CoSWID tags are handled by local policy and is are outside the scope of this document.</t>
      <t>A signed CoSWID tag (see <xref target="coswid-cose"/>) whose signature has been validated can be relied upon to be unchanged since the time at which it was signed. By contrast, the data contained in unsigned tags can be altered by any user or process with write-access write access to the tag. To support signature validation, there is the a need to associate the right key with the software provider or party originating the signature in a secure way. This operation is application specific and needs to be addressed by the application or a user of the application; a specific approach for which this topic is out-of-scope out of scope for this document.</t>
      <t>When an authoritative tag is signed, the originator of the signature can be verified. A trustworthy association between the signature and the originator of the signature can be established via trust anchors. A certification path between a trust anchor and a certificate certificate, including a public key enabling the validation of a tag signature signature, can realize the assessment of trustworthiness of an authoritative tag. Verifying that the software provider is the signer is a different matter. This requires an association between verifying that the signature and party that signed the tag is the same party given in the software-creator role of the tag's entity item associated corresponding to the software provider. item. No mechanism is defined in this draft document to make this association; therefore, this association will need to be handled by local policy.
As always, the validity of a signature does not imply the veracity of the
signed statements: anyone can sign assertions such that the software
is from a specific software-creator or that a specific persistent-id
applies; policy needs to be applied to evaluate these statements and to determine their suitability for a specific use.</t>
      <t>Loss of control of signing credentials used to sign CoSWID tags would create cast doubt about on the authenticity and integrity of any CoSWID tags signed using the compromised keys. In such cases, the legitimate tag signer (namely, the software provider for an authoritative CoSWID tag) can employ uncompromised signing credentials to create a new signature on the original tag. The tag tag's version number would not be incremented incremented, since the tag itself was not modified. Consumers of CoSWID tags would need to validate the tag using the new credentials and would also need to make use of revocation information available for the compromised credentials to avoid validating tags signed with them. The process for doing this is beyond the scope of this specification.</t>
      <t>The CoSWID format allows the use of hash values without an
accompanying hash algorithm identifier.
This exposes the tags to some risk of cross-algorithm attacks.
We believe that this can become a practical problem only if some
implementations allow the use of insecure hash algorithms.
Since it may not become known immediately when an algorithm becomes
insecure, this leads to a strong recommendation to only include
support for hash algorithms that are generally considered secure, and
not just marginally so.</t>
      <t>CoSWID tags are intended to contain public information about software components and, as
such, the contents of a CoSWID tag (as opposed to the set of tags that apply to the endpoint, endpoint; see below) does do not need to be protected against unintended disclosure on an endpoint.
Conversely, generators of CoSWID tags need to ensure that only public
information is disclosed.
Entitlement Keys are
The entitlement-key item is an example for of information where for which particular care
is required; tag authors are advised not to record unprotected,
private software license keys in this field.</t>
      <t>CoSWID tags are intended to be easily discoverable by
authorized applications and users on an endpoint in order to make it easy to determine the tagged software load. Access to the collection of an endpoint's CoSWID tags needs to be appropriately controlled limited to authorized applications and users using an appropriate access control mechanism.</t>
      <t>Since the tag-id of a CoSWID tag can be used as a global index value, failure to ensure the tag-id's uniqueness can cause collisions or ambiguity in CoSWID tags that are retrieved or processed using this identifier. CoSWID is designed to not require a registry of identifiers. As a result, CoSWID requires the tag creator to employ a method of generating a unique tag identifier. Specific methods of generating a unique identifier are beyond the scope of this specification. A collision in tag-ids may result in false positives/negatives in software integrity checks or mis-identification misidentification of installed software, undermining CoSWID use cases such as vulnerability identification, software inventory, etc. If such a collision is detected, then the tag consumer may want to contact the maintainer of the CoSWID to have them issue a correction addressing the collision; however, this also discloses to the maintainer that the consumer has the other tag with the given tag-id in their database.
More generally speaking, a tag consumer needs to be robust against such collisions lest the collision become a viable attack vector.</t>
      <t>CoSWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software components.
On endpoints where the addition or removal of software components is
tightly controlled, the addition or removal of CoSWID tags can be
similarly controlled.  On more open systems, where many users can
manage the software inventory, CoSWID tags can be easier to add or
remove.  On such systems, it can be possible to add or remove CoSWID
tags in a way that does not reflect the actual presence or absence of
corresponding software components.  Similarly, not all software
products automatically install CoSWID tags, so products can be present
on an endpoint without providing a corresponding CoSWID tag.  As such,
any collection of CoSWID tags cannot automatically be assumed to
represent either a complete or fully accurate representation of the
software inventory of the endpoint.  However, especially on endpoint devices
that more strictly control the ability to add or remove applications,
CoSWID tags are an easy way to provide a preliminary understanding of
that endpoint's software inventory.</t>
      <t>As CoSWID tags do not expire, inhibiting new CoSWID tags from reaching an intended consumer would render that consumer stuck with outdated information, potentially leaving associated vulnerabilities or weaknesses unmitigated. Therefore, a CoSWID tag consumer should actively check for updated tag-versions via more than one means.</t>
      <t>This specification makes use of relative paths (e.g., filesystem
paths) in several places.
A signed COSWID CoSWID tag cannot make use of these to derive information
that is considered to be covered under the signature.
Typically, relative file system filesystem paths will be used to identify
targets for an installation, not sources of tag information.</t>
      <t>Any report of an endpoint's CoSWID tag collection provides
information about the software inventory of that endpoint.  If such a
report is exposed to an attacker, this can tell them which software
products and versions thereof are present on the endpoint.  By
examining this list, the attacker might learn of the presence of
applications that are vulnerable to certain types of attacks.  As
noted earlier, CoSWID tags are designed to be easily discoverable by authorized applications and users on an
endpoint, but this does not present a significant risk risk, since an
attacker would already need to have access to the endpoint to view
that information.  However, when the endpoint transmits its software
inventory to another party, party or that inventory is stored on a server
for later analysis, this can potentially expose this information to
attackers who do not yet have access to the endpoint.  For this reason, it is
important to protect the confidentiality of CoSWID tag information that
has been collected from an endpoint in transit and at rest, not because those tags
individually contain sensitive information, information but because the
collection of CoSWID tags and their association with an endpoint
reveals information about that endpoint's attack surface.</t>
      <t>Finally, both the ISO-19770-2:2015 XML schema Schema SWID definition and the
CoSWID CDDL specification allow for the construction of "infinite"
tags with link item loops or tags that contain malicious content with the intent
of creating non-deterministic states during validation or processing of those tags. While software
providers are unlikely to do this, CoSWID tags can be created by any party and the CoSWID tags
collected from an endpoint could contain a mixture of vendor tags created by vendors and non-vendor tags not created tags. by vendors. For this
reason, a CoSWID tag might contain potentially malicious
content. Input sanitization, loop detection, and signature
verification are ways that implementations can address this concern.</t>
      <t>More generally speaking, the security considerations Security Considerations sections of <xref target="RFC8949"/>,
<xref target="I-D.ietf-cose-rfc8152bis-struct"/>, target="RFC9052"/>, and <xref target="I-D.ietf-cose-countersign"/> target="RFC9338"/> apply.</t>
    </section>
    <section anchor="privacy-consideration">
      <name>Privacy Consideration</name> Considerations</name>
      <t>As noted in <xref target="sec-sec"/>, collected information about an endpoint's software load, such as what might be represented by an endpoint's CoSWID tag collection, could be used by attackers to identify vulnerable software for attack. software. Collections of endpoint software information also can have privacy implications for users. The set of application applications a user installs can give provide clues to regarding personal matters such as political affiliation, banking and investments, gender, sexual orientation, medical concerns, etc. While the collection of CoSWID tags on an endpoint wouldn't increase the privacy risk risks (since a party able to view those tags could also view the applications themselves), if those CoSWID tags are gathered and stored in a repository somewhere, visibility into the repository now also gives provides visibility into a user's application collection. For this reason, not only do repositories of collected CoSWID tags not only need to be protected against collection by malicious parties, parties but even authorized parties will need to be vetted and made aware of privacy responsibilities associated with having access to this information. Likewise, users should be made aware that their software inventories are being collected from endpoints. Furthermore, when collected and stored by authorized parties or systems, the inventory data needs to be protected as both security and privacy-sensitive information.</t>
    </section>
    <section removeInRFC="true" anchor="change-log">
      <name>Change Log</name>
      <t>[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.]</t>
      <t>Changes from version 12 to version 14:</t>
      <ul spacing="normal">
        <li>Moved key identifier to protected COSE header</li>
        <li>Fixed index reference for hash</li>
        <li>Removed indirection of CDDL type definition for filesystem-item</li>
        <li>Fixed quantity of resource and process</li>
        <li>Updated resource-collection</li>
        <li>Renamed socket name in software-meta to be consistent in naming</li>
        <li>Aligned excerpt examples in I-D text with full CDDL</li>
        <li>Fixed titles where title was referring to group instead of map</li>
        <li>Added missing date in SEMVER</li>
        <li>Fixed root cardinality for file and directory, etc.</li>
        <li>Transformed path-elements-entry from map to group for re-usability</li>
        <li>Scrubbed IANA Section</li>
        <li>Removed redundant supplemental rule</li>
        <li>Aligned discrepancy with ISO spec.</li>
        <li>Addressed comments on typos.</li>
        <li>Fixed kramdown nits and BCP reference.</li>
        <li>Addressed comments from WGLC reviewers.</li>
      </ul>
      <t>Changes in version 12:</t>
      <ul spacing="normal">
        <li>Addressed a bunch of minor editorial issues based on WGLC feedback.</li>
        <li>Added text about the use of UTF-8 in CoSWID.</li>
        <li>Adjusted tag-id to allow for a UUID to be provided as a bstr.</li>
        <li>Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 bit, 16 bit, etc.</li>
        <li>Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document.</li>
        <li>Added discussion around resolving overlapping value spaces for version schemes.</li>
        <li>Added a set of expert review criteria for new IANA registries created by this document.</li>
        <li>Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA.</li>
      </ul>
      <t>Changes from version 03 to version 11:</t>
      <ul spacing="normal">
        <li>Reduced representation complexity of the media-entry type and removed the Section describing the older data structure.</li>
        <li>Added more signature schemes from COSE</li>
        <li>Included a minimal required set of normative language</li>
        <li>Reordering of attribute name to integer label by priority according to semantics.</li>
        <li>Added an IANA registry for CoSWID items supporting future extension.</li>
        <li>Cleaned up IANA registrations, fixing some inconsistencies in the table labels.</li>
        <li>Added additional CDDL sockets for resource collection entries providing for additional extension points to address future SWID/CoSWID extensions.</li>
        <li>Updated Section on extension points to address new CDDL sockets and to reference the new IANA registry for items.</li>
        <li>Removed unused references and added new references to address placeholder comments.</li>
        <li>Added table with semantics for the link ownership item.</li>
        <li>Clarified language, made term use more consistent, fixed references, and replacing lowercase RFC2119 keywords.</li>
      </ul>
      <t>Changes from version 02 to version 03:</t>
      <ul spacing="normal">
        <li>Updated core CDDL including the CDDL design pattern according to RFC 8428.</li>
      </ul>
      <t>Changes from version 01 to version 02:</t>
      <ul spacing="normal">
        <li>Enforced a more strict separation between the core CoSWID definition and additional usage by
moving content to corresponding appendices.</li>
        <li>Removed artifacts inherited from the reference schema provided by ISO (e.g., NMTOKEN(S))</li>
        <li>Simplified the core data definition by removing group and type choices where possible</li>
        <li>Minor reordering of map members</li>
        <li>Added a first extension point to address requested flexibility for extensions beyond the
any-element</li>
      </ul>
      <t>Changes from version 00 to version 01:</t>
      <ul spacing="normal">
        <li>Ambiguity between evidence and payload eliminated by introducing explicit members (while still</li>
        <li>allowing for "empty" SWID tags)</li>
        <li>Added a relatively restrictive COSE envelope using cose_sign1 to define signed CoSWID (single signer only, at the moment)</li>
        <li>Added a definition how to encode hashes that can be stored in the any-member using existing IANA tables to reference hash-algorithms</li>
      </ul>
      <t>Changes since adopted as a WG I-D -00:</t>
      <ul spacing="normal">
        <li>Removed redundant any-attributes originating from the ISO-19770-2:2015 XML schema definition</li>
        <li>Fixed broken multi-map members</li>
        <li>Introduced a more restrictive item (any-element-map) to represent custom maps, increased restriction on types for the any-attribute, accordingly</li>
        <li>Fixed X.1520 reference</li>
        <li>Minor type changes of some attributes (e.g., NMTOKENS)</li>
        <li>Added semantic differentiation of various name types (e,g. fs-name)</li>
      </ul>
      <t>Changes from version 06 to version 07:</t>
      <ul spacing="normal">
        <li>Added type choices/enumerations based on textual definitions in 19770-2:2015</li>
        <li>Added value registry request</li>
        <li>Added media type registration request</li>
        <li>Added content format registration request</li>
        <li>Added CBOR tag registration request</li>
        <li>Removed RIM appendix to be addressed in complementary draft</li>
        <li>Removed CWT appendix</li>
        <li>Flagged firmware resource collection appendix for revision</li>
        <li>Made use of terminology more consistent</li>
        <li>Better defined use of extension points in the CDDL</li>
        <li>Added definitions for indexed values</li>
        <li>Added IANA registry for Link use indexed values</li>
      </ul>
      <t>Changes from version 05 to version 06:</t>
      <ul spacing="normal">
        <li>Improved quantities</li>
        <li>Included proposals for implicit enumerations that were NMTOKENS</li>
        <li>Added extension points</li>
        <li>Improved exemplary firmware-resource extension</li>
      </ul>
      <t>Changes from version 04 to version 05:</t>
      <ul spacing="normal">
        <li>Clarified language around SWID and CoSWID to make more consistent use of these terms.</li>
        <li>Added language describing CBOR optimizations for single vs. arrays in the model front matter.</li>
        <li>Fixed a number of grammatical, spelling, and wording issues.</li>
        <li>Documented extension points that use CDDL sockets.</li>
        <li>Converted IANA registration tables to markdown tables, reserving the 0 value for use when a value is not known.</li>
        <li>Updated a number of references to their current versions.</li>
      </ul>
      <t>Changes from version 03 to version 04:</t>
      <ul spacing="normal">
        <li>Re-index label values in the CDDL.</li>
        <li>Added a Section describing the CoSWID model in detail.</li>
        <li>Created IANA registries for entity-role and version-scheme</li>
      </ul>
      <t>Changes from version 02 to version 03:</t>
      <ul spacing="normal">
        <li>Updated CDDL to allow for a choice between a payload or evidence</li>
        <li>Re-index label values in the CDDL.</li>
        <li>Added item definitions</li>
        <li>Updated references for COSE, CBOR Web Token, and CDDL.</li>
      </ul>
      <t>Changes from version 01 to version 02:</t>
      <ul spacing="normal">
        <li>Added extensions for Firmware and CoSWID use as Reference Integrity Measurements (CoSWID RIM)</li>
        <li>Changes meta handling in CDDL from use of an explicit use of items to a more flexible unconstrained collection of items.</li>
        <li>Added Sections discussing use of COSE Signatures and CBOR Web Tokens</li>
      </ul>
      <t>Changes from version 00 to version 01:</t>
      <ul spacing="normal">
        <li>Added CWT usage for absolute SWID paths on a device</li>
        <li>Fixed cardinality of type-choices including arrays</li>
        <li>Included first iteration of firmware resource-collection</li>
      </ul>
    </section>
  </middle>
  <back>

<displayreference target="RFC8126" to="BCP26"/>
<displayreference target="RFC6648" to="BCP178"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference

<referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/>
            <seriesInfo name="RFC" value="8126"/>
            <seriesInfo name="BCP" value="26"/>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
        </reference>
        <reference target="https://www.rfc-editor.org/info/bcp26">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</referencegroup>
<referencegroup anchor="BCP178" target="https://www.rfc-editor.org/info/rfc6648">
          <front>
            <title>Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</title>
            <seriesInfo name="DOI" value="10.17487/RFC6648"/>
            <seriesInfo name="RFC" value="6648"/>
            <seriesInfo name="BCP" value="178"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
              <organization/>
            </author>
            <author fullname="D. Crocker" initials="D." surname="Crocker">
              <organization/>
            </author>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <date month="June" year="2012"/>
            <abstract>
              <t>Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs.  In practice, that convention causes more problems than it solves.  Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <seriesInfo name="DOI" value="10.17487/RFC3629"/>
            <seriesInfo name="RFC" value="3629"/>
            <seriesInfo name="STD" value="63"/>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau">
              <organization/>
            </author>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <seriesInfo name="DOI" value="10.17487/RFC3986"/>
            <seriesInfo name="RFC" value="3986"/>
            <seriesInfo name="STD" value="66"/>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5198" target="https://www.rfc-editor.org/info/rfc5198">
          <front>
            <title>Unicode Format for Network Interchange</title>
            <seriesInfo name="DOI" value="10.17487/RFC5198"/>
            <seriesInfo name="RFC" value="5198"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author>
            <author fullname="M. Padlipsky" initials="M." surname="Padlipsky">
              <organization/>
            </author>
            <date month="March" year="2008"/>
            <abstract>
              <t>The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET.  This document specifies that format, using UTF-8 with normalization and specific line-ending sequences.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <seriesInfo name="DOI" value="10.17487/RFC5234"/>
            <seriesInfo name="RFC" value="5234"/>
            <seriesInfo name="STD" value="68"/>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
              <organization/>
            </author>
            <author fullname="P. Overell" initials="P." surname="Overell">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646">
          <front>
            <title>Tags for Identifying Languages</title>
            <seriesInfo name="DOI" value="10.17487/RFC5646"/>
            <seriesInfo name="RFC" value="5646"/>
            <seriesInfo name="BCP" value="47"/>
            <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips">
              <organization/>
            </author>
            <author fullname="M. Davis" initials="M." role="editor" surname="Davis">
              <organization/>
            </author>
            <date month="September" year="2009"/>
            <abstract>
              <t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document  specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
            <seriesInfo name="DOI" value="10.17487/RFC5890"/>
            <seriesInfo name="RFC" value="5890"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8949"/>
            <seriesInfo name="RFC" value="8949"/>
            <seriesInfo name="STD" value="94"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the format.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7252"/>
            <seriesInfo name="RFC" value="7252"/>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-cose-rfc8152bis-struct" target="https://www.ietf.org/archive/id/draft-ietf-cose-rfc8152bis-struct-15.txt">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-cose-rfc8152bis-struct-15"/>
            <author fullname="Jim Schaad">
              <organization>August Cellars</organization>
            </author>
            <date day="1" month="February" year="2021"/>
            <abstract>
              <t>   Concise Binary Object Representation (CBOR) is a data format designed
   for small code size and small message size.  There is a need for the
   ability to have basic security services defined for this data format.
   This document defines the CBOR Object Signing and Encryption (COSE)
   protocol.  This specification describes how to create and process
   signatures, message authentication codes, and encryption using CBOR
   for serialization.  This specification additionally describes how to
   represent cryptographic keys using CBOR.

   This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes
   RFC8152.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8412" target="https://www.rfc-editor.org/info/rfc8412">
          <front>
            <title>Software Inventory Message and Attributes (SWIMA) for PA-TNC</title>
            <seriesInfo name="DOI" value="10.17487/RFC8412"/>
            <seriesInfo name="RFC" value="8412"/>
            <author fullname="C. Schmidt" initials="C." surname="Schmidt">
              <organization/>
            </author>
            <author fullname="D. Haynes" initials="D." surname="Haynes">
              <organization/>
            </author>
            <author fullname="C. Coffin" initials="C." surname="Coffin">
              <organization/>
            </author>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <author fullname="J. Fitzgerald-McKay" initials="J." surname="Fitzgerald-McKay">
              <organization/>
            </author>
            <date month="July" year="2018"/>
            <abstract>
              <t>This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" target="https://www.rfc-editor.org/info/bcp178">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6648.xml"/>
</referencegroup>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>

<!-- draft-ietf-cose-rfc8152bis-struct (RFC 5209).</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8288" target="https://www.rfc-editor.org/info/rfc8288">
          <front>
            <title>Web Linking</title>
            <seriesInfo name="DOI" value="10.17487/RFC8288"/>
            <seriesInfo name="RFC" value="8288"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <date month="October" year="2017"/>
            <abstract>
              <t>This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <seriesInfo name="DOI" value="10.17487/RFC8610"/>
            <seriesInfo name="RFC" value="8610"/>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures 9052; published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8412.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>

<!-- draft-ietf-cose-countersign (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-cose-countersign" target="https://www.ietf.org/archive/id/draft-ietf-cose-countersign-05.txt">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-cose-countersign-05"/>
            <author fullname="Jim Schaad">
              <organization>August Cellars</organization>
            </author>
            <author fullname="Russ Housley">
              <organization>Vigil Security</organization>
            </author>
            <date day="23" month="June" year="2021"/>
            <abstract>
              <t>   Concise Binary Object Representation (CBOR) is a data format designed
   for small code size and small message size.  CBOR Object Signing and
   Encryption (COSE) defines a set of security services for CBOR.  This
   document defines a countersignature algorithm along with the needed
   header parameters and CBOR tags for COSE.

              </t>
            </abstract>
          </front>
        </reference> 9338; published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9338.xml"/>

        <reference anchor="SAM"> anchor="SAM" target="https://www.iso.org/standard/68291.html">
          <front>
            <title>Information technology - Software IT asset management - Part 5: Overview and vocabulary</title>
            <seriesInfo name="ISO/IEC" value="19770-5:2015"/>
            <author>
              <organization/>
            </author>
            <date year="2013" month="November" day="15"/> year="2015" month="August"/>
          </front>
          <refcontent>ISO/IEC 19770-5:2015</refcontent>
        </reference>

        <reference anchor="SWID"> anchor="SWID" target="https://www.iso.org/standard/65666.html">
          <front>
            <title>Information technology - Software IT asset management - Part 2: Software identification tag</title>
            <seriesInfo name="ISO/IEC" value="19770-2:2015"/>
            <author>
              <organization/>
            </author>
            <date year="2015" month="October" day="01"/> month="October"/>
          </front>
         <refcontent>ISO/IEC 19770-2:2015</refcontent>
        </reference>

        <reference anchor="UNSPSC" target="https://www.unspsc.org/">
          <front>
            <title>United Nations Standard Products and Services Code</title>
            <author>
              <organization/>
            </author>
            <date year="2020" month="October" day="26"/> year="2022"/>
          </front>
        </reference>

        <reference anchor="W3C.REC-xpath20-20101214" target="https://www.w3.org/TR/2010/REC-xpath20-20101214/">
          <front>
            <title>XML Path Language (XPath) 2.0 (Second Edition)</title>
            <seriesInfo name="W3C" value="REC-xpath20-20101214"/>
            <seriesInfo name="W3C REC" value="REC-xpath20-20101214"/>
            <author fullname="Anders Berglund" role="editor"/>
            <author fullname="Don Chamberlin" role="editor"/>
            <author fullname="Jerome Simeon" fullname="Scott Boag" role="editor"/>
            <author fullname="Jonathan Robie" fullname="Don Chamberlin" role="editor"/>
            <author fullname="Mary Fernandez" F. Fernández" role="editor"/>
            <author fullname="Michael Kay" role="editor"/>
            <author fullname="Scott Boag" fullname="Jonathan Robie" role="editor"/>
            <author fullname="Jérôme Siméon" role="editor"/>
            <date day="14" month="December" year="2010"/>
          </front>
         <refcontent>W3C Recommendation REC-xpath20-20101214</refcontent>
        </reference>

        <reference anchor="W3C.REC-css3-mediaqueries-20120619" target="https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/"> anchor="W3C.REC-mediaqueries-3-20220405"  target="https://www.w3.org/TR/mediaqueries-3/">
          <front>
            <title>Media Queries</title>
            <seriesInfo name="W3C REC" value="REC-css3-mediaqueries-20120619"/>
            <seriesInfo name="W3C" value="REC-css3-mediaqueries-20120619"/> Queries Level 3</title>
            <author fullname="Florian Rivoal" role="editor"/>
            <date day="19" month="June" year="2012"/> day="05" month="April" year="2022"/>
          </front>
         <refcontent>W3C Recommendation REC-mediaqueries-3-20220405</refcontent>
        </reference>
        <reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">
          <front>
            <title>XML Schema Part 2: Datatypes Second Edition</title>
            <seriesInfo name="W3C REC" value="REC-xmlschema-2-20041028"/>
            <seriesInfo name="W3C" value="REC-xmlschema-2-20041028"/>
            <author fullname="Ashok Malhotra" role="editor"/>
            <author fullname="Paul V. Biron" role="editor"/>
            <author fullname="Ashok Malhotra" role="editor"/>
            <date day="28" month="October" year="2004"/>
          </front>
         <refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
        </reference>

        <reference anchor="IANA.named-information" target="https://www.iana.org/assignments/named-information">
          <front>
            <title>Named Information</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="14" month="August" year="2012"/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
            <date/>
          </front>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="IANA.media-types" target="https://www.iana.org/assignments/media-types">
          <front>
            <title>Media Types</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="13" month="July" year="2022"/>
            <date/>
          </front>
        </reference>

        <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="8" month="June" year="2012"/>
            <date/>
          </front>
        </reference>

        <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="19" month="September" year="2013"/>
            <date/>
          </front>
        </reference>

        <reference anchor="IANA.uri-schemes" target="https://www.iana.org/assignments/uri-schemes">
          <front>
            <title>Uniform Resource Identifier (URI) Schemes</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="6" month="July" year="2022"/>
            <date/>
          </front>
        </reference>

        <reference anchor="IANA.pa-tnc-parameters" target="https://www.iana.org/assignments/pa-tnc-parameters">
          <front>
            <title>Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="13" month="November" year="2009"/>
            <date/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3444">
          <front>
            <title>On the Difference between Information Models and Data Models</title>
            <seriesInfo name="DOI" value="10.17487/RFC3444"/>
            <seriesInfo name="RFC" value="3444"/>
            <author fullname="A. Pras" initials="A." surname="Pras">
              <organization/>
            </author>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
              <organization/>
            </author>
            <date month="January" year="2003"/>
            <abstract>
              <t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4122" target="https://www.rfc-editor.org/info/rfc4122">
          <front>
            <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
            <seriesInfo name="DOI" value="10.17487/RFC4122"/>
            <seriesInfo name="RFC" value="4122"/>
            <author fullname="P. Leach" initials="P." surname="Leach">
              <organization/>
            </author>
            <author fullname="M. Mealling" initials="M." surname="Mealling">
              <organization/>
            </author>
            <author fullname="R. Salz" initials="R." surname="Salz">
              <organization/>
            </author>
            <date month="July" year="2005"/>
            <abstract>
              <t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier).  A UUID is 128 bits long, and can guarantee uniqueness across space and time.  UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t>
              <t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).  Information from earlier versions of the DCE specification have been incorporated into this document.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7595" target="https://www.rfc-editor.org/info/rfc7595">
          <front>
            <title>Guidelines and Registration Procedures for URI Schemes</title>
            <seriesInfo name="DOI" value="10.17487/RFC7595"/>
            <seriesInfo name="RFC" value="7595"/>
            <seriesInfo name="BCP" value="35"/>
            <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler">
              <organization/>
            </author>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author>
            <author fullname="T. Hardie" initials="T." surname="Hardie">
              <organization/>
            </author>
            <date month="June" year="2015"/>
            <abstract>
              <t>This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.  It obsoletes RFC 4395.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8322" target="https://www.rfc-editor.org/info/rfc8322">
          <front>
            <title>Resource-Oriented Lightweight Information Exchange (ROLIE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8322"/>
            <seriesInfo name="RFC" value="8322"/>
            <author fullname="J. Field" initials="J." surname="Field">
              <organization/>
            </author>
            <author fullname="S. Banghart" initials="S." surname="Banghart">
              <organization/>
            </author>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <date month="February" year="2018"/>
            <abstract>
              <t>This document defines a resource-oriented approach for security automation information publication, discovery, and sharing.  Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories.  This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8520" target="https://www.rfc-editor.org/info/rfc8520">
          <front>
            <title>Manufacturer Usage Description Specification</title>
            <seriesInfo name="DOI" value="10.17487/RFC8520"/>
            <seriesInfo name="RFC" value="8520"/>
            <author fullname="E. Lear" initials="E." surname="Lear">
              <organization/>
            </author>
            <author fullname="R. Droms" initials="R." surname="Droms">
              <organization/>
            </author>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu">
              <organization/>
            </author>
            <date month="March" year="2019"/>
            <abstract>
              <t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs).  The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function.  The initial focus is on access control.  Later work can delve into other aspects.</t>
              <t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-rats-architecture" target="https://www.ietf.org/archive/id/draft-ietf-rats-architecture-18.txt">
          <front>
            <title>Remote Attestation Procedures Architecture</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-rats-architecture-18"/>
            <author fullname="Henk Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Dave Thaler">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Michael Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <author fullname="Ned Smith">
              <organization>Intel Corporation</organization>
            </author>
            <author fullname="Wei Pan">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="14" month="June" year="2022"/>
            <abstract>
              <t>   In network protocol exchanges it is often useful for one end of a
   communication to know whether the other end is in an intended
   operating state.  This document provides an architectural overview of
   the entities involved that make such tests possible through the
   process of generating, conveying, and evaluating evidentiary claims.
   An attempt is made to provide for a model that is neutral toward
   processor architectures, the content of claims, and protocols.

              </t>
            </abstract>
          </front>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8322.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>

<!-- draft-ietf-rats-architecture (RFC 9334; published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>

        <reference anchor="CamelCase" target="http://wiki.c2.com/?CamelCase">
          <front>
            <title>UpperCamelCase</title>
            <title>Camel Case (upper camel case)</title>
            <author>
              <organization/>
            </author>
            <date year="2014" month="August" day="29"/> month="December" day="18"/>
          </front>
        </reference>

        <reference anchor="KebabCase" target="http://wiki.c2.com/?KebabCase">
          <front>
            <title>KebabCase</title>
            <title>Kebab Case</title>
            <author>
              <organization/>
            </author>
            <date year="2014" month="December" day="18"/> month="August" day="29"/>
          </front>
        </reference>

        <reference anchor="SEMVER" target="https://semver.org/spec/v2.0.0.html">
          <front>
            <title>Semantic Versioning 2.0.0</title>
            <author initials="T." surname="Preston-Werner" fullname="Tom Preston-Werner">
              <organization/>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="X.1520"> anchor="X.1520" target="https://www.itu.int/rec/T-REC-X.1520">
          <front>
            <title>Recommendation ITU-T X.1520 (2014), Common
            <title>Common vulnerabilities and exposures</title>
            <author>
              <organization/>
              <organization>ITU-T</organization>
            </author>
            <date year="2011" month="April" day="20"/> year="2014" month="January"/>
          </front>
         <refcontent>ITU-T Recommendation X.1520</refcontent>
        </reference>

        <reference anchor="SWID-GUIDANCE" target="https://doi.org/10.6028/NIST.IR.8060">
          <front>
            <title>Guidelines for the Creation of Interoperable Software Identification (SWID) Tags</title>
            <seriesInfo name="NISTIR" value="8060"/>
            <author initials="D." surname="Waltermire" fullname="David Waltermire">
              <organization>National Institute for Standards and Technology</organization>
            </author>
            <author initials="B. A." surname="Cheikes" fullname="Brant A. Cheikes">
              <organization>The MITRE Corporation</organization>
            </author>
            <author initials="L." surname="Feldman" fullname="Larry Feldman">
              <organization>G2, Inc</organization>
            </author>
            <author initials="G." surname="Witte" fullname="Greg Witte">
              <organization>G2, Inc</organization>
            </author>
            <date year="2016" month="April"/>
          </front>
         <refcontent>NISTIR 8060</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document draws heavily on the concepts defined in the ISO/IEC 19770-2:2015 specification. The authors of this document are grateful for the prior work of the 19770-2 contributors.</t>
      <t>We are also grateful for the careful reviews provided by the IESG
reviewers.  Special thanks go to Benjamin Kaduk.</t>
      <!--  LocalWords:  SWID verifier TPM filesystem discoverable CoSWID
 --> <contact fullname="Benjamin Kaduk"/>.</t>
</section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization>Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </contact>
      <t>Carsten Bormann
      <t><contact fullname="Carsten Bormann"/> contributed to the CDDL specifications and the IANA considerations.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHEP12IAA+y96XrbVpow+B9XcZrpZyKlSUqkFktK2VXyksRfx0tbclX3
JJl8EAmKaJMACyAlq2z3tcyPuZKZG5t3PRtAWnKcSlV3uZ+uiMDBWd/z7kuv
10uuTsxekizz5Sw7MY/KYpTXmTkrJ8vrtMrM03FWLPNJPkqXeVmY8/SyTtKL
iyq7wsZnf3r6OBmXoyKdw8fjKp0se3m2nPTqdDTvjcr6Oh/3hsMEekpPzFk2
WlX58ia5voQfp4+emT+V1Zu8uDTfVuVqkby5PjFPi2VWFdmy9xg7S2DYE1Mv
x8moLOqsqFf1iVlWqyypVxfzvK5hTsubBYz99Mn5N0mSrpbTsjpJeiYvoOV3
ffMwr95My9lfEmN4kt9lxRv/aVnBZL6p0lUxLSdZZc6ensNTXWLjRTZP89mJ
mUIv/Qvp5Q91vuxPbMv+OIOG9bLKMpj8q2kGc1lWaQ3beu8A3ozKMczjy8P9
4fHBl/gbtuTEPE6reb1Mx0tqsSqWFTz8NqvmaXGj6/lfffNNvvzLZVals3Hv
2ehf0xu7rv+VwW6M0rYGtMTndIDpzJ6COb3MitGNW9N/zifw7fAPo5sLWERR
p/3L8spbyfHR7q45S6/Sy8y8KtOxnfo3y755lqW07Cq7hGFOzLO0upmlxdhf
zeuzU13Jo745G03nOS2XF/BomlazrPae07zPp5l59vT81RMAt2pRVrQMN+nR
vOb2f5jnMM8+fONNebg7NA9X1QxgbAnQG8z6YTaelNU4mHMNcDtd1dlyWbuD
2h3c29v9cs1CHvfNn9IZwOw8rzK7lsfpVT4OX4SH8BRAIl+ulpkpJ+ZsCRuV
VuPawH/NeTaaFuWsvLzx4PD50zMP+sbYff/adv+HIq+X0WkN4LBg6Vm6Mo+r
/Cqz6/42zZfTrKovVrRVrQdG6x7uHt2711g33sRllV+slnjRjOnB/xt7qA9L
BNiCnsmxplW9zIrgDe3F6wJmVcHV+f/+n6V5WGVzaHT+fz6lBrqIl2W9nMCR
mL293f39XXonp0cf8AOa7uPe8Gjv4FieRPcHHy6mZQHt/mX/uLc/HPSGg6Pe
4d7xcEAvFZrSi/IPy7/kAkbYkyyW9ugBPTPxmlyrbGyWpYHtNY8eP/7e1Its
ZHEnny6+e3r6/BS/qfNxxvBc95MkKbC3JWwKbuvDRy+Hh4A9vnl0NBge8oPB
vSN6cni4fwRP4K+9w+Hxifx5fHQofx4Mjo/0z+He/ok5ffj8G/l9uG9bHR3v
At58/PyUfx8d72tf94YHQ/zzae9xn9A5YPKsV01GR4OD4UVe9+B8ViM4H3o+
ry+lh/3BUHo4Gh7pFI4OB7vNzuiI8PgvixPj/Uig5dnpsxPaaSFKuu1Piwlv
EVzlpb0lpueoFSLZpYEzARwF4LGEdy/TamkOTswLALarPLumU7gq4aRXMwB5
6nqcLjNEFoO93mDQGxwwDGZVntU5jHmi45+92Hn65BHcreN793Z7ByfwBbZF
KviZJzw8cW3ykAQv08tw0ge9wW5vd3C7SQ910q+fn708eyTTTqtLvG7T5XJR
n+zsXF9f91dFvahHeBF2/KXBrUUofy4grajLvKzKMYAEA/kZbvUIcPmjkoiC
m+xwFydLAP2nvUf9V08e9d4u0uUUnsO8dgfDAYArPfFajOp6rzfPxnn65xWt
D9sOdw8HxwA68Tu/5/kMiANc7d4QvtjdH+wO4QLB0548hlmlyD7gR3gp+4iy
xr3cHRti3u9OXyVfrNumHI6ONglOEsAXz7DeaXTTfNJ/O13OZ9Ivby2hhefY
MACc79J6ak5nlyUQ7encvAJ8DdfvJklsb4wxEAfs7+/Ln3AV9S7eOzg+0Lu4
B09NVc7yTB4cDAEJzFdj/4ICTqp7aTWawlGPlkBD4JOUKOIjmN3sUVpnTbjB
/cjf5P3RsD8q5zu/t00D6Fkssip8Y8F4v7d71BsiAv/X7CK9uN0otqk/SvjQ
G2Aw7A0Qc549efbHJ6/aYb/O5oAp6EgRfe9cDfu78H90Wt4YZwA/cCtH5o+I
t8oCuVhqSY2UD+Ur2JP/Cpk878NtyWpgSHp/Ql63sq+ZYp6X87YGvI5JOqN1
/Xt/gEfnT6nzKoM9AQgcM+A8PX/dO5eGZgs3YLsLN3I+h3dXqxn0m17ks3wJ
l4ZubfZ2UdZw2nUn3LdBb3cf7o8gut63r58+Pn3+6En79o1LIp47g93+IVy3
HWRc+k9f9Y92D3f9yX67ArQGfBmMDVDMJBOYFZo4sEQkBpQLnOJsvTSyhRPa
ZqHko9sec2r+lrfwa/xvHdeGc97AtrUM/7BvTvvA5Gb5m6yOhn9YASy1vd7I
AbcM8j0ICNlsDKAZjfB9WlU3jXfU/bfDLixs1N7ht7Bp+XIZ79e3wDVGLxp9
Wfg5BPhZQ5wQOp6+OjEEHUmv1wOGF2Wl0TJJhHAFdOtjkAC0sTaLqoTTBNpa
AEgDm1bnCEP//uz73gXghLFh5gUAHXk1Ia43dIbjrB4BHwcktxjn0McKzrzW
EeFuLYCDBPzeNUCggILAH/gVinfpbMYTuVgVY5Bi+nRXcD7AYC/gTsF3QjJH
MK8LHLs0M7w8BEvjjAnmNeB4A+LvNQjG1DlggQoFLmQXYWNyGL4PEJHXBsTu
FbEM42xC9yjFRiS9h0OSiCGzqT0RHx9tsQzPO9cXid7UqwXAGRJzU+fzHKZp
kE2BfmpBewzzE7iwiDCAjXEjdPHXdTab4X8LYLjcN8tpujSwVeW1jFTjEdhd
T8fjXG4aUWUc0COZXfwUHsCs5iUcyDyD/9yYbAJQkONGcMs+AxLIhHAQCVBY
wCXMnOC1ScJ58t7hGSKj1Atg7d07bPvhQ9dBFBwH3/n8L9k4cSBVAeYFJogn
wMtUrk2Qqy6S9lTEAvhslsH3sM5EwQxmxdDVhRuFINwCXV1zPc1BKEKorLJJ
VlUsd8B6WqAV17b0AaZvHucT+Aq3rBW6iRhcgXwztu1kpnQkabIAFjUfrQgu
Gh10TYYS2zS9wg1zXXgXgjYLGKZylAOSGCcE9UAC5u7a1LS6eYaIEZYG0DGZ
ZW/pJuP0iCzAc6BZAH+4qRcVCPcKpvNsmSJzl4A8t1riljem2fdAgcZa1byL
AvzwUbGaX2QV9gcAALcT158Xo9lqjNQexD1TlEszgxvCgt8JQJ6HoQrYwiVC
6DPL3vPpVjTH1DU9JSnANUPQO3324QNgSRlZj7zK/rzK6cbBNRiNVkAMMphB
TT2O83oE/AJt0jhbzMobxHYyCMnxesZ4R8wfPR7ghuZQ1zzJeCx7hWGo4g0c
xvI6A/AILoMJeIobAfiFk3zbQZOAG6ZJ/EqPxKEals9cy4cPNNFXcNFhmadA
buqloILGFIOZ0a3IihFi8mV2SUpHg9CE/A3x6Gbr1dNn2zQx7jeregtCExkD
PxxseSkoC2c845NJ3SSgGV5yGOTdO+KZabp/muYImtMMpTv4f2AmbwBRXutc
AUvkQIbpWnq4yH2ACgtTLhgRJtKYpqGQ6e4UwCxg7VMLyaxVACYF4BMAoixm
N41x5/nldIkXKqVpTQGl4NuLmyWBd1LDcX5tpuU17EKFACv9LoH4YL88vwmx
bDpN7VtoGzepxsAaI26bp5cgNa4AgRLBq5CArWDNwO/NekDpZkJDixEjGHcv
pb9JmlewEvq6a9UoyOyuCuUAYBz3HeztqkayCReiSKu8hNHqFaJM3Mqyziw+
hsNOKxCHYKU42CiFLUVowqGSdI6KCbpagEwEDwEVBtEYziEbCyWWWfLi8Kjo
bmaLJWEpIAqJpd7Z2JJ6XIZQeqK866iyQbmSOJ1iSceJMEobYKeX8PTcxHCd
CLSpUgYkqNDDzO5tspxW5eqS0C6CkZ6ozCN5mMO+3ZgXF/8JIiDcwICh2Hr0
8MWrbQB7URsR4J8B3MigeY2XXi8jkEkeFlcsHMYc9mKGSGIB4gpe/nGJj3qW
NKaLxayhOON7+BbRCyLQpSjdasbdeeHAqO/uoblKZytog5wUt5I54GUDnAQz
XBUjOLRL3DceCfAHchiI3nm/6bvarVC21S2ObjCAWzqZlDOiD3RleUtpOMAU
Jb2w3BnAaXy69RzRYQW3EQ6JTCOrhRnsGpCERnjhgSeYIb2T2fQTAkBggfCU
4K+rnLndvIiZQGxuyQi8RrC/QfoJTDljxIusAG4IoWdSgQiamgM3Liz26MD+
oj2hXqGjS/isghOLLlw/OXXsHO2c9xVMucDLMWaGF+a5wAWI7lQYu0lZLhdV
zhcQ9xn2HaSHyx040JxlXAC7p8gP8hbzGUxXgH56gFvGdP1m6UU2c2iFbgos
cl4L+7SYpSOZR0JspTLRRDngKKSDLZQJALK25dIDgALHgSgF+dm6AeHISUxJ
xUeIClc9R5DOlz5PC5wsiMFd3gb5krlNPHtEJCiSFkjlaebUnC8eKnvg4hkG
9Hh4UhzCCoqxcDU0F4JRkOA2zoWYxUB1DbcTLhDeBuaXuUnLp8iywt1eLIhB
kvuPgwKa4wXwJ7VOG1cIFHW+oMOHc70smjuJSHCaIoBCb/MU6Aje0K6ZrEiK
qzKEesQTqDhokxpJwdBYFBNCxvi8oLWbQmIKmiuQ/gAMMgKG72INP9HvnGgl
0VSPVtdWXXCJ1k7kwc4d7kWM6jO0tHJ/Hg5vMcfKUHdROrghzattwMTKMptF
kqFKBe4TzlpNgHU5I9MGyaApQCGQbFMhKsSPAHgWJUqcLBEUV3lVsoYT5v7u
xHyRo2TVm+WAfW5Gs+xD8sUXpK2IT/AcOIjvtRVfWcENLP9NmLNAQBERivnj
UGLoth5uouKv8DmMy/ASIyssvdqe7FxB0tCjm81uEC8CbKVJk0k1ecSmolpB
NqYrfFnjoy+dPIzfp7O6TGwnfdiLN9k1HIQMS7eydWBgb9zQlcVW3WBRCcp2
IJ8t40apYCk4dEAgwCcinwzQtZot2/fSSakJ8Pw3wBTPcYZVRiIkMqg5qxkq
xNhlwdyvf89F/nKztuKHx/XHm6jknenVyPIibhw8RwvaiSgM60CUQFjCw9Bu
+1bFEKE+CwIBxCS4WXYMuZusDAmQBkkyzIfjpC5XQIlwyqIiID4BtVriyAC0
D3gnZNq3WNe1Tbquu+o/5RLVopOwOtgPH6z2Z1KuKqc28fQ9cPpzYOW6qlaA
XV2sRMrHlbBgk876dHWBewHEQvcme0swCCgkXUwr0nMQYyCYD8YjRisZoD6b
xqCL3jOnPDwsy2GsjylFihaY8e5CCDIAyrosvWI+rSMFXvuNhatYwtpU4RCB
WJuWYAirw437TGujQ+APkKQRNQN6UskhGGZEa2ba25DCmoXRlnDfv+qG8CD9
ZK9P2uhV/Tn2hYC8dbHAqqFCN+sFajAUwBGfCSyzhMpCmGpxLPdrdUFGdEGR
Sm2Rjt4g4woz1z2qhBy26ba8p6sFqriF6ZFt2Qe64t2pj26OkHFP8+nTfD46
pyjjY0qdesMRfOVKub9lWc54u2E/qpo3hLRucMZ5ZcrrorEvbQeA4+FLYILy
yQ1ChOVR+fbBkizUAdVFDMZ8j9edoMZKkCriKKbvAqnjjKwuwjBZCZDmlvFO
1r7KE9Vcq1okvnfvrHq5B/31sHdU2UpzILw6PjKwYi4Fnr64XKWie1eld6im
zq3Kh3hDj3EI0aR/XtNstqiFi5sBC4haFEWXTnEO4HGDjYTzSz2ggC16IPeq
6xA3nqO3y6RZVb38BGRX5j3zwoqcN06njncaJGZ0VxmR6nQHj8wjtI5BtcSj
TVO3lfUv+133yt6VuvmQmWHvuZhLtmkpsLByiSiBGa+AQV7yBJTCNKYR3S63
HZa6O+MOYNcSmRZRsKG61lfzqk7fPz+UcETTxdCF3XqXbbT5ZAAjzWZCiPGC
037C5EkSgxFnKdyLpblC+RiwlvDWecQAOv7E4zXca89XxGml6eCdMoWUQ6KH
RUIiimJSuMhdY76OVfXrmF5Cvg7wk+S//uu/rL1v/b9/6Xn//uUWH1z5P94n
Vi1O/8Jf0e/2psljUn6zP80DstpadA+/iZzj1cUfrxeXVTrWX6hpvkpnSSK0
Tf4pe9P6+23rryQA1BBsTfT77fpfH9k95kyMDo2/brHf8Tru8kkwOYQHlAMn
+aWTAtnCf7/zmtEbUsBzugkC6PbMrETY+YBo7927oBtgbfPZbIVq0yVBON7t
bPGx+8I3VlDQNIf26bwkKRC1vq4tqfhrvV5Melj+bLDRkSoC+Q64Rmk+y8a+
lUOlFr3/tXST14Fw8O4daRR6ombqkYs0NEdVDlGW/HLlOX3J0u2MuGNiHRSZ
kTIPwCBaHJNb36hwnd7Q9jFttBtIXVqrAOOXsZVKYN+W4YZHAnHffANNs7cp
Esxu1O2oXM3G3C3aT69g14jZEyRFneNApVrrSWSKkF3FYrKawokas83N64ZV
gSIWprXsmw6wvuu8NszwsuIUl+2hWDlTJiHO9jd2CAaho2K04bdG8kMaw9QD
LuC0rrKAlVDjozXXEUVBjRZQCFaQ8/Pw3EWbT+YAGBrebwWDwWZ23nawo0n+
dhuJTgQhcHxkSqmFk6lP8Ap61kuHQvvmIWvD16spHDhs5f2s321w7Ez5EfBE
J8+mNvr4InM7SloLn6u3vJtPpplhxW4CTn6Sz1TGQA858do15Byo/MujxzuP
//i4G7YQEWC7b/G+NQojR5ACP0F7bQ9DwI59n1RRogxGoHVVi52DFyLaY/aa
KJQfZ9INTAZJSVbK6y3zeeZZrkq0JqKzSmPttMh+dIY+4YtF5mtArqFcaEXA
ljPegltRry7q7M+rjOwUwulvEx9b5PAYHrb70rR32cbJUQMRIRAjrC5lx+y0
xUEm9S0Ly8xZjeSmF4xrnbOlaJvxNB1RsRweo9xuIMmQ6r2ORGc4tkAqDo5g
DU/JwGo/gfuY1d51D6Vv9CZp774fHq3yMHis6GMTiP5KblSrKW/ZaDHLnZN6
m4BLKqEbvpJI5GrvunE/5PO0rAOgveUOp7HE7gtoa+64TN7K5pbnFrThLg6h
xyJr0XlcOAwmgnqwm5YJFB3pGmUstVKDKu76Fft+dvkIBExjvRoDlGhlWRYj
9RqRFDKD0U+46TP+2Pp1oCPcGzHls7KBcIAHH+Jh8ivuviw62v+7b7v0Ayjq
eYl+gUyrSdpCPaMvdcLsLoNrZk+bFBq4EXT0JDiSPxjZ1gDPorMQMDm4HZlV
89CHqvxMVUONxILVGpHxZpzxTbYEzFdIMuc0LpkuoGmOLcwMB9ZhiJ9a3vAq
c8oWssVs1HUCDBZy3O6Q5umbbNPkWb797HNhlMy28Zi6iKzUh9tTFjEL1IZZ
0IfsKvU8wdQESxyMKLC0H3bBwfUDnb4kvwq+IRsvAgrrs2y0VLtPNCvlOuiW
AUPsadYYyxCZi64urBuQwoZr1bzsootsKO5gyIYKwdeg+TTEo3FrNZjotdI8
vq6vy9SViYkdzn92Ayt6XaBzDlokdavUDilGk/VSlmXJUiRXOdsvVo3+fHTi
yz+pb64kptjtklOS0YGFNua+eYI8rBxl5FcYymgiLulWeiom9C4rJ0nQbSC+
pKbjkGSH0D4rjBLnptpu8AuYATjcy0xU7U1GrSuccJp07NnTWNbf0RvMsxjw
lUdfFlQqsXar1bPxiy9Ch6JvaLVJ0u447Dmp4Obx1lhXkdqwjytMHo3Uffpf
8Xv1LdIloWPxzf2IJ3JAa0JXJZyMc6xd40Xd5q/L4rPT//mqVdIyq8PXFYgD
vqvTY7xaj8kITX1/r8rhLQziUzenw8GuiuhsQvW04eRqOnY9kCI+vyzcikLi
yr6rF5la+33uGx1dODzJeD2yZ0Ow3kT9k63qX+KPAt+AVmeKwD5i/VPUxbvN
DuPNHnEnDxB1qcKO1cWid6Jps6u68DvAXyQw2pBJjC+orSBN1xhHnGdIzayj
V+KBbDPSsiukfLHgAwggUtx57PrJWS4hvyvr8iMeY4HLTyZTU5VLe5CnxWrq
BAOIg1qie0cEw6ua7Qc8powV3LdlsFeyK+h27nzf2DVDLBU8w9CnvWHkZ/Tw
yveWAJaMg0rodN5kN+a6REeVzrPXZ+edLv/XPH9Bf7968m+vn7568hj/Pvvu
9Pvv7R+JtDj77sXr7x+7v9yXj148e/bk+WP+GJ6a4FHSeXb6Hx1WFXRevDx/
+uL56fedhv86a0CE1SSflkxO0d1x+Obho5f/7/892Ifr+09wf4eDwfGHD/Lj
aHBvH36gdMSjkaMs/0TzSYKgkzJvCWAxShc5YHCOGKinaDxDxRps5Fc/4M78
dGJ+dzFaDPYfyANccPBQ9yx4SHvWfNL4mDex5VHLMHY3g+fRTofzPf2P4Lfu
u/eQnX0QyfUAtj4kEXGJ8CcDkTOQOYMvgjN5CwJPU61UWeOsGMhIWC9JYnj4
itA1Cy8PuRxA80k6z2d5Ss5M7EOHF43wHX5EbkCLZW3VHWihm6woiiRmWXKL
0IIb3ReqWWfsuxguBwZA1pPkh4sbtTp6ZMfHMwHWUDrFuMXGRAKE2r8BRIvS
IgvXQTuJQEdk8WIlAXV6swCA7tUZOnBglIXt6907GyEJQ4hm7FXGHh2P4OAy
66ZJcatI8Ohdb2RfbtvVrMPC4puK7s6inxPnEWBPcxDwAAjWri7ClOyDi6r8
C+C56aynnpc/nF8yyio02/lOwXkReTOgpIkhXX5oAklbDpv64TRwnqjmKMhf
snBH5DYSzbzoMEh62JmKJdbfGQnj1+Li+NH+E3sm5iP9E4gHBonQIbUmP0Y1
HbDjVW3ZiMmqIr6RIsyIq3TBEsQxhO7a3liKf2tWtc9RtU6a9q6ldm6hTIrU
NSzmQkRAGgN7gUGbJfIWrM++uOE7xe5V+r27HtiJ26lovL75TsMWiEP2YTOe
GuJxc0naxopMsgpqM3YRYMYtr9q80GiL+AI6eJNjIELF9lVRcdClRA0FiCNo
EJ4xugrvT3h1QpkEm3Vw1h0mjSLid3gyGnphp1kr09lRVq7nfWyf2V5kBtxP
N5QUUR+G6mfg00gHxnoPMiQBULHJBDmsDFcpR0hxCAit9vjCLYxPIncuwtY7
GOCLtN4CX+hUXODVVUAjfO7pnBCB9I3595cpQLBw1YSU373jBAOIS6X5SgkX
DQ+gkiHWXVU5pwVgkxx/I/zqwb3Yq5yUVs61XNF6KBZ5rFvIkMY8H0okIE3P
ytEb7E1oI3PScCfhflix1+L70OEnErtkAJkO7qrskwRBoFbIRYt022QwCjNw
sZW4YL87DQBSVO7WSnvGsSWqU3A7EzrVd60ugFeBDIA4dcMZwvxE1HOmh9DZ
u8Wpm/lvHl6if7HxFh8ym17t8w8fgLV/nl1LdC3lr1inuyEdr3dw2Vs2BAOo
sdnN9qFd2NgCcocq/GE29Vk41yNeEnbHPuqZF5ZAzZkgWLuLcCQyBiqT0qpW
DoN3+imFPlSSRKLrCwvv3mEyC83aRTES6EnlVCAGE3CRPpcUvsG2STITFnpT
sQnxJFmcaoRNXJX5mJkovZgcMurInr1HjKk02MMLy8T95eA5HsSxj+l4jsSV
KFok1hGI4P1FE2CBCr7zadZoVGX+3qR2y5yDmlyUNzkKEBP+8GtGZdi71xHp
5dUsOCHtHFAdIQycemE0A14XUa7ogCbkppVfIRqlkLS65aikQW+FjFw/eYKL
RynZiQf0La9TJxRIl4yBeW1Z5Ts9KYBQxBwCnrcewg2KayjejUmld9wG5Uv4
CyDzawwDzmhqhqQjiS2k+IQqc9FUFDMXHI2zeOMWys7rLH2RcIuMUpeFmhvc
Lcgn3IlsAjnVvylAhtvui8MAUjxr6dceu+Ya1e9AZWggNKgHuEsUNjhX4CbT
RdYRWlGV5dInCRF+sqpQcgnwl5Azu4bI3/xvvoT/G9YVnTsaR7IxIK4Tcsei
IRKQYqqluW/4K3LLwbUh89Yl/rOq0huOusJjGItcxSGfvpOuuClgc+eWTz+/
rOHUi8sl68iX5YLd1xSx2kBA1JWIuYKjrILI1QF+TZSKoakrHjMqK7IKSNlf
wTx9t9KvhSdKfkbA/RmWvPUzHQf8+cD8jDLjz2bH/GCGX+mvn7Z5P871PGiD
2RNDyE5GCdEo2UFxOctcjJiE4PP2wZkO7fSpidwIibSRgxXjk3aGaedc49A6
axVD87R6g/dWfW70AGhc3vauZoPQjddLgcgTO6vTK3umMgfkqNom7Dnl8izC
261AktZ28YK8iXziKAsM2qrsCYFoZz0DPiYWcpwXpoCY6Nwcl2HRN+oh7f7x
3NBqQSGGSvgbBNcKPgLgLXADnHmvrHo47O/OHwD8nCu4nJufCFB+90+9nvlu
PgfSuOIQ1Iy8Jkc2EK74csnSEwqFuD70tmaNkOn1HiSJzONGTSEMbDIF1Aje
Ep79yTI0PxBgjnUsxCCJH3DgeOFMHxgJ5nhVicLF8xRzwTTFtCtwDZ7IGXhX
poN4rsOe202dBqtciAdN/7Nk7zmz50L0bbRrJ1UsDNN4DeICDI/iEQ8sqOLH
HwAGf/zJh8LX59/0jiTo8XAISKajaOdMjmWvP8A+Ayw0Xa1RgSNJ5C71vvlg
580HQTngE5LzkAfiXuwXlmoRM+Rp+XkpO0wEx0rxRVmTe6E+cOkD8ueC/ohw
ur400F+d9GkZz7NlT7fVUwwF9EPSA5Jog97KDQaAeqNUZECPy4oVJ2UYXec4
ELqaPeEW8gwYRrZX63QpVDfsSXU8IkA/f3b+4l+fPJcIewQdOdteW6I2ZEjd
oe/197c9vpREmGUujs92W1qiuNj5mTEf74B6U0pkYywoNCxqT6xsIfekRYxX
X/KaZVtNlhPwNOxT6Bivll5K9dhkEZz4N+LpYS4uA0+VUfqRc/L3F/45NCCx
NQVhnpQjoaYMx25kwGlRxbW6IDp0cIHOxKR7IPu6DtEJlsdoR1agqUmulP1U
Ke1yVl6ks56bpmQDYWad+GVelz2lyKO+9Ug8jTIIeG/QHtzAJceKS8jmJ9Yf
T5a1Xzo6hvmOeigYZ2Nf7OT7711Az1cARAnqLEiUEnBLngvASnLvBCY3bHuJ
I9yUwqpZcbwelRxl0zhTcWk4b/Jddj/iDd2OpaGAcXWxNjOOdnHBvTA+S7jO
fGj13rXTsDmNE0/Exke/N8/SBaVENO/51RnNEX49trNJ3vd6PWgaO1RDo3/+
ZxFm3Yreb3DAhk6QC17e9DJMH0sd6IOWDvgVfYbJZ7yP+GfLJ/iCPrBaOPTt
8L6Mnrd0EbSgvlq089RXy/PWHlvaUb/oZeRNjX/e4fsx0IsReuV4nXjP7tCT
mIi8fuyTO/Rin7tu3KO7zCa9mZXp2J+NPrG9eN3ISwYvyRjkA5h91AZi8hI+
Rqq0vJj1IsrUo8vS07srsRc+90251R29Mi/pTmPMRUMtpLlFP6oV8p2AhPir
ewspgus5owPELYQB8DMrUcKV99RrntIA5UEOeRyPnSbSZ1bNurQ1PgILzMCk
jyFmjNhw62bWOmm7LIvTSVUQzJHz9bk0Io5Hc4i/65avWjuvA14jBmReFpg7
iyxBgc6v9mPMU3OZYzY2230DfXuEIqRPG9B2KIdhD3JWbpKR9QzYh95oWpLG
mvz8Qz+SrIB+JZ31Nqm0R6saVdctqbAJtz9xH9wWx4smUBT1eH8aTwBeSTM6
7oWvGAWUM/pK/uvaCprH59QQDh2+nuYLbO3/cJ8QkrevBMPMqHf6T9QSHlIb
BFpow/+J2pAeb+1Nxw3edNH9/Wy77qee5lQ1q6SUcOw7Sy7IwDcxQAur7+Vz
DCHnImsXKZzA5WDlNvfSJqQMbSDKYKy7qZRii9h7HBhbegNrI1JgwA3UHELM
zfgBANoicrizfsohaG9ciGicKC2mlz3Pzgvd0/xdpNwVY2tIm6PfGSkRWsdm
NaiPW0Ossm2QzSZP2kDOabBCmsilwVMBP+bpBULWWg+XNKCNL+fAyeW1F3Ek
1AD3aiXBe/lStTqU6NRKkfwFQhKqtShEhKT1ymgqKEKTjjn2laONmdw371BI
SS97IJref8AS947BxLOmT5mqBoddaaHe1NBM1L/45vfqSA+PL8pyxs/YUTN4
FLgGe28Cw6zOQT6J7LPh2wjdwbsIA3Izjnlq7xf5xli71MKOPsDPGC3GrX0m
+QH3TtkXo2aOKX6gG8RsEjRQxgZffNXCp+PzhgDYTQCLtXRidnbumy3tHqcR
smjbGz6yP+GriDvbThIFErObREdmBolujhkmrhezl/BemP0k2nJzkNgpmsNE
QcgcJQI55jiRgzMDGDCAHTMYJAFAmsEwacKKGewlMYyYwX6SxIQSFs/IJK2W
hHvy0W3a9OrVZJK/bWuazhaA5NZ3NQZcMU9nba8453rbG9R07xAUJ/FU6AzW
zI8OxZ8QHYzMgM+GhsQ+DveO9p2JoM1vjWIn2QPVpSaKkAohPcBxpKJoQO6J
ObVZWpVr1FhSIDQ2jabNS+HRuNCzNhHJR7SVZJYP7Xsc3GBWxUW5IoOj+PWm
xY2bEc+iDyyWxyp/TPMit2GLaezuNq5qcNhDk4O54HyRPBXJiaL+VjaWueq6
YEHPeas9Py8RIEpvZT+3BIFniNEg1F3ffJPmM8noLcpAbiINCjJYpkI7Ms+R
LKeCGmwm1bxuutA6q67Yg5k8F7lD9I7lIGEvKGlWlm9QZWGeTiLPYljbmi0i
t/Dm0lLRma64PI63Sr+1ZxYExoTUuljxQTzUJei7KGmw0ZLSVEm2qbJIJCuJ
3x/6UahmZszBRGKaUFDNvJVg+inxG0xGM+A3zL55/RoTlnozESB4/PxMknuy
p5ul5eQV0dlht6TU13t3nX42+FTOw52xd7jpqCrhP2V1CYzWX1TKOLUwKEeq
3rmqmqWYKuxDso5dl+IXCtgZxZzOzz931EOozkZ43+cp6gT1PijmlUsxGOKt
KEJvAjGxSoA2+8fHKcDVr8WLIe9j3gTNT8dBBDlmTZFO1QxGflt0gBkJdbvW
cGtNjpRgSn13fG8azZfPKU6VgeNEKs0wAJmrcLjcu/U/8gJIpMPKypAjCVrS
H9zIBrlLv2Obbki2ilGDuEmIMoBOh+NTW2YoO+cZnVpc6bCBHpvNT+C7zo7H
xKBr2FU3WAcmGn8DXChS+a42Tw0VoyPLKFN4YiG6JluOxBjLm8JLosPmoP6u
eMBcB9DEe2uxnXgpqqeFKWfjZnMCSWEqBBqPCEUj05mlRRss1uwewXvy6yXq
etr2taCVoPvPn5ELMbKnRAqBo3VZXSHwtJHkBaDnIBesgwUIO9QzWnBCez5g
5RR4kugEtdgXnHmHKrh06LSY75PDOv7ch5X9mtnmnoaJq4zEAdpAW5ynRG7/
altoU97hEF/W/geI4uPhdPsCYBN06wchurBjhkO7SVMXXUvBZa2hd71Q6FO6
MLjb6aqbSKTdu0VyuIK1FHGKuCD33F8rWdynp4prg6+0EWkrSbf9p7/uhQ2F
QD3b7RPeT8vv4hysKnk5bUOZX7Ljv5wExwBgXps3yBtbIkzPCUyuiVB5cUkW
PL1sNXiS6oaOcwB5hI7zyx2N2uayOcubnT9g118y1y9hhMECY75mj+BXV6h6
Q0Gk6ujSLGxClW2yWbmg+Xm3p31Xbjt56ag5/0iC1Nnvh1wZ8jmbV3LlqnpJ
V6va55DibcIZd8VjarOfoNl6986GUgGTrF12pJAY+0UAtrIOp+s12ujCOPGH
tBwfB9QsnVQRaEatlydxVr3hwSFu9OHBwd5Bn1LPeo6wrU17AwndJ5Zc9iXj
xBaCSCj8ZlbWWZg5Wq3tTf/V7c1D79openYJxlVW0YxMV+75M6DKuePS4Tw2
4R6bP9I43lb7k2vZbAAwySYkcLXrX323+6mZ5oVNZ691OVATwflyNPAM5Bz0
8uc0QgugSOypTx2C4MvZWvAS+PfCKUWREqiUmWD5w5tILsTR/7T3yDyjSf8b
F0g0UZk4dbdpVFKkIzkT1QOJvNSNvDUeDzcm7zfn2czeTJ4bjiulpBk0JJ+8
q9V1YyOTAlejcNwbhCwtH7IpTz0F2UxuKAFnGnSQq2rdXmilMyECJJ2dnPMB
ow9YFlphcL2ozQYs9ia72eFTJ+K4SPOKpE6/clCmBwKN6yBNLW6NmuU8moGX
iIuGUFg211Ug70+XQ5SlXeZmxpiY4qZvzOvaSYU4QZXN0BPH8hCJ0wFpDG3o
gUT8wVNyNcLqECPKxiScCo0k/hkcg8PlUsII8jjAJ7A0tgJIrh7kUtNlSSmF
WpVTkf/DLSnGM2jcpBaiwZVTRtH95fp8YxjUpR6rgZqhkT/OiXqh5NHVeFd5
S8nakVBa+tkmc1s+TjzGE5+Pa90idUyhNZI2Wla4768wpUgDVqfUaCHP62mQ
OhFu+MiF8CkmY/UiM5miRDwVAzUNFeVhdl2zp73Xve2ZskdUjMs1FNHxseyE
ISBYSyCkOgck/u6yQioqQwX3krJqKaOMxgXz6sX3T5+YCcadYO0mrIeKyOnZ
68duQHgxX43xsT2WMbDCJN3PSs00AAL+tkS6qoM0YuSJpgb67vzZ96aDO9PR
MH24qa3Hxs5BIhiyFkHO7VDJDIG5J7/izbM+P37uBizQNkkxMGfLeUNgbOU0
R2URntu2sbWtylr1npzQTnpp6k5qv2erOyEf/txTFVpZpCHAewmogiQ1oXi5
qSxCEuQbFJmzRcRg/bGbLarfNZZHt3ee3rDKFUQIIMnZssGZuu+t46NNB+gV
dHioMTUoQQEanKkztsvlR1bXbtLIB0N5Nz1PUMx8RAGDPLAekqqpRGyic8lG
K5cEM7nN5kW5O+F6rQofgyIIr2R5NiaJrrHa65DD0O3Dq06ZE7zwB8k+afNt
Mi5ag6isaxRjYzWiCdTvBVDfyO+uEqqkY6kjmRyzhJe0lWIxsZ/aWJdVwdE0
7qMIDBUpqYuLyOqlhGpcT2+CrKjA7ufZlY1JDaCbvR6s9qTQoBMMcO2Goq6s
1JOQ6W5ikAFAKZIlrQ0EG3yDGZjWylP1pknc4tjlgOjU7fGQ5oBCgDmZg5eI
VRAIlzgDpqM3LUfriJR1baPDb5qA5fA9hyY/FFGVtBt9SzeY6cxZe0AoR0M0
P3xU9h45z4TYVjgqe77fgk3xzgxaeyKs1vkRa2XdnF2+xYaOo/b0XBjk0NB2
YB+i+/T0cM5MwM2cRpy6s1aRpUG+hJkeIuv0dRBFy+Rqm1E9zUEoPLe1RoqO
ZH/vqGVyClSe2zDzfqPg7Ch0SzJS1oIQ9sHuxlSYmPRNaybrwWPp7wNcL0S3
F579y9Z981KxuWaaNFP1Wxa3SfJC3WpE8q5yDWd5k6yD7SeIyxLtEuds8z/e
cF6Fh+cCDYSVDSM6LIchPUV6zI2aGDa0CfXzM1yOvES5Grer+xnq+V30rnM4
alqY1eOo8Yb9V/nCNV/SffG9UQMru5+y2TOzJx83s5uPmdm7As3JbezszhtU
fS1Vn8shkkguEosbyGiseXKEEPlRDoI7NHjLemOpJqm5Sy7Hs/WKaja6b7bY
lQc2x3cd+ipcUTfZTpJwjfwlq7siHyDs5IHZCZ7Bgh5gJ/KB+l/B41u4YTgG
1oq6DmfS1FU3cxBoLO2R490mcEbHMMTMteef2LG5385WF9hSPaI7Ejp1uH+o
WeC81KWe7hPOzw7l9DeEG1BAVAUZrgo1MJJZwWoia/SQmHFFY69NyWU4p556
xy+t7C9OtSM244DWcbKSmPrRtY2g2opavg97xoCxcLoqvauPso7Xokd3ue40
t2Rjx+gQA9gSJqBeXfQaV92Kr9ZBobrIgQSjksfR3AQ9kQnUdhgwtjpvspvO
tuBEVtmY7zmVh7BecUBwpDcWN4W+6A9tyoioeTf2aoiiiaVZHXVbhyFoLMsr
egziU0JnTOdb6zVBNVDL7Q/asD+kPGo6JFaZOkriyayqHB+TA3V018mrWlz9
ltPV/IKLd0IrgNspD6b+fnFYzXp/v2BeZm+Q6HzM3jDhaZi9vcQf0Oyhwxu9
27lPhnLipcvKPbTks/EGJAIYIXxms8X7D2fA4ha1/8RWfvSeeQ5s3kTuD5J4
BveHiRv6/l7ijXl/P9HB7h8kbpT7h78UYbY4qm2is+O7eIv5B6cSHZvKMotE
6KVNJeN0alZwREVuPrfpfEtUMji8IaIR7TWt0JbSi02dH9MPPtloFROQ01UM
ZRWBj3c+9v1tXAmAluz4uGwiBCtgKDUXVJowBuXIPUnKxnvbDfamCxxVMS6x
YDXFVxCiGUOHMpcrdZrqJuh9su38sp0qUaXyc+slhIxLEizICzpOMRrS7B0f
HZrXr55+7eWCiqrMIabXQSQfKy1HVMUsYWpNAA1RRM7MWx/vOB6p7vfeR6x3
W5stbuq/5axu202Dn6+Z3Kq3A7Un75aGL+VWfRVtahsT/RnNc8ODv3HjHEzw
F5jm+AaaV3jwG+1yQagOGuVMVJHN468DUxKl3re3wQse62BfHcIRJ9hdD6FN
8E8gVlkW3YqnBKco5HrIvcOJLEn31ERE1t0jxnmi6dP6FyEWa5uVZPnZPK+Y
zLRPrsuyZ1TUGX5yUI1vyORuPmE1m28K+VM6Gq5Xf19QrefymPntQleLlDgN
DU4LWm5bPh3rrQOU8E5+WZvFCrjiEfn1YhJJNiaqY4brunDaP+yK7ZhyHJL2
Krb2cBvCfS5a/iJr7mWgjHLM0ocPLkeKFuMQRZsHva49GyFdZlHWq8WsVote
LbbZUAmVJjPJTIBE76/XnznmlVREyrp6MdLtjKvXYA3b6rVgpvX3Tk/u8ayk
YAr51daQGBfXh3E09hfxtyzKYiif9zlVlwz7wIPAhvBf5W3D6O/1nK0X6+FW
YfbuJTx/s3eUeDME8pvQrMz+buLPxuwPEpqF2R8C2+s+QTaXwseih4LYo6fp
BdAGEJfCpx77Kg2AdZUOgGPl/oFbTSjoEbuBC14zn8wPnOFGn0jOCvvbt4fQ
wuwbcXGyRiTvReX3KBpG+1vQvnsA5KNHRbjtAzb4jP02fmU7fdjbOzjs99Ht
5NDug6wQNsKuDbZCVgV70VgP8O/xSu5jLBCuAXh4mf39e4nO+/5RojO+f5y4
ud6PwoLuDwaw83j4MFWr3dIH0tvYeyCOH94z74C1g/sDncgY1uV9BGu7W5wM
+yH86pKGvT1KNe4h1SgDPwu80fc7jaPpdJ37hfUgDVz30ou6nKGWiyycXOoL
k4M69b5aONkgx+XtKsNJPYQMSkLIFZHSWboqRtOYJgbFnoz5HpBI7anBUVCy
6ySxqUXFMs+rCo1TqC6kWhmoxghj0U2zGoV6ko74zDlPMzqN2Jyjehau5neP
kaxuODuag2zQcxZ8ztcEMoOQsWi9amdnMaGD3XXCY+Bd42AUETe07t+yjDPH
bdlqFUABZ2hUxVSKXC+Dsi1lFZwGLU1Fu+0T4qrIKxTnrp5+cY42prjh4nLO
fCC5gt3zKH0wF/TCvsvYDd2vfIANyCtMWIawJVs9bHq5wCbf6e/AHsCXO0Ep
d7aldZhtTM1ielMj++GcG9SBwRWm4eyLBL3eXogcirB/srNjpsvlQv9b4x8T
+r0t4+CH1GEHhz/paOiUdEbbxOpQ8e6IXJNVnndQAsv/spbgHWbJYCgcBtPe
uVBzuKJXgVXN18xac+6FM9cmxt1MDt4yrTPi/NrhltPahuPJ8TjbO+jtppNJ
bz89Ouylo+ywN7k3hn+DdJztjzpuJbVl+uyVlogkhvXOrfrrt+4zYqN4r132
tXjL/fB1TjxcJJg4+fT8O/GQ81Imc9UZpk8u3QWXmYbPt9akTd4W7rl5oQgT
tOTpimqZrPHqY900V9Uu9diRNfen3wQCzoO5Oc1zm2fnaeDGaV04BazI0gjv
1vhwqilSiu6NJB+cr4/yHXl+Lf/N0xoWcTkljMg3hNcZ5HdYlxCpa01i/1Pc
Px3zq6Tt+HMrnzyXb1//gQTfvLDDN1Qg6xOPbAuXo5TKo6U+AmogAC9srgyj
E8fZZZWRgOn2w1eI3cJPMSBgal2/1Xe4vH8oztYpzu4CM6K7tkFI+7sfgWVC
7J8VoOl/Xvlen3cC7KgKdrv7qFe5RQFN0LFldzxPD4Ey75J8VmD7HxBEcYsz
9efnsh9tS1iX70jRts/W/OonQCeZ5+NZ0Dn2s6PTo8RSHVd6Rqz8/gq4Or2b
/Inlbq+vr/s4Qr+sLnc4uT1t/44uiXcg+tl/O13OZ20R+kfDI0y8ahNE+9sQ
pOn6xF1XRi01wfLb+964Bxpv3gD2T5qXnqtU+QE4E5dCzv7jfzsl5xei6umM
MiOhlZ/rpMVsXRpo18+CJBifjk43LsUxiqx8U8TK0Z3W/53FDWS6rUeCoqI6
9sPskiyGxUyWmFSavATwClfwQLKVkpZXneb6QZgHu9Gt1NFkmjmcZ/lV8QGb
iiMR86s3bHtz7vWlRHv0jdlSd/bUfIVffXXCSSUSksJNeQHcZJjyiTBYBexW
bQ1qoesdSixSegV+Jq5YvWggcDrXnqjNFRs9Y+J28sy2FOYzwOlhOpFO67Xn
Hlqv+6bb7s47+Jvv+S3tywhaO3/A75rWZdwUBaThX5Pb/IXEWc0FmB0dfZIz
dWDcaOmhKx47SEuhaK9i8xp2sUnIH71wOOAfTOMmGk7Hjcjj4+TazuI25PqT
6PTnQ9htKxLTV2iJuZPhKzJG3cHoFQaoqfWrLeFvuxmsreUae1hbU2sYw4TK
dLN7mIWDk9U5uxUmNShgtk2LFkYUlSCCp7P2FHRevurwRSZZn8OHBWWqRICn
LO49NS2EifL8ZmiJDfqQMAPYH3i8Nl3f7zE6QnLie5n95JVU/m572KMikjex
15vk4wmT6K3m5AEdmgCLelGPepR2v+1Fyy5+tT7V83p7YcuJmv29JDxJs7+f
tJ2g2T9IgpMz+4eJPTGzfy/ZcFJm/yhpnJDZP068kzEHu0l0AOYAbYWy8eZg
mMQbbg72ErfR5mA/sRtsDg6SYGPNwWESb6g5uPe37AHXPDAl823ZFPw6PIjw
NEvXGhJ6gbKvjICGCtascTgZx0iSS7stVpWhpzN77hd87Kxdw7w9xIGwpv+8
ytHh7CyrhAHvApZF30P863Uxs39j4CP15wZLC/8e941kGXG+8LXnB6ElP+Oc
HpRvLV+62glBzhPSR9MaKeBlxuHJ41UlaeR0ucJJcE4k/4LoCezf4gR4S+t0
hm7ZvHL146WKPUTjpfePHhXzw8IgyGb/sZytUFf/ipw7uubFk2ddczpKx9k8
H0ls6d/KJjZxim7lQctWxsQsSHwik5kZsgVovzZQxDzRzHMYn+myz91g6hPq
vmtrzehcOOCejqbOAbmkQeo1Le4RRP+lcqUxbFZXvD7pmRcAiukmrTdRSnYt
arKjyvLRzWhms6RpojHmNOw3msfcZvS146xJLUQ3fJaFLIL2HlVGWxdYxoF+
iCaQ27arpkwU6KUkqdbIQ4wqyX40B5wGH4U+r756XbhHLi+Z1wg3mEOwd3FD
uQS3OYKUsv+2upS2ShkekFq2FKBjlrPMNKN0aUF2PwJinwAq9B6uQwSeVxk7
X2XjoIOPhU5JQqHT/8BV2GPGYsyXVbqYYmCXVGam7NOvzPff+MWHUj+PvWqQ
bOmenuW2dB33Wtbh5dFjm906HbwXUD5ZFSPxnnRVcW1Y21hM2noqCvJ2fS0x
qI0w8jUhvTaeBdNZISXB0u45hsdqqmy633AuE67uqlMsGsG/oV/hes5GN29t
orx4igEQjgioC4pfhFmhuWTiD0YQTeXZNODGTlDoKLnkwE2d5TY+lEKV0WLK
ob5UkajX4I914pw0jh3Cex6xZyjAlm3LcDgQK1HZDA1pqItroegWM7Pbdjwr
JioOY9fERVjkrLwgNKWT1E2A3wwjmvqcq1JbtkJii9bnp2OPz67f4Xa3JV9Y
7Iup4a6x5ysFaLO1TAoQc0JSG5bXW6wqyppAXqO8udbEzYQijP2yxZJlxhti
tlFB6EK7VE1IEV0agHmXpYA4cUaJbf3SQWlclJQyXHIPGBbHABImnOuyKY9i
FqRQwJjTWGJPLiR/VcBOLImn6FrNQAPwKRmOzpdSmDI7bgUKTb2zKx7AHEeC
bAX5TWxv2MBNjtQaEy0Drckjymropi+I5w8k7hs26HJjf01XbU7zEchLumJW
Jkcpjv1kvS2sjMSetmUAsHyLZE7pm7OWVujJafVuuNXh3LRgu4VLofy1r/9s
pGiYBUfvRuu6lK8wN69Goavflc8zDrFgNsm10dRywneTIwA5qdwYjdd2lfds
spiwILXzzkCFOp2EoCY9gyEThLQGbCppi9cxtAGGlURIkp8pKNfQqg2tVRQ4
XQDDhelizl8+3vanpMKyzqxNdAzofHseCEyFQYhIFsq9qoxWTzXBiHMl8DnT
MDGm1y05u2B8ZXVJyHKhfh+arifIP2G7bMFvEZdAJersiDTbXCQCKX1I8E52
h64ZzXJikSnQnktm4Kt81H4TlINvmTjQuDnweoY9PQG6HB+ijjxEILsAHCN0
G5NxkEZkF4Q81Q4h0xFxxA6hzjOZR0t1fS3GnRau2CUkkUxc/s23i7xYFWPJ
8uIOYVmCEDrNKva6DO84UWS5FLWHsqL7rP22cXrscCAKHYVYFrVDLbKX4LlY
Jw/qTV+TqyBgs8nqps5ETTSlyaqbZe4/VZRSvEfKk8lqxnfGzxFmBbq4vLld
rg7Jthw6OJ557SxXlqcDcBnF6wkiIeOVeNzaiLNvE1d29nLQNa8ewf88zDC3
NcYIctZa1rzpqbFUD4ihWt5J7HFWAYmGplT4yIDUq5z9S6mAVl4vZilHPnLW
JHIdm6Qiqvm6P53SIRvHjuDjy3xpXj8/e3n2yFACer/m5ngjtm562L0uyKf4
uWRzOxNhAzOljbm2PVzjM7nmwAzgjHjsLkhl/Jemh4w0lDrzexrG5EBZZu8k
C3JtpNgeb+kus/c//3OoJ76TNaPNUHDLaB6xX7xSQ/Ejl3Dssc2e4ds/vPgl
+Ji/9mKUTjH8PdG8bel4XLt6pb63IRsSg9qjsGsU36UmIbaOp7NLDKKdzh2C
T5oF7dkEhmbhMTD3Thn2HXZ4ql0E+R56z59+d/rqwwffCo+tJcJBzvbetvU6
CuuleWtGzaNDGGT9BxQHZ5sVVpNEqRKBCcjMn4Gw863uYB8dX/kXmI7/yxqC
vLHumx8wBAofwM4AXj/Bm9XVZwRQJ1wmvJtQyWvRn0vOSoIeYn+dJs/rjdwC
rI21R8VoeVvsOfis6vW0DBNzk21YREs4/89wOuLecMYadox5HK0qRP4dsyU6
D+ImPS699Lwg0bn+YpXPllZxtP21yH7hsvyMS1IrWIWJaH+QXlPgpCcuhEbp
zm4n8IoJE3Kzj3ShyIJowdOzF8bJb02HWhqUs2xS5TLdMrG0O7M53y1P6LL3
Mzgl5TDY6nzNe2GpaEoApDR9C56Ui0VZS2QGc7QIGof7WrB620sWZolb834H
HizRvfMAzLqPAAr3Nj+ww7aV77QIqa1mqiQaiiv1UGorVbS7HHXtCcwbWecI
OyRePkflxPIg1dw2OzYVDccmv15jYkM7OYdMoC+zzlHch+UbvK7YbcW8LJcs
3Sfa3pZi0PKsOfKzFPDU1YXgn6XLx6k1hAPTdduuMplpMV6j631PUmLWkt0F
K3L93hWOjTOMRBVlKddI+7/f0+zj711F27WfbidJ2yo4xVHLlK0lmfR20XhB
3doHalgW6I7ahtVpH6iVeGMRX8rF5OLSqDqrzeMkZnRnY7cxP54helK3ZXzB
JHn2iQwRuBdEY4pxHG3x8NlK6A2fQbsTAV3o1swwYZnh9dbwuLrwhokFx4aj
vms7SfNBp9BSpHhDPbqgNjHPQp81t3bBjgleLcGv2qoZrx8uKmIstQwjJ46v
Wksb32IvqR5awlfHDO4lFq7N4ChxkGsGxwmfthnuJuEpm+EgYf+A4TBxIGeG
e4kFNjPcTxjIzPAgiY7HDA+TcAPNEGZCDgXDo0TcHIbHd67ZJsIyok7y1Mtn
sxVlO0GGh2qQIp8dQZBfuU2UO0wWrIGrkUrECxTFRXZdUKBLG4wLU/3AZUHS
i5SgShlzkYikp2LVVL+mt4IbTmOg2DQWTkN5FHaqcO9wKTRxL6WdFbRskjDX
fgrcYVqNpjcbZDV7HnZGbOSy4+hkNDmCFiehBjyFIPBswzAK6ToSW4SsPaZl
sKh/Hpuo4KoghvMiA4k/L6v1IjPGV2GCzxb7PKn3g3IfMhUERspKGBbkYc2L
XFBdBFuHXBREi5JWlSbRFhYu2LgM9HouJXzJRQhWRSN7MyUYET5JyFY2drrY
crMCoaFFVlYUFTHZYsn8NQiOkk2OYQoza7A4b2GMORi1GdpzrD3FiDA+J84V
Eu0SwLvSsqjksNTwOg+FNs72iopUTyRD3l9kD9LbY0CvVdFQKF4qyYp9K6j1
xNAAOL01qrRuZH6crGx6D8LCmr9eTSW4bJC66B18QrKevUuxbmI4CL/S1yl6
5uMOMI9L0XPsh+8gVVzZ6bpZpp6i/9gQwkhwC22lVwBdqPzZvqXD9NZLZpl/
fP9EQGl75xsYZ0PtF8n9IlI5hW/iE7l9NMm0bseJfs4V6suzsQ6HLcZhT4GZ
r8HZtYfal8w6a4D9BltCqXm98Qu1xSP8LrDsHcFhzdUdOeO6N2auptPoBqWT
SU4ndoVpyBre2h/NEt5ENJas6xbteTDk50hQsylj7DrGHtSP2huCvOSjcpFr
CjE7WhQfFMfa23Y23S+pgCP6tbUgFQScw7YINJt78eSnrbT2RE+5jLZ94Exu
8Z/1393G/S5KnVVu1ZBti0QlgzOjy81knsHmOfAzrhOAC7tkmQV9oIe071tS
NbeD3RwENzwlzXKMIbl0hoFdXNQUANi1Kl7oq05BARf+lfz0e76FF/3H9491
bttr8/IhD6nLY4U1hqA4R4jAdEetPWzAgBptv9pcvKwaIYRglS7beOLj99by
YkFGERfjGg8XXQx/SCqsyECjiZLWg2gMY6G5OWC0dd9scQnmGW1BT8ehwTC3
ZPTywhYH8JkAIbsurMiST01BIdeGtAleUmYM3pfFOV8jNfDdFMv0LWtCNO7b
MUwBnATihK5bdfKtLorKMGg0Q97kyBxO9Nojd9Z6S7TBZ70oL7nTdddj4ZwK
hkeyWp0H6l5DpWCKjKuE2qHD1Sjb4GKRh0Fs7TugsSKUtN35TAZgwYnfPM/c
ITOt09U8LXpVlo45mzhrGiNDdxzFJoaSjTqTO9lN1iu0xG7SxrFqaQI/ipHD
1ryp1ptsLr2GHuROs/bUNbc08vTatR53GjVWyNxh6Ib+404DhxqYOwzbVJF8
GnDcaWCnoNbqJ1YpLQ82RgeFbdbEBYWNWEfUAspW/aTNP6op+hsOtmhZn2bp
XXeHW/tvMxtYOI036m5wGpzKncHFFkyx8KJPNqcDDxutSwgettoIMr/HPJOZ
p8bscWkjDg5DK3kj/KpN9UxpwO2wt1BS0qBmD+OY7CBm7286B/avD5S0K5qr
5kCIPD0kq7QaPn2p/ZrcYFQtA3Ilun0SSS2b9Bln8WRRjqY9rnH1GLreOc/n
Wn8SiXvgMgMciKxnr7/fH+KGY+qD4/1jnbE9PZ32oUzb4yaU3jtLMukXXHo0
O8lgNZul0yCVH8k26gu4nqF2VkuvBBI61W59Hwh+5LUY6Y5t0KpfMAvlV1sJ
Ya1o0d+W5K2NC3Ji7pS/NbzXt/f5+GYF3C6NceanWEoS9IyuxmzDZxsouwrA
ecq2OYvlNHPZaL3SOJ6TBKbmMnPYDKwxgaJvko5JZyCw6K40r9efS9/DXw0n
LTGMpJceLmqLGsUWnoXKM8z8XmvcBEY0LhAUPAq8zL03YbHoMI409joL3kZF
jDG9bPhobUbbsHppZGFscQIiMyMLGHHrzMv8K6ZL8g6Mmrk46Qe6QUzloIEt
GifYPq7wtcGo1uzE7OygdVivEkwjpKfbGz6yP+Gr6EZIMZtVlQPIwP+2VaVJ
ou2nWg/kygpSTYE5NvLRbdr06tVkkr9ta5rOFtN0Q1djgPs55nZtvqqz+RWm
xm2+8XK7fp6KPf6z8wfQyzk0/MEMv4I/fkp+YU2hT/dh+nsqZ/K3V5bkv1lW
7V8vAfZ/2xzXQ8pxvb/vclx/vqTS/8hR8T8qR8U/nLo+n1PXPzyu/vt6XP0V
nPZ+NSXg34OyyB8MJvjFYX+AqdNgW742Hf6E8zqRh1jHumdztrM6UcHR7CaR
GGcGiQpMZpg4ycLsJSwfmf0kEsPMgXUAvm8OE76J5l6i8qU5SkSsNMd+VZBQ
sDSDQRJIq2YwTJqCpBnsJbEAaQb7CbPgZnDwd+rtFzD0t68DuFZr+NlKrvwj
LVNbWia8ZyEYNi9ZLB/T5VojNNNt86VkunEiFvOlIzmYYHrvaJ8mIHW9Wu72
567DiKNZyGkOubl2Ds40m7V89dtWmvnaRLVmzNfitobGbTTN3ljDvyRfobXA
zWiu5bbFZd6dSJURBK8epVmq6vtc/PoDm0PgoFOA+lGNij66Xx+SL8xj8WtS
2/C52IZZKckGAnFNo8whpPckK4nNHO1nSLgmX58l3QybxRB/92b5JKMMP174
jdXZT2DuXvhpM/gitFP4pepW6M4VVI6XaHV/WqjdpZLcUZIDfKdOYi4vgOQp
4PgzsZHkVS0lHXACOCq7HDm/MN+yHmrDoY9B37yULBTn6SVa6r01tpSkCZNW
BBXO71AevY/jnvlNbjl4IwOIOr3FwzUqrdOQj5hC33IwVxN9TSl3r+eXRPBv
u4W2Kn3uV7KPu02el1gx+ZlG2d+pGD3aEChCWcwZuBmp7ZuNVgyi6CrvBVvb
MswRBHHlFoQjSlCGfs6UTSUK9G9LsyH+KLJKW2CJPWVpkhSUJbuLC3IbEh8j
pnLxRu/aS0GOSB13wrJIeuUS095oRhWdxDVlSqBJUOaq6DiCwbtw0d5EhZf4
tvLGwPgWDvD8vtA9eMpJd7kstWQ3xftLQMrCq1ene6VRDjDWuObS0vw9a3j9
tDp4qSzl4ig05/xMxtItTtdKEc3sbSrfcw4R8cYWt56yzsl+pbWs+wb3m/oJ
c4mzH9wuZSBDpE6fv5KkuWLn1lTDId9AKVT/KLzFGT2Kzb0cVm6T3dl0KDJx
hCZJw7tcG9DvXJ+VbeZs2+HInFBdCnUzGuXlafYAahVkv6X41rMXO0+fPAJO
+t693d7wZLg7OHBu46FViw8/9DOW3N6SmIrzaEu9n5ZJa8QtA3TbAmxus8jN
ivRW6jng9eEivT3TOuFRdsLDuBU8jGzs7zmBAcmIcMDvZV3vWyeE/977AeXv
e70efDOQNw1WUf69N88J+qNsauNyaZM2LW1ssxatoYQemYCwspC2GrskZBn0
h/09+U9/v3/QP+zfw5/wJz0dbMP0hmum9y/CtP4K05OCXT7roMlgZFB/ASnO
ck9mGbDP3r/3lIuZYihSW6y+KN1UWKqD2fBEoct9+VCnF/97j7kjOP+DNpmA
AEyeexwkYrsidh0+EP69vSth+fzohKC6grpSngIjSznQcVvh8ZNnf3zyKr5i
rqqq5xZBGGh5Meu1Y6GeIlGUtu53IhiW/NNY1DMGVE0OoGesnpDrQKYFBlwW
Q/zQAgt0jI1rjtEATDPL3uajkrILUrU3ttOzy3HtZiDJ0ihbkobMXOZL660g
7WxeA8l3FQEZ7WH7GraBCpz6sKb40ptuNNcZlb6y6Q/1C+josYBPmOmz9a7Y
lCOtoObdiwMkQzNUdQBNLODJ3rawx0rqiMdhgteeScJPQ94ODI6sNlOhRxQO
AdddZ01vQQ7Hs/xNxlWDvZlghDn79mgGNS/xuWUnWazHlpKLKaUJC1cYUixu
Y5PV2vSOlBw2aC8JWCU9kAYpcOCP5o1skiTyi70q87G7yun8Ir9cYcql5Gkg
aNh5W7du4rbizHZddMqWaZTzfLmOGvYjZmGarSqMoRuFjrsUxy8z0NIZnMRg
rHFOEZH/ku5yTsCLJzID4c2lOKJcHuhj1zMdQYEdulGd+NZ0mv0IrOWV35km
keRHrtiLIlgGc1teJnS0aSgKg1KbE0pJaB3x83rdgmjTg3gFzSvqFhlBlniB
93EjmkunHWHUf9d9aOkt3BpiUCLKwXFpyLT8Zhulq92wTz6l5j3ijCQxm8kS
0abN+q1W2TZfFxCAhx6uUdKm8A6QIGv7AtLl3VnC+3PMjoqYiRKawy2+XCE2
v67K4tILkWIv7bQO72+Al1yaM1vMUIiioqFIOBE9NKoWSTJ5wsaAV6iBdoJa
UzoJOXm//ojw89Zht1FyHc6FFNwcv1b7bnvUVgpueqKaE0zEVoHf/zKpBNfU
IRa+c2vZxM46lEg6tFlcoueukkjHyQidWBbRq64lo7QMclMEsROwPOZ60QMk
xEesGta25KsPsIQOo5hv+hKG+4sXu+2nHhWhFKfT1HN4EoReSB1q4yhyqI3B
2mLbPfbfqrV1Id/45ZC7pnNahONgniSO5qShgANNF/VqRmfucjNK4C/gnfIa
46LGOzhfuv9+b6RPLYPsfFa3nnu5jznKkjcvZQ3oVV4h7ykdcdxmynFkqESi
5JQyz1LSMktCY5cSOa3ftHWt5BTEKfLHBY5nllXb/Y4v5DgTwPqN889EIrkZ
LG2pACzOxMWNZI+C5fs5HF0sdQWcObJUi1nK3D+A+ArNVivnI4tUcC7ldyob
v0m1r2/ilKBdCSdEGwFdES4AQXoinBqt+0BWqcYOJ4npuk+fAYJA7WCU17es
OqjR66yB2+tpiTBCUcvTcjYWLIFEjDSIeV2vsrY02awPbKbp//EHC+k//oRT
P1SB3BpnbntpiYlG+sh5mjkHF0hQsP22lpNo81aLMaM9zWQg9dY2Jh6UWLEo
raYr2upm3GHVpJcWd+20ixBKOhEW6fQbUq1HviKRtknIUJ79ZKGopbtNEpFP
VkNxSEa/hTQUUeqoYhkS69aCqb+QXnvuk0qtnQ25SbKx+SaCTU4ErgN5/9em
3PGioiVF9NztKFrdfiuiHs4ioOnmvaPq79XTE/56ujbAdWM9Y+RjC6vP97L8
tVW+kxuveQPdd0T939sU6X/V2YQzwVO/zrDSC3IL7zXC+recEQeySw7+NWnK
NRFwA8mFNz/Cc+1Fk38JqvtY6e4mtouLKX5GhIeVdi2qexVYjz4vkkPPmE9E
b5UzSv1tI7agOOZvidsaE9kosqjjiK9EP3eb70rCe2nDndUVXX/KVW3zb2vI
ZJR42ynPMP21S2EMj1eLyyodk1102veEHIc+PmFeakHxK2XEM/OkHfGSMR/f
Ayp4cbmqODe1fBZ3bfzMOlmBbcecfKfmv5XvphpKTZsvOXz2PaGi4buzZn5e
N1Ijhh18TGthF6mH0tgVZelj76B1u9IY1e6DFLTZNNihHazyz/q2x63sOClh
JPFJWFiWEdilAGJQtMbfkLCMQVv5grAYgG3BKe59C12HJ9LReTXgEx/qZ1RV
x4s7JkcDO2qLS4LX2AF3mNLeTkARaFCnx43+ZR3MrWvtT/w67tXNqr1jb2bt
yoV79qxZ5/opZx0frW0hnfYR44mViHwubO5F6xjjiunGPlrbOMsjmZG6vX18
loAFqXGdL5kKBrWJA2x46vnnrJ0FbTyXv87rMK8dFdSya0ZcVzDfI93iFuGt
a5ZNJmcuXN+xapHEl+9j6+P+Q9yGpTUuMvYeQT6jlsomnLevtiHK/k0f7Mq4
1nHwI/tatI0cIlrYGFR21L98Y1v2kRqpXxH6D5UVLY7zePK4uK6BXZfzk/qF
UI0vXH9c6oNMS83ijRtguZXVhSNqY3LbSnv/Yj53c73wNawuMqWfk8nFEtKW
yXUFoD8/k0tuQ5/G5K7cm9+cydVlROwt7txvydXq+Hyx1vOz1rLcqnx9jom/
JLUDgJG6F39Ns/nxB4SRH3/60iNgUXpD+IY4BZfKrePxrNbdvnXs8/VDtEyJ
OdnC+SF7H3jMFo2/Z8e3LtKffe2rgpwgXP4OwpfXeZ3BFFoxDQBSG6bxarD/
YgTTWqF+DV6RUvKfileSL8zrV0/Fb8M6WAauQupmuQwQC36lNljPu1CLmhRB
al0ip3TkkkOXXLj0c60s4GVuYzdexi3+SKmWsfVzzrp8jbyhsmWSIYO03kIO
w4WxG3ntW1njsdShPNHdvyxx8bBgODA00yY//F9CNXtv4d9PjQcnmPvFPBn3
T4xks+Ukyc6PtWsWLGXKdxTBCR/1TuEf7xRuPXbj/FyXzXPiStTzUhxFqBsg
/3TKCMmrKldPLvT7JOrRwb86HggQ6Mrt5bJNInqywbhI5y1iFxwG9CAbyQ5H
ZOZqWiuQA7gQE5G4R1OYmUsDTeacqEYd4/F1mWuZFPWlxiNvTGhsJ1dproUr
lY1gnArkQJeohVzJCqox4kqt+n357CeLVgJ1E8yGSKnRi8ksx2JJdGSSBZlz
2HLBihF7jzF4sZvwu3fkggsQi7iMaAcPJwdj/ZrYDR4P5UsASCAv0PeX2pip
E+491+SEE6fz4P23FjDpUz6yV4kYRuHjYjbu4oaMY3xIyI5KVKCnxVT/iOv0
piGLx1EYLg+39UMm8grbx4JmLlYo2zvaASN3efF9ES1rmKVX6qRyoFvXwhlN
zC3S5uFGTlM8I6jiI38nVVdoC+X6WTiArcXJOHBnvjva3OAo7S0gMZuiG7z6
fWmrRti/GyLjy85rdAReWSksQ/beaiz5q1z2qWF/ILmn9o6PDgmvhsyhZGEi
55fa5jCSjebcaP+V4LpOhuPJ8TjbO+jtppNJbz89OuwBpjrsTe6N4d8gHWf7
Iymk1IJqUAnm0A3++nwoJ6gB6kW2t9Y057gmPFKMIzQ2BlOkP2ReYYx/f4mJ
sdzmfAbkRBvvLWjsb0XulVJg6UxK63pErmsuANegf5DDB9BrKYo46AAVYr8Q
JzHYKrG0uFFHpBywiIOSW+AgFRd0mYzjtjehJt6NFvQ0yWfoEcvXdSXXhnQG
XqQ1nLJ3jiJuqpOs+DUJ2vHSvhJysJ3wOcXnj6W23hIMf4gVhARGPOqqXrpy
ALnDRQE+ldlHc3ebR6Jz2Yh+8pcEc5QwOFTDIrNHuGyLNFxhv9vWOZWUlPjZ
OsQbHAJerU4bIk5+E0ScErK4Gyb2Yakbsa4iIvDVp3BDwHVfmfONKPsia0MN
DS98BRSWES3gNb4j7vyT0fhXTBK4V3Q+tGBAvL0NliQ3oUcvvODJKi1qLqrO
vkheU1fIwmhe8FM5xrVheYwzJSRPFslzwZlzpQeRz6mgNDDdE/RazCmAzS8n
gFXrKGIs3gbd0a5xG7Lf34Nd+N0/9XquTPk1fFSfoL3WC2FF0B6llWA2nmCd
3tSmk66WJXpRjxLak3lO58KepjdYF84LosIe+qbXeyB6GIwNA8GJpY1Hsh+s
EhIJyuJOLqPt+Hb6ZBR80o2JRxKCa726EEmhFr05RaJ3zSHlWBZpx9bU1Vr2
wqIacY7/M8iEyy4/Ih2D52YfVIgJItf65jkM4QU0HchuR6OSxlUGccFsKKRK
xjuKSyQeQOP7KFBRyxnKtllhd1VTOkmvYGDNNWKs5opQGedOTBdcis3fdy82
0O3RDUvs46TjT6ID/CVTQ19wrC05TuzXaaU1deZo27Oe8e/ePXz0cnjIDmEu
tex78yotLn37myE7phvEUPryMUqhqvDZ7e0N7x3eCz45s1LLqcsXb568xcSl
0N9Vnl2jugS+O+rtD4/3jw/vDY8P6MtAQnylmausYiM+IaTSvYWdlGo42s4s
XgCqPU4BqRXoYJlfRTGTHOVIe/pSvD1ek6DyVGCxbe8zEx6UPcdEZHOpKJDB
hmNxGaw2wljdZ7BtqU4ffBghkF7TFaLyeHE1KXEmfryFUd5Np8LDubEnbbTf
9kjZhRa59/dWsBdHnDC1SvAaPWPEpTJ4ju4pNulK8GafPBaBJw2eHvjDUDqW
4PUhma44N0vw4h78pEQtwdMjMmJTxHDw/FgtYNEacfFq3PWfD2LbQvh6KHum
7vPh2z1/Se1NcC8ib/ewAW4LZYQJHx+St6umhwnf4Y5Qrpjw8RG5MLHrbvjm
mLSXIvOGh4v7QillwscDGaJ9VUPcFsxxEj7F7bCZZ8JXuA2ahiZ8g+unnDTh
YwYHP0FN+P6eW2xbr7QXMaAPcR+W7LLhPfb+7eF2vC5SusKsaQ6xZvQbr8HA
3o+WiewNaeubl25vj9YdH+IebpSXOSd8iXs1Zg81/zHBis2pE77DfbIJdsJX
uEeUbSd8jJvkXHHCi71Lq4kuyf5A71avubn7uAHIEodPcfXNdD1hG9yKIHdP
+PqAMEAjkU/YiLfGZfUJ3+LmaIqf8M2RHmprvp+w7XHUtnExDnDbXCag8B1u
XpgWKHzPjomcIyh8s+feaMKgsME+nZZkDwpfETKWVELhG9wxP69Q+Paee9u6
4QcB5d9wl95vIP6hWSMg+kqmfeJfazoaDujEj3uOLyRmL4gR5d5f2RaxOspX
3ntsKSXYQHjM6zkxBoVjSZkb48gFFxKKebm5UGVG0VXCVGiQY5TtBuPDEKkX
UlTL8+QsNDdOqGlHGXR1IZ7xllVgxhj7JeEuuypnV2qPzKls8EIkH6eFZtvk
aFqWtahfWBFmK2lJxR+u8i7sDSx5eZ1pUPJ16frrmzP2WxUllewCwRPp5VnY
gImwoL7SMjZ15m18lxcAmAuNNVxZWav54PhdM2UWacqWnYLto3UwdNyp9cLB
IEmCXzHYkrhuiTnqULfgwPgggHcTvSr032FY7aBWw3H0VDTeFzh8RtJjZblm
xDrmO4JEf9pUUNyVd/a+1ywjltOFFfJ0SGoKOVoV+FFzli85XEmKGzLYpbdh
8+EUZ/mISpWla5h7bWKFkobaN1gdyW3EndvzdFXtY3mLtoBkGlh7b4BHiKlz
2RFJ2Hoxwoe5CURy32dVhk4sKPkuo2iv+6rhspUC/PB2TPf589FSZUBm37UH
YG10YnEfolAKckdEffmwJGtSZ4svfNmFpHnaHxyb+H/fBePjG+lvGG/qltvS
bRvdX9jSrRmXPRUFK8PbaEY157PiKq9KFn6+9sYRYR17ryM3fEsfvL5Fp0ZA
LDp3GzPL9lw3ZX9JXbKdoZG3kORiVPLpcYkhPZpvJcOkCapFcsVXsytEIMTB
OXW1q3uPyio2RSRj6o472sEPuO7Jnwhpko2v4zeRyGquNkbjkmrDVU+EOT9/
1fv+8XeSJIgu1ese/4hBGGjtwdHxLuqhvG7p/lj9ILrv/3klJguvphvtJ8Vt
e12SeBvMt69glepu+bY1uSZsG2GjSOmbQ1pBypUhE4kY99qalC9X+ZiqnOWi
wxjcO7IldwSZItbpARsHZ5unfAlCjPRI3iXJ4wwhitSQGTWpZdu9dG1FhBhV
aVQDjc+WkaLWu6Q6A8omcE6YmL5riOY8pGMdRjO0hViPHK+ynuJ0nBI75vBm
eU3YWIc9YNlQjUbLmSRmTuElRiAKWhSHO3EhJ48Ua8AVhVv/VmtQlaCjs+OA
vPKgXVEyM167gXPucWlBDKaTS5y9zeuQa4h7+TLQrRnBAV0/7j704/KgGxmk
HWGYuK5K0vMzOHmEETkO1Hw2gJVvhy38GdvYA4+OEKRZE13/eZUubZCivZCY
bgPrUt4GMhnUsS//KJz9nWwo6QI9QiqCgDW0HxZ/tsbLAEY9/Q9rk1Hta9Mt
iKlBoDTTxlxSmbZ9E/X3AhTK0WhVqa1mrf+D9X7TEswWN5QBxLQv2tjEanmh
TCcWLiCjJSnhQ8sloyDk92Widb4Um4GLhdLTgw1FvaL3NY+pp8xW68BqQMr+
Z9+zgTk1z5+dv/jXJ8/FWkeVFtk42Xs7n7F2KCVJkzJU+qaGPcx8pQWbA3+h
xnTULxyWcSFFZO310EpRzmVJjW431tCJ63wVsZdXIPQshcf1dmac16NyVaWX
Wjr3tsjQl8ih+ylwtqmHxYRuIZxbrhfPHaiViyFYpm8yjFzGVHe++NfIWBdJ
f20ZgmL9vwVHZ8VYq8L/ePohGxwhX1oYD4BYF5m2Zr8LeDZ/hsRwhrk9+Jg8
ZzjPoe3HH85fmIdPzKsnz1788cnjk2Bq4gg5pbyKuL8S7J5GBBFdulTPd2Km
y+WiPtnZub6+7uMR9Mvqcid1SvAdT6j68adWC0tDpPFU/01/w3WS1QcH7B7t
rutylBPKZfazaRC5hS0EM6Pt3c0MQsnUeocHB3u3toBEec7abSAb4G2TRcQz
SjRcf5xl4mlsmWjJEHh3G8VHbCt3SODVYnDRJDP4BpBBfiVOAqyVkFRpbTck
CSDL3hA1qOhpr8uRuN7KElrZhHg2VMnWqVqbrkusiANJEEJrUs4P1kV6XU+a
0O42Pe0FPa3LU3ibnvaD5uvSE96mpwPv/m1UKWoKQ+15XSLD2wyKPR3I/b29
HnNjqsINgL5Wrxk8sFcX6bgtEsmIh/lGK6C04s1QiEJoX8eRkkAZCUzi1e4k
jdyiZ5u8hRlovdphpis/wZXR0EIRVW8tshjrkm3dB0K0At/OrK7Qc7FhJjBw
w8JpXgD7eU3IXJkmzzPcZbNEcKE9WQ8zPhcSpaYKWZBmPo7PxX+0ZPq4M/MR
JL1yya428R9eZqt/MB+3Zz5uw3cM7wm6uh3PMTzqDQ9uzW/4GWg+zmz4wHVL
TuMWTEbqMoD9qozFpiQ4n8pVNOD+oyxFM9+ZT5I2sRO3ZCWaSdLW0rwgz4/H
QzQzoN26iz3bLs5wdusuHPGOc33duosD2y5Om3XrLg5tuzh91a27uMc38Q68
w/qEUOsA+bfiGiydayZ2Ckldaz6Wz0Xt2pO93JngeSGaUbaoTTQvSg71D7L3
90P2opxEH6d8EaB9RuJXxKmyfnU6+JEMSX89UsgH3LJ8fdWWM+yThWtNNPZR
ShDng2oI12ou+JSeQuFaHBU+qad9oS7c/LYUZmM2rg1QgvD1m5MZSafVQmBa
EiF8VhrTlmjhl5AZm6/rHwTmt1Tqeg7ud/Ntv5NS16YFuSWdCYDt85EaCt1u
pC7765CbjYlK7kpxmsmR+BbdkuC074H5/OrcZua3Tdid0rI0aE0zS9tt+gip
TDP72m36CJW3zQxpt+njIOijme/sNn0cRn3Eacxu08e9qI84PdZt+jgKGjaT
V92mj+OgYTNB1G36GOwGfTSSPd2qj0HUR5RY6VZ9DBUL3pn/aKZI2oww/uZV
42mrcvzGc7fAuQQpPaRCV+g5hWX/0B3fo26W9jWxnvqx2oIPGOAx4wzmF9k0
vcrLyjnAeqML50L29Wk2W8SVLDES1XqdSIhFkAvOxjNzXqLSS6uylJIgNJcr
dvLksJMgiJcqvDCDM7ExulIaM2T6rMfjhuQ0n5XX83Le/BIWz2ar+iiLhy3/
wdz9nWkPMPnSLfk5BKjPy8bZbv+KLFxbKqi/Guf2vmXJjkh9Fq25n9fs41SQ
kl0FKnM/N9ntv9/zvne5xW7//f6ddcxrUoe1nvdvRXgB22OAxb+MLgAcnxG7
ScfuDwsQjFE6LqScqWk6HkfYRCbEGc5cZ35Gs3fv/olcAF0IW83RCjgoouYT
nyYmydnqYule2anivqjzY1rBO0xVcmIKYOCT5IXCV/PVE0y7gFMNw/FPzMO8
wPCsLZuXoeZAc3ICPzreP6Y8JggeNksXXuBxtkzzGTrFnWWjVYVqubhnBqk6
G/Xg/wELc1oH6oJwQ5QlLf781OcQyJX0ssAajuj3+ya7SdgVYJHmlUtqhuwQ
15VCz1Hy/wziLpKmIX6GcLQE1oTGsUlPI0z2cqVpBoI3Jy4qLQnm6+XowAq4
BBF4nOxTwFWSXYyWUsIErleGOV0KkGGIgHNuirprrlazwu0VtqvrsEVKmViS
tHUamCptKXEadFhXcBG89X1TpZfU3VPNFlNFuR5ODOcM4QKwVFRa67LDySYT
7cCmm6n8RIMIMh1vajsWoDvM5HmNk0Zjatc3ZusUM+5c6HMforxwsqJszkY+
kNkrhlgz0DYcpnPG90oQAo/wLL3MR5LiYqvePqF0IOnlJZY94FrrE0r3cbNk
fmyavT0x4xTjKA/uYRTn/r764/JncDGgmS4Dhv4m90GSxuBYMBx8hHlM6ikH
ZhMY4a2lRnzPXZPXRY7OI1g7Hdt5B4ufnGBtmX6eLSd96V2QK90B3uQ+egkD
7HM5mv/DwHnnM8R+FZXSLLnY1YgD4tSVOtiup0/OvjU//i7P6ss/0Fgw6AO+
++LfD4B+Yh69ePbsxXNEbTUVpiXYJa9qev2cVna6Wk7L6sR8lwHleJhXb6bl
7C/QOUgCb/oX8vsPdb7sw+mvimkJXEp/nMFwj6bE1uFsK0wXBJ3gxBJO0HH6
EiGdwmK/Ycfl25AAooNUQbL5PbtAe6GViUMA6vXeafkQyEW9ulA+9qbrmJrO
0yfn3yQSgwJd076eonv+FVZgZH+oreHBYb9/fHy83fUjFmCkV0+Sl5YiBDQJ
4O7e8GAIQKj0aQQ4tufox4cPxBg/cwsI2AZLVt7jqoUXUvYQmZ/WOw+teq6P
84ePB158r89NjMp00RvJJjFcIeae1fc7MwMLt8G7bYdAXAQeMZKz8/TyVuc6
IwEm00xPuoXSRRtBxwVhWXF0pU8WxByDPHjjhA6bX4kplh2PNlb+4fTem8fo
sk8ZNpAhU+x6u3/Eae4dHw2Hx3uU12GeLuwWP+IS6J5867DBFsPotvnxBz2C
H3/yz0DWF0VK65bIJrsMdyEnx/GBmGkyyH7cEmfssgp78ToSEMtVQ4N0ejaL
m5MFJOMb7H1eqIybz1XvRNPRqCcVkBG28oJ41CkTZLq6GisdhpJ6uYlsmEGr
aFNnVgmTFw3Nh7H55ELhlgKX2vpQL8Z6lXOG66jAfRTiHcX0cBK6INFrFJui
UA4Ug9jrV5rEw4cS6GM7kcy53i2wnitjQyEffCdcSsRamG2CEI01wJM0776w
2UDXXEYbjBRqtgQo+klTRyGfc51ArqlMDpaI5g6OD2guZ847+yRhzhoeUmoI
/P1SDyfk6HbgwJclop6It6vD7ppcoAht9u71ADOZLTyoepvLQ9LdTEzUgg+z
3v7aMLsQZ7SNGepHTIxxEkgtDFC9vAL6OML/+tS3SQ4TJogtlNoic2zTOgmP
eUGUcUW06P6Xu19+aD12yrjHR28TJX7K8RMi6DfVVMknggD29/cIBpKp8bcH
BZnIJnDwEqI9w9BJH4/B02enoQoLoARlx+t8nkqScUe+CoyjxpxFz4AVxWSg
iP5Ol+zKl/HGPjvd5hRcp73z548iasPi7f4AWR+XPk0jBimgGxigaTmWypCc
ZZLD6YF35bzPnA7HL8GS68QwnaBWF/dKsNhUVn75z6DwDpOzEZd6dClgyQP6
LRUbUo09LbHlCiCHrqpo1hMH6gm7icRt8EHEyoo4GFw2StH7Iu0ti1HAJVL1
eE7foesOTjbIFfcyA8l5l+WAS2THgQUcJslzUnXchlfxodETwR+jMpBK7za/
xXENHEpbt5I1R9WIaVTbLsrKALcFWcTCyqAauY+rxTjL04fPv4nT4xGTd/rt
z49ePTk9f/Hq51dPvoUBOj936P9fP3/6b6+f/AySAjTkEP9mY1vgmvI8Ob2/
ToHTKIuPFL1G+4xkFiCfKdt8YLbCqAk4vQ5lLJVCotuukJCdm62FROH4Xs5m
GqyvxQO9Z7bAeHMTB4c9lJHNBaufUO7DirnhgBr0aku82KQW1O418jr0oWuh
vKSnAgT4APAdEnLS4HHid1ZVcbJa5eOTjqQg6OP2I6Jpbn5zNzgEtijYLkY3
MgXGckUJikn9hKKU2fpZxDFO2n9jaxzSl6SRm8I9Gi2pfDJe/yWnTxArleQs
gv+gjcqcsfpVABRFEqBaLq1p2lZ8pBew3hgqzFHAXUIzGqE9qm4Wy/KyShdT
zCJNVkm2OVBpgyWWX7dJU0iHJHCnw/fhPstVmnWd/U4UxhcuMboAmdlaapkn
mPgMd+hySto7QHQzOOerDN/gV4BUx9bQ2Fae0lbgcfdWr3e93U8erVsbbsAc
LVp4MlRC2dMt6XzHGS4eOW+v1jwlOMqpRhXIGID2UlQ3Tdq3SLMGa0OXZNsW
BJYmTCgYpFWOdt3NsxQFCTbkkNaFy8ydbz5otqbh78dnT7/1UfW6Q0cmCX7g
PBwutPhMMhq02eJILHxx8Z8ILdoD3p0nBQ3FpJeguTevL6mYh49t9cZfw4wW
YrDGnL5PqDP2MYErv6KC2F3NbYINfsYGA0kBzL8IIAk5k2KOa6+lWDoBs+rQ
TaqYCsqEt1xH21rJ3cvDY7cnyLuwFr5j8fHR48ffr6k2gkY1UX1hxiyUM8lA
RyufZumYqloptWVoD5LL2JQodE/hgXykFmFce59z3NM8Euy5RyuVrGi/k7SY
D8x98wORK9vZibmAyRnSdLinPV64JlXjAbv05arwvvV+bPhERg+H4mfcwG4+
N+kmPyUJgRFnsLmPt8TsmCW84+die7qPVztJNs8BWr2jUQbm/gPsqduuZPka
8NRlCVdxOvcU3fTlHn65RsXNK/jK+PN9YLxZdhPgcD+2UXaSH+mIKhMA6WAh
HpW9PapJX9X3Oem0cNMW2N2N8vPuzEvWWAAqLDzY79JPSqWOmFChkEq5t92C
rqatw50RJZt/4+kqnf6HQjJfmpA54XT/9QhYriovmapwLqGe1a1xPRgWsbC0
cc/ZHrwzsYk+2u/CZ70Kg7/KXfgBoMEeJCOnn+hufGRyFph+OdyGI9EcPvvt
uuvd+bSbk0Q7ed/c4fxbFn4LCGj7wNEZHg6O8zZ32tmslG0i8vEdb8GoXKHF
1evcu3WG09WnKkArPfFmqxQF1crC1VD3GUi8s3IhqbzkYhOJp/FwOC0J4l9E
ytfoZkQFWqi4B1WKwgxsmFogt+yn5HRxs+fU/Y4iK5XVosYlTZL0ra4VqVhZ
VWkdwjCH5lbez/rIG+AvEMbnC6zdYTmTkNR3PRmE653ZjJ3djzLLDvNxuDfx
s+0WdJhV4RvQtx1a9oxshnQGN7JMJxpIXk2piAifCQeErB3bRHrnZID0ZQnz
7guxSrYWR/OoAzcjtAunKB0h70dphyjDqrF5kjwWso/KKVzw0mPv6UOtrOvz
m4Ec5xsjQJjz6sgLBwTb95+rwnPCWjuhNJzSC+YiZRZ1e2ou/Cjoz+rl/d6A
53QGYUrTJ8fCOxWekRtMy3n4xhUVqfDU2o5XR0njr1xKMOChC3abmpRS9yS8
tCB+sNVWF4II8LUc6M+qXKMrRa/Ogxfe9IrG4j59hu27HN0en4AzDgV0rXMQ
rAr8YPA7id/fJ2VOXrMKk6xcOzJr5QXiBg+SoAskpCGBhXX8Lhon+ib+ZNAY
NHz9IEnC1+fImXxx2Hf2vq3z7SRpzsNjZLD50dZ6tn+bSM8Otjv22jWb3Y69
3IQ7UsUeHhtI+v6ayyeqyGeh1F40dIqWb/VKRhfGCETWknUsDTQO5B2iJAH1
iVn/EvA+IO9xr5xMaps2kLRoOdvvoItqRWSDkhMz8UrZpf2mhzr1YrsLs0dp
keQ8i0eAnqajKTO9rXdfinxBf5c4Q0QDmE73KkNfCqzVif2OV8UYlQtqFsUP
G4njWJGwKOsaXZpEd6SkA/VGSmOaFVwCE+caUqSaepRJA33AaIWeGpSokoyc
Shgd4SOn0RUqs5f5SCihjzHhy2WTOfBHYZc7cjpx85tifAdlerV1lXCT2Xdq
jCgLmBeKwnCV5mAo3M6RTnJRLinDpVgiCpt3EnPOzUqy2dJsm4p+vAzIIYja
xsvOiMV2psjFpkjiOqoT8mD9GrgtgkgrMCWuBDqzOlXfnBYm6MnvweomfEYA
eJHV0q9p6NRjzn+W5TOC3TzboFFDTVcpelvm/0SMK9TtklnEvMLwQa86+vl0
hXrINTOvpSaWLdkdtGuupn1yLCSOAcAyckJmUZQUHX4Xcrv09o4zpDW29BZr
sOn6EjcKjcrxjVX0qqsddE++cjcBI7l2Q+G0dW3CQ/sc3/lUPkXXLlWNUUrH
VsDHRSNumvFA6Joy04zX5O4X5hitR8KHB0EAxMg2cI86ofnqZeAw4dBrX9GF
FZ0uECHKJKEP2VW4dShcrxac3Bw5pULNUzUVJwWeAiGdh+6bhzdsZ0yxMhO5
jSOJF0hmBs7iSB85pjP2VMBwjoICA0hRrjVIiA5co2dvLx2NxDFNzhc23Kk6
3aLchnteg/gJ1WNk7y4ODmDTSX45XVIhEufSE19XmhEILJisPL/ETPmKY9yw
XJMVEViGOY7FcudqQ+d1gAQD1YZfkFVwoQO+AHUieeU9msQvv/ar1FJyV0wR
PWGrA2u1AZyAEPYYkmyJRg+U/kSpVWPUJFhQ5SMcV/fBU9vbnZCTZR/UjEut
4iW9hnOa3tjt5yAjl8c31L/echC/RNhVLrQc4yZh+jWOPMoqz0OU/BN00LC1
hD+49plnUErFZ5LghCRZBYDwejM/Es4SSAGmEOfjcp69uCK7K6gmriVmo7H3
fUz0ZgtMpss1MKr2O+Z9iN+3aZ6xuN0yq6w5WUIPcbRbn0bTAOlF2TTsja1z
xMxrXgGMPDJn4e8qnVDFZTLbcK0GN8Ov+UKjLNFtvORoNL3kF2txaz85RV4T
7qiU0qMjtKyLW/i4zJihRC8z8qlOR07WF34cnQqWbLI5QQyG6lM8dXYgheOu
mMUii1Dj9BJYghilGxVee8rWakFNr01Q7IWdwrP6ayUeATpxilmtrKj+Z3bi
WuIcLWHVHFPxMelnjzQmlFLHViewIoPD9yVDrXiYkNuDqHtg8mPmvmqbIJ/2
xKeA1xRzxswSGVeXHmMQcJXs/u5pW5BY+F3JaTjdDbITsLM5jg23VusNkveF
Figxs+wSBIE5bYpcXJQb0M9HtRfNi0ZbsZ5926bzzwBmyhukmt482jYHHa15
A9inI9CBeVhw5ngMnKomQpRyjLyTCKwXhLfYimiJtTVBLutsNiHCjW3ZJIoo
GuUGTNFZx0yKdCy3SvkE26Hb74KCdNy6qHgMfUxynfZA91pkjSq70kpfAW94
leaz/7+zq2uS2jqi7/oVCi+GqpllwdghcZIqg8HeMhgXrLNJJVUpzaxmV16N
tJFmFsa/Pvec7r63r2YGcJ5sQCPdz+7Tp79iJOR0LydrRwMpSmHrlKunwTT6
OmIzQghmuPQycCm/vqh3vYq5HGZNM0XOE+TTOthV8pnqtNhoTv1TKTSgQFXv
9W04t/gwnznEh2vcY0DhveVImpU09mvAlZEZr8sh3L15egON0ZvxpLiokUbX
1He1iZvGwNYSLwB7iq5ZFIhDH5Z5HU4a/NwrfqGYxNRq/Ww3v6ZTmJNPInz7
nSHDdbXTw8hv3nSwIpo1A+U3NcKnDWjECcijY2FvVwHf1pXIMoRvDT0955rm
Jqcl/JMMXwIdCgOE2OTJABNDqHEM7c6bdvbdcHILDP5XgIN1NfD2tcjjYfBd
DuCjUWkJE0GTKVbYt3f2bR3eEwR2FBBNMz3tDHUfp6Z0eb8CoLztVZwKubyJ
rEHMvI4hYRbKNmN0IbMrHyS15lRl8gNUV7A8N8fM5c5HyJHthSCisIzNyfZk
iH3Ix0lzz2ShCr9QwADyPZSRf5FaopU/BiEu9G5nfZu5yf7XwgrRt7DcttWA
drdUspZb+Y14JSm69W2Xd5QrWBHSVKi9710jCPuXck2JHmBNwJp6JUKXFTrt
fuKEALFWY8MOHEHQ3DGZAPlEhWqT33KPpohRAP5xsvbsiDOwgYIK1XDtwrt3
e4rcKLWM3AjQODOn8m7z7jsB8k230kELayDR7lKUqdhYn5xOal/k+lCojWd4
IkJFBqw4RYYQtOntUIsgOrzKq7ZfMMPL5T6vgmrhGXSn0d74hVUSJhjH65bV
VpuQN5JACM2/XjRXW2LgHMxE4TLUKDN8JzSV6hwHTaBxkrh3fPplbfZxrz0m
xOFdpchNSN8U84g+sRJcsm3DHdc3RXQ/DcjCnAWVVBb9CmpSrq1YOVpJOYuw
CmO0/Gj92Xjsd+k3XIjP1Kqw0myJeZu4GyOViLbdDn+7CgofnN7YAG+ND603
Ly+gC7Y1jLi8roM+xBYE3DCfZAqKFtMe7/bjmQT2rRsfGMUDQMbZYrryXM38
xbMDscKzst4sGT8pb/CTHTX6TM3qFCu2VDzGRXgPftgl5OEhV1N04nvsERjK
c72WuA1+chj0eiu/kGCyDuYbtNAAN22WFVCbieIoJ9xnozETx3otDQI1BpJc
aGzPZL3XGTxq3CI4ogVjl173mVYOB6S6YcholS+Hlz8BvNB8V40l2D7d1RZ5
AtkUEwS6ayh3BTQFLI0OuQdEt7+RSXRLi0YJSVn3sTxBgHhROFctkEqcfRYC
3g/yu6rNwsQTJDgp3iT5Gz0d6v7/9M/DphcbkFqZUBZoceQt+06LYN2uAwgf
sneclOWbTlzU4TZ3KTlZhrg2Ao8vKYSrz20odykOOEqwvqLQkIPfD4Wsr3yW
2xu/2GzsR+YUST/TbbHsTH6B7Bxaj/HURgg01KvWnPnhZm2JicHvLsUtutD/
XRU5wXFo18ryna3ZTPxQbZsMfW2yOkIz9kArSwkulZPhVwMypIyP2yyFdS4m
IMDMixRXWk2oGM9PQ10QZhbSXcur/Ml2cPzZSKXNXriEuA1F4vhjy0em5ARp
VjJdGD+p0K4Jan0Sv20Eyt6pSH28FGCW5Q8mlFxEbr+XpBFOPPaVR1MiLdPB
nfL9+SHx6GS2JwCw1sBUPDk+UuUWBPlaottTNQIseDgr0qgsAagD+SMo2pLH
QvQaG33bQBM13XWzaKhdYVhnXjkImwH9/xRARYAZpaTY3UOtDbbY+1D/adxs
g8SjZAoHRzh/h6BnyWsWVjAYX3eTcjpe+8GDCno5yGpAJrb0Woe/vsKTNLmN
q6sm7i0di9QcYg9nQkiobHHW3crIXNv0kfxuHra4ritmQB5wSAMSj4loaIWl
Af87ml+Y0dUUKAX/ns1YR5w2iAHUQArvTs6VNx5pkj1xVIZQaoTew8TXVZh/
25maok9oAAAZxkZokfw5QeUQi56Pw2ddABmyTsVasRrFpnBkF6TecFVrGDnP
SNJAIp2spJZYj37AOJwdoBft6I+YA16EWGGr4hNevslddxclXPaIkQr9eGRC
xKjoVGNHkMJEqrptBe2In+OAyE39rUZhkDGpIUpVY9rcSJ7tCtiYAgWFiGjM
s2VjCMASriO0VIwJBUl7rA7U6sA37QKJxoK7AZQBK8ZwrZXHgbAGCxFmjpaN
Dab8efBkYll+hilGpVIksmCx3ZhnSPVkdOgKhYlbhvxmcFFCMILfsmUx1i/I
qMtdNP4JSnMfXhTiYBZRSEtuijuJTv7HVIr0qyHc/iBvRtCajlKPJ4xHRhvC
wHs3i1R6egaCI/wPjDVx4A3ha6xRgrAD3J2q3Y3N6A6cl5ByOved00FF2nqM
9LWrfN/Vm4+tRJjwS3PLheUbcVkZvFWkLJRJDCIKezTKiCo37vPb/JjCzIvo
8tW7m9BrRi1wbRspMcf0Vhx+ZfQqCWfjvJGhFAzsJtz9rfFpPNAjCpxM3f5y
tNIr6uI4CFG3U7ASch8P4oLSWAv03AUVfEjs5FpYwX4w+leSf/Wy0WBaBvJt
PpFkw5G5fqo6PoMMB9I/8nbb0sl0G+d6L4wY76rvCULlzFjejL61tu9vqV0T
t2BLuw4bvUR3I2MKvaGxIUpcidFP+NB3c+ODggiDgwmOn3C5JZzHOzAjXSFA
xm2yNZb3wpXeEJFE265tbmohHi+lyNJBhO/iYgBBxaduDkb3fPGR07kUp5Eu
RoAEzYeNhvJoIhld6mHa+kf7qMzD7ldh9yvDJiLSI5Hrbnpc9UJXHQ6lW5C6
aGzZ/KYHHPumRj3/zFJKptULX5eJCwcvpIqkCe2+rLpUjOda4EPQFtDOR43l
j4Ubh+VxRb9mRZanJeOcxnULmcyIYjYLX07iywhiRUflscwzJ10OxDB1B8Ex
EyBc5hzwPHdjkiLKs/NJQDLTc3IAG3kVHL9OnEQJAUrO3sJliyfPgRg3J/Ak
2CyK9VtdJ+xm1LQaXjeM4oZSzt7HdWhQh6I02XxQJuVSKuz19PiyYJV48hMd
BZ+veHOqVcCHjQnaqruxECRou3FDVy9peqQihFF8gLkbkIGduRkrmeFNetRG
pa7k6u/TxP6CTw1TLH73xUZ8kdXo2iSH1SFwuK/IwaSAIiIWQUqCR7eRq6z/
lBtthH5j3YYpPphJOB5+O8VKwSa5JtjmhRSNT/EBpBk0FbAA3F+kMmYlYriM
4etUSbsnO3SbxZCuyEBOn5bt/CKP+Elrd7Kv5OO7m1o96nZ/Mva9V8fJR103
bpMWTm5ZyoUoYbSq99DQ8jGmQRR39Wajq7auYPryAvSrtJfkGnT+eMO09LCm
qXvAk4Olk/JVUB7vG+RvCiBVw3BR+28a34jAhKk10Wjpm0UtRRAz5RGptLDu
UsZsTaOUiDI96w5GjpptacKeRf5JlK2BSMa6eWrSbcqoeQImlvEZXbv5QZBE
eVtq7Y5X/RVifYWsaLphtUxh2P/+1/kPZ+/Kdy+en5+9+anMSvyWz/5Znv/w
AtUTyhffnZ2/eXuCKrzyVuUQLITg0WMNg5Q/PWG472sSmwh3cqR+gp5iEFv2
anj+ZfOBNwq+lpTbbE5Y9oMWrhRocXAyBLiJlccm7eyTdT4HIIqf+O+2khAk
2vVaykgWldAlPPiLsgf2z/N0IzgQhHeA9g/ofCONop0LYb6u0VlbDfROw2zw
RAd78IotvMXsqj8EKXm7MW8kWcaz+XdsaCNnHzyYJDHY8OnPNFKXf2A0Bpds
0Nipq6Hf3lIZhNXFPNfVLT5L3nndCDy7lAi1sP2v//7ibXz/0PegRtE+vIqB
O+QNsEay9NEpEX51DqCPs8eDvrme14JCRi1CzZOCrLA4rhXJs/l2VE4NTeKX
w3axCG9gDZJ3bqllz1OUe1Ypfti2tVtOGK5BDlbdUmMxUVcMkPpEJq9hkeL9
30ik7y6IzZM4+ZuhWl8i1KBr1Ox/9vzndByPvIdTvPj+1XOtNSvdwO2qhCVO
F4VXI72iCqK0C2oYW9R0aG1/SRkOryM8L+HuV6OYlnz/KogI1Cg9ibvJo5Jo
EmWTfjl/OX+a/Ivy+K8S56w+FK1m914Ds1gtI8oeCV6mExQZhvj987auGCB1
6zunj+IJ46WV6W6uBxRqsAFZbOhMRBAPXtim7Tjq/X1aLprwr4++lv/qqYqj
zR82Rzprlur3eqlert68WLFa42c0Mg2aAKB3CbLl2BjTqrqvVuHR7tIVkwc1
0ga9rLaP9ZsVlJb3eB7TGytDbUeqEuPHIGp5AdRdC52RJQJksbb2ZldSPi8z
9znV8fBvgi4d1+/KBx2R+KdfZhL/EY/1W+RO8LJmZL3Q+h9ckqPUONbaQ5Dc
3hWGB1QAWM0/czX2LWhO6sqYkp7WQbj7VAZCC9px3FA14cEza7oLo69jK+hY
M1u3pxMtGg5SG+a9ra5qzoyREmrUpjRYin7tPYAzJ4nDC1Tpb3pR1ktEg6hY
jhVx3bHosh3f+RRHSUrUcCTmrm41S1WLv06upX+R+iOC4P4g7ibqqKiOlo21
AwBIBnDm0P3AUoVbYSao7EYV3qo1HVCstRVzciRRrqS3xFGX6pZ0aTs6Mcz6
oU4+FV0+cQrZDgbLIR5/Hz0eftQqBVxpeg043F98rvqJ0z3bjvZf/K28rXJ3
L/6DGwLp/2s5saYonNTmmvOepTLJdm0nTbdYPYk7XUk8fDyZM0G3oGYoA0XC
RcjB3c9GPtObhsFhi9AAZGCCZoB5jx89+hPw2vtwYMejFz+Deqdf8uLb7rCg
Edc9r6TEvxKuGRAhjLfLLwZA5tMnj58e/eqj7KuiRV8A8S7lMie3XVhPVELZ
C0eXsfWHSDh3SKWUxGJXqKoyfoyxE94rKompzbLOjgpw/qqCx6DpAj5rogUh
1p8dPiUEfZIQkIp6lX56ff7mxxc/3X/34AGQEYkAbnucBiWgm8Ril5SrQCye
d5Z/vu4xSItrU1c34DnhxpAJNqC0dY1w4NHpLamOM7lu/qinqowryHkX7+0q
p6dQHviODSQe2+/TbL9FvXwb46ZiFqZVyyN6lwzUUt2qqjMbeHA1pS9oXliy
G5tjef+9UJKbYLKGD2Q1Au7V69vN7l4sGDU+cEti/jT220mFefKsVFGpoMj+
M7L2EJ17bFSfp1vdd/WDEI3TseCVRun0WCb/bbfv1wirRRwasmxpJlk1WGVL
E01B0iOsu0xdx8ZyB/gfSsGNlFfIxCTemWKEx7RdSr1c9rcbA4oX39N2mZ+e
KhqYQnd8v0o1GH0mVLwkHyPQ08wjXl8M/U04COttu2nm+fE9051PAsJvFSny
++4k4tcPZPLmq2LKH20XxIsoDXWZXiN6SBxvJruzOc6SlGt3ccz/OHn01ePT
tMjxMuqFlQXuJZi6dAuWy4d36VCYCknpOk2Mk7hDTZztqFCFY71fz65OytU4
x989OHYFv86u4B/NcKlzwfKw7uCJV+AZjRXryJq2jHDD72x8nZW9Vh2s0iTB
ulRa/FAt3/iciWqNqv/os7HOwJGn7Oy+PXttkv7DXnZdY9CWxihIHKQeuV8/
vziPv8butxJGG+Tp+r2Eee7DqPg1wVmSCYoTAkVvoQJ0xfRtf7Wbqvzw5DPw
bUPMi9Lf7KElyz4VakGtHrdbEhjNdi/WIcce28dMr6yH1OQXR47WV9nR+ppH
6wwJGneJnmnq0QN2RPj2I/x0HNhaJXl2+ij53kPP2RWJQ55O338wDDi8Dhto
OzOPOxN/d2wqT7KpfMWp7AM1MyKnlbgt8nqyi5OYkLDdDjrGdzrjiOcZ3YPW
6kaSZVK9cjeehAEM1S7u+lrK6w59SuyL4qmyjCBWHajWGsA1A5HSthJSycwc
QW9CU+Dn36llemC5y1gM2aNyglrG/28mp0rdzVEhoYAEaRn5K3AJ8LMbvjxV
GWJVCCQ3JNUWBevNDBJvSvh55hBeKGKtFh/jPj7PFD59ospvLqSIWIS+/5qs
gScGjli7ekZkr5pOW+pw0ZQTmHIFhFzkNues5+rCVrQU8/+D6oVgzdkikf4u
EdbQF0agqOz3LQMVshNAGQsbd2el9RtncuQv6kV5DgQgZ1Le+DtMiIlwkPe/
NPnsLqr21ku9K85imPhrX3NTCxBDcUA920jICDOblFemkzXl+PSqS90EEWqW
JSU1iXqDLwKuWT1WQgEkLz73qEXrVab2zryQRmixXF4da0fGWmZi1OaLelR+
H0TnolgvztWGWkn0K5pBatVViTejr1JiLqPI8WwzxF7Q9XMzXFwKNUWYVwpi
mYBAi3BnT7l66r6Yz+cl6NOCHpJvlxAKbX3JXkAj3CQiEurLv95jtkCsVRMb
QgQd/36E0+KukThSjcxY1rebQ7V1H569eJ63tpikLpxroqpmPU36M8LviADY
1baNEJPcEuTvjfFp+n6JVwVY7ElAX9QSgko34/QtyGvCn4WHHDNjlGNHB5xE
Z5eSwoEk0nAkbsbyqscheFZ3v8KpUf5YXW5vwjeLv/whrHH5CunSFyAS/lzK
7msy/1Ce//zauWbyYDMNuC7n878V/wP/8IK8jOoBAA==

-->
</rfc>