Subject: [sacm] NISTIRs SWID and CPE Drafts

From: Jerome Athias <[email-masked]>
Date: Fri, 18 Dec 2015 09:07:06 +0300

Hi

FYI, 2 new drafts for SWID tags and CPE
http://csrc.nist.gov/news_events/#dec17

Best regards

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 18 Dec 2015 07:10:54 -0500

It's the season - following on the heels of
the ATIS-iconectiv announcement of its
SWIDs.  A few weeks ago, the Russian
Federation pushed DOA SWIDs in ITU-T
SG11.  A couple of years ago at this time, the
now defunct Apigee WAC initiative announced
its  SWIDs.  Although out of business, the
residual Wikipedia page provides great
pointers to yet other SWID roadkill.
https://en.wikipedia.org/wiki/Wholesale_Applications_Community

This is also the second time around  for
NIST.  They did this 25 some years ago with
GOSIP and its SWIDs.  Like echoes in space-time,
the remnants still remain in the global OID
repository at http://oid-info.com/get/1.3.5

It's worth noting that when you do Google
searches now on Application ID, the most
prominent URL is the IETF's persistent
listing of SWIDs.
https://www.ietf.org/mail-archive/web/mile/current/pdfJvN_FxflCS.pdf

This raises the prospect of whether SACM
might play the really valuable role of
maintaining a kind of global registry of
all the SWIDs out there.  Just a thought.

--tony

On 2015-12-18 1:07 AM, Jerome Athias wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Fri, 18 Dec 2015 16:31:05 +0000

Jerome,

Thanks for sharing with the working group. We’ve put a lot of work into this NIST IR and would appreciate review and comment by SACM WG members.

One of the things we’ve tried hard to do in the NIST IR is put detailed information about SWID tags out into the public sphere. This is to try to address concerns about the SWID specification sitting behind the ISO pay-for-specs paywall. We hope that the IR, combined with the public SWID XSD, will provide essentially everything you need to know about SWIDs to informed decisions about the uses and benefits of tags.

Cheers,
/Brant

Brant A. Cheikes
Principal Cyber Security Engineer
J83D – Cyber Security Partnerships
781-271-7505 (office) / 617-694-8180 (mobile)
[email-masked]

<https://www.facebook.com/MITREcorp><https://www.linkedin.com/company/mitre><https://twitter.com/MITREcorp><https://www.youtube.com/user/mitrecorp><https://plus.google.com/+MitreOrgFFRDCs/posts>
<http://www.mitre.org/>

From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Friday, December 18, 2015 1:07 AM
To: [email-masked]
Subject: [sacm] NISTIRs SWID and CPE Drafts

Hi

Best regards

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 18 Dec 2015 16:10:42 -0500

Brant,

It might also be useful to consider the NISTIR
in the current marketplace for App IDs that
is advancing significant alternatives  One of
those competitors receiving considerable press
is the OneM2M App ID.  The relevant material
is attached.  As you can see, there is rather
significant treatment as to trust, processes,
branding, etc.  An inquiry as to price from the
iconectiv registry indicates a cost of US$100.
Do you have an information as to the cost for
19770 SWIDs?

Does NIST intend to provide for alternative
competitor SWIDs as part of the NISTIR's
evolution?  That would be useful.

--tony

On 2015-12-18 11:31 AM, Cheikes, Brant A. wrote:
>
> Jerome,
>
> Thanks for sharing with the working group. We’ve put a lot of work 
> into this NIST IR and would appreciate review and comment by SACM WG 
> members.
>
> One of the things we’ve tried hard to do in the NIST IR is put 
> detailed information about SWID tags out into the public sphere. This 
> is to try to address concerns about the SWID specification sitting 
> behind the ISO pay-for-specs paywall. We hope that the IR, combined 
> with the public SWID XSD, will provide essentially everything you need 
> to know about SWIDs to informed decisions about the uses and benefits 
> of tags.
>

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 19 Dec 2015 07:07:00 -0500

Brant,

You and your colleagues deserve cudos for
your efforts in developing NISTIR 8060.  It
is well done, and encouraging a common
global means of expressing and managing
software instances is definitely a good thing.
(You might even use the existence of the
NISTIR to force the SC7 secretariat to make
the specification publicly/freely available.)

Several technical questions that could use
clarification would be appreciated.

Is the only requirement for the tagId data
element that it be globally unique?  Are there
any constraints, e.g., length?

Anyone can generate a SWID tag.  So what is
the relevance, if any, of the TagVault.org
certification and database?  It appears only
that is passes muster using their tools.  See
http://tagvault.org/certification/regid-certification/

