Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc as a SACM WG document

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

Ok - Gunnar has set me straight.

Put in terms for the easily confused (such as myself): Gunnar was advocating
that the network messages used to convey tag data via SWID M&A employ a
standard data model so that recipients always see the same structure in the
messages and can rely on being able to parse it. With that in mind, many tag
types could be converted to this common data model used in the messages,
thus many tag types should be collected by the Posture Collector as
potential input. Gunnar - did I get it right?

In fact, this is largely what the SWID M&A specification does now. The ISO
SWID 2015 and ISO SWID 2009 specifications form a data model for SWID M&A
messages conveying tag information. However, the specification notes that
the SWID tag collection that is conveyed in these messages could come from
many "sources", some of which might be translated from different record
types. (E.g., potentially converted from package manager records or third
party inventory tool results.)

That said, based on some of the conversations that have occurred in meetings
and on list, I think there are some open questions here:
1) Currently SWID M&A uses the ISO SWID specifications as a data model.
Various parties have weighed in on the pros and cons of ISO SWID tags.
Looking from a strictly data-model perspective, what structure makes sense
for conveying tag/inventory data as the standard data model in these
messages. Personally, I would argue that the core should probably be an
existing structure - I don't see any call to invent yet another way to
describe software. 

2) As I wrote it, one of the change proposals presented to the group was
effectively to allow SWID M&A to convey any type of tag natively and simply
include a field to identify the type of tag contained in the message. This
would allow SWID M&A to convey inventory information via an unlimited number
of data models. What do people think about this given the recent
discussions? Gunnar, I take it you would be against this change and would
prefer a fixed tag format (a.k.a. data model) in the SWID M&A messages
themselves. Other thoughts?

3) With regard to conversion, I will note that some tag types (e.g., ISO
SWID tags) can be cryptographically signed. Obviously, any conversion is
going to lose those signatures. Do people think that being able to discern
correctly signed tags from other tags would be of operational significance?
If so, maybe the solution would be three types of messages: a) capture
inventory information using a single, standard data model to which all
source tags are converted [by-normalized-value], b) capture inventory
information using identifiers that can be used to reference tag structures
[by-reference], c) capture inventory information using whatever native tag
structure there is, noting that some tag types might not be consumable, but
ensuring that signatures and the like are correctly conveyed
[by-non-normalized-value]. The requesting party can indicate which of these
return methods it would like.

Any thoughts about any of these?

Thanks,
Charles

> -----Original Message-----
> From: sacm [mailto:[e-mail]] On Behalf Of Schmidt, Charles
> M.
> Sent: Monday, June 06, 2016 2:35 PM
> To: Gunnar Engelbach <[e-mail]>;
> [e-mail]; Michael Godsey <[e-mail]>; Jerome
> Athias <[e-mail]>
> Cc: [e-mail]; Karen O'Donoghue <[e-mail]>
> Subject: Re: [sacm] Call for adoption of draft-coffin-sacm-nea-swid-patnc
as
> a SACM WG document
> 
> > If there's going to be a consistent data model I don't see I reason why
> > there should be any constraint on what endpoint tag types are supported.
> 
> I'm afraid you have lost me here. My understanding was that you were
> arguing
> that SWID M&A should support tag types other than the ISO SWID tags. As I
> understand the term, ISO SWID 2015 defines a data model, and then
> different
> tag formats (XML, CBOR, JSON) would all be data formats of that common
> data
> model.  But if we have completely different tag types, (for example, SWID
> 2015 tags and RPM records), I'm confused how there could be a common
> data
> model that both represent. In other words, when you argued for a common
> data
> model, to me this implicitly meant we needed to curtail the types of tags
> supported to only those that could serialize that common data model.
> 
> Sorry if I am being slow here, but could you clarify how you see the tag
> types relating to this common data model?
> 
> Thanks,
> Charles
> 
> > -----Original Message-----
> > From: Gunnar Engelbach [mailto:[e-mail]]
> > Sent: Monday, June 06, 2016 1:45 PM
> > To: Schmidt, Charles M. <[e-mail]>; [e-mail];
> > Michael Godsey <[e-mail]>; Jerome Athias
> > <[e-mail]>
> > Cc: [e-mail]; Karen O'Donoghue <[e-mail]>
> > Subject: Re: [sacm] Call for adoption of
draft-coffin-sacm-nea-swid-patnc
> as
> > a SACM WG document
> >
> >
> >
> > On 6/6/2016 11:36 AM, Schmidt, Charles M. wrote:
> > > Hello everyone,
> > >
> > > I wanted to do a quick loop back to the original question of this
> thread,
> > > namely the adoption of
> > > https://datatracker.ietf.org/doc/draft-coffin-sacm-nea-swid-patnc/ as
a
> > SACM
> > > working group document. This and other threads have indicated that
> there
> > is
> > > some desire to evolve the document to address certain concerns, many
> of
> > > which I hope to address in the next draft.
> > >
> > > With the understanding that adoption as a working group draft does not
> in
> > > any way end the discussion or evolution of this draft, are there any
> other
> > > thoughts regarding adoption?
> > >
> > > Gunnar/Tony - you both raised concerns about adoption due to the
> > document
> > > being exclusively focused on ISO SWID tags, but since then there
appears
> > to
> > > be agreement to expand to other possible tag types (with the caveat
that
> > > there also appears to be consensus that this list of tags should be
> > > constrained so that endpoints are sending content using a consistent
> data
> > > model). Does this alteration address you concerns? If so, does that
> change
> > > your feelings on adoption?
> >
> > If there's going to be a consistent data model I don't see I reason why
> > there should be any constraint on what endpoint tag types are supported.
> >
> > I'd prefer to see that translation happen as soon in the lifecycle of
> > the data as possible, but we'll see what consensus is on that. For
> > reasons already stated, if that translation is done centrally then I
> > don't SACM adoption extending much beyond a few large vendors that put
> > out, effectively, their own stovepipes.
> >
> >
> > --gun
> >
> >
> > >
> > > Thanks,
> > > Charles
> > >
> > >> -----Original Message-----
> > >> From: Gunnar Engelbach [mailto:[e-mail]]
> > >> Sent: Friday, May 20, 2016 1:51 PM
> > >> To: Schmidt, Charles M. <[e-mail]>;
> [e-mail];
> > >> Michael Godsey <[e-mail]>; Jerome Athias
> > >> <[e-mail]>
> > >> Cc: [e-mail]; Karen O'Donoghue <[e-mail]>
> > >> Subject: Re: [sacm] Call for adoption of
> draft-coffin-sacm-nea-swid-patnc
> > > as
> > >> a SACM WG document
> > >>
> > >>
> > >> Inline...
> > >>
> > >> On 5/19/2016 1:27 PM, Schmidt, Charles M. wrote:
> > >>> Tony/Gunnar,
> > >>>
> > >>> I agree. Details below.
> > >>>
> > >>>> 	Two questions not asked: who might do the
> > >>>> 	work to bridge the gap with the gazillion other
> > >>>> 	software identifier approaches out there, and
> > >>>> 	whether some form of out-of-band SWID capability
> > >>>> 	(as is used with may of the other SWID mechanisms)
> > >>>> 	cannot be included.  For a lot of IoT stuff, it is
> > >>>> 	essential.
> > >>>>
> > >>>> This right here is an excellent point.  There are other software ID
> > >>> mechanisms
> > >>>> out there and SWID is not going to cover everything for which there
> is
> > > an
> > >>>> alternative.
> > >>>>
> > >>>> Because this proposal is so SWID-specific, I can't get behind it.
> > >>> However, if it
> > >>>> was genericized to allow for use of current and possible future
> tagging
> > >>>> mechanisms, I could certainly support that.
> > >>> This makes sense. Even those strongly attached to the use of SWID
> tags
> > >> would
> > >>> like to make sure that this specification can handle future
revisions
> of
> > > the
> > >>> ISO SWID specification, and as you both note, there are other
> structures
> > >> out
> > >>> there which people might wish to use.
> > >>>
> > >>> Basically, it seems to me that we want to support a common, core set
> of
> > >>> functionality related to inventory and inventory events, but that we
> > > want
> > >> to
> > >>> have some flexibility in the data (I'll call these "records") used
to
> > > convey
> > >>> that information to a policy server. Are we in agreement on this? (I
> > > don't
> > >>> think we want the nature of what one can infer from a report to
> change
> > >> based
> > >>> on the record structure used to convey that report.)
> > >>>
> > >>> Given this, the following are the core capabilities of SWID M&A for
> > >>> reporting records as I see them:
> > >>> 1) Records need to be associated with specific instances of a
specific
> > >>> software product and version thereof.
> > >>> --- If the same version of the same product is installed multiple
> times,
> > >>> there will need to be multiple records naming the same product and
> > >> version -
> > >>> one associated with each actual installation. (We need to convey
that
> a
> > >>> given product+version is installed "exactly X times" rather than "at
> > > least
> > >>> one instance".)
> > >>> --- Changes to a software product need to result in a change in the
> > >>> associated record. (The record needs to distinguish between AcmeApp
> > >> v1.2.3
> > >>> and AcmeApp v1.2.4, since this is critical to multiple consumers of
> this
> > >>> data.)
> > >>> --- Records associated with a product+version need to be consistent
> > over
> > >>> time and across endpoints. (There needs to be an easy way for the
> > SWID-
> > >> PV to
> > >>> say "this is the same product+version" across different reports and
> > >> between
> > >>> reports from different machines.)
> > >>> 2) If the record is more than about 200 bytes, there needs to be a
> > > concise
> > >>> identifier for this record. In SWID tags, this is created by the
> > > combination
> > >>> of the TagCreatorRegID and the TagID fields. (Concise identifiers
are
> > > used
> > >>> in multiple places in SWID M&A to convey information without
bloating
> > >>> messages.)
> > >> I tried to find fault, but I think as a basic core set, this is good
> > >> coverage.
> > >>
> > >> In ongoing practice there are undoubtedly going to be more
capabilities
> > >> desired for other use cases, and some tagging solutions will have
> useful
> > >> capabilities that are not available in others. Extensibility is
> assumed.
> > >>
> > >> I think it's also a necessity that a common data model be used
> > >> regardless of the tag type/source.  For hopefully obvious reasons.
> > >>
> > >>
> > >>
> > >>> Do you (or anyone) have any questions or concerns about any of these
> > >> core
> > >>> capabilities, or have any others to add? I think all of the other
SWID
> > > M&A
> > >>> capabilities (monitoring for changes, tracking and ordering of
events,
> > >>> subscriptions, processing targeted requests, etc.) are fairly
neutral
> > > with
> > >>> regard to the record structure used in messages assuming the two
> > >>> requirements above are met. Let me know if you disagree about that.
> > >>>
> > >>> Capabilities do not need to be inherent in the record itself. (For
> > > example,
> > >>> there is nothing in a SWID tag that allows one to distinguish
between
> > >>> multiple installations of a single product.) There just needs to be
a
> > >>> reliable, deterministic mechanism by which these capabilities can be
> met
> > >>> while using the record.
> > >>>
> > >>> I will work on putting together some proposals on how different
> record
> > >> types
> > >>> can be clearly labeled in SWID M&A messages so recipients can know
> the
> > >> type
> > >>> of content they are getting prior to parsing. (Probably want a way
for
> > >>> SWID-PVs to express a preference too... need to think about this.)
> While
> > > I
> > >>> am doing that, if you have a favorite non-ISO-SWID record that you
> > would
> > >>> like to see supported, could you put together any necessary
> > requirements
> > >>> that would be needed to ensure it aligns with the core capabilities
> > >>> described above? I think that would be very useful for fleshing out
> this
> > >>> flexibility.
> > >>>
> > >>> I am interested in your thoughts on this. Thanks for the input.
> > >>>
> > >>> Charles