Re: [auth48] [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review

[Charles M Schmidt <[e-mail]>]

Hello,

Thank you for the feedback. I've included responses to all questions in this email. 

1) This question is directed at Roman

2) Please add the zip code for Jessica:
Author' Addresses:
OLD:
 Jessica Fitzgerald-McKay
 National Security Agency
 9800 Savage Road
 Ft. Meade, Maryland
 United States of America

NEW:
 Jessica Fitzgerald-McKay
 National Security Agency
 9800 Savage Road
 Ft. Meade, Maryland 20755
 United States of America

3) Email of 5/2 noted that this question is removed.

4) Agree with proposed change:
Abstract:

OLD:
 CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that  allow CoSWIDs to describe additional types of information, all in a  more memory efficient format.

NEW:
 CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. 

5) Agree with proposed change:
Section 1.1

OLD:
The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060: Guidelines for the Creation of  Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID tags: primary, patch, corpus, and supplemental.  The following text  is paraphrased from these sources.

NEW:
The SWID specification and supporting guidance provided in NIST Internal Report (NISTIR) 8060 ("Guidelines for the Creation of Interoperable Software Identification (SWID) Tags") [SWID-GUIDANCE] define four types of SWID tags: primary, patch, corpus, and supplemental. The following text is paraphrased from these sources.

6) Text is correct as is. A primary tag is indicated by not setting any of the other indices for other tags. As such, it does not need its own index. Primary tags are described in section 1.1. NO CHANGE.

7) Agree with proposed text (with a slight change in the comma position at the end):
Section 1.1:

OLD:
 Tags are deployed and previously deployed tags that are typically removed (indicated by an  "x" prefix) at each lifecycle stage, as follows:

NEW:
 Tags are deployed, and previously deployed tags are typically removed (indicated by an "x" prefix), at each lifecycle stage as follows:

8) All "Note:" entries should be <aside>s.
Section 1.1: The paragraph that starts with "Note" should be an <aside>. Also, it should be indented but without a lead bullet. The Note paragraph is a second paragraph that is part of the preceding bullet on Software Upgrading.

OLD:
            - Software Upgrading. As a software component is upgraded to a
	new version, new primary and supplemental tags replace
 	existing tags, enabling timely and accurate tracking of
 	updates to software inventory. While not illustrated in the
	figure, a corpus tag can also provide information about the
	upgrade installer and dependencies that need to be installed
	before the upgrade.

Note: In the context of software tagging software patching and
updating differ in an important way. When installing a patch, a set
of file modifications are made to pre-installed software which do
not alter the version number or the descriptive metadata of an
installed software component. An update can also make a set of file
modifications, but the version number or the descriptive metadata of
an installed software component are changed.

NEW:
            - Software Upgrading. As a software component is upgraded to a
	new version, new primary and supplemental tags replace
 	existing tags, enabling timely and accurate tracking of
 	updates to software inventory. While not illustrated in the
	figure, a corpus tag can also provide information about the
	upgrade installer and dependencies that need to be installed
	before the upgrade.

	Note: In the context of software tagging software patching and
	updating differ in an important way. When installing a patch, a set
	of file modifications are made to pre-installed software which do
	not alter the version number or the descriptive metadata of an
	installed software component. An update can also make a set of file
	modifications, but the version number or the descriptive metadata of
	an installed software component are changed.

Section 3: Make the whole paragraph that starts with "Note" an <aside>.

Section 6.2.4: Make the sentence that starts with "Note:" an <aside>. Only this sentence should be an aside.

9) Agree with proposed text:
Section 2:
OLD:
 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  Section 6.2.2. 

NEW:
 The integer values are defined in a registry specific to the kind of value; the text values are not intended for interchange and are exclusively meant for private use as defined in Section 6.2.2. 

10) Types need to be updated:
Global (in the xml lines 362, 366, 371, 382, 567, 735, 759, 830, 995, 1089, 1105, 1197, 1214)):
OLD:
<sourcecode type="cddl">

NEW:
<sourcecode type="cddl" name="coswid-exposition.cddl">

XML line 1243:
OLD:
<sourcecode type="cddl" markers="true">

NEW:
<sourcecode type="cddl" name="concise-swid-tag.cddl" markers="true">

XML line 2900:
OLD:
<sourcecode type="cddl" markers="true">

NEW:
<sourcecode type="cddl" name="sign1.cddl" markers="true">

XML line 2938:
OLD:
<sourcecode type="cddl" markers="true">

NEW:
<sourcecode type="cddl" name="sign.cddl" markers="true">

XML line 2999:
OLD:
<sourcecode type="cddl" markers="true">

NEW:
<sourcecode type="cddl" name="tags.cddl" markers="true">

11) The author comment has been resolved and can be removed.