Because the trust of component of SWID is
dependent on the trust of the associated
digital signature, does the use of EVcerts
enhance that trust?

What is the typical size of a tag file, and
are there any plans to use JSON for the
SWID expressions?

best,
tony

On 2015-12-18 11:31 AM, Cheikes, Brant A. wrote:
> *Brant A. Cheikes*
> <https://www.facebook.com/MITREcorp>cid:[email-masked] 
> <https://www.linkedin.com/company/mitre>cid:[email-masked] 
> <https://twitter.com/MITREcorp>cid:[email-masked] 
> <https://www.youtube.com/user/mitrecorp>cid:[email-masked] 
> <https://plus.google.com/+MitreOrgFFRDCs/posts>
>
> cid:[email-masked] <http://www.mitre.org/>
>
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Jerome Athias
> *Sent:* Friday, December 18, 2015 1:07 AM
> *To:* [email-masked]
> *Subject:* [sacm] NISTIRs SWID and CPE Drafts
>
> Hi
>
**

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Mon, 21 Dec 2015 17:31:27 +0000

Tony,

Thanks for the positive feedback-it's greatly appreciated.

Regarding the <SoftwareIdentity> @tagId attribute, the SWID specification states that it "shall be globally unique for every SWID tag created". The specification recommends (but does not require) "a minimum of a 16 byte globally unique identifier (GUID)", and goes on to say that if a string is used, the string value "shall follow the restrictions for URI character use as specified in IETF RFC 3986".

In the NIST IR, we didn't consider the possible need for @tagId guidelines. What additional guidelines, if any, would you recommend be placed on implementers of @tagId attribute values?

You are correct that anyone can create a SWID tag. The NIST IR is deliberately agnostic to the role of TagVault in the marketplace. I'll finish addressing your questions, then comment specifically on TagVault's role, if any.

We are actively researching the technologies and procedures that should be used to digitally sign tags. We have not specifically considered guidelines related to the type of certificates that should be used. Would you recommend guidelines related to the use of extended validation certificates?

The typical size of a SWID tag is (obviously) dependent on how many elements are populated. A minimal unsigned tag-i.e., one that simply identifies a product and provides basic metadata-is under 1K. But a minimal tag provides very little value w/r/t the cybersecurity usage scenarios we care about. If the <Payload> is fully specified as the NIST IR calls for, and the product has a large number of files and folders, the SWID tag can get very large. Adding digital signatures-especially if one rolls in trusted timestamps and other assurance data-further increases tag size. Think about exporting all the metadata in an RPM package. At present, I'm not aware of any ongoing activities to specify a JSON binding for tags. This strikes me as a marketplace decision; to what extent will "SWID tag success" (i.e., widespread adoption and use) hinge on JSON support?

Now a few *personal* comments about TagVault. Full disclosure: MITRE is a TagVault member and I'm MITRE's TagVault liaison. I cannot and do not speak for TagVault, but do consider myself a "friend" of TagVault. That said, Dave and I are taking care not to enshrine any role for TagVault in US Government guidance. I personally see a need for some kind of *industry-led* "rallying point" to evangelize and promote SWID adoption and use, to educate, to raise awareness, and to drive consensus on the myriad technical matters needed to make SWID tags useful to producers and consumers (e.g., on whether and how to provide a JSON binding). This seems like a very good role for TagVault to play. But it takes some serious resources; I'm deeply skeptical that the role can be satisfied on a purely volunteer basis.

A second potentially useful role for TagVault concerns tag data normalization. As you noted, anybody can create a SWID tag. But this opens the door to data inconsistency. (For example, different tags from the same software vendor might use different strings to identify the vendor.) So there's an idea that TagVault will provide a "certification service" in the market. Although there is no requirement that SWID tags be certified (in the NIST IR, for example), the idea is that a tag certification organization like TagVault could (for a fee) offer a mechanism whereby a tag is inspected for data quality and consistency, then signed as attestation that the tag passes muster. The value and need for such a service is largely hypothetical at this point, but can easily be envisaged. Indeed, one can imagine multiple organizations (per country) offering tag-certification services, not just TagVault.

I believe that TagVault seeks to resource its "industry rallying point" work through membership and tag-certification fees. It's not clear to me yet that this business model is sustainable. That said, I do hope that TagVault manages to craft a sustainable business model since I don't think tagging will get where it needs to get, as fast as it needs to get there, without a TagVault-like organization actively leading the charge, and able to apply the resources necessary to do so.

