1 2 3 4 5 6 7Network Working Group S. Tuecke 8Request for Comments: 3820 ANL 9Category: Standards Track V. Welch 10 NCSA 11 D. Engert 12 ANL 13 L. Pearlman 14 USC/ISI 15 M. Thompson 16 LBNL 17 June 2004 18 19 20 Internet X.509 Public Key Infrastructure (PKI) 21 Proxy Certificate Profile 22 23Status of this Memo 24 25 This document specifies an Internet standards track protocol for the 26 Internet community, and requests discussion and suggestions for 27 improvements. Please refer to the current edition of the "Internet 28 Official Protocol Standards" (STD 1) for the standardization state 29 and status of this protocol. Distribution of this memo is unlimited. 30 31Copyright Notice 32 33 Copyright (C) The Internet Society (2004). 34 35Abstract 36 37 This document forms a certificate profile for Proxy Certificates, 38 based on X.509 Public Key Infrastructure (PKI) certificates as 39 defined in RFC 3280, for use in the Internet. The term Proxy 40 Certificate is used to describe a certificate that is derived from, 41 and signed by, a normal X.509 Public Key End Entity Certificate or by 42 another Proxy Certificate for the purpose of providing restricted 43 proxying and delegation within a PKI based authentication system. 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Tuecke, et al. Standards Track [Page 1] 59 60RFC 3820 X.509 Proxy Certificate Profile June 2004 61 62 63Table of Contents 64 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5 70 2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7 71 2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8 72 2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9 73 2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10 74 3. Certificate and Certificate Extensions Profile . . . . . . . . 12 75 3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12 77 3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13 80 3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13 81 3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14 82 3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14 83 4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17 84 4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19 85 4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23 86 5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 5.1. Relationship to Attribute Certificates . . . . . . . . . 24 88 5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28 89 5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28 90 5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29 91 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30 92 6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30 93 6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31 94 6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31 95 6.4. Protecting Against Denial of Service with Key Generation 32 96 6.5. Use of Proxy Certificates in a Central Repository. . . . 32 97 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 100 8.2. Informative References . . . . . . . . . . . . . . . . . 33 101 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34 102 Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 104 Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37 105 106 107 108 109 110 111 112 113 114Tuecke, et al. Standards Track [Page 2] 115 116RFC 3820 X.509 Proxy Certificate Profile June 2004 117 118 1191. Introduction 120 121 Use of a proxy credential [i7] is a common technique used in security 122 systems to allow entity A to grant to another entity B the right for 123 B to be authorized with others as if it were A. In other words, 124 entity B is acting as a proxy on behalf of entity A. This document 125 forms a certificate profile for Proxy Certificates, based on the RFC 126 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL 127 Profile" [n2]. 128 129 In addition to simple, unrestricted proxying, this profile defines: 130 131 * A framework for carrying policies in Proxy Certificates that 132 allows proxying to be limited (perhaps completely disallowed) 133 through either restrictions or enumeration of rights. 134 135 * Proxy Certificates with unique names, derived from the name of the 136 end entity certificate name. This allows the Proxy Certificates 137 to be used in conjunction with attribute assertion approaches such 138 as Attribute Certificates [i3] and have their own rights 139 independent of their issuer. 140 141 Section 2 provides a non-normative overview of the approach. It 142 begins by defining terminology, motivating Proxy Certificates, and 143 giving a brief overview of the approach. It then introduces the 144 notion of a Proxy Issuer, as distinct from a Certificate Authority, 145 to describe how end entity signing of a Proxy Certificate is 146 different from end entity signing of another end entity certificate, 147 and therefore why this approach does not violate the end entity 148 signing restrictions contained in the X.509 keyCertSign field of the 149 keyUsage extension. It then continues with discussions of how 150 subject names are used by this proxying approach, and features of 151 this approach. 152 153 Section 3 defines requirements on information content in Proxy 154 Certificates. This profile addresses two fields in the basic 155 certificate as well as five certificate extensions. The certificate 156 fields are the subject and issuer fields. The certificate extensions 157 are subject alternative name, issuer alternative name, key usage, 158 basic constraints, and extended key usage. A new certificate 159 extension, Proxy Certificate Information, is introduced. 160 161 Section 4 defines path validation rules for Proxy Certificates. 162 163 Section 5 provides non-normative commentary on Proxy Certificates. 164 165 Section 6 discusses security considerations relating to Proxy 166 Certificates. 167 168 169 170Tuecke, et al. Standards Track [Page 3] 171 172RFC 3820 X.509 Proxy Certificate Profile June 2004 173 174 175 References, listed in Section 8, are sorted into normative and 176 information references. Normative references, listed in Section 8.1, 177 are in the form [nXX]. Informative references, listed in Section 178 8.2, are in the form [iXX]. 179 180 Section 9 contains acknowledgements. 181 182 Following Section 9, contains the Appendix, the contact information 183 for the authors, the intellectual property information, and the 184 copyright information for this document. 185 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in BCP 14, RFC 2119 [n1]. 189 1902. Overview of Approach 191 192 This section provides non-normative commentary on Proxy Certificates. 193 194 The goal of this specification is to develop a X.509 Proxy 195 Certificate profile and to facilitate their use within Internet 196 applications for those communities wishing to make use of restricted 197 proxying and delegation within an X.509 Public Key Infrastructure 198 (PKI) authentication based system. 199 200 This section provides relevant background, motivation, an overview of 201 the approach, and related work. 202 2032.1. Terminology 204 205 This document uses the following terms: 206 207 * CA: A "Certification Authority", as defined by X.509 [n2] 208 209 * EEC: An "End Entity Certificate", as defined by X.509. That is, 210 it is an X.509 Public Key Certificate issued to an end entity, 211 such as a user or a service, by a CA. 212 213 * PKC: An end entity "Public Key Certificate". This is synonymous 214 with an EEC. 215 216 * PC: A "Proxy Certificate", the profile of which is defined by this 217 document. 218 219 220 221 222 223 224 225 226Tuecke, et al. Standards Track [Page 4] 227 228RFC 3820 X.509 Proxy Certificate Profile June 2004 229 230 231 * PI: A "Proxy Issuer" is an entity with an End Entity Certificate 232 or Proxy Certificate that issues a Proxy Certificate. The Proxy 233 Certificate is signed using the private key associated with the 234 public key in the Proxy Issuer's certificate. 235 236 * AC: An "Attribute Certificate", as defined by "An Internet 237 Attribute Certificate Profile for Authorization" [i3]. 238 239 * AA: An "Attribute Authority", as defined in [i3]. 240 2412.2. Background 242 243 Computational and Data "Grids" have emerged as a common approach to 244 constructing dynamic, inter-domain, distributed computing 245 environments. As explained in [i5], large research and development 246 efforts starting around 1995 have focused on the question of what 247 protocols, services, and APIs are required for effective, coordinated 248 use of resources in these Grid environments. 249 250 In 1997, the Globus Project (www.globus.org) introduced the Grid 251 Security Infrastructure (GSI) [i4]. This library provides for public 252 key based authentication and message protection, based on standard 253 X.509 certificates and public key infrastructure, the SSL/TLS 254 protocol [i2], and delegation using proxy certificates similar to 255 those profiled in this document. GSI has been used, in turn, to 256 build numerous middleware libraries and applications, which have been 257 deployed in large-scale production and experimental Grids [i1]. GSI 258 has emerged as the dominant security solution used by Grid efforts 259 worldwide. 260 261 This experience with GSI has proven the viability of restricted 262 proxying as a basis for authorization within Grids, and has further 263 proven the viability of using X.509 Proxy Certificates, as defined in 264 this document, as the basis for that proxying. This document is one 265 part of an effort to migrate this experience with GSI into standards, 266 and in the process clean up the approach and better reconcile it with 267 existing and recent standards. 268 2692.3. Motivation for Proxying 270 271 A motivating example will assist in understanding the role proxying 272 can play in building Internet based applications. 273 274 Steve is an engineer who wants to use a reliable file transfer 275 service to manage the movement of a number of large files around 276 between various hosts on his company's Intranet-based Grid. From his 277 laptop he wants to submit a number of transfer requests to the 278 service and have the files transferred while he is doing other 279 280 281 282Tuecke, et al. Standards Track [Page 5] 283 284RFC 3820 X.509 Proxy Certificate Profile June 2004 285 286 287 things, including being offline. The transfer service may queue the 288 requests for some time (e.g., until after hours or a period of low 289 resource usage) before initiating the transfers. The transfer 290 service will then, for each file, connect to each of the source and 291 destination hosts, and instruct them to initiate a data connection 292 directly from the source to the destination in order to transfer the 293 file. Steve will leave an agent running on his laptop that will 294 periodically check on progress of the transfer by contacting the 295 transfer service. Of course, he wants all of this to happen securely 296 on his company's resources, which requires that he initiate all of 297 this using his PKI smartcard. 298 299 This scenario requires authentication and delegation in a variety of 300 places: 301 302 * Steve needs to be able to mutually authenticate with the reliable 303 file transfer service to submit the transfer request. 304 305 * Since the storage hosts know nothing about the file transfer 306 service, the file transfer service needs to be delegated the 307 rights to mutually authenticate with the various storage hosts 308 involved directly in the file transfer, in order to initiate the 309 file transfer. 310 311 * The source and destination hosts of a particular transfer must be 312 able to mutual authenticate with each other, to ensure the file is 313 being transferred to and from the proper parties. 314 315 * The agent running on Steve's laptop must mutually authenticate 316 with the file transfer service in order to check the result of the 317 transfers. 318 319 Proxying is a viable approach to solving two (related) problems in 320 this scenario: 321 322 * Single sign-on: Steve wants to enter his smartcard password (or 323 pin) once, and then run a program that will submit all the file 324 transfer requests to the transfer service, and then periodically 325 check on the status of the transfer. This program needs to be 326 given the rights to be able to perform all of these operations 327 securely, without requiring repeated access to the smartcard or 328 Steve's password. 329 330 * Delegation: Various remote processes in this scenario need to 331 perform secure operations on Steve's behalf, and therefore must be 332 delegated the necessary rights. For example, the file transfer 333 334 335 336 337 338Tuecke, et al. Standards Track [Page 6] 339 340RFC 3820 X.509 Proxy Certificate Profile June 2004 341 342 343 service needs to be able to authenticate on Steve's behalf with 344 the source and destination hosts, and must in turn delegate rights 345 to those hosts so that they can authenticate with each other. 346 347 Proxying can be used to secure all of these interactions: 348 349 * Proxying allows for the private key stored on the smartcard to be 350 accessed just once, in order to create the necessary proxy 351 credential, which allows the client/agent program to be authorized 352 as Steve when submitting the requests to the transfer service. 353 Access to the smartcard and Steve's password is not required after 354 the initial creation of the proxy credential. 355 356 * The client program on the laptop can delegate to the file transfer 357 service the right to act on Steve's behalf. This, in turn, allows 358 the service to authenticate to the storage hosts and inherit 359 Steve's privileges in order to start the file transfers. 360 361 * When the transfer service authenticates to hosts to start the file 362 transfer, the service can delegate to the hosts the right to act 363 on Steve's behalf so that each pair of hosts involved in a file 364 transfer can mutually authenticate to ensure the file is securely 365 transferred. 366 367 * When the agent on the laptop reconnects to the file transfer 368 service to check on the status of the transfer, it can perform 369 mutual authentication. The laptop may use a newly generated proxy 370 credential, which is just created anew using the smartcard. 371 372 This scenario, and others similar to it, is being built today within 373 the Grid community. The Grid Security Infrastructure's single sign- 374 on and delegation capabilities, built on X.509 Proxy Certificates, 375 are being employed to provide authentication services to these 376 applications. 377 3782.4. Motivation for Restricted Proxies 379 380 One concern that arises is what happens if a machine that has been 381 delegated the right to inherit Steve's privileges has been 382 compromised? For example, in the above scenario, what if the machine 383 running the file transfer service is compromised, such that the 384 attacker can gain access to the credential that Steve delegated to 385 that service? Can the attacker now do everything that Steve is 386 allowed to do? 387 388 A solution to this problem is to allow for restrictions to be placed 389 on the proxy by means of policies on the proxy certificates. For 390 example, the machine running the reliable file transfer service in 391 392 393 394Tuecke, et al. Standards Track [Page 7] 395 396RFC 3820 X.509 Proxy Certificate Profile June 2004 397 398 399 the above example might only be given Steve's right for the purpose 400 of reading the source files and writing the destination files. 401 Therefore, if that file transfer service is compromised, the attacker 402 cannot modify source files, cannot create or modify other files to 403 which Steve has access, cannot start jobs on behalf of Steve, etc. 404 All that an attacker would be able to do is read the specific files 405 to which the file transfer service has been delegated read access, 406 and write bogus files in place of those that the file transfer 407 service has been delegated write access. Further, by limiting the 408 lifetime of the credential that is delegated to the file transfer 409 service, the effects of a compromise can be further mitigated. 410 411 Other potential uses for restricted proxy credentials are discussed 412 in [i7]. 413 4142.5. Motivation for Unique Proxy Name 415 416 The dynamic creation of entities (e.g., processes and services) is an 417 essential part of Grid computing. These entities will require rights 418 in order to securely perform their function. While it is possible to 419 obtain rights solely through proxying as described in previous 420 sections, this has limitations. For example what if an entity should 421 have rights that are granted not just from the proxy issuer but from 422 a third party as well? While it is possible in this case for the 423 entity to obtain and hold two proxy certifications, in practice it is 424 simpler for subsequent credentials to take the form of attribute 425 certificates. 426 427 It is also desirable for these entities to have a unique identity so 428 that they can be explicitly discussed in policy statements. For 429 example, a user initiating a third-party FTP transfer could grant 430 each FTP server a PC with a unique identity and inform each server of 431 the identity of the other, then when the two servers connected they 432 could authenticate themselves and know they are connected to the 433 proper party. 434 435 In order for a party to have rights of it's own it requires a unique 436 identity. Possible options for obtaining an unique identity are: 437 438 1) Obtain an identity from a traditional Certification Authority 439 (CA). 440 441 2) Obtain a new identity independently - for example by using the 442 generated public key and a self-signed certificate. 443 444 3) Derive the new identity from an existing identity. 445 446 447 448 449 450Tuecke, et al. Standards Track [Page 8] 451 452RFC 3820 X.509 Proxy Certificate Profile June 2004 453 454 455 In this document we describe an approach to option #3, because: 456 457 * It is reasonably light-weight, as it can be done without 458 interacting with a third party. This is important when 459 creating identities dynamically. 460 461 * As described in the previous section, a common use for PCs is 462 for restricted proxying, so deriving their identity from the 463 identity of the EEC makes this straightforward. Nonetheless 464 there are circumstances where the creator does not wish to 465 delegate all or any of its rights to a new entity. Since the 466 name is unique, this is easily accomplished by #3 as well, by 467 allowing the application of a policy to limit proxying. 468 4692.6. Description Of Approach 470 471 This document defines an X.509 "Proxy Certificate" or "PC" as a means 472 of providing for restricted proxying within an (extended) X.509 PKI 473 based authentication system. 474 475 A Proxy Certificate is an X.509 public key certificate with the 476 following properties: 477 478 1) It is signed by either an X.509 End Entity Certificate (EEC), or 479 by another PC. This EEC or PC is referred to as the Proxy Issuer 480 (PI). 481 482 2) It can sign only another PC. It cannot sign an EEC. 483 484 3) It has its own public and private key pair, distinct from any 485 other EEC or PC. 486 487 4) It has an identity derived from the identity of the EEC that 488 signed the PC. When a PC is used for authentication, in may 489 inherit rights of the EEC that signed the PC, subject to the 490 restrictions that are placed on that PC by the EEC. 491 492 5) Although its identity is derived from the EEC's identity, it is 493 also unique. This allows this identity to be used for 494 authorization as an independent identity from the identity of the 495 issuing EEC, for example in conjunction with attribute assertions 496 as defined in [i3]. 497 498 6) It contains a new X.509 extension to identify it as a PC and to 499 place policies on the use of the PC. This new extension, along 500 with other X.509 fields and extensions, are used to enable proper 501 path validation and use of the PC. 502 503 504 505 506Tuecke, et al. Standards Track [Page 9] 507 508RFC 3820 X.509 Proxy Certificate Profile June 2004 509 510 511 The process of creating a PC is as follows: 512 513 1) A new public and private key pair is generated. 514 515 2) That key pair is used to create a request for a Proxy Certificate 516 that conforms to the profile described in this document. 517 518 3) A Proxy Certificate, signed by the private key of the EEC or by 519 another PC, is created in response to the request. During this 520 process, the PC request is verified to ensure that the requested 521 PC is valid (e.g., it is not an EEC, the PC fields are 522 appropriately set, etc). 523 524 When a PC is created as part of a delegation from entity A to entity 525 B, this process is modified by performing steps #1 and #2 within 526 entity B, then passing the PC request from entity B to entity A over 527 an authenticated, integrity checked channel, then entity A performs 528 step #3 and passes the PC back to entity B. 529 530 Path validation of a PC is very similar to normal path validation, 531 with a few additional checks to ensure, for example, proper PC 532 signing constraints. 533 5342.7. Features Of This Approach 535 536 Using Proxy Certificates to perform delegation has several features 537 that make it attractive: 538 539 * Ease of integration 540 541 o Because a PC requires only a minimal change to path validation, 542 it is very easy to incorporate support for Proxy Certificates 543 into existing X.509 based software. For example, SSL/TLS 544 requires no protocol changes to support authentication using a 545 PC. Further, an SSL/TLS implementation requires only minor 546 changes to support PC path validation, and to retrieve the 547 authenticated subject of the signing EEC instead of the subject 548 of the PC for authorization purposes. 549 550 o Many existing authorization systems use the X.509 subject name 551 as the basis for access control. Proxy Certificates can be 552 used with such authorization systems without modification, 553 since such a PC inherits its name and rights from the EEC that 554 signed it and the EEC name can be used in place of the PC name 555 for authorization decisions. 556 557 558 559 560 561 562Tuecke, et al. Standards Track [Page 10] 563 564RFC 3820 X.509 Proxy Certificate Profile June 2004 565 566 567 * Ease of use 568 569 o Using PC for single sign-on helps make X.509 PKI authentication 570 easier to use, by allowing users to "login" once and then 571 perform various operations securely. 572 573 o For many users, properly managing their own EEC private key is 574 a nuisance at best, and a security risk at worst. One option 575 easily enabled with a PC is to manage the EEC private keys and 576 certificates in a centrally managed repository. When a user 577 needs a PKI credential, the user can login to the repository 578 using name/password, one time password, etc. Then the 579 repository can delegate a PC to the user with proxy rights, but 580 continue to protect the EEC private key in the repository. 581 582 * Protection of private keys 583 584 o By using the remote delegation approach outlined above, entity 585 A can delegate a PC to entity B, without entity B ever seeing 586 the private key of entity A, and without entity A ever seeing 587 the private key of the newly delegated PC held by entity B. In 588 other words, private keys never need to be shared or 589 communicated by the entities participating in a delegation of a 590 PC. 591 592 o When implementing single sign-on, using a PC helps protect the 593 private key of the EEC, because it minimizes the exposure and 594 use of that private key. For example, when an EEC private key 595 is password protected on disk, the password and unencrypted 596 private key need only be available during the creation of the 597 PC. That PC can then be used for the remainder of its valid 598 lifetime, without requiring access to the EEC password or 599 private key. Similarly, when the EEC private key lives on a 600 smartcard, the smartcard need only be present in the machine 601 during the creation of the PC. 602 603 * Limiting consequences of a compromised key 604 605 o When creating a PC, the PI can limit the validity period of the 606 PC, the depth of the PC path that can be created by that PC, 607 and key usage of the PC and its descendents. Further, fine- 608 grained policies can be carried by a PC to even further 609 restrict the operations that can be performed using the PC. 610 These restrictions permit the PI to limit damage that could be 611 done by the bearer of the PC, either accidentally or 612 maliciously. 613 614 615 616 617 618Tuecke, et al. Standards Track [Page 11] 619 620RFC 3820 X.509 Proxy Certificate Profile June 2004 621 622 623 o A compromised PC private key does NOT compromise the EEC 624 private key. This makes a short term, or an otherwise 625 restricted PC attractive for day-to-day use, since a 626 compromised PC does not require the user to go through the 627 usually cumbersome and time consuming process of having the EEC 628 with a new private key reissued by the CA. 629 630 See Section 5 below for more discussion on how Proxy Certificates 631 relate to Attribute Certificates. 632 6333. Certificate and Certificate Extensions Profile 634 635 This section defines the usage of X.509 certificate fields and 636 extensions in Proxy Certificates, and defines one new extension for 637 Proxy Certificate Information. 638 639 All Proxy Certificates MUST include the Proxy Certificate Information 640 (ProxyCertInfo) extension defined in this section and the extension 641 MUST be critical. 642 6433.1. Issuer 644 645 The Proxy Issuer of a Proxy Certificate MUST be either an End Entity 646 Certificate, or another Proxy Certificate. 647 648 The Proxy Issuer MUST NOT have an empty subject field. 649 650 The issuer field of a Proxy Certificate MUST contain the subject 651 field of its Proxy Issuer. 652 653 If the Proxy Issuer certificate has the KeyUsage extension, the 654 Digital Signature bit MUST be asserted. 655 6563.2. Issuer Alternative Name 657 658 The issuerAltName extension MUST NOT be present in a Proxy 659 Certificate. 660 6613.3. Serial Number 662 663 The serial number of a Proxy Certificate (PC) SHOULD be unique 664 amongst all Proxy Certificates issued by a particular Proxy Issuer. 665 However, a Proxy Issuer MAY use an approach to assigning serial 666 numbers that merely ensures a high probability of uniqueness. 667 668 669 670 671 672 673 674Tuecke, et al. Standards Track [Page 12] 675 676RFC 3820 X.509 Proxy Certificate Profile June 2004 677 678 679 For example, a Proxy Issuer MAY use a sequentially assigned integer 680 or a UUID to assign a unique serial number to a PC it issues. Or a 681 Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a 682 serial number with a high probability of uniqueness. 683 6843.4. Subject 685 686 The subject field of a Proxy Certificate MUST be the issuer field 687 (that is the subject of the Proxy Issuer) appended with a single 688 Common Name component. 689 690 The value of the Common Name SHOULD be unique to each Proxy 691 Certificate bearer amongst all Proxy Certificates with the same 692 issuer. 693 694 If a Proxy Issuer issues two proxy certificates to the same bearer, 695 the Proxy Issuer MAY choose to use the same Common Name for both. 696 Examples of this include Proxy Certificates for different uses (e.g., 697 signing vs encryption) or the re-issuance of an expired Proxy 698 Certificate. 699 700 The Proxy Issuer MAY use an approach to assigning Common Name values 701 that merely ensures a high probability of uniqueness. This value MAY 702 be the same value used for the serial number. 703 704 The result of this approach is that all subject names of Proxy 705 Certificates are derived from the name of the issuing EEC (it will be 706 the first part of the subject name appended with one or more CN 707 components) and are unique to each bearer. 708 7093.5. Subject Alternative Name 710 711 The subjectAltName extension MUST NOT be present in a Proxy 712 Certificate. 713 7143.6. Key Usage and Extended Key Usage 715 716 If the Proxy Issuer certificate has a Key Usage extension, the 717 Digital Signature bit MUST be asserted. 718 719 This document places no constraints on the presence or contents of 720 the key usage and extended key usage extension. However, section 4.2 721 explains what functions should be allowed a proxy certificate by a 722 relying party. 723 724 725 726 727 728 729 730Tuecke, et al. Standards Track [Page 13] 731 732RFC 3820 X.509 Proxy Certificate Profile June 2004 733 734 7353.7. Basic Constraints 736 737 The cA field in the basic constraints extension MUST NOT be TRUE. 738 7393.8. The ProxyCertInfo Extension 740 741 A new extension, ProxyCertInfo, is defined in this subsection. 742 Presence of the ProxyCertInfo extension indicates that a certificate 743 is a Proxy Certificate and whether or not the issuer of the 744 certificate has placed any restrictions on its use. 745 746 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 747 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 748 749 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 750 751 id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } 752 753 ProxyCertInfo ::= SEQUENCE { 754 pCPathLenConstraint INTEGER (0..MAX) OPTIONAL, 755 proxyPolicy ProxyPolicy } 756 757 758 ProxyPolicy ::= SEQUENCE { 759 policyLanguage OBJECT IDENTIFIER, 760 policy OCTET STRING OPTIONAL } 761 762 If a certificate is a Proxy Certificate, then the proxyCertInfo 763 extension MUST be present, and this extension MUST be marked as 764 critical. 765 766 If a certificate is not a Proxy Certificate, then the proxyCertInfo 767 extension MUST be absent. 768 769 The ProxyCertInfo extension consists of one required and two optional 770 fields, which are described in detail in the following subsections. 771 7723.8.1. pCPathLenConstraint 773 774 The pCPathLenConstraint field, if present, specifies the maximum 775 depth of the path of Proxy Certificates that can be signed by this 776 Proxy Certificate. A pCPathLenConstraint of 0 means that this 777 certificate MUST NOT be used to sign a Proxy Certificate. If the 778 pCPathLenConstraint field is not present then the maximum proxy path 779 length is unlimited. End entity certificates have unlimited maximum 780 proxy path lengths. 781 782 783 784 785 786Tuecke, et al. Standards Track [Page 14] 787 788RFC 3820 X.509 Proxy Certificate Profile June 2004 789 790 7913.8.2. proxyPolicy 792 793 The proxyPolicy field specifies a policy on the use of this 794 certificate for the purposes of authorization. Within the 795 proxyPolicy, the policy field is an expression of policy, and the 796 policyLanguage field indicates the language in which the policy is 797 expressed. 798 799 The proxyPolicy field in the proxyCertInfo extension does not define 800 a policy language to be used for proxy restrictions; rather, it 801 places the burden on those parties using that extension to define an 802 appropriate language, and to acquire an OID for that language (or to 803 select an appropriate previously-defined language/OID). Because it 804 is essential for the PI that issues a certificate with a proxyPolicy 805 field and the relying party that interprets that field to agree on 806 its meaning, the policy language OID must correspond to a policy 807 language (including semantics), not just a policy grammar. 808 809 The policyLanguage field has two values of special importance, 810 defined in Appendix A, that MUST be understood by all parties 811 accepting Proxy Certificates: 812 813 * id-ppl-inheritAll indicates that this is an unrestricted proxy 814 that inherits all rights from the issuing PI. An unrestricted 815 proxy is a statement that the Proxy Issuer wishes to delegate all 816 of its authority to the bearer (i.e., to anyone who has that proxy 817 certificate and can prove possession of the associated private 818 key). For purposes of authorization, this an unrestricted proxy 819 effectively impersonates the issuing PI. 820 821 * id-ppl-independent indicates that this is an independent proxy 822 that inherits no rights from the issuing PI. This PC MUST be 823 treated as an independent identity by relying parties. The only 824 rights this PC has are those granted explicitly to it. 825 826 For either of the policyLanguage values listed above, the policy 827 field MUST NOT be present. 828 829 Other values for the policyLanguage field indicates that this is a 830 restricted proxy certification and have some other policy limiting 831 its ability to do proxying. In this case the policy field MAY be 832 present and it MUST contain information expressing the policy. If 833 the policy field is not present the policy MUST be implicit in the 834 value of the policyLanguage field itself. Authors of additional 835 policy languages are encouraged to publicly document their policy 836 language and list it in the IANA registry (see Section 7). 837 838 839 840 841 842Tuecke, et al. Standards Track [Page 15] 843 844RFC 3820 X.509 Proxy Certificate Profile June 2004 845 846 847 Proxy policies are used to limit the amount of authority delegated, 848 for example to assert that the proxy certificate may be used only to 849 make requests to a specific server, or only to authorize specific 850 operations on specific resources. This document is agnostic to the 851 policies that can be placed in the policy field. 852 853 Proxy policies impose additional requirements on the relying party, 854 because only the relying party is in a position to ensure that those 855 policies are enforced. When making an authorization decision based 856 on a proxy certificate based on rights that proxy certificate 857 inherited from its issuer, it is the relying party's responsibility 858 to verify that the requested authority is compatible with all 859 policies in the PC's certificate path. In other words, the relying 860 party MUST verify that the following three conditions are all met: 861 862 1) The relying party MUST know how to interpret the proxy policy and 863 the request is allowed under that policy. 864 865 2) If the Proxy Issuer is an EEC then the relying party's local 866 policies MUST authorize the request for the entity named in the 867 EEC. 868 869 3) If the Proxy Issuer is another PC, then one of the following MUST 870 be true: 871 872 a. The relying party's local policies authorize the Proxy Issuer 873 to perform the request. 874 875 b. The Proxy Issuer inherits the right to perform the request from 876 its issuer by means of its proxy policy. This must be verified 877 by verifying these three conditions on the Proxy Issuer in a 878 recursive manner. 879 880 If these conditions are not met, the relying party MUST either deny 881 authorization, or ignore the PC and the whole certificate chain 882 including the EEC entirely when making its authorization decision 883 (i.e., make the same decision that it would have made had the PC and 884 it's certificate chain never been presented). 885 886 The relying party MAY impose additional restrictions as to which 887 proxy certificates it accepts. For example, a relying party MAY 888 choose to reject all proxy certificates, or MAY choose to accept 889 proxy certificates only for certain operations, etc. 890 891 Note that since a proxy certificate has a unique identity it MAY also 892 have rights granted to it by means other than inheritance from it's 893 issuer via its proxy policy. The rights granted to the bearer of a 894 PC are the union of the rights granted to the PC identity and the 895 896 897 898Tuecke, et al. Standards Track [Page 16] 899 900RFC 3820 X.509 Proxy Certificate Profile June 2004 901 902 903 inherited rights. The inherited rights consist of the intersection 904 of the rights granted to the PI identity intersected with the proxy 905 policy in the PC. 906 907 For example, imagine that Steve is authorized to read and write files 908 A and B on a file server, and that he uses his EEC to create a PC 909 that includes the policy that it can be used only to read or write 910 files A and C. Then a trusted attribute authority grants an 911 Attribute Certificate granting the PC the right to read file D. This 912 would make the rights of the PC equal to the union of the rights 913 granted to the PC identity (right to read file D) with the 914 intersection of the rights granted to Steve, the PI, (right to read 915 files A and B) with the policy in the PC (can only read files A and 916 C). This would mean the PC would have the following rights: 917 918 * Right to read file A: Steve has this right and he issued the PC 919 and his policy grants this right to the PC. 920 921 * Right to read file D: This right is granted explicitly to the PC 922 by a trusted authority. 923 924 The PC would NOT have the following rights: 925 926 * Right to read file B: Although Steve has this right, it is 927 excluded by his policy on the PC. 928 929 * Right to read file C: Although Steve's policy grants this right, 930 he does not have this right himself. 931 932 In many cases, the relying party will not have enough information to 933 evaluate the above criteria at the time that the certificate path is 934 validated. For example, if a certificate is used to authenticate a 935 connection to some server, that certificate is typically validated 936 during that authentication step, before any requests have been made 937 of the server. In that case, the relying party MUST either have some 938 authorization mechanism in place that will check the proxy policies, 939 or reject any certificate that contains proxy policies (or that has a 940 parent certificate that contains proxy policies). 941 9424. Proxy Certificate Path Validation 943 944 Proxy Certification path processing verifies the binding between the 945 proxy certificate distinguished name and proxy certificate public 946 key. The binding is limited by constraints which are specified in 947 the certificates which comprise the path and inputs which are 948 specified by the relying party. 949 950 951 952 953 954Tuecke, et al. Standards Track [Page 17] 955 956RFC 3820 X.509 Proxy Certificate Profile June 2004 957 958 959 This section describes an algorithm for validating proxy 960 certification paths. Conforming implementations of this 961 specification are not required to implement this algorithm, but MUST 962 provide functionality equivalent to the external behavior resulting 963 from this procedure. Any algorithm may be used by a particular 964 implementation so long as it derives the correct result. 965 966 The algorithm presented in this section validates the proxy 967 certificate with respect to the current date and time. A conformant 968 implementation MAY also support validation with respect to some point 969 in the past. Note that mechanisms are not available for validating a 970 proxy certificate with respect to a time outside the certificate 971 validity period. 972 973 Valid paths begin with the end entity certificate (EEC) that has 974 already been validated by public key certificate validation 975 procedures in RFC 3280 [n2]. The algorithm requires the public key 976 of the EEC and the EEC's subject distinguished name. 977 978 To meet the goal of verifying the proxy certificate, the proxy 979 certificate path validation process verifies, among other things, 980 that a prospective certification path (a sequence of n certificates) 981 satisfies the following conditions: 982 983 (a) for all x in {1, ..., n-1}, the subject of certificate x is the 984 issuer of proxy certificate x+1 and the subject distinguished 985 name of certificate x+1 is a legal subject distinguished name to 986 have been issued by certificate x; 987 988 (b) certificate 1 is valid proxy certificate issued by the end entity 989 certificate whose information is given as input to the proxy 990 certificate path validation process; 991 992 (c) certificate n is the proxy certificate to be validated; 993 994 (d) for all x in {1, ..., n}, the certificate was valid at the time 995 in question; and 996 997 (e) for all certificates in the path with a pCPathLenConstraint 998 field, the number of certificates in the path following that 999 certificate does not exceed the length specified in that field. 1000 1001 At this point there is no mechanism defined for revoking proxy 1002 certificates. 1003 1004 1005 1006 1007 1008 1009 1010Tuecke, et al. Standards Track [Page 18] 1011 1012RFC 3820 X.509 Proxy Certificate Profile June 2004 1013 1014 10154.1. Basic Proxy Certificate Path Validation 1016 1017 This section presents the algorithm in four basic steps to mirror the 1018 description of public key certificate path validation in RFC 3280: 1019 (1) initialization, (2) basic proxy certificate processing, (3) 1020 preparation for the next proxy certificate, and (4) wrap-up. Steps 1021 (1) and (4) are performed exactly once. Step (2) is performed for 1022 all proxy certificates in the path. Step (3) is performed for all 1023 proxy certificates in the path except the final proxy certificate. 1024 1025 Certificate path validation as described in RFC 3280 MUST have been 1026 done prior to using this algorithm to validate the end entity 1027 certificate. This algorithm then processes the proxy certificate 1028 chain using the end entity certificate information produced by RFC 1029 3280 path validation. 1030 10314.1.1. Inputs 1032 1033 This algorithm assumes the following inputs are provided to the path 1034 processing logic: 1035 1036 (a) information about the entity certificate already verified using 1037 RFC 3280 path validation. This information includes: 1038 1039 (1) the end entity name, 1040 1041 (2) the working_public_key output from RFC 3280 path validation, 1042 1043 (3) the working_public_key_algorithm output from RFC 3280, 1044 1045 (4) and the working_public_key_parameters output from RFC 3280 1046 path validation. 1047 1048 (b) prospective proxy certificate path of length n. 1049 1050 (c) acceptable-pc-policy-language-set: A set of proxy certificate 1051 policy languages understood by the policy evaluation code. The 1052 acceptable-pc-policy-language-set MAY contain the special value 1053 id-ppl-anyLanguage (as defined in Appendix A) if the path 1054 validation code should not check the proxy certificate policy 1055 languages (typically because the set of known policy languages is 1056 not known yet and will be checked later in the authorization 1057 process). 1058 1059 (d) the current date and time. 1060 1061 1062 1063 1064 1065 1066Tuecke, et al. Standards Track [Page 19] 1067 1068RFC 3820 X.509 Proxy Certificate Profile June 2004 1069 1070 10714.1.2. Initialization 1072 1073 This initialization phase establishes the following state variables 1074 based upon the inputs: 1075 1076 (a) working_public_key_algorithm: the digital signature algorithm 1077 used to verify the signature of a proxy certificate. The 1078 working_public_key_algorithm is initialized from the input 1079 information provided from RFC 3280 path validation. 1080 1081 (b) working_public_key: the public key used to verify the signature 1082 of a proxy certificate. The working_public_key is initialized 1083 from the input information provided from RFC 3280 path 1084 validation. 1085 1086 (c) working_public_key_parameters: parameters associated with the 1087 current public key, that may be required to verify a signature 1088 (depending upon the algorithm). The 1089 proxy_issuer_public_key_parameters variable is initialized from 1090 the input information provided from RFC 3280 path validation. 1091 1092 (d) working_issuer_name: the issuer distinguished name expected in 1093 the next proxy certificate in the chain. The working_issuer_name 1094 is initialized to the distinguished name in the end entity 1095 certificate validated by RFC 3280 path validation. 1096 1097 (e) max_path_length: this integer is initialized to n, is decremented 1098 for each proxy certificate in the path. This value may also be 1099 reduced by the pcPathLenConstraint value of any proxy certificate 1100 in the chain. 1101 1102 (f) proxy_policy_list: this list is empty to start and will be filled 1103 in with the key usage extensions, extended key usage extensions 1104 and proxy policies in the chain. 1105 1106 Upon completion of the initialization steps, perform the basic 1107 certificate processing steps specified in 4.1.3. 1108 11094.1.3. Basic Proxy Certificate Processing 1110 1111 The basic path processing actions to be performed for proxy 1112 certificate i (for all i in [1..n]) are listed below. 1113 1114 (a) Verify the basic certificate information. The certificate MUST 1115 satisfy each of the following: 1116 1117 1118 1119 1120 1121 1122Tuecke, et al. Standards Track [Page 20] 1123 1124RFC 3820 X.509 Proxy Certificate Profile June 2004 1125 1126 1127 (1) The certificate was signed with the 1128 working_public_key_algorithm using the working_public_key and 1129 the working_public_key_parameters. 1130 1131 (2) The certificate validity period includes the current time. 1132 1133 (3) The certificate issuer name is the working_issuer_name. 1134 1135 (4) The certificate subject name is the working_issuer_name with a 1136 CN component appended. 1137 1138 (b) The proxy certificate MUST have a ProxyCertInfo extension. 1139 Process the extension as follows: 1140 1141 (1) If the pCPathLenConstraint field is present in the 1142 ProxyCertInfo field and the value it contains is less than 1143 max_path_length, set max_path_length to its value. 1144 1145 (2) If acceptable-pc-policy-language-set is not id-ppl- 1146 anyLanguage, the OID in the policyLanguage field MUST be 1147 present in acceptable-pc-policy-language-set. 1148 1149 (c) The tuple containing the certificate subject name, policyPolicy, 1150 key usage extension (if present) and extended key usage extension 1151 (if present) must be appended to proxy_policy_list. 1152 1153 (d) Process other certificate extensions, as described in [n2]: 1154 1155 (1) Recognize and process any other critical extensions present in 1156 the proxy certificate. 1157 1158 (2) Process any recognized non-critical extension present in the 1159 proxy certificate. 1160 1161 If either step (a), (b) or (d) fails, the procedure terminates, 1162 returning a failure indication and an appropriate reason. 1163 1164 If i is not equal to n, continue by performing the preparatory steps 1165 listed in 4.1.4. If i is equal to n, perform the wrap-up steps 1166 listed in 4.1.5. 1167 11684.1.4. Preparation for next Proxy Certificate 1169 1170 (a) Verify max_path_length is greater than zero and decrement 1171 max_path_length. 1172 1173 (b) Assign the certificate subject name to working_issuer_name. 1174 1175 1176 1177 1178Tuecke, et al. Standards Track [Page 21] 1179 1180RFC 3820 X.509 Proxy Certificate Profile June 2004 1181 1182 1183 (c) Assign the certificate subjectPublicKey to working_public_key. 1184 1185 (d) If the subjectPublicKeyInfo field of the certificate contains an 1186 algorithm field with non-null parameters, assign the parameters 1187 to the working_public_key_parameters variable. 1188 1189 If the subjectPublicKeyInfo field of the certificate contains an 1190 algorithm field with null parameters or parameters are omitted, 1191 compare the certificate subjectPublicKey algorithm to the 1192 working_public_key_algorithm. If the certificate 1193 subjectPublicKey algorithm and the working_public_key_algorithm 1194 are different, set the working_public_key_parameters to null. 1195 1196 (e) Assign the certificate subjectPublicKey algorithm to the 1197 working_public_key_algorithm variable. 1198 1199 (f) If a key usage extension is present, verify that the 1200 digitalSignature bit is set. 1201 1202 If either check (a) or (f) fails, the procedure terminates, returning 1203 a failure indication and an appropriate reason. 1204 1205 If (a) and (f) complete successfully, increment i and perform the 1206 basic certificate processing specified in 4.1.3. 1207 12084.1.5. Wrap-up Procedures 1209 1210 (a) Assign the certificate subject name to working_issuer_name. 1211 1212 (b) Assign the certificate subjectPublicKey to working_public_key. 1213 1214 (c) If the subjectPublicKeyInfo field of the certificate contains an 1215 algorithm field with non-null parameters, assign the parameters 1216 to the proxy_issuer_public_key_parameters variable. 1217 1218 If the subjectPublicKeyInfo field of the certificate contains an 1219 algorithm field with null parameters or parameters are omitted, 1220 compare the certificate subjectPublicKey algorithm to the 1221 proxy_issuer_public_key_algorithm. If the certificate 1222 subjectPublicKey algorithm and the 1223 proxy_issuer_public_key_algorithm are different, set the 1224 proxy_issuer_public_key_parameters to null. 1225 1226 (d) Assign the certificate subjectPublicKey algorithm to the 1227 proxy_issuer_public_key_algorithm variable. 1228 1229 1230 1231 1232 1233 1234Tuecke, et al. Standards Track [Page 22] 1235 1236RFC 3820 X.509 Proxy Certificate Profile June 2004 1237 1238 12394.1.6. Outputs 1240 1241 If path processing succeeds, the procedure terminates, returning a 1242 success indication together with final value of the 1243 working_public_key, the working_public_key_algorithm, the 1244 working_public_key_parameters, and the proxy_policy_list. 1245 12464.2. Using the Path Validation Algorithm 1247 1248 Each Proxy Certificate contains a ProxyCertInfo extension, which 1249 always contains a policy language OID, and may also contain a policy 1250 OCTET STRING. These policies serve to indicate the desire of each 1251 issuer in the proxy certificate chain, starting with the EEC, to 1252 delegate some subset of their rights to the issued proxy certificate. 1253 This chain of policies is returned by the algorithm to the 1254 application. 1255 1256 The application MAY make authorization decisions based on the subject 1257 distinguished name of the proxy certificate or on one of the proxy 1258 certificates in it's issuing chain or on the EEC that serves as the 1259 root of the chain. If an application chooses to use the subject 1260 distinguished name of a proxy certificate in the issuing chain or the 1261 EEC it MUST use the returned policies to restrict the rights it 1262 grants to the proxy certificate. If the application does not know 1263 how to parse any policy in the policy chain it MUST not use, for the 1264 purposes of making authorization decisions, the subject distinguished 1265 name of any certificate in the chain prior to the certificate in 1266 which the unrecognized policy appears. 1267 1268 Application making authorization decisions based on the contents of 1269 the proxy certificate key usage or extended key usage extensions MUST 1270 examine the list of key usage, extended key usage and proxy policies 1271 resulting from proxy certificate path validation and determine the 1272 effective key usage functions of the proxy certificate as follows: 1273 1274 * If a certificate is a proxy certificate with a proxy policy of 1275 id-ppl-independent or an end entity certificate, the effective key 1276 usage functions of that certificate is as defined by the key usage 1277 and extended key usage extensions in that certificate. The key 1278 usage functionality of the issuer has no bearing on the effective 1279 key usage functionality. 1280 1281 * If a certificate is a proxy certificate with a policy other than 1282 id-ppl-independent, the effective key usage and extended key usage 1283 functionality of the proxy certificate is the intersection of the 1284 functionality of those extensions in the proxy certificate and the 1285 effective key usage functionality of the proxy issuer. 1286 1287 1288 1289 1290Tuecke, et al. Standards Track [Page 23] 1291 1292RFC 3820 X.509 Proxy Certificate Profile June 2004 1293 1294 12955. Commentary 1296 1297 This section provides non-normative commentary on Proxy Certificates. 1298 12995.1. Relationship to Attribute Certificates 1300 1301 An Attribute Certificate [i3] can be used to grant to one identity, 1302 the holder, some attribute such as a role, clearance level, or 1303 alternative identity such as "charging identity" or "audit identity". 1304 This is accomplished by way of a trusted Attribute Authority (AA), 1305 which issues signed Attribute Certificates (AC), each of which binds 1306 an identity to a particular set of attributes. Authorization 1307 decisions can then be made by combining information from the 1308 authenticated End Entity Certificate providing the identity, with the 1309 signed Attribute Certificates providing binding of that identity to 1310 attributes. 1311 1312 There is clearly some overlap between the capabilities provided by 1313 Proxy Certificates and Attribute Certificates. However, the 1314 combination of the two approaches together provides a broader 1315 spectrum of solutions to authorization in X.509 based systems, than 1316 either solution alone. This section seeks to clarify some of the 1317 overlaps, differences, and synergies between Proxy Certificate and 1318 Attribute Certificates. 1319 13205.1.1. Types of Attribute Authorities 1321 1322 For the purposes of this discussion, Attribute Authorities, and the 1323 uses of the Attribute Certificates that they produce, can be broken 1324 down into two broad classes: 1325 1326 1) End entity AA: An End Entity Certificate may be used to sign an 1327 AC. This can be used, for example, to allow an end entity to 1328 delegate some of its privileges to another entity. 1329 1330 2) Third party AA: A separate entity, aside from the end entity 1331 involved in an authenticated interaction, may sign ACs in order to 1332 bind the authenticated identity with additional attributes, such 1333 as role, group, etc. For example, when a client authenticates 1334 with a server, the third party AA may provide an AC that binds the 1335 client identity to a particular group, which the server then uses 1336 for authorization purposes. 1337 1338 This second type of Attribute Authority, the third party AA, works 1339 equally well with an EEC or a PC. For example, unrestricted Proxy 1340 Certificates can be used to delegate the EEC's identity to various 1341 other parties. Then when one of those other parties uses the PC to 1342 authenticate with a service, that service will receive the EEC's 1343 1344 1345 1346Tuecke, et al. Standards Track [Page 24] 1347 1348RFC 3820 X.509 Proxy Certificate Profile June 2004 1349 1350 1351 identity via the PC, and can apply any ACs that bind that identity to 1352 attributes in order to determine authorization rights. Additionally 1353 PC with policies could be used to selectively deny the binding of ACs 1354 to a particular proxy. An AC could also be bound to a particular PC 1355 using the subject or issuer and serial number of the proxy 1356 certificate. There would appear to be great synergies between the 1357 use of Proxy Certificates and Attribute Certificates produced by 1358 third party Attribute Authorities. 1359 1360 However, the uses of Attribute Certificates that are granted by the 1361 first type of Attribute Authority, the end entity AA, overlap 1362 considerably with the uses of Proxy Certificates as described in the 1363 previous sections. Such Attribute Certificates are generally used 1364 for delegation of rights from one end entity to others, which clearly 1365 overlaps with the stated purpose of Proxy Certificates, namely single 1366 sign-on and delegation. 1367 13685.1.2. Delegation Using Attribute Certificates 1369 1370 In the motivating example in Section 2, PCs are used to delegate 1371 Steve's identity to the various other jobs and entities that need to 1372 act on Steve's behalf. This allows those other entities to 1373 authenticate as if they were Steve, for example to the mass storage 1374 system. 1375 1376 A solution to this example could also be cast using Attribute 1377 Certificates that are signed by Steve's EEC, which grant to the other 1378 entities in this example the right to perform various operations on 1379 Steve's behalf. In this example, the reliable file transfer service 1380 and all the hosts involved in file transfers, the starter program, 1381 the agent, the simulation jobs, and the post-processing job would 1382 each have their own EECs. Steve's EEC would therefore issue ACs to 1383 bind each of those other EEC identities to attributes that grant the 1384 necessary privileges allow them to, for example, access the mass 1385 storage system. 1386 1387 However, this AC based solution to delegation has some disadvantages 1388 as compared to the PC based solution: 1389 1390 * All protocols, authentication code, and identity based 1391 authorization services must be modified to understand ACs. With 1392 the PC solution, protocols (e.g., TLS) likely need no 1393 modification, authentication code needs minimal modification 1394 (e.g., to perform PC aware path validation), and identity based 1395 authorization services need minimal modification (e.g., possibly 1396 to find the EEC name and to check for any proxy policies). 1397 1398 1399 1400 1401 1402Tuecke, et al. Standards Track [Page 25] 1403 1404RFC 3820 X.509 Proxy Certificate Profile June 2004 1405 1406 1407 * ACs need to be created by Steve's EEC, which bind attributes to 1408 each of the other identities involved in the distributed 1409 application (i.e., the agent, simulation jobs, and post-processing 1410 job the file transfer service, the hosts transferring files). 1411 This implies that Steve must know in advance which other 1412 identities may be involved in this distributed application, in 1413 order to generate the appropriate ACs which are signed by Steve's 1414 ECC. On the other hand, the PC solution allows for much more 1415 flexibility, since parties can further delegate a PC without a 1416 priori knowledge by the originating EEC. 1417 1418 There are many unexplored tradeoffs and implications in this 1419 discussion of delegation. However, reasonable arguments can be made 1420 in favor of either an AC based solution to delegation or a PC based 1421 solution to delegation. The choice of which approach should be taken 1422 in a given instance may depend on factors such as the software that 1423 it needs to be integrated into, the type of delegation required, and 1424 other factors. 1425 14265.1.3. Propagation of Authorization Information 1427 1428 One possible use of Proxy Certificates is to carry authorization 1429 information associated with a particular identity. 1430 1431 The merits of placing authorization information into End Entity 1432 Certificates (also called a Public Key Certificate or PKC) have been 1433 widely debated. For example, Section 1 of "An Internet Attribute 1434 Certificate Profile for Authorization" [i3] states: 1435 1436 "Authorization information may be placed in a PKC extension or 1437 placed in a separate attribute certificate (AC). The placement of 1438 authorization information in PKCs is usually undesirable for two 1439 reasons. First, authorization information often does not have the 1440 same lifetime as the binding of the identity and the public key. 1441 When authorization information is placed in a PKC extension, the 1442 general result is the shortening of the PKC useful lifetime. 1443 Second, the PKC issuer is not usually authoritative for the 1444 authorization information. This results in additional steps for 1445 the PKC issuer to obtain authorization information from the 1446 authoritative source. 1447 1448 For these reasons, it is often better to separate authorization 1449 information from the PKC. Yet, authorization information also 1450 needs to be bound to an identity. An AC provides this binding; it 1451 is simply a digitally signed (or certified) identity and set of 1452 attributes." 1453 1454 1455 1456 1457 1458Tuecke, et al. Standards Track [Page 26] 1459 1460RFC 3820 X.509 Proxy Certificate Profile June 2004 1461 1462 1463 Placing authorization information in a PC mitigates the first 1464 undesirable property cited above. Since a PC has a lifetime that is 1465 mostly independent of (always shorter than) its signing EEC, a PC 1466 becomes a viable approach for carrying authorization information for 1467 the purpose of delegation. 1468 1469 The second undesirable property cited above is true. If a third 1470 party AA is authoritative, then using ACs issued by that third party 1471 AA is a natural approach to disseminating authorization information. 1472 However, this is true whether the identity being bound by these ACs 1473 comes from an EEC (PKC), or from a PC. 1474 1475 There is one case, however, that the above text does not consider. 1476 When performing delegation, it is usually the EEC itself that is 1477 authoritative (not the EEC issuer, or any third party AA). That is, 1478 it is up to the EEC to decide what authorization rights it is willing 1479 to grant to another party. In this situation, including such 1480 authorization information into PCs that are generated by the EEC 1481 seems a reasonable approach to disseminating such information. 1482 14835.1.4. Proxy Certificate as Attribute Certificate Holder 1484 1485 In a system that employs both PCs and ACs, one can imagine the 1486 utility of allowing a PC to be the holder of an AC. This would allow 1487 for a particular delegated instance of an identity to be given an 1488 attribute, rather than all delegated instances of that identity being 1489 given the attribute. 1490 1491 However, the issue of how to specify a PC as the holder of an AC 1492 remains open. An AC could be bound to a particular instance of a PC 1493 using the unique subject name of the PC, or it's issuer and serial 1494 number combination. 1495 1496 Unrestricted PCs issued by that PC would then inherit those ACs and 1497 independent PCs would not. PCs issued with a policy would depend on 1498 the policy as to whether or not they inherit the issuing PC's ACs 1499 (and potentially which ACs they inherit). 1500 1501 While an AC can be bound to one PC by the AA, how can the AA restrict 1502 that PC from passing it on to a subsequently delegated PC? One 1503 possible solution would be to define an extension to attribute 1504 certificates that allows the attribute authority to state whether an 1505 issued AC is to apply only to the particular entity to which it is 1506 bound, or if it may apply to PCs issued by that entity. 1507 1508 One issue that an AA in this circumstance would need to be aware of 1509 is that the PI of the PC that the AA bound the AC to, could issue 1510 another PC with the same name as the original PC to a different 1511 1512 1513 1514Tuecke, et al. Standards Track [Page 27] 1515 1516RFC 3820 X.509 Proxy Certificate Profile June 2004 1517 1518 1519 entity, effectively stealing the AC. This implies that an AA issuing 1520 an AC to a PC need to not only trust the entity holding the PC, but 1521 the entity holding the PC's issuer as well. 1522 15235.2. Kerberos 5 Tickets 1524 1525 The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a 1526 widely used authentication system based on conventional (shared 1527 secret key) cryptography. It provides support for single sign-on via 1528 creation of "Ticket Granting Tickets" or "TGT", and support for 1529 delegation of rights via "forwardable tickets". 1530 1531 Kerberos 5 tickets have informed many of the ideas surrounding X.509 1532 Proxy Certificates. For example, the local creation of a short-lived 1533 PC can be used to provide single sign-on in an X.509 PKI based 1534 system, just as creation of short-lived TGT allows for single sign-on 1535 in a Kerberos based system. And just as a TGT can be forwarded 1536 (i.e., delegated) to another entity to allow for proxying in a 1537 Kerberos based system, so can a PC can be delegated to allow for 1538 proxying in an X.509 PKI based system. 1539 1540 A major difference between a Kerberos TGT and an X.509 PC is that 1541 while creation and delegation of a TGT requires the involvement of a 1542 third party (Key Distribution Center), a PC can be unilaterally 1543 created without the active involvement of a third party. That is, a 1544 user can directly create a PC from an EEC for single sign-on 1545 capability, without requiring communication with a third party. And 1546 an entity with a PC can delegate the PC to another entity (i.e., by 1547 creating a new PC, signed by the first) without requiring 1548 communication with a third party. 1549 1550 The method used by Kerberos implementations to protect a TGT can also 1551 be used to protect the private key of a PC. For example, some Unix 1552 implementations of Kerberos use standard Unix file system security to 1553 protect a user's TGT from compromise. Similarly, the Globus 1554 Toolkit's Grid Security Infrastructure implementation of Proxy 1555 Certificates protects a user's PC private key using this same 1556 approach. 1557 15585.3. Examples of usage of Proxy Restrictions 1559 1560 This section gives some examples of Proxy Certificate usage and some 1561 examples of how the Proxy policy can be used to restrict Proxy 1562 Certificates. 1563 1564 1565 1566 1567 1568 1569 1570Tuecke, et al. Standards Track [Page 28] 1571 1572RFC 3820 X.509 Proxy Certificate Profile June 2004 1573 1574 15755.3.1. Example use of proxies without Restrictions 1576 1577 Steve wishes to perform a third-party FTP transfer between two FTP 1578 servers. Steve would use an existing PC to authenticate to both 1579 servers and delegate a PC to both hosts. He would inform each host 1580 of the unique subject name of the PC given to the other host. When 1581 the servers establish the data channel connection to each other, they 1582 use these delegated credentials to perform authentication and verify 1583 they are talking to the correct entity by checking the result of the 1584 authentication matches the name as provided by Steve. 1585 15865.3.2. Example use of proxies with Restrictions 1587 1588 Steve wishes to delegate to a process the right to perform a transfer 1589 of a file from host H1 to host H2 on his behalf. Steve would 1590 delegate a PC to the process and he would use Proxy Policy to 1591 restrict the delegated PC to two rights - the right to read file F1 1592 on host H1 and the right to write file F2 on host H2. 1593 1594 The process then uses this restricted PC to authenticate to servers 1595 H1 and H2. The process would also delegate a PC to both servers. 1596 Note that these delegated PCs would inherit the restrictions of their 1597 parents, though this is not relevant to this example. As in the 1598 example in the previous Section, each host would be provided with the 1599 unique name of the PC given to the other server. 1600 1601 Now when the process issues the command to transfer the file F1 on H1 1602 and to F2 on H2, these two servers perform an authorization check 1603 based on the restrictions in the PC that the process used to 1604 authenticate with them (in addition to any local policy they have). 1605 Namely H1 checks that the PC gives the user the right to read F1 and 1606 H2 checks that the PC gives the user the right to write F2. When 1607 setting up the data channel the servers would again verify the names 1608 resulting from the authentication match the names provided by Steve 1609 as in the example in the previous Section. 1610 1611 The extra security provided by these restrictions is that now if the 1612 PC delegated to the process by Steve is stolen, its use is greatly 1613 limited. 1614 16155.4. Delegation Tracing 1616 1617 A relying party accepting a Proxy Certificate may have an interest in 1618 knowing which parties issued earlier Proxy Certificates in the 1619 certificate chain and to whom they delegated them. For example it 1620 may know that a particular service or resource is known to have been 1621 1622 1623 1624 1625 1626Tuecke, et al. Standards Track [Page 29] 1627 1628RFC 3820 X.509 Proxy Certificate Profile June 2004 1629 1630 1631 compromised and if any part of a Proxy Certificate's chain was issued 1632 to the compromised service a relying party may wish to disregard the 1633 chain. 1634 1635 A delegation tracing mechanism was considered by the authors as 1636 additional information to be carried in the ProxyCertInfo extension. 1637 However at this time agreement has not been reached as to what this 1638 information should include so it was left out of this document, and 1639 will instead be considered in future revisions. The debate mainly 1640 centers on whether the tracing information should simply contain the 1641 identity of the issuer and receiver or it should also contain all the 1642 details of the delegated proxy and a signed statement from the 1643 receiver that the proxy was actually acceptable to it. 1644 16455.4.1. Site Information in Delegation Tracing 1646 1647 In some cases, it may be desirable to know the hosts involved in a 1648 delegation transaction (for example, a relying party may wish to 1649 reject proxy certificates that were created on a specific host or 1650 domain). An extension could be modified to include the PA's and 1651 Acceptor's IP addresses; however, IP addresses are typically easy to 1652 spoof, and in some cases the two parties to a transaction may not 1653 agree on the IP addresses being used (e.g., if the Acceptor is on a 1654 host that uses NAT, the Acceptor and the PA may disagree about the 1655 Acceptor's IP address). 1656 1657 Another suggestion was, in those cases where domain information is 1658 needed, to require that the subject names of all End Entities 1659 involved (the Acceptor(s) and the End Entity that appears in a PC's 1660 certificate path) include domain information. 1661 16626. Security Considerations 1663 1664 In this Section we discuss security considerations related to the use 1665 of Proxy Certificates. 1666 16676.1. Compromise of a Proxy Certificate 1668 1669 A Proxy Certificate is generally less secure than the EEC that issued 1670 it. This is due to the fact that the private key of a PC is 1671 generally not protected as rigorously as that of the EEC. For 1672 example, the private key of a PC is often protected using only file 1673 system security, in order to allow that PC to be used for single 1674 sign-on purposes. This makes the PC more susceptible to compromise. 1675 1676 However, the risk of a compromised PC is only the misuse of a single 1677 user's privileges. Due to the PC path validation checks, a PC cannot 1678 be used to sign an EEC or PC for another user. 1679 1680 1681 1682Tuecke, et al. Standards Track [Page 30] 1683 1684RFC 3820 X.509 Proxy Certificate Profile June 2004 1685 1686 1687 Further, a compromised PC can only be misused for the lifetime of the 1688 PC, and within the bound of the restriction policy carried by the PC. 1689 Therefore, one common way to limit the misuse of a compromised PC is 1690 to limit its validity period to no longer than is needed, and/or to 1691 include a restriction policy in the PC that limits the use of the 1692 (compromised) PC. 1693 1694 In addition, if a PC is compromised, it does NOT compromise the EEC 1695 that created the PC. This property is of great utility in protecting 1696 the highly valuable, and hard to replace, public key of the EEC. In 1697 other words, the use of Proxy Certificates to provide single sign-on 1698 capabilities in an X.509 PKI environment can actually increase the 1699 security of the end entity certificates, because creation and use of 1700 the PCs for user authentication limits the exposure of the EEC 1701 private key to only the creation of the first level PC. 1702 17036.2. Restricting Proxy Certificates 1704 1705 The pCPathLenConstraint field of the proxyCertInfo extension can be 1706 used by an EEC to limit subsequent delegation of the PC. A service 1707 may choose to only authorize a request if a valid PC can be delegated 1708 to it. An example of such as service is a job starter, which may 1709 choose to reject a job start request if a valid PC cannot be 1710 delegated to it. By limiting the pCPathLenConstraint, an EEC can 1711 ensure that a compromised PC of one job cannot be used to start 1712 additional jobs elsewhere. 1713 1714 An EEC or PC can limit what a new PC can be used for by turning off 1715 bits in the Key Usage and Extended Key Usage extensions. Once a key 1716 usage or extended key usage has been removed, the path validation 1717 algorithm ensures that it cannot be added back in a subsequent PC. 1718 In other words, key usage can only be decreased in PC chains. 1719 1720 The EEC could use the CRL Distribution Points extension and/or OCSP 1721 to take on the responsibility of revoking PCs that it had issued, if 1722 it felt that they were being misused. 1723 17246.3. Relying Party Trust of Proxy Certificates 1725 1726 The relying party that is going to authorize some actions on the 1727 basis of a PC will be aware that it has been presented with a PC, and 1728 can determine the depth of the delegation and the time that the 1729 delegation took place. It may want to use this information in 1730 addition to the information from the signing EEC. Thus a highly 1731 secure resource might refuse to accept a PC at all, or maybe only a 1732 single level of delegation, etc. 1733 1734 1735 1736 1737 1738Tuecke, et al. Standards Track [Page 31] 1739 1740RFC 3820 X.509 Proxy Certificate Profile June 2004 1741 1742 1743 The relying party should also be aware that since the policy 1744 restricting the rights of a PC is the intersection of the policy of 1745 all the PCs in it's certificate chain, this means any change in the 1746 certificate chain can effect the policy of the PC. Since there is no 1747 mechanism in place to enforce unique subject names of PCs, if an 1748 issuer were to issue two PCs with identical names and keys, but 1749 different rights, this could allow the two PCs to be substituted for 1750 each other in path validation and effect the rights of a PC down the 1751 chain. Ultimately, this means the relying party places trust in the 1752 entities that are acting as Proxy Issuers in the chain to behave 1753 properly. 1754 17556.4. Protecting Against Denial of Service with Key Generation 1756 1757 As discussed in Section 2.3, one of the motivations for Proxy 1758 Certificates is to allow for dynamic delegation between parties. This 1759 delegation potentially requires, by the party receiving the 1760 delegation, the generation of a new key pair which is a potentially 1761 computationally expensive operation. Care should be taken by such 1762 parties to prevent another entity from performing a denial of service 1763 attack by causing them to consume large amount of resource doing key 1764 generation. 1765 1766 A general guideline would always to perform authentication of the 1767 delegating party to prevent such attacks from being performed 1768 anonymously. Another guideline would be to maintain some state to 1769 detect and prevent such attacks. 1770 17716.5. Use of Proxy Certificates with a Central Repository 1772 1773 As discussed in Section 2.7, one potential use of Proxy Certificates 1774 is to ease certificate management for end users by storing the EEC 1775 private keys and certificates in a centrally managed repository. 1776 When a user needs a PKI credential, the user can login to the 1777 repository using name/password, one time password, etc. and the 1778 repository would then delegate a PC to the user with proxy rights, 1779 but continue to protect the EEC private key in the repository. 1780 1781 Care must be taken with this approach since compromise of the 1782 repository will potentially give the attacker access to the long-term 1783 private keys stored in the repository. It is strongly suggested that 1784 some form of hardware module be used to store the long-term private 1785 keys, which will serve to help prevent their direct threat though it 1786 may still allow a successful attacker to use the keys while the 1787 repository is compromised to sign arbitrary objects (including Proxy 1788 Certificates). 1789 1790 1791 1792 1793 1794Tuecke, et al. Standards Track [Page 32] 1795 1796RFC 3820 X.509 Proxy Certificate Profile June 2004 1797 1798 17997. IANA Considerations 1800 1801 IANA has established a registry for policy languages. Registration 1802 under IETF space is by IETF standards action as described in [i8]. 1803 Private policy languages should be under organizational OIDs; policy 1804 language authors are encouraged to list such languages in the IANA 1805 registry, along with a pointer to a specification. 1806 1807 OID Description 1808 --- ----------- 1809 1.3.6.1.5.5.7.21.1 id-ppl-inheritALL 1810 1.3.6.1.5.5.7.21.2 id-ppl-independent 1811 18128. References 1813 18148.1. Normative References 1815 1816 [n1] Bradner, S., "Key words for use in RFCs to Indicate 1817 Requirement Levels", BCP 14, RFC 2119, March 1997. 1818 1819 [n2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1820 Public Key Infrastructure Certificate and Certificate 1821 Revocation List (CRL) Profile", RFC 3280, April 2002. 1822 18238.2. Informative References 1824 1825 [i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. 1826 Tuecke, "A National-Scale Authentication Infrastructure", 1827 IEEE Computer, vol. 33, pp. 60-66, 2000. 1828 1829 [i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1830 2246, January 1999. 1831 1832 [i3] Farrell, S. and R. Housley, "An Internet Attribute 1833 Certificate Profile for Authorization", RFC 3281, April 2002. 1834 1835 [i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A 1836 Security Architecture for Computational Grids", presented at 1837 Proceedings of the 5th ACM Conference on Computer and 1838 Communications Security, 1998. 1839 1840 [i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the 1841 Grid: Enabling Scalable Virtual Organizations", International 1842 Journal of Supercomputer Applications, 2001. 1843 1844 [i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication 1845 Service (V5)", RFC 1510, September 1993. 1846 1847 1848 1849 1850Tuecke, et al. Standards Track [Page 33] 1851 1852RFC 3820 X.509 Proxy Certificate Profile June 2004 1853 1854 1855 [i7] Neuman, B. Clifford, "Proxy-Based Authorization and 1856 Accounting for Distributed Systems", In Proceedings of the 1857 13th International Conference on Distributed Computing 1858 Systems, pages 283-291, May 1993. 1859 1860 [i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA 1861 Considerations Section in RFC", RFC 2434, October 1998. 1862 18639. Acknowledgments 1864 1865 We are pleased to acknowledge significant contributions to this 1866 document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, 1867 Sam Meder, Jim Schaad, and Frank Siebenlist. 1868 1869 We are grateful to numerous colleagues for discussions on the topics 1870 covered in this paper, in particular (in alphabetical order, with 1871 apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy 1872 Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill 1873 Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, 1874 Gene Tsudik. 1875 1876 We are also grateful to members of the Global Grid Forum (GGF) Grid 1877 Security Infrastructure working group (GSI-WG), and the Internet 1878 Engineering Task Force (IETF) Public-Key Infrastructure (X.509) 1879 working group (PKIX) for feedback on this document. 1880 1881 This work was supported in part by the Mathematical, Information, and 1882 Computational Sciences Division subprogram of the Office of Advanced 1883 Scientific Computing Research, U.S. Department of Energy, under 1884 Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense 1885 Advanced Research Projects Agency under contract N66001-96-C-8523; by 1886 the National Science Foundation; and by the NASA Information Power 1887 Grid project. 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Tuecke, et al. Standards Track [Page 34] 1907 1908RFC 3820 X.509 Proxy Certificate Profile June 2004 1909 1910 1911Appendix A. 1988 ASN.1 Module 1912 1913 PKIXproxy88 { iso(1) identified-organization(3) dod(6) 1914 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1915 proxy-cert-extns(25) } 1916 1917 DEFINITIONS EXPLICIT TAGS ::= 1918 1919 BEGIN 1920 1921 -- EXPORTS ALL -- 1922 1923 -- IMPORTS NONE -- 1924 1925 -- PKIX specific OIDs 1926 1927 id-pkix OBJECT IDENTIFIER ::= 1928 { iso(1) identified-organization(3) 1929 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1930 1931 -- private certificate extensions 1932 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1933 1934 -- Locally defined OIDs 1935 1936 -- The proxy certificate extension 1937 id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } 1938 1939 -- Proxy certificate policy languages 1940 id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 } 1941 1942 -- Proxy certificate policies languages defined in 1943 id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 } 1944 id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 } 1945 id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 } 1946 1947 -- The ProxyCertInfo Extension 1948 ProxyCertInfoExtension ::= SEQUENCE { 1949 pCPathLenConstraint ProxyCertPathLengthConstraint 1950 OPTIONAL, 1951 proxyPolicy ProxyPolicy } 1952 1953 ProxyCertPathLengthConstraint ::= INTEGER 1954 ProxyPolicy ::= SEQUENCE { 1955 policyLanguage OBJECT IDENTIFIER, 1956 policy OCTET STRING OPTIONAL } 1957 1958 END 1959 1960 1961 1962Tuecke, et al. Standards Track [Page 35] 1963 1964RFC 3820 X.509 Proxy Certificate Profile June 2004 1965 1966 1967Authors' Addresses 1968 1969 Steven Tuecke 1970 Distributed Systems Laboratory 1971 Mathematics and Computer Science Division 1972 Argonne National Laboratory 1973 Argonne, IL 60439 1974 1975 Phone: 630-252-8711 1976 EMail: tuecke@mcs.anl.gov 1977 1978 1979 Von Welch 1980 National Center for Supercomputing Applications 1981 University of Illinois 1982 1983 EMail: vwelch@ncsa.uiuc.edu 1984 1985 1986 Doug Engert 1987 Argonne National Laboratory 1988 1989 EMail: deengert@anl.gov 1990 1991 1992 Laura Pearlman 1993 University of Southern California, Information Sciences Institute 1994 1995 EMail: laura@isi.edu 1996 1997 1998 Mary Thompson 1999 Lawrence Berkeley National Laboratory 2000 2001 EMail: mrthompson@lbl.gov 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018Tuecke, et al. Standards Track [Page 36] 2019 2020RFC 3820 X.509 Proxy Certificate Profile June 2004 2021 2022 2023Full Copyright Statement 2024 2025 Copyright (C) The Internet Society (2004). This document is subject 2026 to the rights, licenses and restrictions contained in BCP 78, and 2027 except as set forth therein, the authors retain all their rights. 2028 2029 This document and the information contained herein are provided on an 2030 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2031 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2032 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2033 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2034 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2035 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2036 2037Intellectual Property 2038 2039 The IETF takes no position regarding the validity or scope of any 2040 Intellectual Property Rights or other rights that might be claimed to 2041 pertain to the implementation or use of the technology described in 2042 this document or the extent to which any license under such rights 2043 might or might not be available; nor does it represent that it has 2044 made any independent effort to identify any such rights. Information 2045 on the procedures with respect to rights in RFC documents can be 2046 found in BCP 78 and BCP 79. 2047 2048 Copies of IPR disclosures made to the IETF Secretariat and any 2049 assurances of licenses to be made available, or the result of an 2050 attempt made to obtain a general license or permission for the use of 2051 such proprietary rights by implementers or users of this 2052 specification can be obtained from the IETF on-line IPR repository at 2053 http://www.ietf.org/ipr. 2054 2055 The IETF invites any interested party to bring to its attention any 2056 copyrights, patents or patent applications, or other proprietary 2057 rights that may cover technology that may be required to implement 2058 this standard. Please address the information to the IETF at ietf- 2059 ipr@ietf.org. 2060 2061Acknowledgement 2062 2063 Funding for the RFC Editor function is currently provided by the 2064 Internet Society. 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074Tuecke, et al. Standards Track [Page 37] 2075 2076