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

Roman Danyliw <rdd@cert.org> Sat, 06 March 2021 00:12 UTC

Return-Path: <rdd@cert.org>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C267C3A144B for <sacm@ietfa.amsl.com>; Fri, 5 Mar 2021 16:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xz4_MokUcwbN for <sacm@ietfa.amsl.com>; Fri, 5 Mar 2021 16:12:23 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C817B3A1449 for <sacm@ietf.org>; Fri, 5 Mar 2021 16:12:23 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu []) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 1260CM4s040152 for <sacm@ietf.org>; Fri, 5 Mar 2021 19:12:22 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 1260CM4s040152
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1614989542; bh=Am1MAsaqXqJAxxi0wqbbB/xgG16oNteoHJBulzVUpMw=; h=From:To:Subject:Date:From; b=tompdnvd8m/KnKerc0r4za05NVPskG3hSXxwp5vUdQ04jvep6MdAwcfAkfTQi0x72 BwZ0PJZtndxMgg5pD88NBvVLvhCk+fxXSbURGeUqwhJfN4lR8ScrVkQAOetgJ9jeSB cKDCuRvhK0/3cyf6vAnEZh2W8OgrffGqQ1Wqcqc4=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu []) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 1260CMU7027519 for <sacm@ietf.org>; Fri, 5 Mar 2021 19:12:22 -0500
Received: from MORRIS.ad.sei.cmu.edu ( by MURIEL.ad.sei.cmu.edu ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 5 Mar 2021 19:12:22 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.013; Fri, 5 Mar 2021 19:12:22 -0500
From: Roman Danyliw <rdd@cert.org>
To: "<sacm@ietf.org>" <sacm@ietf.org>
Thread-Topic: Updated AD Review: draft-ietf-sacm-coswid-17
Thread-Index: AdcSHEPkUhzZy5IpTQSFgR6AQhV5VQ==
Date: Sat, 6 Mar 2021 00:12:20 +0000
Message-ID: <91940fd9d62c470ebde75a04812d5e68@cert.org>
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: <https://mailarchive.ietf.org/arch/msg/sacm/IDi8scO7T4PhTXLA-Wzvl-XnbiQ>
Subject: [sacm] Updated AD Review: draft-ietf-sacm-coswid-17
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 00:12:26 -0000


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.