[sacm] AD Review of draft-ietf-sacm-coswid-15

Roman Danyliw <rdd@cert.org> Thu, 01 October 2020 15:55 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 D33253A10DB for <sacm@ietfa.amsl.com>; Thu, 1 Oct 2020 08:55:47 -0700 (PDT)
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 C-CYcDZS7Grk for <sacm@ietfa.amsl.com>; Thu, 1 Oct 2020 08:55:45 -0700 (PDT)
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 69A663A0E0D for <sacm@ietf.org>; Thu, 1 Oct 2020 08:55:44 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 091Fthnh003979 for <sacm@ietf.org>; Thu, 1 Oct 2020 11:55:43 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 091Fthnh003979
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1601567743; bh=UoQElg8fW63M4cS9sZXurNPx1lxiGPPltKDTxrnCO0E=; h=From:To:Subject:Date:From; b=k1hgtdRQXrt2Q19WBit8377WAwsXYmDF7Fp+/rVqtjv+k7kjxpcoTAc1XxAtB3ode P6SFCiJBMWA8gvCLKUUEKqvL3LN86UIriB+of3ajwQRTg0NDiPsFkcNpcvT2DbH5GW QekH2L2nFBBmXLOb4uZOdEvAeb9yN/sO7rR8M4cs=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 091Ftc4X013147 for <sacm@ietf.org>; Thu, 1 Oct 2020 11:55:38 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 1 Oct 2020 11:55:38 -0400
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.1979.003; Thu, 1 Oct 2020 11:55:38 -0400
From: Roman Danyliw <rdd@cert.org>
To: "sacm@ietf.org" <sacm@ietf.org>
Thread-Topic: AD Review of draft-ietf-sacm-coswid-15
Thread-Index: AdaYCjvZey9/aFeHT8ajQFr2yIEMSg==
Date: Thu, 01 Oct 2020 15:55:37 +0000
Message-ID: <d2439fe599dd48508c7cedaed3be7764@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.177]
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/lZsk8wlOprU-WKPxgQAYLfBzDdE>
Subject: [sacm] AD Review of draft-ietf-sacm-coswid-15
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: Thu, 01 Oct 2020 15:55:48 -0000

Hi!

I conducted an AD review of draft-ietf-sacm-coswid-15.  Thanks for the work on this document.  My feedback is as follows:

** For shepherd write-up, please note CoSWID implementations: https://github.com/usnistgov/swid-tools/

** There are a number of places in the text where normative guidance is framed as "SWID/CoSWID".  Is this document suggesting any behavior of SWID, or is that just a short-hand because this CoSWID is just a different representation of the SWID information (?) /data(?) model?  What is the SWID behavior relative to the IANA registries? 

