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

[Jessica Fitzgerald-McKay <[e-mail]>]

Roman,
Thank you for the review. The authors met this morning to start working
through your comments. We're going to need to meet a few more times before
we can reply substantively, but we have high hopes we'll be able to address
your comments in a new draft before the IETF 109 submission deadline!

Thanks,
Jess

On Thu, Oct 1, 2020 at 11:55 AM Roman Danyliw <[e-mail]> wrote:

> 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
> [e-mail] 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 [e-mail]?  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
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>