idnits 2.17.1 draft-ietf-pkix-ta-mgmt-reqs-00.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 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. 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 (June 20, 2008) is 5782 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: December 22, 2008 Cygnacom Solutions 6 June 20, 2008 8 Trust Anchor Management Requirements 9 draft-ietf-pkix-ta-mgmt-reqs-00 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 December 22, 2008. 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 . . . . . . . . . . . . . . . 11 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 . . . . . . 12 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 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 102 Intellectual Property and Copyright Statements . . . . . . . . . . 18 104 1. Introduction 106 Digital signatures are used in many applications. For digital 107 signatures to provide integrity and authentication, the public key 108 used to verify the digital signature must be "trusted", i.e., 109 accepted by a relying party (RP) as appropriate for use in the given 110 context. A public key used to verify a signature must be configured 111 as a trust anchor or contained in a certificate that can be 112 transitively verified by a certification path terminating at a trust 113 anchor. A Trust Anchor is a public key and associated data used by a 114 relying party to validate a signature on a signed object where the 115 object is either: 117 o a public key certificate that begins a certification path 118 terminated by a signature certificate or encryption certificate 120 o an object (other than a public key certificate) that cannot be 121 validated via use of a certification path 123 Trust anchors have only local significance, i.e., each RP is 124 configured with a set of trust anchors, either by the RP or by an 125 entity that manages TAs in the context in which the RP operates. The 126 associated data defines the scope of a trust anchor by imposing 127 constraints on the signatures the trust anchor may be used to verify. 128 For example, if a trust anchor is used to verify signatures on X.509 129 certificates, these constraints may include a combination of name 130 spaces, certificate policies, or application/usage types. 132 One use of digital signatures is the verification of signatures on 133 firmware packages loaded into hardware modules, such as cryptographic 134 modules, cable boxes, routers, etc. Since such devices are often 135 managed remotely, the devices must be able to authenticate the source 136 of management interactions and can use trust anchors to perform this 137 authentication. However, trust anchors require management as well. 139 All applications that rely upon digital signatures rely upon some 140 means of managing one or more sets of trust anchors. These sets of 141 trust anchors are referred to in this document as trust anchor 142 stores. Often, the means of managing trust anchor stores are 143 application-specific and rely upon out-of-band means to establish and 144 maintain trustworthiness. An application may use multiple trust 145 anchor stores and a given trust anchor store may be used by multiple 146 applications. Trust anchor stores are managed by trust anchor 147 managers. 149 This section provides an introduction and defines basic terminology. 150 Section 2 describes problems with current trust anchor management 151 methods. Sections 3 and 4 describe requirements and security 152 considerations for a trust anchor management solution. 154 1.1. Terminology 156 The following terms are defined in order to provide a vocabulary for 157 describing requirements for trust anchor management. 159 Trust Anchor: A trust anchor represents an authoritative entity via 160 a public key and associated data. The public key is used to 161 verify digital signatures and the associated data is used to 162 constrain the types of information for which the trust anchor is 163 authoritative. A relying party uses trust anchors to determine if 164 a digitally signed object is valid by verifying a digital 165 signature using the trust anchor's public key, and by enforcing 166 the constraints expressed in the associated data for the trust 167 anchor. 169 Trust Anchor Manager: Trust anchor manager is a role responsible 170 for managing the contents of a trust anchor store. Throughout 171 this document, trust anchor managers are assumed to be represented 172 as trust anchors. 174 Trust Anchor Store: A trust anchor store is a set of one or more 175 trust anchors. A trust anchor store may be managed by one or more 176 trust anchor managers. A device may have more than one trust 177 anchor store. 179 2. Problem Statement 181 Trust anchors are used to support many application scenarios. Most 182 Internet browsers and email clients use trust anchors when 183 authenticating TLS sessions, verifying signed email and generating 184 encrypted email by validating a certification path to a server's 185 certificate, an e-mail originator's certificate or an e-mail 186 recipient's certificate. Many software distributions are digitally 187 signed to enable authentication of the software source to be 188 performed prior to installation. Trust anchors that support these 189 applications are typically installed as part of the operating system 190 (OS) or application, installed using an enterprise configuration 191 management system or installed directly by an OS or application user. 193 Trust anchors are typically stored in application-specific or 194 operating system-specific trust anchor stores. Often, a single 195 machine may have a number of different trust anchor stores that may 196 not be synchronized. Reviewing the contents of a particular trust 197 anchor store typically involves use of a proprietary tool that 198 interacts with a particular type of trust store. 200 The presence of a trust anchor in a particular store often conveys 201 implicit authorization to validate signatures for any contexts from 202 which the store is accessed. For example, the public key of a 203 timestamp authority (TSA) may be installed in a trust anchor store to 204 validate signatures on timestamps. However, if the store containing 205 this TA is used by multiple applications that serve different 206 purposes, the same key may be used (inappropriately) to validate 207 other types of objects such as certificates or OCSP responses. There 208 is currently no standard means of limiting the applicability (scope) 209 of a trust anchor except by placing different TAs in different stores 210 and limiting the set of applications that access a given TA store. 212 Trust relationships between PKIs are negotiated by policy 213 authorities. Negotiations frequently require significant time to 214 ensure all participating parties' requirements are satisfied. These 215 requirements are expressed, to some extent, in public key 216 certificates via policy constraints, name constraints and etc. In 217 order for these requirements to be enforced, trust anchor stores must 218 be managed in accord with policy authority intentions and avoid 219 circumventing constraints defined in a cross-certificate by 220 recognizing the subject of the cross certificate as a trust anchor. 222 Trust anchors are often represented as self-signed certificates, 223 which provide no useful means of establishing the validity of the 224 information contained in the certificate. Confidence in the 225 integrity of a trust anchor is typically established through out-of- 226 band means, often by checking the "fingerprint" (one-way hash) of the 227 self-signed certificate with an authoritative source. Routine trust 228 anchor re-key operations typically require similar out-of-band 229 checks. Ideally, only the initial set of trust anchors installed in 230 a particular trust anchor store should require out-of-band 231 verification, particularly when the costs of performing out-of-band 232 checks commensurate with the security requirements of applications 233 using the trust anchor store are high. 235 Despite the prevalent use of trust anchors, there is neither a 236 standard means for discovering which trust anchors installed in a 237 particular trust anchor store nor a standard means of managing those 238 trust anchors. The remainder of this document describes requirements 239 for a solution to this problem along with some security 240 considerations. 242 3. Requirements 244 This section describes the requirements for a trust anchor management 245 protocol. Requirements are provided for trust anchor contents as 246 well as for trust anchor store management operations. 248 3.1. Transport independence 250 3.1.1. Functional Requirements 252 A general-purpose solution for the management of trust anchors must 253 be transport independent in order to apply to a range of device 254 communications environments. It should be applicable in both 255 session-oriented and store-and-forward contexts. Message integrity 256 must be assured in all cases. 258 3.1.2. Rationale 260 Not all devices that use trust anchors are available for online 261 management operations; some devices may require manual interaction 262 for trust anchor management. Message integrity is required to 263 authenticate the originator of a TA management transaction and 264 confirm the authorization of the originator for that transaction. 266 3.2. Basic management operations 268 3.2.1. Functional Requirements 270 At a minimum, a protocol used for trust anchor management must enable 271 a trust anchor manager to perform the following operations: 273 o Determine which trust anchors are installed in a particular trust 274 anchor store 276 o Add one or more trust anchors to a trust anchor store 278 o Remove one or more trust anchors from a trust anchor store 280 o Replace an entire trust anchor store 282 A trust anchor management protocol must provide support for these 283 basic operations, however, not all implementations must support each 284 option. For example, some implementations may only support 285 replacement of trust anchor stores. 287 3.2.2. Rationale 289 These requirements describe the core operations required to manage 290 the contents of a trust anchor store. An edit operation was omitted 291 for sake of simplicity, with consecutive remove and add operations 292 used for this purpose. Add and remove operations are compound to 293 avoid unnecessary round trips and are provided to avoid always 294 replacing an entire trust anchor store. Trust anchor store 295 replacement may be useful as a simple, higher bandwidth alternative 296 to add and remove operations. Many devices and some applications 297 utilize multiple trust anchor stores. Trust anchor store discovery 298 is required to determine which trust anchor stores are present in a 299 particular context. 301 3.3. Management targets 303 3.3.1. Functional Requirements 305 A protocol for TA management must allow a TA management transaction 306 to be directed to: 308 All TA stores for which the manager is responsible 310 An enumerated list of one or more groups of trust anchor stores 312 An individual trust anchor store 314 3.3.2. Rationale 316 Trust anchor configurations may be uniform across an enterprise, or 317 they may be unique to a single application or small set of 318 applications. 320 Connections between PKIs can be accomplished using different means. 321 Unilateral or bilateral cross-certification can be performed, or a 322 community may simply elect to explicitly accept a trust anchor from 323 another community. Typically, these decisions occur at the 324 enterprise level. In some scenarios, it can be useful to establish 325 these connections for a small community within an enterprise. 326 Enterprise-wide mechanisms such as cross-certificates are ill-suited 327 for this purpose since certificate revocation or expiration affects 328 the entire enterprise. A trust anchor management protocol can 329 address this issue by supporting limited installation of trust 330 anchors and by supporting expression of constraints on trust anchor 331 usage. Limited installation requires the ability to identify the 332 members of the community that are authorized to rely upon a 333 particular trust anchor, as well as the ability to query and report 334 on the contents of trust anchor stores. The trust anchor constraints 335 can represent the limitations that would have been expressed in a 336 cross-certificate and limited installation ensures the recognition of 337 the trust anchor does not necessarily encompass an entire enterprise. 339 3.4. Delegation of TA Management Authority 341 3.4.1. Functional Requirements 343 A trust anchor management protocol must enable secure transfer of 344 control of a trust anchor store from one trust anchor manager to 345 another. It must also enable delegation for specific operations 346 without requiring delegation of the overall trust anchor management 347 capability itself. 349 3.4.2. Rationale 351 Trust anchor re-key is one type of transfer that must be supported. 352 In this case, the new key will be assigned the same privileges as the 353 old key. Creation of trust anchors for specific purposes, such as 354 firmware signing, is another example of delegation. For example, a 355 trust anchor manager may delegate only the authority to sign firmware 356 and disallow further delegation of the privilege, or the trust anchor 357 manager may allow its delegate to delegate firmware signing to other 358 entities. 360 3.5. RFC 5280 Support 362 3.5.1. Functional Requirements 364 A trust anchor management protocol must enable management of trust 365 anchors that can be used to validate certification paths in 366 accordance with [RFC5280] and [RFC5055]. A trust anchor format must 367 enable the representation of constraints that influence certification 368 path validation or otherwise establish the scope of usage of the 369 trust anchor public key. Examples of such constraints are name 370 constraints, certificate policies and key usage. 372 3.5.2. Rationale 374 Certification path validation is one of the most common applications 375 of trust anchors. The rules for using trust anchors for path 376 validation are established in [RFC5280]. [RFC5055] describes the use 377 of trust anchors for delegated path validation. 379 3.6. Support Purposes Other Than Certification Path Validation 380 3.6.1. Functional Requirements 382 A trust anchor management protocol must enable management of trust 383 anchors that can be used for purposes other than certification path 384 validation, including trust anchors that cannot be used for 385 certification path validation. It should be possible to authorize a 386 trust anchor to delegate authority (to other TAs or certificate 387 holders) and to prevent a trust anchor from delegating authority. 389 3.6.2. Rationale 391 Trust anchors are used to validate a variety of objects other than 392 public key certificates and CRLs. For example, a trust anchor may be 393 used to verify firmware packages [RFC4108], OCSP responses [RFC2560], 394 SCVP responses [RFC5055] or timestamps [RFC3161]. TAs authorized for 395 these operations may not be authorized to sign public key 396 certificates or CRLs. 398 3.7. Trust Anchor Format 400 3.7.1. Functional Requirements 402 Minimally, a trust anchor management protocol must support management 403 of trust anchors represented as self-signed certificates or as a 404 distinguished name and public key information. The definition of a 405 trust anchor must include a public key, a public key algorithm and, 406 if necessary, public key parameters. When the public key is used to 407 validate certification paths, a distinguished name also must be 408 included per [RFC3852]. A trust anchor format should enable 409 specification of public key identifier to enable other applications 410 of the trust anchor, for example, verification of data signed using 411 the Cryptographic Message Syntax (CMS) SignedData structure 412 [RFC3852]. A trust anchor format should also enable the use of 413 constraints that can be applied to specify the type/usage of a trust 414 anchor. 416 3.7.2. Rationale 418 There is no standardized format for trust anchors. Self-signed X.509 419 certificates are typically used but [RFC5280] does not mandate a 420 particular trust anchor representation. It requires only that a 421 trust anchor's public key information and distinguished name be 422 available during certification path validation. CMS is widely used 423 to protect a variety of types of content using digital signatures, 424 including contents that may verified directly using a trust anchor, 425 such as firmware packages [RFC4108]. 427 3.8. Authentication of Trust Anchor Store Contents 429 3.8.1. Functional Requirements 431 A trust anchor manager must be able to authenticate which trust 432 anchor store produced a report listing the contents of the trust 433 anchor store and be able to confirm the contents of the report have 434 not been subsequently altered. Replay of old reports (from the same 435 trust anchor store) must be detectable by a TA manager. 437 3.8.2. Rationale 439 Authentication of trust anchor store-generated reports is required to 440 support remote management operations. 442 3.9. Source Authentication 444 3.9.1. Functional Requirements 446 An entity receiving trust anchor management data must be able to 447 authenticate the party providing the information and must be able to 448 confirm the party is authorized to provide that trust anchor 449 information. 451 3.9.2. Rationale 453 A trust anchor manager may be authorized to participate in trust 454 anchor management protocol exchanges, but be limited to managing 455 trust anchors within a particular scope. Alternatively, a trust 456 anchor manager may be authorized to participate in trust anchor 457 management protocol exchanges without any constraints on the types of 458 trust anchors that may be managed. 460 3.10. Reduce Reliance on Out-of-Band Trust Mechanisms 462 3.10.1. Functional Requirements 464 A trust anchor management protocol should enable TA integrity to be 465 checked automatically without relying on out-of-band trust 466 mechanisms. 468 3.10.2. Rationale 470 Traditionally, a trust anchor is distributed out-of-band with its 471 integrity checked manually prior to installation. Installation 472 typically is performed by anyone with sufficient administrative 473 privilege on the system receiving the trust anchor. Reliance on out- 474 of-band trust mechanisms is one problem with current trust anchor 475 management approaches and reduction of the need to use out-of-band 476 trust mechanisms is a primary motivation for developing a trust 477 anchor management protocol. Ideally, out-of-band trust mechanisms 478 will be required only during trust anchor store initialization. 480 3.11. Replay Detection 482 3.11.1. Functional Requirements 484 A trust anchor management protocol must enable participants engaged 485 in a trust anchor management protocol exchange to detect replay 486 attacks. Replay detection mechanisms should not introduce a 487 requirement for a reliable source of time as some devices that 488 utilize trust anchors have no access to a reliable source of time. 490 3.11.2. Rationale 492 Replay of old trust anchor management messages could result in the 493 addition of compromised trust anchors to a trust anchor store, 494 potentially exposing applications to malicious signed objects or 495 certification paths. 497 3.12. Compromise or Disaster Recovery 499 3.12.1. Functional Requirements 501 A trust anchor management protocol must enable recovery from the 502 compromise or loss of a trust anchor private key, including the 503 private key authorized to serve as a source of trust anchor 504 information. 506 3.12.2. Rationale 508 Compromise or loss of a private key corresponding to a trust anchor 509 can have significant negative consequences. Currently, in some 510 cases, re-initialization of all effected trust anchor stores is 511 required to recover from a lost or compromised trust anchor key. A 512 trust anchor management protocol should support recovery options that 513 do not require trust anchor store re-initialization. 515 4. Security Considerations 517 The public key used to authenticate a TA management transaction may 518 have been placed in the client as the result of an earlier TA 519 management transaction or during an initial bootstrap configuration 520 operation. In most scenarios, at least one public key authorized for 521 trust anchor management must be placed in each trust anchor store to 522 be managed during the initial configuration of the trust anchor 523 store. This public key may be transported and checked using out-of- 524 band means. In all scenarios, regardless of the authentication 525 mechanism, at least one trust anchor manager must be established for 526 each trust anchor store during the initial configuration of the trust 527 anchor store. 529 Many of the security considerations from [RFC5280] are also 530 applicable to trust anchor management. 532 5. IANA Considerations 534 None. Please remove this section prior to publication as an RFC. 536 6. References 538 6.1. Normative References 540 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 541 Housley, R., and W. Polk, "Internet X.509 Public Key 542 Infrastructure Certificate and Certificate Revocation List 543 (CRL) Profile", RFC 5280, May 2008. 545 6.2. Informative References 547 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 548 Adams, "X.509 Internet Public Key Infrastructure Online 549 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 551 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 552 "Internet X.509 Public Key Infrastructure Time-Stamp 553 Protocol (TSP)", RFC 3161, August 2001. 555 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 556 RFC 3852, July 2004. 558 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 559 Protect Firmware Packages", RFC 4108, August 2005. 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 Authors' Addresses 567 Raksha Reddy 568 National Security Agency 569 Suite 6599 570 9800 Savage Road 571 Fort Meade, MD 20755 573 Email: r.reddy@radium.ncsc.mil 575 Carl Wallace 576 Cygnacom Solutions 577 Suite 5200 578 7925 Jones Branch Drive 579 McLean, VA 22102 581 Email: cwallace@cygnacom.com 583 Full Copyright Statement 585 Copyright (C) The IETF Trust (2008). 587 This document is subject to the rights, licenses and restrictions 588 contained in BCP 78, and except as set forth therein, the authors 589 retain all their rights. 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 594 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 595 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Intellectual Property 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org.