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

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

+1 

I think it would be great if SWIMA named an IETF record format (CoSWID) in addition to the current ISO record format (SWID).

For those who didn't dig all the way into my response to Adam, all the IANA entry does is ensure that all SWIMA implementations 1) use the same data model identifier for that format and 2) have the same algorithm to derive a Software Identifier from record instances.

I think it is reasonable and appropriate to ensure these are both the case for IETF's home-grown software information description structure.

Charles

> -----Original Message-----
> From: sacm [mailto:[e-mail]] On Behalf Of Henk Birkholz
> Sent: Thursday, August 03, 2017 11:15 AM
> To: [e-mail]
> Subject: Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc
> 
> Hello Charles,
> hello group,
> 
> from the list of topics discussed, l an cherry-picking just one implicit
> topic: the Registry for Software Data Models and CoSWID. I bring this up
> based on this hand-selected quote:
> 
> > 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.
> 
> We already had an MTI discussion and I certainly do not want to rekindle
> that one. SWIMA has a "flexible data representation mechanism" and
> CoSWIDs are also defined in the SACM WG - so my question is: what would
> the group like to do here?
> 
> - Reference CoSWID directly in the SWIMA document in 10.4. Registry for
> Software Data Models, which would increase visibility, I think, or
> 
> - Include a corresponding IANA request for the Registry for Software
> Data Models in the CoSWID document?
> 
> 
> My personal preference is to include them in SWIMA now, as CoSWID are
> always inter-operable with the existing two entries and including the
> registration in SWIMA will expedite the next actions for CoSWID.
> 
> I think Charles brought that exact question up once already, but there
> was neither push-back nor support (aka indifference). In respect to
> Charles question a few months ago: Including CoSWID in the registration
> list would have my support.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> 
> On 08/03/2017 05:42 PM, Schmidt, Charles M. wrote:
> > Hi Adam,
> >
> > A few inline comments added to those made by Andreas. (And thanks to
> Andreas for his inputs.)
> >
> >> Should we be referencing the NIST interagency report related to SWID or
> the
> >> ISO standard directly? The NIST document is more readily accessible, and
> if
> >> they have parity, then we might gain points for referencing the freely
> >> available resource.
> >
> > The NIST and ISO documents are not equivalent. The NIST document
> describes best practices for using and creating SWID tags, and someone could
> use that and the freely available SWID tag XML schema to create compliant
> tags. However, the ISO document remains the authoritative source for SWID
> tag compliance. As such, I feel most references should be made to the
> (authoritative) ISO specification.
> >
> > That said, it probably makes sense to add an informational reference to the
> NIST specification for the reasons you mention.
> >
> >> Is there a reason to mention TCG + NEA in the introduction? If we're
> looking
> >> at NEA, then let's just use NEA references and not the TCG ones for, at
> least,
> >> the sake of consistency.
> >
> > I think there are a few reasons to at least mention the relationship to TCG's
> TNC.
> > 1) It emphasizes that there is alignment (rather than bifurcation) in these
> standards.
> > 2) It sends a reasonable call out to the TCG board, who agreed to support
> transfer of this specification to the IETF.
> >
> > That said, I can agree that Table 1 (which identifies equivalent components
> in the two architectures) might be more than is necessary. If we drop Table 1
> but retain the final paragraph of section 1.1 ("This document is based on
> standards published by the Trusted Computing Group's Trusted Network
> Communications (TNC) workgroup. The TNC and NEA architectures are
> interoperable and many components are equivalent.") would this address
> your concern?
> >
> >> Propose modified definition for SW-PC: A Posture Collector (PC) that
> collects
> >> endpoint software inventory information and that conforms to this
> >> specification.
> >>
> >> Propose modified definition for SW-PV: A Posture Validator (PV) that
> >> interprets SW Attributes sent by SW-PCs and that conforms to this
> >> specification.
> >
> > I like the rewording.
> >
> >> Propose modified definition for SW Attribute: A PA-TNC attribute that
> >> conveys software inventory information. (NOTE: We should ensure that
> PA-
> >> TNC is the NEA-specific term.)
> >
> > In retrospect, I'm not sure I like this or what currently exists. There are PA-
> TNC attributes that convey software information, but are not "SW
> attributes". Moreover, (for reasons you noted) the requests don't convey
> software information, but need to be considered SW attributes for the sake
> of this document. That term needs to refer specifically to the attributes that
> are defined in this specification. I propose:
> >
> > SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792 [RFC5792])
> extension as defined in this specification.
> >
> >> Propose renaming "SW Attribute" to "SWIMA Attribute", which seems
> more
> >> accurate. Take a look a the "SW Attribute" subtypes listed in section 5.2 to
> >> understand my motivation. Assuming "SW" expands to "software" (which
> is a
> >> reasonable presumption), then SW Request is not a SW Attribute. A SW
> >> Attribute might be a configuration item that software contains, but not a
> SW
> >> Request. The SW Request attribute is used to request software inventory
> >> related information from an endpoint, and is thus more appropriately an
> >> attribute associated with SWIMA than with "software". If this is
> acceptable,
> >> then we should update the term in section 10.1.
> >>
> >> Then, we may want to consider expanding "SW" to "SWIMA" wherever
> >> appropriate (i.e. SW Request could become SWIMA Request), which is
> longer
> >> to type but also inarguably more clear.
> >
> > Stephen's comments notwithstanding, I'm of two minds here. On the one
> hand, SW Attribute (and SW-PC and SW-PV) are primarily characterized by
> their conformance to the SWIMA specification, rather than just being
> software related. There are other NEA components that deal with software
> but are not part of SWIMA and therefore would not be SW-PCs or SW
> Attributes according to our definitions, which I agree might be confusing. In
> that regard, SWIMA-PC and SWIMA Attribute better capture the key
> characteristic of these entities.
> >
> > On the other hand, a "Software Inventory Message and Attributes
> Attribute" seems a bit redundant.
> >
> > Overall, I think I might be more inclined to go along with your suggestion
> and change SW Attribute to SWIMA Attribute (and SW-PC to SWIMA-PC,
> etc.) because it will better emphasize the key characteristic of these entities -
> that they are conformant to the SWIMA specification. (Really looking forward
> to a few hundred search and replace actions here....)
> >
> >> 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.
> >
> >> 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.
> >
> >> 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.
> >
> >> Are the subscription semantics of this draft intended to be extrapolated
> to
> >> other types of information collection going over PT-TLS in the future? This
> >> wasn't clear to me when reading the draft, but the IANA table additions
> >> (section 10.2) relating to subscriptions appear to have names generic
> enough
> >> to be reused. If that's the intent, then maybe we can figure out an easy
> way
> >> to clarify this in the draft, so that subsequent collection drafts are easier
> to
> >> create.
> >
> > I was not intending to create a generic subscription mechanism for PA-TNC.
> (Subscriptions would be at the application layer, rather than transport layer,
> which is what PT-TLS is.) I'm not sure a generic subscription mechanism for
> PA-TNC is really feasible since different types of information will have
> different triggers and different transport constraints.
> >
> > With regard to the generic names of the attributes: on a technical level,
> there will be no ambiguity. The attributes defined in this specification (with
> the exception of PA-TNC Error) are all part of the SWIMA PA Subtype.
> (Basically, this serves as a namespace for all the attributes defined in this
> specification.) Some other PA-TNC extension might conceivably define their
> own "Subscription Status Request" attribute, but it would have a different PA
> Subtype, so there would never be any confusion as to meaning. True - a
> human might get confused; however, I think this is mitigated by the fact that
> the attribute names really only are used within the context of a specific PA
> TNC extension (e.g., within the SWIMA specification). Thus I don't think
> there will be many practical opportunities for people to get confused. As
> such, I'd prefer to keep the names as they are rather than to make them
> even longer by prepending SWIMA or some other specification-specific label.
> >
> > Please let me know if you have any questions or comments.
> >
> > Charles
> >
> >> On Fri, Jul 28, 2017 at 10:41 AM Karen O'Donoghue <[e-mail]
> >> <mailto:[e-mail]> > wrote:
> >>
> >>
> >> 	Folks,
> >>
> >> 	This begins a 3 week working group last call (WGLC) for the following
> >> document:
> >>
> >> 	Software Inventory Message and Attributes (SWIMA) for PA-TNC
> >> 	https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/
> >>
> >> 	We have chosen to do a 3 week WGLC to account for post IETF
> >> recovery and August vacations.
> >>
> >> 	Please review the referenced document and send any comments to
> >> the mailing list including your assessment of whether this document is
> >> mature enough to proceed to the IESG. Please note that these messages
> of
> >> support for progression to the mailing list will be used to determine WG
> >> consensus to proceed.
> >>
> >> 	Please send all comments in by Friday 18 August 2017.
> >>
> >> 	Thank you!
> >> 	Karen and Adam
> >>
> >> 	_______________________________________________
> >> 	sacm mailing list
> >> 	[e-mail] <mailto:[e-mail]>
> >> 	https://www.ietf.org/mailman/listinfo/sacm
> >>
> >
> > _______________________________________________
> > sacm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sacm
> >
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm