Software Inventory Message and Attributes (SWIMA) for PA-TNC
draft-ietf-sacm-nea-swima-patnc-05

Thanks for everyone's work on this document. I support Ben's DISCUSS, his
concerns regarding the treatment of privacy in §8, and EKR's concerns
regarding the phrasing "not generally considered to be sensitive."

I also have a few very important comments about this document's
handling of URIs.

§3.4.4:
>  The location is expressed as a URI string consisting of a scheme and
>  path.  [RFC3986] The location URI does not include an authority part.
>  The URI schema describes the context of the described location.  For
>  example, in most cases the location of the installed software product
>  will be expressed in terms of its path in the filesystem.  For such
>  locations, the location URI scheme MUST be "file" or the URI MUST
>  appear without a scheme.  (I.e., "file" is default scheme.)  It is
>  possible that other schemes could be used to represent other location
>  contexts.  Apart from reserving the "file" scheme, this specification
>  does not reserve schemes.  When representing software products in
>  other location contexts, tools MUST be consistent in their use of
>  schemes, but the exact string used in those schemes is not
>  normatively defined here.

Please cite RFC 8098 in this paragraph.

Saying that a URI can appear without a scheme is at least confusing and probably
ambiguous. For example, I can't tell which of the following syntaxes are
expected and/or allowed:

1. :///Applications/TurnipTwaddler
2. ///Applications/TurnipTwaddler
3. /Applications/TurnipTwaddler

Read literally, the quoted paragraph describes the first. It probably means to
describe the second (maybe?), but I suspect some implementors will interpret
it as the third.

This becomes even more problematic for Windows, where it might be interpreted
to mean any of *four* things (where the final one is clearly wrong due to
potential confusion between drive letters and URI schemes -- but which I'm
sure will be implemented if not clearly spelled out):

1. :///C:/Program%20Files/TurnipTwaddler
2. ///C:/Program%20Files/TurnipTwaddler
3. /C:/Program%20Files/TurnipTwaddler
4. C:/Program%20Files/TurnipTwaddler

To be clear, whatever you define in this document cannot allow the omission of a
scheme to result in Form #4 above, as this is syntactically ambiguous.

It also probably bears reiterating that omitting the "file" scheme from a URI
doesn't exempt it from encoding according to RFC 8089 section 4 (e.g.,
including an unescaped space, as in "Program Files", would be syntactically
invalid).

Finally, I question the assertion that "The location URI does not include an
authority part." It's been a while since I used Windows on a regular basis, but
my recollection is that files -- including applications -- can be accessed from
a CIFS filesystem without associating a local mount point with them. It would be
impossible to describe the location of such applications if the authority is
required to be omitted. It is easy to anticipate that future iterations of,
e.g., Linux may have similar properties. (Popular desktops already allow
userland access of files on unmounted access using full URIs, which necessarily
include authority components; it is not far-fetched to imagine that this
functionality might be incorporated into the kernel at some point).

---------------------------------------------------------------------------

The following appears in several places:

>  | Software       | A string containing the Software Locator value.  |
>  | Locator        | This is expressed as a URI. This field value     |
>  |                | MUST be normalized to Network Unicode format as  |
>  |                | described in Section 3.4.4. This string MUST NOT |
>  |                | be NULL terminated.                              |

Section 3.4.4 doesn't describe the use of Network Unicode format, so this text
is confusing. I'll note that file URIs are generally going to be percent
encoded, so they shouldn't contain any non-ASCII characters. Section 4 of RFC
8089 deals with encoding considerations for file URIs. Other URIs have their own
encoding considerations, and it would be somewhat ambitious for this document to
take on any encoding specification above and beyond what is already defined for
each scheme.

Thank you for addressing my DISCUSS and many of my comments. Remaining comments listed below (plus see updated point #7)

Minor:

(Points not mentioned below were addressed).

2) When referencing RFC 5198 (Network Unicode format), I personally prefer a stricter version that disallows control characters (other than CR LF). In RFC 5198, use of control characters is only "SHOULD NOT". So you might want to make a stronger statement on this.

5) In Section 4.3.  Required Exchanges

   All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges.

I question the value in requiring SWIMA-PVs in supporting both types of exchanges. For example,
if a SWIMA-PV never uses subscriptions, it doesn't seem to need to handle subscription responses.

Similar text in 5.2:

   All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and
   be capable of receiving and processing all SWIMA Response attributes
   as well as PA-TNC Error attributes.

6) Use of fields which can contain both human readable and possibly machine readable information -
I think this is rather handwavy and I wish you would be more specific.
Also consider issues raised in BCP 18 (RFC 2277), in particular language tagging of human readable text.

7) (downgraded from DISCUSS): SWID registry is using "http://invalid.unavailable" Tag Creator RegID value in Section 6.1.1.

invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry
<https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml>

I am not entirely sure how big of a problem this is, but use of something which can be interpreted as a URI in a non existing non special-use domain seems like a bad idea.
Note, if you can change the value to "http://unavailable.invalid", that would address my concern.

The Gen-ART review raises some questions to which I'd like to see responses. https://datatracker.ietf.org/doc/review-ietf-sacm-nea-swima-patnc-02-genart-telechat-romascanu-2018-02-18/

Thanks for addressing my DISCUSS points and comments!

More detail in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3336

IMPORTANT
I consider the following comment important, though I have chosen to make
it a comment rather than a discuss.

   Software records on an endpoint are generally not considered to be
   sensitive, although there can be exceptions to this generalization as
   noted in the section on Privacy Considerations.  In general, an
   
I'm not sure where "generally" comes from. I consider it
sensitive and we know that people have been jailed for running certain
software.  Even the rest of this section provides strong evidence that
this is sensitive. So I think you should remove this claim and rewrite
this paragraph to acknowledge that this is sensitive information


MINOR
   The primary use of exchanging software inventory information over the
   PA-TNC interface is to enable a challenger (e.g.  NEA Server) to
   obtain inventory evidence about some system in a way that conforms to
Nit: e.g.,



   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly and reliably providing the
   reported Software Inventory Evidence Collection to the NEA Server.
This seems like a pretty significant narrowing of the use cases. Can you explain what use cases this is useful for if the machine can lie?



   A Record Identifier is a 4-byte integer generated by the SWIMA-PC
   that is uniquely associated with a specific record within the
In what byte order? Signed or unsigned? If it's actually an integer this is important.



   that SWIMA-PV), the SWIMA-PC MUST assign that source a Source
   Identification Number, which is an 8-bit unsigned integer.  Each item
   reported includes the Source Identification Number that provided that
What happens if you have 256 sources? Must these be sequential?



   record that is no longer available, the SWIMA-PC SHOULD return a
   0-length record.
Is this different from what happens if you are requested to send something that never existed? If so, is this a recipe for unlimited growth.



   An EID is a 4-byte unsigned integer that the SWIMA-PC assigns
   sequentially to each observed event (whether detected in real-time or
What byte order?



   very first recorded event in a SWIMA-PC's records within an EID Epoch
   MUST be assigned a value of 1 or greater.  Note that EID and EID
   Epoch values are assigned by the SWIMA-PC without regard to whether
Why "or greater" this is the only place you allow a gap.



   event records MUST only contain events with EIDs that all come from
   the current Epoch.
How does the SWIMA-PC garbage collect? It seems like the answer is it can just change epochs?



   records.  This ensures that every partial list of event records is
   always complete within its indicated range.
Is the point here that the list must be consecutive?



   |              | (8)        | PA-TNC specification [RFC5792].       |
   +--------------+------------+---------------------------------------+
It's up to you, but isn't this table largely duplicative of S 5.2?



   |   Software Identifier Length  | Software Identifier (var len) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OK, I think I see what's going on here: you can have an arbitrary number of instances of this block. Maybe you should show more than one in the diagram with an indication that it's controlled by SWID Count? Or a .... or something? This comment applies to the other PDUs in this document as well.



   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
I would not put lines between these timestamp fields because they are actually one giant field

The shepherd write-up says: "This document is being requested for publication as an Internet Standard RFC." I issued my ballot position under the assumption that document is published as Proposed Standard as indicated in the datatracker.