idnits 2.17.1 draft-birkholz-rats-coswid-rim-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 860 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-15 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track P. Uiterwijk 5 Expires: January 14, 2021 Red Hat 6 N. Smith 7 Intel 8 J. Fitzgerald-McKay 9 Department of Defense 10 D. Waltermire 11 NIST 12 S. Bhandari 13 Cisco 14 July 13, 2020 16 Reference Integrity Measurement Extension for Concise Software 17 Identities 18 draft-birkholz-rats-coswid-rim-01 20 Abstract 22 Concise Software Identification (CoSWID) tags identify and describe 23 individual software components, patches, and installation bundles. 24 CoSWID is based on ISO/IEC 19770-2:2015 2:2015 that provides a 25 complementary XML schema definition (XSD) for Software Identification 26 (SWID) tags. CoSWID supports the same features as the corresponding 27 XML SWID tags. The CoSWID specification also includes more 28 structured extensibility features and reduces a few of ambiguities 29 that are not explicitly resolved in the ISO XSD. In this document, 30 these extensibility features (extension points) are used to add 31 attributes to the CoSWID specification. The new attributes allow for 32 the use of CoSWID as Reference Integrity Measurements (RIM). There 33 are four sets of RIM features defined in this specification. 1.) 34 attributes that support RIM manifests for Measured Boot, 2.) 35 attributes that support package manager managed structures, 3.) 36 attributes that allow for OID to be used in the description of 37 Reference Integrity Measurements, and 4.) attributes for object trees 38 in support of Target Environments that are chained via Layered 39 Attestation. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 14, 2021. 58 Copyright Notice 60 Copyright (c) 2020 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 77 2. CoSWID Attribute Extensions . . . . . . . . . . . . . . . . . 5 78 2.1. RIM requirements on existing CoSWID attributes . . . . . 5 79 2.2. RIM Extensions for Measured Boot . . . . . . . . . . . . 5 80 2.3. RIM Extensions for Software Package Management . . . . . 11 81 2.4. RIM Extensions for Composite Device . . . . . . . . . . . 12 82 2.4.1. The tcb-info Group . . . . . . . . . . . . . . . . . 12 83 2.4.2. CoSWID Version Scheme for RPM . . . . . . . . . . . . 14 84 2.5. Additional Measurement Attributes for CoSWID . . . . . . 14 85 2.6. CoSWID RIM CDDL . . . . . . . . . . . . . . . . . . . . . 14 86 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 6.2. Informative References . . . . . . . . . . . . . . . . . 18 92 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 Reference Integrity Measurements describe the intended state of 98 (composite) software components installed on a (composite) device. A 99 measurement of all installed software components of a devices allows 100 for assertions about the trustworthiness of the given device. In 101 combination with a root of trust (RoT) for reporting (RTR), these 102 measurements can be refined into evidence and enable IETF Remote 103 ATtestation procedureS (RATS). RATS support the decision process of 104 whether to put trust in the trustworthiness of a device - or not. 106 The RATS architecture [I-D.ietf-rats-architecture] defines the roles 107 Verifiers, Attesters, Endorsers, and Relying Parties. The RATS 108 architecture also specifies that Attestation Evidence is created by 109 Attesters and consumed by Verifiers. Ultimately, the goal is to 110 enable a Relying Party to put trust in the trustworthiness of a 111 remote peer (the Attester). Attestation Evidence is composed of 112 believable assertions about an Attester's trustworthiness 113 characteristics. In RATS, these assertions are called Claims. The 114 Verifier conducts a set of appraisal procedures in order to assess 115 the compliance of an Attester's trustworthiness characteristics. 117 A prominent appraisal procedure in RATS is the comparison of Claim 118 values included in Attestation Evidence with Reference Claim values 119 provided by Endorsers (e.g. supply chain entities). The comparison 120 of Claim values via Reference Claim values is vital for the 121 assessment of compliance metrics with respect to software components 122 installed on an Attester. A typical objective here is the 123 remediation of already vulnerabilities discovered in certain versions 124 of software components. 126 The Integrity Measurement Architecture (IMA) of the Linux Security 127 Modules (LSM) provides a detailed Event Log (sometimes also referred 128 to as a Measurement Log) that retains a sequence of hash measurements 129 of every software sub-component (e.g. a firmware, an ELF executable, 130 or a configuration file) that is created and appended to the sequence 131 of measurements that composes the event log before the software 132 component in question is started or read. 134 In essence, to enable this appraisal procedure conducted by Verfiers 135 an Attester's IMA provides Event Logs that include the hash values of 136 every started software component and therefore are part of the 137 Attestation Evidence an Attester creates. The complementary well- 138 known-values that Verifiers require are included in the Reference 139 Integrity Measurements (RIM). RIMs can be provided via Software 140 Identification tags created by Endorsers, such as the software 141 creators, manufacturers, vendors, or other trusted third parties 142 (e.g. supply chain or certification entities). 144 This document provides an extension to the CoSWID specification 145 defined in [I-D.ietf-sacm-coswid]. The extension adds attributes to 146 CoSWID tags that enable them to express RIMs. One prominent subset 147 of these attributes are illustrated in the TCG Reference Integrity 148 Manifest Information Model [ref] specification. These attributes are 149 added to the existing CoSWID specification via the most general 150 extension point the CoSWID specification provides: $$coswid- 151 extensions. An additional map definition named "reference- 152 measurements" is added and is defined in section [ref] of this 153 document. Another prominent subset is the addition of an object tree 154 next to the file system tree as defined by [I-D.ietf-sacm-coswid]. 155 The object tree enables the representation of multiple layered 156 execution environments as described by the Layered Attestation 157 concept in the RATS architecture [I-D.ietf-rats-architecture]. 159 Furthermore, a usage profile for signed CoSWID tags is defined in 160 this specification in support of the software-component structure of 161 systems managed by package managers. Signed CoSWID tags that are 162 aligned with that software model can be used to describe the contents 163 of one or multiple of the packages that make up the contents of a 164 system. In this case, it may be that multiple CoSWID tags are 165 provided as Reference Claim values for a attestation by a single 166 Attester. In order to minimize the impact on the sizes of packages, 167 it is likely that any CoSWID tags delivered as part of packages as 168 part of a package manager managed system will not contain actual 169 reference values, but instead a link-entry to a CoSWID tag published 170 by the vendor in a repository. 172 Reference Integrity Measurements are a subset of the Conceptual 173 Messages defined as Endorsements. RIMs provide a vital resource to 174 be consumed by Verifiers in conjunction with Appraisal Policies and 175 Evidence. While RIMs represent nominal values, Appraisal Policies 176 represent imperative guidance how to use nominal values in an 177 appraisal procedure. Evidence represents assertions about the 178 trustworthiness of a device's Target Environments created by its own 179 Attesting Environment. As Evidence can be rather complex and its 180 appraisal therefore a burden for Relying Parties that are interested 181 in trustworthiness evaluations, Verifies take on this duty and create 182 easier to digest Attestation Results for Relying Parties. In 183 consequence, Verifiers are the entities that have to put trust in the 184 provenance and integrity of RIMs - and Endorsements in general - 185 relying on proof of integrity and authenticity. 187 1.1. Requirements Notation 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 2. CoSWID Attribute Extensions 197 This specification defines four types of attribute sets that can be 198 added to the CoSWID specification via its defined extension points. 200 1. Attributes that support RIM manifests for Measured Boot (often 201 referred to as Secure Boot), 203 2. Attributes that support the RPM package manager structure, 205 3. Attributes that allow to represent composite devices including 206 several Target Environments, and 208 4. Attributes that allow for OID to be used in the description of 209 Reference Integrity Measurements. 211 2.1. RIM requirements on existing CoSWID attributes 213 As defined by NIST IR 8060 [ref], there are required "Meta 214 Attributes" for XML SWID tags that have to be included in a SWID tag 215 in order to compose a valid SWID RIM. In this section, these 216 attributes are mapped to CoSWID attributes and corresponding 217 requirements on attributes defined in the CoSWID specification to 218 compose valid NIST IR 8060 signed Payload content in the Concise 219 Software Identity Reference Integrity Measurement (CoSWID RIM) 220 representation. 222 The 'software-meta-entry' type defined in the CoSWID specification 223 includes the optional members 'product', 'colloquial-version', 224 'revision', and 'edition'. These four members MUST be included in a 225 CoSWID RIM in order to compose a valid Reference Integrity 226 Measurement in alignment with NIST IR 8060. Furthermore, the 227 semantics of the text (tstr) typed values MUST convey content that 228 allows for semantic interoperability in a given scope (e.g., an 229 administrative domain). The software-meta-entries provide vital 230 support for steering decisions made by the RATS verifier role in 231 order to enable discovery and matching of related or additional 232 CoSWID RIM available to or discoverable by the verifier. 234 2.2. RIM Extensions for Measured Boot 236 The following attributes are derived from the TCG Reference Integrity 237 Manifest Information Model [ref] specification. These attributes 238 support the creation of very small CoSWID RIM tags that enable the 239 Remote Integrity Verification (RIV 241 [I-D.fedorkow-rats-network-device-attestation]) of small things, 242 i.e., constrained devices in constrained network environments. In 243 consequence, the majority of the attributes listed in this section 244 represent metadata about firmware and supply chain entities that 245 provide firmware for a device (platform). Analogously to the 246 mandated software-meta-entries illustrated above, the attributes 247 defined in the table below provide more context and enable steering 248 decisions for the appraisal procedures of a Verifier. Consecutively, 249 RIM have to be managed and curated in a consistent manner so that 250 there is no significant threshold for a Verifier to make use of them 251 during an appraisal procedure. 253 The design of the additional RIM attributes in this section is 254 motivated by the vast variety of identifier types used in production 255 today, e.g. endorsement documents [I-D.ietf-rats-architecture] that 256 are enrolled or on-boarded on the Attester itself. It is vital to 257 highlight that this variety can render semantic self-descriptiveness 258 more difficult. Most importantly though: interoperability beats 259 self-descriptiveness. A convergence towards a common identification 260 scheme with respect to software components and its subset that is 261 firmware is highly encouraged - alas not achieved at the time of 262 creating this proposed standard. The following table defines the 263 semantics of the set of new members that are added via the reference- 264 measurement-entry map. The reference-measurement-entry map is added 265 using the $$coswid-extension CDDL extension point. 267 +--------------------------------+----------+-----------------------+ 268 | Attribute Name | Quantity | Description | 269 +--------------------------------+----------+-----------------------+ 270 | payload-type | 0-1 | The value of this | 271 | | | attribute MUST be one | 272 | | | equivalent of the | 273 | | | following three | 274 | | | choices. 'direct': | 275 | | | the representation | 276 | | | used in this RIM (and | 277 | | | referred RIMs) is | 278 | | | using the CoSWID | 279 | | | encoding as its | 280 | | | representation. | 281 | | | 'indirect': the | 282 | | | representation used | 283 | | | in referred RIMs | 284 | | | ('Support RIMs) is | 285 | | | using a different | 286 | | | representation than | 287 | | | CoSWID as it's | 288 | | | encoding. | 289 | | | Analogously, a | 290 | | | reference to the | 291 | | | corresponding | 292 | | | specification MUST be | 293 | | | provided if the value | 294 | | | is set to an | 295 | | | equivalent of | 296 | | | 'indirect' (see | 297 | | | binding-spec-name and | 298 | | | binding-spec- | 299 | | | version). 'hybrid': | 300 | | | the representation | 301 | | | used in the referred | 302 | | | RIMs ('Support RIMs') | 303 | | | is a mix of CoSWID | 304 | | | representations and | 305 | | | other | 306 | | | representations. In | 307 | | | this case, a | 308 | | | reference to the | 309 | | | representation used | 310 | | | MUST be included - | 311 | | | even if it is the | 312 | | | CoSWID representation | 313 | | | - for every Support | 314 | | | RIM (see 'binding- | 315 | | | spec-name' and | 316 | | | 'binding-spec- | 317 | | | version' definition | 318 | | | in this table). | 319 | | | | 320 | platform-configuration-uri- | 0-1 | A byte-comparable | 321 | global | | reference to a | 322 | | | Platform | 323 | | | Configuration URI as | 324 | | | defined by the TCG | 325 | | | Platform Certificate | 326 | | | Profile [ref TCG | 327 | | | Platform Certificate | 328 | | | Profile, Version 1.1] | 329 | | | for X.509v3 | 330 | | | certificates that | 331 | | | MUST be identical to | 332 | | | the URI included in a | 333 | | | TCG Platform | 334 | | | Certificate pointing | 335 | | | to a resource | 336 | | | providing a copy of | 337 | | | the CoSWID RIM this | 338 | | | attribute is included | 339 | | | in. | 340 | | | | 341 | platform-configuration-uri- | 0-1 | A byte-comparable | 342 | local | | reference to a | 343 | | | Platform | 344 | | | Configuration URI | 345 | | | defined by the TCG | 346 | | | Platform Certificate | 347 | | | Profile [ref TCG | 348 | | | Platform Certificate | 349 | | | Profile, Version 1.1] | 350 | | | that MUST represent | 351 | | | the resource at which | 352 | | | a copy of this CoSWID | 353 | | | RIM can be found | 354 | | | within the | 355 | | | (composite) | 356 | | | device/platform | 357 | | | itself. | 358 | | | | 359 | binding-spec-name | 1 | If the value of | 360 | | | 'payload-type' is an | 361 | | | equivalent to the | 362 | | | enumeration | 363 | | | 'indirect', the value | 364 | | | of this attribute | 365 | | | MUST contain a global | 366 | | | unique text (tstr) | 367 | | | identifier referring | 368 | | | to the specification | 369 | | | that defines the | 370 | | | representation of the | 371 | | | referred RIM in order | 372 | | | to enable its | 373 | | | decoding. | 374 | | | | 375 | binding-spec-version | 1 | If the value of | 376 | | | 'payload-type' is an | 377 | | | equivalent to the | 378 | | | enumeration | 379 | | | 'indirect', the value | 380 | | | of this attribute | 381 | | | MUST contain a unique | 382 | | | version number with | 383 | | | respect to the | 384 | | | specification | 385 | | | represented in the | 386 | | | value of 'binding- | 387 | | | spec-name'. | 388 | | | | 389 | platform-manufacturer-id | 0-1 | An identifier based | 390 | | | on the IANA Private | 391 | | | Enterprise Number | 392 | | | registry that is | 393 | | | assigned to firmware | 394 | | | manufacturer. This | 395 | | | identifier MUST be | 396 | | | included unless the | 397 | | | firmware manufacturer | 398 | | | and the platform | 399 | | | manufacturer are | 400 | | | represented by the | 401 | | | same text (tstr) | 402 | | | value. Analogously, | 403 | | | if the firmware | 404 | | | manufacturer and the | 405 | | | platform manufacturer | 406 | | | are represented via | 407 | | | the same text (tstr) | 408 | | | value, this attribute | 409 | | | MAY be omitted. | 410 | | | | 411 | platform-manufacturer-name | 0-1 | An identifier number | 412 | | | (uint) value that | 413 | | | uniquely represents | 414 | | | the firmware | 415 | | | manufacturer. This | 416 | | | identifier MUST be | 417 | | | included unless the | 418 | | | firmware manufacturer | 419 | | | and the platform | 420 | | | manufacturer are | 421 | | | represented via the | 422 | | | same number (unit) | 423 | | | value, this attribute | 424 | | | MAY be omitted. | 425 | | | | 426 | platform-model-name | 1 | An identifier text | 427 | | | (tstr) value enabling | 428 | | | the identification of | 429 | | | a certain device | 430 | | | model/type composite. | 431 | | | The reliability of | 432 | | | this identifier is | 433 | | | not absolute. In | 434 | | | consequence this | 435 | | | identifier MUST NOT | 436 | | | be omitted. In an | 437 | | | case, the use of this | 438 | | | identifier requires | 439 | | | foresight and | 440 | | | preparation as it's | 441 | | | purpose supports | 442 | | | semantic | 443 | | | interoperability. | 444 | | | Arbitrary, | 445 | | | conflicting, or | 446 | | | unresolvable values | 447 | | | SHOULD be avoided. | 448 | | | | 449 | platform-version | 0-1 | A byte-comparable | 450 | | | reference to a | 451 | | | Platform | 452 | | | Certificate's | 453 | | | 'Manufacturer- | 454 | | | Specific Identifier' | 455 | | | extension value [ref | 456 | | | TCG Platform | 457 | | | Certificate Profile, | 458 | | | Version 1.1]. | 459 | | | | 460 | firmware-manufacturer-id | 0-1 | An IANA defined | 461 | | | unique value that is | 462 | | | a Private Enterprise | 463 | | | Number (Platform | 464 | | | manufacturer unique | 465 | | | identifier) that | 466 | | | SHOULD be included in | 467 | | | a CoSWID RIM that | 468 | | | covers firmware. | 469 | | | | 470 | firmware-manufacturer-name | 0-1 | An identifier that is | 471 | | | represented as the | 472 | | | name of a platform | 473 | | | manufacturer via a | 474 | | | text (tstr) value | 475 | | | that SHOULD be | 476 | | | included in a CoSWID | 477 | | | RIM that covers | 478 | | | firmware. | 479 | | | | 480 | firmware-model-name | 0-1 | An identifier that | 481 | | | represents the target | 482 | | | platform model via a | 483 | | | text (tstr) value | 484 | | | that SHOULD be | 485 | | | included in a CoSWID | 486 | | | RIM. | 487 | | | | 488 | firmware-version | 0-1 | An identifier that is | 489 | | | represented as the | 490 | | | version number of a | 491 | | | specific firmware | 492 | | | version corresponding | 493 | | | to a given set of | 494 | | | platform identifiers | 495 | | | and SHOULD be | 496 | | | included in a CoSWID | 497 | | | RIM. | 498 | | | | 499 | boot-events | 0-1 | A reference to the | 500 | | | platform measured | 501 | | | boot event logs that | 502 | | | can be compared to | 503 | | | individual events | 504 | | | from the platform | 505 | | | measured boot events | 506 | | | collected at platform | 507 | | | runtime. | 508 +--------------------------------+----------+-----------------------+ 510 2.3. RIM Extensions for Software Package Management 512 To enable very small CoSWID tags that basically are signed references 513 to full Base RIMs for each software package that ultimately include 514 all the hash values required by the appraisal procedure of a 515 Verifier, the member rim-reference is added using the $$payload- 516 extension CDDL extension point. 518 +---------------+----------+----------------------------------------+ 519 | Attribute | Quantity | Description | 520 | Name | | | 521 +---------------+----------+----------------------------------------+ 522 | rim-reference | 0-1 | A URI pointing to the CoSWID Base RIM | 523 | | | that will list the payload reference | 524 | | | measurements (hashes) in case of a | 525 | | | minimal CoSWID tag. | 526 +---------------+----------+----------------------------------------+ 528 2.4. RIM Extensions for Composite Device 530 Attesters that are composite devices can include several Target 531 Environments. Some of these Target Environments can take on the 532 duties of Attesting Environments during a boot sequence as described 533 in section 4.3. of the RATS architecture 534 [I-D.ietf-rats-architecture]. The corresponding procedure is called 535 Layered Attestation and requires a dedicated RIM for each Target 536 Environment of the Attester. The addition of object tree attributes 537 to CoSWID using the $$resource-collection-extension extension point 538 addresses the resulting requirements. 540 Each Target Environment involved in Layered Attestation can be 541 considered its own Trusted Computing Base (TCB) [ref]. TCB metadata 542 can be used to identify or locate RIMs. The addition of TCB 543 information to the new object tree structure is in support of these 544 identifiers for RIM discovery. 546 Additionally, software components started in these Target 547 Environments might not be referenceable via a filesystem (e.g., in 548 the case of firmware). To enable RIMs to represent firmware items 549 that are not associated with a filesystem, attributes for object 550 trees are added to the existing filesystem items tree. 552 2.4.1. The tcb-info Group 554 Every object in the object tree can be represented with a set of 555 metadata items pertaining a specific TCB. The following items can be 556 associated with a dedicate object-entry: 558 +-----------------------+----------+--------------------------------+ 559 | Attribute Name | Quantity | Description | 560 +-----------------------+----------+--------------------------------+ 561 | tcb-info.id | 1 | A hash of the tcb-info.key- | 562 | | | elements value including the | 563 | | | map structure | 564 | | | | 565 | tcb-info.key-elements | 1 | A collection of attributes | 566 | | | that disambiguates the various | 567 | | | TCB objects in a composite | 568 | | | device scope | 569 | | | | 570 | tcb-info.vendor | 1 | The entity that named the | 571 | | | measurement of the Target | 572 | | | Environment TCB referenced by | 573 | | | an object-entry | 574 | | | | 575 | tcb-info.model | 0-1 | The product name associated | 576 | | | with the object-entry in a | 577 | | | measurement | 578 | | | | 579 | tcb-info.layer | 0-1 | The layer in the composite | 580 | | | devive (and therefore object | 581 | | | tree) of the TCB associated | 582 | | | with the object-entry in a | 583 | | | measurement | 584 | | | | 585 | tcb-info.index | 0-1 | An index that enumerates | 586 | | | TCB/object-entries in a CoSWID | 587 | | | RIM tag | 588 | | | | 589 | tcb-info.type | 1 | A machine-readable description | 590 | | | of the measurement | 591 | | | | 592 | tcb-info.version | 0-1 | A revision string associated | 593 | | | with the measurement and a | 594 | | | reference value | 595 | | | | 596 | tcb-info.SVN | 0-1 | The security version number | 597 | | | associated with the | 598 | | | measurement and a reference | 599 | | | value | 600 | | | | 601 | tcb-info.flags | 0-1 | Operational states associated | 602 | | | with a TCB or composite device | 603 | | | that affects the object being | 604 | | | measured. If omitted, the TCB | 605 | | | or omposite device is not | 606 | | | capable of entering this | 607 | | | state. Valid states are: not- | 608 | | | configured, not-secure, | 609 | | | recovery, debug. | 610 | | | | 611 | tcb-info.fwids | 0-1 | A list of digests resulting | 612 | | | from applying the hash | 613 | | | algorithm over the object | 614 | | | being measured | 615 | | | | 616 | tcb-info.vendorinfo | 0-1 | Actual values or state that is | 617 | | | associated with a TVB element | 618 | | | | 619 | tcb-info.vendormask | 0-1 | A mask that allows a Verifier | 620 | | | to ignore a subset of | 621 | | | collected tcb-info.vendorinfo | 622 | | | values that the Endorser | 623 | | | asserts are not security | 624 | | | relevant | 625 +-----------------------+----------+--------------------------------+ 627 2.4.2. CoSWID Version Scheme for RPM 629 To enable encoding version information into a CoSWID of RPM packages, 630 the SWID version scheme value index TBD1 has been registered. RPM 631 versions are defined as epoch:version-release-architecture, where the 632 "epoch:" component is optional. Epoch is a numerical value, which 633 should be considered zero if the epoch component is missing. Version 634 and Release can be any string as long as they do not contain a hyphen 635 (-). Architecture is an alphanumerical string. 637 Sorting of RPM versions is a multi-step process: - The epoch, version 638 and release components are compared in that order, as soon as a 639 difference is found, that is the overall difference. - The epoch 640 component is compared as integers. A higher number means a higher 641 version. - The version and release components are compared 642 alphabetically, until a digit is encountered in both strings, at 643 which point as many digits are consumed from both to form an integer, 644 which is then compared. If the integers are identical, the 645 comparison continues alphabetically. - The architecture component is 646 never sorted. If they are different between two versions, the 647 versions are inequal, not higher or lower. 649 2.5. Additional Measurement Attributes for CoSWID 651 [I-D.ietf-sacm-coswid] specifies a well-defined file hash structure 652 for integrity measurements of individual files in a file-system. 653 This documents extends this feature to all additional members of the 654 resource-collection group: 'directory', 'resource', and 'process'. 655 These new well-defined measurement options extend the scope of RIM to 656 (sub-)trees of files, software running in memory (e.g. available from 657 Trusted Execution Environments, such as SGX enclaves), and even 658 external resources, such as remote services of collections of RIM 659 bundles. 661 2.6. CoSWID RIM CDDL 663 The following CDDL specification uses the existing CDDL extension 664 points as defined in [I-D.ietf-sacm-coswid]: 666 o $$coswid-extension 668 o $$payload-extension 670 o $$directory-extension 671 o $$resource-extension 673 o $$process-extension 675 o $$link-extension 677 o $$resource-collection-extension 679 680 $$coswid-extension //= (reference-measurement => reference-measurement-entry) 682 reference-measurement-entry = { 683 ? payload-type => direct / indirect / hybrid, 684 ? platform-configuration-uri-global => any-uri, 685 ? platform-configuration-uri-local => any-uri, 686 binding-spec-name => text, 687 binding-spec-version => text, 688 platform-manufacturer-id => uint, 689 platform-manufacturer-name => text, 690 platform-model-name => text, 691 ? platform-version => uint, 692 ? firmware-manufacturer-id => uint, 693 ? firmware-manufacturer-name => text, 694 ? firmware-model-name => text, 695 ? firmware-version => uint, 696 ? boot-events => [ * boot-event-entry ], 697 rim-link-hash => bytes, 698 } 700 boot-event-entry = { 701 boot-event-number => uint, 702 boot-event-type => uint, 703 boot-digest-list => [ 1* hash-entry ], 704 boot-event-data => bytes 705 } 707 $$payload-extension //= ( ? support-rim-type-kramdown => direct / indirect ) 708 $$payload-extension //= ( ? support-rim-format => text ) 709 $$payload-extension //= ( ? support-rim-uri-global => any-uri ) 710 $$payload-extension //= ( ? rim-reference => any-uri ) 712 reference-measurement = 58 713 payload-type = 59 714 payload-rim = 60 715 platform-configuration-uri-global = 61 716 platform-configuration-uri-local = 62 717 binding-spec-name = 63 718 binding-spec-version = 64 719 platform-manufacturer-id = 65 720 platform-manufacturer-name = 66 721 platform-model-name = 67 722 platform-version = 68 723 firmware-manufacturer-id = 69 724 firmware-manufacturer-name = 70 725 firmware-model-name = 71 726 firmware-version = 72 727 rim-link-hash = 73 728 support-rim-type-kramdown = 74 729 support-rim-format = 75 730 support-rim-uri-global = 76 731 rim-reference = 77 732 boot-events = 78 733 boot-event-number = 79 734 boot-event-type = 80 735 boot-digest-list = 81 736 boot-event-data = 82 738 direct = 0 739 indirect = 1 740 hybrid = 2 742 $$directory-extension //= ( ? hash => hash-entry ) 744 $$resource-extension //= ( ? hash => hash-entry ) 746 $$process-extension //= ( ? hash => hash-entry ) 748 $$link-extension //= ( ? thumbprint => hash-entry ) 750 $$resource-collection-extension //= ( 751 ? object => object-entry / [ 2* object-entry ] 752 ) 754 object-entry = { 755 resource-collection, 756 tcb-info, 757 $$object-extension, 758 } 760 tcb-info = ( 761 tcb-info.id => hash-entry, 762 tcb-info.key-elements => { 763 tcb-info.vendor => text, 764 ? tcb-info.model => text, 765 ? tcb-info.layer => int, 766 ? tcb-info.index => int, 767 tcb-info.type => tagged-bytes / uuid-bytes, 768 }, 769 ? tcb-info.version => text, 770 ? tcb-info.SVN => int, 771 ? tcb-info.flags => uint .bits tcb-info.operational-flags, 772 ? tcb-info.fwids, 773 ? tcb-info.vendorinfo => bytes .size 8, 774 ? tcb-info.vendormask => bytes, 775 ) 777 uuid-bytes = bytes .size 8 779 tcb-info.operational-flags = &( 780 not-configured: 0, 781 not-secure: 1, 782 recovery: 2, 783 debug: 3, 784 ) 786 tcb-info.fwids = [ 787 + [ hash-alg: [ * int ] / text, 788 digest: bytes, 789 ] 790 ] 792 object = 83 793 tcb-info.id = 84 794 tcb-info.key-elements = 85 795 tcb-info.vendor = 86 796 tcb-info.model = 87 797 tcb-info.layer = 88 798 tcb-info.index = 89 799 tcb-info.type = 90 800 tcb-info.version = 91 801 tcb-info.SVN = 92 802 tcb-info.flags = 93 803 tcb-info.fwids = 94 804 tcb-info.vendorinfo = 95 805 tcb-info.vendormask = 96 806 808 3. Privacy Considerations 810 TBD 812 4. Security Considerations 814 To be elaborated on 816 5. IANA Considerations 818 This document has added the following entries to the SWID/CoSWID 819 Version Scheme Values registry at https://www.iana.org/assignments/ 820 swid [1]: 822 Index: TBD1 823 Version Scheme Name: rpm 824 Specification: See {{rpm-version-scheme}} 826 6. References 828 6.1. Normative References 830 [I-D.ietf-sacm-coswid] 831 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 832 Waltermire, "Concise Software Identification Tags", draft- 833 ietf-sacm-coswid-15 (work in progress), May 2020. 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, 837 DOI 10.17487/RFC2119, March 1997, 838 . 840 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 841 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 842 May 2017, . 844 6.2. Informative References 846 [I-D.fedorkow-rats-network-device-attestation] 847 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 848 based Network Device Remote Integrity Verification", 849 draft-fedorkow-rats-network-device-attestation-05 (work in 850 progress), April 2020. 852 [I-D.ietf-rats-architecture] 853 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 854 W. Pan, "Remote Attestation Procedures Architecture", 855 draft-ietf-rats-architecture-05 (work in progress), July 856 2020. 858 6.3. URIs 860 [1] https://www.iana.org/assignments/swid 862 Authors' Addresses 864 Henk Birkholz 865 Fraunhofer SIT 866 Rheinstrasse 75 867 Darmstadt 64295 868 Germany 870 Email: henk.birkholz@sit.fraunhofer.de 872 Patrick Uiterwijk 873 Red Hat 874 100 E Davie Street 875 Raleigh 27601 876 Netherlands 878 Email: puiterwijk@redhat.com 880 Ned Smith 881 Intel Corporation 882 USA 884 Email: ned.smith@intel.com 886 Jessica Fitzgerald-McKay 887 Department of Defense 888 9800 Savage Road 889 Ft. Meade, Maryland 890 USA 892 Email: jmfitz2@nsa.gov 894 David Waltermire 895 National Institute of Standards and Technology 896 100 Bureau Drive 897 Gaithersburg, Maryland 20877 898 USA 900 Email: david.waltermire@nist.gov 901 Shwetha Bhandari 902 Cisco Systems, Inc. 903 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 904 Bangalore, KARNATAKA 560087 905 India 907 Email: shwethab@cisco.com