idnits 2.17.1 draft-ietf-pkix-ta-mgmt-reqs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2010) is 4983 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: February 26, 2011 Cygnacom Solutions 6 August 25, 2010 8 Trust Anchor Management Requirements 9 draft-ietf-pkix-ta-mgmt-reqs-06 11 Abstract 13 A trust anchor represents an authoritative entity via a public key 14 and associated data. The public key is used to verify digital 15 signatures and the associated data is used to constrain the types of 16 information for which the trust anchor is authoritative. A relying 17 party uses trust anchors to determine if a digitally signed object is 18 valid by verifying a digital signature using the trust anchor's 19 public key, and by enforcing the constraints expressed in the 20 associated data for the trust anchor. This document describes some 21 of the problems associated with the lack of a standard trust anchor 22 management mechanism and defines requirements for data formats and 23 push-based protocols designed to address these problems. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 26, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 74 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1. Transport independence . . . . . . . . . . . . . . . . . . 8 77 3.1.1. Functional Requirements . . . . . . . . . . . . . . . 8 78 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2. Basic management operations . . . . . . . . . . . . . . . 8 80 3.2.1. Functional Requirements . . . . . . . . . . . . . . . 8 81 3.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 82 3.3. Management targets . . . . . . . . . . . . . . . . . . . . 9 83 3.3.1. Functional Requirements . . . . . . . . . . . . . . . 9 84 3.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9 85 3.4. Delegation of TA Manager Authority . . . . . . . . . . . . 10 86 3.4.1. Functional Requirements . . . . . . . . . . . . . . . 10 87 3.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 88 3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 10 89 3.5.1. Functional Requirements . . . . . . . . . . . . . . . 10 90 3.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 91 3.6. Support Purposes Other Than Certification Path 92 Validation . . . . . . . . . . . . . . . . . . . . . . . . 11 93 3.6.1. Functional Requirements . . . . . . . . . . . . . . . 11 94 3.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 95 3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 11 96 3.7.1. Functional Requirements . . . . . . . . . . . . . . . 11 97 3.7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 98 3.8. Source Authentication . . . . . . . . . . . . . . . . . . 12 99 3.8.1. Functional Requirements . . . . . . . . . . . . . . . 12 100 3.8.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 101 3.9. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 12 102 3.9.1. Functional Requirements . . . . . . . . . . . . . . . 12 103 3.9.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 104 3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 13 105 3.10.1. Functional Requirements . . . . . . . . . . . . . . . 13 106 3.10.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 107 3.11. Compromise or Disaster Recovery . . . . . . . . . . . . . 13 108 3.11.1. Functional Requirements . . . . . . . . . . . . . . . 13 109 3.11.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 110 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 111 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 112 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 113 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 114 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 117 1. Introduction 119 Digital signatures are used in many applications. For digital 120 signatures to provide integrity and authentication, the public key 121 used to verify the digital signature must be "trusted", i.e., 122 accepted by a relying party (RP) as appropriate for use in the given 123 context. A public key used to verify a signature must be configured 124 as a trust anchor (TA) or contained in a certificate that can be 125 transitively verified by a certification path terminating at a trust 126 anchor. A Trust Anchor is a public key and associated data used by a 127 relying party to validate a signature on a signed object where the 128 object is either: 130 o a public key certificate that begins a certification path 131 terminated by a signature certificate or encryption certificate 133 o an object, other than a public key certificate or certificate 134 revocation list (CRL), that cannot be validated via use of a 135 certification path 137 Trust anchors have only local significance, i.e., each RP is 138 configured with a set of trust anchors, either by the RP or by an 139 entity that manages TAs in the context in which the RP operates. The 140 associated data defines the scope of a trust anchor by imposing 141 constraints on the signatures the trust anchor may be used to verify. 142 For example, if a trust anchor is used to verify signatures on X.509 143 certificates, these constraints may include a combination of name 144 spaces, certificate policies, or application/usage types. 146 One use of digital signatures is the verification of signatures on 147 firmware packages loaded into hardware modules, such as cryptographic 148 modules, cable boxes, routers, etc. Since such devices are often 149 managed remotely, the devices must be able to authenticate the source 150 of management interactions and can use trust anchors to perform this 151 authentication. However, trust anchors require management as well. 152 Other applications requiring trust anchor management include web 153 browsers, which use trust anchors when authenticating web servers, 154 and email clients, which use trust anchors when validating signed 155 email and when authenticating recipients of encrypted email. 157 All applications that rely upon digital signatures rely upon some 158 means of managing one or more sets of trust anchors. Each set of 159 trust anchors is referred to in this document as a trust anchor 160 store. Often, the means of managing trust anchor stores are 161 application-specific and rely upon out-of-band means to establish and 162 maintain trustworthiness. An application may use multiple trust 163 anchor stores and a given trust anchor store may be used by multiple 164 applications. Each trust anchor store is managed by at least one TA 165 manager; a TA manager may manage multiple TA stores. 167 The requirements stated in this document were prepared prior to the 168 publication of [RFC5914] and [RFC5934]. The document was not 169 published at that time to allow for changes in requirements during 170 the development of the associated technical specifications. The 171 requirements described below are those that were considered during 172 the development of [RFC5914] and [RFC5934]. 174 This section provides an introduction and defines basic terminology. 175 Section 2 describes problems with current trust anchor management 176 methods. Sections 3 and 4 describe requirements and security 177 considerations for a trust anchor management solution. 179 1.1. Terminology 181 The following terms are defined in order to provide a vocabulary for 182 describing requirements for trust anchor management. 184 Trust Anchor: A trust anchor represents an authoritative entity via 185 a public key and associated data. The public key is used to 186 verify digital signatures and the associated data is used to 187 constrain the types of information for which the trust anchor is 188 authoritative. A relying party uses trust anchors to determine if 189 a digitally signed object is valid by verifying a digital 190 signature using the trust anchor's public key, and by enforcing 191 the constraints expressed in the associated data for the trust 192 anchor. 194 Trust Anchor Manager: Trust anchor manager is an entity responsible 195 for managing the contents of a trust anchor store. Throughout 196 this document, each trust anchor manager is assumed to be 197 represented as or delegated by a distinct trust anchor. 199 Trust Anchor Store: A trust anchor store is a set of one or more 200 trust anchors stored in a device. A trust anchor store may be 201 managed by one or more trust anchor managers. A device may have 202 more than one trust anchor store, each of which may be used by one 203 or more applications. 205 1.2. Requirements Notation 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 2. Problem Statement 213 Trust anchors are used to support many application scenarios. Most 214 Internet browsers and email clients use trust anchors when 215 authenticating TLS sessions, verifying signed email and generating 216 encrypted email by validating a certification path to a server's 217 certificate, an e-mail originator's certificate or an e-mail 218 recipient's certificate, respectively. Many software distributions 219 are digitally signed to enable authentication of the software source 220 prior to installation. Trust anchors that support these applications 221 are typically installed as part of the operating system (OS) or 222 application, installed using an enterprise configuration management 223 system, or installed directly by an OS or application user. 225 Trust anchors are typically stored in application-specific or 226 operating system-specific trust anchor stores. Often, a single 227 machine may have a number of different trust anchor stores that may 228 not be synchronized. Reviewing the contents of a particular trust 229 anchor store typically involves use of a proprietary tool that 230 interacts with a particular type of trust store. 232 The presence of a trust anchor in a particular store often conveys 233 implicit authorization to validate signatures for any contexts from 234 which the store is accessed. For example, the public key of a 235 timestamp authority (TSA) may be installed in a trust anchor store to 236 validate signatures on timestamps [RFC3161]. However, if the store 237 containing this TA is used by multiple applications that serve 238 different purposes, the same key may be used (inappropriately) to 239 validate other types of objects such as certificates or OCSP 240 responses. Prior to publication of [RFC5914], there was no standard 241 general purpose mechanism for limiting the applicability (scope) of a 242 trust anchor. Placing different TAs in different stores and limiting 243 the set of applications that access a given TA store is a common 244 practice to address this problem. 246 Trust relationships between PKIs are negotiated by policy 247 authorities. Negotiations frequently require significant time to 248 ensure all participating parties' requirements are satisfied. These 249 requirements are expressed, to some extent, in public key 250 certificates via policy constraints, name constraints, etc. In order 251 for these requirements to be enforced, trust anchor stores must be 252 managed in accord with policy authority intentions. Otherwise, the 253 constraints defined in a cross-certificate could be circumvented by 254 recognizing the subject of the cross certificate as a trust anchor, 255 which would enable path processing implementations to avoid the 256 cross-certificate. 258 Trust anchors are often represented as self-signed certificates, 259 which provide no useful means of establishing the validity of the 260 information contained in the certificate. Confidence in the 261 integrity of a trust anchor is typically established through out-of- 262 band means, often by checking the "fingerprint" (one-way hash) of the 263 self-signed certificate with an authoritative source. Routine trust 264 anchor re-key operations typically require similar out-of-band 265 checks, though in-band rekey of a trust anchor is supported by the 266 Certificate Management Protocol (CMP) [RFC4210]. Ideally, only the 267 initial set of trust anchors are installed in a particular trust 268 anchor store should require out-of-band verification, particularly 269 when the costs of performing out-of-band checks commensurate with the 270 security requirements of applications using the trust anchor store 271 are high. 273 Despite the prevalent use of trust anchors, there is neither a 274 standard means for discovering the set of trust anchors installed in 275 a particular trust anchor store nor a standard means of managing 276 those trust anchors. The remainder of this document describes 277 requirements for a solution to this problem along with some security 278 considerations. 280 3. Requirements 282 This section describes the requirements for a trust anchor management 283 protocol. Requirements are provided for trust anchor contents as 284 well as for trust anchor store management operations. 286 3.1. Transport independence 288 3.1.1. Functional Requirements 290 A general-purpose solution for the management of trust anchors MUST 291 be transport independent in order to apply to a range of device 292 communications environments. It MUST work in both session-oriented 293 and store-and-forward communications environments as well as in both 294 push and pull distribution models. To accommodate both communication 295 models in a uniform fashion, connectionless integrity and data origin 296 authentication for TA transactions MUST be provided at the 297 application layer. Confidentiality MAY be provided for such 298 transactions. 300 3.1.2. Rationale 302 Not all devices that use trust anchors are available for online 303 management operations; some devices may require manual interaction 304 for trust anchor management. Data origin authentication and 305 integrity are required to ensure that the transaction has not been 306 modified en route. Only connectionless integrity is required, for 307 compatibility with store-and-forward contexts. 309 3.2. Basic management operations 311 3.2.1. Functional Requirements 313 At a minimum, a protocol used for trust anchor management MUST enable 314 a trust anchor manager to perform the following operations: 316 o Determine which trust anchors are installed in a particular trust 317 anchor store 319 o Add one or more trust anchors to a trust anchor store 321 o Remove one or more trust anchors from a trust anchor store 323 o Replace an entire trust anchor store 325 A trust anchor management protocol MUST provide support for these 326 basic operations, however, not all implementations must support each 327 option. For example, some implementations may support only 328 replacement of trust anchor stores. 330 3.2.2. Rationale 332 These requirements describe the core operations required to manage 333 the contents of a trust anchor store. An edit operation was omitted 334 for sake of simplicity, with consecutive remove and add operations 335 used for this purpose. A single add or remove operation can act upon 336 more than one trust anchor to avoid unnecessary round trips and are 337 provided to avoid the need to always replace an entire trust anchor 338 store. Trust anchor store replacement may be useful as a simple, 339 higher bandwidth alternative to add and remove operations. 341 3.3. Management targets 343 3.3.1. Functional Requirements 345 A protocol for TA management MUST allow a TA management transaction 346 to be directed to: 348 All TA stores for which the manager is responsible 350 An enumerated list of one or more named groups of trust anchor 351 stores 353 An individual trust anchor store 355 3.3.2. Rationale 357 Connections between PKIs can be accomplished using different means. 358 Unilateral or bilateral cross-certification can be performed, or a 359 community may simply elect to explicitly accept a trust anchor from 360 another community. Typically, these decisions occur at the 361 enterprise level. In some scenarios, it can be useful to establish 362 these connections for a small community within an enterprise. 363 Enterprise-wide mechanisms such as cross-certificates are ill-suited 364 for this purpose since certificate revocation or expiration affects 365 the entire enterprise. 367 A trust anchor management protocol can address this issue by 368 supporting limited installation of trust anchors (i.e., installation 369 of TAs in subsets of the enterprise user community), and by 370 supporting expression of constraints on trust anchor use by relying 371 parties. Limited installation requires the ability to identify the 372 members of the community that are intended to rely upon a particular 373 trust anchor, as well as the ability to query and report on the 374 contents of trust anchor stores. Trust anchor constraints can be 375 used to represent the limitations that might otherwise be expressed 376 in a cross-certificate, and limited installation ensures the 377 recognition of the trust anchor does not necessarily encompass an 378 entire enterprise. 380 Trust anchor configurations may be uniform across an enterprise, or 381 they may be unique to a single application or small set of 382 applications. Many devices and some applications utilize multiple 383 trust anchor stores. By providing means of addressing a specific 384 store or collections of stores, a trust anchor management protocol 385 can enable efficient management of all stores under a trust anchor 386 manager's control. 388 3.4. Delegation of TA Manager Authority 390 3.4.1. Functional Requirements 392 A trust anchor management protocol MUST enable secure transfer of 393 control of a trust anchor store from one trust anchor manager to 394 another. It also SHOULD enable delegation for specific operations 395 without requiring delegation of the overall trust anchor management 396 capability itself. 398 3.4.2. Rationale 400 Trust anchor manager re-key is one type of transfer that must be 401 supported. In this case, the new key will be assigned the same 402 privileges as the old key. 404 Creation of trust anchors for specific purposes, such as firmware 405 signing, is another example of delegation. For example, a trust 406 anchor manager may delegate only the authority to sign firmware to an 407 entity, but disallow further delegation of that privilege, or the 408 trust anchor manager may allow its delegate to further delegate 409 firmware signing authority to other entities. 411 3.5. RFC 5280 Support 413 3.5.1. Functional Requirements 415 A trust anchor management protocol MUST enable management of trust 416 anchors that will be used to validate certification paths and CRLs in 417 accordance with [RFC5280] and [RFC5055]. A trust anchor format MUST 418 enable the representation of constraints that influence certification 419 path validation or otherwise establish the scope of usage of the 420 trust anchor public key. Examples of such constraints are name 421 constraints, certificate policies, and key usage. 423 3.5.2. Rationale 425 Certification path validation is one of the most common applications 426 of trust anchors. The rules for using trust anchors for path 427 validation are established in [RFC5280]. [RFC5055] describes the use 428 of trust anchors for delegated path validation. Trust anchors used 429 to validate certification paths are responsible for providing, 430 possibly through a delegate, the revocation status information of 431 certificates it issues; this is often accomplished by signing a CRL. 433 3.6. Support Purposes Other Than Certification Path Validation 435 3.6.1. Functional Requirements 437 A trust anchor management protocol MUST enable management of trust 438 anchors that can be used for purposes other than certification path 439 validation, including trust anchors that cannot be used for 440 certification path validation. It SHOULD be possible to authorize a 441 trust anchor to delegate authority (to other TAs or certificate 442 holders) and to prevent a trust anchor from delegating authority. 444 3.6.2. Rationale 446 Trust anchors are used to validate a variety of signed objects, not 447 just public key certificates and CRLs. For example, a trust anchor 448 may be used to verify firmware packages [RFC4108], OCSP responses 449 [RFC2560], SCVP responses [RFC5055] or timestamps [RFC3161]. TAs 450 that are authorized for use with some or all of these other types of 451 operations may not be authorized to verify public key certificates or 452 CRLs. Thus it is important to be able to impose constraints on the 453 ways in which a given TA is employed. 455 3.7. Trust Anchor Format 457 3.7.1. Functional Requirements 459 Minimally, a trust anchor management protocol MUST support management 460 of trust anchors represented as self-signed certificates and trust 461 anchors represented as a distinguished name, public key information 462 and, optionally, associated data. The definition of a trust anchor 463 MUST include a public key, a public key algorithm and, if necessary, 464 public key parameters. When the public key is used to validate 465 certification paths or CRLs, a distinguished name also MUST be 466 included per [RFC5280]. A trust anchor format SHOULD enable 467 specification of a public key identifier to enable other applications 468 of the trust anchor, for example, verification of data signed using 469 the Cryptographic Message Syntax (CMS) SignedData structure 470 [RFC5652]. A trust anchor format also SHOULD enable the 471 representation of constraints that can be applied to restrict the use 472 of a trust anchor. 474 3.7.2. Rationale 476 Prior to the publication of [RFC5914], there was no standardized 477 format for trust anchors. Self-signed X.509 certificates are 478 typically used but [RFC5280] does not mandate a particular trust 479 anchor representation. It requires only that a trust anchor's public 480 key information and distinguished name be available during 481 certification path validation. CMS is widely used to protect a 482 variety of types of content using digital signatures, including 483 contents that may verified directly using a trust anchor, such as 484 firmware packages [RFC4108]. Constraints may include a validity 485 period, constraints on certification path validation, etc. 487 3.8. Source Authentication 489 3.8.1. Functional Requirements 491 An entity receiving trust anchor management data MUST be able to 492 authenticate the identity of the party providing the information and 493 MUST be able to confirm the party is authorized to provide that trust 494 anchor information. 496 A trust anchor manager MUST be able to authenticate which trust 497 anchor store corresponds to a report listing the contents of the 498 trust anchor store and be able to confirm the contents of the report 499 have not been subsequently altered. 501 3.8.2. Rationale 503 Data origin authentication and integrity are required to support 504 remote management operations, even when TA management transactions 505 are effected via store-and-forward communications. 507 3.9. Reduce Reliance on Out-of-Band Trust Mechanisms 509 3.9.1. Functional Requirements 511 When performing add operations, a trust anchor management protocol 512 SHOULD enable TA integrity to be checked automatically by a relying 513 party without relying on out-of-band trust mechanisms. 515 3.9.2. Rationale 517 Traditionally, a trust anchor is distributed out-of-band with its 518 integrity checked manually prior to installation. Installation 519 typically is performed by anyone with sufficient administrative 520 privilege on the system receiving the trust anchor. Reliance on out- 521 of-band trust mechanisms is one problem with current trust anchor 522 management approaches and reduction of the need to use out-of-band 523 trust mechanisms is a primary motivation for developing a trust 524 anchor management protocol. Ideally, out-of-band trust mechanisms 525 will be required only during trust anchor store initialization. 527 3.10. Replay Detection 529 3.10.1. Functional Requirements 531 A trust anchor management protocol MUST enable participants engaged 532 in a trust anchor management protocol exchange to detect replay 533 attacks. A replay detection mechanism that does not introduce a 534 requirement for a reliable source of time MUST be available. 535 Mechanisms that do require a reliable source of time MAY be 536 available. 538 3.10.2. Rationale 540 Detection of replays of trust anchor management transaction is 541 required to support remote management operations. Replay of old 542 trust anchor management transaction could result in the 543 reintroduction of compromised trust anchors to a trust anchor store, 544 potentially exposing applications to malicious signed objects or 545 certification paths. 547 Some devices that utilize trust anchors have no access to a reliable 548 source of time, so a replay detection mechanism that requires a 549 reliable time source is insufficient. 551 3.11. Compromise or Disaster Recovery 553 3.11.1. Functional Requirements 555 A trust anchor management protocol MUST enable recovery from the 556 compromise or loss of a trust anchor private key, including the 557 private key authorized to serve as a trust anchor manager, without 558 requiring reinitialization of the trust store. 560 3.11.2. Rationale 562 Compromise or loss of a private key corresponding to a trust anchor 563 can have significant negative consequences. Currently, in some 564 cases, re-initialization of all effected trust anchor stores is 565 required to recover from a lost or compromised trust anchor key. Due 566 to the costs associated with re-initialization, a trust anchor 567 management protocol should support recovery options that do not 568 require trust anchor store re-initialization. 570 4. Security Considerations 572 The public key used to authenticate a TA management transaction may 573 have been placed in the client as the result of an earlier TA 574 management transaction or during an initial bootstrap configuration 575 operation. In most scenarios, at least one public key authorized for 576 trust anchor management must be placed in each trust anchor store to 577 be managed during the initial configuration of the trust anchor 578 store. This public key may be transported and checked using out-of- 579 band means. In all scenarios, regardless of the authentication 580 mechanism, at least one trust anchor manager must be established for 581 each trust anchor store during the initial configuration of the trust 582 anchor store. 584 Compromise of a trust anchor's private key can result in many 585 security problems including issuance of bogus certificates or 586 installation of rogue trust anchors. 588 Usage of trust anchor-based constraints requires great care when 589 defining trust anchors. Errors on the part of a trust anchor manager 590 could result in denial of service or have serious security 591 consequences. For example, if a name constraint for a trust anchor 592 that serves as the root of a PKI includes a typo, denial of service 593 results for certificate holders and relying parties. If a trust 594 anchor manager inadvertently delegates all of its privileges and the 595 delegate subsequently removes the trust anchor manager from trust 596 anchor stores now under its control, recovery may require 597 reinitialization of all effected trust anchor stores. 599 RFC 5280 requires that certificate path validation be initialized 600 with a TA subject name and public key, but does not require 601 processing of other information, such as name constraints extensions. 602 Inclusion of constraints in trust anchors is optional. When 603 constraints are explicitly included by a trust anchor manager using a 604 trust anchor management protocol, there exists an expectation that 605 the certificate path validation algorithm will make use of the 606 constraints. Application owners must confirm the path processing 607 implementations support the processing of TA-based constraints, where 608 required. 610 Many of the security considerations from [RFC5280] are also 611 applicable to trust anchor management. 613 5. IANA Considerations 615 None. Please remove this section prior to publication as an RFC. 617 6. References 619 6.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 625 Polk, "Server-Based Certificate Validation Protocol 626 (SCVP)", RFC 5055, December 2007. 628 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 629 Housley, R., and W. Polk, "Internet X.509 Public Key 630 Infrastructure Certificate and Certificate Revocation List 631 (CRL) Profile", RFC 5280, May 2008. 633 6.2. Informative References 635 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 636 Adams, "X.509 Internet Public Key Infrastructure Online 637 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 639 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 640 "Internet X.509 Public Key Infrastructure Time-Stamp 641 Protocol (TSP)", RFC 3161, August 2001. 643 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 644 Protect Firmware Packages", RFC 4108, August 2005. 646 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 647 "Internet X.509 Public Key Infrastructure Certificate 648 Management Protocol (CMP)", RFC 4210, September 2005. 650 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 651 RFC 5652, September 2009. 653 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 654 Format", RFC 5914, June 2010. 656 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 657 Management Protocol (TAMP)", RFC 5934, August 2010. 659 Authors' Addresses 661 Raksha Reddy 662 National Security Agency 663 Suite 6599 664 9800 Savage Road 665 Fort Meade, MD 20755 667 Email: r.reddy@radium.ncsc.mil 669 Carl Wallace 670 Cygnacom Solutions 671 Suite 5400 672 7925 Jones Branch Drive 673 McLean, VA 22102 675 Email: cwallace@cygnacom.com