idnits 2.17.1 draft-ietf-sacm-rolie-softwaredescriptor-03.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 abstract seems to contain references ([RFC8322]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Intended status: InformationalNational Institute of Standards and Techno', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 15, 2018) is 2112 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) == Missing Reference: 'RFC3023' is mentioned on line 487, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Unused Reference: 'RFC5070' is defined on line 600, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'NISTIR8060' ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group S. Banghart 3 Internet-Draft D. Waltermire 4 Intended status: InformationalNational Institute of Standards and Techno 5 Expires: January 16, 2019 July 15, 2018 7 Definition of the ROLIE Software Descriptor Extension 8 draft-ietf-sacm-rolie-softwaredescriptor-03 10 Abstract 12 This document uses the "information-type" extension point as defined 13 in the Resource-Oriented Lightweight Information Exchange (ROLIE) 14 [RFC8322] Section 7.1.2 to better support Software Record and 15 Software Inventory use cases. This specification registers a new 16 ROLIE information-type, "software-descriptor", that allows for the 17 categorization of information relevant to software description 18 activities and formats. In particular, the usage of the ISO 19 19770-2:2015 (SWID Tag) and the Concise SWID (COSWID) formats in 20 ROLIE are standardized. Additionally, this document discusses 21 requirements and usage of other ROLIE elements in order to best 22 syndicate software description information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 16, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. The "software-descriptor" information type . . . . . . . . . 4 62 5. rolie:property Extensions . . . . . . . . . . . . . . . . . . 5 63 5.1. urn:ietf:params:rolie:property:swd:swname . . . . . . . . 5 64 5.2. urn:ietf:params:rolie:property:swd:swversion . . . . . . 6 65 5.3. urn:ietf:params:rolie:property:swd:swcreator . . . . . . 6 66 6. Data format requirements . . . . . . . . . . . . . . . . . . 6 67 6.1. The ISO SWID 2015 format . . . . . . . . . . . . . . . . 6 68 6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 69 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 7 70 6.2. The Concise SWID format . . . . . . . . . . . . . . . . . 7 71 6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 72 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 8 73 7. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 11 76 8.1.1. ISO SWID . . . . . . . . . . . . . . . . . . . . . . 11 77 8.2. software-descriptor information-type . . . . . . . . . . 12 78 8.3. swd:swname property . . . . . . . . . . . . . . . . . . . 12 79 8.4. swd:swversion property . . . . . . . . . . . . . . . . . 12 80 8.5. swd:swcreator property . . . . . . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . 14 84 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 This document defines an extension to the Resource-Oriented 90 Lightweight Information Exchange (ROLIE) [RFC8322] to support the 91 publication of software descriptor information. Software descriptor 92 information is information that characterizes static software 93 components, packages, and installers; including identifying, 94 versioning, software creation and publication, and file artifact 95 information. 97 Software descriptor information provides data about what might be 98 installed, but doesn't describe a specific software installation's 99 configuration or execution. This static approach to software 100 description is a smaller state space that covers the majority of 101 current use cases for software inventory and record keeping. 103 Some possible use cases for software descriptor information ROLIE 104 Feeds include: 106 o Software providers can publish software descriptor information so 107 that software researchers, enterprises, and users of software can 108 understand the collection of software produced by that software 109 provider. 111 o Organizations can aggregate and syndicate collections of software 112 descriptor information provided by multiple software providers to 113 support software-related analysis processes (e.g., vulnerability 114 analysis) and value added information (e.g., software 115 configuration checklist repositories) using identification and 116 characterization information derived from software descriptor 117 information. 119 o End user organizations can consume sources of software descriptor 120 information, and other related software vulnerability and 121 configuration information to provide the data needed to automate 122 software asset, patch, and configuration management practices. 124 o Organizations can use software descriptors to support verification 125 of other entities, thru mechanisms such as RIM or other integrity 126 measurements. 128 This document supports these use cases by describing the content 129 requirements for Feeds and Entries of software descriptor information 130 that are to be published to or retrieved from a ROLIE repository. 132 2. Terminology 134 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 135 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 Several places in this document refer to the "information-type" of a 139 Resource (Entry or Feed). This refers to the "value" attribute of an 140 "atom:category" element whose scheme is 141 "urn:ietf:params:rolie:category:information-type". For an Entry, 142 this value can be inherited from it's containing Feed as per 143 [RFC8322]. 145 3. Background 147 In order to effectively protect and secure an endpoint, it is vital 148 to know what the software load of that endpoint is. This software 149 load, the combination of software, patches and installers on a 150 device, represents the majority of the endpoint's attack surface. 151 Unfortunately, without a reliable and secure package manager, or 152 otherwise a secured and managed operating system, tracking what 153 software is installed on an endpoint is currently not feasible 154 without undue effort. Even attempting to whitelist software is 155 difficult without a way of identifying software and its editions, 156 versions and hotfixes. 158 Software descriptor information, such as that standardized in the ISO 159 19770-2:2015 SWID Tag format, or expressed in proprietary enterprise 160 databases, attempts to provide as much data about this software as 161 possible. 163 Once this information is expressed, it needs to be stored and shared 164 to internal and external parties. ROLIE provides a mechanism to 165 handle this sharing in an automation-friendly way. 167 4. The "software-descriptor" information type 169 When an "atom:category" element has the scheme 170 "urn:ietf:params:rolie:category:information-type", the value is 171 considered to be the information type of the associated resource. 172 The new information type value "software-descriptor", is described in 173 this section, and registered in Section 8.2. 175 The "software-descriptor" information type represents any static 176 information that describes a piece of software. This document uses 177 the definition of software provided by [RFC4949]. Note that as per 178 this definition, this information type pertains to static software, 179 that is, code on the disc. The "software-descriptor" information 180 type is intended to provide a category for information that does one 181 or more of the following: 183 identifies and characterizes software: This software identification 184 and characterization information can be provided by a large 185 variety of data, but always describes software in a pre-installed 186 state. 188 provides software installer metadata: This represents information 189 about software used to install other software. This metadata 190 identifies, and characterizes a software installation package or 191 media. 193 describes stateless installation metadata: Information that 194 describes the software post-deployment, such as files that may be 195 deployed during an installation. It is expected that this 196 metadata is produced generally for a given installation, and may 197 not exactly match the actual installed files on a given endpoint. 199 Provided below is a non-exhaustive list of information that may be 200 considered to be of a software-descriptor information type. 202 o Naming information: IDs and names that aid in the identification 203 of a piece of software 205 o Version and patching information: Version numbers, patch 206 identifiers, or other information that 208 o Vendor and source information: Includes where the software was 209 developed or distributed from, as well as where the software 210 installation media may be located. 212 o Payload and file information: information that describes or 213 enumerates the files and folders that make up the piece of 214 software, and information about those files. 216 o Descriptive information and data: Any information that otherwise 217 characterizes a piece of software, such as libraries, runtime 218 environments, target OSes, intended purpose or audience, etc. 220 Note again that this list is not exhaustive, any information that in 221 is the abstract realm of an incident should be classified under this 222 information-type. 224 It is important to note that software descriptor information is 225 static for a given piece of software. That is, the information 226 expressed is the data that doesn't change from the publication of the 227 software to its final install. Information about the current status 228 (e.g. install location, memory usage, CPU usage, launch parameters, 229 job progress, etc.), is out of scope of this information type. 231 5. rolie:property Extensions 233 This document registers new valid rolie:property names as follows: 235 5.1. urn:ietf:params:rolie:property:swd:swname 237 This property provides an exposure point for the plain text name of 238 the software being described. Naming of software is not a well 239 standardized process, and software names can change between product 240 versions or editions. As such, care should be taken that this value 241 is set as consistently as possible by generating it directly from an 242 attached software descriptor resource. 244 5.2. urn:ietf:params:rolie:property:swd:swversion 246 This property provides an exposure point for the version of the 247 software being described. This value should be generated or taken 248 from the software descriptor linked to by the entry. This helps 249 avoid, but does not prevent, inconsistent versioning schemes being 250 shared. 252 5.3. urn:ietf:params:rolie:property:swd:swcreator 254 This property provides an exposure point for a plain text name of the 255 creator of the software being described. This is in many cases an 256 organization or company, but certainly could be a single person. 257 Most software descriptor formats include this information, and where 258 possible, this property should be set equal to that value. 260 6. Data format requirements 262 This section defines usage guidance and additional requirements 263 related to data formats above and beyond those specified in 264 [RFC8322]. The following formats are expected to be commonly used to 265 express software descriptor information. For this reason, this 266 document specifies additional requirements to ensure 267 interoperability. 269 6.1. The ISO SWID 2015 format 271 6.1.1. Description 273 ISO/IEC 19770-2:2015 defines a software record data format referred 274 to as a "SWID Tag". It provides several tag types: 276 o primary: provides descriptive and naming information about 277 software, 279 o patch: describes non-standalone software meant to patch existing 280 software, 282 o corpus:describes the software installation media that installs a 283 given piece of software, 285 o supplemental: provides additional metadata to be deployed 286 alongside a tag. 288 For a more complete overview as well as normative requirements, refer 289 to ISO/IEC 19770-2:2015 [SWID]. 291 For additional requirements and guidance around creation of SWID 292 Tags, consult NIST Internal Report 8060 [NISTIR8060]. 294 6.1.2. Requirements 296 For an Entry to be considered as a "SWID Tag Entry", it MUST fulfill 297 the following conditions: 299 o The information-type of the Entry is "software-descriptor". For a 300 typical Entry, this is derived from the information type of the 301 Feed it is contained in. For a standalone Entry, this is provided 302 by an "atom:category" element. 304 o The document linked to by the "href" attribute of the 305 "atom:content" element is a 2015 SWID Tag as per ISO/IEC 306 19770-2:2015. 308 A "SWID Tag Entry" MUST conform to the following requirements: 310 o The value of the "type" attribute of the "atom:content" element 311 MUST be "application/swid2015+xml"[TODO]. 313 o There MUST be one "rolie:property" with the "name" attribute equal 314 to "urn:ietf:params:rolie:property:content-id" and the "value" 315 attribute exactly equal to the "" element in the attached 316 SWID Tag. This allows for ROLIE consumers to more easily search 317 for SWID tags without needing to download the tag itself. 319 o There MUST be one "rolie:property" with the "name" attribute equal 320 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 321 attribute equal to the value of the "" element in the 322 attached SWID Tag. As above, this field aids ROLIE consumers in 323 search and filtering Entries. 325 o There MAY be a property element with the "name" attribute equal to 326 "urn:ietf:params:rolie:property:swd:swversion". When this 327 property appears, it's value MUST be equal to the value of the 328 "TODO-version" element in the attached SWID Tag. 330 6.2. The Concise SWID format 331 6.2.1. Description 333 The Concise SWID (COSWID) format is an alternative representation of 334 the SWID Tag format using a Concise Binary Object Representation 335 (CBOR) encoding. This provides the format with a reduced size that 336 is more suitable for constrained devices. It provides the same 337 features and attributes as are specified in ISO 19770-2:2015, plus: 339 o a straight forward method to sign and encrypt using COSE, and 341 o additional attributes that provide an improved structure to 342 include file hashes intended to be used as Reference Integrity 343 Measurements (RIM). 345 For more information and the complete specification, refer to the 346 COSWID internet draft [I-D.ietf-sacm-coswid]. 348 6.2.2. Requirements 350 For an Entry to be considered as a "COSWID Tag Entry", it MUST 351 fulfill the following conditions: 353 o The information-type of the Entry is "software-descriptor". For a 354 typical Entry, this is derived from the information-type of the 355 Feed it is contained in. For a standalone Entry, this is provided 356 by an "atom:category" element. 358 o The document linked to by the "href" attribute of the 359 "atom:content" element is a COSWID Tag as per 360 [I-D.ietf-sacm-coswid] 362 A "COSWID Tag Entry" MUST conform to the following requirements: 364 o The value of the "type" attribute of the atom:content element MUST 365 be "application/coswid+cbor". 367 o There MUST be one "rolie:property" with the "name" attribute equal 368 to "urn:ietf:params:rolie:property:content-id" and the "value" 369 attribute exactly equal to the "tag-id" element in the attached 370 COSWID Tag. This allows for ROLIE consumers to more easily search 371 for COSWID tags without needing to download the tag itself. 373 o There MUST be one "rolie:property" with the "name" attribute equal 374 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 375 attribute equal to the value of the "swid-name" element in the 376 attached COSWID Tag. As above, this field aids ROLIE consumers in 377 searching and filtering Entries. 379 o There MAY be a property element with the "name" attribute equal to 380 "urn:ietf:params:rolie:property:swd:swversion". When this 381 property appears, it's value MUST be equal to the value of the 382 "TODO-version" element in the attached COSWID Tag. 384 7. atom:link Extensions 386 This section defines additional link relationships that 387 implementations MUST support. These relationships are not registered 388 in the Link Relation IANA table as their use case is too narrow. 389 Each relationship is named and described. 391 These relations come in related pairs. The first of each pair is 392 expected to be more common, as they can be determined at the time 393 that the Entry is created. The second of each pair will often need 394 to be added retroactively to an Entry. 396 +----------------------+--------------------------------------------+ 397 | Name | Description | 398 +----------------------+--------------------------------------------+ 399 | ancestor | Links to a software descriptor resource | 400 | | that defines an ancestor of the software | 401 | | being described by this Entry. This is | 402 | | usually a previous version of the | 403 | | software. | 404 | descendent | Links to a software descriptor resource | 405 | | that defines an descendent of the software | 406 | | being described by this Entry. This is | 407 | | usually a more recent version or edition | 408 | | of the software. | 409 | patches | Links to a software descriptor resource | 410 | | that defines the software being patched by | 411 | | this software | 412 | patchedby | Links to a software descriptor resource | 413 | | that defines the patch or update itself | 414 | | that can be or has been applied to this | 415 | | software. | 416 | requires | Links to a software descriptor resource | 417 | | that defines a piece of software required | 418 | | for this software to function properly, | 419 | | i.e., a dependency. | 420 | requiredBy | Links to a software descriptor resource | 421 | | that defines a piece of software that | 422 | | requires this software to function | 423 | | properly. | 424 | installs | Links to a software descriptor resource | 425 | | that defines the software that is | 426 | | installed by this software. | 427 | installedBy | Links to a software descriptor resource | 428 | | that defines the software package that | 429 | | installs this software. | 430 | patchesVulnerability | Links to a vulnerability that this | 431 | | software update fixes. Used for software | 432 | | descriptors that are describing software | 433 | | patches or updates. | 434 | hasVulnerability | Links to a vulnerability description | 435 | | object that details a vulnerability that | 436 | | this software has. | 437 +----------------------+--------------------------------------------+ 439 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 440 Exchange 442 8. IANA Considerations 444 8.1. Media Type Registrations 446 8.1.1. ISO SWID 448 This document registers a MIME Type for the SWID Tag format. The 449 registration is as follows 451 MIME media type name: application 453 MIME subtype name: swid2015+xml 455 Mandatory parameters: None. 457 Optional parameters: "charset": This parameter has semantics 458 identical to the charset parameter of the "application/xml" media 459 type as specified in [RFC3023]. 461 Encoding considerations: Identical to those of "application/xml" as 462 described in [RFC3023], Section 3.2. 464 Security considerations: As defined in this specification, and in 465 [RFC8322]. In addition, as this media type uses the "+xml" 466 convention, it shares the same security considerations as described 467 in [RFC3023], Section 10. 469 Interoperability considerations: There are no known interoperability 470 issues. 472 Published specification: This specification. 474 Applications that use this media type: No known applications 475 currently use this media type. 477 Additional information: 479 Magic number(s): As specified for "application/xml" in [RFC3023], 480 Section 3.2. 482 File extension: .swidtag 484 Fragment identifiers: As specified for "application/xml" in 485 [RFC3023], Section 5. 487 Base URI: As specified in [RFC3023], Section 6. 489 Macintosh File Type code: TEXT 490 Person and email address to contact for further information: Stephen 491 Banghart 493 Intended usage: COMMON 495 Author/Change controller: IESG 497 8.2. software-descriptor information-type 499 IANA has added an entry to the "ROLIE Security Resource Information 500 Type Sub-Registry" registry located at 501 . 503 The entry is as follows: 505 name: software-descriptor 507 index: TBD 509 reference: This document, Section 4 511 8.3. swd:swname property 513 IANA has added an entry to the "ROLIE URN Parameters" registry 514 located in . 516 The entry is as follows: 518 name: property:swd:swname 520 Extension IRI: urn:ietf:params:rolie:property:swd:swname 522 Reference: This document, Section 5.1 524 Subregistry: None 526 8.4. swd:swversion property 528 IANA has added an entry to the "ROLIE URN Parameters" registry 529 located in . 531 The entry is as follows: 533 name: property:swd:swversion 535 Extension IRI: urn:ietf:params:rolie:property:swd:swversion 537 Reference: This document, Section 5.1 538 Subregistry: None 540 8.5. swd:swcreator property 542 IANA has added an entry to the "ROLIE URN Parameters" registry 543 located in . 545 The entry is as follows: 547 name: property:swd:swcreator 549 Extension IRI: urn:ietf:params:rolie:property:swd:swcreator 551 Reference: This document, Section 5.1 553 Subregistry: None 555 9. Security Considerations 557 Use of this extension implies dealing with the security implications 558 of both ROLIE and of software descriptors in general. As with any 559 data, care should be taken to verify the trustworthiness and veracity 560 of the descriptor information to the fullest extent possible. 562 Ideally, software descriptors should have been signed by the software 563 manufacturer, or signed by whichever agent processed the source code. 564 Software descriptor documents from these sources are more likely to 565 be accurate than those generated by scraping installed software. 567 These "authoritative" sources of software descriptor content should 568 consider additional security for their ROLIE repository beyond the 569 typical recommendations, as the central importance of the repository 570 is likely to make it a target. 572 Version information is often represented differently across 573 manufacturers and even across product releases. If using software 574 version information for low fault tolerance comparisons and searches, 575 care should be taken that the correct version scheme is being 576 utilized. 578 10. Normative References 580 [I-D.ietf-sacm-coswid] 581 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 582 Waltermire, "Concise Software Identifiers", draft-ietf- 583 sacm-coswid-06 (work in progress), July 2018. 585 [NISTIR8060] 586 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 587 "Guidelines for the Creation of Interoperable Software 588 Identification (SWID) Tags", NISTIR 8060, April 2016, 589 . 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 597 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 598 . 600 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 601 Object Description Exchange Format", RFC 5070, 602 DOI 10.17487/RFC5070, December 2007, 603 . 605 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 606 Oriented Lightweight Information Exchange (ROLIE)", 607 RFC 8322, DOI 10.17487/RFC8322, February 2018, 608 . 610 [SWID] "Information technology - Software asset management - Part 611 2: Software identification tag", ISO/IEC 19770-2:2015, 612 October 2015. 614 Appendix A. Schema 616 This document does not require any schema extensions. 618 Appendix B. Examples of Use 620 Use of this extension in a ROLIE repository will not typically change 621 that repository's operation. As such, the general examples provided 622 by the ROLIE core document would serve as examples. Provided below 623 is a sample software descriptor ROLIE entry: 625 626 628 dd786dba-88e6-440b-9158-b8fae67ef67c 629 Sample Software Descriptor 630 2015-08-04T18:13:51.0Z 631 2015-08-05T18:13:51.0Z 632 A descriptor for a piece of software published by this 633 organization. 634 635 636 637 639 642 644 646 648 Authors' Addresses 650 Stephen Banghart 651 National Institute of Standards and Technology 652 100 Bureau Drive 653 Gaithersburg, Maryland 20877 654 USA 656 Email: stephen.banghart@nist.gov 658 David Waltermire 659 National Institute of Standards and Technology 660 100 Bureau Drive 661 Gaithersburg, Maryland 20877 662 USA 664 Email: david.waltermire@nist.gov