Subject: [sacm] coswid-04 review

From: Chris Inacio <[email-masked]>
Date: Mon, 19 Mar 2018 15:03:00 +0000

I assume this is blocked by the CDDL draft - waiting for WG chair.  Also, I can’t find in the CDDL draft the positional notation used
key = (nn: type)
Is this still valid CDDL?

Do we need section 1.1?  What is it adding to the purpose of the document?
If we keep it, then shouldn’t the diagram on top of page 4 (diagrams numbered please) be fixed to include a circular part with patches until removal?
Formatting for 1.1 P4; I think those are supposed to be some type of bulleted list.

2 P3:
"A typical endpoint is capable of storing

   the CoSWID tag of installed software, a constrained-node might lack
   that capability.  CoSWID address these constraints and the
   corresponding specification is augmented to retain their usefulness
   in the thing-2-thing domain.”

First use of CoSWID should be SWID, right?

2 P3: editorial NIT, ending a sentence with “in”.  Rephrase for improved readability.

2.1 P1: "The items are ordered ensure that tag” should be "ensuring”.

2.1: should “global-attributes” be included in the ordering list somewhere?

2.1: “software-version” - is there any guidance on something like if a software item has 2 version numbers, ala “16.0.3” and then also something like “(a8e742)” or something like that.  Should this tag include both, the marketing number (16.0.3) or the build number version?

2.1: "item to represent a attributes” change “a” to “an”

2.1: "A reference to any another item (can include

      details that are related to the CoSWID tag” change “another” to “other”

2.1: link-entry:  at the end of the description there is a use of “their”; I wasn’t 100% what “their” referred to, can “their” be replaced with a proper noun?

2.1: any-element-entry: "which would be also any-elements)” change to “also be”

2.1.1: I find this confusing.  Who/What are are considering something a primary tag?  Or is that just a definition for human convenience?  What does it mean if you have an unsupported tag?  There doesn’t seem to be a consequence.  Lastly - stored/removed from where?

2.1.2: "Only one of the corpus, patch, and supplemental items MUST be set to "true”,”  - Is that really one and only one shall be true at a time?

2.1.2: “suplements” is misspelled and quoted - is it quoted because its purposefully misspelled?

2.1.2: "This ensure that primary and corpus tags have” change to “This ensures that the primary and corpus...”.

2.2:  I’m confused by this definition:

any-attribute = (
     label => text / int / [ 2* text ] / [ 2* int ]
   )

Doesn’t that just say any string with with 1 or more characters or integers?  “/“ is or in CDDL; maybe some parenthesis were intended? Maybe something like (text/int)([2* text]/[2* int]) ??

2.4: extended-data = (30: any-element-map / [ 2* any-element-map ])
I’m not sure about this CDDL; doesn’t this just mean “+ any-element-map”?  And this is open ended, why is it required?

2.4: "any role value, but the per-defined roles include:”  change to “pre-defined”.

2,4”. “ "software-creator", "tag-creator” “ add the missing “and” before tag-creator.

2.4: ”…  of the signing entities certificate(s). .” extra period.

2.4 thumbprint - can we describe what goes into the hash, how, and which hash algorithm (even if that’s a code point) should be used?

2.5: artifact - the text implies that everything called “install.exe” is the same file if it’s on CD?  Or did I read that incorrectly? (In which case it still needs a fix.)

2.5: href - why are we generating/accepting a no-uri scheme?  How do we know that the scheme means?
2.5: href - should that be labeled “href”?

2.5: href - examples between coswid and XPATH tag are mislabeled (maybe an extra bullet point in the text)

2.5 media - I’m not sure that this is sufficiently specified.  Is there a media definition for DVD?  The reference talks about selecting a font for print vs. a font for screen.  Does this cover media statements for things like other source media?

2.6: Is "http://msdn.microsoft<http://msdn.microsoft.com/en-us/library/aa372375(v=vs.85).aspx>.com/en-us/library/aa372375(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/aa372375(v=vs.85).aspx>” a stable reference for a standard?

2.6: unspc - why is this defined as “text” when its limited to 8-characters?

2.6: "directory / [2 * directory]” - this pattern repeats in the document and I don’t understand why from the CDDL draft.  Help.

2.7.2: There is no place to specify an operating system.  If the file systems are very different, how to I make sense of things like file paths?  Word on Windows vs. Word on Mac. - how do you understand those resources in that case?

2.7.3:  Payload extension - ???? - (specified as group socket to be specified later in the CDDL)

2.7.4 - Evidence extension - ???? - (specified as group socket to be specified later in the CDDL)

3.1 - SEMVER - is that a stable reference?

5. "If the SWID tag was created by the software author, this generally means that it has undergone no change” - generally means, or implies?

5. "contain malicious content with the intend if creating non-deterministic” change intend to “intent”.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 21 Mar 2018 10:58:54 +0000

Chris,

Thank you for the detailed feedback!

Comments inline below marked [daw:].

I have addressed all of your feedback in the version posted to https://github.com/david-waltermire-nist/draft-ietf-sacm-coswid. I will post this as -05 later today once I complete an editorial pass through the document.

Please let me know if you have any questions or comments on the changes I have made to the draft.

Thanks,
Dave

________________________________
From: Chris Inacio <[email-masked]>
Sent: Monday, March 19, 2018 11:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: coswid-04 review

I assume this is blocked by the CDDL draft - waiting for WG chair.

[daw: Yes. The draft is in WGLC waiting for chair go-ahead.]

Also, I can’t find in the CDDL draft the positional notation used
key = (nn: type)
Is this still valid CDDL?

[daw: I believe the syntax is compliant with the group syntax described in section 2.1.2 in the CDDL draft. The group syntax can be in the form of:

 _keytype_ : _valuetype_

This appears to still be allowed syntax.]

[daw: Section 1.1 provides operational context for the use of a SWID/CoSWID. It answers the "why does this specification matter? question, which I believe is important for implementers to understand. It defines tag types which are useful in describing co-constraints later in the document and the operational model for how tag types support software inventory. The section is just under 3 pages in length, which I believe is worth including to provide the additional context around the draft.

What are your specific concerns with this section?]

If we keep it, then shouldn’t the diagram on top of page 4 (diagrams numbered please) be fixed to include a circular part with patches until removal?
[daw: I will add this to -05 along with figure numbers.]

[daw: This was a formatting issue, which is fixed in -05.]

2 P3:

[daw: Yep. Fixed.]

[daw: Fixed.]

[daw: I removed the ordering text since this information is actually unordered in a CBOR map. We may want to consider using an array if ordering is important.]

[daw: See above.]

[daw: Some versioing schemes (e.g., SEMVER} allow build version information to be provided. Providing multiple versions is not something allowed in SWID tags. We have attempted to keep parity with the common information model shared by both formats.

We could allow an array of versions, but this would increase the complexity of the format. It may also increase ambiguity when determing which version to display. To date I have not had someone raise this issue with either format. We may want to be cautious here about adding this feature to ensure we understand all the downstream impacts.]

[daw: I adjusted the wording here.]

[daw: I rephrased this text to improve its content and readability.]

[daw: see above.]

[daw: fixed.]

[daw: I added some text pointing to section 1.1 to clarify the tag type topic. Does the new text help make this more understandable?]

[daw: Nope. This text was wrong. It should be correct now.]

[daw: Fixed.]

[daw: Fixed.]

any-attribute = (

[daw: I don't believe that we need grouping here. The point of this definition is to allow for the most concise representation in CBOR for either a character string, an integer value, or an array of these types if two or more values need to be provided. By using a choice, fewer bytes can be used to represent single items as compared to how arrays are represented in CBOR.

Section 2.2.1 of CBOR (https://tools.ietf.org/html/rfc7049#section-2.2.1) describes how an array is encoded in the CBOR format. Encoding an array requires more data than just an individual string or integer value. We can save the extra array-related data for single value arrays by not using an array representation. This allows the format to be more concise in such cases.

Would it make sense to add a section in the front matter, or at the beginning of the model definition explaining why this syntax is used?]

[daw: We could use + any-element-map, but use of an array requires additional data in the encoding (see above). This construct allows both a single value and an array of two or more values to be both be allowed, making the data more concise in the single value case.]

[daw: done.]

[daw: fixed.]

[daw: fixed.]

[daw: I added some text and updated the CDDL to address this. Is the new text sufficient?]

[daw: The intent is that if the rel="installation-media", then the artifact can point to the path to the file used to run the installation. I added some text to this effect. Does the new text address your concern?]

[daw: The intent is to allow relative paths from the tag's location, where no scheme is provided. The resolved relative path would be resolved relative to the URI used to access the CoSWID tag.]

[daw: Not sure which one you are referencing here. I think it is the first reference in the body of the text. I surrounded this with quotes.]

[daw: fixed.]

[daw: This is underspecified in the SWID specification as well. Not sure what to do here. I'll raise this issue with the WG.]

2.6: Is "http://msdn.microsoft<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa372375(v%3Dvs.85).aspx&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C7e73d58ac101429e10a208d58daa8c99%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636570686004763698&sdata=mt9Pbb0XxYXSJ3JQnmRAtvi8jnMG%2FPIXYBwbdWRzfkg%3D&reserved=0>.com/en-us/library/aa372375(v=vs.85).aspx<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa372375(v%3Dvs.85).aspx&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C7e73d58ac101429e10a208d58daa8c99%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636570686004763698&sdata=mt9Pbb0XxYXSJ3JQnmRAtvi8jnMG%2FPIXYBwbdWRzfkg%3D&reserved=0>” a stable reference for a standard?

[daw: I removed this example.]

[daw: I am not sure we want to constrain this for future agility reasons. I also do not know how to constrain the length to be 8 characters. The CDDL .size control operator is in bytes, which is not the same as characters in Unicode. We could use the .regexp control operator to address your concern if you think we should still constrain it to 8 characters.]

[daw: See previous comments on this.]

[daw: In a NIST document I wrote, we created extensions in the SWID XML format to address this. We specified the "pathSeparator", "envVarPrefix", and "envVarSuffix" items to declare the conventions being used. Through this, the conventions of a given platform could be substituted. Would it be useful to add these extensions to this draft?]

[daw: Added text on the use of CDDL sockets for extension.]

[daw: see above.]

[daw: It is a web page that seems to be a stable reference for the SEMVER specification.]

[daw: I made some significant edits to this paragraph. Is the new text more clear?]

[daw: Fixed.]