Cheers,
/Brant

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Saturday, December 19, 2015 7:07 AM
To: Cheikes, Brant A. <[email-masked]>; [email-masked]
Subject: Re: [sacm] NISTIRs SWID and CPE Drafts

Brant,

best,
tony

Thanks for sharing with the working group. We've put a lot of work into this NIST IR and would appreciate review and comment by SACM WG members.

One of the things we've tried hard to do in the NIST IR is put detailed information about SWID tags out into the public sphere. This is to try to address concerns about the SWID specification sitting behind the ISO pay-for-specs paywall. We hope that the IR, combined with the public SWID XSD, will provide essentially everything you need to know about SWIDs to informed decisions about the uses and benefits of tags.

Cheers,
/Brant

Brant A. Cheikes
Principal Cyber Security Engineer
J83D - Cyber Security Partnerships
781-271-7505 (office) / 617-694-8180 (mobile)
[email-masked]<mailto:[email-masked]>

From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Friday, December 18, 2015 1:07 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] NISTIRs SWID and CPE Drafts

Hi

Best regards

sacm mailing list

[email-masked]<mailto:[email-masked]>

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 21 Dec 2015 13:24:35 -0500

This is very helpful Brant.  My sense is that the
NISTIR is the first in an array of steps that could
be taken to expand uptake - beginning with a
simple explanation of the benefits of a "common
software instance expression."  One could muse
that if MITRE  had played a greater role all along,
it might have been known as a CSIE. :-)

The IETF URL provides extracts from several
3GPP group documents describing their efforts
to do something similar over an 18 month period,
and included significant engagement with software
vendors.  It might be worth seeing if the GUID construct
they adopted can be mapped into the SWID spec.
Indeed, going forward, you might want to engage
both 3GPP  and GSMA who have long been seeking
SWID like solutions.  IMHO, TagVault has been more
of a hindrance than a help.

Regarding JSON, you might just want something
considerably more compact for IoT related software.
OASIS TC CTI seems now to have move significantly
in that direction to accommodate large numbers
threat sightings.  It would likely be fairly trivial to do
the translations into JSON - which could be done either
by NIST or a willing ancillary standards forum.  OASIS
like IETF is moving increasingly toward that syntax.

EVcerts?  Are they helpful?  Certainly CA/B Forum thinks
they are, and building that relationship could help with
SWID scaling...as well as trust levels.

best,
tony

