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

[Roman Danyliw <[e-mail]>]

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 <[e-mail]> On Behalf Of Roman Danyliw
> Sent: Friday, March 5, 2021 7:12 PM
> To: <[e-mail]> <[e-mail]>
> 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.
> 
> [-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

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

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

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