From 425ee58ee60795be084861d000e54c1adf8d8ca0 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 9 Feb 2022 11:22:40 +0100 Subject: [PATCH 01/73] =?UTF-8?q?Nits=20from=20=C3=89ric=20during=20IESG?= =?UTF-8?q?=20evaluation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- draft-ietf-sacm-coswid.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 111655e..a62a565 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -198,10 +198,10 @@ Binary Object Representation (CBOR) {{RFC8949}}. 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 instances sizes, which can benefit from a 50 percent to 85 percent reduction of size in generic usage scenarios. -Additional size reduction is enabled with respect to the memory footprint of XML parsing/validation as well as the reduction of stack sizes where XML processing is now obsolete. +Additional size reduction is enabled with respect to the memory footprint of XML parsing/validation as well as the reduction of stack sizes where XML processing is now obsolete. 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 {{RFC3444}}. While SWID and CoSWID are intended to share the same implicit information model, this specification does not define this information model, or a mapping between the 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. +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 {{RFC3444}}. While SWID and CoSWID are intended to share the same implicit information model, this specification does not define this information 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. 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. @@ -291,14 +291,14 @@ XML attribute and element names defined in ISO/IEC 19770-2:2015. 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. This section describes the conventions by which a CoSWID is represented in the CDDL structure. The CamelCase {{CamelCase}} notation used in the XML schema definition is changed to a hyphen-separated -notation {{KebabCase}} (e.g. ResourceCollection is named resource-collection) in the CoSWID CDDL specification. +notation {{KebabCase}} (e.g., ResourceCollection is named 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 reference both XML SWID and CBOR CoSWID documents. -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 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. These cases are specifically noted in this and subsequent sections using an {{-xpath}} where a manual mapping is needed. +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 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. These cases are specifically noted in this and subsequent sections using an {{-xpath}} where a manual mapping is needed. 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. @@ -446,9 +446,9 @@ The following describes each member of the concise-swid-tag root map. - global-attributes: 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. Described in {{model-global-attributes}}. -- tag-id (index 0): A 16 byte binary string or textual identifier uniquely referencing a software component. The tag -identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching and lookups. If represented as a 16 byte binary string, the identifier MUST be a valid universally unique identifier as defined by {{RFC4122}}. There are no strict guidelines on -how this identifier is structured, but examples include a 16 byte GUID (e.g. +- tag-id (index 0): A 16-byte binary string or textual identifier uniquely referencing a software component. The tag +identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching and lookups. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by {{RFC4122}}. There are no strict guidelines on +how this identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ensure uniqueness across organizations. - tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is monotonically increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to 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 MUST be greater than the old tag-version value. @@ -466,7 +466,7 @@ class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ens - version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Version Scheme Values" registry (see {{iana-version-scheme}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values based on a Version Scheme Name from the IANA "Software Tag Version Scheme Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. - media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag -applies to. This item item MUST be formatted as a +applies to. This item item MUST be formatted as a query as defined by the W3C Media Queries Recommendation (see {{-css3-mediaqueries}}). Support for media queries are included here for interoperability with {{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. - software-meta (index 5): An open-ended map of key/value data pairs. @@ -478,7 +478,7 @@ attribute to be included in the tag. It is expected that industry groups will us CoSWID tag. Described in {{model-entity}}. - 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. +CoSWID tag, e.g., vulnerability database association, ROLIE feed {{-rolie}}, MUD resource {{-mud}}, software download location, etc). This is modeled after the HTML "link" element. Described in {{model-link}}. @@ -576,7 +576,7 @@ The following describes each child item of this group. - entity-name (index 31): 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 {{SWID}}. - reg-id (index 32): The registration id value is intended to uniquely identify a naming authority in a -given scope (e.g. global, organization, vendor, customer, administrative domain, +given scope (e.g., global, organization, vendor, customer, administrative domain, etc.) for the referenced entity. The value of a registration ID MUST be a RFC 3986 URI. The scope will usually be the scope of an organization. @@ -733,9 +733,9 @@ The following describes each child item of this group. - global-attributes: The global-attributes group described in {{model-global-attributes}}. -- activation-status (index 43): 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) and relate to an entitlement. This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. +- activation-status (index 43): 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) and relate to an entitlement. This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. -- channel-type (index 44): 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). This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. +- channel-type (index 44): 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). This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. - colloquial-version (index 45): A textual value for the software component's informal or colloquial version. Examples may include a year value, a major version number, or 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 only and is not intended to be used to determine if a specific value is earlier or later in a sequence. @@ -1573,7 +1573,7 @@ Deriving Software Identifiers: TAG_CREATOR_REGID "_" "_" UNIQUE_ID - 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"), 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 MUST be represented using the UUID string representation defined in {{RFC4122}} including the "urn:uuid:" prefix. + 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"), 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 MUST be represented using the UUID string representation defined in {{RFC4122}} including the "urn:uuid:" prefix. The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double underscore (_), without any other connecting character or whitespace. @@ -1617,7 +1617,7 @@ In case an unsigned CoSWID is tagged, a CoSWID CBOR tag MUST be appended before ~~~~ {: sourcecode-markers="true"} -This specification allows for a 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), retaining CBOR tags attached to unsigned CoSWID tags can be of great use. Nevertheless, redundant use of tags SHOULD be avoided when possible. +This specification allows for a 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), retaining CBOR tags attached to unsigned CoSWID tags can be of great use. Nevertheless, redundant use of tags SHOULD be avoided when possible. {: #sec-sec} # Security Considerations @@ -1752,7 +1752,7 @@ Changes from version 01 to version 02: - Enforced a more strict separation between the core CoSWID definition and additional usage by moving content to corresponding appendices. -- Removed artifacts inherited from the reference schema provided by ISO (e.g. NMTOKEN(S)) +- Removed artifacts inherited from the reference schema provided by ISO (e.g., NMTOKEN(S)) - Simplified the core data definition by removing group and type choices where possible - Minor reordering of map members - Added a first extension point to address requested flexibility for extensions beyond the @@ -1771,7 +1771,7 @@ Changes since adopted as a WG I-D -00: - Fixed broken multi-map members - Introduced a more restrictive item (any-element-map) to represent custom maps, increased restriction on types for the any-attribute, accordingly - Fixed X.1520 reference -- Minor type changes of some attributes (e.g. NMTOKENS) +- Minor type changes of some attributes (e.g., NMTOKENS) - Added semantic differentiation of various name types (e,g. fs-name) Changes from version 06 to version 07: From 36f9c52c8235fa311db4cd09cd04135fc5f33737 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 9 Feb 2022 11:32:02 +0100 Subject: [PATCH 02/73] fixed redundant BCP 26 / RFC 8126 ref --- draft-ietf-sacm-coswid.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index a62a565..2a2dd26 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -78,7 +78,6 @@ normative: RFC5892: RFC8949: RFC7252: - RFC8126: RFC8152: cose-msg RFC8412: RFC8288: From 29057dde820c26c1710918dab8d384a581c6999e Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 9 Feb 2022 11:43:34 +0100 Subject: [PATCH 03/73] fixing the correct ref entry helps... --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 2a2dd26..e0182df 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1123,7 +1123,7 @@ This registry uses integer values as index values in CBOR maps. This document defines a new registry titled "CoSWID Items". Future registrations for this -registry are to be made based on {{RFC8126}} as follows: +registry are to be made based on {{BCP26}} as follows: | Range | Registration Procedures |--- From d59efeb5ad0e55dc686673eedcaef8bb1db6d6ab Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 17 Feb 2022 12:10:54 +0100 Subject: [PATCH 04/73] Adressing Ben's comment (1) --- draft-ietf-sacm-coswid.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index e0182df..a79ded9 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -285,6 +285,7 @@ XML attribute and element names defined in ISO/IEC 19770-2:2015. {::boilerplate bcp14} +{: #data-def} # Concise SWID Data Definition 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. @@ -303,6 +304,11 @@ The 57 human-readable text labels of the CDDL-based CoSWID vocabulary are mapped Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see {{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 to identify the construct to parse. The CoSWID Items registry, defined in {{iana-coswid-items}}, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis. This approach avoids the need to have an explicit CoSWID version. +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 exclusively meant for private use as defined in {{iana-private-use}}. +Encoders SHOULD NOT use string values based on the names registered in the registry, as these values are less concise than their index value equivalent; a decoder MUST however be prepared to accept text strings that are not specified in this document (and ignore the construct if that string is unknown). +In the rest of the document, we call this an "integer label with text escape". + The root of the CDDL specification provided by this document is the rule `coswid` (as defined in {{tagged}}): @@ -462,7 +468,9 @@ class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ens - software-version (index 13): A textual value representing the specific release or development version of the software component. This item maps to '/SoftwareIdentity/@version' in {{SWID}}. -- version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Version Scheme Values" registry (see {{iana-version-scheme}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values based on a Version Scheme Name from the IANA "Software Tag Version Scheme Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. +- version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape ({{data-def}}, for the "Version Scheme" registry {{indexed-version-scheme}}. +. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Version Scheme Values" registry (see {{iana-version-scheme}}. + - media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag applies to. This item item MUST be formatted as a @@ -579,7 +587,7 @@ given scope (e.g., global, organization, vendor, customer, administrative domain etc.) for the referenced entity. The value of a registration ID MUST be a RFC 3986 URI. The scope will usually be the scope of an organization. -- role (index 33): An integer or textual value representing the relationship(s) between the entity, and this tag or the referenced software component. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software Tag Entity Role Values" registry (see {{iana-entity-role}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values based on a Role Name from the IANA "Software Tag Entity Role Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. +- role (index 33): An integer or textual value (integer label with text escape, see {{data-def}}) representing the relationship(s) between the entity, and this tag or the referenced software component. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software Tag Entity Role Values" registry (see {{iana-entity-role}}. The following additional requirements exist for the use of the "role" item: @@ -675,13 +683,13 @@ The following describes each member of this map. - 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 {{-css3-mediaqueries}}). As highlighted in media defined in {{model-concise-swid-tag}}, support for media queries are included here for interoperability with {{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. -- ownership (index 39): An integer or textual value used when the "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 it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software Tag Link Ownership Values" registry (see {{iana-link-ownership}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values based on a Ownership Type Name from the IANA "Software Tag Link Ownership Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. +- ownership (index 39): An integer or textual value (integer label with text escape, see {{data-def}}, for the "Software Tag Link Ownership Values" registry {{indexed-link-ownership}}) used when the "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 it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the "Software Tag Link Ownership Values" registry. -- rel (index 40): An integer or textual value that identifies the relationship between this CoSWID and the target resource identified by the "href" item. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Link Relationship Values" registry (see {{iana-link-rel}}. If a string value is used it MUST be either a private use name as defined in {{iana-private-use}} or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml as defined by {{RFC8288}}. When a string value defined in the IANA "Software Tag Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software Tag Link Relationship Values" registry MUST be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag. String values based on a Relationship Type Name from the IANA "Software Tag Link Relationship Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. +- rel (index 40): An integer or textual value that (integer label with text escape, see {{data-def}}, for the "Software Tag Link Link Relationship Values" registry {{indexed-link-ownership}}) identifies the relationship between this CoSWID and the target resource identified by the "href" item. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Link Relationship Values" registry (see {{iana-link-rel}}. If a string value is used it MUST be either a private use name as defined in {{iana-private-use}} or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml as defined by {{RFC8288}}. When a string value defined in the IANA "Software Tag Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software Tag Link Relationship Values" registry MUST 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 Tag Link Relationship Values" registry. - media-type (index 41): 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. Media types are identified by referencing a "Name" from the IANA "Media Types" registry: http://www.iana.org/assignments/media-types/media-types.xhtml. This item maps to '/SoftwareIdentity/Link/@type' in {{SWID}}. -- use (index 42): An integer or textual value used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see {{iana-link-use}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values based on an Link Use Type Name from the IANA "Software Tag Link Use Values" registry MUST NOT be used, as these values are less concise than their index value equivalent. +- use (index 42): An integer or textual value (integer label with text escape, see {{data-def}}, for the "Software Tag Link Link Relationship Values" registry {{indexed-link-ownership}}) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see {{iana-link-use}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values correspond to registered entries in the "Software Tag Link Use Values" registry. - $$link-extension: This CDDL socket can be used to extend the link-entry map model. See {{model-extension}}. @@ -983,7 +991,7 @@ Note: Multiple of the corpus, patch, and supplemental items can have values set {: #indexed-version-scheme} ## Version Scheme -The following table contains a set of values for use in the concise-swid-tag group's version-scheme item. These values match the version schemes defined in the ISO/IEC 19770-2:2015 {{SWID}} specification. Index value indicates the value to use as the version-scheme item's value. The Version Scheme Name provides human-readable text for the value. The Definition describes the syntax of allowed values for each entry. +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 {{SWID}} specification. Index value indicates the value to use as the version-scheme item's value. The Version Scheme Name provides human-readable text for the value. The Definition describes the syntax of allowed values for each entry. | Index | Version Scheme Name | Definition |--- From 9a8c6fafc1595a9a514b8207c2d669f150d0ce96 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 17 Feb 2022 12:14:42 +0100 Subject: [PATCH 05/73] Addrssing Ben's commnet (8). What a curious oversight. --- draft-ietf-sacm-coswid.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index a79ded9..fd70b79 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -368,6 +368,7 @@ The following CDDL sockets (extension points) are defined in this document, whic | entity-entry | $$entity-extension | {{model-entity}} | link-entry | $$link-extension | {{model-link}} | software-meta-entry | $$software-meta-extension | {{model-software-meta}} +| resource-collection | $$resource-collection-extension | {{model-resource-collection}} | file-entry | $$file-extension | {{model-resource-collection}} | directory-entry | $$directory-extension | {{model-resource-collection}} | process-entry | $$process-extension | {{model-resource-collection}} From e4aef22618492386df3547997ec9a9e440e1665f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Mon, 21 Feb 2022 14:55:34 +0100 Subject: [PATCH 06/73] partially addressed Ben's comment #2 --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index fd70b79..23f9471 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1005,10 +1005,10 @@ The following table contains a set of values for use in the concise-swid-tag gro The values above are registered in the IANA "Software Tag Version Scheme Values" registry defined in Section {{iana-version-scheme}}. Additional entries will likely be registered over time in this registry. -These version schemes have partially overlapping value spaces. The following guidelines help to ensure that the most specific version-scheme is used: +These version schemes have partially overlapping value spaces. A CoSWID producer that is aware of the version scheme behind the version value, it SHOULD include the optional version-scheme item to avoid semantic ambiguity. If the CoSWID producer does not have this information it, SHOULD omit the version-scheme item. The following heuristics can be used by a CoSWID consumer: - "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, the "decimal" version scheme SHOULD be used. -- "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, the "semver" version scheme SHOULD be used. +- "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, the "semver" version scheme SHOULD be assumed. - "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, the other version scheme SHOULD be used instead of "alphanumeric". {: #indexed-entity-role} From 5744d3bbe4377ea89e7c654c3370058f1d226669 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 14:28:46 +0100 Subject: [PATCH 07/73] markdown... --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 23f9471..9f92186 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -283,7 +283,7 @@ XML attribute and element names defined in ISO/IEC 19770-2:2015. ## Requirements Notation -{::boilerplate bcp14} +{::boilerplate bcp14-tagged} {: #data-def} # Concise SWID Data Definition From 24e72c9481d69938c88d77eec420bef0401493de Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 15:05:19 +0100 Subject: [PATCH 08/73] More updates for Ben#2 --- draft-ietf-sacm-coswid.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 9f92186..b601f7a 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1005,11 +1005,15 @@ The following table contains a set of values for use in the concise-swid-tag gro The values above are registered in the IANA "Software Tag Version Scheme Values" registry defined in Section {{iana-version-scheme}}. Additional entries will likely be registered over time in this registry. -These version schemes have partially overlapping value spaces. A CoSWID producer that is aware of the version scheme behind the version value, it SHOULD include the optional version-scheme item to avoid semantic ambiguity. If the CoSWID producer does not have this information it, SHOULD omit the version-scheme item. The following heuristics can be used by a CoSWID consumer: +A CoSWID producer that is aware of the version scheme that has been used to select the version value, SHOULD include the optional version-scheme item to avoid semantic ambiguity. +If the CoSWID producer does not have this information, it SHOULD omit the version-scheme item. +The following heuristics can be used by a CoSWID consumer, based on the version schemes' partially overlapping value spaces: -- "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, the "decimal" version scheme SHOULD be used. +- "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, the "decimal" version scheme SHOULD be assumed. - "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, the "semver" version scheme SHOULD be assumed. -- "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, the other version scheme SHOULD be used instead of "alphanumeric". +- "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, the other version scheme SHOULD be assumed instead of "alphanumeric". + +Note that these heuristics are imperfect and can guess wrong, which is the reason the version-scheme item SHOULD be included by the producer. {: #indexed-entity-role} ## Entity Role Values From 70f3434604c52e4b7187b59dad9cbf95d23aaa29 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 15:11:38 +0100 Subject: [PATCH 09/73] Ben#3 --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index b601f7a..c6e9c9f 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -629,9 +629,9 @@ $ownership /= shared $ownership /= private $ownership /= abandon $ownership /= int / text -shared=1 +abandon=1 private=2 -abandon=3 +shared=3 $rel /= ancestor $rel /= component From be1172c572de3d6b6f0ff9a6599f93fd96899237 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 15:19:08 +0100 Subject: [PATCH 10/73] Ben #5, IANA --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index c6e9c9f..b89010f 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -302,7 +302,7 @@ In most cases, mapping attribute names between SWID and CoSWID can be done autom 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. -Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see {{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 to identify the construct to parse. The CoSWID Items registry, defined in {{iana-coswid-items}}, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis. This approach avoids the need to have an explicit CoSWID version. +Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see {{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 to identify the construct to parse. The CoSWID Items registry, defined in {{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. 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 exclusively meant for private use as defined in {{iana-private-use}}. @@ -1219,7 +1219,7 @@ The following IANA registries provide a mechanism for new values to be added ove {: #iana-registration-procedures} ### Registration Procedures -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 {{BCP26}}. New index values will be provided on a First Come First Served as defined by {{BCP26}}. +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 {{BCP26}}. The following registries also reserve the integer-based index values in the range of -1 to -256 for private use as defined by {{BCP26}} in Section 4.1. This allows values -1 to -24 to be expressed as a single uint_8t in CBOR, and values -25 to -256 to be expressed using an additional uint_8t in CBOR. From 719ebf5437d7b34461bf3113bd8babad89816953 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 15:38:18 +0100 Subject: [PATCH 11/73] Ben #7 --- draft-ietf-sacm-coswid.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index b89010f..4f9f8f4 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1597,14 +1597,15 @@ In general, tags are signed by the tag creator (typically, although not exclusiv 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 for files. The ISO-19770-2:2015 XML schema uses XML DSIG to support cryptographic signatures. -Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption {{RFC8152}}. A CoSWID tag MUST be wrapped in a COSE Single Signer Data Object (COSE_Sign1) that contains a single signature and MUST be signed by the tag creator. The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header. +Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption {{RFC8152}}. A CoSWID tag MUST 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 MUST be signed by the tag creator. The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header in this case. ~~~~ CDDL {::include sign1.cddl} ~~~~ {: sourcecode-markers="true"} -The COSE_Sign structure that allows for more than one signature to be applied to a CoSWID tag MAY be used. The corresponding usage scenarios are domain-specific and require well-specified application guidance. +The COSE_Sign structure allows for more than one signature, one of which MUST be issued by the tag creator, to be applied to a CoSWID tag and MAY be used. The corresponding usage scenarios are domain-specific and require well-specified application guidance. ~~~~ CDDL {::include sign.cddl} @@ -1613,7 +1614,7 @@ The COSE_Sign structure that allows for more than one signature to be applied to Additionally, the COSE Header counter signature MAY be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID. The application of counter signing 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). -A CoSWID SHOULD be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in {{sec-sec}}) for more information on why a signed CoSWID is valuable in most cases. +A CoSWID MUST be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in {{sec-sec}}) for more information on why a signed CoSWID is valuable in most cases. # Tagged CoSWID Tags {#tagged} From 767f23583de3b88b723cf795d69db1937f32712d Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 16:22:24 +0100 Subject: [PATCH 12/73] Ben #4 --- draft-ietf-sacm-coswid.md | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 4f9f8f4..2aa7ad7 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -298,7 +298,7 @@ notation explicitly relates to XML SWID tags; an attribute referred to by its na KebabCase notation explicitly relates to CBOR CoSWID tags. This approach simplifies the composition of further work that reference both XML SWID and CBOR CoSWID documents. -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 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. These cases are specifically noted in this and subsequent sections using an {{-xpath}} where a manual mapping is needed. +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 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 {{-xpath}} need to use SWID names, see {{uri-scheme-swidpath}}. 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. @@ -679,7 +679,7 @@ The following describes each member of this map. URI needs to be resolved in the context of the endpoint by software that can lookup 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". - a URI with "swidpath:" as the scheme, which refers to another software tag via an - XPATH query {{-xpath}}. This scheme is provided for compatibility with {{SWID}}. This specification does not define how to resolve an XPATH query in the context of CBOR. + XPATH query {{-xpath}} that matches items in that tag ({{uri-scheme-swidpath}}). This scheme is provided for compatibility with {{SWID}}. This specification does not define how to resolve an XPATH query in the context of CBOR, see {{uri-scheme-swidpath}}. - 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 {{-css3-mediaqueries}}). As highlighted in media defined in {{model-concise-swid-tag}}, support for media queries are included here for interoperability with {{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. @@ -1094,7 +1094,7 @@ defined going forward. {: #uri-scheme-swid} ## "swid" URI Scheme -There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in {{model-link}}) of this document. 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 {{swid-reg}}, the scheme "swid" is registered as a 'permanent' scheme for that purpose. +There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in {{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 {{swid-reg}}, the scheme "swid" is registered as a 'permanent' scheme for that purpose. URIs 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 with this scheme. @@ -1109,19 +1109,24 @@ swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c {: #uri-scheme-swidpath} ## "swidpath" URI Scheme -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 {{model-link}}) of this document. -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 {{swidpath-reg}}, the scheme "swidpath" is hereby registered as a -'permanent' scheme for that purpose. +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 {{model-link}}. +The scheme named "swidpath" is used for this purpose in {{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 {{swidpath-reg}}). -URIs specifying the "swidpath" scheme are used to reference the data that must be found in a given software tag for that tag to be considered a matching tag to be included in the identified tag collection. Tags to be evaluated include all tags in the context of where the tag 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 with this scheme. +URIs 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 {{-xpath}} references the data that must be found in a given software tag out of 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"" 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 with this scheme. -For URIs that use the "swidpath" scheme, the requirements apply. +For URIs that use the "swidpath" scheme, the following requirements apply: -The scheme specific part MUST be an XPath expression as defined by {{-xpath}}. The included XPath expression will be URI encoded according to {{RFC3986}} Section 2.1. +* The scheme specific part MUST be an XPath expression as defined by {{-xpath}}. The included XPath expression will be URI encoded according to {{RFC3986}} Section 2.1. -This XPath is evaluated over SWID or CoSWID tags found on a system. A given tag MUST be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to {{-xpath}} Section 2.4.3. +* This XPath is evaluated over SWID tags, or COSWID tags transformed into SWID tags, found on a system. A given tag MUST be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to {{-xpath}} Section 2.4.3. + {: #iana} # IANA Considerations From 7842f128fa8561302df9e90a0bb8ef5d90fbada1 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 16:22:24 +0100 Subject: [PATCH 13/73] Ben #4 --- draft-ietf-sacm-coswid.md | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 4f9f8f4..7b0a4d5 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -298,7 +298,7 @@ notation explicitly relates to XML SWID tags; an attribute referred to by its na KebabCase notation explicitly relates to CBOR CoSWID tags. This approach simplifies the composition of further work that reference both XML SWID and CBOR CoSWID documents. -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 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. These cases are specifically noted in this and subsequent sections using an {{-xpath}} where a manual mapping is needed. +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 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 {{-xpath}} need to use SWID names, see {{uri-scheme-swidpath}}. 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. @@ -679,7 +679,7 @@ The following describes each member of this map. URI needs to be resolved in the context of the endpoint by software that can lookup 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". - a URI with "swidpath:" as the scheme, which refers to another software tag via an - XPATH query {{-xpath}}. This scheme is provided for compatibility with {{SWID}}. This specification does not define how to resolve an XPATH query in the context of CBOR. + XPATH query {{-xpath}} that matches items in that tag ({{uri-scheme-swidpath}}). This scheme is provided for compatibility with {{SWID}}. This specification does not define how to resolve an XPATH query in the context of CBOR, see {{uri-scheme-swidpath}}. - 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 {{-css3-mediaqueries}}). As highlighted in media defined in {{model-concise-swid-tag}}, support for media queries are included here for interoperability with {{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. @@ -1094,7 +1094,7 @@ defined going forward. {: #uri-scheme-swid} ## "swid" URI Scheme -There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in {{model-link}}) of this document. 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 {{swid-reg}}, the scheme "swid" is registered as a 'permanent' scheme for that purpose. +There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in {{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 {{swid-reg}}, the scheme "swid" is registered as a 'permanent' scheme for that purpose. URIs 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 with this scheme. @@ -1109,19 +1109,24 @@ swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c {: #uri-scheme-swidpath} ## "swidpath" URI Scheme -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 {{model-link}}) of this document. -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 {{swidpath-reg}}, the scheme "swidpath" is hereby registered as a -'permanent' scheme for that purpose. +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 {{model-link}}. +The scheme named "swidpath" is used for this purpose in {{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 {{swidpath-reg}}). -URIs specifying the "swidpath" scheme are used to reference the data that must be found in a given software tag for that tag to be considered a matching tag to be included in the identified tag collection. Tags to be evaluated include all tags in the context of where the tag 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 with this scheme. +URIs 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 {{-xpath}} references the data that must be found in a given software tag out of 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" 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 with this scheme. -For URIs that use the "swidpath" scheme, the requirements apply. +For URIs that use the "swidpath" scheme, the following requirements apply: -The scheme specific part MUST be an XPath expression as defined by {{-xpath}}. The included XPath expression will be URI encoded according to {{RFC3986}} Section 2.1. +* The scheme specific part MUST be an XPath expression as defined by {{-xpath}}. The included XPath expression will be URI encoded according to {{RFC3986}} Section 2.1. -This XPath is evaluated over SWID or CoSWID tags found on a system. A given tag MUST be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to {{-xpath}} Section 2.4.3. +* This XPath is evaluated over SWID tags, or COSWID tags transformed into SWID tags, found on a system. A given tag MUST be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to {{-xpath}} Section 2.4.3. + {: #iana} # IANA Considerations From 268bdc25c242ecdbb1b13f6b6871ee6207eb6d2f Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 21 Feb 2022 16:47:59 +0100 Subject: [PATCH 14/73] Fix trailing whitespace --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 7b0a4d5..fefe151 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -305,7 +305,7 @@ The 57 human-readable text labels of the CDDL-based CoSWID vocabulary are mapped Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see {{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 to identify the construct to parse. The CoSWID Items registry, defined in {{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. 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 exclusively meant for private use as defined in {{iana-private-use}}. +The integer values are defined in a registry specific to the kind of value; the text values are not intended for interchange and exclusively meant for private use as defined in {{iana-private-use}}. Encoders SHOULD NOT use string values based on the names registered in the registry, as these values are less concise than their index value equivalent; a decoder MUST however be prepared to accept text strings that are not specified in this document (and ignore the construct if that string is unknown). In the rest of the document, we call this an "integer label with text escape". From 4bbab0e7f2f0c2c24e9ee2f15e3143ad53101f63 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Mon, 21 Feb 2022 17:28:07 +0100 Subject: [PATCH 15/73] double quote for merge --- draft-ietf-sacm-coswid.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 59ac333..7b0a4d5 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1116,11 +1116,7 @@ To enable usage without fear of conflicts with current or future actual schemes, URIs 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 {{-xpath}} references the data that must be found in a given software tag out of base collection for that tag to be considered a matching tag. -<<<<<<< HEAD -Tags to be evaluated (the base collection) include all tags in the context of where the "swidpath URI"" is referenced from. -======= Tags to be evaluated (the base collection) include all tags in the context of where the "swidpath URI" is referenced from. ->>>>>>> 7842f128fa8561302df9e90a0bb8ef5d90fbada1 For example, when a tag is installed on a given device, that tag can reference related tags on the same device using a URI with this scheme. For URIs that use the "swidpath" scheme, the following requirements apply: From 29ffe1301cec4aeb6800c7be958046816401bd0f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 14:26:39 +0100 Subject: [PATCH 16/73] size and stack update --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index fefe151..b63c117 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -196,8 +196,8 @@ Binary Object Representation (CBOR) {{RFC8949}}. 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 instances sizes, which can benefit from a 50 percent to 85 percent reduction of size in generic usage scenarios. -Additional size reduction is enabled with respect to the memory footprint of XML parsing/validation as well as the reduction of stack sizes where XML processing is now obsolete. +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. 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 {{RFC3444}}. While SWID and CoSWID are intended to share the same implicit information model, this specification does not define this information 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. From ba33b21cb8ecdac09c99055334abf023cc2aa6b2 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 14:33:19 +0100 Subject: [PATCH 17/73] payload and evidence (commment on section 2.3) --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index b63c117..f9b9aab 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -493,9 +493,9 @@ This is modeled after the HTML "link" element. Described in {{model-link}}. - 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. Described in {{model-payload}}. +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 {{model-payload}}. -- 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. Described in {{model-evidence}}. +- 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 {{model-evidence}}. - $$coswid-extension: This CDDL socket is used to add new information structures to the concise-swid-tag root map. See {{model-extension}}. From c5fd9c69188df25b53e1fe246bd348efb3762747 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 14:40:12 +0100 Subject: [PATCH 18/73] removed the weird monotonic --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index f9b9aab..63f4c6d 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -457,7 +457,7 @@ identifier MUST be globally unique. Failure to ensure global uniqueness can crea how this identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ensure uniqueness across organizations. -- tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is monotonically increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to 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 MUST be greater than the old tag-version value. +- tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to 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 MUST be greater than the old tag-version value. - corpus (index 8): A boolean value that indicates if the tag identifies and describes an installable software component in its pre-installation state. Installable software includes a installation package or installer for a software component, a software update, or a patch. If the CoSWID tag represents installable software, the corpus item MUST be set to "true". If not provided, the default value MUST be considered "false". From 54d2e0c6d6c1b60cbc3fa7671bb78e77fed7674d Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 14:48:35 +0100 Subject: [PATCH 19/73] SHOULD contraints consequences (comment on section 2.4) --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 63f4c6d..af57af1 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -505,9 +505,9 @@ The following co-constraints apply to the information provided in the concise-sw - The patch and supplemental items MUST NOT both be set to "true". -- If the patch item is set to "true", the tag SHOULD contain at least one link item (see {{model-link}}) with both the rel item value of "patches" and an href item specifying an association with the software that was patched. +- If the patch item is set to "true", the tag SHOULD contain at least one link item (see {{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 the target of the patch cannot be identified and the patch tag cannot be applied without external context. -- If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel item value of "supplemental" and an href item specifying an association with the software that is supplemented. +- If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel item value of "supplemental" and an href item specifying an association with the software that is supplemented. Without at least one link item the target of supplement tag cannot be identified and the patch tag cannot be applied without external context. - If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST 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. From 63ef9aa2f47f96a67768171c09fb35080dce33d3 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 14:59:59 +0100 Subject: [PATCH 20/73] more consequences on violating constraints --- draft-ietf-sacm-coswid.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index af57af1..a2e842f 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -501,7 +501,7 @@ endpoint when the software component is installed or run. This item is mutually ## concise-swid-tag Co-Constraints -The following co-constraints apply to the information provided in the concise-swid-tag group. +The following co-constraints apply to the information provided in the concise-swid-tag group. If any of these constraint is not met, a signed tag cannot be used anymore as a signed statement. - The patch and supplemental items MUST NOT both be set to "true". @@ -510,7 +510,6 @@ The following co-constraints apply to the information provided in the concise-sw - If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel item value of "supplemental" and an href item specifying an association with the software that is supplemented. Without at least one link item the target of supplement tag cannot be identified and the patch tag cannot be applied without external context. - If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST 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. - {: #model-global-attributes} ## The global-attributes Group From 0a2472090e09f88d7fbc5cda96ad9140bf68e499 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 25 Feb 2022 15:06:53 +0100 Subject: [PATCH 21/73] uri-schemes in reg-id --- draft-ietf-sacm-coswid.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index a2e842f..04ee719 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -511,6 +511,7 @@ The following co-constraints apply to the information provided in the concise-sw - If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST 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. {: #model-global-attributes} + ## The global-attributes Group The global-attributes group provides a list of items, including an optional @@ -585,7 +586,7 @@ The following describes each child item of this group. - reg-id (index 32): The registration id 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 MUST be a RFC 3986 URI. The scope will usually be the scope of an organization. +registration ID MUST be a RFC 3986 URI; it is not intended to be dereferenced. The scope will usually be the scope of an organization. - role (index 33): An integer or textual value (integer label with text escape, see {{data-def}}) representing the relationship(s) between the entity, and this tag or the referenced software component. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software Tag Entity Role Values" registry (see {{iana-entity-role}}. From e3f8af0536c616d6d2a9c78f94dbe3c824848198 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 14:25:03 +0100 Subject: [PATCH 22/73] Switch do domainprefix/name --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index a2e842f..4a5066e 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1235,10 +1235,10 @@ The integer-based index values in the private use range (-1 to -256) are intende For names that correspond to private use index values, an Internationalized Domain Name prefix MUST be used to prevent name conflicts using the form: ``` -domain.prefix-name +domainprefix/name ``` -Where "domain.prefix" MUST be a valid Internationalized Domain Name as defined by {{RFC5892}}, and "name" MUST be a unique name within the namespace defined by the "domain.prefix". Use of a prefix in this way allows for a name to be used initially in the private use range, and to be registered at a future point in time. This is consistent with the guidance in {{BCP178}}. +Where "domainprefix" MUST be a valid Internationalized Domain Name as defined by {{RFC5892}}, and "name" MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range, and to be registered at a future point in time. This is consistent with the guidance in {{BCP178}}. {: #iana-review-guidelines} ### Expert Review Guidelines From f220b9602a139caefb6d2f03929ddc85b91c2a89 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 2 Mar 2022 14:25:45 +0100 Subject: [PATCH 23/73] some things --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 04ee719..3bd9d71 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -670,7 +670,7 @@ The following describes each member of this map. - global-attributes: The global-attributes group described in {{model-global-attributes}}. -- artifact (index: 37): To be used with rel="installation-media", this item's value provides the path to the installer executable or script that can be run to launch the referenced installation. Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. +- artifact (index: 37): To be used with rel="installation-media", this item's value provides the path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. - href (index 38): A URI-reference {{RFC3986}} for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from {{SWID}}): - If no URI scheme is provided, then the URI-reference is a relative reference relative to the URI of the CoSWID tag. For example, "./folder/supplemental.coswid". From 5d7d3923cf11587b228d36b0b110b94554d0d965 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 14:55:06 +0100 Subject: [PATCH 24/73] Sec-cons for relative paths --- draft-ietf-sacm-coswid.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 64c8bd8..3fb4d99 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1681,6 +1681,13 @@ 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. +This specification makes use of relative paths (e.g., filesystem +paths) in several places. +A signed COSWID tag cannot make use of these to derive information +that is considered to be covered under the signature. +Typically, relative file system paths will be used to identify +targets for an installation, not sources of tag information. + 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 From f1c49bd5d2c3728439777e7d2f98a2dd7d15770d Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 14:57:55 +0100 Subject: [PATCH 25/73] Clarify that artifact is an absolute filesystem path --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 3fb4d99..0c7546c 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -670,7 +670,7 @@ The following describes each member of this map. - global-attributes: The global-attributes group described in {{model-global-attributes}}. -- artifact (index: 37): To be used with rel="installation-media", this item's value provides the path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. +- artifact (index: 37): To be used with rel="installation-media", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. - href (index 38): A URI-reference {{RFC3986}} for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from {{SWID}}): - If no URI scheme is provided, then the URI-reference is a relative reference relative to the URI of the CoSWID tag. For example, "./folder/supplemental.coswid". From 87fdb84b7badf1a24276de11dc6b19e1fb782ac3 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:03:49 +0100 Subject: [PATCH 26/73] Clarify base of relative URIs --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 0c7546c..726c79b 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -673,7 +673,7 @@ The following describes each member of this map. - artifact (index: 37): To be used with rel="installation-media", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. - href (index 38): A URI-reference {{RFC3986}} for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from {{SWID}}): - - If no URI scheme is provided, then the URI-reference is a relative reference relative to the URI of the CoSWID tag. For example, "./folder/supplemental.coswid". + - 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 example, "./folder/supplemental.coswid". - a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://) - a URI with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This URI needs to be resolved in the context of the endpoint by software From eb36b077886c02f572c3bec50c9ab68a167a98e7 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:05:41 +0100 Subject: [PATCH 27/73] typo --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 726c79b..89c9aab 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -474,7 +474,7 @@ class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ens - media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag -applies to. This item item MUST be formatted as a +applies to. This item MUST be formatted as a query as defined by the W3C Media Queries Recommendation (see {{-css3-mediaqueries}}). Support for media queries are included here for interoperability with {{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. - software-meta (index 5): An open-ended map of key/value data pairs. From d1ca4281793e72d76247017accb981c0be4f95db Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:07:38 +0100 Subject: [PATCH 28/73] Ben re media-type (Section 2.7) --- draft-ietf-sacm-coswid.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 89c9aab..49c7dfa 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -688,7 +688,10 @@ query as defined by the W3C Media Queries Recommendation (see {{-css3-mediaqueri - rel (index 40): An integer or textual value that (integer label with text escape, see {{data-def}}, for the "Software Tag Link Link Relationship Values" registry {{indexed-link-ownership}}) identifies the relationship between this CoSWID and the target resource identified by the "href" item. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Link Relationship Values" registry (see {{iana-link-rel}}. If a string value is used it MUST be either a private use name as defined in {{iana-private-use}} or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml as defined by {{RFC8288}}. When a string value defined in the IANA "Software Tag Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software Tag Link Relationship Values" registry MUST 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 Tag Link Relationship Values" registry. -- media-type (index 41): 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. Media types are identified by referencing a "Name" from the IANA "Media Types" registry: http://www.iana.org/assignments/media-types/media-types.xhtml. This item maps to '/SoftwareIdentity/Link/@type' in {{SWID}}. +- media-type (index 41): 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 *hint*: 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. This item maps to '/SoftwareIdentity/Link/@type' in {{SWID}}. - use (index 42): An integer or textual value (integer label with text escape, see {{data-def}}, for the "Software Tag Link Link Relationship Values" registry {{indexed-link-ownership}}) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see {{iana-link-use}}. If a string value is used it MUST be a private use name as defined in {{iana-private-use}}. String values correspond to registered entries in the "Software Tag Link Use Values" registry. From 8d2ec78c4743da160682515a7ae453e84f2807f0 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:13:17 +0100 Subject: [PATCH 29/73] Ben 2.8: String comparison is byte-by-byte --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 49c7dfa..d24f596 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -748,7 +748,7 @@ The following describes each child item of this group. - channel-type (index 44): 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). This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. -- colloquial-version (index 45): A textual value for the software component's informal or colloquial version. Examples may include a year value, a major version number, or 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 only and is not intended to be used to determine if a specific value is earlier or later in a sequence. +- colloquial-version (index 45): A textual value for the software component's informal or colloquial version. Examples may include a year value, a major version number, or 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) only and is not intended to be used to determine if a specific value is earlier or later in a sequence. - description (index 46): A textual value that provides a detailed description of the software component. This value MAY be multiple paragraphs separated by CR LF characters as described by {{RFC5198}}. From 6df2d878ee511fcc408684026071a22cfc9b3a7c Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:20:18 +0100 Subject: [PATCH 30/73] Ben 2.8: Generator can be a tag-id --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index d24f596..b5a91ae 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -711,7 +711,7 @@ software-meta-entry = { ? edition => text, ? entitlement-data-required => bool, ? entitlement-key => text, - ? generator => text, + ? generator => text / bstr .size 16, ? persistent-id => text, ? product => text, ? product-family => text, From 7a3d8532dc594ab050bf2abb79b56d5c4a8c6793 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:21:34 +0100 Subject: [PATCH 31/73] Ben 2.8: Generator can be a tag-id --- concise-swid-tag.cddl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/concise-swid-tag.cddl b/concise-swid-tag.cddl index 13f83e8..ec2da53 100644 --- a/concise-swid-tag.cddl +++ b/concise-swid-tag.cddl @@ -105,7 +105,7 @@ software-meta-entry = { ? edition => text, ? entitlement-data-required => bool, ? entitlement-key => text, - ? generator => text, + ? generator => text / bstr .size 16, ? persistent-id => text, ? product => text, ? product-family => text, From 93dff88fd886abe5de5e29725951c56ffe7f4e51 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:26:57 +0100 Subject: [PATCH 32/73] Ben 2.9.1 ("current" in registry) --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index b5a91ae..73a4113 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -791,7 +791,7 @@ hash-entry = [ ] ~~~~ -The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's value MUST refer to an ID in the IANA "Named Information Hash Algorithm Registry" {{-NIHAR}} with a Status of "current"; other hash algorithms MUST NOT be used. If the hash-alg-id is not known, then the integer value "0" MUST be used. This ensures parity between the SWID tag specification {{SWID}}, which does not allow an algorithm to be identified for this field. +The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's value MUST refer to an ID in the IANA "Named Information Hash Algorithm Registry" {{-NIHAR}} with a Status of "current" (at the time the generator software was built or later); other hash algorithms MUST NOT be used. If the hash-alg-id is not known, then the integer value "0" MUST be used. This ensures parity between the SWID tag specification {{SWID}}, which does not allow an algorithm to be identified for this field. The hash-value MUST represent the raw hash value in byte representation (in contrast to, e.g., base64 encoded byte representation) of the byte string that represents the hashed resource generated using the hash algorithm indicated by the hash-alg-id. From 45f0c5f3be06ca6d6b8333643d1950d1c94588a5 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 2 Mar 2022 15:30:50 +0100 Subject: [PATCH 33/73] comment on Section 2.9.1 "parity" --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 73a4113..d653790 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -791,7 +791,7 @@ hash-entry = [ ] ~~~~ -The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's value MUST refer to an ID in the IANA "Named Information Hash Algorithm Registry" {{-NIHAR}} with a Status of "current" (at the time the generator software was built or later); other hash algorithms MUST NOT be used. If the hash-alg-id is not known, then the integer value "0" MUST be used. This ensures parity between the SWID tag specification {{SWID}}, which does not allow an algorithm to be identified for this field. +The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's value MUST refer to an ID in the IANA "Named Information Hash Algorithm Registry" {{-NIHAR}} with a Status of "current" (at the time the generator software was built or later); other hash algorithms MUST NOT be used. If the hash-alg-id is not known, then the integer value "0" MUST be used. This allows for conversion from ISO SWID tags {{SWID}}, which do not allow an algorithm to be identified for this field. The hash-value MUST represent the raw hash value in byte representation (in contrast to, e.g., base64 encoded byte representation) of the byte string that represents the hashed resource generated using the hash algorithm indicated by the hash-alg-id. From ed897808f13e8ffd96426acc29c692c09749edf6 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Wed, 2 Mar 2022 15:34:32 +0100 Subject: [PATCH 34/73] ownership change in .cddl, too --- concise-swid-tag.cddl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/concise-swid-tag.cddl b/concise-swid-tag.cddl index ec2da53..42c3a7d 100644 --- a/concise-swid-tag.cddl +++ b/concise-swid-tag.cddl @@ -255,9 +255,9 @@ licensor=5 maintainer=6 ; "ownership" integer indexes -shared=1 +abandon=1 private=2 -abandon=3 +shared=3 ; "rel" integer indexes ancestor=1 From 769374828045e13d5076526dda21a612c44874a8 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 15:20:34 +0100 Subject: [PATCH 35/73] comment file version (index 21) --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index d653790..5a04779 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -885,7 +885,7 @@ The following describes each member of the groups and maps illustrated above. - size (index 20): The file's size in bytes. -- file-version (index 21): The file's version as reported by querying information on the file from the operating system. This item maps to '/SoftwareIdentity/(Payload\|Evidence)/File/@version' in {{SWID}}. +- file-version (index 21): 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 {{SWID}}. - hash (index 7): A hash of the file as described in {{model-hash-entry}}. From 0cd0830b92de6e789579756ab68527215dd7aee9 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 15:35:54 +0100 Subject: [PATCH 36/73] added location to evidence-entry based on the comment on location (index 23) --- draft-ietf-sacm-coswid.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 5a04779..47ab7ff 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -472,7 +472,6 @@ class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ens - version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape ({{data-def}}, for the "Version Scheme" registry {{indexed-version-scheme}}. . If an integer value is used it MUST 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 {{iana-private-use}}). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software Tag Version Scheme Values" registry (see {{iana-version-scheme}}. - - media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag applies to. This item MUST be formatted as a query as defined by the W3C Media Queries Recommendation (see {{-css3-mediaqueries}}). Support for media queries are included here for interoperability with {{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. @@ -946,6 +945,7 @@ evidence-entry = { resource-collection, ? date => integer-time, ? device-id => text, + ? location => text, * $$evidence-extension, global-attributes, } @@ -964,6 +964,8 @@ The following describes each child item of this group. - device-id (index 36): The endpoint's string identifier from which the evidence was collected. +- location (index 23): The absolute filepath of the location of the CoSWID tag generated as evidence. + - $$evidence-extension: This CDDL socket can be used to extend the evidence-entry group model. See {{model-extension}}. ## Full CDDL Specification From d77003f176bbe54a4453541019383f245f696c15 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 15:37:01 +0100 Subject: [PATCH 37/73] corresponding change in full cddl --- concise-swid-tag.cddl | 1 + 1 file changed, 1 insertion(+) diff --git a/concise-swid-tag.cddl b/concise-swid-tag.cddl index 42c3a7d..b84cd8f 100644 --- a/concise-swid-tag.cddl +++ b/concise-swid-tag.cddl @@ -174,6 +174,7 @@ evidence-entry = { resource-collection, ? date => integer-time, ? device-id => text, + ? location => text, * $$evidence-extension, global-attributes, } From 457ad58abfc0c33621cc9b66907a62a0f404b93f Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 15:43:35 +0100 Subject: [PATCH 38/73] clarify interdependence of location values --- draft-ietf-sacm-coswid.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 47ab7ff..a6975c9 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -890,7 +890,7 @@ The following describes each member of the groups and maps illustrated above. - key (index 22): 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. -- location (index 23): The filesystem path where a file is expected to be located when installed or copied. The location MUST be either relative to the location of the parent directory item (preferred) or relative to the location of the CoSWID tag if no parent is defined. The location MUST NOT include a file's name, which is provided by the fs-name item. +- location (index 23): The filesystem path where a file is expected to be located when installed or copied. The location MUST be either relative to the location of the parent directory item (preferred), or 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 MUST NOT include a file's name, which is provided by the fs-name item. - fs-name (index 24): The name of the directory or file without any path information. This aligns with a file "name" in {{SWID}}. This item maps to '/SoftwareIdentity/(Payload\|Evidence)/(File\|Directory)/@name' in {{SWID}}. @@ -965,6 +965,7 @@ The following describes each child item of this group. - device-id (index 36): The endpoint's string identifier from which the evidence was collected. - 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.) - $$evidence-extension: This CDDL socket can be used to extend the evidence-entry group model. See {{model-extension}}. From 273405bc519aa1fb37ed7b3f392e2966db57dba9 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 15:51:27 +0100 Subject: [PATCH 39/73] comment on type (index 29) --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index a6975c9..75ba795 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -902,7 +902,7 @@ The following describes each member of the groups and maps illustrated above. - pid (index 28): 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. -- type (index 29): A string indicating the type of resource. +- type (index 29): A human-readable string indicating the type of resource. - $$resource-collection-extension: This CDDL socket can be used to extend the resource-collection group model. This can be used to add new specialized types of resources. See {{model-extension}}. From dab54e714ebb5d148f9f4a9548d90852ca1507e5 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 15:56:47 +0100 Subject: [PATCH 40/73] Explain that indexed label values have a reserved 0 --- draft-ietf-sacm-coswid.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 75ba795..4e4a2f4 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -995,6 +995,9 @@ Note: Multiple of the corpus, patch, and supplemental items can have values set # CoSWID Indexed Label Values +This section defines a number of kinds of indexed label values that are maintained in a registry each ({{iana}}). +These values are represented as positive integers. In each registry, the value 0 is marked as Reserved. + {: #indexed-version-scheme} ## Version Scheme From 0ca68e4e66595c70f66a8fc154762604a8c3af28 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 16:11:09 +0100 Subject: [PATCH 41/73] Clarify version scheme ordering --- draft-ietf-sacm-coswid.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 4e4a2f4..08135a2 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1005,13 +1005,15 @@ The following table contains a set of values for use in the concise-swid-tag gro | Index | Version Scheme Name | Definition |--- -| 1 | multipartnumeric | Numbers separated by dots, where the numbers are interpreted as integers (e.g., 1.2.3, 1.4.5, 1.2.3.4.5.6.7) -| 2 | multipartnumeric+suffix | Numbers separated by dots, where the numbers are interpreted as integers with an additional textual suffix (e.g., 1.2.3a) -| 3 | alphanumeric | Strictly a string, sorting is done alphanumerically -| 4 | decimal | A floating point number (e.g., 1.25 is less than 1.3) +| 1 | multipartnumeric | 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) +| 2 | multipartnumeric+suffix | Numbers separated by dots, where the numbers are interpreted as decimal integers with an additional textual suffix (e.g., 1.2.3a) +| 3 | alphanumeric | Strictly a string, no interpretation as number +| 4 | decimal | A single decimal floating point number | 16384 | semver | A semantic version as defined by {{SWID}}. Also see the {{SEMVER}} specification for more information {: #tbl-indexed-version-scheme-values title="Version Scheme Values"} +multipartnumeric and the numbers part of 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 strings are sorted lexicographically as character strings. Decimal version numbers are interpreted as a single floating point number (e.g., 1.25 is less than 1.3). + The values above are registered in the IANA "Software Tag Version Scheme Values" registry defined in Section {{iana-version-scheme}}. Additional entries will likely be registered over time in this registry. A CoSWID producer that is aware of the version scheme that has been used to select the version value, SHOULD include the optional version-scheme item to avoid semantic ambiguity. From a6a45083cb2c260617b61210bc499897afd870e0 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 16:20:45 +0100 Subject: [PATCH 42/73] Mark index 30 as unassigned --- draft-ietf-sacm-coswid.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 08135a2..29a6f13 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1008,7 +1008,7 @@ The following table contains a set of values for use in the concise-swid-tag gro | 1 | multipartnumeric | 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) | 2 | multipartnumeric+suffix | Numbers separated by dots, where the numbers are interpreted as decimal integers with an additional textual suffix (e.g., 1.2.3a) | 3 | alphanumeric | Strictly a string, no interpretation as number -| 4 | decimal | A single decimal floating point number +| 4 | decimal | A single decimal floating point number | 16384 | semver | A semantic version as defined by {{SWID}}. Also see the {{SEMVER}} specification for more information {: #tbl-indexed-version-scheme-values title="Version Scheme Values"} @@ -1197,6 +1197,7 @@ are provided below. Assignments consist of an integer index value, the item name | 27 | process-name | RFC-AAAA | 28 | pid | RFC-AAAA | 29 | type | RFC-AAAA +| 30 | Unassigned | | | 31 | entity-name | RFC-AAAA | 32 | reg-id | RFC-AAAA | 33 | role | RFC-AAAA From 82272586a6c433ddd00d98a5ab334b6c5a6056f4 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 16:31:57 +0100 Subject: [PATCH 43/73] Clarify the use of IDNA labels in domainprefix/name --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 29a6f13..1aaf6dc 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -75,7 +75,7 @@ normative: RFC5198: RFC5234: ABNF RFC5646: - RFC5892: + RFC5890: IDNA RFC8949: RFC7252: RFC8152: cose-msg @@ -1251,7 +1251,7 @@ For names that correspond to private use index values, an Internationalized Doma domainprefix/name ``` -Where "domainprefix" MUST be a valid Internationalized Domain Name as defined by {{RFC5892}}, and "name" MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range, and to be registered at a future point in time. This is consistent with the guidance in {{BCP178}}. +Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range, and to be registered at a future point in time. This is consistent with the guidance in {{BCP178}}. {: #iana-review-guidelines} ### Expert Review Guidelines From c94b7f86e35f7e17fb4951da0997e279e26903e1 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 16:36:41 +0100 Subject: [PATCH 44/73] comment on Section 6.2.2 --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 1aaf6dc..1930637 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1251,7 +1251,7 @@ For names that correspond to private use index values, an Internationalized Doma domainprefix/name ``` -Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range, and to be registered at a future point in time. This is consistent with the guidance in {{BCP178}}. +Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range. This is consistent with the guidance in {{BCP178}}. {: #iana-review-guidelines} ### Expert Review Guidelines From 55ce7fa23bd0708f1ed9ca2b3218eb91010e84da Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 16:39:20 +0100 Subject: [PATCH 45/73] also no "initially" --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 1930637..9cade03 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1251,7 +1251,7 @@ For names that correspond to private use index values, an Internationalized Doma domainprefix/name ``` -Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used initially in the private use range. This is consistent with the guidance in {{BCP178}}. +Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used in the private use range. This is consistent with the guidance in {{BCP178}}. {: #iana-review-guidelines} ### Expert Review Guidelines From 1a1ccf645f07f0a56169318256e7a80c92c14ae2 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Thu, 3 Mar 2022 16:41:54 +0100 Subject: [PATCH 46/73] made a span a block --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 9cade03..14ff857 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1247,9 +1247,9 @@ The integer-based index values in the private use range (-1 to -256) are intende For names that correspond to private use index values, an Internationalized Domain Name prefix MUST be used to prevent name conflicts using the form: -``` +~~~ domainprefix/name -``` +~~~ Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used in the private use range. This is consistent with the guidance in {{BCP178}}. From 01d2e0ecb8a298a6b3652ae4f4fd061f17a32b41 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 16:51:03 +0100 Subject: [PATCH 47/73] Use "criteria" in place of "guidelines" that are more like "rules"... --- draft-ietf-sacm-coswid.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 14ff857..d7621e1 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1253,10 +1253,10 @@ domainprefix/name Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by {{RFC5890}}, and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used in the private use range. This is consistent with the guidance in {{BCP178}}. -{: #iana-review-guidelines} -### Expert Review Guidelines +{: #iana-review-criteria} +### Expert Review Criteria -Designated experts MUST ensure that new registration requests meet the following additional guidelines: +Designated experts MUST ensure that new registration requests meet the following additional criteria: - The requesting specification MUST provide a clear semantic definition for the new entry. This definition MUST clearly differentiate the requested entry from other previously registered entries. - The requesting specification MUST describe the intended use of the entry, including any co-constraints that exist between the use of the entry's index value or name, and other values defined within the SWID/CoSWID model. @@ -1300,9 +1300,9 @@ defined in {{SWID}}. | 16385-65535 | Unassigned | {: #tbl-iana-version-scheme-values title="CoSWID Version Scheme Initial Registrations"} -Registrations MUST conform to the expert review guidelines defined in {{iana-review-guidelines}}. +Registrations MUST conform to the expert review criteria defined in {{iana-review-criteria}}. -Designated experts MUST also ensure that newly requested entries define a value space for the corresponding version item that is unique from other previously registered entries. Note: The initial registrations violate this requirement, but are included for backwards compatibility with {{SWID}}. Guidelines on how to deconflict these value spaces are defined in {{indexed-version-scheme}}. +Designated experts MUST also ensure that newly requested entries define a value space for the corresponding version item that is unique from other previously registered entries. Note: The initial registrations violate this requirement, but are included for backwards compatibility with {{SWID}}. See also {{indexed-version-scheme}}. {: #iana-entity-role} ### Software Tag Entity Role Values Registry @@ -1339,7 +1339,7 @@ defined in {{SWID}}. | 7-255 | Unassigned | {: #tbl-iana-entity-role-values title="CoSWID Entity Role Initial Registrations"} -Registrations MUST conform to the expert review guidelines defined in {{iana-review-guidelines}}. +Registrations MUST conform to the expert review criteria defined in {{iana-review-criteria}}. {: #iana-link-ownership} ### Software Tag Link Ownership Values Registry @@ -1373,7 +1373,7 @@ defined in {{SWID}}. | 4-255 | Unassigned | {: #tbl-iana-link-ownership-values title="CoSWID Link Ownership Inital Registrations"} -Registrations MUST conform to the expert review guidelines defined in {{iana-review-guidelines}}. +Registrations MUST conform to the expert review criteria defined in {{iana-review-criteria}}. {: #iana-link-rel} ### Software Tag Link Relationship Values Registry @@ -1415,7 +1415,7 @@ defined in {{SWID}}. | 12-65535 | Unassigned | {: #tbl-iana-link-rel-values title="CoSWID Link Relationship Initial Registrations"} -Registrations MUST conform to the expert review guidelines defined in {{iana-review-guidelines}}. +Registrations MUST conform to the expert review criteria defined in {{iana-review-criteria}}. Designated experts MUST 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. @@ -1451,7 +1451,7 @@ defined in {{SWID}}. | 4-255 | Unassigned | {: #tbl-iana-link-use-values title="CoSWID Link Use Initial Registrations"} -Registrations MUST conform to the expert review guidelines defined in {{iana-review-guidelines}}. +Registrations MUST conform to the expert review criteria defined in {{iana-review-criteria}}. ## swid+cbor Media Type Registration @@ -1764,7 +1764,7 @@ Changes in version 12: - Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 bit, 16 bit, etc. - Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document. - Added discussion around resolving overlapping value spaces for version schemes. -- Added a set of expert review guidelines for new IANA registries created by this document. +- Added a set of expert review criteria for new IANA registries created by this document. - Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA. Changes from version 03 to version 11: From 00ffc800fd97fa0460f82cec6b9eee853d0a138f Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 16:53:18 +0100 Subject: [PATCH 48/73] SHOULD -> MUST for squatting --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index d7621e1..d64f4b4 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1260,7 +1260,7 @@ Designated experts MUST ensure that new registration requests meet the following - The requesting specification MUST provide a clear semantic definition for the new entry. This definition MUST clearly differentiate the requested entry from other previously registered entries. - The requesting specification MUST describe the intended use of the entry, including any co-constraints that exist between the use of the entry's index value or name, and other values defined within the SWID/CoSWID model. -- Index values and names outside the private use space MUST NOT be used without registration. This is considered squatting and SHOULD be avoided. Designated experts MUST ensure that reviewed specifications register all appropriate index values and names. +- Index values and names outside the private use space MUST NOT be used without registration. This is considered squatting and MUST be avoided. Designated experts MUST ensure that reviewed specifications register all appropriate index values and names. - Standards track documents MAY include entries registered in the range reserved for entries under the Specification Required policy. This can occur when a standards track document provides further guidance on the use of index values and names that are in common use, but were not registered with IANA. This situation SHOULD be avoided. - All registered names MUST be valid according to the XML Schema NMTOKEN data type (see {{-xml-schema-datatypes}} Section 3.3.4). This ensures that registered names are compatible with the SWID format {{SWID}} where they are used. - Registration of vanity names SHOULD be discouraged. The requesting specification MUST provide a description of how a requested name will allow for use by multiple stakeholders. From 4092a79af9aa067893389e994a2de9cd0f513ec5 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 17:16:02 +0100 Subject: [PATCH 49/73] Reference 9052-to-be instead of 8152 --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index d64f4b4..99481e9 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -78,7 +78,7 @@ normative: RFC5890: IDNA RFC8949: RFC7252: - RFC8152: cose-msg + I-D.ietf-cose-rfc8152bis-struct: cose-msg RFC8412: RFC8288: RFC8610: @@ -1614,7 +1614,7 @@ In general, tags are signed by the tag creator (typically, although not exclusiv 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 for files. The ISO-19770-2:2015 XML schema uses XML DSIG to support cryptographic signatures. -Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption {{RFC8152}}. A CoSWID tag MUST be wrapped in a COSE Signature structure, either COSE_Sign1 or COSE_Sign. +Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption {{-cose-msg}}. A CoSWID tag MUST 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 MUST be signed by the tag creator. The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header in this case. ~~~~ CDDL From af2cb66d6363847d08670fda78a6149e3d07a564 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:25:52 +0100 Subject: [PATCH 50/73] Fragment identifier considerations --- draft-ietf-sacm-coswid.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 99481e9..f96e12a 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1102,6 +1102,14 @@ Note: These URI schemes are used in {{SWID}} without an IANA registration. The present specification ensures that these URI schemes are properly defined going forward. + +[^replace-xxxx] + +[^replace-xxxx]: RFC Ed.: throughout this section, please replace + RFC-AAAA with the RFC number of this specification and remove this + note. + + {: #uri-scheme-swid} ## "swid" URI Scheme @@ -1465,8 +1473,8 @@ Required parameters: none Optional parameters: none -Encoding considerations: Must be encoded as using {{RFC8949}}. See -RFC-AAAA for details. +Encoding considerations: Binary (encoded as CBOR {{RFC8949}}). +See RFC-AAAA for details. Security considerations: See {{sec-sec}} of RFC-AAAA. @@ -1480,9 +1488,10 @@ Applications that use this media type: The type is used by software asset management systems, vulnerability assessment systems, and in applications that use remote integrity verification. -Fragment identifier considerations: Fragment identification for -application/swid+cbor is supported by using fragment identifiers as -specified by {{Section 9.5 of RFC8949}}. +Fragment Identifier Considerations: The syntax and semantics of +fragment identifiers specified for "application/swid+cbor" are as specified +for "application/cbor". (At publication of RFC-AAAA, there is no +fragment identification syntax defined for "application/cbor".) Additional information: From 54f1e604535ba48b0d6a93fecc99e398881c7413 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:34:21 +0100 Subject: [PATCH 51/73] Conditionalize magic number --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index f96e12a..aad15e4 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1495,7 +1495,7 @@ fragment identification syntax defined for "application/cbor".) Additional information: -Magic number(s): first five bytes in hex: da 53 57 49 44 +Magic number(s): if tagged, first five bytes in hex: da 53 57 49 44 (see {{tagged}} in RFC-AAAA) File extension(s): coswid From 8ed87fc24a15422c21ec074da86ba86abb7d79da Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:54:25 +0100 Subject: [PATCH 52/73] Silence xml2rfc a bit more --- draft-ietf-sacm-coswid.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index aad15e4..910aab8 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -9,6 +9,7 @@ wg: SACM Working Group kw: Internet-Draft cat: std consensus: true +submissiontype: IETF pi: toc: yes sortrefs: yes From 904ffe45185f14993a58e4ff183d8cc75d64d72e Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:55:29 +0100 Subject: [PATCH 53/73] fix irregularity --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 910aab8..3f14788 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -670,7 +670,7 @@ The following describes each member of this map. - global-attributes: The global-attributes group described in {{model-global-attributes}}. -- artifact (index: 37): To be used with rel="installation-media", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. +- artifact (index 37): To be used with rel="installation-media", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. - href (index 38): A URI-reference {{RFC3986}} for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from {{SWID}}): - 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 example, "./folder/supplemental.coswid". From a6894dfb388ceea86d7037675279ebef693ac7f1 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:58:46 +0100 Subject: [PATCH 54/73] already fixed, typo --- draft-ietf-sacm-coswid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 3f14788..22f006e 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -460,7 +460,7 @@ class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ens - tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to 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 MUST be greater than the old tag-version value. -- corpus (index 8): A boolean value that indicates if the tag identifies and describes an installable software component in its pre-installation state. Installable software includes a installation package or installer for a software component, a software update, or a patch. If the CoSWID tag represents installable software, the corpus item MUST be set to "true". If not provided, the default value MUST be considered "false". +- corpus (index 8): 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 MUST be set to "true". If not provided, the default value MUST be considered "false". - patch (index 9): 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 MUST be set to "true". If not provided, the default value MUST be considered "false". A patch item's value MUST NOT be set to "true" if the installation of the associated software package changes the version of a software component. @@ -670,7 +670,7 @@ The following describes each member of this map. - global-attributes: The global-attributes group described in {{model-global-attributes}}. -- artifact (index 37): To be used with rel="installation-media", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. [FIXME] Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. +- artifact (index 37): To be used with rel="installation-media", 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 MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. - href (index 38): A URI-reference {{RFC3986}} for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from {{SWID}}): - 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 example, "./folder/supplemental.coswid". From 4b09d9e02ba98cfce243395787fd7df078a16f39 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Thu, 3 Mar 2022 20:59:10 +0100 Subject: [PATCH 55/73] Ben re 6.7 (-> better define tag-id) --- draft-ietf-sacm-coswid.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 22f006e..517d4cb 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -453,10 +453,11 @@ The following describes each member of the concise-swid-tag root map. - global-attributes: 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. Described in {{model-global-attributes}}. -- tag-id (index 0): A 16-byte binary string or textual identifier uniquely referencing a software component. The tag +- tag-id (index 0): A 16-byte binary string, or a textual identifier, uniquely referencing a software component. The tag identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching and lookups. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by {{RFC4122}}. There are no strict guidelines on -how this identifier is structured, but examples include a 16-byte GUID (e.g., -class 4 UUID) {{RFC4122}}, or a text string appended to a DNS domain name to ensure uniqueness across organizations. +how the identifier is structured, but examples include a 16-byte GUID (e.g., +class 4 UUID) {{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 MUST NOT contain a sequence of two underscores ("__", see {{sec-swima}}). - tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to 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 MUST be greater than the old tag-version value. @@ -1594,7 +1595,7 @@ Reference: {: vspace='0'} -## CoSWID Model for use in SWIMA Registration +## CoSWID Model for use in SWIMA Registration {#sec-swima} The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification {{RFC8412}} defines a standardized method for collecting an endpoint device's software inventory. A CoSWID can provide evidence of software installation which can then be used and exchanged with SWIMA. This registration adds a new entry to the IANA "Software Data Model Types" registry defined by {{RFC8412}} {{!IANA.pa-tnc-parameters}} to support CoSWID use in SWIMA as follows: From a46ed91515c03cec117663ace58c754512b088e7 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 6 Mar 2022 21:04:40 +0100 Subject: [PATCH 56/73] removed prescriptive key identifier content --- sign.cddl | 1 - sign1.cddl | 1 - 2 files changed, 2 deletions(-) diff --git a/sign.cddl b/sign.cddl index 2213d40..4cb27f1 100644 --- a/sign.cddl +++ b/sign.cddl @@ -12,7 +12,6 @@ protected-signed-coswid-header1 = { protected-signature-coswid-header = { 1 => int, ; algorithm identifier - 4 => bstr, ; key identifier * cose-label => cose-values, } diff --git a/sign1.cddl b/sign1.cddl index 3ee4d36..588e58b 100644 --- a/sign1.cddl +++ b/sign1.cddl @@ -11,7 +11,6 @@ cose-values = any protected-signed-coswid-header = { 1 => int, ; algorithm identifier 3 => "application/swid+cbor", - 4 => bstr, ; key identifier * cose-label => cose-values, } From a9e75a88abbbc43f4c7f5d8b64ad23a1c48a5e6a Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 6 Mar 2022 21:06:10 +0100 Subject: [PATCH 57/73] improved Section 8 header --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 517d4cb..c71f55e 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1644,7 +1644,7 @@ Additionally, the COSE Header counter signature MAY be used as an attribute in t A CoSWID MUST be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in {{sec-sec}}) for more information on why a signed CoSWID is valuable in most cases. -# Tagged CoSWID Tags {#tagged} +# CBOR-Tagged CoSWID Tags {#tagged} This specification allows for tagged and untagged CBOR data items that are CoSWID tags. Consecutively, the CBOR tag for CoSWID tags defined in {{tbl-cbor-tag}} SHOULD be used in conjunction with CBOR data items that are a CoSWID tags. From e3bb265039d5139e5b716518a879b567de271b3f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 6 Mar 2022 21:20:30 +0100 Subject: [PATCH 58/73] added an up to date COSE countersign reference --- draft-ietf-sacm-coswid.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index c71f55e..6ac3d47 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -83,6 +83,8 @@ normative: RFC8412: RFC8288: RFC8610: + I-D.ietf-cose-countersign: countersign + X.1520: title: "Recommendation ITU-T X.1520 (2014), Common vulnerabilities and exposures" date: 2011-04-20 @@ -1640,7 +1642,8 @@ The COSE_Sign structure allows for more than one signature, one of which MUST be ~~~~ {: sourcecode-markers="true"} -Additionally, the COSE Header counter signature MAY be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID. The application of counter signing 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). +Additionally, the COSE Header counter signature MAY be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID {{-countersign}}. +. The application of counter signing 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). A CoSWID MUST be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in {{sec-sec}}) for more information on why a signed CoSWID is valuable in most cases. From 4f30db65a6ba5e533c547ca42c1ee1251cfe15f0 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Sun, 6 Mar 2022 21:21:24 +0100 Subject: [PATCH 59/73] Spell checker --- draft-ietf-sacm-coswid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 6ac3d47..53f3ed1 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1892,5 +1892,5 @@ This document draws heavily on the concepts defined in the ISO/IEC 19770-2:2015 We are also grateful to the careful reviews provided by ... - From e74210366c48907ede65b0a81b5226d4dd4c951d Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Sun, 6 Mar 2022 21:34:58 +0100 Subject: [PATCH 60/73] Discuss cross-algorithm attacks on hashes --- draft-ietf-sacm-coswid.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/draft-ietf-sacm-coswid.md b/draft-ietf-sacm-coswid.md index 53f3ed1..59c2cfe 100644 --- a/draft-ietf-sacm-coswid.md +++ b/draft-ietf-sacm-coswid.md @@ -1643,7 +1643,7 @@ The COSE_Sign structure allows for more than one signature, one of which MUST be {: sourcecode-markers="true"} Additionally, the COSE Header counter signature MAY be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID {{-countersign}}. -. The application of counter signing 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). +The application of counter signing 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). A CoSWID MUST be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in {{sec-sec}}) for more information on why a signed CoSWID is valuable in most cases. @@ -1681,6 +1681,16 @@ When an authoritative tag is signed, the originator of the signature can be veri Loss of control of signing credentials used to sign CoSWID tags would create doubt about 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 version number would not be 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 revoke certificates associated with the compromised credentials to avoid validating tags signed with them. The process for doing this is beyond the scope of this specification. +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. + CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag does not need to be protected against unintended disclosure on an endpoint. @@ -1889,7 +1899,8 @@ Changes from version 00 to version 01: 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. -We are also grateful to the careful reviews provided by ... +We are also grateful for the careful reviews provided by the IESG +reviewers. Special thanks go to Benjamin Kaduk.