Subject: [sacm] Updated AD Review: draft-ietf-sacm-coswid-17

From: Roman Danyliw <[email-masked]>
Date: Sat, 6 Mar 2021 00:12:20 +0000

Hi!

Thanks for all of the work to date on updating this document in response to my AD review of -15 (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/) and again to the -16 (https://mailarchive.ietf.org/arch/msg/sacm/sYG4jhw0e56eD9v5nAQgl_z7lXs/).  To make we have a shared understanding of where we stand, let me reiterate my open issues/questions and places where we still need discussion based on the revisions in -16 or -17:

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

** [-15] Section 2.9.4.  The date field here is a CDDL time type.  In SWID, the equivalent is a xs:date.  Wouldn't it be more appropriate to use a CDDL tstr here?

[-16] I see you're tracking this and have a marker for it with [QUESTION: Is "time" a correct representation of XSD:date?]"

[-17] There appears to still be some discussion on list on which value to choose -- https://mailarchive.ietf.org/arch/msg/sacm/Tanq_rBu1YFwLaVkorrUxCfqKks/

** [-15] Section 2.10.  It would be helpful to be clear on where the naming convention and semantics don't align between SWID and CoSWID don't line up.  I caught the following:

-- Names
(SWID) Process@name is (CoSWID) process-name

(SWID) File@name is (CoSWID) fs-name

-- Semantics
(CoSWID) file-entry has a hash-entry, but does that have an equivalent in SWID?

(CoSWID) Section 2.9.1.  Per path-elements, what is the equivalent of that in SWID?

** [-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?)]

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

** [-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?

** [-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?

[-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]

[-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.

** [-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.

[-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.

** [-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.

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

** [-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.

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 10 Mar 2021 14:07:02 +0000

Hi!

Based on the IETF 110 meeting discussion, I have updated the list of open issues with additional commentary or remove those that don't apply (because they in fact were addressed in -17).

> -----Original Message-----
> From: sacm <[email-masked]> On Behalf Of Roman Danyliw
> Sent: Friday, March 5, 2021 7:12 PM
> To: <[email-masked]> <[email-masked]>
> Subject: [sacm] Updated AD Review: draft-ietf-sacm-coswid-17
> 
> Hi!
> 
> Thanks for all of the work to date on updating this document in response to my
> AD review of -15 (https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-
> WKPxgQAYLfBzDdE/) and again to the -16
> (https://mailarchive.ietf.org/arch/msg/sacm/sYG4jhw0e56eD9v5nAQgl_z7lXs/).
> To make we have a shared understanding of where we stand, let me reiterate
> my open issues/questions and places where we still need discussion based on
> the revisions in -16 or -17:
> 
> ** [-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.

> ** [-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.
> 

[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

> [-17] Is there something in SWID preventing normative guidance that says

[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?
> 
> [-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]
> 
> [-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.
> 
> ** [-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.
> 
> [-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.
> 
> ** [-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.
> 
> ** [-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.

Regards,
Roman

> Regards,
> Roman
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm