Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

["Schmidt, Charles M." <[e-mail]>]

Hi Adam,

Sounds like we are mostly aligned. I've trimmed the points where it looks like we are on the same page and responded inline to the others.

> 	> On Page 15 the draft states "All SW-PCs MUST at least be able to
> generate
> 	> Software Identifiers for the data model types specified in Section 6
> of this
> 	> document." Section 6 describes data models for SWID 2009 and
> SWID 2015,
> 	> but nothing else. Is this really what we desire? What about Linux
> distribution
> 	> package managers?
> 
> 	Adding on to Stephen's comments, I'll note that we intend SWIMA to
> be extensible. If someone wished to report RPM records or other types of
> packages, they are welcome to do so. The just need to define an
> authoritative way of deriving a Software Identifier from the record.
> However, I don't think we want to *require* support for such packages in all
> SW-PCs.
> 
> [AWM] I was looking at this a bit differently, I think. If there is a collector
> capable of expressing RPM packages, as an example, and they want to
> extend this to shuttle that information over PT-TLS, then would they need to
> also collect 2009 and 2015 SWIDs? It seems contrary to the point of having
> posture brokers. Maybe I'm missing something.

<CMS>
I think that this stems from confusion about what "MTI" means for records in SWIMA. SWIMA never requires that any given type of record be collected from an endpoint. An endpoint might have hundreds of SWID tags on it, but a compliant SWIMA specification might never touch them and instead choose to gather some other indicator of software installation. (For example, a SWIMA implementation might feel that RPM records are likely to be more complete and accurate than any SWID tags that might get installed across the endpoint.) The SWIMA specification is explicit that it only requires collection to be done in an internally consistent manner (i.e., it cannot use one source in one report and ignore that source in a subsequent report) but it never requires the use of any specific source of information. In short, a SWIMA implementation can make use of whatever information is available in whatever way it chooses, provided that it uses those sources consistently.

All the MTI requirement means is that every compliant SWIMA-PC MUST know how to take any 2009 or 2015 SWID tag it does collect (*if* it collects any at all) and deterministically derive a standard Software Identifier from that record. The issue this tries to address is that we would need a one-to-one mapping between information records describing software and the Software Identifier that is the shorthand for the described software. Unfortunately, there are lots of ways to do such a mapping, so there could be variation across implementations as to how a given piece of software is represented by a Software Identifier. By making 2009 and 2015 SWID tags MTI, all we are doing is ensuring that every SWIMA implementation will have the same one-to-one mapping between a given tag and its Software Identifier. This means that, at least for SWID tags, two collectors (from different vendors) will use the same Software Identifier for the same SWID tag, and thus those Identifiers can be directly compared.

This might get at your "redundancy" comment too - if MTI meant "required collection", then yes, requiring both types of tags be collected could be redundant. However, that is not the requirement. All the MTI statement requires is that SWIMA implementations are universally consistent in their mapping of 2009 and 2015 SWID tags to Software Identifiers. I don't think that is redundant - it is just better covering the bases.

> 	> What about discovered software outside typical
> 	> installation patterns?
> 
> 	As Andreas notes, such software can still be represented using SWID
> tags. They could also be represented using other record formats, as I note
> above.
> 
> [AWM] Do we need to mention how? If so, is this the right place to do that?

<CMS>
If you are talking about "how to convert to a SWID tag", I think that is beyond the scope of SWIMA. (Maybe if SACM decides someday to endorse SWID tags as the official record format for software information, that might be reasonable, but for now I think it would be premature.)

If you are talking about how to represent records other than SWID tags within SWIMA messages, I'm not sure that is necessary because the specification itself is completely generic. We just talk about records and Software Identifiers.  

> 	> And, does it make sense, in a brokered architecture like
> 	> NEA, to require redundant capabilities in the anticipated myriad
> collectors?
> 
> 	Not sure how this is "redundant". The group agreed that 2009 SWID
> tags should be supported for legacy reasons, while 2015 tags should be
> supported for future compliance. In general, SWIMA has virtually no control
> over the nature of the records on the endpoint - they might be SWID 2009,
> SWID 2015, something completely different, or a combination thereof.
> SWIMA is concerned with collection and conveyance of available information.
> Normalization of that information into one preferred record format is
> beyond the scope of SWIMA. (Deliberately so, since our early conversations
> on SWIMA involved a lot of holy wars about preferred record formats, none
> of which appear to "dominate" are target environment today.) Maybe SACM
> will eventually get behind a single format, and when they do SWIMA will be
> ready and able to convey it. Until then, SWIMA's goal is to support collection
> and conveyance of whatever software records might be available.
> 
> [AWM] Maybe I should ask this way. Is the expectation that RPM package
> management collectors, for example, would require a separate specification
> for shuttling over PT-TLS, or that they would extend this draft? If a separate
> specification, then I retract my comments, because then SWID data models
> aren't necessary. If an extension of this draft, then my comment remains.

<CMS>
See my earlier comment about redundancy - if this is related to concerns about require collection of records, SWIMA never imposes such a requirement. 

To answer your question, no - ideally we would hope that those collectors would not use a separate PA-TNC binding. In fact, no extension of this draft is necessary for RPM package manifests to be used directly in SWIMA. Any representation of installed software can be directly conveyed by SWIMA. Of course, if that representation hasn't been standardized in the IANA table, then two different vendors might identify that data model differently and use a different algorithm to derive Software Identifiers from those records, making direct comparison between their findings more challenging, but at least within that vendor's product space there would be no problem. (The advantage of the IANA table entries, is that the data model type identifier of the record will be the same across all implementations and the algorithm to derive the Software Identifier will be the same, allowing any such records to be directly compared across vendor boundaries.) 

So, in the current draft, any vendor could declare that an RPM manifest entry was a utilized Data Model Type, create a way to create a Software Identifier from each manifest entry, and start sending those to a consumer via SWIMA with no extensions necessary. Of course, vendor 2 might do the same thing, but would use a different type identifier and Software Identifier algorithm. In either case, however, the information is collected and delivered.

Does this address your questions?

Thanks,
Charles