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

[David Waltermire <[e-mail]>]

Addressed the following comments:

> ** [-15] Section 2.3  Are there any considerations that would need to 
> 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.]

> ** [-15] Section 4.1 and 5.2.4.  [SEMVER] doesn't meet the threshold 
> for a normative requirement and a "specification required" - it's just 
> a website.  If this is used in SWID then that would be compelling argument to waiver it.
> However, that should be explicitly stated here.  If it isn't, we 
> should discuss it a bit more.
> 
> [-16: Can the ISO spec please be used as the basis for this reference 
> (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.]

> ** [17] Section 6.*.  Various "FIXME" markers need to be populated.

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

> 
> ** [-15] Section 6.  What are the normative requirements, if any, on 
> signing the CoSWID?
> 
> [-17] Is there something in SWID preventing normative guidance that 
> 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 "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."  > ** [-15] Section 6.  Per "When an authoritative tag is signed, the software
> provider can be authenticated as the originator of the signature", 
> what is the binding between the software provider and the key used to 
> provide the signature?  Put in another way, how do I know the 
> 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.]

> 
> [-16] Thanks for the new text.  Unless more detailed will be provided, 
> please add that provisioning and validation logic of these tags will 
> 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?]

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

[daw: done.]

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

[daw: This confusing text has been removed.]

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

[daw: done.]

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

[daw: We added a note about this.]

> 
> ** [-17] Section 9. Nit. s/pub-key/public key/

[daw: Done.]

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

[daw: Added signature validation as a way.]

Regards,
Roman

> Regards,
> 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