12) This is not a verbatim quote. The quotation marks should be removed.
Section 2.1:
OLD:
The CDDL "text" type is represented in CBOR as a major type 3, which  represents "a string of Unicode characters that [are] encoded as UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]).

NEW:
The CDDL "text" type is represented in CBOR as a major type 3, which represents a string of Unicode characters that [are] encoded as UTF-8 [RFC3629] (see Section 3.1 of [RFC8949]).

13) We request no change. Unlike the entity-entry and link-entry values, the version-scheme is relatively straightforward and doesn't have or need a section dedicated to it. We feel a reference from section 4.1 is unnecessary and (since only a small portion of that section deals with version-scheme) potentially confusing. 

14) The MUST NOT only applies to the "right part" of the value in 6.7. Proposing the following change to avoid ambiguity.
Section 2.3:
OLD: 
A textual tag-id MUST NOT contain a sequence of two underscores ("__", see Section 6.7).

NEW:
A textual tag-id value MUST NOT contain a sequence of two underscores ("__"). This is because a sequence of two underscores is used to separate the TAG_CREATOR_REGID value and UNIQUE_ID value in a Software Identifier and a sequence of two underscores in a tag-id value could create ambiguity when parsing this identifier. See Section 6.7.

15) Replace confusing parenthetical
Section 2.3:

OLD:
- 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 (Section 2, for the "Version Scheme" registry Section 4.1).

NEW:
- 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. For the "Version Scheme" values, see Section 4.1.

16) Agree with proposed change.
Section 2.3

OLD:
link (index 4): Provides a means to establish relationship arcs between the tag and another items.

NEW:
link (index 4):  Provides a means to establish relationship arcs between the tag and another item.

17) Delete the confusing sentence.
Section 2.4

OLD:
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.

NEW:
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.

18) Agree with proposed change.
Section 2.6:

OLD:
role (index 33): An integer or textual value (integer label with text escape, see Section 2) representing the relationship(s) between the entity, and this tag or the referenced software component.

NEW:
role (index 33):  An integer or textual value (integer label with text escape; see Section 2) representing the relationship(s) between the entity and this tag or the referenced software component.

19) Should be 256..65536.
Section 2.7:

OLD:
$rel /= -356..65536 / text

NEW:
$rel /= -256..65536 / text

20) Rephrase two bullets:
Section 2.7:

OLD:
- a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This expression 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-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query [W3C.REC-xpath20-20101214] that matches items in that tag (Section 5.2). 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 Section 5.2.

NEW:
- a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This expression 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". See Section 5.1 for guidance on the "swid" expression.

- a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query [W3C.REC-xpath20-20101214] that matches items in that tag (Section 5.2). 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 Section 5.2 for guidance on the "swidpath" expression.

21) Agree with proposed changes.
Section 2.7:
*  ownership (index 39): An integer or textual value (integer label
    with text escape, see Section 2, for the "Software ID Link
    Ownership Values" registry Section 4.3) 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.
...
 *  rel (index 40): An integer or textual value that (integer label
    with text escape, see Section 2, for the "Software ID Link Link
    Relationship Values" registry Section 4.3) identifies the
    relationship between this CoSWID and the target resource
    identified by the "href" item.
...
 *  use (index 42): An integer or textual value (integer label with
    text escape, see Section 2, for the "Software ID Link Link
    Relationship Values" registry Section 4.3) used to determine if
    the referenced software component has to be installed before
    installing the software component identified by the COSWID tag.

NEW:
*  ownership (index 39):  An integer or textual value (integer label
    with text escape; see Section 2).  See Section 4.3 for the list
    of values available for this item.  This item is 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.
...
*  rel (index 40):  An integer or textual value (integer label with
    text escape; see Section 2).  See Section 4.4 for the list of
    values available for this item.  This item identifies the
    relationship between this CoSWID and the target resource
    identified by the href item.
...
*  use (index 42):  An integer or textual value (integer label with
    text escape; see Section 2).  See Section 4.5 for the list of
    values available for this item.  This item is used to determine
    if the referenced software component has to be installed before
    installing the software component identified by the CoSWID tag.

22) Change i.e. to e.g.
Section 2.8:
OLD:
Examples of an entitlement-key might include a  serial number, product key, or license key.  For values that  relate to a given software component install (i.e., license key),  a supplemental tag will typically contain this information.

NEW:
Examples of an entitlement-key might include a serial number, product key, or license key.  For values that relate to a given software component install (e.g., license key),  a supplemental tag will typically contain this information.

23) "$$software-meta-extension" is correct
Section 2.8:

OLD:
$$meta-extension: This CDDL socket can be used to extend the software-meta-entry group model. See Section 2.2.

NEW:
$$software-meta-extension: This CDDL socket can be used to extend the software-meta-entry group model. See Section 2.2.

24) 65536 is correct
Section 2.10:

OLD:
$rel /= -256..64436 / text

NEW:
$rel /= -256..65536 / text

OLD:
; supplemental=11 ; this is already defined earlier

NEW:
; supplemental=11 ; already defined in the "global map member" integer indices

25) Revised text
Section 3:

OLD:
Note: Multiple of the corpus, patch, and supplemental items can have  values set as "true".  The rules above provide a means to determine  the tag's type in such a case.  For example, a SWID or CoSWID tag for  a patch installer might have both corpus and patch items set to  "true".  In such a case, the tag is a "Corpus Tag".  The tag  installed by this installer would have only the patch item set to  "true", making the installed tag type a "Patch Tag".

NEW:
Note: It is possible for some or all of the corpus, patch, and supplemental items to simultaneously have values set as “true”. The rules above provide a means to determine the tag's type in such a case.  For example, a SWID or CoSWID tag for a patch installer might have both corpus and patch items set to "true".  In such a case, the tag is a "Corpus Tag".  The tag installed by this installer would have only the patch item set to "true", making the installed tag type a "Patch Tag".

26) Agree with proposed text
Section 4:

OLD:
This section defines a number of kinds of indexed label values that  are maintained in a registry each (Section 6).

NEW:
This section defines multiple kinds of indexed label values that are maintained in several IANA registries.  See Section 6 for details.

27) Agree with proposed text
Table 6:

OLD:
| 10    | supersedes        | The link references another           |
 |       |                   | software that this software           |
 |       |                   | replaces.  A patch tag (see           |
...

NEW:
| 10    | supersedes        | The link references other software   |
 |       |                   | (e.g., an older software version)    |
 |       |                   | that this software replaces.  A path tag (see   |
...

28) Agree with proposed text:
Section 6.2.1:

OLD:
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.

NEW:
This allows values -1 to -24 to be expressed as a single uint8_t in CBOR, and values -25 to -256 to be expressed using an additional uint8_t in CBOR.

29) Agree with proposed text:
Sections 6.2.4 through 6.2.8

OLD:
Initial registrations for the "Software ID Version Scheme Values"
 registry are provided below, which are derived from the textual  version scheme names defined in [SWID].
...
 Initial registrations for the "Software ID Entity Role Values"
 registry are provided below, which are derived from the textual  entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Ownership Values"
 registry are provided below, which are derived from the textual  entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Relationship Values"
 registry are provided below, which are derived from the link  relationship values defined in [SWID].
...
 Initial registrations for the "Software ID Link Use Values" registry  are provided below, which are derived from the link relationship  values defined in [SWID].

NEW:
Initial registrations for the "Software ID Version Scheme Values"
 registry are provided below and are derived from the textual version scheme names defined in [SWID].
...
 Initial registrations for the "Software ID Entity Role Values"
 registry are provided below and are derived from the textual entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Ownership Values"
 registry are provided below and are derived from the textual entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Relationship Values"
 registry are provided below and are derived from the link relationship values defined in [SWID].
...
 Initial registrations for the "Software ID Link Use Values" registry are provided below and are derived from the link relationship values defined in [SWID]. 

30) Use "software-version item"
Section 6.2.4

OLD:
define a value space for the corresponding version item that is

NEW:
define a value space for the corresponding software-version item that is

31) Change to underscore
Sections 7 and 8

OLD:
COSE-Sign1-coswid<payload>

NEW:
COSE_Sign1-coswid<payload>

OLD:
COSE-Sign-coswid<payload>

NEW:
COSE_Sign-coswid<payload>

32) Agree with proposed removal of extraneous space.
Section 7:

OLD:
signature : bstr -->

NEW:
signature: bstr -->

33) Agree with proposed text:
Section 8:

OLD:
Consecutively, the CBOR tag for CoSWID tags  defined in Table 21 SHOULD be used in conjunction with CBOR data  items that are a CoSWID tags.

NEW:
Consequently, the CBOR tag defined by this document (Table 21) for CoSWID tags SHOULD be used in conjunction with CBOR data items that are CoSWID tags.

34) Rephrase
Section 8

OLD:
a tagged CoSWID tag

NEW:
a CBOR-tagged CoSWID tag

35) Agree with proposed text
Section 9:

OLD:
A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since it was signed.

NEW:
A signed CoSWID tag (see Section 7) whose signature has been validated can be relied upon to be unchanged since the time at which it was signed.

36) Agree with the first proposed text.
Section 9:

OLD:
A certification path between a trust anchor and a certificate  including a public key enabling the validation of a tag signature can  realize the assessment of trustworthiness of an authoritative tag.

