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

Roman Danyliw <rdd@cert.org> Wed, 10 March 2021 14:07 UTC

Return-Path: <rdd@cert.org>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD23A0A1E for <sacm@ietfa.amsl.com>; Wed, 10 Mar 2021 06:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPasvjgQCoqS for <sacm@ietfa.amsl.com>; Wed, 10 Mar 2021 06:07:09 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 457423A0A06 for <sacm@ietf.org>; Wed, 10 Mar 2021 06:07:08 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 12AE776T016325 for <sacm@ietf.org>; Wed, 10 Mar 2021 09:07:07 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 12AE776T016325
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; 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 MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 12AE73jR018467 for <sacm@ietf.org>; Wed, 10 Mar 2021 09:07:03 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) 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 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; Wed, 10 Mar 2021 09:07:03 -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: AdcSHEPkUhzZy5IpTQSFgR6AQhV5VQDmKbRw
Date: Wed, 10 Mar 2021 14:07:02 +0000
Message-ID: <fccdac0644534fea8ac720f84780f276@cert.org>
References: <91940fd9d62c470ebde75a04812d5e68@cert.org>
In-Reply-To: <91940fd9d62c470ebde75a04812d5e68@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.203.75]
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/JOdWmBUqxv4TwuPZunVTueu84hc>
Subject: Re: [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: Wed, 10 Mar 2021 14:07:12 -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 <sacm-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Friday, March 5, 2021 7:12 PM
> To: <sacm@ietf.org> <sacm@ietf.org>
> 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
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm