Subject: [mile] CPE and SWID

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 5 Feb 2014 21:43:46 +0000

Changing the subject to reflect the discussion thread.

I just saw this message. Here is what I can vouch for as the NIST lead for these efforts:

NIST is continuing to support CPE as it has for the last few years. SCAP and a few other efforts are dependent on it, so this is critical. It has not been defunded.

NIST is working with the SWID community to advance the ISO specification efforts and to ensure that the necessary implementation guidance for SWID tag producers and tool consumers is put in place.

We see SWID tags as having synergies with the CPE effort. We are looking at methods to consume SWID tags, as software publishers create them, for use in auto generating CPEs. This has significant advantages over the current CPE methodology that largely involves investigating vulnerability reports and vendor product pages and documentation to generate CPE names. By generating CPE names in this way we can increase the fidelity and accuracy of the product data, using less human effort, making product identification information available as close to the publication of the software as possible.

Our long-term plans are to maintain a mapping between SWID and CPE in the National Vulnerability Database. This information does not exist yet, but is in the planning stages. Such information will provide a transition path for the SCAP community and other that use CPE today to take greater advantages of the information that SWID offer including: a more robust product metadata model and footprint information including file names, versions, and hashes.

Please let me know if you have any questions.

Thanks,
Dave

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
> Sent: Monday, January 27, 2014 5:40 PM
> To: Roman D. Danyliw; [email-masked]
> Subject: Re: [mile] @user-agent attribute
> 
> CPE isn't funded anymore and may get folded in SWID.  I don't have the
> latest on this, but would not want to rely on something that may go away.  Is
> anyone aware of the latest on CPE?
> 
> Thanks,
> Kathleen
> 
> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Monday, January 27, 2014 3:22 PM
> To: [email-masked]
> Subject: [mile] @user-agent attribute
> 
> Hello!
> 
> The -04 schema of 5070bis has the following comment in the definition of
> @user-agent in the Application and OperatingSystem classes.
> 
> [begin comment]
> "<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in SoftwareTypes?
> This is typically intended to mean servers, but the category seems more
> appropriate than others.-->"
> [end comment]
> 
> SoftwareType is the complexType used to define System/Application and
> Service/OperatingSystem.  Lacking documentation in the text and going only
> on the name in the schema, it would appear that this attribute is attempting
> to describe the "User-Agent" HTTP field per Section 14.43 of RFC2616.  If
> there is a broader definition, could someone please talk us through it.
> 
> With the addition of the Service/ApplicationHeader there appear to be two
> ways to represent a User-Agent.  Consider the following XML snippet below:
> 
> <System>...
> <Service ip_protocol="80">
> ... <ApplicationHeader proto="80" field="User-Agent"
> dtype="string">Mozilla/5.0 (Windows NT 6.2; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0
> Safari/537.36</ApplicationApplication>
> 
> ... <Application swid="xxx" configid="xxx" vendor="Google"
> name="Chrome" user-agent="Mozilla/5.0 (Windows NT 6.2; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
> version="32.0.11667"> <URL>something</URL> </Application> </Service>
> </System>
> 
> A few questions:
> ** Does the data model need the @user-agent attribute if
> ApplicationHeader can model it?
> ** Could @swid (defined as "An identifier that can be used to reference this
> software") be used for a User-Agent?
> ** What implementation guidance should be given about how @user-agent
> should be set with Service/OperatingSystem?
> 
> To share my own bias, the Application and OperatingSystem Class are
> currently very poorly specified.  I don't think we should continue improving
> them.  Instead, we should reference software through CPE
> (http://nvd.nist.gov/cpe.cfm) or similar effort as is possible through the SCI-
> defined class Platform.  For the time being, I would drop @user-agent.
> 
> Roman
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Blibbet <[email-masked]>
Date: Wed, 05 Feb 2014 14:13:22 -0800

> Please let me know if you have any questions.

Will this long-term mapping between SWID and CPE mean that we can ignore 
SWID and just use CPE?

Will I have to pay and/or join the SWID trade group to access this 
information? MITRE and NIST were goot at SCAP standards, making their 
data and schemas available without the extra licenses and registration 
barriers and fees. Do you have to pay ISO for access to their SWID 
standards? The last time a TagVault evangelist came on this list to push 
SWID, they failed to make any case for noncommercial use of SWID.
http://www.ietf.org/mail-archive/web/sacm/current/msg00679.html

SWID adds barriers, that'll make it difficult to create open source 
software, especially Free Software, that uses SCAP/SACM.

Does it still cost US$500/year for an individual to use CPE. The only 
"Open Source" Microsoft mentions when they defend SWID is an internal 
project (WIX), where they fund all the fees for it.

This sounds bad. SCAP/SACM should not use CPE.

---

From: Blibbet <[email-masked]>
Date: Wed, 05 Feb 2014 15:30:08 -0800

Sorry, I mistyped two things in my last message.

 > MITRE and NIST were goot at SCAP standards, ...

/goot/good

NIST/SCAP/IETF are good at making standards, ...

 > SCAP/SACM should not use CPE.

/CPE/SWID.

SCAP/SACM should not use SWID.

(CPE should be used.
SWID adds to many barriers and restrictions.)

Thanks.

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 10 Feb 2014 19:57:46 +0000

Blibbet,

I don't think we can simply ignore SWIDs. In my personal opinion, SWIDs have many advantages over CPEs including:

- Providing authoritative, high-fidelity software data generated at build time by the software creator/publisher. CPEs are commonly generated by 3rd parties in a labor intensive way by scraping vendor websites and vulnerability bulletins for software data that is often incomplete and inaccurate.
- Providing more robust software metadata that goes beyond the 11 fields supported by CPE including tags/identification for patches which CPE doesn't support.
- Normalizing the data representation for installed software on endpoints regardless of platform/software specific technologies.
- Providing software footprint details including composite files, versions, and hashes. This is not something that CPE supports.

Simply put, SWIDs provide greater support for the management of software across the deployment lifecycle than CPE allows for. This has both security and IT operational benefits. SWIDs allow for greater coverage and address the scalability concerns that currently exist with CPE.

With SWID there is not a requirement to pay or join any trade group to participate. Software publishers are responsible for the creation and propagation of SWID tags they produce. There is not a requirement to centrally curate them like there is with the US Government curated CPE dictionary.

The ISO specification is behind a paywall, which is the ISO model for publication. The IETF and ISO both reference each other's specifications. This should not be a significant barrier.

The schema is freely available. You can access it here:

http://standards.iso.org/iso/19770/-2/2009/schema.xsd

TagVault is developing best practice guides and certification requirements to help interested software publishers to demonstrate the degree of information provided by a publisher's SWID tags to support various use cases. They have stated publically that they intend to make these documents publically available as they are produced. Participation in TagVault is not a requirement for SWID tag publication; it is simply a value added service for publishers and consumers if they choose to participate.

I know of no US$500/year cost for use of CPE. Current CPE information is provided for use on a voluntary basis at no cost to the consumer at:

http://nvd.nist.gov/cpe.cfm

I hope this helps address your questions/concerns.

Sincerely,
Dave

> From: Blibbet [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2014 5:13 PM
> To: Waltermire, David A.
> Cc: [email-masked]
> Subject: Re: [mile] CPE and SWID
> 
> information? MITRE and NIST were goot at SCAP standards, making their data
> and schemas available without the extra licenses and registration barriers
> and fees. Do you have to pay ISO for access to their SWID standards? The last
> time a TagVault evangelist came on this list to push SWID, they failed to make
> any case for noncommercial use of SWID.
> SWID adds barriers, that'll make it difficult to create open source software,
> especially Free Software, that uses SCAP/SACM.
> 
> Does it still cost US$500/year for an individual to use CPE. The only "Open
> Source" Microsoft mentions when they defend SWID is an internal project
> (WIX), where they fund all the fees for it.
>

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 10 Feb 2014 19:48:23 -0500

Dave,

Across multiple bodies and companies, the
notion of SWIDs has been DOA.  Why is
it still being pursued here?

--tony

---

From: Blibbet <[email-masked]>
Date: Wed, 12 Feb 2014 10:59:30 -0800

Yes, you can simply ignore SWID. Continue with CPE.

Just like you should have rejected the Microsoft inclusion of PowerShell 
into NIST SCAP's OVAL. :-)

I believe you are incorrect. Perhaps you have been mislead by the SWID 
lobbyists? Have you joined yourself? Answer: probably not.

Re: cost, Wikipedia page on SWID:
----snip----
"The organization will act as a registration and certification authority 
for ISO/IEC 19770-2 software identifiation tags (SWID Tags) and will 
provide tools and services allowing all SAM eco-system members to take 
advantage of SWID tags faster, with a lower cost ($500 per year for 
individuals, $1,500 and up for organizations[6]) and with more industry 
compatibility than would otherwise be possible."
[6] http://tagvault.org/documents/2013/06/membership-information.zip
----snip----

Have you read the 40 pages of legal fine print required to join? How is 
this a good thing for IETF SACM and NIST SCAP-related standards?

Besides the freely-available XSD schema on their web site, are you able 
to access ANY SWID tags? Answer: No.

 From earlier in thread, the comments from Symantec -- one of SWID's 
founding corporations -- are fine for large commercial corporations. 
There are still massive SWID barriers for open source or Free Software. 
These barriers will ensure that only large corporations produce security 
software, which is bad now that the gov is finally realizing the value 
of open source.

I think one of their main main arguments for SWID -vs- CPE is that CPE's 
Microsoft namespace has errors? That's not a fault in CPE design, it's a 
fault for Micorosft, a SWID member, that has been relying on third 
parties to maintain their CPE namespace.

Again, NIST SCAP should not use SWID. IETF SACM should not use SWID. 
NIST SCAP may be going down this wrong path, but I hope IETF doesn't 
follow them.

Why give control over such critical metadata to a corporate trade group 
interested in making money and making barriers to access? Corporate-run 
industry trade groups that use standards bodies like ISO for legitimacy 
are not the kind of people that should be controlling key metadata for 
all computer security!

Thanks,
Lee

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 12 Feb 2014 15:52:01 -0500

We seem to live in a world of parallel universes
and reinvention of platforms every generation.

The idea for globally unique software/application IDs
is compelling - as it has been for the past 30 years.
Since the CCITT/JTC1 meetings of the early 80s,
SWIDs have been pursued by different groups.  Perhaps
the first and most elegant SWIDs were created in the
OSI world.  They deserve cudos for being far-sighted
- even binding the SWIDs to PKI certificates, although
their platform had limited takeup in the marketplace.

As the years progressed, and the need for unique
software IDs grew, multiple organizations and
groups created their own SWID schemes and sought
to assert it in the marketplace.  Bob Khan's combination
of DOIs and Handles is perhaps the zenith of the SWID
concepts.  The 19770-2 based SWIDs are the latest
folks on the SWID block.

About two years ago, the largest standards body today
in the networking sector, as well as the constituents
with the most compelling need - 3GPP - undertook
an 18 month process to consider if they should
establish their own SWIDs.  In the end, they did not
pursue that course.

What they discovered was that there was a world of
autonomous parties that have adopted well known
and widely established SWIDs.  Especially significant
were the maintainers of the two largest application
platform OSs - IOS and Android - which have their
own widely implemented SWIDs.  So in the end, 3GPP
chose embrace this diverse, autonomous SWID world.
The result was promulgated in Rel. 11 of the world's
universal spec for mobile networks.  The materials -
although extensive - are difficult to find unless one
is familiar with 3GPP and has access to the materials.
Some summary slides with pointers are attached.

Although 19770-2 based SWIDs are not a bad approach,
it is incomprehensible that a global standards body -
especially the IETF - would embrace them as the only
solution to a complex need where there are already so
many equally compelling solutions.  The work of 3GPP
here is worth emulating.

--tony

---

From: Steve Klos <[email-masked]>
Date: Wed, 12 Feb 2014 21:39:42 +0000

It appears there are some misunderstandings.

My comments will be bounded by [TagVault >] and [< TagVault} as I don't really see any way to do a proper response to e-mails like this using this type of messaging system...

My comments are in-line in the message below.

-----Original Message-----
From: Blibbet [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 11:00 AM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [mile] CPE and SWID

[TagVault >] 

CPE's can certainly still be used - never said they could not be.  SWID tags provide the data required and provided by publishers to construct the CPE names, with a few key exceptions:

1) Not all data elements are structured in the same way - they will be consistent, since they are provided by the publisher, but they will not be exactly the same as the names that are created by the volunteers who create CPE names today.

2) The data will be provided by the publishers - this ensures that the data is consistently made available and will not change depending on who is creating the CPE name.

3) The data will link directly with inventory of software discovered from a device.  Since there will be SWID tags installed on the device with the software, those can be directly linked to CPE names.  There will be no more data scrubbing, nor assumptions of what matches what.  The data provided in the SWID tag will exactly match the CPE and any tools that are managing a discovery process, regardless of who makes the tool, will provide exactly the same data!

[< TagVault}

Just like you should have rejected the Microsoft inclusion of PowerShell into NIST SCAP's OVAL. :-)

I believe you are incorrect. Perhaps you have been mislead by the SWID lobbyists? Have you joined yourself? Answer: probably not.

[TagVault>]

TagVault.org is not a lobbying organization.  We are working with producers and consumers to ensure the data structured is provided in a manner that works for both keystones who need to either create or use the data.

[< TagVault}

----snip----
"The organization will act as a registration and certification authority for ISO/IEC 19770-2 software identifiation tags (SWID Tags) and will provide tools and services allowing all SAM eco-system members to take advantage of SWID tags faster, with a lower cost ($500 per year for individuals, $1,500 and up for organizations[6]) and with more industry compatibility than would otherwise be possible."
[6] http://tagvault.org/documents/2013/06/membership-information.zip
----snip----

[TagVault >]

Yes, that's what TagVault.org is.  There are other tool providers and other approaches that can be used - with all of them ending up with exactly the same data structure and format.  There are open source tools on the market today that will create tags.  There are commercial tools on the market that will create and install tags.  There are commercial tools that read tags.  TagVault.org is structured to ensure that the very large software providers have a clear and concise definition for the amount of data that must be provided.  Smaller orgs are not likely to need this level of information, but with the disparity of platforms, dev team locations, dev processes, naming conventions, languages used, etc, an organization like TagVault.org makes sense.  There is absolutely no requirement for the company Blibbet works for to join TagVault.org.  If Blibbet would like to help specify best practices, to test use cases, to work with IBM, HP, Microsoft, Symantec and with other SDO's, great - join as an individual member.  Unfortunately, in today's world there are costs to manage an organization - program managers by IEEE-ISTO, E&O insurance, resources to write, edit and distribute materials and tools, etc.  IETF manages funding through a different means - meeting fees, meeting sponsors, and others.  There is money provided by someone, somewhere along the line to keep lights on and efforts moving forward.  At the moment, TagVault.org uses membership fees, that will change over time.  But with all of that, there is absolutely no requirement for someone to be a member of TagVault.org in order to produce SWID tags.

[< TagVault}

Have you read the 40 pages of legal fine print required to join? How is this a good thing for IETF SACM and NIST SCAP-related standards?

[TagVault >]

it's not particularly that fine print - it's in a 12 point font :-).  It's also mostly boiler plate text on how a non-profit works.  TagVault.org is formed as an IEEE-ISTO program which means it has a program manager and a board of directors to oversee how the program is run.  If anyone would like to read the material, it tries to be very clear and very transparent about how the board operates, how working groups are formed, how membership works, etc.  Non-profits require these types of rules to ensure they are operating on behalf of their membership.  Personally, I'd rather know how an organization works and what the expectations are than not.  I'm sure that the IETF has similar types of documents that define how its operations work.

[< TagVault}

Besides the freely-available XSD schema on their web site, are you able to access ANY SWID tags? Answer: No.

[TagVault >]

You are incorrect here!  Any software product that includes a SWID tag installs the tag along with the software.  If you have access to that software, you have access to the tag.  This is one reason why this approach is so much more scalable - data is provided by the publisher and there is no centralized catalog that *must* be referenced.  Will there ever be a catalog put up by TagVault.org - perhaps - if that's something that members want and if there are funds to pay for the development of such a repository.  I can easily see commercial and open source systems that create their own catalog as well.  The key here is that the SWID tag travels with the software and patches, there is no after the fact work that's needed, nor is there any third party work that's needed.

[< TagVault}

 From earlier in thread, the comments from Symantec -- one of SWID's founding corporations -- are fine for large commercial corporations. 
There are still massive SWID barriers for open source or Free Software. 
These barriers will ensure that only large corporations produce security software, which is bad now that the gov is finally realizing the value of open source.

[TagVault >]

You may be surprised to hear me say, I agree with you, but I do.  TagVault.org is working on a few avenues to mitigate the issue of FOSS developers having access to the materials they need and in having some added benefits that come with SWID tags:

1) TagVault.org will publish a compendium for the standard.  It will not be the official standard, but will provide the data required to understand the data elements and attributes, know how they should be used and the details behind how the data is used by consumers.  This document will be available to anyone.

