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

[Roman Danyliw <[e-mail]>]

Hi Jess!

Thanks for the -16 updated.  It addresses quite a lot of my feedback.  To simplify the next step, here are the unresolved items I see (many are noted with TODO in the text).  I also added updated comments noted by [Update]:

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

[Updated: I see you have a marker for it via "TODO: Add CoSWID size comparison." IMO, this is a nice to have, but not necessary]

** 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. Global Typo. s/section Section/Section/g
[Updated: still here, and now as "Section Section", likely an artifact of the draft building tool chain]

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

[Updated: Thanks for this clarifying text.  The updates introduced a typo. s/is a a/is a/

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

[Updated: Thanks for this clarifying text, can you please make a reference to the IANA registry rather than an inline URL, i.e., https://www.iana.org/assignments/named-information/named-information.xhtml)

** 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?
[Update: I see you're tracking this and have a marker for it with [QUESTION: Is "time" a correct representation of XSD:date?]”

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

[Updated: Can the ISO spec be used as the basis for this reference (even it just points to the same website?)]

** Section 5.3.  Per Section 5.1 of RFC6838, was a message sent to mailto:[e-mail] for preliminary review?  I didn't see it on that mailing list (did I miss it?).  Please kick that off.

** Section 5.6. Per Step 3.2 of Section 7.2 of RFC7595, has this been sent to mailto:[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.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.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 6.  Per "As such, any security considerations regarding SWID/CoSWID tag focus on the application of SWID/CoSWID tags to address security challenges ...", wouldn't there also be integrity and authenticity in support “of these security challenges” be of concern for 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?

[Updated comments: 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]

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

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






From: sacm <[e-mail]> On Behalf Of Jessica Fitzgerald-McKay
Sent: Wednesday, October 14, 2020 9:29 AM
To: Roman Danyliw <[e-mail]>; <[e-mail]> <[e-mail]>
Cc: Jessica Fitzgerald-McKay <[e-mail]>; Henk Birkholz <[e-mail]>; Schmidt, Charles M. <[e-mail]>; Waltermire, David A. <[e-mail]>
Subject: Re: [sacm] AD Review of draft-ietf-sacm-coswid-15

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 <mailto:[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 "http://contoso.com" in the example.  Use http://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 http://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 mailto:[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 mailto:[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
mailto:[e-mail]
https://www.ietf.org/mailman/listinfo/sacm