** In the long term, will SWID and CoSWID diverge and how should this be handled? This spec seems to defined a number of helpful extension points.  Does SWID have to use those? It might be helpful to clarify that in the text.  Section 2.2 (i.e., "The inclusion of extension points ...") and Section 2.3 ("... references to the IANA registries will be added to the next revision of [SWID]")hints that only future version of SWID might pick up these extensions.  The Section 5 IANA registrations call the registries "SWID/CoSWID" which seems confusing since SWID doesn't use them now.  Can you help me understand the state of play with SWID.  Without the background, it seems like a big leap that we're going to make registries for future work in another SDO (if they haven't already asked).

** Section 1.  Per the remote attestation use case, would the RATS architecture draft be more appropriate than [I-D.birkholz-rats-tuda]?

** Section 1.  
A SWID tag consisting
   of only required fields might be a few hundred bytes in size;
   however, a tag containing many of the optional fields can be many
   orders of magnitude larger

My rough read of this text is that if the required-only fields will generate a tag of ~300 bytes, a tag with optional fields would be ~3000 bytes.  It would be helpful to note here the respective sizes of CoSWID tag.  For the shepherd report, it might be useful to frame who exactly is doing inventory management and vul assessment to the degree that the device is actually providing information, but doesn't have the bandwidth/compute resources to serve 3Kb.

** Section 1.1.  This section doesn't explicitly state with normative language that this lifecycle applies

** Section 1.1. Figure 1.  What is the perspective of this lifecycle - should it be viewed from a particular host?  I ask because the Corpus tag appears to have no change of state -- get removed at all during the Lifecycle?  Perhaps at Software Installation?  Minimally at Software Removal?

** Section 1.1. Typo. s/xSuplemental/xSupplemental/

** Section 1.1.  Editorial.  After reading this section, I was wondering about what's the difference between patching and upgrading?  Does one bump the version number and the other does not?  Perhaps a forward reference to Section 2.3 would be appropriate here.

** Section 2.1.  Recommend using normative language:

OLD:
All names registered with IANA according to requirements in section
   Section 5.2 also need to be valid according to the XML Schema NMToken
   data type 

NEW
All names registered with IANA according to requirements in section
   Section 5.2 also MUST be valid according to the XML Schema NMToken
   data type 

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

** Section 2.3.  Per "If the software component's version number is modified, then the correct course of action would be to replace the previous primary tag for the component with a new primary tag that reflected this new version.", would normative language be more appropriate here: "If the software component's version number is modified, then the new a new primary reflecting this new version SHOULD (MUST?) replace the previous primary tag for this component"?  Additionally, if SHOULD is chosen, under what circumstances would this not be followed (i.e., why not a MUST)?

** Section 2.3. Global Typo. s/section Section/Section/g

** Section 2.3.  Per "This item represents a query as defined by the W3C Media Queries     Recommendation (see [W3C.REC-css3-mediaqueries-20120619])" can normative language be applied here to constrain the format.  Perhaps "This item MUST be formatted as query defined by the W3C Media Queries Recommendation (see [W3C.REC-css3-mediaqueries-20120619]) format.

** Section 2.3.  It isn't apparent to me from this text on how to use CSS to provide hints on a target platform (e.g., how do I use color-index or aspect ratio?).  Is there a reference in the SWID text that can help?

** Section 2.6. s/entity-name (index 32)/entity-name (index 31)/

** Section 2.6 Editorial.  s/an registration ID/a registration ID/

** Section 2.6.  Per "In a given scope, the registration id MUST be used consistently for CoSWID tag production.", can you clarify what you mean by consistently?

** Section 2.7.  href.  Per "If no URI scheme is provided ...", then how is this a valid URI?  Per Section 3 of RFC3986, the scheme is mandatory.  The example "./folder/supplemental.coswid" is not a valid URI.

** Section 2.7.  swidpath.  This syntax seems underspecified.  What does XPATH on CBOR mean?  What is the mapping?  Tthe example provide seem to be using the SWID names not the CoSWID names, is that a requirement?  Practically, I don't know of any Xpath library that ingests CBOR so all the semantics here are unique.  FYSA, draft-ietf-regext-rdap-sorting-and-paging was attempting to specify XPATH on JSON, https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ballot/, the discussion on how to resolve this with the right normative reference might be helpful here.

** Section 2.7. swidpath examples.  Please do not use "contoso.com" in the example.  Use example.com instead.

** Section 2.7. Typo. s/a Ownership/an Ownership/

** Section 2.7.  Typo. s/Link Use Value Value/Link Use Value/

** Section 2.8.  Typo. s/identfies/identifies/

** Section 2.8.  unspsc-code.  Please cite the URL of unspsc.org by reference.

** Section 2.9.1.  Should the Status field of the Named Information Hash Algorithm Registry be considered when choosing an appropriate hash algorithm?

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

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

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

** Section 4.1. Typo. s/gudelines/guidelines/

** Section 4.1. Editorial. s/decimal number ./decimal number./

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

** Section 5.2.1. Typo. s/Proceedures/Procedures/

** Section 5.2.1.  Per "The latter SHOULD be used only for the registrations requested by SDOs outside of the IETF", can you explain the thinking on additional caveat of "by SDOs outside of the IETF"?  How will the threshold for what is an acceptable SDO be judged?

** Section 5.2.4.  Global Typo. s/proceedures/procedures/g

** Section 5.2.4.  Global Typo. s/inital/initial/g

** Section 5.2.6. Global Typo. s/guidlines/guidelines/g

** Section 5.3.  Per Section 5.1 of RFC6838, was a message sent to media-types@iana.org for preliminary review?  I didn't see it on that mailing list (did I miss it?).  Please kick that off.

** Section 5.3.  Editorial. s/RFC-7049/[RFC7049]

** Section 5.6. Per Step 3.2 of Section 7.2 of RFC7595, has this been sent to uri-review@ietf.org?  I didn't see it on that mailing list (did I miss it?).  Please kick that off.

** Section 5.6.1 and 5.6.2.  Please use the template described in Section 7.4 of RFC 7595.  The fields below are part of the "old template".

** Section 5.6.1.  Typo. s/speific/specific/

** Section 5.6.1.  Global Typo. s/indentify/identify/g

** Section 5.6.2.  The uri scheme syntax seems under-specified.  Please provide a bit more formal syntax which includes all of the scheme elements (perhaps as simply as just not stating it as an example)

** Section 5.6.2.  Editorial.  There are words missing in paragraph ending with "... rence related tags on the same device using this URI scheme"

** Section 5.7.  Per the "Software Data Model Types" registry: 

-- "Defining Specification" is actually named "Reference" in the registry
-- In the derived SW identifiers syntax, are those bare underscores or are those quotes really supposed to be in there?

** Section 5.7.  Typo. s/ietm/item/

** Section 6.  Per "SWID/CoSWID tags are intended to be easily discoverable ...", can a reference be provided on how this discoverability is realized.

** Section 6.  Per "As such, any security considerations regarding SWID/CoSWID tag focys on the application of SWID/CoSWID tags to address security challenges ...", wouldn't there also be integrity and authenticity concerns about the SWID?
** Section 6.  What are the normative requirements, if any, on signing the CoSWID?

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

** Section 6.  Per "Having a signed authoritative SWID/CoSWID tag can be useful when the information in the tag needs to be trusted ...", when would this tag not need to be trusted?  What is the use case for unsigned tags?

** Section 6.  
OLD
For this reason, it is important to protect the
   confidentiality of SWID/CoSWID tag information that has been
   collected from an endpoint

NEW
For this reason, it is important to protect the
   confidentiality of SWID/CoSWID tag information that has been
   collected from an endpoint in transit and at rest

Section 6.  Per "For this reason, tools that consume SWID/CoSWID tags ought to treat ...", is normative language or less colloquial language more appropriate here - s/ought/should/?

** Appendix A.  The SWID spec is clear on how to provide integrity on the SWID tags.  Here, there is what seems like an example of how to use COSE.  The language is soft.  For example, "Concise SWID can be wrapped in ...".  For the purposes of interop, why isn't there a canonical way to sign CoSWID specified?  Is it envisioned that an approach other than what's described in Appendix A would be used?  If there are multiple ways, please discuss how the interop would work.  If there aren't, please use normative language to describe how to realize the desired security properties (which I think is integrity and authenticity).  Editorially, it would also help the reader if you would clearly state which CoSWID elements would be protected with the described approach (i.e., the whole tag)

Regards,
Roman