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

[Adam Montville <[e-mail]>]

Thanks! This does help, yes.

On Tue, Aug 1, 2017 at 8:59 AM Andreas Steffen <
[e-mail]> wrote:

> Hi Adam,
>
> see my inline comments
>
> On 31.07.2017 21:51, Adam Montville wrote:
> >
> > 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.
> >
> A SW Request can very well be a SW Attribute. Have look at RFC5792
> PA-TNC were the standard Attribute Request Attribute is defined
>
>   https://tools.ietf.org/html/rfc5792#section-4.2.1
>
> which can be used by a Posture Validator to request any number of
> PA-TNC attributes from a Posture Collector.
>
> > 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.
> >
> SWIMA is the acronym for *Software Inventory Message and Attributes",
> i.e the I-D document is about Software Inventory Attributes being
> transported in PA-TNC messages of PA Subtype "SW Attributes".
>
> Since a Posture Validator can request either a SW [Identifier] Inventory
> Attribute or a SW [Identifier] Events Attribute, SW Request is a
> very good description for the request.
>
> > 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? What about discovered
> > software outside typical installation patterns? And, does it make sense,
> > in a brokered architecture like NEA, to require redundant capabilities
> > in the anticipated myriad collectors?>
> Before the advent of SWIMA, simple software inventory information
> (Package Name/Package Version Number) available from a Linux Package
> Manager had to be sent in a standard Installed Packages Attribute
> accompanied by a standard Product Version Attribute (giving information
> about the underlying Operating System), both attributes defined in
> RFC5792 PA-TNC. Thus a minimalistic SWID 2015 tag of the form
>
>   <SoftwareIdentity name="tar"
>     tagId="Ubuntu_16.04-x86_64-tar-1.28-2.1ubuntu0.1"
>     version="1.28-2.1ubuntu0.1" versionScheme="alphanumeric">
>     <Entity name="strongSwan Project" regid="strongswan.org"
>       role="tagCreator"/>
>   </SoftwareIdentity>
>
> carries about the same information and the software release can be
> uniquely referenced by a Software Identifier of the form
>
>   strongswan.org__Ubuntu_16.04-x86_64-tar-1.28-2.1ubuntu0.1
>
> Hopefully some time in the not too distant future Ubuntu in the
> role of a distributor would then release signed reference SWID 2015
> tags e.g. with a Software Identifier of the form
>
>   ubuntu.com__16.04-amd64-tar-1.28-2.1ubuntu0.1
>
> retrievable from the page manager.
>
> I think for most use cases the SWID 2015 Data Model can be used. I'm
> not sure about the relevance of the SWID 2009 Data Model because only
> about a dozen of tags seem to exist in the wild.
>
> The extensibility of the Data Model via the PEN/Type mechanism is
> very important. I think there are shortly going to be SWID 2015
> variants, e.g using a JSON or CBOR encoding of the SW record.
>
> Hope this helps
>
> Andreas
>
> ======================================================================
> Andreas Steffen                         [e-mail]
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> Institute for Networked Solutions
> HSR University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[INS-HSR]==
>
>