idnits 2.17.1 draft-ietf-pkix-ta-mgmt-reqs-02.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 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. 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 30, 2008) is 5649 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: May 3, 2009 Cygnacom Solutions 6 October 30, 2008 8 Trust Anchor Management Requirements 9 draft-ietf-pkix-ta-mgmt-reqs-02 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 May 3, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A trust anchor represents an authoritative entity via a public key 43 and associated data. The public key is used to verify digital 44 signatures and the associated data is used to constrain the types of 45 information for which the trust anchor is authoritative. A relying 46 party uses trust anchors to determine if a digitally signed object is 47 valid by verifying a digital signature using the trust anchor's 48 public key, and by enforcing the constraints expressed in the 49 associated data for the trust anchor. This document describes some 50 of the problems associated with the lack of a standard trust anchor 51 management mechanism and defines requirements for data formats and 52 protocols designed to address these problems. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. Transport independence . . . . . . . . . . . . . . . . . . 8 62 3.1.1. Functional Requirements . . . . . . . . . . . . . . . 8 63 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Basic management operations . . . . . . . . . . . . . . . 8 65 3.2.1. Functional Requirements . . . . . . . . . . . . . . . 8 66 3.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 67 3.3. Management targets . . . . . . . . . . . . . . . . . . . . 9 68 3.3.1. Functional Requirements . . . . . . . . . . . . . . . 9 69 3.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 70 3.4. Delegation of TA Manager Authority . . . . . . . . . . . . 10 71 3.4.1. Functional Requirements . . . . . . . . . . . . . . . 10 72 3.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 73 3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 10 74 3.5.1. Functional Requirements . . . . . . . . . . . . . . . 10 75 3.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 76 3.6. Support Purposes Other Than Certification Path 77 Validation . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.6.1. Functional Requirements . . . . . . . . . . . . . . . 11 79 3.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 80 3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 11 81 3.7.1. Functional Requirements . . . . . . . . . . . . . . . 11 82 3.7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 83 3.8. Source Authentication . . . . . . . . . . . . . . . . . . 12 84 3.8.1. Functional Requirements . . . . . . . . . . . . . . . 12 85 3.8.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 86 3.9. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 12 87 3.9.1. Functional Requirements . . . . . . . . . . . . . . . 12 88 3.9.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 89 3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 13 90 3.10.1. Functional Requirements . . . . . . . . . . . . . . . 13 91 3.10.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 92 3.11. Compromise or Disaster Recovery . . . . . . . . . . . . . 13 93 3.11.1. Functional Requirements . . . . . . . . . . . . . . . 13 94 3.11.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 95 3.12. Usage of Trust Anchor Information for Certification 96 Path Validation . . . . . . . . . . . . . . . . . . . . . 14 97 3.12.1. Functional Requirements . . . . . . . . . . . . . . . 14 98 3.12.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 99 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 101 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 103 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 105 Intellectual Property and Copyright Statements . . . . . . . . . . 19 107 1. Introduction 109 Digital signatures are used in many applications. For digital 110 signatures to provide integrity and authentication, the public key 111 used to verify the digital signature must be "trusted", i.e., 112 accepted by a relying party (RP) as appropriate for use in the given 113 context. A public key used to verify a signature must be configured 114 as a trust anchor (TA) or contained in a certificate that can be 115 transitively verified by a certification path terminating at a trust 116 anchor. A Trust Anchor is a public key and associated data used by a 117 relying party to validate a signature on a signed object where the 118 object is either: 120 o a public key certificate that begins a certification path 121 terminated by a signature certificate or encryption certificate 123 o an object, other than a public key certificate or certificate 124 revocation list (CRL), that cannot be validated via use of a 125 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. 142 Other applications requiring trust anchor management include web 143 browsers, which use trust anchors when authenticating web servers, 144 and email clients, which use trust anchors when validating signed 145 email and when authenticating recipients of encrypted email. 147 All applications that rely upon digital signatures rely upon some 148 means of managing one or more sets of trust anchors. Each set of 149 trust anchors is referred to in this document as a trust anchor 150 store. Often, the means of managing trust anchor stores are 151 application-specific and rely upon out-of-band means to establish and 152 maintain trustworthiness. An application may use multiple trust 153 anchor stores and a given trust anchor store may be used by multiple 154 applications. Each trust anchor store is managed by at least one TA 155 manager; a TA manager may manage multiple TA stores. 157 This section provides an introduction and defines basic terminology. 158 Section 2 describes problems with current trust anchor management 159 methods. Sections 3 and 4 describe requirements and security 160 considerations for a trust anchor management solution. 162 1.1. Terminology 164 The following terms are defined in order to provide a vocabulary for 165 describing requirements for trust anchor management. 167 Trust Anchor: A trust anchor represents an authoritative entity via 168 a public key and associated data. The public key is used to 169 verify digital signatures and the associated data is used to 170 constrain the types of information for which the trust anchor is 171 authoritative. A relying party uses trust anchors to determine if 172 a digitally signed object is valid by verifying a digital 173 signature using the trust anchor's public key, and by enforcing 174 the constraints expressed in the associated data for the trust 175 anchor. 177 Trust Anchor Manager: Trust anchor manager is an entity responsible 178 for managing the contents of a trust anchor store. Throughout 179 this document, each trust anchor manager is assumed to be 180 represented as or delegated by a distinct trust anchor. 182 Trust Anchor Store: A trust anchor store is a set of one or more 183 trust anchors stored in a device. A trust anchor store may be 184 managed by one or more trust anchor managers. A device may have 185 more than one trust anchor store, each of which may be used by one 186 or more applications. 188 1.2. Requirements Notation 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 2. Problem Statement 196 Trust anchors are used to support many application scenarios. Most 197 Internet browsers and email clients use trust anchors when 198 authenticating TLS sessions, verifying signed email and generating 199 encrypted email by validating a certification path to a server's 200 certificate, an e-mail originator's certificate or an e-mail 201 recipient's certificate, respectively. Many software distributions 202 are digitally signed to enable authentication of the software source 203 prior to installation. Trust anchors that support these applications 204 are typically installed as part of the operating system (OS) or 205 application, installed using an enterprise configuration management 206 system, or installed directly by an OS or application user. 208 Trust anchors are typically stored in application-specific or 209 operating system-specific trust anchor stores. Often, a single 210 machine may have a number of different trust anchor stores that may 211 not be synchronized. Reviewing the contents of a particular trust 212 anchor store typically involves use of a proprietary tool that 213 interacts with a particular type of trust store. 215 The presence of a trust anchor in a particular store often conveys 216 implicit authorization to validate signatures for any contexts from 217 which the store is accessed. For example, the public key of a 218 timestamp authority (TSA) may be installed in a trust anchor store to 219 validate signatures on timestamps [RFC3161]. However, if the store 220 containing this TA is used by multiple applications that serve 221 different purposes, the same key may be used (inappropriately) to 222 validate other types of objects such as certificates or OCSP 223 responses. Currently, there is no standard general purpose mechanism 224 for limiting the applicability (scope) of a trust anchor. Placing 225 different TAs in different stores and limiting the set of 226 applications that access a given TA store is a common practice to 227 address this problem. 229 Trust relationships between PKIs are negotiated by policy 230 authorities. Negotiations frequently require significant time to 231 ensure all participating parties' requirements are satisfied. These 232 requirements are expressed, to some extent, in public key 233 certificates via policy constraints, name constraints, etc. In order 234 for these requirements to be enforced, trust anchor stores must be 235 managed in accord with policy authority intentions. Otherwise, the 236 constraints defined in a cross-certificate could be circumvented by 237 recognizing the subject of the cross certificate as a trust anchor, 238 which would enable path processing implementations to avoid the 239 cross-certificate. 241 Trust anchors are often represented as self-signed certificates, 242 which provide no useful means of establishing the validity of the 243 information contained in the certificate. Confidence in the 244 integrity of a trust anchor is typically established through out-of- 245 band means, often by checking the "fingerprint" (one-way hash) of the 246 self-signed certificate with an authoritative source. Routine trust 247 anchor re-key operations typically require similar out-of-band 248 checks, though in-band rekey of a trust anchor is supported by the 249 Certificate Management Protocol (CMP) [RFC4210]. Ideally, only the 250 initial set of trust anchors are installed in a particular trust 251 anchor store should require out-of-band verification, particularly 252 when the costs of performing out-of-band checks commensurate with the 253 security requirements of applications using the trust anchor store 254 are high. 256 Despite the prevalent use of trust anchors, there is neither a 257 standard means for discovering the set of trust anchors installed in 258 a particular trust anchor store nor a standard means of managing 259 those trust anchors. The remainder of this document describes 260 requirements for a solution to this problem along with some security 261 considerations. 263 3. Requirements 265 This section describes the requirements for a trust anchor management 266 protocol. Requirements are provided for trust anchor contents as 267 well as for trust anchor store management operations. 269 3.1. Transport independence 271 3.1.1. Functional Requirements 273 A general-purpose solution for the management of trust anchors MUST 274 be transport independent in order to apply to a range of device 275 communications environments. It MUST work in both session-oriented 276 and store-and-forward communications environments as well as in both 277 push and pull distribution models. To accommodate both communication 278 models in a uniform fashion, connectionless integrity and data origin 279 authentication for TA transactions MUST be provided at the 280 application layer. Confidentiality MAY be provided for such 281 transactions. 283 3.1.2. Rationale 285 Not all devices that use trust anchors are available for online 286 management operations; some devices may require manual interaction 287 for trust anchor management. Data origin authentication and 288 integrity are required to ensure that the transaction has not been 289 modified en route. Only connectionless integrity is required, for 290 compatibility with store-and-forward contexts. 292 3.2. Basic management operations 294 3.2.1. Functional Requirements 296 At a minimum, a protocol used for trust anchor management MUST enable 297 a trust anchor manager to perform the following operations: 299 o Determine which trust anchors are installed in a particular trust 300 anchor store 302 o Add one or more trust anchors to a trust anchor store 304 o Remove one or more trust anchors from a trust anchor store 306 o Replace an entire trust anchor store 308 A trust anchor management protocol MUST provide support for these 309 basic operations, however, not all implementations must support each 310 option. For example, some implementations may support only 311 replacement of trust anchor stores. 313 3.2.2. Rationale 315 These requirements describe the core operations required to manage 316 the contents of a trust anchor store. An edit operation was omitted 317 for sake of simplicity, with consecutive remove and add operations 318 used for this purpose. A single add or remove operation can act upon 319 more than one trust anchor to avoid unnecessary round trips and are 320 provided to avoid the need to always replace an entire trust anchor 321 store. Trust anchor store replacement may be useful as a simple, 322 higher bandwidth alternative to add and remove operations. 324 3.3. Management targets 326 3.3.1. Functional Requirements 328 A protocol for TA management MUST allow a TA management transaction 329 to be directed to: 331 All TA stores for which the manager is responsible 333 An enumerated list of one or more named groups of trust anchor 334 stores 336 An individual trust anchor store 338 3.3.2. Rationale 340 Connections between PKIs can be accomplished using different means. 341 Unilateral or bilateral cross-certification can be performed, or a 342 community may simply elect to explicitly accept a trust anchor from 343 another community. Typically, these decisions occur at the 344 enterprise level. In some scenarios, it can be useful to establish 345 these connections for a small community within an enterprise. 346 Enterprise-wide mechanisms such as cross-certificates are ill-suited 347 for this purpose since certificate revocation or expiration affects 348 the entire enterprise. 350 A trust anchor management protocol can address this issue by 351 supporting limited installation of trust anchors (i.e., installation 352 of TAs in subsets of the enterprise user community), and by 353 supporting expression of constraints on trust anchor use by relying 354 parties. Limited installation requires the ability to identify the 355 members of the community that are intended to rely upon a particular 356 trust anchor, as well as the ability to query and report on the 357 contents of trust anchor stores. Trust anchor constraints can be 358 used to represent the limitations that might otherwise be expressed 359 in a cross-certificate, and limited installation ensures the 360 recognition of the trust anchor does not necessarily encompass an 361 entire enterprise. 363 Trust anchor configurations may be uniform across an enterprise, or 364 they may be unique to a single application or small set of 365 applications. Many devices and some applications utilize multiple 366 trust anchor stores. By providing means of addressing a specific 367 store or collections of stores, a trust anchor management protocol 368 can enable efficient management of all stores under a trust anchor 369 manager's control. 371 3.4. Delegation of TA Manager Authority 373 3.4.1. Functional Requirements 375 A trust anchor management protocol MUST enable secure transfer of 376 control of a trust anchor store from one trust anchor manager to 377 another. It also SHOULD enable delegation for specific operations 378 without requiring delegation of the overall trust anchor management 379 capability itself. 381 3.4.2. Rationale 383 Trust anchor manager re-key is one type of transfer that must be 384 supported. In this case, the new key will be assigned the same 385 privileges as the old key. 387 Creation of trust anchors for specific purposes, such as firmware 388 signing, is another example of delegation. For example, a trust 389 anchor manager may delegate only the authority to sign firmware to an 390 entity, but disallow further delegation of that privilege, or the 391 trust anchor manager may allow its delegate to further delegate 392 firmware signing authority to other entities. 394 3.5. RFC 5280 Support 396 3.5.1. Functional Requirements 398 A trust anchor management protocol MUST enable management of trust 399 anchors that will be used to validate certification paths and CRLs in 400 accordance with [RFC5280] and [RFC5055]. A trust anchor format MUST 401 enable the representation of constraints that influence certification 402 path validation or otherwise establish the scope of usage of the 403 trust anchor public key. Examples of such constraints are name 404 constraints, certificate policies, and key usage. 406 3.5.2. Rationale 408 Certification path validation is one of the most common applications 409 of trust anchors. The rules for using trust anchors for path 410 validation are established in [RFC5280]. [RFC5055] describes the use 411 of trust anchors for delegated path validation. Trust anchors used 412 to validate certification paths are responsible for providing, 413 possibly through a delegate, the revocation status information of 414 certificates it issues; this is often accomplished by signing a CRL. 416 3.6. Support Purposes Other Than Certification Path Validation 418 3.6.1. Functional Requirements 420 A trust anchor management protocol MUST enable management of trust 421 anchors that can be used for purposes other than certification path 422 validation, including trust anchors that cannot be used for 423 certification path validation. It SHOULD be possible to authorize a 424 trust anchor to delegate authority (to other TAs or certificate 425 holders) and to prevent a trust anchor from delegating authority. 427 3.6.2. Rationale 429 Trust anchors are used to validate a variety of signed objects, not 430 just public key certificates and CRLs. For example, a trust anchor 431 may be used to verify firmware packages [RFC4108], OCSP responses 432 [RFC2560], SCVP responses [RFC5055] or timestamps [RFC3161]. TAs 433 that are authorized for use with some or all of these other types of 434 operations may not be authorized to verify public key certificates or 435 CRLs. Thus it is important to be able to impose constraints on the 436 ways in which a given TA is employed. 438 3.7. Trust Anchor Format 440 3.7.1. Functional Requirements 442 Minimally, a trust anchor management protocol MUST support management 443 of trust anchors represented as self-signed certificates and trust 444 anchors represented as a distinguished name, public key information 445 and, optionally, associated data. The definition of a trust anchor 446 MUST include a public key, a public key algorithm and, if necessary, 447 public key parameters. When the public key is used to validate 448 certification paths or CRLs, a distinguished name also MUST be 449 included per [RFC5280]. A trust anchor format SHOULD enable 450 specification of a public key identifier to enable other applications 451 of the trust anchor, for example, verification of data signed using 452 the Cryptographic Message Syntax (CMS) SignedData structure 453 [RFC3852]. A trust anchor format also SHOULD enable the 454 representation of constraints that can be applied to restrict the use 455 of a trust anchor. 457 3.7.2. Rationale 459 There is no standardized format for trust anchors. Self-signed X.509 460 certificates are typically used but [RFC5280] does not mandate a 461 particular trust anchor representation. It requires only that a 462 trust anchor's public key information and distinguished name be 463 available during certification path validation. CMS is widely used 464 to protect a variety of types of content using digital signatures, 465 including contents that may verified directly using a trust anchor, 466 such as firmware packages [RFC4108]. Constraints may include a 467 validity period, constraints on certification path validation, etc. 469 3.8. Source Authentication 471 3.8.1. Functional Requirements 473 An entity receiving trust anchor management data MUST be able to 474 authenticate the identity of the party providing the information and 475 MUST be able to confirm the party is authorized to provide that trust 476 anchor information. 478 A trust anchor manager MUST be able to authenticate which trust 479 anchor store corresponds to a report listing the contents of the 480 trust anchor store and be able to confirm the contents of the report 481 have not been subsequently altered. 483 3.8.2. Rationale 485 Data origin authentication and integrity are required to support 486 remote management operations, even when TA management transactions 487 are effected via store-and-forward communications. 489 3.9. Reduce Reliance on Out-of-Band Trust Mechanisms 491 3.9.1. Functional Requirements 493 When performing add operations, a trust anchor management protocol 494 SHOULD enable TA integrity to be checked automatically by a relying 495 party without relying on out-of-band trust mechanisms. 497 3.9.2. Rationale 499 Traditionally, a trust anchor is distributed out-of-band with its 500 integrity checked manually prior to installation. Installation 501 typically is performed by anyone with sufficient administrative 502 privilege on the system receiving the trust anchor. Reliance on out- 503 of-band trust mechanisms is one problem with current trust anchor 504 management approaches and reduction of the need to use out-of-band 505 trust mechanisms is a primary motivation for developing a trust 506 anchor management protocol. Ideally, out-of-band trust mechanisms 507 will be required only during trust anchor store initialization. 509 3.10. Replay Detection 511 3.10.1. Functional Requirements 513 A trust anchor management protocol MUST enable participants engaged 514 in a trust anchor management protocol exchange to detect replay 515 attacks. A replay detection mechanism that does not introduce a 516 requirement for a reliable source of time MUST be available. 517 Mechanisms that do require a reliable source of time MAY be 518 available. 520 3.10.2. Rationale 522 Detection of replays of trust anchor management transaction is 523 required to support remote management operations. Replay of old 524 trust anchor management transaction could result in the 525 reintroduction of compromised trust anchors to a trust anchor store, 526 potentially exposing applications to malicious signed objects or 527 certification paths. 529 Some devices that utilize trust anchors have no access to a reliable 530 source of time, so a replay detection mechanism that requires a 531 reliable time source is insufficient. 533 3.11. Compromise or Disaster Recovery 535 3.11.1. Functional Requirements 537 A trust anchor management protocol MUST enable recovery from the 538 compromise or loss of a trust anchor private key, including the 539 private key authorized to serve as a trust anchor manager, without 540 requiring reinitialization of the trust store. 542 3.11.2. Rationale 544 Compromise or loss of a private key corresponding to a trust anchor 545 can have significant negative consequences. Currently, in some 546 cases, re-initialization of all effected trust anchor stores is 547 required to recover from a lost or compromised trust anchor key. Due 548 to the costs associated with re-initialization, a trust anchor 549 management protocol should support recovery options that do not 550 require trust anchor store re-initialization. 552 3.12. Usage of Trust Anchor Information for Certification Path 553 Validation 555 3.12.1. Functional Requirements 557 RFC 5280 requires that certificate path validation be initialized 558 with a TA subject name and public key, but leaves the use of other 559 information, such as name constraints extensions, as optional. Where 560 a trust anchor management protocol is used, constraints MUST be 561 observed if included in a trust anchor. 563 3.12.2. Rationale 565 Inclusion of constraints in trust anchors is optional. When 566 constraints are explicitly included by a trust anchor manager using a 567 trust anchor management protocol, there exists an expectation that 568 the certificate path validation algorithm will make use of the 569 constraints, to ensure consistent behavior across applications. 570 Legacy considerations prevent requiring enforcement in all cases 571 where a trust anchor is used. 573 4. Security Considerations 575 The public key used to authenticate a TA management transaction may 576 have been placed in the client as the result of an earlier TA 577 management transaction or during an initial bootstrap configuration 578 operation. In most scenarios, at least one public key authorized for 579 trust anchor management must be placed in each trust anchor store to 580 be managed during the initial configuration of the trust anchor 581 store. This public key may be transported and checked using out-of- 582 band means. In all scenarios, regardless of the authentication 583 mechanism, at least one trust anchor manager must be established for 584 each trust anchor store during the initial configuration of the trust 585 anchor store. 587 Compromise of a trust anchor's private key can result in many 588 security problems including issuance of bogus certificates or 589 installation of rogue trust anchors. 591 Usage of trust anchor-based constraints requires great care when 592 defining trust anchors. Errors on the part of a trust anchor manager 593 could result in denial of service or have serious security 594 consequences. For example, if a name constraint for a trust anchor 595 that serves as the root of a PKI includes a typo, denial of service 596 results for certificate holders and relying parties. If a trust 597 anchor manager inadvertently delegates all of its privileges and the 598 delegate subsequently removes the trust anchor manager from trust 599 anchor stores now under its control, recovery may require 600 reinitialization of all effected trust anchor stores. 602 Many of the security considerations from [RFC5280] are also 603 applicable to trust anchor management. 605 5. IANA Considerations 607 None. Please remove this section prior to publication as an RFC. 609 6. References 611 6.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 617 Polk, "Server-Based Certificate Validation Protocol 618 (SCVP)", RFC 5055, December 2007. 620 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 621 Housley, R., and W. Polk, "Internet X.509 Public Key 622 Infrastructure Certificate and Certificate Revocation List 623 (CRL) Profile", RFC 5280, May 2008. 625 6.2. Informative References 627 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 628 Adams, "X.509 Internet Public Key Infrastructure Online 629 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 631 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 632 "Internet X.509 Public Key Infrastructure Time-Stamp 633 Protocol (TSP)", RFC 3161, August 2001. 635 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 636 RFC 3852, July 2004. 638 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 639 Protect Firmware Packages", RFC 4108, August 2005. 641 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 642 "Internet X.509 Public Key Infrastructure Certificate 643 Management Protocol (CMP)", RFC 4210, September 2005. 645 Authors' Addresses 647 Raksha Reddy 648 National Security Agency 649 Suite 6599 650 9800 Savage Road 651 Fort Meade, MD 20755 653 Email: r.reddy@radium.ncsc.mil 655 Carl Wallace 656 Cygnacom Solutions 657 Suite 5200 658 7925 Jones Branch Drive 659 McLean, VA 22102 661 Email: cwallace@cygnacom.com 663 Full Copyright Statement 665 Copyright (C) The IETF Trust (2008). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Intellectual Property 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Acknowledgment 705 Funding for the RFC Editor function is provided by the IETF 706 Administrative Support Activity (IASA).