idnits 2.17.1 draft-ietf-pkix-ta-mgmt-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 451. 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 (February 18, 2008) is 5910 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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: August 21, 2008 Cygnacom Solutions 6 February 18, 2008 8 Trust Anchor Management Problem Statement 9 draft-ietf-pkix-ta-mgmt-problem-statement-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A trust anchor is an authoritative entity represented via a public 43 key 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 as well as problems that must be addressed by 52 such a mechanism. This document discusses only public keys as trust 53 anchors; symmetric key trust anchors are not considered. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Functional Properties . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . . . 15 69 1. Introduction 71 Digital signatures are used in many applications. For digital 72 signatures to provide integrity and authentication, the public key 73 used to verify the digital signature must be "trusted", i.e., 74 accepted by a relying paty (RP) as authoritative for an application. 75 A public key used to verify a signature must be configured as a trust 76 anchor or contained in a certificate that can be transitively 77 verified by a certification path terminating at a trust anchor. 78 Directly trusted public keys are known as trust anchors. A Trust 79 Anchor is a public key and associated data used by a relying party to 80 validate a signature on a signed object where the object is either: 82 o a public key certificate that begins a certification path 83 terminated by a signature certificate or encryption certificate 85 o an object (other than a public key certificate) that cannot be 86 validated via use of a certification path 88 Trust anchors have only local significance, i.e., each RP is 89 configured with a set of trust anchors, either by the RP or by an 90 entity that manages TAs in the context in which the RP operates. The 91 associated data often is used to define the scope of a trust anchor, 92 by imposing constraints on the signatures it may be used to verify. 93 For example, if a trust anchor is used to verify signatures on X.509 94 certificates, these constraints may include a combination of name 95 spaces, certificate policies, or application/usage types. Whenever a 96 signature is verified, a trust anchor must be used, either by 97 verifying the signature directly using a TA or by validating a 98 certification path that begins with a TA. 100 One particular use of digital signatures is the verification of 101 signatures on firmware packages loaded into hardware modules, such as 102 cryptographic modules, cable boxes, routers, etc. Since such devices 103 are often managed remotely, the devices must be able to authenticate 104 the source of management interactions and can use trust anchors to 105 perform this authentication. However, trust anchors require 106 management as well. 108 All applications that rely upon digital signatures rely upon some 109 means of managing one or more sets of trust anchors. These sets of 110 trust anchors are referred to in this document as trust anchor 111 stores. Often, the means of managing trust anchor stores are 112 application-specific and rely upon out-of-band means to establish and 113 maintain trustworthiness. An application may use multiple trust 114 anchor stores and a given trust anchor store may be used by multiple 115 applications. Trust anchor stores are managed by trust anchor 116 managers. 118 In some cases, a device may have a single trust anchor that is hard- 119 wired or managed only through physical access to the device. 120 However, to support the ability to delegate different TA managment 121 functions to different authorities, the device may require multiple 122 trust anchors. It may be desirable to manage these trust anchors 123 using similar means as software updates, certificate requests, etc., 124 to enable code reuse. 126 This section provides an introduction and defines basic terminology. 127 Section 2 describes problems with current trust anchor management 128 methods. Sections 3 and 4 describe functional properties and 129 security considerations for a trust anchor management solution, and 130 essentially define requirements for a trust anchor management 131 solution. 133 1.1. Terminology 135 The following terms are defined in order to provide a vocabulary for 136 describing requirements for trust anchor management. 138 Trust Anchor: A trust anchor is an authoritative entity represented 139 via a public key and associated data. The public key is used to 140 verify digital signatures and the associated data is used to 141 constrain the types of information for which the trust anchor is 142 authoritative. A relying party uses trust anchors to determine if 143 a digitally signed object is valid by verifying a digital 144 signature using the trust anchor's public key, and by enforcing 145 the constraints expressed in the associated data for the trust 146 anchor. 148 Trust Anchor Manager: A trust anchor manager is a role responsible 149 for managing the contents of a trust anchor store. 151 Trust Anchor Store: A trust anchor store is a set of one or more 152 trust anchors. A trust anchor store may be managed by one or more 153 trust anchor managers. 155 2. Problem Statement 157 Trust anchors are used to support many application scenarios. Most 158 Internet browsers and email clients use trust anchors when 159 authenticating TLS sessions, verifying signed email and generating 160 encrypted email by validating a certification path to a server's 161 certificate or a mail originator's or recipient's certificate. Many 162 software distributions are digitally signed to enable authentication 163 of the software source to be performed prior to installation. Trust 164 anchors that support these applications are typically installed as 165 part of the operating system (OS) or application, installed using an 166 enterprise configuration management system or installed directly by 167 an OS or application user. An application and platform-independent 168 way to manage TAs would be preferable. 170 Trust anchors are typically stored in application- or operating 171 system- specific trust anchor stores. Often, a single machine may 172 have a number of different trust anchor stores that may not be 173 synchronized. Reviewing the contents of a particular trust anchor 174 store typically involves use of a proprietary tool that interacts 175 with a particular type of trust store. 177 The presence of a trust anchor in a particular store often conveys 178 implicit authorization to validate signatures for any contexts from 179 which the store is accessed. For example, the public key of a 180 timestamp authority (TSA) may be installed in a trust anchor store to 181 validate signatures on timestamps. However, if the store containing 182 this TA is used by multiple applications that serve different 183 purposes, the same key may be used (inappropriately) to validate 184 other types of objects such as certificates or OCSP responses. There 185 is currently no standard means of limiting the applicability (scope) 186 of a trust anchor except by placing different TAs in different stores 187 and limiting the set of applications that access a given TA store. 189 Trust relationships between PKIs are negotiated by policy 190 authorities. Negotiations frequently require significant time to 191 ensure all participating parties' requirements are satisfied. These 192 requirements are expressed, to some extent, in public key 193 certificates via policy constraints, name constraints and etc. In 194 order for these requirements to be enforced, trust anchor stores must 195 be managed in accord with policy authority intentions and avoid 196 circumventing constraints defined in a cross-certificate by 197 recognizing the subject of the cross certificate as a trust anchor. 199 Trust anchors are often represented as self-signed certificates, 200 which provide no useful means of establishing the validity of the 201 information contained in the certificate. Confidence in the 202 integrity of a trust anchor is typically established through out-of- 203 band means, often by checking the "fingerprint" (one-way hash) of the 204 self-signed certificate with an authoritative source. Routine trust 205 anchor re-key operations typically require similar out-of-band 206 checks. Ideally, only the initial set of trust anchors installed in 207 a particular trust anchor store should require out-of-band 208 verification, particularly when the costs of performing out-of-band 209 checks commensurate with the security requirements of applications 210 using the trust anchor store are high. 212 Despite the prevalent use of trust anchors, there is neither a 213 standard means for discovering which trust anchors installed in a 214 particular trust anchor store nor a standard means of managing those 215 trust anchors. The remainder of this document describes some of the 216 functional characteristics a solution to this problem should exhibit 217 along with some security considerations. 219 3. Functional Properties 221 A general-purpose solution for the management of trust anchors must 222 be transport independent in order to apply to a range of device 223 communications environments. It should also be applicable in both 224 session-oriented and store-and-forward contexts. At a minimum, it 225 must enable a trust anchor manager to discovery which TA stores are 226 present, to add trust anchors to, remove trust anchors from, and 227 determine which trust anchors are installed in a particular trust 228 anchor store. 230 Trust anchor configurations may be uniform across an enterprise, or 231 they may be unique to a single application or small set of 232 applications. A protocol for TA management must allow a TA 233 management transaction, to be directed to all TA stores for which the 234 manager is responsible, targeted to an enumerated list of one or more 235 groups of trust anchor stores, or targeted to an individual trust 236 anchor store. 238 Once installed into a trust anchor store, a trust anchor represents 239 an entity with authority recognized by applications that use that 240 store. It is important to be able to define the scope of authority 241 associated with each trust anchor. That scope be very specific 242 (e.g., a trust anchor public key may be limited to verification of 243 firmware updates only), or more general (such as to validate 244 certification paths for certificates issued to users or devices). It 245 should be possible to authorize a trust anchor to delegate authority 246 (to other TAs) and to prevent delegation. 248 A trust anchor manager has significant control over a device or 249 application due to the ability to control what other authorities are 250 recognized. In some cases, a trust anchor manager may be the legal 251 owner of a device or application. In other cases, a trust anchor 252 manager may be an entity responsible for the operation of a device, 253 such as a firmware provider for a cable or satellite TV set top box. 254 A trust anchor manager may be static over the life of a device, or it 255 may change as legal ownership or other factors change. A trust 256 anchor management protocol should enable secure transfer of control 257 of a device from one trust anchor manager to another. It also should 258 enable delegation of TA management control over specific aspects of 259 the device, without requiring delegation of the overall trust anchor 260 management capability itself. Trust anchor re-key is one type of 261 transfer that must be supported. 263 A trust anchor management protocol must be capable of managing trust 264 anchors that can be used to validate certification paths in 265 accordance with [RFC3280]. Minimally, the definition of a trust 266 anchor must include a public key, a public key algorithm and, if 267 necessary, public key parameters. When the public key is used to 268 validate certification paths, a distinguished name also must be 269 included. A public key identifier should be included to enable other 270 applications of the trust anchor, for example, verification of data 271 signed using the Cryptographic Message Syntax SignedData structure 272 [RFC3852]. 274 Trust anchors may be explicitly authorized for a limited set of 275 purposes. For example, a trust anchor may be authorized for 276 verification of signed firmware packages [RFC4108] but not authorized 277 for validating certification paths. A trust anchor management 278 protocol must enable the management of trust anchors that do not 279 serve as trust anchors for certification path validation. 281 Connections between PKIs can be accomplished using different means. 282 Unilateral or bilateral cross-certification can be performed, or a 283 community may simply elect to explicitly accept a trust anchor from 284 another community. Typically, these decisions occur at the 285 enterprise level. In some scenarios, it can be useful to establish 286 these connections for a small community within an enterprise. 287 Enterprise-wide mechanisms such as cross-certificates are ill-suited 288 for this purpose since certificate revocation or expiration affects 289 the entire enterprise. A trust anchor management protocol can 290 address this issue by supporting limited installation of trust 291 anchors and by supporting expression of constraints on trust anchor 292 usage. Limited installation requires the ability to identify the 293 members of the community that are authorized to rely upon a 294 particular trust anchor, as well as the ability to query and report 295 on the contents of trust anchor stores. The trust anchor constraints 296 can represent the limitations that would have been expressed in a 297 cross-certificate and limited installation ensures the recognition of 298 the trust anchor does not necessarily encompass and entire 299 enterprise. 301 There is no standardized format for trust anchors. Self-signed X.509 302 certificates are typically used but [RFC3280] does not mandate a 303 particular trust anchor representation. It requires only that a 304 trust anchor's public key information and distinguished name be 305 available during certification path validation. Minimally, a trust 306 anchor management protocol should support management of trust anchors 307 represented as self-signed certificates or as a distinguished name 308 and public key information. 310 A trust anchor manager must be able to authenticate which device 311 produced a report listing the contents of a trust anchor store and, 312 be able to confirm the contents of the report have not been 313 subsequently altered. Replay of old reports (from the same device) 314 must be detectable by a TA manager. 316 A trust anchor definition should enable the representation of 317 constraints that influence certification path validation or otherwise 318 establish the scope of usage of the trust anchor public key. 319 Examples of such constraints are name constraints, certificate 320 policies and key usage. A trust anchor manager must be able to 321 establish the constraints associated with every trust anchor 322 controlled by the manager. 324 4. Security Considerations 326 The integrity of trust anchor management transactions must be 327 assured, i.e., and it must be possible to authenticate the originator 328 of a TA management transaction and confirm the authorization of the 329 originator for that transaction. 331 Traditionally, a trust anchor is distributed out-of-band with its 332 integrity checked manually prior to installation. Installation 333 typically is performed by anyone with sufficient administrative 334 privilege on the system receiving the trust anchor. A trust anchor 335 management protocol should enable TA integrity to be checked 336 automatically by relying upon a public key that is resident in a 337 client system participating in the protocol. 339 The public key used to authenticate the trust anchor management 340 transactions may have been placed in the client as the result of an 341 earlier transaction, or during an initial bootstrap configuration 342 operation. In most scenarios, at least one public key authorized for 343 trust anchor management must be placed in each trust store to be 344 managed during the initial configuration of the trust store. This 345 public key may be transported and checked using traditional out-of- 346 band means. In all scenarios, regardless of the authentication 347 mechanism, at least one trust anchor manager must be established for 348 each trust store during the initial configuration of the trust store. 350 An entity receiving trust anchor information must be able to 351 authenticate the party providing the information and must be able to 352 confirm the party is authorized to provide that trust anchor 353 information. A trust anchor manager may be authorized to participate 354 in trust anchor management protocol exchanges, but be limited to 355 managing trust anchors within a particular scope. Alternatively, a 356 trust anchor manager may be authorized to participate in trust anchor 357 management protocol exchanges without any constraints on the types of 358 trust anchors that may be managed. Clear subordination rules must be 359 defined so that an administrator can determine, unambiguously, the 360 scope of authority for any trust anchor installed in a device. 362 Some devices that utilize trust anchors may have no access to a 363 reliable source of time. Trust anchor management transactions should 364 enable such devices to engage in trust anchor management protocol 365 exchanges without being subject to replay attacks that could add old 366 or no-longer-trusted trust anchors to a trust anchor store. 368 Compromise of a private key corresponding to a trust anchor can have 369 significant negative consequences. A trust anchor management 370 protocol must enable recovery from the compromise of a trust anchor 371 private key, including the private key authorized to serve as a 372 source of trust anchor information. 374 5. IANA Considerations 376 None. Please remove this section prior to publication as an RFC. 378 6. References 380 6.1. Normative References 382 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 383 X.509 Public Key Infrastructure Certificate and 384 Certificate Revocation List (CRL) Profile", RFC 3280, 385 April 2002. 387 6.2. Informative References 389 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 390 RFC 3852, July 2004. 392 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 393 Protect Firmware Packages", RFC 4108, August 2005. 395 Authors' Addresses 397 Raksha Reddy 398 National Security Agency 399 Suite 6751 400 9800 Savage Road 401 Fort Meade, MD 20755 403 Email: r.reddy@radium.ncsc.mil 405 Carl Wallace 406 Cygnacom Solutions 407 Suite 5200 408 7925 Jones Branch Drive 409 McLean, VA 22102 411 Email: cwallace@cygnacom.com 413 Full Copyright Statement 415 Copyright (C) The IETF Trust (2008). 417 This document is subject to the rights, licenses and restrictions 418 contained in BCP 78, and except as set forth therein, the authors 419 retain all their rights. 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 424 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 425 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 426 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Intellectual Property 431 The IETF takes no position regarding the validity or scope of any 432 Intellectual Property Rights or other rights that might be claimed to 433 pertain to the implementation or use of the technology described in 434 this document or the extent to which any license under such rights 435 might or might not be available; nor does it represent that it has 436 made any independent effort to identify any such rights. Information 437 on the procedures with respect to rights in RFC documents can be 438 found in BCP 78 and BCP 79. 440 Copies of IPR disclosures made to the IETF Secretariat and any 441 assurances of licenses to be made available, or the result of an 442 attempt made to obtain a general license or permission for the use of 443 such proprietary rights by implementers or users of this 444 specification can be obtained from the IETF on-line IPR repository at 445 http://www.ietf.org/ipr. 447 The IETF invites any interested party to bring to its attention any 448 copyrights, patents or patent applications, or other proprietary 449 rights that may cover technology that may be required to implement 450 this standard. Please address the information to the IETF at 451 ietf-ipr@ietf.org. 453 Acknowledgment 455 Funding for the RFC Editor function is provided by the IETF 456 Administrative Support Activity (IASA).