NEW:
A certification path between a trust anchor and a certificate, including a public key enabling the validation of a tag signature, can realize the assessment of trustworthiness of an authoritative tag.

37) Reword
Section 9:

OLD:
This requires an association between the signature and the  tag's entity item associated corresponding to the software provider.

NEW:
This requires verifying that party that signed the tag is the same party given in the software-creator role of the tag’s entity item.

38) Replace with "limited to"
Section 9:

OLD:
Access to the collection of an endpoint's CoSWID tags needs to be appropriately controlled to authorized applications and users using an appropriate access control mechanism.

NEW:
Access to the collection of an endpoint's CoSWID tags needs to be limited to authorized applications and users using an appropriate access control mechanism.

39) Agree with proposed text
References:

OLD:
[W3C.REC-css3-mediaqueries-20120619]
            Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619, 19 June 2012, <https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/>.

NEW:
[W3C.REC-css3-mediaqueries-20120619]
            Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619, 19 June 2012, <https://www.w3.org/TR/mediaqueries-3/>.

40) Document was reviewed for inclusive language. Authors did not identify any other issues. In looking for a replacement for "whitespace", none of the proposed replacements were seen as adequate because they were not sufficiently comprehensive to include all the types of characters that fall under the general term of "whitespace". If you have a suggestion we would be open to using it, but currently do not have an adequate replacement.

41) Normalizations:
Global:

OLD:
URI-scheme

NEW:
URI scheme

* Note: one instance of "URI-scheme" is in a URL, and thus should not be changed.

OLD:
XPATH

NEW:
XPath

OLD:
Private Use

NEW:
private use

* NOTE: one instance of "Private Use" is in a section title and should not be changed.

OLD:
XML Schema

NEW:
XML schema

* NOTE: one instance of "XML Schema" is in the title of a reference and it should not be changed.

OLD:
indexes

NEW:
indices

OLD:
"href" item

NEW:
href item

OLD:
"role" item

NEW
role item

Section 1:

OLD:
Remote Attestation, which requires a link between reference integrity measurements (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].

NEW:
Remote Attestation, which requires a link between Reference Integrity Manifests (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture].

I believe this addresses all of your questions and feedback. Please let me know if I missed anything or if any part of this response is unclear.

Thanks a bunch,
Charles

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Friday, April 14, 2023 4:46 PM
To: [e-mail]; [e-mail]; Charles M Schmidt <[e-mail]>; Waltermire, David <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Inacio, Christopher <[e-mail]>; [e-mail]; [e-mail]
Subject: [EXT] [AD] Re: AUTH48: RFC-to-be 9393 <draft-ietf-sacm-coswid-24> for your review

Authors and *Roman (AD),

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 

*AD, please see question #1.

1) <!-- [rfced] *AD - This document underwent two version changes since version -22, which we edited last year; we later received notifications for versions -23 and -24.

We manually incorporated the updates by looking at the diff between version -22 and version -24 on the Datatracker.

Please review the changes to Sections 5 and 6 carefully, and let us know if you approve. -->


2) <!-- [rfced] Authors' Addresses:  Jessica Fitzgerald-McKay's contact information is the only listing that does not include a postal code.
If you would like us to include a postal code, please provide it.
(We see "20755" used in
draft-ietf-rats-tpm-based-network-device-attest.)

Original:
 Jessica Fitzgerald-McKay
 National Security Agency
 9800 Savage Road
 Ft. Meade, Maryland
 United States of America
 Email: [e-mail] -->


3) <!-- [rfced]  As it appears that "LocalWords" as listed after the Acknowledgments section in the original XML file refers to "key words" as defined in RFC 2119, we list them here as key words and have added them to our database record for this document.

If this is incorrect, please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>,
and we will update the <keyword> settings here and in our database record accordingly.

Original:
 LocalWords:  SWID verifier TPM filesystem discoverable CoSWID -->


4) <!-- [rfced] Abstract:  To what does "similar" refer in this sentence?  If the suggested text is not correct, please provide clarifying text.

Original:
 CoSWID supports a similar set of
 semantics and features as SWID tags, as well as new semantics that  allow CoSWIDs to describe additional types of information, all in a  more memory efficient format.

Suggested:
 CoSWID supports a set of
 semantics and features that are similar to those for SWID tags, as  well as new semantics that allow CoSWIDs to describe additional  types of information, all in a more memory-efficient format. -->


5) <!-- [rfced] Section 1.1:  Because we see "paraphrased from these sources", we changed "defines" to "define" in the sentence that precedes it.  If this is incorrect, please provide clarifying text.

Original:
 The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060: Guidelines for the Creation of  Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID
 tags: primary, patch, corpus, and supplemental.  The following text  is paraphrased from these sources.

Currently:
 The SWID specification and supporting guidance provided in NIST  Internal Report (NISTIR) 8060 ("Guidelines for the Creation of  Interoperable Software Identification (SWID) Tags") [SWID-GUIDANCE]  define four types of SWID tags: primary, patch, corpus, and  supplemental.  The following text is paraphrased from these sources. -->


6) <!-- [rfced] Section 1.1:  Section 2.3 does not contain a description of the primary tag type.  We also see that the primary tag type does not have an index number, as do the other three types.

Please confirm that (1) the lack of a description for the primary tag type in Section 2.3 will not be an issue for readers and (2) the primary tag type should not have an index number.

Original ("four tags types" has been changed to "four tag types"):
 A detailed description of the four
 tags types is provided in Section 2.3. -->


7) <!-- [rfced] Section 1.1:  This sentence did not parse.  We changed "that are typically removed" to "are typically removed".  If this is incorrect, please provide clarifying text.

Original:
 Tags are deployed and
 previously deployed tags that are typically removed (indicated by an  "x" prefix) at each lifecycle stage, as follows:

Currently:
 Tags are deployed, and
 previously deployed tags are typically removed (indicated by an "x"
 prefix) at each lifecycle stage, as follows: -->


8) <!-- [rfced] Please review whether any of the separate "Note:"
paragraphs in this document should be in the <aside> element.
<aside> is defined as "a container for content that is semantically less important or tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside) -->


9) <!-- [rfced] Section 2:  It appears that one or more words are missing from this sentence.  Should "and exclusively meant" be "and are exclusively meant"?  If not, please provide clarifying text.

Original:
 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  Section 6.2.2. -->


10) <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness.  If the current list of preferred values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, please let us know.

Also, please review the remaining two instances of the artwork element.  Should any of the artwork elements be tagged as sourcecode or another type of element?

Please note that (1) for the ABNF in Section 6.7, we changed artwork to sourcecode with type="abnf" and (2) we changed the instances of sourcecode types "cddl;example" to "cddl", as "cddl;example" is not included on <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
Please let us know any concerns. -->


11) <!-- [rfced] Please let us know if any updates are needed regarding this author comment as seen in the original approved document.

Original:
 Hmm, duplicate detection doesn't work in CDDL tool here. -->


12) <!-- [rfced] Section 2.1:  Because this text is quoted, we searched RFCs 3629 and 8949 but could not find this text in either RFC.  To avoid possible reader confusion, may we either rephrase as suggested or remove the quotes?

Original:
 The CDDL "text" type is represented in CBOR as a major type 3, which  represents "a string of Unicode characters that [are] encoded as
 UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]).

Suggested (per RFC 8949):
 The CDDL "text" type is represented in CBOR as a major type 3, which  represents a string of Unicode characters that are "encoded as
 UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]). -->


13) <!-- [rfced] Table 2:  All "$" entries in this table, except for $version-scheme, are indirectly cited in their respective subsections of Section 4.

Per the pattern of indirect citations used for the other entries (where the other entries point to Sections 2.6 ("The entity-entry
Map") and 2.7 ("The link-entry Map")), may we update the first sentence of Section 4.1 so that the sentence cites Section 2.3 ("The concise-swid-tag Map")?

Original (Table 2 and Section 4.1):
 | version-scheme   | $version-scheme | Section 4.1 |
...
 The following table contains a set of values for use in the concise-  swid-tag group's version-scheme item.

Suggested (Section 4.1):
 The following table contains a set of values for use in the concise-  swid-tag group's version-scheme item (see Section 2.3). -->


14) <!-- [rfced] Section 2.3:  This sentence seems to contradict the cited information in Section 6.7.  If the text below is correct as is, please confirm that "... MUST NOT contain a sequence of two underscores" and "... are connected with a double underscore (_)"
will be clear to readers.

Original:
 A textual
    tag-id MUST NOT contain a sequence of two underscores ("__", see
    Section 6.7).

From Section 6.7:
 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. -->


15) <!-- [rfced] Section 2.3:  We had trouble following the meaning of the parenthetical phrase in this sentence.  Also, we could not find a '"Version Scheme" registry'; this appears to refer to the "Software ID Version Scheme Values" registry, as mentioned a few lines after this sentence.

If the suggested text is not correct, please provide text that clarifies the meaning of "(Section 2, for the "Version Scheme"
registry Section 4.1)".

Original:
 *  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 (Section 2, for the
    "Version Scheme" registry Section 4.1).

Suggested:
 *  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 (Section 2).  See
    Section 4.1 for the list of values available for this item. -->


16) <!-- [rfced] Section 2.3:  As it appears that "another items" should be "another item", we updated this sentence accordingly.  If this is incorrect, please clarify this text.

Original:
 *  link (index 4): Provides a means to establish relationship arcs
    between the tag and another items.

Currently:
 link (index 4):  Provides a means to establish relationship arcs
    between the tag and another item. -->


17) <!-- [rfced] Section 2.4:  Does "software version" here refer to the software-version item or to a software version in general?

Original:
 This ensures that primary and corpus tags  have an identifiable software version. -->


18) <!-- [rfced] Section 2.6:  As it appears that this sentence means "... between (1) the entity and (2) this tag or the referenced software component", we removed the comma after "entity" to avoid reader confusion.  If this is incorrect (e.g., the intent is to say "between entities"), please provide clarifying text.

Original:
 *  role (index 33): An integer or textual value (integer label with
    text escape, see Section 2) representing the relationship(s)
    between the entity, and this tag or the referenced software
    component.

Currently:
 role (index 33):  An integer or textual value (integer label with
    text escape; see Section 2) representing the relationship(s)
    between the entity and this tag or the referenced software
    component. -->


19) <!-- [rfced] Section 2.7:  Please confirm that "-356..65536" and not "-256..65535" is correct here.  We ask because we do not see this range used anywhere else.

Original:
 $rel /= -356..65536 / text -->


20) <!-- [rfced] Section 2.7:  We do not see CBOR mentioned in Section 5.2.  Please confirm that this citation is correct and will be clear to readers.

Original:
 This specification
 does not define how to resolve an XPATH query in the context of  CBOR, see Section 5.2.

Possibly (perhaps the intent was to point to the XPath query or
   expression?):
 This specification does not define how to resolve an  XPath expression (Section 5.2) in the context of CBOR. -->


21) <!-- [rfced] Section 2.7:  We had trouble following the three instances of "... registry Section 4.3" in this section.  If the suggested text is not correct, please provide text that clarifies the meanings of these citations.

Please note that in the second and third suggestions we
(1) suggest different section numbers, as there appear to be some section-number mismatches and (2) changed "COSWID" to "CoSWID".

Original:
 *  ownership (index 39): An integer or textual value (integer label
    with text escape, see Section 2, for the "Software ID Link
    Ownership Values" registry Section 4.3) 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.
...
 *  rel (index 40): An integer or textual value that (integer label
    with text escape, see Section 2, for the "Software ID Link Link
    Relationship Values" registry Section 4.3) identifies the
    relationship between this CoSWID and the target resource
    identified by the "href" item.
...
 *  use (index 42): An integer or textual value (integer label with
    text escape, see Section 2, for the "Software ID Link Link
    Relationship Values" registry Section 4.3) used to determine if
    the referenced software component has to be installed before
    installing the software component identified by the COSWID tag.

Suggested:
 ownership (index 39):  An integer or textual value (integer label
    with text escape; see Section 2).  See Section 4.3 for the list
    of values available for this item.  This item is 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.
...
 rel (index 40):  An integer or textual value (integer label with
    text escape; see Section 2).  See Section 4.4 for the list of
    values available for this item.  This item identifies the
    relationship between this CoSWID and the target resource
    identified by the href item.
...
 use (index 42):  An integer or textual value (integer label with
    text escape; see Section 2).  See Section 4.5 for the list of
    values available for this item.  This item is used to determine
    if the referenced software component has to be installed before
    installing the software component identified by the CoSWID tag. -->


22) <!-- [rfced] Section 2.8:  Should "i.e.," (that is) be "e.g.," (for
example) here?  In other words are license keys the only applicable category as related to a given software component install, or would serial numbers or product keys also be applicable?

Original:
 Examples of an entitlement-key might include a  serial number, product key, or license key.  For values that  relate to a given software component install (i.e., license key),  a supplemental tag will typically contain this information. -->


23) <!-- [rfced] Section 2.8:  There appears to be a string mismatch for "$$meta-extension" versus "$$software-meta-extension".  Table 1, the CDDL earlier in this section, and Section 2.10 use "$$software-meta-extension".  Which string is correct?

Original:
 | software-meta-entry | $$software-meta-extension       | Section |
 |                     |                                 | 2.8     |
...
 * $$software-meta-extension,
...
 *  $$meta-extension: This CDDL socket can be used to extend the
    software-meta-entry group model.  See Section 2.2.
...
 * $$software-meta-extension, -->


24) <!-- [rfced] Section 2.10:

a) Please confirm that "64436" is correct here.  We ask because we do not see this value used anywhere else.

Original:
 $rel /= -256..64436 / text

b) "already defined earlier" reads oddly.  Should a specific section number be cited here?  If not, would "already defined" or "defined earlier" be sufficient?

Original:
 ; supplemental=11 ; this is already defined earlier -->


25) <!-- [rfced] Section 3:  We had trouble following the meaning of "Multiple of" here.  Does "Multiple of" mean "Multiples of", "Multiple", or something else?  Please clarify.