On 2015-12-21 12:31 PM, Cheikes, Brant A. wrote:
>
> Tony,
>
> Thanks for the positive feedback—it’s greatly appreciated.
>
> Regarding the <SoftwareIdentity> @tagId attribute, the SWID 
> specification states that it “shall be globally unique for every SWID 
> tag created”. The specification recommends (but does not require) “a 
> minimum of a 16 byte globally unique identifier (GUID)”, and goes on 
> to say that if a string is used, the string value “shall follow the 
> restrictions for URI character use as specified in IETF RFC 3986”.
>
> In the NIST IR, we didn’t consider the possible need for @tagId 
> guidelines. What additional guidelines, if any, would you recommend be 
> placed on implementers of @tagId attribute values?
>
> You are correct that anyone can create a SWID tag. The NIST IR is 
> deliberately agnostic to the role of TagVault in the marketplace. I’ll 
> finish addressing your questions, then comment specifically on 
> TagVault’s role, if any.
>
> We are actively researching the technologies and procedures that 
> should be used to digitally sign tags. We have not specifically 
> considered guidelines related to the type of certificates that should 
> be used. Would you recommend guidelines related to the use of extended 
> validation certificates?
>
> The typical size of a SWID tag is (obviously) dependent on how many 
> elements are populated. A minimal unsigned tag—i.e., one that simply 
> identifies a product and provides basic metadata—is under 1K. But a 
> minimal tag provides very little value w/r/t the cybersecurity usage 
> scenarios we care about. If the <Payload> is fully specified as the 
> NIST IR calls for, and the product has a large number of files and 
> folders, the SWID tag can get very large. Adding digital 
> signatures—especially if one rolls in trusted timestamps and other 
> assurance data—further increases tag size. Think about exporting all 
> the metadata in an RPM package. At present, I’m not aware of any 
> ongoing activities to specify a JSON binding for tags. This strikes me 
> as a marketplace decision; to what extent will “SWID tag success” 
> (i.e., widespread adoption and use) hinge on JSON support?
>
> Now a few **personal** comments about TagVault. Full disclosure: MITRE 
> is a TagVault member and I’m MITRE’s TagVault liaison. I cannot and do 
> not speak for TagVault, but do consider myself a “friend” of TagVault. 
> That said, Dave and I are taking care not to enshrine any role for 
> TagVault in US Government guidance. I personally see a need for some 
> kind of **industry-led** “rallying point” to evangelize and promote 
> SWID adoption and use, to educate, to raise awareness, and to drive 
> consensus on the myriad technical matters needed to make SWID tags 
> useful to producers and consumers (e.g., on whether and how to provide 
> a JSON binding). This seems like a very good role for TagVault to 
> play. But it takes some serious resources; I’m deeply skeptical that 
> the role can be satisfied on a purely volunteer basis.
>
> A second potentially useful role for TagVault concerns tag data 
> normalization. As you noted, anybody can create a SWID tag. But this 
> opens the door to data inconsistency. (For example, different tags 
> from the same software vendor might use different strings to identify 
> the vendor.) So there’s an idea that TagVault will provide a 
> “certification service” in the market. Although there is no 
> requirement that SWID tags be certified (in the NIST IR, for example), 
> the idea is that a tag certification organization like TagVault could 
> (for a fee) offer a mechanism whereby a tag is inspected for data 
> quality and consistency, then signed as attestation that the tag 
> passes muster. The value and need for such a service is largely 
> hypothetical at this point, but can easily be envisaged. Indeed, one 
> can imagine multiple organizations (per country) offering 
> tag-certification services, not just TagVault.
>
> I believe that TagVault seeks to resource its “industry rallying 
> point” work through membership and tag-certification fees. It’s not 
> clear to me yet that this business model is sustainable. That said, I 
> do hope that TagVault manages to craft a sustainable business model 
> since I don’t think tagging will get where it needs to get, as fast as 
> it needs to get there, without a TagVault-like organization actively 
> leading the charge, and able to apply the resources necessary to do so.
>
> Cheers,
>
> /Brant
>
> *From:*Tony Rutkowski [mailto:[email-masked]]
> *Sent:* Saturday, December 19, 2015 7:07 AM
> *To:* Cheikes, Brant A. <[email-masked]>; [email-masked]
> *Subject:* Re: [sacm] NISTIRs SWID and CPE Drafts
>
> Brant,
>
>     into this NIST IR and would appreciate review and comment by SACM
>     WG members.
>
>     detailed information about SWID tags out into the public sphere.
>     This is to try to address concerns about the SWID specification
>     sitting behind the ISO pay-for-specs paywall. We hope that the IR,
>     combined with the public SWID XSD, will provide essentially
>     everything you need to know about SWIDs to informed decisions
>     about the uses and benefits of tags.
>
>     Cheers,
>
>     /Brant
>
>     *Brant A. Cheikes*
>
>     [email-masked] <mailto:[email-masked]>
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Tue, 22 Dec 2015 14:19:06 +0000

Tony,

Glad that helped. I rather like that phrase (common software instance expression), though I'm sure many will be relieved that MITRE didn't spawn another "common" standard in the vein of CVE, CPE, CWE, CRE, CEE, ...!!

I'll look into the 3GPP and GSMA connections, thanks for the suggestion. I don't think that the SWID work to date has been well informed or well connected to the mobile/IoT world. That strikes me simply as a case of trying to "crawl" before "walking." I also think that the "I" in SWID (for "Identification") has created confusion. I hope you noticed that in the NIST IR, we tried to describe SWID tags as both "identifying" and "describing" software. A SWID tag document can contain a unique identifier for a product (in the @tagId attribute), while also providing a lot of additional descriptive metadata, ranging from description information on various organizations associated with the product and with the tag, links to other tags and information items (such as pointers to applicable licenses), and detailed lists of the files and folders comprising the product. If other organizations have found satisfactory and scalable ways of generating and maintaining product identifiers, I see no reason why those identifiers couldn't be used within a tag.

I'm aware of the trend towards JSON and agree that a compact representation for tags will be needed. I tend to see the next 1-2 years as pretty critical for tags. They'll either take off or fade. If the former, then I think there will be a natural movement towards rethinking the representation.

Cheers,
/Brant

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Monday, December 21, 2015 1:25 PM
To: Cheikes, Brant A. <[email-masked]>; [email-masked]
Subject: Re: [sacm] NISTIRs SWID and CPE Drafts

best,
tony

Cheers,
/Brant

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Saturday, December 19, 2015 7:07 AM
To: Cheikes, Brant A. <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] NISTIRs SWID and CPE Drafts

Brant,

best,
tony

Cheers,
/Brant

Brant A. Cheikes

Hi

Best regards

sacm mailing list

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA

sacm mailing list

--

________________________________

Anthony Michael Rutkowski

[email-masked]<mailto:[email-masked]>

________________________________

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA