< draft-ietf-pkix-proxy-09.txt   draft-ietf-pkix-proxy-10.txt >
Internet Draft S. Tuecke Internet Draft S. Tuecke
Document: draft-ietf-pkix-proxy-09 ANL Document: draft-ietf-pkix-proxy-10 ANL
Expires May 2004 V. Welch Expires May 2004 V. Welch
U. Chicago NCSA
D. Engert D. Engert
ANL ANL
L. Pearlman L. Pearlman
USC/ISI USC/ISI
M. Thompson M. Thompson
LBNL LBNL
7 November 2003 19 December 2003
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Proxy Certificate Profile Proxy Certificate Profile
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 63 skipping to change at line 63
1 Introduction...................................................3 1 Introduction...................................................3
2 Overview of Approach...........................................4 2 Overview of Approach...........................................4
2.1 Terminology..................................................5 2.1 Terminology..................................................5
2.2 Background...................................................5 2.2 Background...................................................5
2.3 Motivation for Proxying......................................6 2.3 Motivation for Proxying......................................6
2.4 Motivation for Restricted Proxies............................8 2.4 Motivation for Restricted Proxies............................8
2.5 Motivation for Unique Proxy Name.............................9 2.5 Motivation for Unique Proxy Name.............................9
2.6 Description Of Approach.....................................10 2.6 Description Of Approach.....................................10
2.7 Features Of This Approach...................................11 2.7 Features Of This Approach...................................11
3 Certificate and Certificate Extensions Profile................13 3 Certificate and Certificate Extensions Profile................13
3.1 Issuer......................................................13 3.1 Issuer......................................................14
3.2 Issuer Alternative Name.....................................14 3.2 Issuer Alternative Name.....................................14
3.3 Serial Number...............................................14 3.3 Serial Number...............................................14
3.4 Subject.....................................................14 3.4 Subject.....................................................14
3.5 Subject Alternative Name....................................15 3.5 Subject Alternative Name....................................15
3.6 Key Usage and Extended Key Usage............................15 3.6 Key Usage and Extended Key Usage............................15
3.7 Basic Constraints...........................................15 3.7 Basic Constraints...........................................15
3.8 The ProxyCertInfo Extension.................................15 3.8 The ProxyCertInfo Extension.................................15
4 Proxy Certificate Path Validation.............................19 4 Proxy Certificate Path Validation.............................20
4.1 Basic Proxy Certificate Path Validation.....................21 4.1 Basic Proxy Certificate Path Validation.....................21
4.2 Using the Path Validation Algorithm.........................25 4.2 Using the Path Validation Algorithm.........................25
5 Commentary....................................................26 5 Commentary....................................................27
5.1 Relationship to Attribute Certificates......................26 5.1 Relationship to Attribute Certificates......................27
5.2 Kerberos 5 Tickets..........................................31 5.2 Kerberos 5 Tickets..........................................31
5.3 Examples of usage of Proxy Restrictions.....................32 5.3 Examples of usage of Proxy Restrictions.....................32
5.4 Delegation Tracing..........................................33 5.4 Delegation Tracing..........................................33
6 Security Considerations.......................................34 6 Security Considerations.......................................34
6.1 Compromise of a Proxy Certificate...........................34 6.1 Compromise of a Proxy Certificate...........................34
6.2 Restricting Proxy Certificates..............................34 6.2 Restricting Proxy Certificates..............................35
6.3 Relying Party Trust of Proxy Certificates...................35 6.3 Relying Party Trust of Proxy Certificates...................35
7 Normative References..........................................36 6.4 Protecting Against Denial of Service with Key Generation....36
8 Informational References......................................36 6.5 Use of Proxy Certificates in a Central Repository...........36
9 Acknowledgments...............................................37 7 IANA Considerations...........................................37
10 Contact Information.........................................37 8 Normative References..........................................37
11 Copyright Notice............................................38 9 Informational References......................................37
12 Intellectual Property Statement.............................38 10 Acknowledgments.............................................38
Appendix A. 1988 ASN.1 Module....................................39 11 Contact Information.........................................39
Appendix B. Change Log...........................................40 12 Copyright Notice............................................39
13 Intellectual Property Statement.............................40
Appendix A. 1988 ASN.1 Module....................................41
Appendix B. Change Log (To be removed prior to publication)......42
1 Introduction 1 Introduction
Use of a proxy credential [i8] is a common technique used in Use of a proxy credential [i8] is a common technique used in
security systems to allow entity A to grant to another entity B the security systems to allow entity A to grant to another entity B the
right for B to be authorized with others as if it were A. In other right for B to be authorized with others as if it were A. In other
words, entity B is acting as a proxy on behalf of entity A. This words, entity B is acting as a proxy on behalf of entity A. This
document forms a certificate profile for Proxy Certificates, based document forms a certificate profile for Proxy Certificates, based
on the RFC 3280, "Internet X.509 Public Key Infrastructure on the RFC 3280, "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile" [n2]. Certificate and CRL Profile" [n2].
skipping to change at line 143 skipping to change at line 146
is introduced. is introduced.
Section 4 defines path validation rules for Proxy Certificates. Section 4 defines path validation rules for Proxy Certificates.
Section 5 provides non-normative commentary on Proxy Certificates. Section 5 provides non-normative commentary on Proxy Certificates.
Section 6 discusses security considerations relating to Proxy Section 6 discusses security considerations relating to Proxy
Certificates. Certificates.
References in this document are sorted into normative and References in this document are sorted into normative and
information references. Normative references, listed in Section 7, information references. Normative references, listed in Section 8,
are in the form [nXX]. Informative references, listed in Section are in the form [nXX]. Informative references, listed in Section
8, are in the form [iXX]. 9, are in the form [iXX].
Section 9 contains acknowledgements. Section 10 contains acknowledgements.
Section 10 contains contact information for the authors. Section 11 contains contact information for the authors.
Section 11 contains the copyright information for this document. Section 12 contains the copyright information for this document.
Section 12 contains the intellectual property information for this Section 13 contains the intellectual property information for this
document. document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [n1]. this document are to be interpreted as described in RFC-2119 [n1].
2 Overview of Approach 2 Overview of Approach
This section provides non-normative commentary on Proxy This section provides non-normative commentary on Proxy
Certificates. Certificates.
skipping to change at line 659 skipping to change at line 662
The ProxyCertInfo extension consists of one required and two The ProxyCertInfo extension consists of one required and two
optional fields, which are described in detail in the following optional fields, which are described in detail in the following
subsections. subsections.
3.8.1 pCPathLenConstraint 3.8.1 pCPathLenConstraint
The pCPathLenConstraint field, if present, specifies the maximum The pCPathLenConstraint field, if present, specifies the maximum
depth of the path of Proxy Certificates that can be signed by this depth of the path of Proxy Certificates that can be signed by this
Proxy Certificate. A pCPathLenConstraint of 0 means that this Proxy Certificate. A pCPathLenConstraint of 0 means that this
certificate MUST NOT be used to sign a Proxy Certificate. If the certificate MUST NOT be used to sign a Proxy Certificate. If the
proxyCertInfo extension is not present then the maximum proxy path pCPathLenConstraint field is not present then the maximum proxy
length is unlimited. End entity certificates have unlimited maximum path length is unlimited. End entity certificates have unlimited
proxy path lengths. maximum proxy path lengths.
3.8.2 proxyPolicy 3.8.2 proxyPolicy
The proxyPolicy field specifies a policy on the use of this The proxyPolicy field specifies a policy on the use of this
certificate for the purposes of authorization. Within the certificate for the purposes of authorization. Within the
proxyPolicy, the policy field is an expression of policy, and the proxyPolicy, the policy field is an expression of policy, and the
policyLanguage field indicates the language in which the policy is policyLanguage field indicates the language in which the policy is
expressed. expressed.
The proxyPolicy field in the proxyCertInfo extension does not The proxyPolicy field in the proxyCertInfo extension does not
skipping to change at line 707 skipping to change at line 710
rights this PC has are those granted explicitly to it. rights this PC has are those granted explicitly to it.
For either of the policyLanguage values listed above, the policy For either of the policyLanguage values listed above, the policy
field MUST NOT be present. field MUST NOT be present.
Other values for the policyLanguage field indicates that this is a Other values for the policyLanguage field indicates that this is a
restricted proxy certification and have some other policy limiting restricted proxy certification and have some other policy limiting
its ability to do proxying. In this case the policy field MAY be its ability to do proxying. In this case the policy field MAY be
present and it MUST contain information expressing the policy. If present and it MUST contain information expressing the policy. If
the policy field is not present the policy MUST be implicit in the the policy field is not present the policy MUST be implicit in the
value of the policyLanguage field itself. value of the policyLanguage field itself. Authors of additional
policy languages are encouraged to publicly document their policy
language and list it in the IANA registry (see Section Error!
Reference source not found.).
Proxy policies are used to limit the amount of authority delegated, Proxy policies are used to limit the amount of authority delegated,
for example to assert that the proxy certificate may be used only for example to assert that the proxy certificate may be used only
to make requests to a specific server, or only to authorize to make requests to a specific server, or only to authorize
specific operations on specific resources. This document is specific operations on specific resources. This document is
agnostic to the policies that can be placed in the policy field. agnostic to the policies that can be placed in the policy field.
Proxy policies impose additional requirements on the relying party, Proxy policies impose additional requirements on the relying party,
because only the relying party is in a position to ensure that because only the relying party is in a position to ensure that
those policies are enforced. When making an authorization decision those policies are enforced. When making an authorization decision
based on a proxy certificate based on rights that proxy certificate based on a proxy certificate based on rights that proxy certificate
inherited from its issuer, it is the relying party's responsibility inherited from its issuer, it is the relying party's responsibility
to verify that the requested authority is compatible with all to verify that the requested authority is compatible with all
policies in the PC's certificate path. In other words, the relying policies in the PC's certificate path. In other words, the relying
party MUST verify that the following three conditions are all met: party MUST verify that the following three conditions are all met:
1) The relying MUST party know how to interpret the proxy policy and 1) The relying party MUST know how to interpret the proxy policy and
the request is allowed under that policy. the request is allowed under that policy.
2) If the Proxy Issuer is an EEC then the relying party's local 2) If the Proxy Issuer is an EEC then the relying party's local
policies MUST authorize the request for the entity named in the policies MUST authorize the request for the entity named in the
EEC. EEC.
3) If the Proxy Issuer is another PC, then one of the following MUST 3) If the Proxy Issuer is another PC, then one of the following MUST
be true: be true:
a. The relying partyÆs local policies authorize the Proxy a. The relying party's local policies authorize the Proxy
Issuer to perform the request. Issuer to perform the request.
b. The Proxy Issuer inherits the right to perform the request b. The Proxy Issuer inherits the right to perform the request
from its issuer by means of its proxy policy. This must be from its issuer by means of its proxy policy. This must be
verified by verifying these three conditions on the Proxy verified by verifying these three conditions on the Proxy
Issuer in a recursive manner. Issuer in a recursive manner.
If these conditions are not met, the relying party MUST either deny If these conditions are not met, the relying party MUST either deny
authorization, or ignore the PC and the whole certificate chain authorization, or ignore the PC and the whole certificate chain
including the EEC entirely when making its authorization decision including the EEC entirely when making its authorization decision
skipping to change at line 1021 skipping to change at line 1025
(f) If a key usage extension is present, verify that the (f) If a key usage extension is present, verify that the
digitalSignature bit is set. digitalSignature bit is set.
If either check (a) or (f) fails, the procedure terminates, If either check (a) or (f) fails, the procedure terminates,
returning a failure indication and an appropriate reason. returning a failure indication and an appropriate reason.
If (a) and (f) complete successfully, increment i and perform the If (a) and (f) complete successfully, increment i and perform the
basic certificate processing specified in 4.1.3. basic certificate processing specified in 4.1.3.
4.1.5 Wrap-up Proceedures 4.1.5 Wrap-up Procedures
(a) Assign the certificate subject name to working_issuer_name. (a) Assign the certificate subject name to working_issuer_name.
(b) Assign the certificate subjectPublicKey to (b) Assign the certificate subjectPublicKey to
working_public_key. working_public_key.
(c) If the subjectPublicKeyInfo field of the certificate (c) If the subjectPublicKeyInfo field of the certificate
contains an algorithm field with non-null parameters, assign the contains an algorithm field with non-null parameters, assign the
parameters to the proxy_issuer_public_key_parameters variable. parameters to the proxy_issuer_public_key_parameters variable.
skipping to change at line 1489 skipping to change at line 1493
all the PCs in it's certificate chain, this means any change in the all the PCs in it's certificate chain, this means any change in the
certificate chain can effect the policy of the PC. Since there is certificate chain can effect the policy of the PC. Since there is
no mechanism in place to enforce unique subject names of PCs, if an no mechanism in place to enforce unique subject names of PCs, if an
issuer were two PCs with identical names and keys, but different issuer were two PCs with identical names and keys, but different
rights this could allow the two PCs to be substituted for each rights this could allow the two PCs to be substituted for each
other in path validation and effect the rights of a PC down the other in path validation and effect the rights of a PC down the
chain. Ultimately, this means the relying party places trust in the chain. Ultimately, this means the relying party places trust in the
entities that are acting as Proxy Issuers in the chain to behave entities that are acting as Proxy Issuers in the chain to behave
properly. properly.
7 Normative References 6.4 Protecting Against Denial of Service with Key Generation
As discussed in Section 2.3, one of the motivations for Proxy
Certificates is to allow for dynamic delegation between parties.
This delegation potentially requires, by the party receiving the
delegation, the generation of a new key pair which is a potentially
computationally expensive operation. Care should be taken by such
parties to prevent another entity from performing a denial of
service attack by causing them to consume large amount of resource
doing key generation.
A general guideline would always to perform authentication of the
delegating party to prevent such attacks from being performed
anonymously. Another guideline would be to maintain some state to
detect and prevent such attacks.
6.5 Use of Proxy Certificates with a Central Repository
As discussed in Section 2.7, one potential use of Proxy
Certificates is to ease certificate management for end users by
storing the EEC private keys and certificates in a centrally
managed repository. When a user needs a PKI credential, the user
can login to the repository using name/password, one time password,
etc. and the repository would then delegate a PC to the user with
proxy rights, but continue to protect the EEC private key in the
repository.
Care must be taken with this approach since compromise of the
repository will potentially give the attacker access to the long-
term private keys stored in the repository. It is strongly
suggested that some form of hardware module be used to store the
long-term private keys, which will serve to help prevent their
direct threat though it may still allow a successful attacker to
use the keys while the repository is compromised to sign arbitrary
objects (including Proxy Certificates).
7 IANA Considerations
IANA should establish a registry for policy languages. Registration
under IETF space is by IETF standards action as described in [i9].
Private policy languages should be under organizational OIDs;
policy language authors are encouraged to list such languages in
the IANA registry, along with a pointer to a specification.
8 Normative References
[n1] Bradner, S., "Key words for use in RFCs to Indicate [n1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[n2] Housley, R., W. Polk, W. Ford, and D. Solo, "Internet X.509 [n2] Housley, R., W. Polk, W. Ford, and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile," RFC 3280, April 2002. Revocation List (CRL) Profile," RFC 3280, April 2002.
8 Informational References 9 Informational References
[i1] Butler, R., D. Engert, I. Foster, C. Kesselman, and S. [i1] Butler, R., D. Engert, I. Foster, C. Kesselman, and S.
Tuecke, "A National-Scale Authentication Infrastructure," Tuecke, "A National-Scale Authentication Infrastructure,"
IEEE Computer, vol. 33, pp. 60-66, 2000. IEEE Computer, vol. 33, pp. 60-66, 2000.
[i2] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0," [i2] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0,"
RFC 2246, January 1999. RFC 2246, January 1999.
[i3] Farrell, S. and R. Housley, "An Internet Attribute [i3] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization," RFC 3281, April Certificate Profile for Authorization," RFC 3281, April
2002. 2002.
[i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A [i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A
skipping to change at line 1514 skipping to change at line 1562
[i3] Farrell, S. and R. Housley, "An Internet Attribute [i3] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization," RFC 3281, April Certificate Profile for Authorization," RFC 3281, April
2002. 2002.
[i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A [i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A
Security Architecture for Computational Grids," presented Security Architecture for Computational Grids," presented
at Proceedings of the 5th ACM Conference on Computer and at Proceedings of the 5th ACM Conference on Computer and
Communications Security, 1998. Communications Security, 1998.
[i5] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of [i5] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of
the Grid: Enabling Scalable Virtual Organizations," the Grid: Enabling Scalable Virtual Organizations,"
International Journal of Supercomputer Applications, 2001. International Journal of Supercomputer Applications, 2001.
[i6] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation [i6] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation
Protocol," Internet Draft draft-ietf-tls-delegation-00.txt, Protocol," Internet Draft draft-ietf-tls-delegation-00.txt,
2001 2001
[i7] Kohl, J. and C. Neuman, "The Kerberos Network [i7] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)," RFC 1510, September 1993. Authentication Service (V5)," RFC 1510, September 1993.
[i8] B. Clifford Neuman. Proxy-Based Authorization and [i8] B. Clifford Neuman. "Proxy-Based Authorization and
Accounting for Distributed Systems. In Proceedings of the Accounting for Distributed Systems." In Proceedings of the
13th International Conference on Distributed Computing 13th International Conference on Distributed Computing
Systems, pages 283-291, May 1993. Systems, pages 283-291, May 1993.
9 Acknowledgments [i9] Narten, T. and and H. Alvestrand. "Guidelines for Writing
an IANA Considerations Section in RFC," RFC 2434, October
1998.
10 Acknowledgments
We are pleased to acknowledge significant contributions to this We are pleased to acknowledge significant contributions to this
document by David Chadwick, Ian Foster, Jarek Gawor, Carl document by David Chadwick, Ian Foster, Jarek Gawor, Carl
Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist. Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.
We are grateful to numerous colleagues for discussions on the We are grateful to numerous colleagues for discussions on the
topics covered in this paper, in particular (in alphabetical order, topics covered in this paper, in particular (in alphabetical order,
with apologies to anybody we've missed): Carlisle Adams, Joe with apologies to anybody we've missed): Carlisle Adams, Joe
Bester, Randy Butler, Doug Engert, Keith Jackson, Steve Hanna, Russ Bester, Randy Butler, Doug Engert, Keith Jackson, Steve Hanna, Russ
Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang,
skipping to change at line 1550 skipping to change at line 1603
working group (PKIX) for feedback on this document. working group (PKIX) for feedback on this document.
This work was supported in part by the Mathematical, Information, This work was supported in part by the Mathematical, Information,
and Computational Sciences Division subprogram of the Office of and Computational Sciences Division subprogram of the Office of
Advanced Scientific Computing Research, U.S. Department of Energy, Advanced Scientific Computing Research, U.S. Department of Energy,
under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense
Advanced Research Projects Agency under contract N66001-96-C-8523; Advanced Research Projects Agency under contract N66001-96-C-8523;
by the National Science Foundation; and by the NASA Information by the National Science Foundation; and by the NASA Information
Power Grid project. Power Grid project.
10 Contact Information 11 Contact Information
Steven Tuecke Steven Tuecke
Distributed Systems Laboratory Distributed Systems Laboratory
Mathematics and Computer Science Division Mathematics and Computer Science Division
Argonne National Laboratory Argonne National Laboratory
Argonne, IL 60439 Argonne, IL 60439
Phone: 630-252-8711 Phone: 630-252-8711
Email: tuecke@mcs.anl.gov Email: tuecke@mcs.anl.gov
Von Welch Von Welch
University of Chicago National Center for Supercomputing Applications
Email: welch@mcs.anl.gov University of Illinois
Email: vwelch@ncsa.uiuc.edu
Doug Engert Doug Engert
Argonne National Laboratory Argonne National Laboratory
Email: deengert@anl.gov Email: deengert@anl.gov
Laura Pearlman Laura Pearlman
University of Southern California, Information Sciences Institute University of Southern California, Information Sciences Institute
Email: laura@isi.edu Email: laura@isi.edu
Mary Thompson Mary Thompson
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
Email: mrthompson@lbl.gov Email: mrthompson@lbl.gov
11 Copyright Notice 12 Copyright Notice
Copyright (C) The Internet Society (September 23, 2002). All Rights Copyright (C) The Internet Society (September 23, 2002). All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
skipping to change at line 1604 skipping to change at line 1659
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE MERCHANTABILITY OR FITNESS THE INFORMATION HEREIN WILL NOT INFRINGE MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
12 Intellectual Property Statement 13 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
skipping to change at line 1669 skipping to change at line 1724
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 } id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 } id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension -- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE { ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL, OPTIONAL,
proxyPolicy ProxyPolicy } proxyPolicy ProxyPolicy }
ProxyCertPathLengthConstraint ::= INTEGER ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE { ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER, policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL } policy OCTET STRING OPTIONAL }
END END
Appendix B. Change Log Appendix B. Change Log (To be removed prior to publication)
draft-ietf-pkix-impersonation-00 (February 2001) draft-ietf-pkix-impersonation-00 (February 2001)
Initial submission. Initial submission.
draft-ietf-pkix-proxy-00 (July 2001) draft-ietf-pkix-proxy-00 (July 2001)
Renamed to "Proxy Certificate", from "Impersonation Renamed to "Proxy Certificate", from "Impersonation
Certificate", due to overwhelming feedback from IETF and GGF. Certificate", due to overwhelming feedback from IETF and GGF.
skipping to change at line 1925 skipping to change at line 1977
regardless of whether or not the PC itself contains a policy, as regardless of whether or not the PC itself contains a policy, as
other PCs in the signing chain MAY contain conditions that MUST other PCs in the signing chain MAY contain conditions that MUST
be verified." be verified."
Clarification in 3.8.2: "interpret the policy" to "interpret the Clarification in 3.8.2: "interpret the policy" to "interpret the
proxy policy" proxy policy"
Clarified text in 3.8.1 regarding EECs. Clarified text in 3.8.1 regarding EECs.
draft-ietf-pkix-proxy-09 (November 2003) draft-ietf-pkix-proxy-09 (November 2003)
Corrected object identifier for proxy cert extension in 3.8 Corrected object identifier for proxy cert extension in 3.8
Improved phrasing of conditions 2 and 3 in 3.8.2 Improved phrasing of conditions 2 and 3 in 3.8.2
Improved phrasing of (e) in 4 to make clear that any proxy Improved phrasing of (e) in 4 to make clear that any proxy
certificate can limit length of path. certificate can limit length of path.
Minor editorial changes in 4.1.1, 4.2, 5.1.3, 6.1 Minor editorial changes in 4.1.1, 4.2, 5.1.3, 6.1
Added reference to RFC 3280 in 4.1.3 step (d). Added reference to RFC 3280 in 4.1.3 step (d).
draft-ietf-pkix-proxy-10 (December 2003)
Minor corrections in 3.8.2, 4.1.5, and non-normative references.
Marked Appendix B as "To be removed before publication"
Updated contact information and institution for Von Welch.
Added Section 7, IANA Considerations, and non-normative
reference to RFC 2434.
Section 3.8.1: Correction "If the proxyCertInfo extension is not
present..." changed to "If the pCPathLenConstraint field is not
present..."
Section 3.8.2: Added encouragement for authors to publicly
specific and list their policy languages with IANA.
Added sections 6.4 and 6.5 to Security Considerations.
 End of changes. 33 change blocks. 
42 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/