2) The best practices document we are currently working on will also be available to the public.  The standard itself has to accommodate every use case where someone wants to conform to the standard, but the best practices guide will focus on what data elements and attributes need to be provided by a publisher to provide the most value to the SWID tag consumer.

3) Should there be a requirement to use SWID tags in software that's purchased by the US Government, the 19770-2 standard will be available for free (as mentioned in my last e-mail).

4) TagVault.org is working with a FOSS proponent to ensure that the revision provides added value for that community.  I won't go into detail here, but I can ask if there is a venue where these types of discussions are happening and point you toward that venue if you are interested.

One other thing - we do have a fairly strong open source presence on the ISO working group as there is a significant interest in having software that can be more automated from an IT management perspective.

Would love to have everything available right now, but it's a progressive development effort.

[< TagVault}

I think one of their main main arguments for SWID -vs- CPE is that CPE's Microsoft namespace has errors? That's not a fault in CPE design, it's a fault for Micorosft, a SWID member, that has been relying on third parties to maintain their CPE namespace.

[TagVault >]

There are a number of well-known issues with CPE's.  It's not just the Microsoft namespace, it's most of the namespaces that have errors.  This also isn't just a CPE issue, it's generally an issue of any system that attempts to use an archeological approach to software identification - all of these systems can get close, but they are almost never perfect.  They are also not scalable.  Having said all that - if you want to keep using CPE's - great - do so, the SWID tag data will provide vendor supplied data values that can be used to construct normalized CPE names.  Other than TagVault.org helping to ensure the revision of the standard allows for the data needed to create CPE's - there's no TagVault.org involvement.  

[< TagVault}

Again, NIST SCAP should not use SWID. IETF SACM should not use SWID. 
NIST SCAP may be going down this wrong path, but I hope IETF doesn't follow them.

Why give control over such critical metadata to a corporate trade group interested in making money and making barriers to access? Corporate-run industry trade groups that use standards bodies like ISO for legitimacy are not the kind of people that should be controlling key metadata for all computer security!

[TagVault >]

I take serious issue with the above statement for any number of reasons, but will limit my reply.  ISO is an international SDO, so is IETF - they both have their respective focus areas and a variety of strengths and weaknesses.  I would say that neither is perfect, nor would most any rational person try to say they were.  I personally don't care too much about the standards body I work with - what I personally am interested in is being able to fix what, so far, has been a large and growing problem for IT - and that is the standardized provision of software identification information.  I don't particularly care which SDO is managing the overall standards development process, as long as there are clear rules to follow and I know where my work fits into the overall process.  Further, the meta data that you're referring to is managed by the publishers of the software - who have a very significant vested interest in ensuring their software is easy to manage and that it can be validated as being secure.  I would be more than happy to provide details on how the process works, so you can see there is no requirement for companies to be a member of TagVault.org, nor is there a requirement for someone to buy the standard.  The key part of the SWID standard is the definition of the data provided and the structure of how it's provided.  Beyond that, it's between the publisher and the consumer to define expectations.  

I hope this provides some additional insights to those who cared to read to the end.  

There seem to be two approaches that are being promoted here:

CPE 
  - Only available in a central repository
  - Curated by 3rd party individuals (who don't seem to manage CPE names as a full time job, but as an added extra)
  - No strict approach towards normalization applied
  - Definition happens well after the software is released
  - No direct link that can be used to associate the CPE with software inventory
  - No CPE's defined for patches
  - No direct link between a CPE and where someone can automatically download patches
  - No ability to use inventory data  to know if patches are installed or not.
  - No commercial value for software publishers to define a CPE name for each release
  - No ability to use signatures in the CPE to validate publisher, or other app data
  - No ability to get to file level details for application data (note, this is not even close to being in scope for CPE's so really not fair)

SWID tags
  - No repository required - publishers provide SWID tag data with their software making this unbelievably scalable
  - Defined by publisher and consistently applied by publisher
  - Normalization applied to many values - more possible, but need market support
  - Definition happens as part of the software release process
  - Direct link between meta data and software inventory
  - Full support for patches
  - Direct link (in revision) between SWID tag and the publisher location where patches can be downloaded
  - Direct link between inventory data and patch installation checks
  - Lots of value for publishers (both commercial and FOSS) to provide SWID tag data as it benefits many IT processes
  - Digital signatures of data required (plenty more to define here such as how CA's are used, what algorithms are used, etc, but SWID tags can be signed by the publisher today - further refinement of requirements can be applied to best practices)
  - File level data provided when publishers include the file payload information (based on customer demand).

Will let others on this list make the call.

Cheers,

SK

[< TagVault}

Thanks,
Lee

On 2/10/14 11:57 AM, Waltermire, David A. wrote:
>> Will this long-term mapping between SWID and CPE mean that we can 
>> ignore SWID and just use CPE?
>>
>> data and schemas available without the extra licenses and 
>> registration barriers and fees. Do you have to pay ISO for access to 
>> their SWID standards? The last time a TagVault evangelist came on 
>> this list to push SWID, they failed to make any case for noncommercial use of SWID.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 12 Feb 2014 18:06:08 -0500

It costs CHF 196.00 to even look at the the
19770-2:2009 specification of SWIDs.
That's $217.66 cents at today's exchange rate.

Of course, that's just the starting price, as
it likely makes reference to other ISO
specs for which there are additional costs.

Out of curiosity, if use of the spec was of some
importance to USG parties, why wasn't ISO
forced to make it publicly available like the
Common Criteria specs?

What other IT/telecom identifier spec these
days has a several hundred dollar pricetag to
view it?

--tony

---

From: Blibbet <[email-masked]>
Date: Thu, 13 Feb 2014 15:21:03 -0800

Steve,

In answer to your question, I don't represent any organization. I 
represent the use case of a open source project, specifically the more 
stringent case of a Free Software-licensed project, which usually 
consists of 2-5 people with zero budget. Big companies will have no 
problems with the barriers your organizion imposes (and I'm happy for 
all those non-profit income you earn from them!). But, as you admit, 
SWID is not usable for open source project use. And I do have an issue 
if SCAP or IETF SACM or related IETF standards use your stuff, as it 
currently exists.

Tony,

Speaking of parallel universes, there's also the Linux Foundation-based 
standard SPDX, which also tracks computer metadata, and might compete 
with CPE and SWID. Microsoft-based TagVault will likely have zero 
interest in a Linux Foundation-based standard, of course. ;-) I'd much 
rather see CPE mapped to SPDX, not SWID.

IETF/NIST:

So, as Steve of TagVault admits in his last msg, it is not viable for 
open source-based proejcts.

In previous msgs, I didn't even bring up the lack of transparency in the 
corporations that control this industry group. I can't find out that 
data, they try hard to keep that data from the public. I seem to recall 
it was started by Microsoft and the Business Software Alliance (BSA, the 
piracy lawyer trade group), but can't confirm this. There's also the 
issue of what patents and related legal barriers that the SWID tech has, 
I see nothing that makes it ready for IETF-based usage.

If IETF-based standards are happy to write-off open source 
implemenations, and NIST is happy to do likewise with SCAP, then you 
should adopt SWID today.

If you want SWID to be usable by open source projects, we need to wait 
for TagVault v.next. Fewer legal barriers, zero price barriers for open 
source projects. Complete transparency about the controlling 
corporations and intellectual property they're controlling. And a 
reference implementation of SWID-based open soruce project that is not 
hosted/funded by MSFT, that is capable of being added to the 
package/port list of an FSF.org-approved Linux distro, Debian at the least.

Until then, any IETF or NIST SCAP standards should completely ignore SWID.

Just like they ignore ICASI SWRF and other vendor-controlled 
non-standards that pretend to be ones.

In the mean time, you can keep using CPE, and ignore SWID. TagVault will 
write a batch file -- not a shell script, I'm fairly sure -- to do the 
mappings themselves, if they want to keep being important in this space.

I look forward to the day that SWID is usable by Free Software.

Thanks,
Lee

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 19 Feb 2014 02:23:03 +0000

Going back to the start of this thread, what was proposed was to incorporate ISO/IEC 19770-2 SWIDs as ONE method of identifying software in the Application and OperatingSystem classes "using the SCI-defined class Platform". I agree that we will never see 100% convergence on a single software identification approach across all use cases and communities of interest. But efforts like SWID tagging and CPE do offer a degree of commonality across specific communities of interest and use cases. This should not be discounted here. It seems to me that SWID tags should be included in this work, along with CPE, as a possible method to identify software in this context. There is running code for both examples.

Dave

> From: mile [mailto:[email-masked]] On Behalf Of Tony Rutkowski
> Sent: Wednesday, February 12, 2014 3:52 PM
> To: [email-masked]
> We seem to live in a world of parallel universes and reinvention of platforms
> every generation.
> 
> The idea for globally unique software/application IDs is compelling - as it has
> been for the past 30 years.
> Since the CCITT/JTC1 meetings of the early 80s, SWIDs have been pursued by
> different groups.  Perhaps the first and most elegant SWIDs were created in
> the OSI world.  They deserve cudos for being far-sighted
> - even binding the SWIDs to PKI certificates, although their platform had
> limited takeup in the marketplace.
> 
> As the years progressed, and the need for unique software IDs grew,
> multiple organizations and groups created their own SWID schemes and
> sought to assert it in the marketplace.  Bob Khan's combination of DOIs and
> Handles is perhaps the zenith of the SWID concepts.  The 19770-2 based
> SWIDs are the latest folks on the SWID block.
> 
> About two years ago, the largest standards body today in the networking
> sector, as well as the constituents with the most compelling need - 3GPP -
> undertook an 18 month process to consider if they should establish their own
> SWIDs.  In the end, they did not pursue that course.
> 
> What they discovered was that there was a world of autonomous parties
> that have adopted well known and widely established SWIDs.  Especially
> significant were the maintainers of the two largest application platform OSs -
> IOS and Android - which have their own widely implemented SWIDs.  So in
> the end, 3GPP chose embrace this diverse, autonomous SWID world.
> The result was promulgated in Rel. 11 of the world's universal spec for mobile
> networks.  The materials - although extensive - are difficult to find unless one
> Although 19770-2 based SWIDs are not a bad approach, it is
> incomprehensible that a global standards body - especially the IETF - would
> embrace them as the only solution to a complex need where there are
> already so many equally compelling solutions.  The work of 3GPP here is
> worth emulating.
> 
> --tony
> 
>

---

From: Steve Klos <[email-masked]>
Date: Fri, 21 Feb 2014 23:04:40 +0000

+1

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2014 6:23 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] CPE and SWID

Dave

> We seem to live in a world of parallel universes and reinvention of 
> platforms every generation.
> 
> The idea for globally unique software/application IDs is compelling - 
> as it has been for the past 30 years.
> Since the CCITT/JTC1 meetings of the early 80s, SWIDs have been 
> pursued by different groups.  Perhaps the first and most elegant SWIDs 
> were created in the OSI world.  They deserve cudos for being 
> far-sighted
> - even binding the SWIDs to PKI certificates, although their platform 
> had limited takeup in the marketplace.
> 
> sought to assert it in the marketplace.  Bob Khan's combination of 
> DOIs and Handles is perhaps the zenith of the SWID concepts.  The 
> 19770-2 based SWIDs are the latest folks on the SWID block.
> 
> About two years ago, the largest standards body today in the 
> networking sector, as well as the constituents with the most 
> compelling need - 3GPP - undertook an 18 month process to consider if 
> they should establish their own SWIDs.  In the end, they did not pursue that course.
> 
> significant were the maintainers of the two largest application 
> platform OSs - IOS and Android - which have their own widely 
> implemented SWIDs.  So in the end, 3GPP chose embrace this diverse, autonomous SWID world.
> The result was promulgated in Rel. 11 of the world's universal spec 
> for mobile networks.  The materials - although extensive - are 
> difficult to find unless one is familiar with 3GPP and has access to the materials.
> incomprehensible that a global standards body - especially the IETF - 
> would embrace them as the only solution to a complex need where there 
> are already so many equally compelling solutions.  The work of 3GPP 
> here is worth emulating.
> 
> --tony
> 
>