idnits 2.17.1 draft-birkholz-rats-coswid-rim-02.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 is 1 instance of too long lines in the document, the longest one being 4 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 (January 13, 2021) is 1199 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 636 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-16 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-08 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: July 17, 2021 Red Hat 6 D. Waltermire 7 NIST 8 S. Bhandari 9 Cisco 10 J. Fitzgerald-McKay 11 Department of Defense 12 January 13, 2021 14 Reference Integrity Measurement Extension for Concise Software 15 Identities 16 draft-birkholz-rats-coswid-rim-02 18 Abstract 20 This document specifies the CDDL and usage description for Reference 21 Integrity Measurements (RIM) in Remote Attestation Procedures (RATS). 22 The specification is based on Concise Software Identification 23 (CoSWID) and TCG Reference Integrity Manifest Information Model - 24 based on Host Integrity at Runtime and Start-up (HIRS). Extension 25 points defined in CoSWID used to augment CoSWID tags with new 26 attributes that can express the TCG Reference Integrity Manifest 27 extensions. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 17, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 65 2. CoSWID Attribute Extensions for RIM . . . . . . . . . . . . . 4 66 2.1. RIM requirements on existing CoSWID attributes . . . . . 4 67 2.2. RIM Extensions for HIRS . . . . . . . . . . . . . . . . . 5 68 2.3. RIM Extensions for Software Package Management . . . . . 10 69 2.3.1. CoSWID Version Scheme for RPM . . . . . . . . . . . . 11 70 2.4. CoSWID RIM CDDL . . . . . . . . . . . . . . . . . . . . . 11 71 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 6.2. Informative References . . . . . . . . . . . . . . . . . 14 77 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Reference Integrity Measurements describe the intended state of 83 (composite) software components installed on a (composite) device. A 84 measurement of all installed software components of a devices allows 85 for assertions about the trustworthiness of the given device. In 86 combination with a root of trust (RoT) for reporting (RTR), these 87 measurements can be refined into evidence and enable Remote 88 ATtestation procedureS (RATS). RATS support the decision process of 89 whether to put trust in the trustworthiness of a device - or not. 91 The RATS architecture [I-D.ietf-rats-architecture] defines the 92 following roles: Verifier, Attester, Endorse, and Relying Party, and 93 Reference Value Provider. The RATS architecture also specifies that 94 attestation Evidence is created by Attesters and consumed by 95 Verifiers. Ultimately, the goal is to enable a Relying Party to put 96 trust in the trustworthiness of a remote peer (the Attester). 97 Attestation Evidence is composed of believable assertions about an 98 Attester's trustworthiness characteristics. In RATS, these 99 assertions are called Claims. The Verifier conducts a set of 100 appraisal procedures in order to assess the compliance of an 101 Attester's trustworthiness characteristics. 103 A prominent appraisal procedure in RATS is the comparison of Claim 104 values included in attestation Evidence with reference Claim values 105 provided by Reference Value Providers (RVP, e.g. a supply chain 106 entity). The comparison of Claim values via Reference Claim Values 107 (RCV) is vital for the assessment of compliance metrics with respect 108 to software components installed on an Attester. A typical objective 109 here is the remediation of vulnerabilities discovered in certain 110 versions of installed software components. 112 The Integrity Measurement Architecture (IMA) of the Linux Security 113 Modules (LSM) provides a detailed Event Log (sometimes also referred 114 to as a Measurement Log) that retains a sequence of hash measurements 115 of every software sub-component (e.g. a firmware, an ELF executable, 116 or a configuration file) that is created and appended to the sequence 117 of measurements that composes the event log before the software 118 component in question is started or read - "first measure, than 119 start". 121 In essence, to enable this appraisal procedure conducted by Verfiers 122 an Attester's IMA provides Event Logs that include the hash values of 123 every started software component and therefore are part of the 124 attestation Evidence an Attester creates. The complementary well- 125 known-values that Verifiers require are included in the Reference 126 Integrity Measurements (RIM). RIMs for software components can be 127 provided via Concise Software Identification (CoSWID) tags created or 128 maintained by RVPs, such as the software creators, manufacturers, 129 vendors, or other trusted third parties (e.g. a certification 130 entity). 132 This document provides an extension to the CoSWID specification 133 defined in [I-D.ietf-sacm-coswid]. The extension adds attributes to 134 CoSWID tags that enable them to express RIMs. One prominent subset 135 of these attributes are illustrated in the TCG Reference Integrity 136 Manifest Information Model [ref] specification. These attributes are 137 added to the existing CoSWID specification via the most general 138 extension point the CoSWID specification provides: $$coswid- 139 extensions. An new map type-definition named "reference-values" is 140 added and is defined in section [ref] of this document. 142 Furthermore, a usage profile for signed CoSWID tags is defined in 143 this specification in support of the software-component structure of 144 systems managed by package managers. Signed CoSWID tags that are 145 aligned with that software model can be used to describe the contents 146 of one or multiple of the packages that make up the contents of a 147 system. In order to minimize the impact on the sizes of packages, it 148 is likely that any CoSWID tags delivered as part of packages as part 149 of a package manager managed system will not contain actual reference 150 values, but instead a link-entry to a CoSWID tag published by the 151 vendor in a repository. 153 1.1. Requirements Notation 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2. CoSWID Attribute Extensions for RIM 163 This specification defines two types of attribute sets that can be 164 added to the CoSWID specification via the specified defined extension 165 points: 167 1. Attributes that support RIM manifests for Measured Boot (often 168 referred to as Secure Boot) and 170 2. Attributes that support the RPM package manager structure. 172 2.1. RIM requirements on existing CoSWID attributes 174 As defined by NIST IR 8060 [ref], there are required "Meta 175 Attributes" for XML SWID tags that have to be included in a SWID tag 176 in order to compose a valid SWID RIM. In this section, these 177 attributes are mapped to CoSWID attributes and corresponding 178 requirements on attributes defined in the CoSWID specification to 179 compose valid NIST IR 8060 signed Payload content in the Concise 180 Software Identity Reference Integrity Measurement (CoSWID RIM) 181 representation. 183 The 'software-meta-entry' type defined in the CoSWID specification 184 includes the optional members 'product', 'colloquial-version', 185 'revision', and 'edition'. These four members MUST be included in a 186 CoSWID RIM in order to compose a valid Reference Integrity 187 Measurement in alignment with NIST IR 8060. Furthermore, the 188 semantics of the text (tstr) typed values MUST convey content that 189 allows for semantic interoperability in a given scope (e.g., an 190 administrative domain). The software-meta-entries provide vital 191 support for steering decisions made by the RATS verifier role in 192 order to enable discovery and matching of related or additional 193 CoSWID RIM available to or discoverable by the verifier. 195 2.2. RIM Extensions for HIRS 197 The following attributes are derived from the TCG Reference Integrity 198 Manifest Information Model [ref] specification. These attributes 199 support the creation of very small CoSWID RIM tags that enable the 200 Remote Integrity Verification (RIV 201 [I-D.fedorkow-rats-network-device-attestation]) of small things, 202 i.e., constrained devices in constrained network environments. In 203 consequence, the majority of the attributes listed in this section 204 represent metadata about firmware and supply chain entities that 205 provide firmware for a device (platform). Analogously to the 206 mandated software-meta-entries illustrated above, the attributes 207 defined in the table below provide more context and enable steering 208 decisions for the appraisal procedures of a Verifier. Consecutively, 209 RIM have to be managed and curated in a consistent manner so that 210 there is no significant threshold for a Verifier to make use of them 211 during an appraisal procedure. 213 The design of the additional RIM attributes in this section is 214 motivated by the vast variety of identifier types used in production 215 today, e.g. endorsement documents [I-D.ietf-rats-architecture] that 216 are enrolled or on-boarded on the Attester itself. It is vital to 217 highlight that this variety can render semantic self-descriptiveness 218 more difficult. Most importantly though: interoperability beats 219 self-descriptiveness. A convergence towards a common identification 220 scheme with respect to software components and its subset that is 221 firmware is highly encouraged - alas not achieved at the time of 222 creating this proposed standard. The following table defines the 223 semantics of the set of new members that are added via the reference- 224 measurement-entry map. The reference-measurement-entry map is added 225 using the $$coswid-extension CDDL extension point. 227 +--------------------------------+----------+-----------------------+ 228 | Attribute Name | Quantity | Description | 229 +--------------------------------+----------+-----------------------+ 230 | payload-type | 0-1 | The value of this | 231 | | | attribute MUST be one | 232 | | | equivalent of the | 233 | | | following three | 234 | | | choices. 'direct': | 235 | | | the representation | 236 | | | used in this RIM (and | 237 | | | referred RIMs) is | 238 | | | using the CoSWID | 239 | | | encoding as its | 240 | | | representation. | 241 | | | 'indirect': the | 242 | | | representation used | 243 | | | in referred RIMs | 244 | | | ('Support RIMs) is | 245 | | | using a different | 246 | | | representation than | 247 | | | CoSWID as it's | 248 | | | encoding. | 249 | | | Analogously, a | 250 | | | reference to the | 251 | | | corresponding | 252 | | | specification MUST be | 253 | | | provided if the value | 254 | | | is set to an | 255 | | | equivalent of | 256 | | | 'indirect' (see | 257 | | | binding-spec-name and | 258 | | | binding-spec- | 259 | | | version). 'hybrid': | 260 | | | the representation | 261 | | | used in the referred | 262 | | | RIMs ('Support RIMs') | 263 | | | is a mix of CoSWID | 264 | | | representations and | 265 | | | other | 266 | | | representations. In | 267 | | | this case, a | 268 | | | reference to the | 269 | | | representation used | 270 | | | MUST be included - | 271 | | | even if it is the | 272 | | | CoSWID representation | 273 | | | - for every Support | 274 | | | RIM (see 'binding- | 275 | | | spec-name' and | 276 | | | 'binding-spec- | 277 | | | version' definition | 278 | | | in this table). | 279 | | | | 280 | platform-configuration-uri- | 0-1 | A byte-comparable | 281 | global | | reference to a | 282 | | | Platform | 283 | | | Configuration URI as | 284 | | | defined by the TCG | 285 | | | Platform Certificate | 286 | | | Profile [ref TCG | 287 | | | Platform Certificate | 288 | | | Profile, Version 1.1] | 289 | | | for X.509v3 | 290 | | | certificates that | 291 | | | MUST be identical to | 292 | | | the URI included in a | 293 | | | TCG Platform | 294 | | | Certificate pointing | 295 | | | to a resource | 296 | | | providing a copy of | 297 | | | the CoSWID RIM this | 298 | | | attribute is included | 299 | | | in. | 300 | | | | 301 | platform-configuration-uri- | 0-1 | A byte-comparable | 302 | local | | reference to a | 303 | | | Platform | 304 | | | Configuration URI | 305 | | | defined by the TCG | 306 | | | Platform Certificate | 307 | | | Profile [ref TCG | 308 | | | Platform Certificate | 309 | | | Profile, Version 1.1] | 310 | | | that MUST represent | 311 | | | the resource at which | 312 | | | a copy of this CoSWID | 313 | | | RIM can be found | 314 | | | within the | 315 | | | (composite) | 316 | | | device/platform | 317 | | | itself. | 318 | | | | 319 | binding-spec-name | 1 | If the value of | 320 | | | 'payload-type' is an | 321 | | | equivalent to the | 322 | | | enumeration | 323 | | | 'indirect', the value | 324 | | | of this attribute | 325 | | | MUST contain a global | 326 | | | unique text (tstr) | 327 | | | identifier referring | 328 | | | to the specification | 329 | | | that defines the | 330 | | | representation of the | 331 | | | referred RIM in order | 332 | | | to enable its | 333 | | | decoding. | 334 | | | | 335 | binding-spec-version | 1 | If the value of | 336 | | | 'payload-type' is an | 337 | | | equivalent to the | 338 | | | enumeration | 339 | | | 'indirect', the value | 340 | | | of this attribute | 341 | | | MUST contain a unique | 342 | | | version number with | 343 | | | respect to the | 344 | | | specification | 345 | | | represented in the | 346 | | | value of 'binding- | 347 | | | spec-name'. | 348 | | | | 349 | platform-manufacturer-id | 0-1 | An identifier based | 350 | | | on the IANA Private | 351 | | | Enterprise Number | 352 | | | registry that is | 353 | | | assigned to firmware | 354 | | | manufacturer. This | 355 | | | identifier MUST be | 356 | | | included unless the | 357 | | | firmware manufacturer | 358 | | | and the platform | 359 | | | manufacturer are | 360 | | | represented by the | 361 | | | same text (tstr) | 362 | | | value. Analogously, | 363 | | | if the firmware | 364 | | | manufacturer and the | 365 | | | platform manufacturer | 366 | | | are represented via | 367 | | | the same text (tstr) | 368 | | | value, this attribute | 369 | | | MAY be omitted. | 370 | | | | 371 | platform-manufacturer-name | 0-1 | An identifier number | 372 | | | (uint) value that | 373 | | | uniquely represents | 374 | | | the firmware | 375 | | | manufacturer. This | 376 | | | identifier MUST be | 377 | | | included unless the | 378 | | | firmware manufacturer | 379 | | | and the platform | 380 | | | manufacturer are | 381 | | | represented via the | 382 | | | same number (unit) | 383 | | | value, this attribute | 384 | | | MAY be omitted. | 385 | | | | 386 | platform-model-name | 1 | An identifier text | 387 | | | (tstr) value enabling | 388 | | | the identification of | 389 | | | a certain device | 390 | | | model/type composite. | 391 | | | The reliability of | 392 | | | this identifier is | 393 | | | not absolute. In | 394 | | | consequence this | 395 | | | identifier MUST NOT | 396 | | | be omitted. In an | 397 | | | case, the use of this | 398 | | | identifier requires | 399 | | | foresight and | 400 | | | preparation as it's | 401 | | | purpose supports | 402 | | | semantic | 403 | | | interoperability. | 404 | | | Arbitrary, | 405 | | | conflicting, or | 406 | | | unresolvable values | 407 | | | SHOULD be avoided. | 408 | | | | 409 | platform-version | 0-1 | A byte-comparable | 410 | | | reference to a | 411 | | | Platform | 412 | | | Certificate's | 413 | | | 'Manufacturer- | 414 | | | Specific Identifier' | 415 | | | extension value [ref | 416 | | | TCG Platform | 417 | | | Certificate Profile, | 418 | | | Version 1.1]. | 419 | | | | 420 | firmware-manufacturer-id | 0-1 | An IANA defined | 421 | | | unique value that is | 422 | | | a Private Enterprise | 423 | | | Number (Platform | 424 | | | manufacturer unique | 425 | | | identifier) that | 426 | | | SHOULD be included in | 427 | | | a CoSWID RIM that | 428 | | | covers firmware. | 429 | | | | 430 | firmware-manufacturer-name | 0-1 | An identifier that is | 431 | | | represented as the | 432 | | | name of a platform | 433 | | | manufacturer via a | 434 | | | text (tstr) value | 435 | | | that SHOULD be | 436 | | | included in a CoSWID | 437 | | | RIM that covers | 438 | | | firmware. | 439 | | | | 440 | firmware-model-name | 0-1 | An identifier that | 441 | | | represents the target | 442 | | | platform model via a | 443 | | | text (tstr) value | 444 | | | that SHOULD be | 445 | | | included in a CoSWID | 446 | | | RIM. | 447 | | | | 448 | firmware-version | 0-1 | An identifier that is | 449 | | | represented as the | 450 | | | version number of a | 451 | | | specific firmware | 452 | | | version corresponding | 453 | | | to a given set of | 454 | | | platform identifiers | 455 | | | and SHOULD be | 456 | | | included in a CoSWID | 457 | | | RIM. | 458 | | | | 459 | boot-events | 0-1 | A reference to the | 460 | | | platform measured | 461 | | | boot event logs that | 462 | | | can be compared to | 463 | | | individual events | 464 | | | from the platform | 465 | | | measured boot events | 466 | | | collected at platform | 467 | | | runtime. | 468 +--------------------------------+----------+-----------------------+ 470 2.3. RIM Extensions for Software Package Management 472 To enable very small CoSWID tags that basically are signed references 473 to full Base RIMs for each software package that ultimately include 474 all the hash values required by the appraisal procedure of a 475 Verifier, the member rim-reference is added using the $$payload- 476 extension CDDL extension point. 478 +---------------+----------+----------------------------------------+ 479 | Attribute | Quantity | Description | 480 | Name | | | 481 +---------------+----------+----------------------------------------+ 482 | rim-reference | 0-1 | A URI pointing to the CoSWID Base RIM | 483 | | | that will list the payload reference | 484 | | | measurements (hashes) in case of a | 485 | | | minimal CoSWID tag. | 486 +---------------+----------+----------------------------------------+ 488 2.3.1. CoSWID Version Scheme for RPM 490 To enable encoding version information into a CoSWID tag for RPM 491 packages, the SWID version scheme value index TBD1 has been 492 registered. RPM versions are defined as epoch:version-release- 493 architecture, where the "epoch:" component is optional. Epoch is a 494 numerical value, which should be considered zero if the epoch 495 component is missing. Version and Release can be any string as long 496 as they do not contain a hyphen (-). Architecture is an 497 alphanumerical string. 499 Sorting of RPM versions is a multi-step process: - The epoch, version 500 and release components are compared in that order, as soon as a 501 difference is found, that is the overall difference. - The epoch 502 component is compared as integers. A higher number means a higher 503 version. - The version and release components are compared 504 alphabetically, until a digit is encountered in both strings, at 505 which point as many digits are consumed from both to form an integer, 506 which is then compared. If the integers are identical, the 507 comparison continues alphabetically. - The architecture component is 508 never sorted. If they are different between two versions, the 509 versions are inequal, not higher or lower. 511 2.4. CoSWID RIM CDDL 513 The following CDDL specification uses the existing CDDL extension 514 points as defined in [I-D.ietf-sacm-coswid]: 516 o $$coswid-extension 518 o $$payload-extension 520 521 $$coswid-extension //= (reference-values => reference-values-entry) 523 reference-value-entry = { 524 ? payload-type => direct / indirect / hybrid, 525 ? platform-configuration-uri-global => any-uri, 526 ? platform-configuration-uri-local => any-uri, 527 binding-spec-name => text, 528 binding-spec-version => text, 529 platform-manufacturer-id => uint, 530 platform-manufacturer-name => text, 531 platform-model-name => text, 532 ? platform-version => uint, 533 ? firmware-manufacturer-id => uint, 534 ? firmware-manufacturer-name => text, 535 ? firmware-model-name => text, 536 ? firmware-version => uint, 537 ? boot-events => [ * boot-event-entry ], 538 rim-link-hash => bytes, 539 } 541 boot-event-entry = { 542 boot-event-number => uint, 543 boot-event-type => uint, 544 boot-digest-list => [ 1* hash-entry ], 545 boot-event-data => bytes 546 } 548 $$payload-extension //= ( ? support-rim-type-kramdown => direct / indirect ) 549 $$payload-extension //= ( ? support-rim-format => text ) 550 $$payload-extension //= ( ? support-rim-uri-global => any-uri ) 551 $$payload-extension //= ( ? rim-reference => any-uri ) 553 reference-measurement = 58 554 payload-type = 59 555 payload-rim = 60 556 platform-configuration-uri-global = 61 557 platform-configuration-uri-local = 62 558 binding-spec-name = 63 559 binding-spec-version = 64 560 platform-manufacturer-id = 65 561 platform-manufacturer-name = 66 562 platform-model-name = 67 563 platform-version = 68 564 firmware-manufacturer-id = 69 565 firmware-manufacturer-name = 70 566 firmware-model-name = 71 567 firmware-version = 72 568 rim-link-hash = 73 569 support-rim-type-kramdown = 74 570 support-rim-format = 75 571 support-rim-uri-global = 76 572 rim-reference = 77 573 boot-events = 78 574 boot-event-number = 79 575 boot-event-type = 80 576 boot-digest-list = 81 577 boot-event-data = 82 579 direct = 0 580 indirect = 1 581 hybrid = 2 582 584 3. Privacy Considerations 586 TBD 588 4. Security Considerations 590 To be elaborated on 592 5. IANA Considerations 594 This document has added the following entries to the SWID/CoSWID 595 Version Scheme Values registry at https://www.iana.org/assignments/ 596 swid [1]: 598 Index: TBD1 599 Version Scheme Name: rpm 600 Specification: See {{rpm-version-scheme}} 602 6. References 604 6.1. Normative References 606 [I-D.ietf-sacm-coswid] 607 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 608 Waltermire, "Concise Software Identification Tags", draft- 609 ietf-sacm-coswid-16 (work in progress), November 2020. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 618 May 2017, . 620 6.2. Informative References 622 [I-D.fedorkow-rats-network-device-attestation] 623 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 624 based Network Device Remote Integrity Verification", 625 draft-fedorkow-rats-network-device-attestation-05 (work in 626 progress), April 2020. 628 [I-D.ietf-rats-architecture] 629 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 630 W. Pan, "Remote Attestation Procedures Architecture", 631 draft-ietf-rats-architecture-08 (work in progress), 632 December 2020. 634 6.3. URIs 636 [1] https://www.iana.org/assignments/swid 638 Authors' Addresses 640 Henk Birkholz 641 Fraunhofer SIT 642 Rheinstrasse 75 643 Darmstadt 64295 644 Germany 646 Email: henk.birkholz@sit.fraunhofer.de 648 Patrick Uiterwijk 649 Red Hat 650 100 E Davie Street 651 Raleigh 27601 652 Netherlands 654 Email: puiterwijk@redhat.com 656 David Waltermire 657 National Institute of Standards and Technology 658 100 Bureau Drive 659 Gaithersburg, Maryland 20877 660 USA 662 Email: david.waltermire@nist.gov 663 Shwetha Bhandari 664 Cisco Systems, Inc. 665 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 666 Bangalore, KARNATAKA 560087 667 India 669 Email: shwethab@cisco.com 671 Jessica Fitzgerald-McKay 672 Department of Defense 673 9800 Savage Road 674 Ft. Meade, Maryland 675 USA 677 Email: jmfitz2@nsa.gov