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

Roman Danyliw <> Wed, 10 March 2021 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7CD23A0A1E for <>; Wed, 10 Mar 2021 06:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jPasvjgQCoqS for <>; Wed, 10 Mar 2021 06:07:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 457423A0A06 for <>; Wed, 10 Mar 2021 06:07:08 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 12AE776T016325 for <>; Wed, 10 Mar 2021 09:07:07 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 12AE776T016325
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=yc2bmwvrj62m; t=1615385227; bh=oUnOachPSVWp2+sIXIQzNKv45CjNp5dQoUQ0ushotZA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=UQMK2494gXik/bnSllbufF1Nad2QsXj11fuHgKO0tH5aCRb7hFjFHPeVirFte+o+x v5kTnpfRfBqgU4Ead25UbaEvyBit5nOxpR4HLcTqzaGoLnj1DAeJp2AOzEVu6TPPVr u336eQ28dBzZl+veKGRH0riank9GArJJE1NfeotA=
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 12AE73jR018467 for <>; Wed, 10 Mar 2021 09:07:03 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:07:03 -0500
Received: from ([fe80::555b:9498:552e:d1bb]) by ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 09:07:03 -0500
From: Roman Danyliw <>
To: "<>" <>
Thread-Topic: Updated AD Review: draft-ietf-sacm-coswid-17
Thread-Index: AdcSHEPkUhzZy5IpTQSFgR6AQhV5VQDmKbRw
Date: Wed, 10 Mar 2021 14:07:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [sacm] Updated AD Review: draft-ietf-sacm-coswid-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Mar 2021 14:07:12 -0000


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 <> On Behalf Of Roman Danyliw
> Sent: Friday, March 5, 2021 7:12 PM
> To: <> <>
> 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 (
> WKPxgQAYLfBzDdE/) and again to the -16
> (
> 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
> [-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
> _______________________________________________
> sacm mailing list