draft-ietf-sacm-coswid-00.txt   draft-ietf-sacm-coswid-01.txt 
SACM Working Group H. Birkholz SACM Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Standards Track J. Fitzgerald-McKay Intended status: Standards Track J. Fitzgerald-McKay
Expires: July 13, 2017 Department of Defense Expires: August 20, 2017 Department of Defense
C. Schmidt C. Schmidt
The MITRE Corporation The MITRE Corporation
D. Waltermire D. Waltermire
NIST NIST
January 09, 2017 February 16, 2017
Concise Software Identifiers Concise Software Identifiers
draft-ietf-sacm-coswid-00 draft-ietf-sacm-coswid-01
Abstract Abstract
This document defines a concise representation of ISO 19770-2:2015 This document defines a concise representation of ISO 19770-2:2015
Software Identifiers (SWID tags) that is interoperable with the XML Software Identifiers (SWID tags) that is interoperable with the XML
schema definition of ISO 19770-2:2015. schema definition of ISO 19770-2:2015 and augmented for application
in Constrained-Node Networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2017. This Internet-Draft will expire on August 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Concise SWID data definition . . . . . . . . . . . . . . . . 4 2. Concise SWID CDDL specification . . . . . . . . . . . . . . . 4
3. Encoding hashes for Concise SWID tags . . . . . . . . . . . . 8 3. Encoding hashes for Concise SWID tags . . . . . . . . . . . . 9
4. COSE signatures for Concise SWID tags . . . . . . . . . . . . 8 4. CoSWID used as Reference Integrity Measurements (CoSWID RIM) 9
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Firmware SWID tags . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. COSE signatures for Concise SWID tags . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. CBOR Web Token for Concise SWID tags . . . . . . . . . . . . 11
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
SWID tags have several use-applications including but not limited to: SWID tags have several use-applications including but not limited to:
o Software Inventory Management, a part of the Software Asset o Software Inventory Management, a part of the Software Asset
Management [SAM] process, which requires an accurate list of Management [SAM] process, which requires an accurate list of
discernible deployed software instances. discernible deployed software instances.
o Vulnerability Assessment, which requires a semantic link between o Vulnerability Assessment, which requires a semantic link between
standardized vulnerability descriptions and IT-assets [X.1520]. standardized vulnerability descriptions and IT-assets [X.1520].
o Remote Attestation, which requires a link between golden (well- o Remote Attestation, which requires a link between reference
known) measurements and software instances [I-D-birkholz-tuda]. integrity measurements (RIM) and security logs of measured
software components [I-D.birkholz-tuda].
SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a
standardized format for a record that identifies and describes a standardized format for a record that identifies and describes a
specific release of a software product. Different software products, specific release of a software product. Different software products,
and even different releases of a particular software product, each and even different releases of a particular software product, each
have a different SWID tag record associated with them. In addition have a different SWID tag record associated with them. In addition
to defining the format of these records, ISO-19770-2:2015 defines to defining the format of these records, ISO-19770-2:2015 defines
requirements concerning the SWID tag lifecycle. Specifically, when a requirements concerning the SWID tag lifecycle. Specifically, when a
software product is installed on an endpoint, that product's SWID tag software product is installed on an endpoint, that product's SWID tag
is also installed. Likewise, when the product is uninstalled or is also installed. Likewise, when the product is uninstalled or
skipping to change at page 4, line 5 skipping to change at page 4, line 5
SWID tags to be part of an enterprise security solution for a wider SWID tags to be part of an enterprise security solution for a wider
range of endpoints and environments. range of endpoints and environments.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 [RFC2119]. 2119, BCP 14 [RFC2119].
2. Concise SWID data definition 2. Concise SWID CDDL specification
The following is a CDDL representation of the ISO-19770-2:2015 [SWID] The following is a CDDL representation of the ISO-19770-2:2015 [SWID]
XML schema definition of SWID tags. This representation includes all XML schema definition of SWID tags. This representation includes all
SWID tag fields and thus supports all SWID tag use cases. The SWID tag fields and thus supports all SWID tag use cases. The
CamelCase notation used in the XML schema definition is changed to CamelCase notation used in the XML schema definition is changed to
hyphen-separated notation (e.g. ResourceCollection is named hyphen-separated notation (e.g. ResourceCollection is named
resource-collection in the Concise SWID data definition). The human- resource-collection in the COSWID CDDL specification). The human-
readable names of members are mapped to integer indices via a block readable names of members are mapped to integer indices via a block
of rules at the bottom of the Concise SWID data definition. The 48 of rules at the bottom of the CDDL specification. The 66 character
character strings of the SWID vocabulary that would have to be stored strings of the SWID vocabulary that would have to be stored or
or transported in full if using the original vocabulary are replaced. transported in full if using the original vocabulary are replaced.
concise-software-identity = { Concise Software Identifiers are tailored to be used in the domain of
global-attributes, constrained-node networks. A typical endpoint is capable of storing
? entity-entry, the CoSWID tag of installed software, a constrained-node might lack
? evidence-entry, that capability. CoSWID address these constraints and the
? link-entry, corresponding specification is augmented to retain their usefulness
? software-meta-entry, in the thing-2-thing domain. Specific examples include, but are not
? payload-entry, limited to limiting the scope of hash algorithms to the IANA Named
? any-element-entry, Information tables or including firmware attributes addressing
? corpus, devices that do not necessarily provide a file-system to store a
? patch, CoSWID tag in.
? media,
swid-name,
? supplemental,
tag-id,
? tag-version,
? version,
? version-scheme,
}
NMTOKEN = text <CODE BEGINS>
NMTOKENS = text concise-software-identity = {
global-attributes,
? entity-entry,
? evidence-entry,
? link-entry,
? software-meta-entry,
? payload-entry,
? any-element-entry,
? corpus,
? patch,
? media,
swid-name,
? supplemental,
tag-id,
? tag-version,
? version,
? version-scheme,
}
date-time = time NMTOKEN = text
any-uri = text NMTOKENS = text
label = text / int
any-attribute = ( date-time = time
label => text / int / [ 2* text ] / [ 2* int ] any-uri = text
) label = text / int
any-element-map = { any-attribute = (
global-attributes, label => text / int / [ 2* text ] / [ 2* int ]
* label => any-element-map / [ * any-element-map ], )
}
global-attributes = (
? lang,
* any-attribute,
)
resource-collection = ( any-element-map = {
? directory-entry, global-attributes,
? file-entry, * label => any-element-map / [ 2* any-element-map ],
? process-entry, }
? resource-entry
)
file = { global-attributes = (
filesystem-item, ? lang,
? size, * any-attribute,
? version, )
? file-hash,
}
filesystem-item = ( resource-collection = (
global-attributes, ? directory-entry,
? key, ? file-entry,
? location, ? process-entry,
fs-name, ? resource-entry
? root, ? firmware-entry
) )
directory = { file = {
filesystem-item, filesystem-item,
path-elements, ? size,
} ? version,
? file-hash,
}
process = { filesystem-item = (
global-attributes, global-attributes,
process-name, ? key,
? pid, ? location,
} fs-name,
? root,
)
resource = { directory = {
global-attributes, filesystem-item,
type, path-elements,
} }
entity = { firmware = {
global-attributes, firmware-name, ; inherited from RFC4108
meta-elements, ? firmware-version,
entity-name, ? firmware-package-identifier, ; inherited from RFC4108
? reg-id, ? dependency, ; inherited from RFC4108
role, ? component-index, ; equivalent to RFC4108 fwPkgType
? thumbprint, ? block-device-identifier,
} ? target-hardware-identifier, ; an RFC4108 alternative to model-label
model-label,
? firmware-hash, ; a hash for a single, incl. NI hash-algo index
? cms-firmware-package, ; RCF4108, experimental, this is an actual firmware blob!
}
evidence = { process = {
global-attributes, global-attributes,
resource-collection, process-name,
? date, ? pid,
? device-id, }
}
link = { resource = {
global-attributes, global-attributes,
? artifact, type,
href, }
? media,
? ownership,
rel,
? type,
? use,
}
software-meta = { entity = {
global-attributes, global-attributes,
? activation-status, meta-elements,
? channel-type, entity-name,
? colloquial-version, ? reg-id,
? description, role,
? edition, ? thumbprint,
? entitlement-data-required, }
? entitlement-key,
? generator,
? persistent-id,
? product,
? product-family,
? revision,
? summary,
? unspsc-code,
? unspsc-version,
}
payload = { evidence = {
global-attributes, global-attributes,
resource-collection, resource-collection,
} ? date,
? device-id,
}
tag-id = (0: text) link = {
swid-name = (1: text) global-attributes,
entity-entry = (2: entity / [ * entity ]) ? artifact,
evidence-entry = (3: evidence / [ * evidence ]) href,
link-entry = (4: link / [ * link ]) ? media,
software-meta-entry = (5: software-meta / [ * software-meta ]) ? ownership,
payload-entry = (6: payload / [ * payload ]) rel,
any-element-entry = (7: any-element-map / [ * any-element-map ]) ? type,
corpus = (8: bool) ? use,
patch = (9: bool) }
media = (10: text) software-meta = {
supplemental = (11: bool) global-attributes,
tag-version = (12: integer) ? activation-status,
version = (13: text) ? channel-type,
version-scheme = (14: NMTOKEN) ? colloquial-version,
lang = (15: text) ? description,
directory-entry = (16: directory / [ * directory ]) ? edition,
file-entry = (17: file / [ * file ]) ? entitlement-data-required,
process-entry = (18: process / [ * process ]) ? entitlement-key,
resource-entry = (19: resource / [ * resource ]) ? generator,
size = (20: integer) ? persistent-id,
key = (21: bool) ? product,
location = (22: text) ? product-family,
fs-name = (23: text) ? revision,
root = (24: text) ? summary,
path-elements = (25: { ? directory-entry, ? unspsc-code,
? file-entry, ? unspsc-version,
} }
)
process-name = (26: text) payload = {
pid = (27: integer) global-attributes,
type = (28: text) resource-collection,
meta-elements = (29: any-element-map / [ * any-element-map ]) }
entity-name = (30: text)
reg-id = (31: any-uri) tag-id = (0: text)
role = (32: NMTOKENS) swid-name = (1: text)
thumbprint = (33: text) entity-entry = (2: entity / [ 2* entity ])
date = (34: date-time) evidence-entry = (3: evidence / [ 2* evidence ])
device-id = (35: text) link-entry = (4: link / [ * link ])
artifact = (36: text) software-meta-entry = (5: software-meta / [ 2* software-meta ])
href = (37: any-uri) payload-entry = (6: payload / [ 2* payload ])
ownership = (38: "shared" / "private" / "abandon") any-element-entry = (7: any-element-map / [ 2* any-element-map ])
rel = (39: NMTOKEN) corpus = (8: bool)
use = (40: "optional" / "required" / "recommended") patch = (9: bool)
activation-status = (41: text) media = (10: text)
channel-type = (42: text) supplemental = (11: bool)
colloquial-version = (43: text) tag-version = (12: integer)
description = (44: text) version = (13: text)
edition = (45: text) version-scheme = (14: NMTOKEN)
entitlement-data-required = (46: bool) lang = (15: text)
entitlement-key = (47: text) directory-entry = (16: directory / [ 2* directory ])
generator = (48: text) file-entry = (17: file / [ 2* file ])
persistent-id = (49: text) process-entry = (18: process / [ 2* process ])
product = (50: text) resource-entry = (19: resource / [ 2* resource ])
product-family = (51: text) size = (20: integer)
revision = (52: text) key = (21: bool)
summary = (53: text) location = (22: text)
unspsc-code = (54: text) fs-name = (23: text)
unspsc-version = (55: text) root = (24: text)
file-hash = (56: [ hash-alg-id: int, path-elements = (25: { * directory-entry,
* file-entry,
}
)
process-name = (26: text)
pid = (27: integer)
type = (28: text)
meta-elements = (29: any-element-map / [ 2* any-element-map ])
entity-name = (30: text)
reg-id = (31: any-uri)
role = (32: NMTOKENS)
thumbprint = (33: text)
date = (34: date-time)
device-id = (35: text)
artifact = (36: text)
href = (37: any-uri)
ownership = (38: "shared" / "private" / "abandon")
rel = (39: NMTOKEN)
use = (40: "optional" / "required" / "recommended")
activation-status = (41: text)
channel-type = (42: text)
colloquial-version = (43: text)
description = (44: text)
edition = (45: text)
entitlement-data-required = (46: bool)
entitlement-key = (47: text)
generator = (48: text)
persistent-id = (49: text)
product = (50: text)
product-family = (51: text)
revision = (52: text)
summary = (53: text)
unspsc-code = (54: text)
unspsc-version = (55: text)
file-hash = (56: [ hash-alg-id: int,
hash-value: bstr,
]
)
firmware-entry = (57: firmware / [ 2* firmware ])
firmware-hash = (58: [ hash-alg-id: int,
hash-value: bstr, hash-value: bstr,
] ]
) )
firmware-name = (59 : text)
firmware-version = (60 : text / int)
component-index = (61 : int)
model-label = (62: text / int)
block-device-identifier = (63 : text / int)
cms-firmware-package = (64: bstr)
firmware-package-identifier = (65: text)
target-hardware-identifier = (66: text)
dependency = (67: { ? firmware-name,
? firmware-version,
? firmware-package-identifier,
}
)
<CODE ENDS>
3. Encoding hashes for Concise SWID tags 3. Encoding hashes for Concise SWID tags
Concise SWID add explicit support for the representation of file- Concise SWID add explicit support for the representation of file-
hashes using algorithms that are registered at the Named Information hashes using algorithms that are registered at the Named Information
Hash Algorithm Registry via the file-hash item (label 56). The Hash Algorithm Registry via the file-hash item (label 56). The
number used as a value for hash-alg-id refers the ID in the Named number used as a value for hash-alg-id refers the ID in the Named
Information Hash Algorithm table. Information Hash Algorithm table.
4. COSE signatures for Concise SWID tags 4. CoSWID used as Reference Integrity Measurements (CoSWID RIM)
A vendor supplied signed CoSWID tag that includes hash-values for the
files that compose a software component can be used as a RIM
(reference integrity measurement). A RIM is a type of declarative
guidance that can be used to assert the compliance of an endpoint by
assessing the installed software. In the context of remote
attestation based on an attestation via a hardware security module
(hardware rooted trust), a verifier can appraise the integrity of the
conveyed measurements of software components using a CoSWID RIM
provided by a source, such as
[I-D.banghart-sacm-rolie-softwaredescriptor].
5. Firmware SWID tags
The metadata defined in [RFC4108] is incorporated in the resource-
collection structure that semantically differentiates content stored
in a Concise Software Identifier. The optional attributes that
annoate a firmware package addresse specific characteristics of
pieces of firmware stored directly on a block-device in contrast to
software deployed in a file-system. Trees of relative path-elements
expressed by the directory and file structure in CoSWID tags are
typically unable to represent the location of a firmware on a
constrained-node (small thing). The composite nature of firmware and
also the actual composition of small things require a set of
attributes to identify the correct component in a composite thing for
each individual piece of firmware. A single component also
potentially requires a number of distinct firmware parts that might
depend on each other(s version). These dependencies can be limited
to the scope of the component itself or extend to the scope of a
small composite device. In addition, it might not be possible (or
feasible) to store a CoSWID tag document (permanently) on a small
thing along with the corresponding piece of firmware. Hence, CoSWID
tags can be used as a concise and flexible metadata document that
functions as a wrapper containing a (potentially compressed, signed,
and/or encrypted) piece of firmware and its corresponding CoSWID
attributes. A CoSWID tag about firmware can be transmitted as an
identifying document across endpoints or used as an reference
integrity measurement as usual. Alternatively, it can also convey an
actual piece of firmware, serve its intended purpose as a SWID tag
and then - due to the lack of a location to store it - be discarded.
6. COSE signatures for Concise SWID tags
SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include
cryptographic signatures to protect the integrity of the SWID tag. cryptographic signatures to protect the integrity of the SWID tag.
In general, tags are signed by the tag creator (typically, although In general, tags are signed by the tag creator (typically, although
not exclusively, the vendor of the software product that the SWID tag not exclusively, the vendor of the software product that the SWID tag
identifies). Cryptographic signatures can make any modification of identifies). Cryptographic signatures can make any modification of
the tag detectable, which is especially important if the integrity of the tag detectable, which is especially important if the integrity of
the tag is important, such as when the tag is providing golden the tag is important, such as when the tag is providing golden
measurements for files. measurements for files.
The ISO-19770-2:2015 XML schema uses XML DSIG to support The ISO-19770-2:2015 XML schema uses XML DSIG to support
cryptographic signatures. Concise SWID tags require a different cryptographic signatures. Concise SWID tags require a different
signature scheme than this. COSE (CBOR Encoded Message Syntax) signature scheme than this. COSE (CBOR Encoded Message Syntax)
provides the required mechanism [I-D.ietf-cose-msg]. Concise SWID provides the required mechanism [I-D.ietf-cose-msg]. Concise SWID
can be wrapped in a COSE Single Signer Data Object (cose-sign1) that can be wrapped in a COSE Single Signer Data Object (cose-sign1) that
contains a single signature. The following CDDL defines a more contains a single signature. The following CDDL defines a more
restrictive subset of header attributes allowed by COSE tailored to restrictive subset of header attributes allowed by COSE tailored to
suit the requirements of Concise SWID. suit the requirements of Concise SWID.
signed-software-identity = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D <CODE BEGINS>
signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D
label = int / tstr ; see COSE I-D 1.4. label = int / tstr ; see COSE I-D 1.4.
values = any ; see COSE I-D 1.4. values = any ; see COSE I-D 1.4.
unprotected-signed-coswid-header = { unprotected-signed-coswid-header = {
1 => int, ; algorithm identifier 1 => int, ; algorithm identifier
3 => "application/coswid", ; request for CoAP IANA registry to become an int 3 => "application/coswid", ; request for CoAP IANA registry to become an int
* label => values, * label => values,
} }
skipping to change at page 9, line 27 skipping to change at page 11, line 28
4 => bstr, ; key identifier 4 => bstr, ; key identifier
* label => values, * label => values,
} }
COSE-Sign1-coswid = [ COSE-Sign1-coswid = [
protected: bstr .cbor protected-signed-coswid-header, protected: bstr .cbor protected-signed-coswid-header,
unprotected: unprotected-signed-coswid-header, unprotected: unprotected-signed-coswid-header,
payload: bstr .cbor concise-software-identity, payload: bstr .cbor concise-software-identity,
signature: bstr, signature: bstr,
] ]
<CODE ENDS>
5. IANA considerations 7. CBOR Web Token for Concise SWID tags
A typical requirement regarding specific instantiations of endpoints
- and, as a result, specific instantiations of software components -
is a representation of the absolute path of a CoSWID tag document in
a file system in order to derive absolute paths of files represented
in the corresponding CoSWID tag. The absolute path of an evidence
CoSWID tag can be included as a claim in the header of a CBOR Web
Token [I-D.ietf-ace-cbor-web-token]. Depending on the source of the
token, the claim can be in the protected or unprotected header
portion.
<CODE BEGINS>
CDDL TBD
<CODE ENDS>
8. IANA considerations
This document will include requests to IANA: This document will include requests to IANA:
o Integer indices for SWID content attributes and information o Integer indices for SWID content attributes and information
elements. elements.
o Content-Type for CoAP to be used in COSE. o Content-Type for CoAP to be used in COSE.
6. Security Considerations 9. Security Considerations
SWID tags contain public information about software products and, as SWID tags contain public information about software products and, as
such, do not need to be protected against disclosure on an endpoint. such, do not need to be protected against disclosure on an endpoint.
Similarly, SWID tags are intended to be easily discoverable by Similarly, SWID tags are intended to be easily discoverable by
applications and users on an endpoint in order to make it easy to applications and users on an endpoint in order to make it easy to
identify and collect all of an endpoint's SWID tags. As such, any identify and collect all of an endpoint's SWID tags. As such, any
security considerations regarding SWID tags focus on the application security considerations regarding SWID tags focus on the application
of SWID tags to address security challenges, and the possible of SWID tags to address security challenges, and the possible
disclosure of the results of those applications. disclosure of the results of those applications.
skipping to change at page 11, line 11 skipping to change at page 13, line 28
Concise SWID data definition allow for the construction of "infinite" Concise SWID data definition allow for the construction of "infinite"
SWID tags or SWID tags that contain malicious content with the intend SWID tags or SWID tags that contain malicious content with the intend
if creating non-deterministic states during validation or processing if creating non-deterministic states during validation or processing
of SWID tags. While software product vendors are unlikely to do of SWID tags. While software product vendors are unlikely to do
this, SWID tags can be created by any party and the SWID tags this, SWID tags can be created by any party and the SWID tags
collected from an endpoint could contain a mixture of vendor and non- collected from an endpoint could contain a mixture of vendor and non-
vendor created tags. For this reason, tools that consume SWID tags vendor created tags. For this reason, tools that consume SWID tags
ought to treat the tag contents as potentially malicious and should ought to treat the tag contents as potentially malicious and should
employ input sanitizing on the tags they ingest. employ input sanitizing on the tags they ingest.
7. Acknowledgements 10. Acknowledgements
8. Change Log 11. Change Log
Changes from version 00 to version 01:
o Added CWT usage for absolute SWID paths on a device
o Fixed cardinality of type-choices including arrays
o Included first iteration of firmware resource-collection
Changes since adopted as a WG I-D -00: Changes since adopted as a WG I-D -00:
o Removed redundant any-attributes originating from the ISO- o Removed redundant any-attributes originating from the ISO-
19770-2:2015 XML schema definition 19770-2:2015 XML schema definition
o Fixed broken multi-map members o Fixed broken multi-map members
o Introduced a more restrictive item (any-element-map) to represent o Introduced a more restrictive item (any-element-map) to represent
custom maps, increased restriction on types for the any-attribute, custom maps, increased restriction on types for the any-attribute,
skipping to change at page 11, line 46 skipping to change at page 14, line 22
explicit members (while still allowing for "empty" swid tags) explicit members (while still allowing for "empty" swid tags)
o Added a relatively restrictive COSE envelope using cose_sign1 to o Added a relatively restrictive COSE envelope using cose_sign1 to
define signed coswids (single signer only, at the moment) define signed coswids (single signer only, at the moment)
o Added a defintion how to encode hashes that can be stored in the o Added a defintion how to encode hashes that can be stored in the
any-member using existing IANA tables to reference hash-algorithms any-member using existing IANA tables to reference hash-algorithms
First version -00 First version -00
9. Contributors 12. Contributors
10. References
10.1. Normative References 13. References
13.1. Normative References
[I-D.ietf-ace-cbor-web-token]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-02
(work in progress), January 2017.
[I-D.ietf-cose-msg] [I-D.ietf-cose-msg]
Schaad, J., "CBOR Object Signing and Encryption (COSE)", Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016. draft-ietf-cose-msg-24 (work in progress), November 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005,
<http://www.rfc-editor.org/info/rfc4108>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[SAM] "Information technology - Software asset management - Part [SAM] "Information technology - Software asset management - Part
5: Overview and vocabulary", ISO/IEC 19770-5:2013, 5: Overview and vocabulary", ISO/IEC 19770-5:2013,
November 2013. November 2013.
[SWID] "Information technology - Software asset management - Part [SWID] "Information technology - Software asset management - Part
2: Software identification tag'", ISO/IEC 19770-2:2015, 2: Software identification tag'", ISO/IEC 19770-2:2015,
October 2015. October 2015.
[X.1520] "Recommendation ITU-T X.1520 (2014), Common [X.1520] "Recommendation ITU-T X.1520 (2014), Common
vulnerabilities and exposures", April 2011. vulnerabilities and exposures", April 2011.
10.2. Informative References 13.2. Informative References
[I-D-birkholz-tuda] [I-D.banghart-sacm-rolie-softwaredescriptor]
Waltermire, D. and S. Banghart, "Definition of the ROLIE
Software Descriptor Extension", draft-banghart-sacm-rolie-
softwaredescriptor-00 (work in progress), October 2016.
[I-D.birkholz-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
tuda-03 (work in progress), January 2017. tuda-03 (work in progress), January 2017.
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language Vigano, C. and H. Birkholz, "CBOR data definition language
(CDDL): a notational convention to express CBOR data (CDDL): a notational convention to express CBOR data
structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work
in progress), September 2016. in progress), September 2016.
 End of changes. 40 change blocks. 
209 lines changed or deleted 344 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/