Original:
 Note: Multiple of the corpus, patch, and supplemental items can have  values set as "true".  The rules above provide a means to determine  the tag's type in such a case.  For example, a SWID or CoSWID tag for  a patch installer might have both corpus and patch items set to  "true".  In such a case, the tag is a "Corpus Tag".  The tag  installed by this installer would have only the patch item set to  "true", making the installed tag type a "Patch Tag". -->


26) <!-- [rfced] Section 4:  We could not follow the meaning of "that are maintained in a registry each".  Does this mean "that are each maintained in separate IANA registries (Section 6)", "that are maintained in several IANA registries (Section 6)", or something else?  If the suggested text is not correct, please clarify.

Original:
 This section defines a number of kinds of indexed label values that  are maintained in a registry each (Section 6).

Suggested:
 This section defines a number of kinds of indexed label values that  are maintained in several IANA registries.  See Section 6 for  details. -->


27) <!-- [rfced] Table 6:  We had trouble following "another software that" here.  We updated the text.  If this update is incorrect, please clarify this sentence.

Original:
 | 10    | supersedes        | The link references another           |
 |       |                   | software that this software           |
 |       |                   | replaces.  A patch tag (see           |

Currently:
 | 10    | supersedes        | The link references other software   |
 |       |                   | (e.g., an older software version)    |
 |       |                   | that this software replaces.  A      | -->


28) <!-- [rfced] Section 6.2.1:  Should "uint_8t" be "uint8_t" here?
We ask because we do not see any instances of "uint_8t" in any RFC.
However, we see "uint8_t" in RFC 8949.

Original:
 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. -->


29) <!-- [rfced] Sections 6.2.4 through 6.2.8:  As it appears that "which" in these sentences refers to the initial registrations derived from names or values defined in [SWID], and not to the registries themselves, we updated the sentences accordingly.  If these updates are incorrect, please provide clarifying text.

Original:
 Initial registrations for the "Software ID Version Scheme Values"
 registry are provided below, which are derived from the textual  version scheme names defined in [SWID].
...
 Initial registrations for the "Software ID Entity Role Values"
 registry are provided below, which are derived from the textual  entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Ownership Values"
 registry are provided below, which are derived from the textual  entity role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Relationship Values"
 registry are provided below, which are derived from the link  relationship values defined in [SWID].
...
 Initial registrations for the "Software ID Link Use Values" registry  are provided below, which are derived from the link relationship  values defined in [SWID].

Currently:
 Initial registrations for the "Software ID Version Scheme Values"
 registry are provided below and are derived from the textual version  scheme names defined in [SWID].
...
 Initial registrations for the "Software ID Entity Role Values"
 registry are provided below and are derived from the textual entity  role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Ownership Values"
 registry are provided below and are derived from the textual entity  role names defined in [SWID].
...
 Initial registrations for the "Software ID Link Relationship Values"
 registry are provided below and are derived from the link  relationship values defined in [SWID].
...
 Initial registrations for the "Software ID Link Use Values" registry  are provided below and are derived from the link relationship values  defined in [SWID]. -->


30) <!-- [rfced] Section 6.2.4:  Should "version item" here be "software-version item"?  We do not see "version item" used anywhere else in this document.

Original:
 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. -->


31) <!-- [rfced] Sections 7 and 8:  
Should "COSE-Sign1-coswid<payload>" and "COSE-Sign-coswid<payload>"
be "COSE_Sign1-coswid<payload>" and "COSE_Sign-coswid<payload>"
(i.e., underscores after "COSE" instead of hyphens)?  We ask because we see "COSE_Sign1" and "COSE_Sign" used in the second paragraph of Section 7.

Original:
 COSE-Sign1-coswid<payload> = [
...
 COSE-Sign-coswid<payload> = [
...
 signed-coswid-for<payload> = #6.18(COSE-Sign1-coswid<payload>)
     / #6.98(COSE-Sign-coswid<payload>) -->


32) <!-- [rfced] Section 7:  Should "signature :" be "signature:" here?

Original:
 signature : bstr -->


33) <!-- [rfced] Section 8:  We had trouble following this sentence.
If the suggested update is not correct, please provide text that clarifies the meaning of "Consecutively" and "a CoSWID tags".

Original:
 Consecutively, the CBOR tag for CoSWID tags  defined in Table 21 SHOULD be used in conjunction with CBOR data  items that are a CoSWID tags.

Suggested:
 Consequently, the CBOR tag defined by this  document (Table 21) for CoSWID tags SHOULD be used in conjunction  with CBOR data items that are CoSWID tags. -->


34) <!-- [rfced] Section 8:  "a tagged CoSWID tag" reads oddly.  Please confirm that the text is correct and will be clear to readers (e.g., are any words missing?).

