idnits 2.17.1 draft-birkholz-rats-coswid-rim-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (March 09, 2020) is 1480 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) == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-13 == Outdated reference: A later version (-05) exists of draft-fedorkow-rats-network-device-attestation-04 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: September 10, 2020 Red Hat 6 J. Fitzgerald-McKay 7 Department of Defense 8 D. Waltermire 9 NIST 10 March 09, 2020 12 Reference Integrity Measurement Extension for Concise Software 13 Identities 14 draft-birkholz-rats-coswid-rim-00 16 Abstract 18 Concise Software Identification (CoSWID) tags identify and describe 19 individual software components, patches, and installation bundles. 20 CoSWID is based on ISO/IEC 19770-2:2015 2:2015 that provides a 21 complementary XML schema definition (XSD) for Software Identification 22 (SWID) tags. CoSWID supports the same features as the corresponding 23 XML SWID tags. The CoSWID specification also includes more 24 structured extensibility features and reduces a few of ambiguities 25 that are not explicitly resolved in the ISO XSD. In this document, 26 these extensibility features (extension points) are used to add 27 attributes to the CoSWID specification. The new attributes allow for 28 the use of CoSWID as Reference Integrity Measurements (RIM). There 29 are three set of RIM features defined in this specification. 1.) 30 attributes that support RIM manifests for Measured Boot, 2.) 31 attributes that support package manager managed structures, and 3.) 32 attributes that allow for OID to be used in the description of 33 Reference Integrity Measurements. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 10, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 70 2. CoSWID Attribute Extensions . . . . . . . . . . . . . . . . . 4 71 2.1. RIM requirements on existing CoSWID attributes . . . . . 4 72 2.2. RIM extensions for Measured Boot . . . . . . . . . . . . 5 73 2.3. RIM extension for Software Package Management . . . . . . 10 74 2.4. Additional Measurement Attributes for CoSWID . . . . . . 11 75 2.5. CoSWID RIM CDDL . . . . . . . . . . . . . . . . . . . . . 11 76 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 5.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Reference Integrity Measurements describe the intended state of 86 (composite) software components installed on a (composite) device. A 87 measurement of all installed software components of a devices allows 88 for assertions about the trustworthiness of the given device. In 89 combination with a root of trust (RoT) for reporting (RTM), these 90 measurements can be refined into evidence and enable IETF Remote 91 Attestation ProcedureS (RATS). RATS support the decision process of 92 whether to put trust in the trustworthiness of a device - or not. 94 The RATS architecture [I-D.ietf-rats-architecture] defines the roles 95 Verifiers, Attesters, Endorsers, and Relying Parties. The RATS 96 architecture also specifies that Attestation Evidence is created by 97 Attesters and consumed by Verifiers. Ultimately, the goal is to 98 enable a Relying Party to put trust in the trustworthiness of a 99 remote peer (the Attester). Attestation Evidence is composed of 100 believable assertions about an Attester's trustworthiness 101 characteristics. In RATS, these assertions are called Claims. The 102 Verifier conducts a set of appraisal procedures in order to assess 103 the compliance of an Attester's trustworthiness characteristics. 105 The most prominent appraisal procedure in RATS is the comparison of 106 Claim values included in Attestation Evidence with Reference Claim 107 values provided by Endorsers (e.g. supply chain entities). The 108 comparison of Claim values via Reference Claim values is vital for 109 the assessment of compliance metrics with respect to software 110 components installed on an Attester. A typical objective here is the 111 remediation of already vulnerabilities discovered in certain versions 112 of software components. 114 The Integrity Measurement Architecture (IMA) of the Linux Security 115 Modules (LSM) provides a detailed Event Log (sometimes also referred 116 to as a Measurement Log) that retains a sequence of hash measurements 117 of every software sub-component (e.g. a firmware, an ELF executable, 118 or a configuration file) that is created and appended to the sequence 119 of measurements that composes the event log before the software 120 component in question is started or read. 122 In essence, to enable this appraisal procedure conducted by Verfiers 123 an Attester's IMA provides Event Logs that include the hash values of 124 every started software component and therefore are part of the 125 Attestation Evidence an Attester creates. The complementary well- 126 known-values that Verifiers require are included in the Reference 127 Integrity Measurements (RIM). RIMs can be provided via Software 128 Identification tags created by Endorsers, such as the software 129 creators, manufacturers, vendors, or other trusted third parties 130 (e.g. supply chain or certification entities). 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. A vital subset of 135 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 additional map definition named "reference- 140 measurements" is added and is defined in section [ref] of this 141 document. 143 Furthermore, a usage profile for signed CoSWID tags is defined in 144 this specification in support of the software-component structure of 145 systems managed by package managers. Signed CoSWID tags that are 146 aligned with that software model can be used to describe the contents 147 of one or multiple of the packages that make up the contents of a 148 system. In this case, it may be that multiple CoSWID tags are 149 provided as Reference Claim values for a attestation by a single 150 Attester. In order to minimize the impact on the sizes of packages, 151 it is likely that any CoSWID tags delivered as part of packages as 152 part of a package manager managed system will not contain actual 153 reference values, but instead a link-entry to a CoSWID tag published 154 by the vendor in a repository. 156 Reference Integrity Measurements provide a vital resource to be 157 consumed by ... TBD 159 1.1. Requirements Notation 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2. CoSWID Attribute Extensions 169 This specification defines three types of attribute sets that can be 170 added to the CoSWID specification via its defined extension points. 172 1. Attributes that support RIM manifests for Measured Boot (often 173 still referred to as Secure Boot), 175 2. Attributes that support the RPM package manager structure, and 177 3. Attributes that allow for OID to be used in the description of 178 Reference Integrity Measurements. 180 2.1. RIM requirements on existing CoSWID attributes 182 As defined by NIST IR 8060 [ref], there are required "Meta 183 Attributes" for XML SWID tags that have to be included in a SWID tag 184 in order to compose a valid SWID RIM. In this section, these 185 attributes are mapped to CoSWID attributes and corresponding 186 requirements on attributes defined in the CoSWID specification to 187 compose valid NIST IR 8060 signed Payload content in the Concise 188 Software Identity Reference Integrity Measurement (CoSWID RIM) 189 representation. 191 The 'software-meta-entry' type defined in the CoSWID specification 192 includes the optional members 'product', 'colloquial-version', 193 'revision', and 'edition'. These four members MUST be included in a 194 CoSWID RIM in order to compose a valid Reference Integrity 195 Measurement in alignment with NIST IR 8060. Furthermore, the 196 semantics of the text (tstr) typed values MUST convey content that 197 allows for semantic interoperability in a given scope (e.g. an 198 administrative domain). The software-meta-entries provide vital 199 support for steering decisions made by the RATS verifier role in 200 order to enable discovery and matching of related or additional 201 CoSWID RIM available to or discoverable by the verifier. 203 2.2. RIM extensions for Measured Boot 205 The following attributes are derived from the TCG Reference Integrity 206 Manifest Information Model [ref] specification. These attributes 207 support the creation of very small CoSWID RIM tags that enable the 208 Remote Integrity Verification (RIV 209 [I-D.fedorkow-rats-network-device-attestation]) of small things, i.e. 210 constrained devices in constrained network environments. In 211 consequence, the majority of the attributes listed in this section 212 represent metadata about firmware and supply chain entities that 213 provide firmware for a device (platform). Analogously to the 214 mandated software-meta-entries illustrated above, the attributes 215 defined in the table below provide more context and enable steering 216 decisions for the appraisal procedures of a Verifier. Consecutively, 217 RIM have to be managed and curated in a consistent manner so that 218 there is no significant threshold for a Verifier to make use of them 219 during an appraisal procedure. 221 The design of the additional RIM attributes in this section is 222 motivated by the vast variety of identifier types used in production 223 today, e.g. endorsement documents [I-D.ietf-rats-architecture] that 224 are enrolled or on-boarded on the Attester itself. It is vital to 225 highlight that this variety can render semantic self-descriptiveness 226 more difficult. Most importantly though: interoperability beats 227 self-descriptiveness. A convergence towards a common identification 228 scheme with respect to software components and its subset that is 229 firmware is highly encouraged - alas not achieved at the time of 230 creating this proposed standard. The following table defines the 231 semantics of the set of new members that are added via the reference- 232 measurement-entry map. The reference-measurement-entry map is added 233 using the $$coswid-extension CDDL extension point. 235 +--------------------------------+----------+-----------------------+ 236 | Attribute Name | Quantity | Description | 237 +--------------------------------+----------+-----------------------+ 238 | payload-type | 0-1 | The value of this | 239 | | | attribute MUST be one | 240 | | | equivalent of the | 241 | | | following three | 242 | | | choices. 'direct': | 243 | | | the representation | 244 | | | used in this RIM (and | 245 | | | referred RIMs) is | 246 | | | using the CoSWID | 247 | | | encoding as its | 248 | | | representation. | 249 | | | 'indirect': the | 250 | | | representation used | 251 | | | in referred RIMs | 252 | | | ('Support RIMs) is | 253 | | | using a different | 254 | | | representation than | 255 | | | CoSWID as it's | 256 | | | encoding. | 257 | | | Analogously, a | 258 | | | reference to the | 259 | | | corresponding | 260 | | | specification MUST be | 261 | | | provided if the value | 262 | | | is set to an | 263 | | | equivalent of | 264 | | | 'indirect' (see | 265 | | | binding-spec-name and | 266 | | | binding-spec- | 267 | | | version). 'hybrid': | 268 | | | the representation | 269 | | | used in the referred | 270 | | | RIMs ('Support RIMs') | 271 | | | is a mix of CoSWID | 272 | | | representations and | 273 | | | other | 274 | | | representations. In | 275 | | | this case, a | 276 | | | reference to the | 277 | | | representation used | 278 | | | MUST be included - | 279 | | | even if it is the | 280 | | | CoSWID representation | 281 | | | - for every Support | 282 | | | RIM (see 'binding- | 283 | | | spec-name' and | 284 | | | 'binding-spec- | 285 | | | version' definition | 286 | | | in this table). | 287 | | | | 288 | platform-configuration-uri- | 0-1 | A byte-comparable | 289 | global | | reference to a | 290 | | | Platform | 291 | | | Configuration URI as | 292 | | | defined by the TCG | 293 | | | Platform Certificate | 294 | | | Profile [ref TCG | 295 | | | Platform Certificate | 296 | | | Profile, Version 1.1] | 297 | | | for X.509v3 | 298 | | | certificates that | 299 | | | MUST be identical to | 300 | | | the URI included in a | 301 | | | TCG Platform | 302 | | | Certificate pointing | 303 | | | to a resource | 304 | | | providing a copy of | 305 | | | the CoSWID RIM this | 306 | | | attribute is included | 307 | | | in. | 308 | | | | 309 | platform-configuration-uri- | 0-1 | A byte-comparable | 310 | local | | reference to a | 311 | | | Platform | 312 | | | Configuration URI | 313 | | | defined by the TCG | 314 | | | Platform Certificate | 315 | | | Profile [ref TCG | 316 | | | Platform Certificate | 317 | | | Profile, Version 1.1] | 318 | | | that MUST represent | 319 | | | the resource at which | 320 | | | a copy of this CoSWID | 321 | | | RIM can be found | 322 | | | within the | 323 | | | (composite) | 324 | | | device/platform | 325 | | | itself. | 326 | | | | 327 | binding-spec-name | 1 | If the value of | 328 | | | 'payload-type' is an | 329 | | | equivalent to the | 330 | | | enumeration | 331 | | | 'indirect', the value | 332 | | | of this attribute | 333 | | | MUST contain a global | 334 | | | unique text (tstr) | 335 | | | identifier referring | 336 | | | to the specification | 337 | | | that defines the | 338 | | | representation of the | 339 | | | referred RIM in order | 340 | | | to enable its | 341 | | | decoding. | 342 | | | | 343 | binding-spec-version | 1 | If the value of | 344 | | | 'payload-type' is an | 345 | | | equivalent to the | 346 | | | enumeration | 347 | | | 'indirect', the value | 348 | | | of this attribute | 349 | | | MUST contain a unique | 350 | | | version number with | 351 | | | respect to the | 352 | | | specification | 353 | | | represented in the | 354 | | | value of 'binding- | 355 | | | spec-name'. | 356 | | | | 357 | platform-manufacturer-id | 0-1 | An identifier based | 358 | | | on the IANA Private | 359 | | | Enterprise Number | 360 | | | registry that is | 361 | | | assigned to firmware | 362 | | | manufacturer. This | 363 | | | identifier MUST be | 364 | | | included unless the | 365 | | | firmware manufacturer | 366 | | | and the platform | 367 | | | manufacturer are | 368 | | | represented by the | 369 | | | same text (tstr) | 370 | | | value. Analogously, | 371 | | | if the firmware | 372 | | | manufacturer and the | 373 | | | platform manufacturer | 374 | | | are represented via | 375 | | | the same text (tstr) | 376 | | | value, this attribute | 377 | | | MAY be omitted. | 378 | | | | 379 | platform-manufacturer-name | 0-1 | An identifier number | 380 | | | (uint) value that | 381 | | | uniquely represents | 382 | | | the firmware | 383 | | | manufacturer. This | 384 | | | identifier MUST be | 385 | | | included unless the | 386 | | | firmware manufacturer | 387 | | | and the platform | 388 | | | manufacturer are | 389 | | | represented via the | 390 | | | same number (unit) | 391 | | | value, this attribute | 392 | | | MAY be omitted. | 393 | | | | 394 | platform-model-name | 1 | An identifier text | 395 | | | (tstr) value enabling | 396 | | | the identification of | 397 | | | a certain device | 398 | | | model/type composite. | 399 | | | The reliability of | 400 | | | this identifier is | 401 | | | not absolute. In | 402 | | | consequence this | 403 | | | identifier MUST NOT | 404 | | | be omitted. In an | 405 | | | case, the use of this | 406 | | | identifier requires | 407 | | | foresight and | 408 | | | preparation as it's | 409 | | | purpose supports | 410 | | | semantic | 411 | | | interoperability. | 412 | | | Arbitrary, | 413 | | | conflicting, or | 414 | | | unresolvable values | 415 | | | SHOULD be avoided. | 416 | | | | 417 | platform-version | 0-1 | A byte-comparable | 418 | | | reference to a | 419 | | | Platform | 420 | | | Certificate's | 421 | | | 'Manufacturer- | 422 | | | Specific Identifier' | 423 | | | extension value [ref | 424 | | | TCG Platform | 425 | | | Certificate Profile, | 426 | | | Version 1.1]. | 427 | | | | 428 | firmware-manufacturer-id | 0-1 | An IANA defined | 429 | | | unique value that is | 430 | | | a Private Enterprise | 431 | | | Number (Platform | 432 | | | manufacturer unique | 433 | | | identifier) that | 434 | | | SHOULD be included in | 435 | | | a CoSWID RIM that | 436 | | | covers firmware. | 437 | | | | 438 | firmware-manufacturer-name | 0-1 | An identifier that is | 439 | | | represented as the | 440 | | | name of a platform | 441 | | | manufacturer via a | 442 | | | text (tstr) value | 443 | | | that SHOULD be | 444 | | | included in a CoSWID | 445 | | | RIM that covers | 446 | | | firmware. | 447 | | | | 448 | firmware-model-name | 0-1 | An identifier that | 449 | | | represents the target | 450 | | | platform model via a | 451 | | | text (tstr) value | 452 | | | that SHOULD be | 453 | | | included in a CoSWID | 454 | | | RIM. | 455 | | | | 456 | firmware-version | 0-1 | An identifier that is | 457 | | | represented as the | 458 | | | version number of a | 459 | | | specific firmware | 460 | | | version corresponding | 461 | | | to a given set of | 462 | | | platform identifiers | 463 | | | and SHOULD be | 464 | | | included in a CoSWID | 465 | | | RIM. | 466 +--------------------------------+----------+-----------------------+ 468 2.3. RIM extension for Software Package Management 470 To enable very small CoSWID tags that basically are signed references 471 to full Base RIMs for each software package that ultimately include 472 all the hash values required by the appraisal procedure of a 473 Verifier, the member rim-reference is added using the $$payload- 474 extension CDDL extension point. 476 +---------------+----------+----------------------------------------+ 477 | Attribute | Quantity | Description | 478 | Name | | | 479 +---------------+----------+----------------------------------------+ 480 | rim-reference | 0-1 | A URI pointing to the CoSWID Base RIM | 481 | | | that will list the payload reference | 482 | | | measurements (hashes) in case of a | 483 | | | minimal CoSWID tag. | 484 +---------------+----------+----------------------------------------+ 486 2.4. Additional Measurement Attributes for CoSWID 488 [I-D.ietf-sacm-coswid] specifies a well-defined file hash structure 489 for integrity measurements of individual files in a file-system. 490 This documents extends this feature to all additional members of the 491 resource-collection group: 'directory', 'resource', and 'process'. 492 These new well-defined measurement options extend the scope of RIM to 493 (sub-)trees of files, software running in memory (e.g. available from 494 Trusted Execution Environments, such as SGX enclaves), and even 495 external resources, such as remote services of collections of RIM 496 bundles. 498 2.5. CoSWID RIM CDDL 500 The following CDDL specification uses the existing CDDL extension 501 points as defined in [I-D.ietf-sacm-coswid]: 503 o $$coswid-extension 505 o $$payload-extension 507 o $$directory-extension 509 o $$resource-extension 511 o $$process-extension 513 514 $$coswid-extension //= (reference-measurement => reference-measurement-entry) 516 reference-measurement-entry = { 517 ? payload-type => direct / indirect / hybrid, 518 ? platform-configuration-uri-global => any-uri, 519 ? platform-configuration-uri-local => any-uri, 520 binding-spec-name => text, 521 binding-spec-version => text, 522 platform-manufacturer-id => uint, 523 platform-manufacturer-name => text, 524 platform-model-name => text, 525 ? platform-version => uint, 526 ? firmware-manufacturer-id => uint, 527 ? firmware-manufacturer-name => text, 528 ? firmware-model-name => text, 529 ? firmware-version => uint, 530 rim-link-hash => bytes, 531 } 533 $$payload-extension //= ( ? support-rim-type-kramdown => direct / indirect, ) 534 $$payload-extension //= ( ? support-rim-format => text, ) 535 $$payload-extension //= ( ? support-rim-uri-global => any-uri, ) 536 $$payload-extension //= ( ? rim-reference => any-uri, ) 538 reference-measurement = 58 539 payload-type = 59 540 payload-rim = 60 541 platform-configuration-uri-global = 61 542 platform-configuration-uri-local = 62 543 binding-spec-name = 63 544 binding-spec-version = 64 545 platform-manufacturer-id = 65 546 platform-manufacturer-name = 66 547 platform-model-name = 67 548 platform-version = 68 549 firmware-manufacturer-id = 69 550 firmware-manufacturer-name = 70 551 firmware-model-name = 71 552 firmware-version = 72 553 rim-link-hash = 73 554 support-rim-type-kramdown = 74 555 support-rim-format = 75 556 support-rim-uri-global = 76 557 rim-reference = 77 559 direct = 0 560 indirect = 1 561 hybrid = 2 563 $$directory-extension //= ( ? hash => hash-entry ) 565 $$resource-extension //= ( ? hash => hash-entry ) 567 $$process-extension //= ( ? hash => hash-entry ) 568 569 3. Privacy Considerations 571 TBD 573 4. Security Considerations 575 To be elaborated on 577 5. References 579 5.1. Normative References 581 [I-D.ietf-sacm-coswid] 582 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 583 Waltermire, "Concise Software Identification Tags", draft- 584 ietf-sacm-coswid-13 (work in progress), November 2019. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 593 May 2017, . 595 5.2. Informative References 597 [I-D.fedorkow-rats-network-device-attestation] 598 Fedorkow, G. and J. Fitzgerald-McKay, "Network Device 599 Remote Integrity Verification", draft-fedorkow-rats- 600 network-device-attestation-04 (work in progress), March 601 2020. 603 [I-D.ietf-rats-architecture] 604 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 605 W. Pan, "Remote Attestation Procedures Architecture", 606 draft-ietf-rats-architecture-02 (work in progress), March 607 2020. 609 Authors' Addresses 610 Henk Birkholz 611 Fraunhofer SIT 612 Rheinstrasse 75 613 Darmstadt 64295 614 Germany 616 Email: henk.birkholz@sit.fraunhofer.de 618 Patrick Uiterwijk 619 Red Hat 620 100 E Davie Street 621 Raleigh 27601 622 Netherlands 624 Email: puiterwijk@redhat.com 626 Jessica Fitzgerald-McKay 627 Department of Defense 628 9800 Savage Road 629 Ft. Meade, Maryland 630 USA 632 Email: jmfitz2@nsa.gov 634 David Waltermire 635 National Institute of Standards and Technology 636 100 Bureau Drive 637 Gaithersburg, Maryland 20877 638 USA 640 Email: david.waltermire@nist.gov