idnits 2.17.1 draft-ietf-pkix-ta-mgmt-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 3, 2008) is 5677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Reddy 3 Internet-Draft National Security Agency 4 Intended status: Informational C. Wallace 5 Expires: April 6, 2009 Cygnacom Solutions 6 October 3, 2008 8 Trust Anchor Management Requirements 9 draft-ietf-pkix-ta-mgmt-reqs-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 6, 2009. 36 Abstract 38 A trust anchor represents an authoritative entity via a public key 39 and associated data. The public key is used to verify digital 40 signatures and the associated data is used to constrain the types of 41 information for which the trust anchor is authoritative. A relying 42 party uses trust anchors to determine if a digitally signed object is 43 valid by verifying a digital signature using the trust anchor's 44 public key, and by enforcing the constraints expressed in the 45 associated data for the trust anchor. This document describes some 46 of the problems associated with the lack of a standard trust anchor 47 management mechanism and defines requirements for data formats and 48 protocols designed to address these problems. This document 49 discusses only public keys as trust anchors; symmetric key trust 50 anchors are not considered. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1. Transport independence . . . . . . . . . . . . . . . . . . 8 59 3.1.1. Functional Requirements . . . . . . . . . . . . . . . 8 60 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Basic management operations . . . . . . . . . . . . . . . 8 62 3.2.1. Functional Requirements . . . . . . . . . . . . . . . 8 63 3.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. Management targets . . . . . . . . . . . . . . . . . . . . 9 65 3.3.1. Functional Requirements . . . . . . . . . . . . . . . 9 66 3.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Delegation of TA Management Authority . . . . . . . . . . 10 68 3.4.1. Functional Requirements . . . . . . . . . . . . . . . 10 69 3.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 70 3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 10 71 3.5.1. Functional Requirements . . . . . . . . . . . . . . . 10 72 3.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 73 3.6. Support Purposes Other Than Certification Path 74 Validation . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.6.1. Functional Requirements . . . . . . . . . . . . . . . 10 76 3.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 77 3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 11 78 3.7.1. Functional Requirements . . . . . . . . . . . . . . . 11 79 3.7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 80 3.8. Authentication of Trust Anchor Store Contents . . . . . . 11 81 3.8.1. Functional Requirements . . . . . . . . . . . . . . . 12 82 3.8.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 84 3.9. Source Authentication . . . . . . . . . . . . . . . . . . 12 85 3.9.1. Functional Requirements . . . . . . . . . . . . . . . 12 86 3.9.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 87 3.10. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 12 88 3.10.1. Functional Requirements . . . . . . . . . . . . . . . 12 89 3.10.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 90 3.11. Replay Detection . . . . . . . . . . . . . . . . . . . . . 13 91 3.11.1. Functional Requirements . . . . . . . . . . . . . . . 13 92 3.11.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 93 3.12. Compromise or Disaster Recovery . . . . . . . . . . . . . 13 94 3.12.1. Functional Requirements . . . . . . . . . . . . . . . 13 95 3.12.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 96 3.13. Usage of Trust Anchor Information for Certification 97 Path Validation . . . . . . . . . . . . . . . . . . . . . 13 98 3.13.1. Functional Requirements . . . . . . . . . . . . . . . 13 99 3.13.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 102 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 104 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 106 Intellectual Property and Copyright Statements . . . . . . . . . . 19 108 1. Introduction 110 Digital signatures are used in many applications. For digital 111 signatures to provide integrity and authentication, the public key 112 used to verify the digital signature must be "trusted", i.e., 113 accepted by a relying party (RP) as appropriate for use in the given 114 context. A public key used to verify a signature must be configured 115 as a trust anchor or contained in a certificate that can be 116 transitively verified by a certification path terminating at a trust 117 anchor. A Trust Anchor is a public key and associated data used by a 118 relying party to validate a signature on a signed object where the 119 object is either: 121 o a public key certificate that begins a certification path 122 terminated by a signature certificate or encryption certificate 124 o an object (other than a public key certificate) that cannot be 125 validated via use of a certification path 127 Trust anchors have only local significance, i.e., each RP is 128 configured with a set of trust anchors, either by the RP or by an 129 entity that manages TAs in the context in which the RP operates. The 130 associated data defines the scope of a trust anchor by imposing 131 constraints on the signatures the trust anchor may be used to verify. 132 For example, if a trust anchor is used to verify signatures on X.509 133 certificates, these constraints may include a combination of name 134 spaces, certificate policies, or application/usage types. 136 One use of digital signatures is the verification of signatures on 137 firmware packages loaded into hardware modules, such as cryptographic 138 modules, cable boxes, routers, etc. Since such devices are often 139 managed remotely, the devices must be able to authenticate the source 140 of management interactions and can use trust anchors to perform this 141 authentication. However, trust anchors require management as well. 143 All applications that rely upon digital signatures rely upon some 144 means of managing one or more sets of trust anchors. These sets of 145 trust anchors are referred to in this document as trust anchor 146 stores. Often, the means of managing trust anchor stores are 147 application-specific and rely upon out-of-band means to establish and 148 maintain trustworthiness. An application may use multiple trust 149 anchor stores and a given trust anchor store may be used by multiple 150 applications. Trust anchor stores are managed by trust anchor 151 managers. 153 This section provides an introduction and defines basic terminology. 154 Section 2 describes problems with current trust anchor management 155 methods. Sections 3 and 4 describe requirements and security 156 considerations for a trust anchor management solution. 158 1.1. Terminology 160 The following terms are defined in order to provide a vocabulary for 161 describing requirements for trust anchor management. 163 Trust Anchor: A trust anchor represents an authoritative entity via 164 a public key and associated data. The public key is used to 165 verify digital signatures and the associated data is used to 166 constrain the types of information for which the trust anchor is 167 authoritative. A relying party uses trust anchors to determine if 168 a digitally signed object is valid by verifying a digital 169 signature using the trust anchor's public key, and by enforcing 170 the constraints expressed in the associated data for the trust 171 anchor. 173 Trust Anchor Manager: Trust anchor manager is a role responsible 174 for managing the contents of a trust anchor store. Throughout 175 this document, trust anchor managers are assumed to be represented 176 as trust anchors. 178 Trust Anchor Store: A trust anchor store is a set of one or more 179 trust anchors. A trust anchor store may be managed by one or more 180 trust anchor managers. A device may have more than one trust 181 anchor store. 183 2. Problem Statement 185 Trust anchors are used to support many application scenarios. Most 186 Internet browsers and email clients use trust anchors when 187 authenticating TLS sessions, verifying signed email and generating 188 encrypted email by validating a certification path to a server's 189 certificate, an e-mail originator's certificate or an e-mail 190 recipient's certificate. Many software distributions are digitally 191 signed to enable authentication of the software source to be 192 performed prior to installation. Trust anchors that support these 193 applications are typically installed as part of the operating system 194 (OS) or application, installed using an enterprise configuration 195 management system or installed directly by an OS or application user. 197 Trust anchors are typically stored in application-specific or 198 operating system-specific trust anchor stores. Often, a single 199 machine may have a number of different trust anchor stores that may 200 not be synchronized. Reviewing the contents of a particular trust 201 anchor store typically involves use of a proprietary tool that 202 interacts with a particular type of trust store. 204 The presence of a trust anchor in a particular store often conveys 205 implicit authorization to validate signatures for any contexts from 206 which the store is accessed. For example, the public key of a 207 timestamp authority (TSA) may be installed in a trust anchor store to 208 validate signatures on timestamps. However, if the store containing 209 this TA is used by multiple applications that serve different 210 purposes, the same key may be used (inappropriately) to validate 211 other types of objects such as certificates or OCSP responses. There 212 is currently no standard means of limiting the applicability (scope) 213 of a trust anchor except by placing different TAs in different stores 214 and limiting the set of applications that access a given TA store. 216 Trust relationships between PKIs are negotiated by policy 217 authorities. Negotiations frequently require significant time to 218 ensure all participating parties' requirements are satisfied. These 219 requirements are expressed, to some extent, in public key 220 certificates via policy constraints, name constraints and etc. In 221 order for these requirements to be enforced, trust anchor stores must 222 be managed in accord with policy authority intentions and avoid 223 circumventing constraints defined in a cross-certificate by 224 recognizing the subject of the cross certificate as a trust anchor. 226 Trust anchors are often represented as self-signed certificates, 227 which provide no useful means of establishing the validity of the 228 information contained in the certificate. Confidence in the 229 integrity of a trust anchor is typically established through out-of- 230 band means, often by checking the "fingerprint" (one-way hash) of the 231 self-signed certificate with an authoritative source. Routine trust 232 anchor re-key operations typically require similar out-of-band 233 checks. Ideally, only the initial set of trust anchors installed in 234 a particular trust anchor store should require out-of-band 235 verification, particularly when the costs of performing out-of-band 236 checks commensurate with the security requirements of applications 237 using the trust anchor store are high. 239 Despite the prevalent use of trust anchors, there is neither a 240 standard means for discovering which trust anchors installed in a 241 particular trust anchor store nor a standard means of managing those 242 trust anchors. The remainder of this document describes requirements 243 for a solution to this problem along with some security 244 considerations. 246 3. Requirements 248 This section describes the requirements for a trust anchor management 249 protocol. Requirements are provided for trust anchor contents as 250 well as for trust anchor store management operations. 252 3.1. Transport independence 254 3.1.1. Functional Requirements 256 A general-purpose solution for the management of trust anchors must 257 be transport independent in order to apply to a range of device 258 communications environments. It should be applicable in both 259 session-oriented and store-and-forward contexts. Message integrity 260 must be assured in all cases. 262 3.1.2. Rationale 264 Not all devices that use trust anchors are available for online 265 management operations; some devices may require manual interaction 266 for trust anchor management. Message integrity is required to 267 authenticate the originator of a TA management transaction and 268 confirm the authorization of the originator for that transaction. 270 3.2. Basic management operations 272 3.2.1. Functional Requirements 274 At a minimum, a protocol used for trust anchor management must enable 275 a trust anchor manager to perform the following operations: 277 o Determine which trust anchors are installed in a particular trust 278 anchor store 280 o Add one or more trust anchors to a trust anchor store 282 o Remove one or more trust anchors from a trust anchor store 284 o Replace an entire trust anchor store 286 A trust anchor management protocol must provide support for these 287 basic operations, however, not all implementations must support each 288 option. For example, some implementations may only support 289 replacement of trust anchor stores. 291 3.2.2. Rationale 293 These requirements describe the core operations required to manage 294 the contents of a trust anchor store. An edit operation was omitted 295 for sake of simplicity, with consecutive remove and add operations 296 used for this purpose. Add and remove operations are compound to 297 avoid unnecessary round trips and are provided to avoid always 298 replacing an entire trust anchor store. Trust anchor store 299 replacement may be useful as a simple, higher bandwidth alternative 300 to add and remove operations. Many devices and some applications 301 utilize multiple trust anchor stores. 303 3.3. Management targets 305 3.3.1. Functional Requirements 307 A protocol for TA management must allow a TA management transaction 308 to be directed to: 310 All TA stores for which the manager is responsible 312 An enumerated list of one or more groups of trust anchor stores 314 An individual trust anchor store 316 3.3.2. Rationale 318 Trust anchor configurations may be uniform across an enterprise, or 319 they may be unique to a single application or small set of 320 applications. 322 Connections between PKIs can be accomplished using different means. 323 Unilateral or bilateral cross-certification can be performed, or a 324 community may simply elect to explicitly accept a trust anchor from 325 another community. Typically, these decisions occur at the 326 enterprise level. In some scenarios, it can be useful to establish 327 these connections for a small community within an enterprise. 328 Enterprise-wide mechanisms such as cross-certificates are ill-suited 329 for this purpose since certificate revocation or expiration affects 330 the entire enterprise. A trust anchor management protocol can 331 address this issue by supporting limited installation of trust 332 anchors and by supporting expression of constraints on trust anchor 333 usage. Limited installation requires the ability to identify the 334 members of the community that are authorized to rely upon a 335 particular trust anchor, as well as the ability to query and report 336 on the contents of trust anchor stores. The trust anchor constraints 337 can represent the limitations that would have been expressed in a 338 cross-certificate and limited installation ensures the recognition of 339 the trust anchor does not necessarily encompass an entire enterprise. 341 3.4. Delegation of TA Management Authority 343 3.4.1. Functional Requirements 345 A trust anchor management protocol must enable secure transfer of 346 control of a trust anchor store from one trust anchor manager to 347 another. It must also enable delegation for specific operations 348 without requiring delegation of the overall trust anchor management 349 capability itself. 351 3.4.2. Rationale 353 Trust anchor re-key is one type of transfer that must be supported. 354 In this case, the new key will be assigned the same privileges as the 355 old key. Creation of trust anchors for specific purposes, such as 356 firmware signing, is another example of delegation. For example, a 357 trust anchor manager may delegate only the authority to sign firmware 358 and disallow further delegation of the privilege, or the trust anchor 359 manager may allow its delegate to delegate firmware signing to other 360 entities. 362 3.5. RFC 5280 Support 364 3.5.1. Functional Requirements 366 A trust anchor management protocol must enable management of trust 367 anchors that can be used to validate certification paths in 368 accordance with [RFC5280] and [RFC5055]. A trust anchor format must 369 enable the representation of constraints that influence certification 370 path validation or otherwise establish the scope of usage of the 371 trust anchor public key. Examples of such constraints are name 372 constraints, certificate policies and key usage. 374 3.5.2. Rationale 376 Certification path validation is one of the most common applications 377 of trust anchors. The rules for using trust anchors for path 378 validation are established in [RFC5280]. [RFC5055] describes the use 379 of trust anchors for delegated path validation. 381 3.6. Support Purposes Other Than Certification Path Validation 383 3.6.1. Functional Requirements 385 A trust anchor management protocol must enable management of trust 386 anchors that can be used for purposes other than certification path 387 validation, including trust anchors that cannot be used for 388 certification path validation. It should be possible to authorize a 389 trust anchor to delegate authority (to other TAs or certificate 390 holders) and to prevent a trust anchor from delegating authority. 392 3.6.2. Rationale 394 Trust anchors are used to validate a variety of objects other than 395 public key certificates and CRLs. For example, a trust anchor may be 396 used to verify firmware packages [RFC4108], OCSP responses [RFC2560], 397 SCVP responses [RFC5055] or timestamps [RFC3161]. TAs authorized for 398 these operations may not be authorized to sign public key 399 certificates or CRLs. 401 3.7. Trust Anchor Format 403 3.7.1. Functional Requirements 405 Minimally, a trust anchor management protocol must support management 406 of trust anchors represented as self-signed certificates and trust 407 anchors represented as a distinguished name and public key 408 information. The definition of a trust anchor must include a public 409 key, a public key algorithm and, if necessary, public key parameters. 410 When the public key is used to validate certification paths, a 411 distinguished name also must be included per [RFC3852]. A trust 412 anchor format should enable specification of public key identifier to 413 enable other applications of the trust anchor, for example, 414 verification of data signed using the Cryptographic Message Syntax 415 (CMS) SignedData structure [RFC3852]. A trust anchor format should 416 also enable the use of constraints that can be applied to specify the 417 type/usage of a trust anchor. 419 3.7.2. Rationale 421 There is no standardized format for trust anchors. Self-signed X.509 422 certificates are typically used but [RFC5280] does not mandate a 423 particular trust anchor representation. It requires only that a 424 trust anchor's public key information and distinguished name be 425 available during certification path validation. CMS is widely used 426 to protect a variety of types of content using digital signatures, 427 including contents that may verified directly using a trust anchor, 428 such as firmware packages [RFC4108]. 430 3.8. Authentication of Trust Anchor Store Contents 431 3.8.1. Functional Requirements 433 A trust anchor manager must be able to authenticate which trust 434 anchor store corresponds to a report listing the contents of the 435 trust anchor store and be able to confirm the contents of the report 436 have not been subsequently altered. Replay of old reports (from the 437 same trust anchor store) must be detectable by a TA manager. 439 3.8.2. Rationale 441 Authentication of trust anchor store reports is required to support 442 remote management operations. 444 3.9. Source Authentication 446 3.9.1. Functional Requirements 448 An entity receiving trust anchor management data must be able to 449 authenticate the party providing the information and must be able to 450 confirm the party is authorized to provide that trust anchor 451 information. 453 3.9.2. Rationale 455 A trust anchor manager may be authorized to participate in trust 456 anchor management protocol exchanges, but be limited to managing 457 trust anchors within a particular scope. Alternatively, a trust 458 anchor manager may be authorized to participate in trust anchor 459 management protocol exchanges without any constraints on the types of 460 trust anchors that may be managed. 462 3.10. Reduce Reliance on Out-of-Band Trust Mechanisms 464 3.10.1. Functional Requirements 466 A trust anchor management protocol should enable TA integrity to be 467 checked automatically without relying on out-of-band trust 468 mechanisms. 470 3.10.2. Rationale 472 Traditionally, a trust anchor is distributed out-of-band with its 473 integrity checked manually prior to installation. Installation 474 typically is performed by anyone with sufficient administrative 475 privilege on the system receiving the trust anchor. Reliance on out- 476 of-band trust mechanisms is one problem with current trust anchor 477 management approaches and reduction of the need to use out-of-band 478 trust mechanisms is a primary motivation for developing a trust 479 anchor management protocol. Ideally, out-of-band trust mechanisms 480 will be required only during trust anchor store initialization. 482 3.11. Replay Detection 484 3.11.1. Functional Requirements 486 A trust anchor management protocol must enable participants engaged 487 in a trust anchor management protocol exchange to detect replay 488 attacks. Replay detection mechanisms should not introduce a 489 requirement for a reliable source of time as some devices that 490 utilize trust anchors have no access to a reliable source of time. 492 3.11.2. Rationale 494 Replay of old trust anchor management messages could result in the 495 addition of compromised trust anchors to a trust anchor store, 496 potentially exposing applications to malicious signed objects or 497 certification paths. 499 3.12. Compromise or Disaster Recovery 501 3.12.1. Functional Requirements 503 A trust anchor management protocol must enable recovery from the 504 compromise or loss of a trust anchor private key, including the 505 private key authorized to serve as a source of trust anchor 506 information. 508 3.12.2. Rationale 510 Compromise or loss of a private key corresponding to a trust anchor 511 can have significant negative consequences. Currently, in some 512 cases, re-initialization of all effected trust anchor stores is 513 required to recover from a lost or compromised trust anchor key. A 514 trust anchor management protocol should support recovery options that 515 do not require trust anchor store re-initialization. 517 3.13. Usage of Trust Anchor Information for Certification Path 518 Validation 520 3.13.1. Functional Requirements 522 RFC5280 requires subject name and public key and leaves the usage of 523 other information, such as name constraints extensions, as optional. 524 Where a trust anchor management protocol is used, constraints must be 525 observed if included in a trust anchor. 527 3.13.2. Rationale 529 Inclusion of constraints in trust anchor objects is optional. Where 530 constraints are established by a trust anchor manager using a trust 531 anchor management protocol, there must exist an expectation of 532 enforcement to ensure consistent behavior across applications. 533 Legacy considerations prevent requiring enforcement in all cases 534 where a trust anchor is used. 536 4. Security Considerations 538 The public key used to authenticate a TA management transaction may 539 have been placed in the client as the result of an earlier TA 540 management transaction or during an initial bootstrap configuration 541 operation. In most scenarios, at least one public key authorized for 542 trust anchor management must be placed in each trust anchor store to 543 be managed during the initial configuration of the trust anchor 544 store. This public key may be transported and checked using out-of- 545 band means. In all scenarios, regardless of the authentication 546 mechanism, at least one trust anchor manager must be established for 547 each trust anchor store during the initial configuration of the trust 548 anchor store. 550 Many of the security considerations from [RFC5280] are also 551 applicable to trust anchor management. 553 5. IANA Considerations 555 None. Please remove this section prior to publication as an RFC. 557 6. References 559 6.1. Normative References 561 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 562 Polk, "Server-Based Certificate Validation Protocol 563 (SCVP)", RFC 5055, December 2007. 565 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 566 Housley, R., and W. Polk, "Internet X.509 Public Key 567 Infrastructure Certificate and Certificate Revocation List 568 (CRL) Profile", RFC 5280, May 2008. 570 6.2. Informative References 572 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 573 Adams, "X.509 Internet Public Key Infrastructure Online 574 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 576 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 577 "Internet X.509 Public Key Infrastructure Time-Stamp 578 Protocol (TSP)", RFC 3161, August 2001. 580 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 581 RFC 3852, July 2004. 583 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 584 Protect Firmware Packages", RFC 4108, August 2005. 586 Authors' Addresses 588 Raksha Reddy 589 National Security Agency 590 Suite 6599 591 9800 Savage Road 592 Fort Meade, MD 20755 594 Email: r.reddy@radium.ncsc.mil 596 Carl Wallace 597 Cygnacom Solutions 598 Suite 5200 599 7925 Jones Branch Drive 600 McLean, VA 22102 602 Email: cwallace@cygnacom.com 604 Full Copyright Statement 606 Copyright (C) The IETF Trust (2008). 608 This document is subject to the rights, licenses and restrictions 609 contained in BCP 78, and except as set forth therein, the authors 610 retain all their rights. 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 615 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 616 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 617 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Intellectual Property 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org.