Subject: [sacm] [sacmwg/draft-ietf-sacm-coswid] addressed comments from Roman Danyliw (#44)

From: David Waltermire <[email-masked]>
Date: Mon, 12 Jul 2021 06:19:59 -0700

Addressed the following comments:

&gt; ** [-15] Section 2.3  Are there any considerations that would need to 
&gt; be made for versioning CoSWID beyond the native support provided with CBOR?

[Per IETF 110] Add text on the order of native CDDL approach for handling version is used.  If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it.

[daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.]

&gt; ** [-15] Section 4.1 and 5.2.4.  [SEMVER] doesn&#39;t meet the threshold 
&gt; for a normative requirement and a &quot;specification required&quot; - it&#39;s just 
&gt; a website.  If this is used in SWID then that would be compelling argument to waiver it.
&gt; However, that should be explicitly stated here.  If it isn&#39;t, we 
&gt; should discuss it a bit more.
&gt; 
&gt; [-16: Can the ISO spec please be used as the basis for this reference 
&gt; (even it just points to the same website?)]

[Per IETF 110] see -16.  Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text

[daw: This has been done in section 4.1.]

&gt; ** [17] Section 6.*.  Various &quot;FIXME&quot; markers need to be populated.

[daw: The FIXME markers have been replaced with actual text.]

&gt; 
&gt; ** [-15] Section 6.  What are the normative requirements, if any, on 
&gt; signing the CoSWID?
&gt; 
&gt; [-17] Is there something in SWID preventing normative guidance that 
&gt; says SHOULD or MUST sign?

[daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.]

[Per IETF 110] We discussed adding language on the order of &quot;This document specifies a data format and an associated integrity mechanism agnostic of a deployment.  Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances.&quot;  &gt; ** [-15] Section 6.  Per &quot;When an authoritative tag is signed, the software
&gt; provider can be authenticated as the originator of the signature&quot;, 
&gt; what is the binding between the software provider and the key used to 
&gt; provide the signature?  Put in another way, how do I know the 
&gt; signature on the CoSWID really belongs to the software provider?  Same for a supplementary tag?

[daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.]

&gt; 
&gt; [-16] Thanks for the new text.  Unless more detailed will be provided, 
&gt; please add that provisioning and validation logic of these tags will 
&gt; be done via local policy and is outside the scope of this document]
2

[daw: Not sure which tags this applies to? Signing? All of section 2?]

&gt; 
&gt; [-17] Section 9. Per &quot;A trustworthy association between the signature 
&gt; and the originator of the signature can be established via trust 
&gt; anchors. A certification path between a trust anchor and a certificate 
&gt; including a pub-key enabling the validation of a tag signature can 
&gt; realize the assessment of trustworthiness of an authoritative tag.&quot;, 
&gt; this is true.  Additionally, there is also the problem of how to 
&gt; associate the right key with the software provider or party permitted 
&gt; to add tags.  This significant complexity does not need to be solved 
&gt; here, but please acknowledge that it is someone that needs to be addressed by the users, and is out of scope here.

[daw: done.]

&gt; 
&gt; ** [-15] Section 6.  Per &quot;Having a signed authoritative SWID/CoSWID 
&gt; tag can be useful when the information in the tag needs to be trusted 
&gt; such as when the tag is being used to convey reference integrity 
&gt; measurements for software components &quot;, when would this tag not need 
&gt; to be trusted?  Perhaps I misunderstood, but I thought the whole 
&gt; premise of using SWIDs/CoSWIDs in the SACM context was to support 
&gt; asset inventory (i.e., reference integrity measurement of software 
&gt; components).  I&#39;m not clear on the use case for unsigned tags - that 
&gt; said, I recognize that the SWID spec doesn&#39;t specify that either.

[daw: This confusing text has been removed.]

&gt; [-17] Please add caution that without an integrity scheme, any user or 
&gt; process that has write-access to the CoSWID tag can alter it.  As 
&gt; such, any consuming application need to treat this data with caution.

[daw: done.]

&gt; ** [-17] Section 9.  Per &quot;Thus, authoritative CoSWID tags can be 
&gt; trusted to represent authoritative information about the software 
&gt; component&quot;, this seems too strong of a statement and dependent on the 
&gt; custody of that tag.  If it isn&#39;t signed, little, if anything, 
&gt; extracted from CoSWID tag should be considered authoritative.

[daw: We added a note about this.]

&gt; 
&gt; ** [-17] Section 9. Nit. s/pub-key/public key/

[daw: Done.]

&gt; ** [-17] Section 9.  Per &quot;Input sanitization and loop detection are 
&gt; two ways that implementations can address this concern&quot;, and the use 
&gt; of signed tags whose signature is verified on use too.

[daw: Added signature validation as a way.]

Regards,
Roman

&gt; Regards,
&gt; Roman

You can view, comment on, or merge this pull request online at:

  https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44

-- Commit Summary --

  * addressed comments from Roman Danyliw

-- File Changes --

    M draft-ietf-sacm-coswid.md (26)

-- Patch Links --

https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44.patch
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44

---

From: David Waltermire <[email-masked]>
Date: Mon, 12 Jul 2021 10:46:08 -0700

@david-waltermire-nist pushed 1 commit.

bb4a1734d83a2b983349167cf38fd9ccfeb273c7  added additional text about signing and validation

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44/files/545c3a57f49f22ed509e769a2064b0294e52b7e4..bb4a1734d83a2b983349167cf38fd9ccfeb273c7

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 12 Jul 2021 13:04:30 -0700

@henkbirkholz approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44#pullrequestreview-704495129

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 12 Jul 2021 13:05:12 -0700

Merged #44 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/44#event-5009590977