Original:
 This specification allows for a tagged CoSWID tag to reside in a COSE  envelope that is also tagged with a CoSWID CBOR tag. -->


35) <!-- [rfced] Section 9:  To prevent some readers from possibly interpreting "since" as "because", we changed "since it was signed"
in this sentence to "since the time at which it was signed".  Please let us know any concerns.

Original:
 A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since it was signed.

Currently:
 A signed CoSWID tag (see Section 7) whose signature has been  validated can be relied upon to be unchanged since the time at which  it was signed. -->


36) <!-- [rfced] Section 9:  Does "including a public key" refer to the certification path or the certificate?

Original:
 A certification path between a trust anchor and a certificate  including a public key enabling the validation of a tag signature can  realize the assessment of trustworthiness of an authoritative tag.

Perhaps (certification path that includes):
 A certification path between a trust anchor and a certificate,  including a public key enabling the validation of a tag signature,  can realize the assessment of trustworthiness of an authoritative  tag.

Or possibly (certificate that includes):
 A certification path between (1) a trust anchor and (2) a certificate  that includes a public key enabling the validation of a tag signature  can realize the assessment of trustworthiness of an authoritative  tag. -->


37) <!-- [rfced] Section 9: We had trouble following this sentence.
Please provide text that clarifies the meaning of "associated corresponding to".

Original:
 This requires an association between the signature and the  tag's entity item associated corresponding to the software provider. -->


38) <!-- [rfced] Section 9:  "controlled to authorized applications and users" reads oddly.  Should "controlled to" be "controlled for" or perhaps "limited to"?  If not, please provide clarifying text.

Original:
 Access to the collection of an
 endpoint's CoSWID tags needs to be appropriately controlled to  authorized applications and users using an appropriate access control  mechanism. -->


39) <!-- [rfced] When accessing the page corresponding to [W3C.REC-css3-mediaqueries-20120619], we got a red popup saying "This version is outdated!"  Because the citations in this document are general in nature, we updated the citation string and reference listing as follows.  Please let us know any concerns.

Original:
 [W3C.REC-css3-mediaqueries-20120619]
            Rivoal, F., Ed., "Media Queries", W3C REC REC-css3-
            mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619,
            19 June 2012, <https://www.w3.org/TR/2012/REC-css3-
            mediaqueries-20120619/>.

Currently:
 [W3C.REC-mediaqueries-3-20220405]
            Rivoal, F., Ed., "Media Queries Level 3", W3C
            Recommendation REC-mediaqueries-3-20220405, 5 April 2022,
            <https://www.w3.org/TR/mediaqueries-3/>. -->


40) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.

For example, please consider whether the following should be updated:

 whitespace -->


41) <!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 URI-scheme (titles of Sections 6.6.1 and 6.6.2) / URI Scheme

 Version Scheme Name / version scheme name (in running text)

 XPATH / XPath (per usage elsewhere in this document and per W3C)

b) The following terms appear to be used inconsistently in this document.  Please let us know which form is preferred.

 private use / Private Use (e.g., "for private use", "for Private Use")

 XML schema / XML Schema

c) The following terms appear to be used inconsistently in this document and the companion documents. Please let us know which form is preferred.

  indices / indexes
  
  reference integrity measurements (RIM) / reference measurements (RIMs) /
  Reference Integrity Manifests (RIMs)

d) Quoting of item names was inconsistent.  For example:

 href item vs. "href" item
 role item vs. "role" item

 We removed the quotes, as item names were mostly unquoted.
 Please let us know any objections. -->


Thank you.

RFC Editor/lb/kc


On Apr 14, 2023, at 2:41 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/04/14

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor
  that have been included in the XML file as comments marked as
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your
  coauthors.  We assume that if you do not speak up that you
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of
  content are correctly tagged.  For example, ensure that <sourcecode>
  and <artwork> are set correctly.  See details at
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the
  formatted output, as generated from the markup in the XML file, is
  reasonable.  Please note that the TXT will have formatting
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9393.xml
  https://www.rfc-editor.org/authors/rfc9393.html
  https://www.rfc-editor.org/authors/rfc9393.pdf
  https://www.rfc-editor.org/authors/rfc9393.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9393-diff.html
  https://www.rfc-editor.org/authors/rfc9393-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9393-xmldiff1.html

XMLv3 file that is a best effort to capture v3-related format updates
only: 
  https://www.rfc-editor.org/authors/rfc9393.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9393

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9393 (draft-ietf-sacm-coswid-24)

Title            : Concise Software Identification Tags
Author(s)        : H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire
WG Chair(s)      : Karen O'Donoghue, Christopher Inacio

Area Director(s) : Roman Danyliw, Paul Wouters