idnits 2.17.1 draft-ietf-pkix-proxy-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 912 has weird spacing: '...e. The worki...' == Line 922 has weird spacing: '...ed name expec...' == Line 1050 has weird spacing: '...ey, the worki...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The application MAY make authorization decisions based on the subject distinguished name of the proxy certificate or on one of the proxy certificates in it's issuing chain or on the EEC that serves as the root of the chain. If an application chooses to use the subject distinguished name of a proxy certificate in the issuing chain or the EEC it MUST use the returned policies to restrict the rights it grants to the proxy certificate. If the application does not know how to parse any policy in the policy chain it MUST not use, for the purposes of making authorization decisions, the subject distinguished name of any certificate in the chain prior to the certificate in which the unrecognized policy appears. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Changed "MUST not be present" to "MUST be absent" second to last paragraph of section 3.8. -- 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 (19 December 2003) is 7427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Tuecke 2 Document: draft-ietf-pkix-proxy-10 ANL 3 Expires May 2004 V. Welch 4 NCSA 5 D. Engert 6 ANL 7 L. Pearlman 8 USC/ISI 9 M. Thompson 10 LBNL 11 19 December 2003 13 Internet X.509 Public Key Infrastructure 14 Proxy Certificate Profile 16 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This document provides information to the community regarding the 38 profile of the X.509 Proxy Certificate. It defines a standard for 39 implementing X.509 Proxy Certificates. 41 Abstract 42 This document forms a certificate profile for Proxy Certificates, 43 based on X.509 Public Key Infrastructure (PKI) certificates as 44 defined in RFC 3280, for use in the Internet. The term Proxy 45 Certificate is used to describe a certificate that is derived from, 46 and signed by, a normal X.509 Public Key End Entity Certificate or 47 by another Proxy Certificate for the purpose of providing 48 restricted proxying and delegation within a PKI based 49 authentication system. 51 Table of Contents 52 1 Introduction...................................................3 53 2 Overview of Approach...........................................4 54 2.1 Terminology..................................................5 55 2.2 Background...................................................5 56 2.3 Motivation for Proxying......................................6 57 2.4 Motivation for Restricted Proxies............................8 58 2.5 Motivation for Unique Proxy Name.............................9 59 2.6 Description Of Approach.....................................10 60 2.7 Features Of This Approach...................................11 61 3 Certificate and Certificate Extensions Profile................13 62 3.1 Issuer......................................................14 63 3.2 Issuer Alternative Name.....................................14 64 3.3 Serial Number...............................................14 65 3.4 Subject.....................................................14 66 3.5 Subject Alternative Name....................................15 67 3.6 Key Usage and Extended Key Usage............................15 68 3.7 Basic Constraints...........................................15 69 3.8 The ProxyCertInfo Extension.................................15 70 4 Proxy Certificate Path Validation.............................20 71 4.1 Basic Proxy Certificate Path Validation.....................21 72 4.2 Using the Path Validation Algorithm.........................25 73 5 Commentary....................................................27 74 5.1 Relationship to Attribute Certificates......................27 75 5.2 Kerberos 5 Tickets..........................................31 76 5.3 Examples of usage of Proxy Restrictions.....................32 77 5.4 Delegation Tracing..........................................33 78 6 Security Considerations.......................................34 79 6.1 Compromise of a Proxy Certificate...........................34 80 6.2 Restricting Proxy Certificates..............................35 81 6.3 Relying Party Trust of Proxy Certificates...................35 82 6.4 Protecting Against Denial of Service with Key Generation....36 83 6.5 Use of Proxy Certificates in a Central Repository...........36 84 7 IANA Considerations...........................................37 85 8 Normative References..........................................37 86 9 Informational References......................................37 87 10 Acknowledgments.............................................38 88 11 Contact Information.........................................39 89 12 Copyright Notice............................................39 90 13 Intellectual Property Statement.............................40 91 Appendix A. 1988 ASN.1 Module....................................41 92 Appendix B. Change Log (To be removed prior to publication)......42 94 1 Introduction 96 Use of a proxy credential [i8] is a common technique used in 97 security systems to allow entity A to grant to another entity B the 98 right for B to be authorized with others as if it were A. In other 99 words, entity B is acting as a proxy on behalf of entity A. This 100 document forms a certificate profile for Proxy Certificates, based 101 on the RFC 3280, "Internet X.509 Public Key Infrastructure 102 Certificate and CRL Profile" [n2]. 104 In addition to simple, unrestricted proxying, this profile defines: 106 * A framework for carrying policies in Proxy Certificates that 107 allows proxying to be limited (perhaps completely disallowed) 108 through either restrictions or enumeration of rights. 110 * Proxy Certificates with unique names, derived from the name of 111 the end entity certificate name. This allows the Proxy 112 Certificates to be used in conjunction with attribute assertion 113 approaches such as Attribute Certificates [i3] and have their 114 own rights independent of their issuer. 116 Section 2 provides a non-normative overview of the approach. It 117 begins by defining terminology, motivating Proxy Certificates, and 118 giving a brief overview of the approach. It then introduces the 119 notion of a Proxy Issuer, as distinct from a Certificate Authority, 120 to describe how end entity signing of a Proxy Certificate is 121 different from end entity signing of another end entity 122 certificate, and therefore why this approach does not violate the 123 end entity signing restrictions contained in the X.509 keyCertSign 124 field of the keyUsage extension. It then continues with 125 discussions of how subject names are used by this proxying 126 approach, and features of this approach. 128 Section 3 defines requirements on information content in Proxy 129 Certificates. This profile addresses two fields in the basic 130 certificate as well as five certificate extensions. The 131 certificate fields are the subject and issuer fields. The 132 certificate extensions are subject alternative name, issuer 133 alternative name, key usage, basic constraints, and extended key 134 usage. A new certificate extension, Proxy Certificate Information, 135 is introduced. 137 Section 4 defines path validation rules for Proxy Certificates. 139 Section 5 provides non-normative commentary on Proxy Certificates. 141 Section 6 discusses security considerations relating to Proxy 142 Certificates. 144 References in this document are sorted into normative and 145 information references. Normative references, listed in Section 8, 146 are in the form [nXX]. Informative references, listed in Section 147 9, are in the form [iXX]. 149 Section 10 contains acknowledgements. 151 Section 11 contains contact information for the authors. 153 Section 12 contains the copyright information for this document. 155 Section 13 contains the intellectual property information for this 156 document. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 160 this document are to be interpreted as described in RFC-2119 [n1]. 162 2 Overview of Approach 164 This section provides non-normative commentary on Proxy 165 Certificates. 167 The goal of this specification is to develop a X.509 Proxy 168 Certificate profile and to facilitate their use within Internet 169 applications for those communities wishing to make use of 170 restricted proxying and delegation within an X.509 Public Key 171 Infrastructure (PKI) authentication based system. 173 This section provides relevant background, motivation, an overview 174 of the approach, and related work. 176 2.1 Terminology 178 This document uses the following terms: 180 * CA: A "Certificate Authority", as defined by X.509 [n2]. 182 * EEC: An "End Entity Certificate", as defined by X.509. That is, 183 it is an X.509 Public Key Certificate issued to an end entity, 184 such as a user or a service, by a CA. 186 * PKC: An end entity "Public Key Certificate". This is synonymous 187 with an EEC. 189 * PC: A "Proxy Certificate", the profile of which is defined by 190 this document. 192 * PI: A "Proxy Issuer" is an entity with an End Entity Certificate 193 or Proxy Certificate that issues a Proxy Certificate. The Proxy 194 Certificate is signed using the private key associated with the 195 public key in the Proxy Issuer's certificate. 197 * AC: An "Attribute Certificate", as defined by "An Internet 198 Attribute Certificate Profile for Authorization" [i3]. 200 * AA: An "Attribute Authority", as defined in [i3]. 202 2.2 Background 204 Computational and Data "Grids" have emerged as a common approach to 205 constructing dynamic, inter-domain, distributed computing 206 environments. As explained in [i5], large research and development 207 efforts starting around 1995 have focused on the question of what 208 protocols, services, and APIs are required for effective, 209 coordinated use of resources in these Grid environments. 211 In 1997, the Globus Project (www.globus.org) introduced the Grid 212 Security Infrastructure (GSI) [i4]. This library provides for 213 public key based authentication and message protection, based on 214 standard X.509 certificates and public key infrastructure, the 215 SSL/TLS protocol [i2], and delegation using proxy certificates 216 similar to those profiled in this document. GSI has been used, in 217 turn, to build numerous middleware libraries and applications, 218 which have been deployed in large-scale production and experimental 219 Grids [i1]. GSI has emerged as the dominant security solution used 220 by Grid efforts worldwide. 222 This experience with GSI has proven the viability of restricted 223 proxying as a basis for authorization within Grids, and has further 224 proven the viability of using X.509 Proxy Certificates, as defined 225 in this document, as the basis for that proxying. This document is 226 one part of an effort to migrate this experience with GSI into 227 standards, and in the process clean up the approach and better 228 reconcile it with existing and recent standards. 230 2.3 Motivation for Proxying 232 A motivating example will assist in understanding the role proxying 233 can play in building Internet based applications. 235 Steve is an engineer who wants to use a reliable file transfer 236 service to manage the movement of a number of large files around 237 between various hosts on his company's Intranet-based Grid. From 238 his laptop he wants to submit a number of transfer requests to the 239 service and have the files transferred while he is doing other 240 things, including being offline. The transfer service may queue 241 the requests for some time (e.g. until after hours or a period of 242 low resource usage) before initiating the transfers. The transfer 243 service will then, for each file, connect to each of the source and 244 destination hosts, and instruct them initiate a data connection 245 directly from the source to the destination in order to transfer 246 the file. Steve will leave an agent running on his laptop that 247 will periodically check on progress of the transfer by contacts the 248 transfer service. Of course, he wants all of this to happen 249 securely on his company's resources, which requires that he 250 initiate all of this using his PKI smartcard. 252 This scenario requires authentication and delegation in a variety 253 of places: 255 * Steve needs to be able to mutually authenticate with the remote 256 file transfer service to submit the transfer request. 258 * Since the storage hosts know nothing about the file transfer 259 service, the file transfer service needs to be delegated the 260 rights to mutually authenticate with the various storage hosts 261 involved directly in the file transfer, in order to initiate the 262 file transfer. 264 * The source and destination hosts of a particular transfer must 265 be able to mutual authenticate with each other, to ensure the 266 file is being transferred to and from the proper parties. 268 * The agent running on Steve's laptop must mutually authenticate 269 with the file transfer service in order to check the result of 270 the transfers. 272 Proxying is a viable approach to solving two (related) problems in 273 this scenario: 275 * Single sign-on: Steve wants to enter his smartcard password (or 276 pin) once, and then run a program that will submit all the file 277 transfer requests to the transfer service, and then periodically 278 check on the status of the transfer. This program needs to be 279 given the rights to be able to perform all of these operations 280 securely, without requiring repeated access to the smartcard or 281 Steve's password. 283 * Delegation: Various remote processes in this scenario need to 284 perform secure operations on Steve's behalf, and therefore must 285 be delegated the necessary rights. For example, the file 286 transfer service needs to be able to authenticate on Steve's 287 behalf with the source and destination hosts, and must in turn 288 delegate rights to those hosts so that they can authenticate 289 with each other. 291 Proxying can be used to secure all of these interactions: 293 * Proxying allows for the private key stored on the smartcard to 294 be accessed just once, in order to create the necessary proxy 295 credential, which allows the client/agent program to be 296 authorized as Steve when submitting the requests to the transfer 297 service. Access to the smartcard and Steve's password is not 298 required after the initial creation of the proxy credential. 300 * The client program on the laptop can delegate to the file 301 transfer service the right to act on Steve's behalf. This, in 302 turn, allows the service to authenticate to the storage hosts 303 and inherit Steve's privileges in order to start the file 304 transfers. 306 * When the transfer service authenticates to hosts to start the 307 file transfer, the service can delegate to the hosts the right 308 to act on Steve's behalf so that each pair of hosts involved in 309 a file transfer can mutually authenticate to ensure the file is 310 securely transferred. 312 * When the agent on the laptop reconnects to the file transfer 313 service to check on the status of the transfer, it can perform 314 mutual authentication. The laptop may use a newly generated 315 proxy credential, which is just created anew using the 316 smartcard. 318 This scenario, and others similar to it, is being built today 319 within the Grid community. The Grid Security Infrastructure's 320 single sign-on and delegation capabilities, built on X.509 Proxy 321 Certificates, are being employed to provide authentication services 322 to these applications. 324 2.4 Motivation for Restricted Proxies 326 One concern that arises is what happens if a machine that has been 327 delegated the right to inherit Steve's privileges has been 328 compromised? For example, in the above scenario, what if the 329 machine running the file transfer service is compromised, such that 330 the attacker can gain access to the credential that Steve delegated 331 to that service? Can the attacker now do everything that Steve is 332 allowed to do? 334 A solution to this problem is to allow for restrictions to be 335 placed on the proxy by means of policies on the proxy certificates. 336 For example, the machine running the reliable file transfer service 337 in the above example might only be given Steve's right for the 338 purpose of reading the source files and writing the destination 339 files. Therefore, if that file transfer service is compromised, 340 the attacker cannot modify source files, cannot create or modify 341 other files to which Steve has access, cannot start jobs on behalf 342 of Steve, etc. All that an attacker would be able to do is read 343 the specific files to which the file transfer service has been 344 delegated read access, and write bogus files in place of those that 345 the file transfer service has been delegated write access. 346 Further, by limiting the lifetime of the credential that is 347 delegated to the file transfer service, the effects of a compromise 348 can be further mitigated. 350 Other potential uses for restricted proxy credentials are discussed 351 in [i8]. 353 2.5 Motivation for Unique Proxy Name 355 The dynamic creation of entities (e.g. processes and services) is 356 an essential part of Grid computing. These entities will require 357 rights in order to securely perform their function. While it is 358 possible to obtain rights solely through proxying as described in 359 previous sections, this has limitations. For example what if an 360 entity should have rights that are granted not just from the proxy 361 issuer but from a third party as well? While it is possible in 362 this case for the entity to obtain and hold two proxy 363 certifications, in practice it is simpler for subsequent 364 credentials to take the form of attribute certificates. 366 It is also desirable for these entities to have a unique identity 367 so that they can be explicitly discussed in policy statements. For 368 example, a user initiating a third-party FTP transfer could grant 369 each FTP server a PC with a unique identity and inform each server 370 of the identity of the other, then when the two servers connected 371 they could authenticate themselves and know they are connected to 372 the proper party. 374 In order for a party to have rights of it's own it requires a 375 unique identity. Possible options for obtaining an unique identity 376 are: 378 1) Obtain an identity from a traditional Certification Authority 379 (CA). 381 2) Obtain a new identity independently - for example by using the 382 generated public key and a self-signed certificate. 384 3) Derive the new identity from an existing identity. 386 In this document we describe an approach to option #3, because: 388 * It is reasonably light-weight, as it can be done without 389 interacting with a third party. This is important when creating 390 identities dynamically. 392 * As described in the previous section, a common use for PCs is 393 for restricted proxying, so deriving their identity from the 394 identity of the EEC makes this straightforward. Nonetheless 395 there are circumstances where the creator does not wish to 396 delegate all or any of its rights to a new entity. Since the 397 name is unique, this is easily accomplished by #3 as well, by 398 allowing the application of a policy to limit proxying. 400 2.6 Description Of Approach 402 This document defines an X.509 "Proxy Certificate" or "PC" as a 403 means of providing for restricted proxying within an (extended) 404 X.509 PKI based authentication system. 406 A Proxy Certificate is an X.509 public key certificate with the 407 following properties: 409 1) It is signed by either an X.509 End Entity Certificate (EEC), or 410 by another PC. This EEC or PC is referred to as the Proxy 411 Issuer (PI). 413 2) It can sign only another PC. It cannot sign an EEC. 415 3) It has its own public and private key pair, distinct from any 416 other EEC or PC. 418 4) It has an identity derived from the identity of the EEC that 419 signed the PC. When a PC is used for authentication, in may 420 inherit rights of the EEC that signed the PC, subject to the 421 restrictions that are placed on that PC by the EEC. 423 5) Although its identity is derived from the EEC's identity, it is 424 also unique. This allows this identity to be used for 425 authorization as an independent identity from the identity of 426 the issuing EEC, for example in conjunction with attribute 427 assertions as defined in [i3]. 429 6) It contains a new X.509 extension to identify it as a PC and to 430 place policies on the use of the PC. This new extension, along 431 with other X.509 fields and extensions, are used to enable 432 proper path validation and use of the PC. 434 The process of creating a PC is as follows: 436 1) A new public and private key pair is generated. 438 2) That key pair is used to create a request for a Proxy Certificate 439 that conforms to the profile described in this document. 441 3) A Proxy Certificate, signed by the private key of the EEC or by 442 another PC, is created in response to the request. During this 443 process, the PC request is verified to ensure that the requested 444 PC is valid (e.g. it is not an EEC, the PC fields are 445 appropriately set, etc). 447 When a PC is created as part of a delegation from entity A to 448 entity B, this process is modified by performing steps #1 and #2 449 within entity B, then passing the PC request from entity B to 450 entity A over an authenticated, integrity checked channel, then 451 entity A performs step #3 and passes the PC back to entity B. 453 Path validation of a PC is very similar to normal path validation, 454 with a few additional checks to ensure, for example, proper PC 455 signing constraints. 457 2.7 Features Of This Approach 459 Using Proxy Certificates to perform delegation has several features 460 that make it attractive: 462 * Ease of integration 464 . Because a PC requires only a minimal change to path 465 validation, it is very easy to incorporate support for Proxy 466 Certificates into existing X.509 based software. For 467 example, SSL/TLS requires no protocol changes to support 468 authentication using a PC. Further, an SSL/TLS 469 implementation requires only minor changes to support PC path 470 validation, and to retrieve the authenticated subject of the 471 signing EEC instead of the subject of the PC for 472 authorization purposes. 474 . Many existing authorization systems use the X.509 subject 475 name as the basis for access control. Proxy Certificates can 476 be used with such authorization systems without modification, 477 since such a PC inherits its name and rights from the EEC 478 that signed it and the EEC name can be used in place of the 479 PC name for authorization decisions. 481 * Ease of use 483 . Using PC for single sign-on helps make X.509 PKI 484 authentication easier to use, by allowing users to "login" 485 once and then perform various operations securely. 487 . For many users, properly managing their own EEC private key 488 is a nuisance at best, and a security risk at worst. One 489 option easily enabled with a PC is to manage the EEC private 490 keys and certificates in a centrally managed repository. 491 When a user needs a PKI credential, the user can login to the 492 repository using name/password, one time password, etc. Then 493 the repository can delegate a PC to the user with proxy 494 rights, but continue to protect the EEC private key in the 495 repository. 497 * Protection of private keys 499 . By using the remote delegation approach outlined above, 500 entity A can delegate a PC to entity B, without entity B ever 501 seeing the private key of entity A, and without entity A ever 502 seeing the private key of the newly delegated PC held by 503 entity B. In other words, private keys never need to be 504 shared or communicated by the entities participating in a 505 delegation of a PC. 507 . When implementing single sign-on, using a PC helps protect 508 the private key of the EEC, because it minimizes the exposure 509 and use of that private key. For example, when an EEC 510 private key is password protected on disk, the password and 511 unencrypted private key need only be available during the 512 creation of the PC. That PC can then be used for the 513 remainder of its valid lifetime, without requiring access to 514 the EEC password or private key. Similarly, when the EEC 515 private key lives on a smartcard, the smartcard need only be 516 present in the machine during the creation of the PC. 518 * Limiting consequences of a compromised key 520 . When creating a PC, the PI can limit the validity period of 521 the PC, the depth of the PC path that can be created by that 522 PC, and key usage of the PC and its descendents. Further, 523 fine-grained policies can be carried by a PC to even further 524 restrict the operations that can be performed using the PC. 525 These restrictions permit the PI to limit damage that could 526 be done by the bearer of the PC, either accidentally or 527 maliciously. 529 . A compromised PC private key does NOT compromise the EEC 530 private key. This makes a short term, or an otherwise 531 restricted PC attractive for day-to-day use, since a 532 compromised PC does not require the user to go through the 533 usually cumbersome and time consuming process of having the 534 EEC with a new private key reissued by the CA. 536 See Section 5 below for more discussion on how Proxy Certificates 537 relate to Attribute Certificates. 539 3 Certificate and Certificate Extensions Profile 541 This section defines the usage of X.509 certificate fields and 542 extensions in Proxy Certificates, and defines one new extension for 543 Proxy Certificate Information. 545 All Proxy Certificates MUST include the Proxy Certificate 546 Information (ProxyCertInfo) extension defined in this section and 547 the extension MUST be critical. 549 3.1 Issuer 551 The Proxy Issuer of a Proxy Certificate MUST be either an End 552 Entity Certificate, or another Proxy Certificate. 554 The Proxy Issuer MUST NOT have an empty subject field. 556 The issuer field of a Proxy Certificate MUST contain the subject 557 field of its Proxy Issuer. 559 If the Proxy Issuer certificate has the KeyUsage extension, the 560 Digital Signature bit MUST be asserted. 562 3.2 Issuer Alternative Name 564 The issuerAltName extension MUST NOT be present in a Proxy 565 Certificate. 567 3.3 Serial Number 569 The serial number of a Proxy Certificate (PC) SHOULD be unique 570 amongst all Proxy Certificates issued by a particular Proxy Issuer. 571 However, a Proxy Issuer MAY use an approach to assigning serial 572 numbers that merely ensures a high probability of uniqueness. 574 For example, a Proxy Issuer MAY use a sequentially assigned integer 575 or a UUID to assign a unique serial number to a PC it issues. Or a 576 Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a 577 serial number with a high probability of uniqueness. 579 3.4 Subject 581 The subject field of a Proxy Certificate MUST be the issuer field 582 (that is the subject of the Proxy Issuer) appended with a single 583 Common Name component. 585 The value of the Common Name SHOULD be unique to each Proxy 586 Certificate bearer amongst all Proxy Certificates with the same 587 issuer. 589 If a Proxy Issuer issues two proxy certificates to the same bearer, 590 the Proxy Issuer MAY choose to use the same Common Name for both. 591 Examples of this include Proxy Certificates for different uses 592 (e.g. signing vs encryption) or the re-issuance of an expired Proxy 593 Certificate. 595 The Proxy Issuer MAY use an approach to assigning Common Name 596 values that merely ensures a high probability of uniqueness. This 597 value MAY be the same value used for the serial number. 599 The result of this approach is that all subject names of Proxy 600 Certificates are derived from the name of the issuing EEC (it will 601 be the first part of the subject name appended with one or more CN 602 components) and are unique to each bearer. 604 3.5 Subject Alternative Name 606 The subjectAltName extension MUST NOT be present in a Proxy 607 Certificate. 609 3.6 Key Usage and Extended Key Usage 611 If the Proxy Issuer certificate has a Key Usage extension, the 612 Digital Signature bit MUST be asserted. 614 This draft places no constraints on the presence or contents of the 615 key usage and extended key usage extension. However, section 4.2 616 explains what functions should be allowed a proxy certificate by a 617 relying party. 619 3.7 Basic Constraints 621 The cA field in the basic constraints extension MUST NOT be TRUE. 623 3.8 The ProxyCertInfo Extension 625 A new extension, ProxyCertInfo, is defined in this subsection. 626 Presence of the ProxyCertInfo extension indicates that a 627 certificate is a Proxy Certificate and whether or not the issuer of 628 the certificate has placed any restrictions on its use. 630 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 631 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 633 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 634 id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } 636 ProxyCertInfo ::= SEQUENCE { 637 pCPathLenConstraint INTEGER (0..MAX) OPTIONAL, 638 proxyPolicy ProxyPolicy } 640 ProxyPolicy ::= SEQUENCE { 641 policyLanguage OBJECT IDENTIFIER, 642 policy OCTET STRING OPTIONAL } 644 If a certificate is a Proxy Certificate, then the proxyCertInfo 645 extension MUST be present, and this extension MUST be marked as 646 critical. 648 If a certificate is not a Proxy Certificate, then the proxyCertInfo 649 extension MUST be absent. 651 The ProxyCertInfo extension consists of one required and two 652 optional fields, which are described in detail in the following 653 subsections. 655 3.8.1 pCPathLenConstraint 657 The pCPathLenConstraint field, if present, specifies the maximum 658 depth of the path of Proxy Certificates that can be signed by this 659 Proxy Certificate. A pCPathLenConstraint of 0 means that this 660 certificate MUST NOT be used to sign a Proxy Certificate. If the 661 pCPathLenConstraint field is not present then the maximum proxy 662 path length is unlimited. End entity certificates have unlimited 663 maximum proxy path lengths. 665 3.8.2 proxyPolicy 667 The proxyPolicy field specifies a policy on the use of this 668 certificate for the purposes of authorization. Within the 669 proxyPolicy, the policy field is an expression of policy, and the 670 policyLanguage field indicates the language in which the policy is 671 expressed. 673 The proxyPolicy field in the proxyCertInfo extension does not 674 define a policy language to be used for proxy restrictions; rather, 675 it places the burden on those parties using that extension to 676 define an appropriate language, and to acquire an OID for that 677 language (or to select an appropriate previously-defined 678 language/OID). Because it is essential for the PI that issues a 679 certificate with a proxyPolicy field and the relying party that 680 interprets that field to agree on its meaning, the policy language 681 OID must correspond to a policy language (including semantics), not 682 just a policy grammar. 684 The policyLanguage field has two values of special importance, 685 defined in Appendix A, that MUST be understood by all parties 686 accepting Proxy Certificates: 688 * id-ppl-inheritAll indicates that this is an unrestricted proxy 689 that inherits all rights from the issuing PI. An unrestricted 690 proxy is a statement that the Proxy Issuer wishes to delegate 691 all of its authority to the bearer (i.e., to anyone who has that 692 proxy certificate and can prove possession of the associated 693 private key). For purposes of authorization, this an 694 unrestricted proxy effectively impersonates the issuing PI. 696 * id-ppl-independent indicates that this is an independent proxy 697 that inherits no rights from the issuing PI. This PC MUST be 698 treated as an independent identity by relying parties. The only 699 rights this PC has are those granted explicitly to it. 701 For either of the policyLanguage values listed above, the policy 702 field MUST NOT be present. 704 Other values for the policyLanguage field indicates that this is a 705 restricted proxy certification and have some other policy limiting 706 its ability to do proxying. In this case the policy field MAY be 707 present and it MUST contain information expressing the policy. If 708 the policy field is not present the policy MUST be implicit in the 709 value of the policyLanguage field itself. Authors of additional 710 policy languages are encouraged to publicly document their policy 711 language and list it in the IANA registry (see Section Error! 712 Reference source not found.). 714 Proxy policies are used to limit the amount of authority delegated, 715 for example to assert that the proxy certificate may be used only 716 to make requests to a specific server, or only to authorize 717 specific operations on specific resources. This document is 718 agnostic to the policies that can be placed in the policy field. 720 Proxy policies impose additional requirements on the relying party, 721 because only the relying party is in a position to ensure that 722 those policies are enforced. When making an authorization decision 723 based on a proxy certificate based on rights that proxy certificate 724 inherited from its issuer, it is the relying party's responsibility 725 to verify that the requested authority is compatible with all 726 policies in the PC's certificate path. In other words, the relying 727 party MUST verify that the following three conditions are all met: 729 1) The relying party MUST know how to interpret the proxy policy and 730 the request is allowed under that policy. 732 2) If the Proxy Issuer is an EEC then the relying party's local 733 policies MUST authorize the request for the entity named in the 734 EEC. 736 3) If the Proxy Issuer is another PC, then one of the following MUST 737 be true: 739 a. The relying party's local policies authorize the Proxy 740 Issuer to perform the request. 742 b. The Proxy Issuer inherits the right to perform the request 743 from its issuer by means of its proxy policy. This must be 744 verified by verifying these three conditions on the Proxy 745 Issuer in a recursive manner. 747 If these conditions are not met, the relying party MUST either deny 748 authorization, or ignore the PC and the whole certificate chain 749 including the EEC entirely when making its authorization decision 750 (i.e., make the same decision that it would have made had the PC 751 and it's certificate chain never been presented). 753 The relying party MAY impose additional restrictions as to which 754 proxy certificates it accepts. For example, a relying party MAY 755 choose to reject all proxy certificates, or MAY choose to accept 756 proxy certificates only for certain operations, etc. 758 Note that since a proxy certificate has a unique identity it MAY 759 also have rights granted to it by means other than inheritance from 760 it's issuer via its proxy policy. The rights granted to the bearer 761 of a PC are the union of the rights granted to the PC identity and 762 the inherited rights. The inherited rights consist of the 763 intersection of the rights granted to the PI identity intersected 764 with the proxy policy in the PC. 766 For example, imagine that Steve is authorized to read and write 767 files A and B on a file server, and that he uses his EEC to create 768 a PC that includes the policy that it can be used only to read or 769 write files A and C. Then a trusted attribute authority grants an 770 Attribute Certificate granting the PC the right to read file D. 771 This would make the rights of the PC equal to the union of the 772 rights granted to the PC identity (right to read file D) with the 773 intersection of the rights granted to Steve, the PI, (right to read 774 files A and B) with the policy in the PC (can only read files A and 775 C). This would mean the PC would have the following rights: 777 * Right to read file A: Steve has this right and he issued the PC 778 and his policy grants this right to the PC. 780 * Right to read file D: This right is granted explicitly to the PC 781 by a trusted authority. 783 The PC would NOT have the following rights: 785 * Right to read file B: Although Steve has this right, it is 786 excluded by his policy on the PC. 788 * Right to read file C: Although Steve's policy grants this right, 789 he does not have this right himself. 791 In many cases, the relying party will not have enough information 792 to evaluate the above criteria at the time that the certificate 793 path is validated. For example, if a certificate is used to 794 authenticate a connection to some server, that certificate is 795 typically validated during that authentication step, before any 796 requests have been made of the server. In that case, the relying 797 party MUST either have some authorization mechanism in place that 798 will check the proxy policies, or reject any certificate that 799 contains proxy policies (or that has a parent certificate that 800 contains proxy policies). 802 4 Proxy Certificate Path Validation 804 Proxy Certification path processing verifies the binding between 805 the proxy certificate distinguished name and proxy certificate 806 public key. The binding is limited by constraints which are 807 specified in the certificates which comprise the path and inputs 808 which are specified by the relying party. 810 This section describes an algorithm for validating proxy 811 certification paths. Conforming implementations of this 812 specification are not required to implement this algorithm, but 813 MUST provide functionality equivalent to the external behavior 814 resulting from this procedure. Any algorithm may be used by a 815 particular implementation so long as it derives the correct result. 817 The algorithm presented in this section validates the proxy 818 certificate with respect to the current date and time. A 819 conformant implementation MAY also support validation with respect 820 to some point in the past. Note that mechanisms are not available 821 for validating a proxy certificate with respect to a time outside 822 the certificate validity period. 824 Valid paths begin with the end entity certificate (EEC) that has 825 already been validated by public key certificate validation 826 procedures in RFC 3280 [n2]. The algorithm requires the public key 827 of the EEC and the EEC's subject distinguished name. 829 To meet the goal of verifying the proxy certificate, the proxy 830 certificate path validation process verifies, among other things, 831 that a prospective certification path (a sequence of n 832 certificates) satisfies the following conditions: 834 (a) for all x in {1, ..., n-1}, the subject of certificate x is 835 the issuer of proxy certificate x+1 and the subject 836 distinguished name of certificate x+1 is a legal subject 837 distinguished name to have been issued by certificate x; 839 (b) certificate 1 is valid proxy certificate issued by the end 840 entity certificate whose information is given as input to the 841 proxy certificate path validation process; 843 (c) certificate n is the proxy certificate to be validated; 844 (d) for all x in {1, ..., n}, the certificate was valid at the 845 time in question; and 847 (e) for all certificates in the path with a pCPathLenConstraint 848 field, the number of certificates in the path following that 849 certificate does not exceed the length specified in that field. 851 At this point there is no mechanism defined for revoking proxy 852 certificates. 854 4.1 Basic Proxy Certificate Path Validation 856 This section presents the algorithm in four basic steps to mirror 857 the description of public key certificate path validation in RFC 858 3280: (1) initialization, (2) basic proxy certificate processing, 859 (3) preparation for the next proxy certificate, and (4) wrap-up. 860 Steps (1) and (4) are performed exactly once. Step (2) is 861 performed for all proxy certificates in the path. Step (3) is 862 performed for all proxy certificates in the path except the final 863 proxy certificate. 865 Certificate path validation as described in RFC 3280 MUST have been 866 done prior to using this algorithm to validate the end entity 867 certificate. This algorithm then processes the proxy certificate 868 chain using the end entity certificate information produced by RFC 869 3280 path validation. 871 4.1.1 Inputs 873 This algorithm assumes the following inputs are provided to the 874 path processing logic: 876 (a) information about the entity certificate already verified 877 using RFC 3280 path validation. This information includes: 879 (1) the end entity name, 881 (2) the working_public_key output from RFC 3280 path 882 validation, 884 (3) the working_public_key_algorithm output from RFC 3280, 885 (4) and the working_public_key_parameters output from RFC 886 3280 path validation. 888 (b) prospective proxy certificate path of length n. 890 (c) acceptable-pc-policy-language-set: A set of proxy 891 certificate policy languages understood by the policy evaluation 892 code. The acceptable-pc-policy-language-set MAY contain the 893 special value id-ppl-anyLanguage (as defined in Appendix A) if 894 the path validation code should not check the proxy certificate 895 policy languages (typically because the set of known policy 896 languages is not known yet and will be checked later in the 897 authorization process). 899 (d) the current date and time. 901 4.1.2 Initialization 903 This initialization phase establishes the following state variables 904 based upon the inputs: 906 (a) working_public_key_algorithm: the digital signature 907 algorithm used to verify the signature of a proxy certificate. 908 The working_public_key_algorithm is initialized from the input 909 information provided from RFC 3280 path validation. 911 (b) working_public_key: the public key used to verify the 912 signature of a proxy certificate. The working_public_key is 913 initialized from the input information provided from RFC 3280 914 path validation. 916 (c) working_public_key_parameters: parameters associated with 917 the current public key, that may be required to verify a 918 signature (depending upon the algorithm). The 919 proxy_issuer_public_key_parameters variable is initialized from 920 the input information provided from RFC 3280 path validation. 922 (d) working_issuer_name: the issuer distinguished name expected 923 in the next proxy certificate in the chain. The 924 working_issuer_name is initialized to the distinguished name in 925 the end entity certificate validated by RFC 3280 path 926 validation. 928 (e) max_path_length: this integer is initialized to n, is 929 decremented for each proxy certificate in the path. This value 930 may also be reduced by the pcPathLenConstraint value of any 931 proxy certificate in the chain. 933 (f) proxy_policy_list: this list is empty to start and will be 934 filled in with the key usage extensions, extended key usage 935 extensions and proxy policies in the chain. 937 Upon completion of the initialization steps, perform the basic 938 certificate processing steps specified in 4.1.3. 940 4.1.3 Basic Proxy Certificate Processing 942 The basic path processing actions to be performed for proxy 943 certificate i (for all i in [1..n]) are listed below. 945 (a) Verify the basic certificate information. The certificate 946 MUST satisfy each of the following: 948 (1) The certificate was signed with the 949 working_public_key_algorithm using the working_public_key and 950 the working_public_key_parameters. 952 (2) The certificate validity period includes the current 953 time. 955 (3) The certificate issuer name is the working_issuer_name. 957 (4) The certificate subject name is the working_issuer_name 958 with a CN component appended. 960 (b) The proxy certificate MUST have a ProxyCertInfo extension. 961 Process the extension as follows: 963 (1) If the pCPathLenConstraint field is present in the 964 ProxyCertInfo field and the value it contains is less than 965 max_path_length, set max_path_length to its value. 967 (2) If acceptable-pc-policy-language-set is not id-ppl- 968 anyLanguage, the OID in the policyLanguage field MUST be 969 present in acceptable-pc-policy-language-set. 971 (c) The tuple containing the certificate subject name, 972 policyPolicy, key usage extension (if present) and extended key 973 usage extension (if present) must be appended to 974 proxy_policy_list. 976 (d) Process other certificate extensions, as described in [n2]: 978 (1) Recognize and process any other critical extensions 979 present in the proxy certificate. 981 (2) Process any recognized non-critical extension present in 982 the proxy certificate. 984 If either step (a), (b) or (d) fails, the procedure terminates, 985 returning a failure indication and an appropriate reason. 987 If i is not equal to n, continue by performing the preparatory 988 steps listed in 4.1.4. If i is equal to n, perform the wrap-up 989 steps listed in 4.1.5. 991 4.1.4 Preparation for next Proxy Certificate 993 (a) Verify max_path_length is greater than zero and decrement 994 max_path_length. 996 (b) Assign the certificate subject name to working_issuer_name. 998 (c) Assign the certificate subjectPublicKey to 999 working_public_key. 1001 (d) If the subjectPublicKeyInfo field of the certificate 1002 contains an algorithm field with non-null parameters, assign the 1003 parameters to the working_public_key_parameters variable. 1005 If the subjectPublicKeyInfo field of the certificate contains an 1006 algorithm field with null parameters or parameters are omitted, 1007 compare the certificate subjectPublicKey algorithm to the 1008 working_public_key_algorithm. If the certificate 1009 subjectPublicKey algorithm and the working_public_key_algorithm 1010 are different, set the working_public_key_parameters to null. 1012 (e) Assign the certificate subjectPublicKey algorithm to the 1013 working_public_key_algorithm variable. 1015 (f) If a key usage extension is present, verify that the 1016 digitalSignature bit is set. 1018 If either check (a) or (f) fails, the procedure terminates, 1019 returning a failure indication and an appropriate reason. 1021 If (a) and (f) complete successfully, increment i and perform the 1022 basic certificate processing specified in 4.1.3. 1024 4.1.5 Wrap-up Procedures 1026 (a) Assign the certificate subject name to working_issuer_name. 1028 (b) Assign the certificate subjectPublicKey to 1029 working_public_key. 1031 (c) If the subjectPublicKeyInfo field of the certificate 1032 contains an algorithm field with non-null parameters, assign the 1033 parameters to the proxy_issuer_public_key_parameters variable. 1035 If the subjectPublicKeyInfo field of the certificate contains an 1036 algorithm field with null parameters or parameters are omitted, 1037 compare the certificate subjectPublicKey algorithm to the 1038 proxy_issuer_public_key_algorithm. If the certificate 1039 subjectPublicKey algorithm and the 1040 proxy_issuer_public_key_algorithm are different, set the 1041 proxy_issuer_public_key_parameters to null. 1043 (d) Assign the certificate subjectPublicKey algorithm to the 1044 proxy_issuer_public_key_algorithm variable. 1046 4.1.6 Outputs 1048 If path processing succeeds, the procedure terminates, returning a 1049 success indication together with final value of the 1050 working_public_key, the working_public_key_algorithm, the 1051 working_public_key_parameters, and the proxy_policy_list. 1053 4.2 Using the Path Validation Algorithm 1055 Each Proxy Certificate contains a ProxyCertInfo extension, which 1056 always contains a policy language OID, and may also contain a 1057 policy OCTET STRING. These policies serve to indicate the desire of 1058 each issuer in the proxy certificate chain, starting with the EEC, 1059 to delegate some subset of their rights to the issued proxy 1060 certificate. This chain of policies is returned by the algorithm 1061 to the application. 1063 The application MAY make authorization decisions based on the 1064 subject distinguished name of the proxy certificate or on one of 1065 the proxy certificates in it's issuing chain or on the EEC that 1066 serves as the root of the chain. If an application chooses to use 1067 the subject distinguished name of a proxy certificate in the 1068 issuing chain or the EEC it MUST use the returned policies to 1069 restrict the rights it grants to the proxy certificate. If the 1070 application does not know how to parse any policy in the policy 1071 chain it MUST not use, for the purposes of making authorization 1072 decisions, the subject distinguished name of any certificate in the 1073 chain prior to the certificate in which the unrecognized policy 1074 appears. 1076 Application making authorization decisions based on the contents of 1077 the proxy certificate key usage or extended key usage extensions 1078 MUST examine the list of key usage, extended key usage and proxy 1079 policies resulting from proxy certificate path validation and 1080 determine the effective key usage functions of the proxy 1081 certificate as follows: 1083 * If a certificate is a proxy certificate with a proxy policy of 1084 id-ppl-independent or an end entity certificate, the effective 1085 key usage functions of that certificate is as defined by the key 1086 usage and extended key usage extensions in that certificate. The 1087 key usage functionality of the issuer has no bearing on the 1088 effective key usage functionality. 1090 * If a certificate is a proxy certificate with a policy other than 1091 id-ppl-independent, the effective key usage and extended key 1092 usage functionality of the proxy certificate is the intersection 1093 of the functionality of those extensions in the proxy 1094 certificate and the effective key usage functionality of the 1095 proxy issuer. 1097 5 Commentary 1099 This section provides non-normative commentary on Proxy 1100 Certificates. 1102 5.1 Relationship to Attribute Certificates 1104 An Attribute Certificate [i3] can be used to grant to one identity, 1105 the holder, some attribute such as a role, clearance level, or 1106 alternative identity such as "charging identity" or "audit 1107 identity". This is accomplished by way of a trusted Attribute 1108 Authority (AA), which issues signed Attribute Certificates (AC), 1109 each of which binds an identity to a particular set of attributes. 1110 Authorization decisions can then be made by combining information 1111 from the authenticated End Entity Certificate providing the 1112 identity, with the signed Attribute Certificates providing binding 1113 of that identity to attributes. 1115 There is clearly some overlap between the capabilities provided by 1116 Proxy Certificates and Attribute Certificates. However, the 1117 combination of the two approaches together provides a broader 1118 spectrum of solutions to authorization in X.509 based systems, than 1119 either solution alone. This section seeks to clarify some of the 1120 overlaps, differences, and synergies between Proxy Certificate and 1121 Attribute Certificates. 1123 5.1.1 Types of Attribute Authorities 1125 For the purposes of this discussion, Attribute Authorities, and the 1126 uses of the Attribute Certificates that they produce, can be broken 1127 down into two broad classes: 1129 1) End entity AA: An End Entity Certificate may be used to sign an 1130 AC. This can be used, for example, to allow an end entity to 1131 delegate some of its privileges to another entity. 1133 2) Third party AA: A separate entity, aside from the end entity 1134 involved in an authenticated interaction, may sign ACs in order 1135 to bind the authenticated identity with additional attributes, 1136 such as role, group, etc. For example, when a client 1137 authenticates with a server, the third party AA may provide an AC 1138 that binds the client identity to a particular group, which the 1139 server then uses for authorization purposes. 1141 This second type of Attribute Authority, the third party AA, works 1142 equally well with an EEC or a PC. For example, unrestricted Proxy 1143 Certificates can be used to delegate the EEC's identity to various 1144 other parties. Then when one of those other parties uses the PC to 1145 authenticate with a service, that service will receive the EEC's 1146 identity via the PC, and can apply any ACs that bind that identity 1147 to attributes in order to determine authorization rights. 1148 Additionally PC with policies could be used to selectively deny the 1149 binding of ACs to a particular proxy. An AC could also be bound to 1150 a particular PC using the subject or issuer and serial number of 1151 the proxy certificate. There would appear to be great synergies 1152 between the use of Proxy Certificates and Attribute Certificates 1153 produced by third party Attribute Authorities. 1155 However, the uses of Attribute Certificates that are granted by the 1156 first type of Attribute Authority, the end entity AA, overlap 1157 considerably with the uses of Proxy Certificates as described in 1158 the previous sections. Such Attribute Certificates are generally 1159 used for delegation of rights from one end entity to others, which 1160 clearly overlaps with the stated purpose of Proxy Certificates, 1161 namely single sign-on and delegation. 1163 5.1.2 Delegation Using Attribute Certificates 1165 In the motivating example in Section 2, PCs are used to delegate 1166 Steve's identity to the various other jobs and entities that need 1167 to act on Steve's behalf. This allows those other entities to 1168 authenticate as if they were Steve, for example to the mass storage 1169 system. 1171 A solution to this example could also be cast using Attribute 1172 Certificates that are signed by Steve's EEC, which grant to the 1173 other entities in this example the right to perform various 1174 operations on Steve's behalf. In this example, the reliable file 1175 transfer service and all the hosts involved in file transfers, the 1176 starter program, the agent, the simulation jobs, and the post- 1177 processing job would each have their own EECs. Steve's EEC would 1178 therefore issue ACs to bind each of those other EEC identities to 1179 attributes that grant the necessary privileges allow them to, for 1180 example, access the mass storage system. 1182 However, this AC based solution to delegation has some 1183 disadvantages as compared to the PC based solution: 1185 * All protocols, authentication code, and identity based 1186 authorization services must be modified to understand ACs. With 1187 the PC solution, protocols (e.g. TLS) likely need no 1188 modification, authentication code needs minimal modification 1189 (e.g. to perform PC aware path validation), and identity based 1190 authorization services need minimal modification (e.g. possibly 1191 to find the EEC name and to check for any proxy policies). 1193 * ACs need to be created by Steve's EEC, which bind attributes to 1194 each of the other identities involved in the distributed 1195 application (i.e. the agent, simulation jobs, and post- 1196 processing job the file transfer service, the hosts transferring 1197 files). This implies that Steve must know in advance which 1198 other identities may be involved in this distributed 1199 application, in order to generate the appropriate ACs which are 1200 signed by Steve's ECC. On the other hand, the PC solution 1201 allows for much more flexibility, since parties can further 1202 delegate a PC without a priori knowledge by the originating EEC. 1204 There are many unexplored tradeoffs and implications in this 1205 discussion of delegation. However, reasonable arguments can be 1206 made in favor of either an AC based solution to delegation or a PC 1207 based solution to delegation. The choice of which approach should 1208 be taken in a given instance may depend on factors such as the 1209 software that it needs to be integrated into, the type of 1210 delegation required, and religion. 1212 5.1.3 Propagation of Authorization Information 1214 One possible use of Proxy Certificates is to carry authorization 1215 information associated with a particular identity. 1217 The merits of placing authorization information into End Entity 1218 Certificates (also called a Public Key Certificate or PKC) have 1219 been widely debated. For example, Section 1 of "An Internet 1220 Attribute Certificate Profile for Authorization" [i3] states: 1222 "Authorization information may be placed in a PKC extension or 1223 placed in a separate attribute certificate (AC). The placement 1224 of authorization information in PKCs is usually undesirable for 1225 two reasons. First, authorization information often does not 1226 have the same lifetime as the binding of the identity and the 1227 public key. When authorization information is placed in a PKC 1228 extension, the general result is the shortening of the PKC 1229 useful lifetime. Second, the PKC issuer is not usually 1230 authoritative for the authorization information. This results 1231 in additional steps for the PKC issuer to obtain authorization 1232 information from the authoritative source. 1234 For these reasons, it is often better to separate authorization 1235 information from the PKC. Yet, authorization information also 1236 needs to be bound to an identity. An AC provides this binding; 1237 it is simply a digitally signed (or certified) identity and set 1238 of attributes." 1240 Placing authorization information in a PC mitigates the first 1241 undesirable property cited above. Since a PC has a lifetime that 1242 is mostly independent of (always shorter than) its signing EEC, a 1243 PC becomes a viable approach for carrying authorization information 1244 for the purpose of delegation. 1246 The second undesirable property cited above is true. If a third 1247 party AA is authoritative, then using ACs issued by that third 1248 party AA is a natural approach to disseminating authorization 1249 information. However, this is true whether the identity being 1250 bound by these ACs comes from an EEC (PKC), or from a PC. 1252 There is one case, however, that the above text does not consider. 1253 When performing delegation, it is usually the EEC itself that is 1254 authoritative (not the EEC issuer, or any third party AA). That 1255 is, it is up to the EEC to decide what authorization rights it is 1256 willing to grant to another party. In this situation, including 1257 such authorization information into PCs that are generated by the 1258 EEC seems a reasonable approach to disseminating such information. 1260 5.1.4 Proxy Certificate as Attribute Certificate Holder 1262 In a system that employs both PCs and ACs, one can imagine the 1263 utility of allowing a PC to be the holder of an AC. This would 1264 allow for a particular delegated instance of an identity to be 1265 given an attribute, rather than all delegated instances of that 1266 identity being given the attribute. 1268 However, the issue of how to specify a PC as the holder of an AC 1269 remains open. An AC could be bound to a particular instance of a 1270 PC using the unique subject name of the PC, or it's issuer and 1271 serial number combination. 1273 Unrestricted PCs issued by that PC would then inherit those ACs and 1274 independent PCs would not. PCs issued with a policy would depend 1275 on the policy as to whether or not they inherit the issuing PC's 1276 ACs (and potentially which ACs they inherit). 1278 While an AC can be bound to one PC by the AA, how can the AA 1279 restrict that PC from passing it on to a subsequently delegated PC? 1280 One possible solution would be to define an extension to attribute 1281 certificates that allows the attribute authority to state whether 1282 an issued AC is to apply only to the particular entity to which it 1283 is bound, or if it may apply to PCs issued by that entity. 1285 One issue that an AA in this circumstance would need to be aware of 1286 is that the PI of the PC that the AA bound the AC to, could issue 1287 another PC with the same name as the original PC to a different 1288 entity, effectively stealing the AC. This implies that an AA 1289 issuing an AC to a PC need to not only trust the entity holding the 1290 PC, but the entity holding the PC's issuer as well. 1292 5.2 Kerberos 5 Tickets 1294 The Kerberos Network Authentication Protocol (RFC 1510 [i8]) is a 1295 widely used authentication system based on conventional (shared 1296 secret key) cryptography. It provides support for single sign-on 1297 via creation of "Ticket Granting Tickets" or "TGT", and support for 1298 delegation of rights via "forwardable tickets". 1300 Kerberos 5 tickets have informed many of the ideas surrounding 1301 X.509 Proxy Certificates. For example, the local creation of a 1302 short-lived PC can be used to provide single sign-on in an X.509 1303 PKI based system, just as creation of short-lived TGT allows for 1304 single sign-on in a Kerberos based system. And just as a TGT can 1305 be forwarded (i.e. delegated) to another entity to allow for 1306 proxying in a Kerberos based system, so can a PC can be delegated 1307 to allow for proxying in an X.509 PKI based system. 1309 A major difference between a Kerberos TGT and an X.509 PC is that 1310 while creation and delegation of a TGT requires the involvement of 1311 a third party (the Kerberos Domain Controller), a PC can be 1312 unilaterally created without the active involvement of a third 1313 party. That is, a user can directly create a PC from an EEC for 1314 single sign-on capability, without requiring communication with a 1315 third party. And an entity with a PC can delegate the PC to 1316 another entity (i.e. by creating a new PC, signed by the first) 1317 without requiring communication with a third party. 1319 The method used by Kerberos implementations to protect a TGT can 1320 also be used to protect the private key of a PC. For example, some 1321 Unix implementations of Kerberos use standard Unix file system 1322 security to protect a user's TGT from compromise. Similarly, the 1323 Globus Toolkit's Grid Security Infrastructure implementation of 1324 Proxy Certificates protects a user's PC private key using this same 1325 approach. 1327 5.3 Examples of usage of Proxy Restrictions 1329 This section gives some examples of Proxy Certificate usage and 1330 some examples of how the Proxy policy can be used to restrict Proxy 1331 Certificates. 1333 5.3.1 Example use of proxies without Restrictions 1335 Steve wishes to perform a third-party FTP transfer between two FTP 1336 servers. Steve would use an existing PC to authenticate to both 1337 servers and delegate a PC to both hosts. He would inform each host 1338 of the unique subject name of the PC given to the other host. When 1339 the servers establish the data channel connection to each other, 1340 they use these delegated credentials to perform authentication and 1341 verify they are talking to the correct entity by checking the 1342 result of the authentication matches the name as provided by Steve. 1344 5.3.2 Example use of proxies with Restrictions 1346 Steve wishes to delegate to a process the right to perform a 1347 transfer of a file from host H1 to host H2 on his behalf. Steve 1348 would delegate a PC to the process and he would use Proxy Policy to 1349 restrict the delegated PC to two rights - the right to read file F1 1350 on host H1 and the right to write file F2 on host H2. 1352 The process then uses this restricted PC to authenticate to servers 1353 H1 and H2. The process would also delegate a PC to both servers. 1355 Note that these delegated PCs would inherit the restrictions of 1356 their parents, though this is not relevant to this example. As in 1357 the example in the previous Section, each host would be provided 1358 with the unique name of the PC given to the other server. 1360 Now when the process issues the command to transfer the file F1 on 1361 H1 and to F2 on H2, these two servers perform an authorization 1362 check based on the restrictions in the PC that the process used to 1363 authenticate with them (in addition to any local policy they have). 1364 Namely H1 checks that the PC gives the user the right to read F1 1365 and H2 checks that the PC gives the user the right to write F2. 1366 When setting up the data channel the servers would again verify the 1367 names resulting from the authentication match the names provided by 1368 Steve as in the example in the previous Section. 1370 The extra security provided by these restrictions is that now if 1371 the PC delegated to the process by Steve is stolen, its use is 1372 greatly limited. 1374 5.4 Delegation Tracing 1376 A relying party accepting a Proxy Certificate may have an interest 1377 in knowing which parties issued earlier Proxy Certificates in the 1378 certificate chain and to whom they delegated them. For example it 1379 may know that a particular service or resource is known to have 1380 been compromised and if any part of a Proxy Certificate's chain was 1381 issued to the compromised service a relying party may wish to 1382 disregard the chain. 1384 A delegation tracing mechanism was considered by the authors as 1385 additional information to be carried in the ProxyCertInfo 1386 extension. However at this time agreement has not been reached as 1387 to what this information should include so it was left out of this 1388 document, and will instead be considered in future revisions. The 1389 debate mainly centers on whether the tracing information should 1390 simply contain the identity of the issuer and receiver or it should 1391 also contain all the details of the delegated proxy and a signed 1392 statement from the receiver that the proxy was actually acceptable 1393 to it. 1395 5.4.1 Site Information in Delegation Tracing 1397 In some cases, it may be desirable to know the hosts involved in a 1398 delegation transaction (for example, a relying party may wish to 1399 reject proxy certificates that were created on a specific host or 1400 domain). An extension could be modified to include the PA's and 1401 Acceptor's IP addresses; however, IP addresses are typically easy 1402 to spoof, and in some cases the two parties to a transaction may 1403 not agree on the IP addresses being used (e.g., if the Acceptor is 1404 on a host that uses NAT, the Acceptor and the PA may disagree about 1405 the Acceptor's IP address). 1407 Another suggestion was, in those cases where domain information is 1408 needed, to require that the subject names of all End Entities 1409 involved (the Acceptor(s) and the End Entity that appears in a PC's 1410 certificate path) include domain information. 1412 6 Security Considerations 1414 In this Section we discuss security considerations related to the 1415 use of Proxy Certificates. 1417 6.1 Compromise of a Proxy Certificate 1419 A Proxy Certificate is generally less secure than the EEC that 1420 issued it. This is due to the fact that the private key of a PC is 1421 generally not protected as rigorously as that of the EEC. For 1422 example, the private key of a PC is often protected using only file 1423 system security, in order to allow that PC to be used for single 1424 sign-on purposes. This makes the PC more susceptible to 1425 compromise. 1427 However, the risk of a compromised PC is only the misuse of a 1428 single user's privileges. Due to the PC path validation checks, a 1429 PC cannot be used to sign an EEC or PC for another user. 1431 Further, a compromised PC can only be misused for the lifetime of 1432 the PC, and within the bound of the restriction policy carried by 1433 the PC. Therefore, one common way to limit the misuse of a 1434 compromised PC is to limit its validity period to no longer than is 1435 needed, and/or to include a restriction policy in the PC that 1436 limits the use of the (compromised) PC. 1438 In addition, if a PC is compromised, it does NOT compromise the EEC 1439 that created the PC. This property is of great utility in 1440 protecting the highly valuable, and hard to replace, public key of 1441 the EEC. In other words, the use of Proxy Certificates to provide 1442 single sign-on capabilities in an X.509 PKI environment can 1443 actually increase the security of the end entity certificates, 1444 because creation and use of the PCs for user authentication limits 1445 the exposure of the EEC private key to only the creation of the 1446 first level PC. 1448 6.2 Restricting Proxy Certificates 1450 The pCPathLenConstraint field of the proxyCertInfo extension can be 1451 used by an EEC to limit subsequent delegation of the PC. A service 1452 may choose to only authorize a request if a valid PC can be 1453 delegated to it. An example of such as service is a job starter, 1454 which may choose to reject a job start request if a valid PC cannot 1455 be delegated to it. By limiting the pCPathLenConstraint, an EEC 1456 can ensure that a compromised PC of one job cannot be used to start 1457 additional jobs elsewhere. 1459 An EEC or PC can limit what a new PC can be used for by turning off 1460 bits in the Key Usage and Extended Key Usage extensions. Once a 1461 key usage or extended key usage has been removed, the path 1462 validation algorithm ensures that it cannot be added back in a 1463 subsequent PC. In other words, key usage can only be decreased in 1464 PC chains. 1466 The EEC could use the CRL Distribution Points extension and/or OCSP 1467 to take on the responsibility of revoking PCs that it had issued, 1468 if it felt that they were being misused. 1470 6.3 Relying Party Trust of Proxy Certificates 1472 The relying party that is going to authorize some actions on the 1473 basis of a PC will be aware that it has been presented with a PC, 1474 and can determine the depth of the delegation and the time that the 1475 delegation took place. It may want to use this information in 1476 addition to the information from the signing EEC. Thus a highly 1477 secure resource might refuse to accept a PC at all, or maybe only a 1478 single level of delegation, etc. 1480 The relying party should also be aware that since the policy 1481 restricting the rights of a PC is the intersection of the policy of 1482 all the PCs in it's certificate chain, this means any change in the 1483 certificate chain can effect the policy of the PC. Since there is 1484 no mechanism in place to enforce unique subject names of PCs, if an 1485 issuer were two PCs with identical names and keys, but different 1486 rights this could allow the two PCs to be substituted for each 1487 other in path validation and effect the rights of a PC down the 1488 chain. Ultimately, this means the relying party places trust in the 1489 entities that are acting as Proxy Issuers in the chain to behave 1490 properly. 1492 6.4 Protecting Against Denial of Service with Key Generation 1494 As discussed in Section 2.3, one of the motivations for Proxy 1495 Certificates is to allow for dynamic delegation between parties. 1496 This delegation potentially requires, by the party receiving the 1497 delegation, the generation of a new key pair which is a potentially 1498 computationally expensive operation. Care should be taken by such 1499 parties to prevent another entity from performing a denial of 1500 service attack by causing them to consume large amount of resource 1501 doing key generation. 1503 A general guideline would always to perform authentication of the 1504 delegating party to prevent such attacks from being performed 1505 anonymously. Another guideline would be to maintain some state to 1506 detect and prevent such attacks. 1508 6.5 Use of Proxy Certificates with a Central Repository 1510 As discussed in Section 2.7, one potential use of Proxy 1511 Certificates is to ease certificate management for end users by 1512 storing the EEC private keys and certificates in a centrally 1513 managed repository. When a user needs a PKI credential, the user 1514 can login to the repository using name/password, one time password, 1515 etc. and the repository would then delegate a PC to the user with 1516 proxy rights, but continue to protect the EEC private key in the 1517 repository. 1519 Care must be taken with this approach since compromise of the 1520 repository will potentially give the attacker access to the long- 1521 term private keys stored in the repository. It is strongly 1522 suggested that some form of hardware module be used to store the 1523 long-term private keys, which will serve to help prevent their 1524 direct threat though it may still allow a successful attacker to 1525 use the keys while the repository is compromised to sign arbitrary 1526 objects (including Proxy Certificates). 1528 7 IANA Considerations 1530 IANA should establish a registry for policy languages. Registration 1531 under IETF space is by IETF standards action as described in [i9]. 1532 Private policy languages should be under organizational OIDs; 1533 policy language authors are encouraged to list such languages in 1534 the IANA registry, along with a pointer to a specification. 1536 8 Normative References 1538 [n1] Bradner, S., "Key words for use in RFCs to Indicate 1539 Requirement Levels," BCP 14, RFC 2119, March 1997. 1540 [n2] Housley, R., W. Polk, W. Ford, and D. Solo, "Internet X.509 1541 Public Key Infrastructure Certificate and Certificate 1542 Revocation List (CRL) Profile," RFC 3280, April 2002. 1544 9 Informational References 1546 [i1] Butler, R., D. Engert, I. Foster, C. Kesselman, and S. 1547 Tuecke, "A National-Scale Authentication Infrastructure," 1548 IEEE Computer, vol. 33, pp. 60-66, 2000. 1549 [i2] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0," 1550 RFC 2246, January 1999. 1551 [i3] Farrell, S. and R. Housley, "An Internet Attribute 1552 Certificate Profile for Authorization," RFC 3281, April 1553 2002. 1554 [i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A 1555 Security Architecture for Computational Grids," presented 1556 at Proceedings of the 5th ACM Conference on Computer and 1557 Communications Security, 1998. 1558 [i5] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of 1559 the Grid: Enabling Scalable Virtual Organizations," 1560 International Journal of Supercomputer Applications, 2001. 1562 [i6] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation 1563 Protocol," Internet Draft draft-ietf-tls-delegation-00.txt, 1564 2001 1565 [i7] Kohl, J. and C. Neuman, "The Kerberos Network 1566 Authentication Service (V5)," RFC 1510, September 1993. 1567 [i8] B. Clifford Neuman. "Proxy-Based Authorization and 1568 Accounting for Distributed Systems." In Proceedings of the 1569 13th International Conference on Distributed Computing 1570 Systems, pages 283-291, May 1993. 1572 [i9] Narten, T. and and H. Alvestrand. "Guidelines for Writing 1573 an IANA Considerations Section in RFC," RFC 2434, October 1574 1998. 1576 10 Acknowledgments 1578 We are pleased to acknowledge significant contributions to this 1579 document by David Chadwick, Ian Foster, Jarek Gawor, Carl 1580 Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist. 1582 We are grateful to numerous colleagues for discussions on the 1583 topics covered in this paper, in particular (in alphabetical order, 1584 with apologies to anybody we've missed): Carlisle Adams, Joe 1585 Bester, Randy Butler, Doug Engert, Keith Jackson, Steve Hanna, Russ 1586 Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, 1587 Ellen McDermott, Clifford Neuman, Gene Tsudik. 1589 We are also grateful to members of the Global Grid Forum (GGF) Grid 1590 Security Infrastructure working group (GSI-WG), and the Internet 1591 Engineering Task Force (IETF) Public-Key Infrastructure (X.509) 1592 working group (PKIX) for feedback on this document. 1594 This work was supported in part by the Mathematical, Information, 1595 and Computational Sciences Division subprogram of the Office of 1596 Advanced Scientific Computing Research, U.S. Department of Energy, 1597 under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense 1598 Advanced Research Projects Agency under contract N66001-96-C-8523; 1599 by the National Science Foundation; and by the NASA Information 1600 Power Grid project. 1602 11 Contact Information 1604 Steven Tuecke 1605 Distributed Systems Laboratory 1606 Mathematics and Computer Science Division 1607 Argonne National Laboratory 1608 Argonne, IL 60439 1609 Phone: 630-252-8711 1610 Email: tuecke@mcs.anl.gov 1612 Von Welch 1613 National Center for Supercomputing Applications 1614 University of Illinois 1615 Email: vwelch@ncsa.uiuc.edu 1617 Doug Engert 1618 Argonne National Laboratory 1619 Email: deengert@anl.gov 1621 Laura Pearlman 1622 University of Southern California, Information Sciences Institute 1623 Email: laura@isi.edu 1625 Mary Thompson 1626 Lawrence Berkeley National Laboratory 1627 Email: mrthompson@lbl.gov 1629 12 Copyright Notice 1631 Copyright (C) The Internet Society (September 23, 2002). All Rights 1632 Reserved. 1634 This document and translations of it may be copied and furnished to 1635 others, and derivative works that comment on or otherwise explain 1636 it or assist in its implementation may be prepared, copied, 1637 published and distributed, in whole or in part, without restriction 1638 of any kind, provided that the above copyright notice and this 1639 paragraph are included on all such copies and derivative works. 1640 However, this document itself may not be modified in any way, such 1641 as by removing the copyright notice or references to the Internet 1642 Society or other Internet organizations, except as needed for the 1643 purpose of developing Internet standards in which case the 1644 procedures for copyrights defined in the Internet Standards process 1645 must be followed, or as required to translate it into languages 1646 other than English. 1648 The limited permissions granted above are perpetual and will not be 1649 revoked by the Internet Society or its successors or assigns. 1651 This document and the information contained herein is provided on 1652 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1653 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1654 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1655 THE INFORMATION HEREIN WILL NOT INFRINGE MERCHANTABILITY OR FITNESS 1656 FOR A PARTICULAR PURPOSE. 1658 13 Intellectual Property Statement 1660 The IETF takes no position regarding the validity or scope of any 1661 intellectual property or other rights that might be claimed to 1662 pertain to the implementation or use of the technology described in 1663 this document or the extent to which any license under such rights 1664 might or might not be available; neither does it represent that it 1665 has made any effort to identify any such rights. Information on 1666 the IETF's procedures with respect to rights in standards-track and 1667 standards-related documentation can be found in BCP-11. Copies of 1668 claims of rights made available for publication and any assurances 1669 of licenses to be made available, or the result of an attempt made 1670 to obtain a general license or permission for the use of such 1671 proprietary rights by implementers or users of this specification 1672 can be obtained from the IETF Secretariat. 1674 The IETF invites any interested party to bring to its attention any 1675 copyrights, patents or patent applications, or other proprietary 1676 rights which may cover technology that may be required to practice 1677 this standard. Please address the information to the IETF 1678 Executive Director. 1680 Appendix A. 1988 ASN.1 Module 1682 PKIXproxy88 {iso(1) identified-organization(3) dod(6) 1683 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1684 proxy-cert-extns(25) } 1686 DEFINITIONS EXPLICIT TAGS ::= 1688 BEGIN 1690 -- EXPORTS ALL -- 1692 -- IMPORTS NONE -- 1694 -- PKIX specific OIDs 1696 id-pkix OBJECT IDENTIFIER ::= 1697 { iso(1) identified-organization(3) 1698 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1700 -- private certificate extensions 1701 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1703 -- Locally defined OIDs 1705 -- The proxy certificate extension 1706 id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } 1708 -- Proxy certificate policy languages 1709 id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 } 1711 -- Proxy certificate policies languages defined in draft 1712 id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 } 1713 id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 } 1714 id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 } 1716 -- The ProxyCertInfo Extension 1717 ProxyCertInfoExtension ::= SEQUENCE { 1718 pCPathLenConstraint ProxyCertPathLengthConstraint 1719 OPTIONAL, 1720 proxyPolicy ProxyPolicy } 1722 ProxyCertPathLengthConstraint ::= INTEGER 1723 ProxyPolicy ::= SEQUENCE { 1724 policyLanguage OBJECT IDENTIFIER, 1725 policy OCTET STRING OPTIONAL } 1727 END 1729 Appendix B. Change Log (To be removed prior to publication) 1731 draft-ietf-pkix-impersonation-00 (February 2001) 1733 Initial submission. 1735 draft-ietf-pkix-proxy-00 (July 2001) 1737 Renamed to "Proxy Certificate", from "Impersonation 1738 Certificate", due to overwhelming feedback from IETF and GGF. 1740 Added proxyRestriction field to ProxyCertInfo extension. 1742 Added delegationTrace field to ProxyCertInfo extension. 1744 Updated to agree with draft-ietf-pkix-part1-08. 1746 draft-ietf-pkix-proxy-01 (August 2001) 1748 Changes related to delegation tracing: removed delegationTrace 1749 field from ProxyCertInfo extension, created DelegationTrace 1750 extension, added and modified commentary sections related to 1751 delegation tracing. 1753 Added issuerCertHash to proxyCertInfo extension and to the path 1754 validation section. 1756 draft-ietf-pkix-proxy-02 (February 2002) 1758 Draft for Global Grid Forum 4 (Toronto) 1760 Added concept of proxy group. 1762 Updated section on keyCertSign bit to reflect draft-pkix-new- 1763 part1-07. 1765 draft-ietf-pkix-proxy-02 (March 2002) 1767 Draft for IETF. 1769 Same version number (-02) as February 2002 for GGF4 but with 1770 changes. 1772 Globally changed "Proxy Authority" to "Proxy Issuer". 1774 Changed example in Motivations section to use a reliable file 1775 transfer service. 1777 An EEC issuing a PC must have a non-empty subject name. 1779 Proxy subject names are now non-empty and contain a sequence of 1780 proxy identifiers. Changes to path validation to reflect this. 1782 subjectAltNames and issuerAltNames are now not present PCs. 1784 Renamed issuerCertHash to issuerCertSignature and similarly with 1785 it's contents. 1787 Added consideration to path validation for PC's with an infinite 1788 path length (i.e. no pCPathLenConstraint). 1790 draft-ggf-gsi-proxy-03 (July 2002) 1792 Draft for GGF-5 (Edinburgh) 1794 Renamed to draft-ggf-gsi-proxy-03 1796 Changed formatting to meet GGF document format requirements. 1798 Added GGF copyright notice to beginning. 1800 Removed Internet Draft language from status section and replaced 1801 with current text. 1803 Added Copyright and Intellectual Property sections (12 & 13) 1805 Removed Section 3.7.2: DelegationTrace Extension. Renumbered 1806 subsections 3.7.1.x to 3.7.x. Removed subsections in Section 6 1807 related to this extension and replaced with one subsection 1808 discussing it. 1810 Proxy Certificate subject name is now issuer name concatenated 1811 with a single unique component. Functional changes to Sections 3 1812 and 4 to reflect this, numerous changes throughout the document 1813 including removal of section 6.3. 1815 Removed text stating the Proxy subject name should only be used 1816 for path validation to leave door open for use with attribute 1817 certificates. 1819 Rewrote 2.6 so reflect that PCs now have unique identities. 1821 Added new section 2.5 (Motivation for Unique Proxy Name) 1823 Removed sections 2.7 (Proxy Issuer, not Certificate Authority) 1824 and 2.8 (Names versus Subjects) 1826 Renamed proxyRestrictions to proxyPolicy and made it a required 1827 field. Numerous changes elsewhere to reflect this change. 1829 Removed issuerCertSignature since it is no longer needed since 1830 PCs now have unique names. 1832 Added previously deleted (accidentally?) text in 6.1 1833 (keyCertSign Bit commentary). 1835 Cleaned up pCPathLenConstraint checking in section 4 by adding 1836 the max_pc_path_length variable. 1838 Removed the proxyGroup field to make document restriction policy 1839 agnostic. 1841 Added structure to Section 7 (Security Considerations) and added 1842 some text about a relying party trusting all issuers in a PC 1843 chain. 1845 Removed sections 6.1 and 6.2 from commentary since the PKIX 1846 draft is now an RFC and won't be changed. 1848 Moved text from 6.3 to 3.9.4 and removed section 6.3. 1850 Moved 6.4 to end of Commentary section. 1852 Moved section 5 (Relationship to attribute certificate to be 1853 first section of commentary). 1854 Changed intro to commentary and added text to beginning of 1855 section 2 to indicate that these two sections are non-normative. 1857 Changed text in 2.7 to indicate ease of integration with 1858 existing authorization systems is true only in the case of 1859 impersonation PCs. 1861 Added text to new section 5.1.4 to indicate that binding ACs to 1862 PCs indicates a trust of the PI. 1864 Removed the pC bit - any certificate with a proxyCertInfo 1865 extensions is now a PC. 1867 draft-ggf-gsi-proxy-04 (August 2002) 1869 Minor non-normative editorial corrections. 1871 draft-ietf-pkix-proxy-03 (October 2002) 1873 Name change for attempted inclusion as a PKIX WG document. Based 1874 on draft-ggf-gsi-proxy-04 with changes listed below. 1875 Changed reference from "draft update to RFC 2459" to RFC 3280. 1877 draft-ietf-pkix-proxy-04 (February 2003) 1879 Rewrote section 4, Path Validation, to be additions to RFC 3280 1880 path validation instead of changes. 1882 Added Appendix A with ASN.1 module. 1884 Added oids for Impersonation and Independent policy languages to 1885 section 3.9.3. 1887 In section 3.6: keyusage extension in a proxy certificate only 1888 has to be marked critical if marked critical in the issuer's 1889 certificate. Previously it always had to be marked critical. 1891 draft-ietf-pkix-proxy-05 (April 2003) 1892 Removed version field from ProxyCertInfo extension 1894 Restrictions on contents of key usage and extended key usage 1895 removed and placed as burden to relying party(4.2 and 3.6). 1897 Path validation (4.1.3) now outputs proxy_policy_list as a list 1898 of tuples containing subject name, policy oid, policy field, key 1899 usage extension and extended key usage extension 1901 Number of fixes to ASN module from Jim Schaad. 1903 Changes policy language OID name from "id-ppl-impersonation" to 1904 "id-ppl-inheritall". 1906 Fixed discrepancy between ASN.1 module and 3.9.2: id-ppl- 1907 independent and id-ppl-inheritall now refer to the whole OID. 1909 Clarified that a proxy issuer must have digitalSignature 1910 asserted if its certificate includes the keyUsage extension. 1912 Accepted text from David Chadwick globally getting rid of the 1913 term "impersonation" and replacing with "proxying". 1915 Reformatted document to be less indented and be more in line 1916 with other IDs. 1918 Numerous clarifications to draft based on Jim Schaad's comments. 1919 Effected sections: 3, 3.1, 3.4, 3.7, 3.9.3, 4, 5.4.1 1921 Expanded PKI acronym in abstract and section 2. 1923 Shorten title of section 4.2 to allow it to fit in table of 1924 contents. 1926 draft-ietf-pkix-proxy-06 (May 2003) 1928 Renamed "id-ppl-inheritall" to "id-ppl-inheritAll" (capitalizing 1929 the "a") for consistency. 1931 In section 4, renamed "acceptable-pc-policy-set" to "acceptable- 1932 pc-policy-language-set" for clarity. 1934 In section 4, renamed "any-policy" to "id-ppl-anyLanguage" for 1935 clarity. 1937 Added an OID for id-ppl-anyLanguage to Appendix A. 1939 Clarified text in 4.1.3 (c). 1941 Clarified Proxy Issuer definition in 2.1. 1943 Changed "MUST not be present" to "MUST be absent" second to last 1944 paragraph of section 3.8. 1946 Removed OID definitions from 3.8.2 and added pointer to Appendix 1947 A. 1949 draft-ietf-pkix-proxy-07 (July 2003) 1951 Non-normative change: Split references into normative and 1952 informative. 1954 Non-normative change: Moved change log to appendix B. 1956 Non-normative change: Reduced author count to 5. Added 1957 significant contributors list to acknowledgments. 1959 draft-ietf-pkix-proxy-08 (August 2003) 1961 Correction to 4.1.3: Failure of step(d) also causes process 1962 termination. 1964 Deleted following sentence from 3.8.2 since it no longer 1965 pertains: "Note that this verification MUST take place 1966 regardless of whether or not the PC itself contains a policy, as 1967 other PCs in the signing chain MAY contain conditions that MUST 1968 be verified." 1970 Clarification in 3.8.2: "interpret the policy" to "interpret the 1971 proxy policy" 1973 Clarified text in 3.8.1 regarding EECs. 1975 draft-ietf-pkix-proxy-09 (November 2003) 1976 Corrected object identifier for proxy cert extension in 3.8 1978 Improved phrasing of conditions 2 and 3 in 3.8.2 1980 Improved phrasing of (e) in 4 to make clear that any proxy 1981 certificate can limit length of path. 1983 Minor editorial changes in 4.1.1, 4.2, 5.1.3, 6.1 1985 Added reference to RFC 3280 in 4.1.3 step (d). 1987 draft-ietf-pkix-proxy-10 (December 2003) 1989 Minor corrections in 3.8.2, 4.1.5, and non-normative references. 1991 Marked Appendix B as "To be removed before publication" 1993 Updated contact information and institution for Von Welch. 1995 Added Section 7, IANA Considerations, and non-normative 1996 reference to RFC 2434. 1998 Section 3.8.1: Correction "If the proxyCertInfo extension is not 1999 present..." changed to "If the pCPathLenConstraint field is not 2000 present..." 2002 Section 3.8.2: Added encouragement for authors to publicly 2003 specific and list their policy languages with IANA. 2005 Added sections 6.4 and 6.5 to Security Considerations.