diff --git a/doc/standardisation/rfc2253.txt b/doc/standardisation/rfc2253.txt new file mode 100644 index 000000000..a7439eed7 --- /dev/null +++ b/doc/standardisation/rfc2253.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group M. Wahl +Request for Comments: 2253 Critical Angle Inc. +Obsoletes: 1779 S. Kille +Category: Standards Track Isode Ltd. + T. Howes + Netscape Communications Corp. + December 1997 + + + Lightweight Directory Access Protocol (v3): + UTF-8 String Representation of Distinguished Names + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +IESG Note + + This document describes a directory access protocol that provides + both read and update access. Update access requires secure + authentication, but this document does not mandate implementation of + any satisfactory authentication mechanisms. + + In accordance with RFC 2026, section 4.4.1, this specification is + being approved by IESG as a Proposed Standard despite this + limitation, for the following reasons: + + a. to encourage implementation and interoperability testing of + these protocols (with or without update access) before they + are deployed, and + + b. to encourage deployment and use of these protocols in read-only + applications. (e.g. applications where LDAPv3 is used as + a query language for directories which are updated by some + secure mechanism other than LDAP), and + + c. to avoid delaying the advancement and deployment of other Internet + standards-track protocols which require the ability to query, but + not update, LDAPv3 directory servers. + + + + +Wahl, et. al. Proposed Standard [Page 1] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + Readers are hereby warned that until mandatory authentication + mechanisms are standardized, clients and servers written according to + this specification which make use of update functionality are + UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION + IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. + + Implementors are hereby discouraged from deploying LDAPv3 clients or + servers which implement the update functionality, until a Proposed + Standard for mandatory authentication in LDAPv3 has been approved and + published as an RFC. + +Abstract + + The X.500 Directory uses distinguished names as the primary keys to + entries in the directory. Distinguished Names are encoded in ASN.1 + in the X.500 Directory protocols. In the Lightweight Directory + Access Protocol, a string representation of distinguished names is + transferred. This specification defines the string format for + representing names, which is designed to give a clean representation + of commonly used distinguished names, while being able to represent + any distinguished name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [6]. + +1. Background + + This specification assumes familiarity with X.500 [1], and the + concept of Distinguished Name. It is important to have a common + format to be able to unambiguously represent a distinguished name. + The primary goal of this specification is ease of encoding and + decoding. A secondary goal is to have names that are human readable. + It is not expected that LDAP clients with a human user interface + would display these strings directly to the user, but would most + likely be performing translations (such as expressing attribute type + names in one of the local national languages). + +2. Converting DistinguishedName from ASN.1 to a String + + In X.501 [2] the ASN.1 structure of distinguished name is defined as: + + DistinguishedName ::= RDNSequence + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + + + + + +Wahl, et. al. Proposed Standard [Page 2] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + RelativeDistinguishedName ::= SET SIZE (1..MAX) OF + AttributeTypeAndValue + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue } + + The following sections define the algorithm for converting from an + ASN.1 structured representation to a UTF-8 string representation. + +2.1. Converting the RDNSequence + + If the RDNSequence is an empty sequence, the result is the empty or + zero length string. + + Otherwise, the output consists of the string encodings of each + RelativeDistinguishedName in the RDNSequence (according to 2.2), + starting with the last element of the sequence and moving backwards + toward the first. + + The encodings of adjoining RelativeDistinguishedNames are separated + by a comma character (',' ASCII 44). + +2.2. Converting RelativeDistinguishedName + + When converting from an ASN.1 RelativeDistinguishedName to a string, + the output consists of the string encodings of each + AttributeTypeAndValue (according to 2.3), in any order. + + Where there is a multi-valued RDN, the outputs from adjoining + AttributeTypeAndValues are separated by a plus ('+' ASCII 43) + character. + +2.3. Converting AttributeTypeAndValue + + The AttributeTypeAndValue is encoded as the string representation of + the AttributeType, followed by an equals character ('=' ASCII 61), + followed by the string representation of the AttributeValue. The + encoding of the AttributeValue is given in section 2.4. + + If the AttributeType is in a published table of attribute types + associated with LDAP [4], then the type name string from that table + is used, otherwise it is encoded as the dotted-decimal encoding of + the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is + described in [3]. As an example, strings for a few of the attribute + types frequently seen in RDNs include: + + + + + +Wahl, et. al. Proposed Standard [Page 3] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + String X.500 AttributeType + ------------------------------ + CN commonName + L localityName + ST stateOrProvinceName + O organizationName + OU organizationalUnitName + C countryName + STREET streetAddress + DC domainComponent + UID userid + +2.4. Converting an AttributeValue from ASN.1 to a String + + If the AttributeValue is of a type which does not have a string + representation defined for it, then it is simply encoded as an + octothorpe character ('#' ASCII 35) followed by the hexadecimal + representation of each of the bytes of the BER encoding of the X.500 + AttributeValue. This form SHOULD be used if the AttributeType is of + the dotted-decimal form. + + Otherwise, if the AttributeValue is of a type which has a string + representation, the value is converted first to a UTF-8 string + according to its syntax specification (see for example section 6 of + [4]). + + If the UTF-8 string does not have any of the following characters + which need escaping, then that string can be used as the string + representation of the value. + + o a space or "#" character occurring at the beginning of the + string + + o a space character occurring at the end of the string + + o one of the characters ",", "+", """, "\", "<", ">" or ";" + + Implementations MAY escape other characters. + + If a character to be escaped is one of the list shown above, then it + is prefixed by a backslash ('\' ASCII 92). + + Otherwise the character to be escaped is replaced by a backslash and + two hex digits, which form a single byte in the code of the + character. + + Examples of the escaping mechanism are shown in section 5. + + + + +Wahl, et. al. Proposed Standard [Page 4] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +3. Parsing a String back to a Distinguished Name + + The structure of the string is specified in a BNF grammar, based on + the grammar defined in RFC 822 [5]. Server implementations parsing a + DN string generated by an LDAPv2 client MUST also accept (and ignore) + the variants given in section 4 of this document. + +distinguishedName = [name] ; may be empty string + +name = name-component *("," name-component) + +name-component = attributeTypeAndValue *("+" attributeTypeAndValue) + +attributeTypeAndValue = attributeType "=" attributeValue + +attributeType = (ALPHA 1*keychar) / oid +keychar = ALPHA / DIGIT / "-" + +oid = 1*DIGIT *("." 1*DIGIT) + +attributeValue = string + +string = *( stringchar / pair ) + / "#" hexstring + / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2 + +quotechar = + +special = "," / "=" / "+" / "<" / ">" / "#" / ";" + +pair = "\" ( special / "\" / QUOTATION / hexpair ) +stringchar = + +hexstring = 1*hexpair +hexpair = hexchar hexchar + +hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" + / "a" / "b" / "c" / "d" / "e" / "f" + +ALPHA = + ; (decimal 65-90 and 97-122) +DIGIT = ; (decimal 48-57) +QUOTATION = + + + + + + + + +Wahl, et. al. Proposed Standard [Page 5] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +4. Relationship with RFC 1779 and LDAPv2 + + The syntax given in this document is more restrictive than the syntax + in RFC 1779. Implementations parsing a string generated by an LDAPv2 + client MUST accept the syntax of RFC 1779. Implementations MUST NOT, + however, generate any of the RFC 1779 encodings which are not + described above in section 2. + + Implementations MUST allow a semicolon character to be used instead + of a comma to separate RDNs in a distinguished name, and MUST also + allow whitespace characters to be present on either side of the comma + or semicolon. The whitespace characters are ignored, and the + semicolon replaced with a comma. + + Implementations MUST allow an oid in the attribute type to be + prefixed by one of the character strings "oid." or "OID.". + + Implementations MUST allow for space (' ' ASCII 32) characters to be + present between name-component and ',', between attributeTypeAndValue + and '+', between attributeType and '=', and between '=' and + attributeValue. These space characters are ignored when parsing. + + Implementations MUST allow a value to be surrounded by quote ('"' + ASCII 34) characters, which are not part of the value. Inside the + quoted value, the following characters can occur without any + escaping: + + ",", "=", "+", "<", ">", "#" and ";" + +5. Examples + + This notation is designed to be convenient for common forms of name. + This section gives a few examples of distinguished names written + using this notation. First is a name containing three relative + distinguished names (RDNs): + + CN=Steve Kille,O=Isode Limited,C=GB + + Here is an example name containing three RDNs, in which the first RDN + is multi-valued: + + OU=Sales+CN=J. Smith,O=Widget Inc.,C=US + + This example shows the method of quoting of a comma in an + organization name: + + CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB + + + + +Wahl, et. al. Proposed Standard [Page 6] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + An example name in which a value contains a carriage return + character: + + CN=Before\0DAfter,O=Test,C=GB + + An example name in which an RDN was of an unrecognized type. The + value is the BER encoding of an OCTET STRING containing two bytes + 0x48 and 0x69. + + 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB + + Finally, an example of an RDN surname value consisting of 5 letters: + + Unicode Letter Description 10646 code UTF-8 Quoted + =============================== ========== ====== ======= + LATIN CAPITAL LETTER L U0000004C 0x4C L + LATIN SMALL LETTER U U00000075 0x75 u + LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D + LATIN SMALL LETTER I U00000069 0x69 i + LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87 + + Could be written in printable ASCII (useful for debugging purposes): + + SN=Lu\C4\8Di\C4\87 + +6. References + + [1] The Directory -- overview of concepts, models and services. + ITU-T Rec. X.500(1993). + + [2] The Directory -- Models. ITU-T Rec. X.501(1993). + + [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [5] Crocker, D., "Standard of the Format of ARPA-Internet Text + Messages", STD 11, RFC 822, August 1982. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119. + + + + + + + +Wahl, et. al. Proposed Standard [Page 7] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +7. Security Considerations + +7.1. Disclosure + + Distinguished Names typically consist of descriptive information + about the entries they name, which can be people, organizations, + devices or other real-world objects. This frequently includes some + of the following kinds of information: + + - the common name of the object (i.e. a person's full name) + - an email or TCP/IP address + - its physical location (country, locality, city, street address) + - organizational attributes (such as department name or affiliation) + + Most countries have privacy laws regarding the publication of + information about people. + +7.2. Use of Distinguished Names in Security Applications + + The transformations of an AttributeValue value from its X.501 form to + an LDAP string representation are not always reversible back to the + same BER or DER form. An example of a situation which requires the + DER form of a distinguished name is the verification of an X.509 + certificate. + + For example, a distinguished name consisting of one RDN with one AVA, + in which the type is commonName and the value is of the TeletexString + choice with the letters 'Sam' would be represented in LDAP as the + string CN=Sam. Another distinguished name in which the value is + still 'Sam' but of the PrintableString choice would have the same + representation CN=Sam. + + Applications which require the reconstruction of the DER form of the + value SHOULD NOT use the string representation of attribute syntaxes + when converting a distinguished name to the LDAP format. Instead, + they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') + as described in the first paragraph of section 2.4. + +8. Authors' Addresses + + Mark Wahl + Critical Angle Inc. + 4815 W. Braker Lane #502-385 + Austin, TX 78759 + USA + + EMail: M.Wahl@critical-angle.com + + + + +Wahl, et. al. Proposed Standard [Page 8] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + + Steve Kille + Isode Ltd. + The Dome + The Square + Richmond, Surrey + TW9 1DT + England + + Phone: +44-181-332-9091 + EMail: S.Kille@ISODE.COM + + + Tim Howes + Netscape Communications Corp. + 501 E. Middlefield Rd, MS MV068 + Mountain View, CA 94043 + USA + + Phone: +1 650 937-3419 + EMail: howes@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wahl, et. al. Proposed Standard [Page 9] + +RFC 2253 LADPv3 Distinguished Names December 1997 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Wahl, et. al. Proposed Standard [Page 10] + diff --git a/doc/standardisation/rfc3280.txt b/doc/standardisation/rfc3280.txt new file mode 100644 index 000000000..433908bb7 --- /dev/null +++ b/doc/standardisation/rfc3280.txt @@ -0,0 +1,7227 @@ + + + + + + +Network Working Group R. Housley +Request for Comments: 3280 RSA Laboratories +Obsoletes: 2459 W. Polk +Category: Standards Track NIST + W. Ford + VeriSign + D. Solo + Citigroup + April 2002 + + Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List (CRL) Profile + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This memo profiles the X.509 v3 certificate and X.509 v2 Certificate + Revocation List (CRL) for use in the Internet. An overview of this + approach and model are provided as an introduction. The X.509 v3 + certificate format is described in detail, with additional + information regarding the format and semantics of Internet name + forms. Standard certificate extensions are described and two + Internet-specific extensions are defined. A set of required + certificate extensions is specified. The X.509 v2 CRL format is + described in detail, and required extensions are defined. An + algorithm for X.509 certification path validation is described. An + ASN.1 module and examples are provided in the appendices. + +Table of Contents + + 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 + 2 Requirements and Assumptions . . . . . . . . . . . . . . 5 + 2.1 Communication and Topology . . . . . . . . . . . . . . 6 + 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6 + 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7 + 2.4 Administrator Expectations . . . . . . . . . . . . . . 7 + 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7 + + + +Housley, et. al. Standards Track [Page 1] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8 + 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9 + 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13 + 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13 + 4 Certificate and Certificate Extensions Profile . . . . . 14 + 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15 + 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16 + 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16 + 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16 + 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16 + 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17 + 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17 + 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17 + 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18 + 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 + 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 + 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22 + 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 + 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24 + 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24 + 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24 + 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24 + 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25 + 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26 + 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27 + 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28 + 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29 + 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30 + 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33 + 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33 + 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36 + 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36 + 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36 + 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37 + 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40 + 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40 + 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42 + 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44 + 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44 + 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45 + 4.2.2.1 Authority Information Access . . . . . . . . . . . 45 + 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46 + 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48 + 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49 + 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50 + 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50 + + + +Housley, et. al. Standards Track [Page 2] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50 + 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51 + 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51 + 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52 + 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52 + 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52 + 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52 + 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53 + 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53 + 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53 + 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53 + 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54 + 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54 + 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55 + 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55 + 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58 + 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59 + 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60 + 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60 + 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61 + 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62 + 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62 + 6 Certificate Path Validation . . . . . . . . . . . . . . . 62 + 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63 + 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66 + 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67 + 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70 + 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75 + 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78 + 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80 + 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80 + 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81 + 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82 + 6.3.2 Initialization and Revocation State Variables . . . . 82 + 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83 + 7 References . . . . . . . . . . . . . . . . . . . . . . . 86 + 8 Intellectual Property Rights . . . . . . . . . . . . . . 88 + 9 Security Considerations . . . . . . . . . . . . . . . . . 89 + Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92 + A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92 + A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105 + Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112 + Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115 + C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115 + C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119 + C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122 + C.4 Certificate Revocation List . . . . . . . . . . . . . . 126 + Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128 + + + +Housley, et. al. Standards Track [Page 3] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Full Copyright Statement . . . . . . . . . . . . . . . . . . 129 + +1 Introduction + + This specification is one part of a family of standards for the X.509 + Public Key Infrastructure (PKI) for the Internet. + + This specification profiles the format and semantics of certificates + and certificate revocation lists (CRLs) for the Internet PKI. + Procedures are described for processing of certification paths in the + Internet environment. Finally, ASN.1 modules are provided in the + appendices for all data structures defined or referenced. + + Section 2 describes Internet PKI requirements, and the assumptions + which affect the scope of this document. Section 3 presents an + architectural model and describes its relationship to previous IETF + and ISO/IEC/ITU-T standards. In particular, this document's + relationship with the IETF PEM specifications and the ISO/IEC/ITU-T + X.509 documents are described. + + Section 4 profiles the X.509 version 3 certificate, and section 5 + profiles the X.509 version 2 CRL. The profiles include the + identification of ISO/IEC/ITU-T and ANSI extensions which may be + useful in the Internet PKI. The profiles are presented in the 1988 + Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 + syntax used in the most recent ISO/IEC/ITU-T standards. + + Section 6 includes certification path validation procedures. These + procedures are based upon the ISO/IEC/ITU-T definition. + Implementations are REQUIRED to derive the same results but are not + required to use the specified procedures. + + Procedures for identification and encoding of public key materials + and digital signatures are defined in [PKIXALGS]. Implementations of + this specification are not required to use any particular + cryptographic algorithms. However, conforming implementations which + use the algorithms identified in [PKIXALGS] MUST identify and encode + the public key materials and digital signatures as described in that + specification. + + Finally, three appendices are provided to aid implementers. Appendix + A contains all ASN.1 structures defined or referenced within this + specification. As above, the material is presented in the 1988 + ASN.1. Appendix B contains notes on less familiar features of the + ASN.1 notation used within this specification. Appendix C contains + examples of a conforming certificate and a conforming CRL. + + + + + +Housley, et. al. Standards Track [Page 4] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + This specification obsoletes RFC 2459. This specification differs + from RFC 2459 in five basic areas: + + * To promote interoperable implementations, a detailed algorithm + for certification path validation is included in section 6.1 of + this specification; RFC 2459 provided only a high-level + description of path validation. + + * An algorithm for determining the status of a certificate using + CRLs is provided in section 6.3 of this specification. This + material was not present in RFC 2459. + + * To accommodate new usage models, detailed information describing + the use of delta CRLs is provided in Section 5 of this + specification. + + * Identification and encoding of public key materials and digital + signatures are not included in this specification, but are now + described in a companion specification [PKIXALGS]. + + * Four additional extensions are specified: three certificate + extensions and one CRL extension. The certificate extensions are + subject info access, inhibit any-policy, and freshest CRL. The + freshest CRL extension is also defined as a CRL extension. + + * Throughout the specification, clarifications have been + introduced to enhance consistency with the ITU-T X.509 + specification. X.509 defines the certificate and CRL format as + well as many of the extensions that appear in this specification. + These changes were introduced to improve the likelihood of + interoperability between implementations based on this + specification with implementations based on the ITU-T + specification. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + +2 Requirements and Assumptions + + The goal of this specification is to develop a profile to facilitate + the use of X.509 certificates within Internet applications for those + communities wishing to make use of X.509 technology. Such + applications may include WWW, electronic mail, user authentication, + and IPsec. In order to relieve some of the obstacles to using X.509 + + + + + + +Housley, et. al. Standards Track [Page 5] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + certificates, this document defines a profile to promote the + development of certificate management systems; development of + application tools; and interoperability determined by policy. + + Some communities will need to supplement, or possibly replace, this + profile in order to meet the requirements of specialized application + domains or environments with additional authorization, assurance, or + operational requirements. However, for basic applications, common + representations of frequently used attributes are defined so that + application developers can obtain necessary information without + regard to the issuer of a particular certificate or certificate + revocation list (CRL). + + A certificate user should review the certificate policy generated by + the certification authority (CA) before relying on the authentication + or non-repudiation services associated with the public key in a + particular certificate. To this end, this standard does not + prescribe legally binding rules or duties. + + As supplemental authorization and attribute management tools emerge, + such as attribute certificates, it may be appropriate to limit the + authenticated attributes that are included in a certificate. These + other management tools may provide more appropriate methods of + conveying many authenticated attributes. + +2.1 Communication and Topology + + The users of certificates will operate in a wide range of + environments with respect to their communication topology, especially + users of secure electronic mail. This profile supports users without + high bandwidth, real-time IP connectivity, or high connection + availability. In addition, the profile allows for the presence of + firewall or other filtered communication. + + This profile does not assume the deployment of an X.500 Directory + system or a LDAP directory system. The profile does not prohibit the + use of an X.500 Directory or a LDAP directory; however, any means of + distributing certificates and certificate revocation lists (CRLs) may + be used. + +2.2 Acceptability Criteria + + The goal of the Internet Public Key Infrastructure (PKI) is to meet + the needs of deterministic, automated identification, authentication, + access control, and authorization functions. Support for these + services determines the attributes contained in the certificate as + well as the ancillary control information in the certificate such as + policy data and certification path constraints. + + + +Housley, et. al. Standards Track [Page 6] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +2.3 User Expectations + + Users of the Internet PKI are people and processes who use client + software and are the subjects named in certificates. These uses + include readers and writers of electronic mail, the clients for WWW + browsers, WWW servers, and the key manager for IPsec within a router. + This profile recognizes the limitations of the platforms these users + employ and the limitations in sophistication and attentiveness of the + users themselves. This manifests itself in minimal user + configuration responsibility (e.g., trusted CA keys, rules), explicit + platform usage constraints within the certificate, certification path + constraints which shield the user from many malicious actions, and + applications which sensibly automate validation functions. + +2.4 Administrator Expectations + + As with user expectations, the Internet PKI profile is structured to + support the individuals who generally operate CAs. Providing + administrators with unbounded choices increases the chances that a + subtle CA administrator mistake will result in broad compromise. + Also, unbounded choices greatly complicate the software that process + and validate the certificates created by the CA. + +3 Overview of Approach + + Following is a simplified view of the architectural model assumed by + the PKIX specifications. + + The components in this model are: + + end entity: user of PKI certificates and/or end user system that is + the subject of a certificate; + CA: certification authority; + RA: registration authority, i.e., an optional system to which + a CA delegates certain management functions; + CRL issuer: an optional system to which a CA delegates the + publication of certificate revocation lists; + repository: a system or collection of distributed systems that stores + certificates and CRLs and serves as a means of + distributing these certificates and CRLs to end entities. + + Note that an Attribute Authority (AA) might also choose to delegate + the publication of CRLs to a CRL issuer. + + + + + + + + +Housley, et. al. Standards Track [Page 7] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + +---+ + | C | +------------+ + | e | <-------------------->| End entity | + | r | Operational +------------+ + | t | transactions ^ + | i | and management | Management + | f | transactions | transactions PKI + | i | | users + | c | v + | a | ======================= +--+------------+ ============== + | t | ^ ^ + | e | | | PKI + | | v | management + | & | +------+ | entities + | | <---------------------| RA |<----+ | + | C | Publish certificate +------+ | | + | R | | | + | L | | | + | | v v + | R | +------------+ + | e | <------------------------------| CA | + | p | Publish certificate +------------+ + | o | Publish CRL ^ ^ + | s | | | Management + | i | +------------+ | | transactions + | t | <--------------| CRL Issuer |<----+ | + | o | Publish CRL +------------+ v + | r | +------+ + | y | | CA | + +---+ +------+ + + Figure 1 - PKI Entities + +3.1 X.509 Version 3 Certificate + + Users of a public key require confidence that the associated private + key is owned by the correct remote subject (person or system) with + which an encryption or digital signature mechanism will be used. + This confidence is obtained through the use of public key + certificates, which are data structures that bind public key values + to subjects. The binding is asserted by having a trusted CA + digitally sign each certificate. The CA may base this assertion upon + technical means (a.k.a., proof of possession through a challenge- + response protocol), presentation of the private key, or on an + assertion by the subject. A certificate has a limited valid lifetime + which is indicated in its signed contents. Because a certificate's + signature and timeliness can be independently checked by a + certificate-using client, certificates can be distributed via + + + +Housley, et. al. Standards Track [Page 8] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + untrusted communications and server systems, and can be cached in + unsecured storage in certificate-using systems. + + ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first + published in 1988 as part of the X.500 Directory recommendations, + defines a standard certificate format [X.509]. The certificate + format in the 1988 standard is called the version 1 (v1) format. + When X.500 was revised in 1993, two more fields were added, resulting + in the version 2 (v2) format. + + The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, + include specifications for a public key infrastructure based on X.509 + v1 certificates [RFC 1422]. The experience gained in attempts to + deploy RFC 1422 made it clear that the v1 and v2 certificate formats + are deficient in several respects. Most importantly, more fields + were needed to carry information which PEM design and implementation + experience had proven necessary. In response to these new + requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version + 3 (v3) certificate format. The v3 format extends the v2 format by + adding provision for additional extension fields. Particular + extension field types may be specified in standards or may be defined + and registered by any organization or community. In June 1996, + standardization of the basic v3 format was completed [X.509]. + + ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions + for use in the v3 extensions field [X.509][X9.55]. These extensions + can convey such data as additional subject identification + information, key attribute information, policy information, and + certification path constraints. + + However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very + broad in their applicability. In order to develop interoperable + implementations of X.509 v3 systems for Internet use, it is necessary + to specify a profile for use of the X.509 v3 extensions tailored for + the Internet. It is one goal of this document to specify a profile + for Internet WWW, electronic mail, and IPsec applications. + Environments with additional requirements may build on this profile + or may replace it. + +3.2 Certification Paths and Trust + + A user of a security service requiring knowledge of a public key + generally needs to obtain and validate a certificate containing the + required public key. If the public key user does not already hold an + assured copy of the public key of the CA that signed the certificate, + the CA's name, and related information (such as the validity period + or name constraints), then it might need an additional certificate to + obtain that public key. In general, a chain of multiple certificates + + + +Housley, et. al. Standards Track [Page 9] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + may be needed, comprising a certificate of the public key owner (the + end entity) signed by one CA, and zero or more additional + certificates of CAs signed by other CAs. Such chains, called + certification paths, are required because a public key user is only + initialized with a limited number of assured CA public keys. + + There are different ways in which CAs might be configured in order + for public key users to be able to find certification paths. For + PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There + are three types of PEM certification authority: + + (a) Internet Policy Registration Authority (IPRA): This + authority, operated under the auspices of the Internet Society, + acts as the root of the PEM certification hierarchy at level 1. + It issues certificates only for the next level of authorities, + PCAs. All certification paths start with the IPRA. + + (b) Policy Certification Authorities (PCAs): PCAs are at level 2 + of the hierarchy, each PCA being certified by the IPRA. A PCA + shall establish and publish a statement of its policy with respect + to certifying users or subordinate certification authorities. + Distinct PCAs aim to satisfy different user needs. For example, + one PCA (an organizational PCA) might support the general + electronic mail needs of commercial organizations, and another PCA + (a high-assurance PCA) might have a more stringent policy designed + for satisfying legally binding digital signature requirements. + + (c) Certification Authorities (CAs): CAs are at level 3 of the + hierarchy and can also be at lower levels. Those at level 3 are + certified by PCAs. CAs represent, for example, particular + organizations, particular organizational units (e.g., departments, + groups, sections), or particular geographical areas. + + RFC 1422 furthermore has a name subordination rule which requires + that a CA can only issue certificates for entities whose names are + subordinate (in the X.500 naming tree) to the name of the CA itself. + The trust associated with a PEM certification path is implied by the + PCA name. The name subordination rule ensures that CAs below the PCA + are sensibly constrained as to the set of subordinate entities they + can certify (e.g., a CA for an organization can only certify entities + in that organization's name tree). Certificate user systems are able + to mechanically check that the name subordination rule has been + followed. + + The RFC 1422 uses the X.509 v1 certificate formats. The limitations + of X.509 v1 required imposition of several structural restrictions to + clearly associate policy information or restrict the utility of + certificates. These restrictions included: + + + +Housley, et. al. Standards Track [Page 10] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (a) a pure top-down hierarchy, with all certification paths + starting from IPRA; + + (b) a naming subordination rule restricting the names of a CA's + subjects; and + + (c) use of the PCA concept, which requires knowledge of + individual PCAs to be built into certificate chain verification + logic. Knowledge of individual PCAs was required to determine if + a chain could be accepted. + + With X.509 v3, most of the requirements addressed by RFC 1422 can be + addressed using certificate extensions, without a need to restrict + the CA structures used. In particular, the certificate extensions + relating to certificate policies obviate the need for PCAs and the + constraint extensions obviate the need for the name subordination + rule. As a result, this document supports a more flexible + architecture, including: + + (a) Certification paths start with a public key of a CA in a + user's own domain, or with the public key of the top of a + hierarchy. Starting with the public key of a CA in a user's own + domain has certain advantages. In some environments, the local + domain is the most trusted. + + (b) Name constraints may be imposed through explicit inclusion of + a name constraints extension in a certificate, but are not + required. + + (c) Policy extensions and policy mappings replace the PCA + concept, which permits a greater degree of automation. The + application can determine if the certification path is acceptable + based on the contents of the certificates instead of a priori + knowledge of PCAs. This permits automation of certification path + processing. + +3.3 Revocation + + When a certificate is issued, it is expected to be in use for its + entire validity period. However, various circumstances may cause a + certificate to become invalid prior to the expiration of the validity + period. Such circumstances include change of name, change of + association between subject and CA (e.g., an employee terminates + employment with an organization), and compromise or suspected + compromise of the corresponding private key. Under such + circumstances, the CA needs to revoke the certificate. + + + + + +Housley, et. al. Standards Track [Page 11] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + X.509 defines one method of certificate revocation. This method + involves each CA periodically issuing a signed data structure called + a certificate revocation list (CRL). A CRL is a time stamped list + identifying revoked certificates which is signed by a CA or CRL + issuer and made freely available in a public repository. Each + revoked certificate is identified in a CRL by its certificate serial + number. When a certificate-using system uses a certificate (e.g., + for verifying a remote user's digital signature), that system not + only checks the certificate signature and validity but also acquires + a suitably-recent CRL and checks that the certificate serial number + is not on that CRL. The meaning of "suitably-recent" may vary with + local policy, but it usually means the most recently-issued CRL. A + new CRL is issued on a regular periodic basis (e.g., hourly, daily, + or weekly). An entry is added to the CRL as part of the next update + following notification of revocation. An entry MUST NOT be removed + from the CRL until it appears on one regularly scheduled CRL issued + beyond the revoked certificate's validity period. + + An advantage of this revocation method is that CRLs may be + distributed by exactly the same means as certificates themselves, + namely, via untrusted servers and untrusted communications. + + One limitation of the CRL revocation method, using untrusted + communications and servers, is that the time granularity of + revocation is limited to the CRL issue period. For example, if a + revocation is reported now, that revocation will not be reliably + notified to certificate-using systems until all currently issued CRLs + are updated -- this may be up to one hour, one day, or one week + depending on the frequency that CRLs are issued. + + As with the X.509 v3 certificate format, in order to facilitate + interoperable implementations from multiple vendors, the X.509 v2 CRL + format needs to be profiled for Internet use. It is one goal of this + document to specify that profile. However, this profile does not + require the issuance of CRLs. Message formats and protocols + supporting on-line revocation notification are defined in other PKIX + specifications. On-line methods of revocation notification may be + applicable in some environments as an alternative to the X.509 CRL. + On-line revocation checking may significantly reduce the latency + between a revocation report and the distribution of the information + to relying parties. Once the CA accepts a revocation report as + authentic and valid, any query to the on-line service will correctly + reflect the certificate validation impacts of the revocation. + However, these methods impose new security requirements: the + certificate validator needs to trust the on-line validation service + while the repository does not need to be trusted. + + + + + +Housley, et. al. Standards Track [Page 12] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +3.4 Operational Protocols + + Operational protocols are required to deliver certificates and CRLs + (or status information) to certificate using client systems. + Provisions are needed for a variety of different means of certificate + and CRL delivery, including distribution procedures based on LDAP, + HTTP, FTP, and X.500. Operational protocols supporting these + functions are defined in other PKIX specifications. These + specifications may include definitions of message formats and + procedures for supporting all of the above operational environments, + including definitions of or references to appropriate MIME content + types. + +3.5 Management Protocols + + Management protocols are required to support on-line interactions + between PKI user and management entities. For example, a management + protocol might be used between a CA and a client system with which a + key pair is associated, or between two CAs which cross-certify each + other. The set of functions which potentially need to be supported + by management protocols include: + + (a) registration: This is the process whereby a user first makes + itself known to a CA (directly, or through an RA), prior to that + CA issuing a certificate or certificates for that user. + + (b) initialization: Before a client system can operate securely + it is necessary to install key materials which have the + appropriate relationship with keys stored elsewhere in the + infrastructure. For example, the client needs to be securely + initialized with the public key and other assured information of + the trusted CA(s), to be used in validating certificate paths. + + Furthermore, a client typically needs to be initialized with its + own key pair(s). + + (c) certification: This is the process in which a CA issues a + certificate for a user's public key, and returns that certificate + to the user's client system and/or posts that certificate in a + repository. + + (d) key pair recovery: As an option, user client key materials + (e.g., a user's private key used for encryption purposes) may be + backed up by a CA or a key backup system. If a user needs to + recover these backed up key materials (e.g., as a result of a + forgotten password or a lost key chain file), an on-line protocol + exchange may be needed to support such recovery. + + + + +Housley, et. al. Standards Track [Page 13] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (e) key pair update: All key pairs need to be updated regularly, + i.e., replaced with a new key pair, and new certificates issued. + + (f) revocation request: An authorized person advises a CA of an + abnormal situation requiring certificate revocation. + + (g) cross-certification: Two CAs exchange information used in + establishing a cross-certificate. A cross-certificate is a + certificate issued by one CA to another CA which contains a CA + signature key used for issuing certificates. + + Note that on-line protocols are not the only way of implementing the + above functions. For all functions there are off-line methods of + achieving the same result, and this specification does not mandate + use of on-line protocols. For example, when hardware tokens are + used, many of the functions may be achieved as part of the physical + token delivery. Furthermore, some of the above functions may be + combined into one protocol exchange. In particular, two or more of + the registration, initialization, and certification functions can be + combined into one protocol exchange. + + The PKIX series of specifications defines a set of standard message + formats supporting the above functions. The protocols for conveying + these messages in different environments (e.g., e-mail, file + transfer, and WWW) are described in those specifications. + +4 Certificate and Certificate Extensions Profile + + This section presents a profile for public key certificates that will + foster interoperability and a reusable PKI. This section is based + upon the X.509 v3 certificate format and the standard certificate + extensions defined in [X.509]. The ISO/IEC and ITU-T documents use + the 1997 version of ASN.1; while this document uses the 1988 ASN.1 + syntax, the encoded certificate and standard extensions are + equivalent. This section also defines private extensions required to + support a PKI for the Internet community. + + Certificates may be used in a wide range of applications and + environments covering a broad spectrum of interoperability goals and + a broader spectrum of operational and assurance requirements. The + goal of this document is to establish a common baseline for generic + applications requiring broad interoperability and limited special + purpose requirements. In particular, the emphasis will be on + supporting the use of X.509 v3 certificates for informal Internet + electronic mail, IPsec, and WWW applications. + + + + + + +Housley, et. al. Standards Track [Page 14] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.1 Basic Certificate Fields + + The X.509 v3 certificate basic syntax is as follows. For signature + calculation, the data that is to be signed is encoded using the ASN.1 + distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a + tag, length, value encoding system for each element. + + Certificate ::= SEQUENCE { + tbsCertificate TBSCertificate, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING } + + TBSCertificate ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + serialNumber CertificateSerialNumber, + signature AlgorithmIdentifier, + issuer Name, + validity Validity, + subject Name, + subjectPublicKeyInfo SubjectPublicKeyInfo, + issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, + -- If present, version MUST be v2 or v3 + subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, + -- If present, version MUST be v2 or v3 + extensions [3] EXPLICIT Extensions OPTIONAL + -- If present, version MUST be v3 + } + + Version ::= INTEGER { v1(0), v2(1), v3(2) } + + CertificateSerialNumber ::= INTEGER + + Validity ::= SEQUENCE { + notBefore Time, + notAfter Time } + + Time ::= CHOICE { + utcTime UTCTime, + generalTime GeneralizedTime } + + UniqueIdentifier ::= BIT STRING + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING } + + Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension + + + + +Housley, et. al. Standards Track [Page 15] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Extension ::= SEQUENCE { + extnID OBJECT IDENTIFIER, + critical BOOLEAN DEFAULT FALSE, + extnValue OCTET STRING } + + The following items describe the X.509 v3 certificate for use in the + Internet. + +4.1.1 Certificate Fields + + The Certificate is a SEQUENCE of three required fields. The fields + are described in detail in the following subsections. + +4.1.1.1 tbsCertificate + + The field contains the names of the subject and issuer, a public key + associated with the subject, a validity period, and other associated + information. The fields are described in detail in section 4.1.2; + the tbsCertificate usually includes extensions which are described in + section 4.2. + +4.1.1.2 signatureAlgorithm + + The signatureAlgorithm field contains the identifier for the + cryptographic algorithm used by the CA to sign this certificate. + [PKIXALGS] lists supported signature algorithms, but other signature + algorithms MAY also be supported. + + An algorithm identifier is defined by the following ASN.1 structure: + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + parameters ANY DEFINED BY algorithm OPTIONAL } + + The algorithm identifier is used to identify a cryptographic + algorithm. The OBJECT IDENTIFIER component identifies the algorithm + (such as DSA with SHA-1). The contents of the optional parameters + field will vary according to the algorithm identified. + + This field MUST contain the same algorithm identifier as the + signature field in the sequence tbsCertificate (section 4.1.2.3). + +4.1.1.3 signatureValue + + The signatureValue field contains a digital signature computed upon + the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded + tbsCertificate is used as the input to the signature function. This + + + + +Housley, et. al. Standards Track [Page 16] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + signature value is encoded as a BIT STRING and included in the + signature field. The details of this process are specified for each + of algorithms listed in [PKIXALGS]. + + By generating this signature, a CA certifies the validity of the + information in the tbsCertificate field. In particular, the CA + certifies the binding between the public key material and the subject + of the certificate. + +4.1.2 TBSCertificate + + The sequence TBSCertificate contains information associated with the + subject of the certificate and the CA who issued it. Every + TBSCertificate contains the names of the subject and issuer, a public + key associated with the subject, a validity period, a version number, + and a serial number; some MAY contain optional unique identifier + fields. The remainder of this section describes the syntax and + semantics of these fields. A TBSCertificate usually includes + extensions. Extensions for the Internet PKI are described in Section + 4.2. + +4.1.2.1 Version + + This field describes the version of the encoded certificate. When + extensions are used, as expected in this profile, version MUST be 3 + (value is 2). If no extensions are present, but a UniqueIdentifier + is present, the version SHOULD be 2 (value is 1); however version MAY + be 3. If only basic fields are present, the version SHOULD be 1 (the + value is omitted from the certificate as the default value); however + the version MAY be 2 or 3. + + Implementations SHOULD be prepared to accept any version certificate. + At a minimum, conforming implementations MUST recognize version 3 + certificates. + + Generation of version 2 certificates is not expected by + implementations based on this profile. + +4.1.2.2 Serial number + + The serial number MUST be a positive integer assigned by the CA to + each certificate. It MUST be unique for each certificate issued by a + given CA (i.e., the issuer name and serial number identify a unique + certificate). CAs MUST force the serialNumber to be a non-negative + integer. + + + + + + +Housley, et. al. Standards Track [Page 17] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Given the uniqueness requirements above, serial numbers can be + expected to contain long integers. Certificate users MUST be able to + handle serialNumber values up to 20 octets. Conformant CAs MUST NOT + use serialNumber values longer than 20 octets. + + Note: Non-conforming CAs may issue certificates with serial numbers + that are negative, or zero. Certificate users SHOULD be prepared to + gracefully handle such certificates. + +4.1.2.3 Signature + + This field contains the algorithm identifier for the algorithm used + by the CA to sign the certificate. + + This field MUST contain the same algorithm identifier as the + signatureAlgorithm field in the sequence Certificate (section + 4.1.1.2). The contents of the optional parameters field will vary + according to the algorithm identified. [PKIXALGS] lists the + supported signature algorithms, but other signature algorithms MAY + also be supported. + +4.1.2.4 Issuer + + The issuer field identifies the entity who has signed and issued the + certificate. The issuer field MUST contain a non-empty distinguished + name (DN). The issuer field is defined as the X.501 type Name + [X.501]. Name is defined by the following ASN.1 structures: + + Name ::= CHOICE { + RDNSequence } + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + RelativeDistinguishedName ::= + SET OF AttributeTypeAndValue + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue } + + AttributeType ::= OBJECT IDENTIFIER + + AttributeValue ::= ANY DEFINED BY AttributeType + + + + + + + + +Housley, et. al. Standards Track [Page 18] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + DirectoryString ::= CHOICE { + teletexString TeletexString (SIZE (1..MAX)), + printableString PrintableString (SIZE (1..MAX)), + universalString UniversalString (SIZE (1..MAX)), + utf8String UTF8String (SIZE (1..MAX)), + bmpString BMPString (SIZE (1..MAX)) } + + The Name describes a hierarchical name composed of attributes, such + as country name, and corresponding values, such as US. The type of + the component AttributeValue is determined by the AttributeType; in + general it will be a DirectoryString. + + The DirectoryString type is defined as a choice of PrintableString, + TeletexString, BMPString, UTF8String, and UniversalString. The + UTF8String encoding [RFC 2279] is the preferred encoding, and all + certificates issued after December 31, 2003 MUST use the UTF8String + encoding of DirectoryString (except as noted below). Until that + date, conforming CAs MUST choose from the following options when + creating a distinguished name, including their own: + + (a) if the character set is sufficient, the string MAY be + represented as a PrintableString; + + (b) failing (a), if the BMPString character set is sufficient the + string MAY be represented as a BMPString; and + + (c) failing (a) and (b), the string MUST be represented as a + UTF8String. If (a) or (b) is satisfied, the CA MAY still choose + to represent the string as a UTF8String. + + Exceptions to the December 31, 2003 UTF8 encoding requirements are as + follows: + + (a) CAs MAY issue "name rollover" certificates to support an + orderly migration to UTF8String encoding. Such certificates would + include the CA's UTF8String encoded name as issuer and and the old + name encoding as subject, or vice-versa. + + (b) As stated in section 4.1.2.6, the subject field MUST be + populated with a non-empty distinguished name matching the + contents of the issuer field in all certificates issued by the + subject CA regardless of encoding. + + The TeletexString and UniversalString are included for backward + compatibility, and SHOULD NOT be used for certificates for new + subjects. However, these types MAY be used in certificates where the + name was previously established. Certificate users SHOULD be + prepared to receive certificates with these types. + + + +Housley, et. al. Standards Track [Page 19] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + In addition, many legacy implementations support names encoded in the + ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as + TeletexString. TeletexString encodes a larger character set than ISO + 8859-1, but it encodes some characters differently. Implementations + SHOULD be prepared to handle both encodings. + + As noted above, distinguished names are composed of attributes. This + specification does not restrict the set of attribute types that may + appear in names. However, conforming implementations MUST be + prepared to receive certificates with issuer names containing the set + of attribute types defined below. This specification RECOMMENDS + support for additional attribute types. + + Standard sets of attributes have been defined in the X.500 series of + specifications [X.520]. Implementations of this specification MUST + be prepared to receive the following standard attribute types in + issuer and subject (section 4.1.2.6) names: + + * country, + * organization, + * organizational-unit, + * distinguished name qualifier, + * state or province name, + * common name (e.g., "Susan Housley"), and + * serial number. + + In addition, implementations of this specification SHOULD be prepared + to receive the following standard attribute types in issuer and + subject names: + + * locality, + * title, + * surname, + * given name, + * initials, + * pseudonym, and + * generation qualifier (e.g., "Jr.", "3rd", or "IV"). + + The syntax and associated object identifiers (OIDs) for these + attribute types are provided in the ASN.1 modules in Appendix A. + + In addition, implementations of this specification MUST be prepared + to receive the domainComponent attribute, as defined in [RFC 2247]. + The Domain Name System (DNS) provides a hierarchical resource + labeling system. This attribute provides a convenient mechanism for + organizations that wish to use DNs that parallel their DNS names. + This is not a replacement for the dNSName component of the + + + + +Housley, et. al. Standards Track [Page 20] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + alternative name field. Implementations are not required to convert + such names into DNS names. The syntax and associated OID for this + attribute type is provided in the ASN.1 modules in Appendix A. + + Certificate users MUST be prepared to process the issuer + distinguished name and subject distinguished name (section 4.1.2.6) + fields to perform name chaining for certification path validation + (section 6). Name chaining is performed by matching the issuer + distinguished name in one certificate with the subject name in a CA + certificate. + + This specification requires only a subset of the name comparison + functionality specified in the X.500 series of specifications. + Conforming implementations are REQUIRED to implement the following + name comparison rules: + + (a) attribute values encoded in different types (e.g., + PrintableString and BMPString) MAY be assumed to represent + different strings; + + (b) attribute values in types other than PrintableString are case + sensitive (this permits matching of attribute values as binary + objects); + + (c) attribute values in PrintableString are not case sensitive + (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and + + (d) attribute values in PrintableString are compared after + removing leading and trailing white space and converting internal + substrings of one or more consecutive white space characters to a + single space. + + These name comparison rules permit a certificate user to validate + certificates issued using languages or encodings unfamiliar to the + certificate user. + + In addition, implementations of this specification MAY use these + comparison rules to process unfamiliar attribute types for name + chaining. This allows implementations to process certificates with + unfamiliar attributes in the issuer name. + + Note that the comparison rules defined in the X.500 series of + specifications indicate that the character sets used to encode data + in distinguished names are irrelevant. The characters themselves are + compared without regard to encoding. Implementations of this profile + are permitted to use the comparison algorithm defined in the X.500 + series. Such an implementation will recognize a superset of name + matches recognized by the algorithm specified above. + + + +Housley, et. al. Standards Track [Page 21] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.1.2.5 Validity + + The certificate validity period is the time interval during which the + CA warrants that it will maintain information about the status of the + certificate. The field is represented as a SEQUENCE of two dates: + the date on which the certificate validity period begins (notBefore) + and the date on which the certificate validity period ends + (notAfter). Both notBefore and notAfter may be encoded as UTCTime or + GeneralizedTime. + + CAs conforming to this profile MUST always encode certificate + validity dates through the year 2049 as UTCTime; certificate validity + dates in 2050 or later MUST be encoded as GeneralizedTime. + + The validity period for a certificate is the period of time from + notBefore through notAfter, inclusive. + +4.1.2.5.1 UTCTime + + The universal time type, UTCTime, is a standard ASN.1 type intended + for representation of dates and time. UTCTime specifies the year + through the two low order digits and time is specified to the + precision of one minute or one second. UTCTime includes either Z + (for Zulu, or Greenwich Mean Time) or a time differential. + + For the purposes of this profile, UTCTime values MUST be expressed + Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are + YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming + systems MUST interpret the year field (YY) as follows: + + Where YY is greater than or equal to 50, the year SHALL be + interpreted as 19YY; and + + Where YY is less than 50, the year SHALL be interpreted as 20YY. + +4.1.2.5.2 GeneralizedTime + + The generalized time type, GeneralizedTime, is a standard ASN.1 type + for variable precision representation of time. Optionally, the + GeneralizedTime field can include a representation of the time + differential between local and Greenwich Mean Time. + + For the purposes of this profile, GeneralizedTime values MUST be + expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., + times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. + GeneralizedTime values MUST NOT include fractional seconds. + + + + + +Housley, et. al. Standards Track [Page 22] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.1.2.6 Subject + + The subject field identifies the entity associated with the public + key stored in the subject public key field. The subject name MAY be + carried in the subject field and/or the subjectAltName extension. If + the subject is a CA (e.g., the basic constraints extension, as + discussed in 4.2.1.10, is present and the value of cA is TRUE), then + the subject field MUST be populated with a non-empty distinguished + name matching the contents of the issuer field (section 4.1.2.4) in + all certificates issued by the subject CA. If the subject is a CRL + issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is + present and the value of cRLSign is TRUE) then the subject field MUST + be populated with a non-empty distinguished name matching the + contents of the issuer field (section 4.1.2.4) in all CRLs issued by + the subject CRL issuer. If subject naming information is present + only in the subjectAltName extension (e.g., a key bound only to an + email address or URI), then the subject name MUST be an empty + sequence and the subjectAltName extension MUST be critical. + + Where it is non-empty, the subject field MUST contain an X.500 + distinguished name (DN). The DN MUST be unique for each subject + entity certified by the one CA as defined by the issuer name field. + A CA MAY issue more than one certificate with the same DN to the same + subject entity. + + The subject name field is defined as the X.501 type Name. + Implementation requirements for this field are those defined for the + issuer field (section 4.1.2.4). When encoding attribute values of + type DirectoryString, the encoding rules for the issuer field MUST be + implemented. Implementations of this specification MUST be prepared + to receive subject names containing the attribute types required for + the issuer field. Implementations of this specification SHOULD be + prepared to receive subject names containing the recommended + attribute types for the issuer field. The syntax and associated + object identifiers (OIDs) for these attribute types are provided in + the ASN.1 modules in Appendix A. Implementations of this + specification MAY use these comparison rules to process unfamiliar + attribute types (i.e., for name chaining). This allows + implementations to process certificates with unfamiliar attributes in + the subject name. + + In addition, legacy implementations exist where an RFC 822 name is + embedded in the subject distinguished name as an EmailAddress + attribute. The attribute value for EmailAddress is of type IA5String + to permit inclusion of the character '@', which is not part of the + PrintableString character set. EmailAddress attribute values are not + case sensitive (e.g., "fanfeedback@redsox.com" is the same as + "FANFEEDBACK@REDSOX.COM"). + + + +Housley, et. al. Standards Track [Page 23] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Conforming implementations generating new certificates with + electronic mail addresses MUST use the rfc822Name in the subject + alternative name field (section 4.2.1.7) to describe such identities. + Simultaneous inclusion of the EmailAddress attribute in the subject + distinguished name to support legacy implementations is deprecated + but permitted. + +4.1.2.7 Subject Public Key Info + + This field is used to carry the public key and identify the algorithm + with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The + algorithm is identified using the AlgorithmIdentifier structure + specified in section 4.1.1.2. The object identifiers for the + supported algorithms and the methods for encoding the public key + materials (public key and parameters) are specified in [PKIXALGS]. + +4.1.2.8 Unique Identifiers + + These fields MUST only appear if the version is 2 or 3 (section + 4.1.2.1). These fields MUST NOT appear if the version is 1. The + subject and issuer unique identifiers are present in the certificate + to handle the possibility of reuse of subject and/or issuer names + over time. This profile RECOMMENDS that names not be reused for + different entities and that Internet certificates not make use of + unique identifiers. CAs conforming to this profile SHOULD NOT + generate certificates with unique identifiers. Applications + conforming to this profile SHOULD be capable of parsing unique + identifiers. + +4.1.2.9 Extensions + + This field MUST only appear if the version is 3 (section 4.1.2.1). + If present, this field is a SEQUENCE of one or more certificate + extensions. The format and content of certificate extensions in the + Internet PKI is defined in section 4.2. + +4.2 Certificate Extensions + + The extensions defined for X.509 v3 certificates provide methods for + associating additional attributes with users or public keys and for + managing a certification hierarchy. The X.509 v3 certificate format + also allows communities to define private extensions to carry + information unique to those communities. Each extension in a + certificate is designated as either critical or non-critical. A + certificate using system MUST reject the certificate if it encounters + a critical extension it does not recognize; however, a non-critical + extension MAY be ignored if it is not recognized. The following + sections present recommended extensions used within Internet + + + +Housley, et. al. Standards Track [Page 24] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + certificates and standard locations for information. Communities may + elect to use additional extensions; however, caution ought to be + exercised in adopting any critical extensions in certificates which + might prevent use in a general context. + + Each extension includes an OID and an ASN.1 structure. When an + extension appears in a certificate, the OID appears as the field + extnID and the corresponding ASN.1 encoded structure is the value of + the octet string extnValue. A certificate MUST NOT include more than + one instance of a particular extension. For example, a certificate + may contain only one authority key identifier extension (section + 4.2.1.1). An extension includes the boolean critical, with a default + value of FALSE. The text for each extension specifies the acceptable + values for the critical field. + + Conforming CAs MUST support key identifiers (sections 4.2.1.1 and + 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section + 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If + the CA issues certificates with an empty sequence for the subject + field, the CA MUST support the subject alternative name extension + (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. + Conforming CAs MAY support extensions that are not identified within + this specification; certificate issuers are cautioned that marking + such extensions as critical may inhibit interoperability. + + At a minimum, applications conforming to this profile MUST recognize + the following extensions: key usage (section 4.2.1.3), certificate + policies (section 4.2.1.5), the subject alternative name (section + 4.2.1.7), basic constraints (section 4.2.1.10), name constraints + (section 4.2.1.11), policy constraints (section 4.2.1.12), extended + key usage (section 4.2.1.13), and inhibit any-policy (section + 4.2.1.15). + + In addition, applications conforming to this profile SHOULD recognize + the authority and subject key identifier (sections 4.2.1.1 and + 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. + +4.2.1 Standard Extensions + + This section identifies standard certificate extensions defined in + [X.509] for use in the Internet PKI. Each extension is associated + with an OID defined in [X.509]. These OIDs are members of the id-ce + arc, which is defined by the following: + + id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } + + + + + + +Housley, et. al. Standards Track [Page 25] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.2.1.1 Authority Key Identifier + + The authority key identifier extension provides a means of + identifying the public key corresponding to the private key used to + sign a certificate. This extension is used where an issuer has + multiple signing keys (either due to multiple concurrent key pairs or + due to changeover). The identification MAY be based on either the + key identifier (the subject key identifier in the issuer's + certificate) or on the issuer name and serial number. + + The keyIdentifier field of the authorityKeyIdentifier extension MUST + be included in all certificates generated by conforming CAs to + facilitate certification path construction. There is one exception; + where a CA distributes its public key in the form of a "self-signed" + certificate, the authority key identifier MAY be omitted. The + signature on a self-signed certificate is generated with the private + key associated with the certificate's subject public key. (This + proves that the issuer possesses both the public and private keys.) + In this case, the subject and authority key identifiers would be + identical, but only the subject key identifier is needed for + certification path building. + + The value of the keyIdentifier field SHOULD be derived from the + public key used to verify the certificate's signature or a method + that generates unique values. Two common methods for generating key + identifiers from the public key, and one common method for generating + unique values, are described in section 4.2.1.2. Where a key + identifier has not been previously established, this specification + RECOMMENDS use of one of these methods for generating keyIdentifiers. + Where a key identifier has been previously established, the CA SHOULD + use the previously established identifier. + + This profile RECOMMENDS support for the key identifier method by all + certificate users. + + This extension MUST NOT be marked critical. + + id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } + + AuthorityKeyIdentifier ::= SEQUENCE { + keyIdentifier [0] KeyIdentifier OPTIONAL, + authorityCertIssuer [1] GeneralNames OPTIONAL, + authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } + + KeyIdentifier ::= OCTET STRING + + + + + + +Housley, et. al. Standards Track [Page 26] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.2.1.2 Subject Key Identifier + + The subject key identifier extension provides a means of identifying + certificates that contain a particular public key. + + To facilitate certification path construction, this extension MUST + appear in all conforming CA certificates, that is, all certificates + including the basic constraints extension (section 4.2.1.10) where + the value of cA is TRUE. The value of the subject key identifier + MUST be the value placed in the key identifier field of the Authority + Key Identifier extension (section 4.2.1.1) of certificates issued by + the subject of this certificate. + + For CA certificates, subject key identifiers SHOULD be derived from + the public key or a method that generates unique values. Two common + methods for generating key identifiers from the public key are: + + (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the + value of the BIT STRING subjectPublicKey (excluding the tag, + length, and number of unused bits). + + (2) The keyIdentifier is composed of a four bit type field with + the value 0100 followed by the least significant 60 bits of the + SHA-1 hash of the value of the BIT STRING subjectPublicKey + (excluding the tag, length, and number of unused bit string bits). + + One common method for generating unique values is a monotonically + increasing sequence of integers. + + For end entity certificates, the subject key identifier extension + provides a means for identifying certificates containing the + particular public key used in an application. Where an end entity + has obtained multiple certificates, especially from multiple CAs, the + subject key identifier provides a means to quickly identify the set + of certificates containing a particular public key. To assist + applications in identifying the appropriate end entity certificate, + this extension SHOULD be included in all end entity certificates. + + For end entity certificates, subject key identifiers SHOULD be + derived from the public key. Two common methods for generating key + identifiers from the public key are identified above. + + Where a key identifier has not been previously established, this + specification RECOMMENDS use of one of these methods for generating + keyIdentifiers. Where a key identifier has been previously + established, the CA SHOULD use the previously established identifier. + + This extension MUST NOT be marked critical. + + + +Housley, et. al. Standards Track [Page 27] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } + + SubjectKeyIdentifier ::= KeyIdentifier + +4.2.1.3 Key Usage + + The key usage extension defines the purpose (e.g., encipherment, + signature, certificate signing) of the key contained in the + certificate. The usage restriction might be employed when a key that + could be used for more than one operation is to be restricted. For + example, when an RSA key should be used only to verify signatures on + objects other than public key certificates and CRLs, the + digitalSignature and/or nonRepudiation bits would be asserted. + Likewise, when an RSA key should be used only for key management, the + keyEncipherment bit would be asserted. + + This extension MUST appear in certificates that contain public keys + that are used to validate digital signatures on other public key + certificates or CRLs. When this extension appears, it SHOULD be + marked critical. + + id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } + + KeyUsage ::= BIT STRING { + digitalSignature (0), + nonRepudiation (1), + keyEncipherment (2), + dataEncipherment (3), + keyAgreement (4), + keyCertSign (5), + cRLSign (6), + encipherOnly (7), + decipherOnly (8) } + + Bits in the KeyUsage type are used as follows: + + The digitalSignature bit is asserted when the subject public key + is used with a digital signature mechanism to support security + services other than certificate signing (bit 5), or CRL signing + (bit 6). Digital signature mechanisms are often used for entity + authentication and data origin authentication with integrity. + + The nonRepudiation bit is asserted when the subject public key is + used to verify digital signatures used to provide a non- + repudiation service which protects against the signing entity + falsely denying some action, excluding certificate or CRL signing. + In the case of later conflict, a reliable third party may + determine the authenticity of the signed data. + + + +Housley, et. al. Standards Track [Page 28] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Further distinctions between the digitalSignature and + nonRepudiation bits may be provided in specific certificate + policies. + + The keyEncipherment bit is asserted when the subject public key is + used for key transport. For example, when an RSA key is to be + used for key management, then this bit is set. + + The dataEncipherment bit is asserted when the subject public key + is used for enciphering user data, other than cryptographic keys. + + The keyAgreement bit is asserted when the subject public key is + used for key agreement. For example, when a Diffie-Hellman key is + to be used for key management, then this bit is set. + + The keyCertSign bit is asserted when the subject public key is + used for verifying a signature on public key certificates. If the + keyCertSign bit is asserted, then the cA bit in the basic + constraints extension (section 4.2.1.10) MUST also be asserted. + + The cRLSign bit is asserted when the subject public key is used + for verifying a signature on certificate revocation list (e.g., a + CRL, delta CRL, or an ARL). This bit MUST be asserted in + certificates that are used to verify signatures on CRLs. + + The meaning of the encipherOnly bit is undefined in the absence of + the keyAgreement bit. When the encipherOnly bit is asserted and + the keyAgreement bit is also set, the subject public key may be + used only for enciphering data while performing key agreement. + + The meaning of the decipherOnly bit is undefined in the absence of + the keyAgreement bit. When the decipherOnly bit is asserted and + the keyAgreement bit is also set, the subject public key may be + used only for deciphering data while performing key agreement. + + This profile does not restrict the combinations of bits that may be + set in an instantiation of the keyUsage extension. However, + appropriate values for keyUsage extensions for particular algorithms + are specified in [PKIXALGS]. + +4.2.1.4 Private Key Usage Period + + This extension SHOULD NOT be used within the Internet PKI. CAs + conforming to this profile MUST NOT generate certificates that + include a critical private key usage period extension. + + + + + + +Housley, et. al. Standards Track [Page 29] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + The private key usage period extension allows the certificate issuer + to specify a different validity period for the private key than the + certificate. This extension is intended for use with digital + signature keys. This extension consists of two optional components, + notBefore and notAfter. The private key associated with the + certificate SHOULD NOT be used to sign objects before or after the + times specified by the two components, respectively. CAs conforming + to this profile MUST NOT generate certificates with private key usage + period extensions unless at least one of the two components is + present and the extension is non-critical. + + Where used, notBefore and notAfter are represented as GeneralizedTime + and MUST be specified and interpreted as defined in section + 4.1.2.5.2. + + id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } + + PrivateKeyUsagePeriod ::= SEQUENCE { + notBefore [0] GeneralizedTime OPTIONAL, + notAfter [1] GeneralizedTime OPTIONAL } + +4.2.1.5 Certificate Policies + + The certificate policies extension contains a sequence of one or more + policy information terms, each of which consists of an object + identifier (OID) and optional qualifiers. Optional qualifiers, which + MAY be present, are not expected to change the definition of the + policy. + + In an end entity certificate, these policy information terms indicate + the policy under which the certificate has been issued and the + purposes for which the certificate may be used. In a CA certificate, + these policy information terms limit the set of policies for + certification paths which include this certificate. When a CA does + not wish to limit the set of policies for certification paths which + include this certificate, it MAY assert the special policy anyPolicy, + with a value of { 2 5 29 32 0 }. + + Applications with specific policy requirements are expected to have a + list of those policies which they will accept and to compare the + policy OIDs in the certificate to that list. If this extension is + critical, the path validation software MUST be able to interpret this + extension (including the optional qualifier), or MUST reject the + certificate. + + To promote interoperability, this profile RECOMMENDS that policy + information terms consist of only an OID. Where an OID alone is + insufficient, this profile strongly recommends that use of qualifiers + + + +Housley, et. al. Standards Track [Page 30] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + be limited to those identified in this section. When qualifiers are + used with the special policy anyPolicy, they MUST be limited to the + qualifiers identified in this section. + + This specification defines two policy qualifier types for use by + certificate policy writers and certificate issuers. The qualifier + types are the CPS Pointer and User Notice qualifiers. + + The CPS Pointer qualifier contains a pointer to a Certification + Practice Statement (CPS) published by the CA. The pointer is in the + form of a URI. Processing requirements for this qualifier are a + local matter. No action is mandated by this specification regardless + of the criticality value asserted for the extension. + + User notice is intended for display to a relying party when a + certificate is used. The application software SHOULD display all + user notices in all certificates of the certification path used, + except that if a notice is duplicated only one copy need be + displayed. To prevent such duplication, this qualifier SHOULD only + be present in end entity certificates and CA certificates issued to + other organizations. + + The user notice has two optional fields: the noticeRef field and the + explicitText field. + + The noticeRef field, if used, names an organization and + identifies, by number, a particular textual statement prepared by + that organization. For example, it might identify the + organization "CertsRUs" and notice number 1. In a typical + implementation, the application software will have a notice file + containing the current set of notices for CertsRUs; the + application will extract the notice text from the file and display + it. Messages MAY be multilingual, allowing the software to select + the particular language message for its own environment. + + An explicitText field includes the textual statement directly in + the certificate. The explicitText field is a string with a + maximum size of 200 characters. + + If both the noticeRef and explicitText options are included in the + one qualifier and if the application software can locate the notice + text indicated by the noticeRef option, then that text SHOULD be + displayed; otherwise, the explicitText string SHOULD be displayed. + + Note: While the explicitText has a maximum size of 200 characters, + some non-conforming CAs exceed this limit. Therefore, certificate + users SHOULD gracefully handle explicitText with more than 200 + characters. + + + +Housley, et. al. Standards Track [Page 31] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } + + anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } + + certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation + + PolicyInformation ::= SEQUENCE { + policyIdentifier CertPolicyId, + policyQualifiers SEQUENCE SIZE (1..MAX) OF + PolicyQualifierInfo OPTIONAL } + + CertPolicyId ::= OBJECT IDENTIFIER + + PolicyQualifierInfo ::= SEQUENCE { + policyQualifierId PolicyQualifierId, + qualifier ANY DEFINED BY policyQualifierId } + + -- policyQualifierIds for Internet policy qualifiers + + id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } + id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } + id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } + + PolicyQualifierId ::= + OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) + + Qualifier ::= CHOICE { + cPSuri CPSuri, + userNotice UserNotice } + + CPSuri ::= IA5String + + UserNotice ::= SEQUENCE { + noticeRef NoticeReference OPTIONAL, + explicitText DisplayText OPTIONAL} + + NoticeReference ::= SEQUENCE { + organization DisplayText, + noticeNumbers SEQUENCE OF INTEGER } + + DisplayText ::= CHOICE { + ia5String IA5String (SIZE (1..200)), + visibleString VisibleString (SIZE (1..200)), + bmpString BMPString (SIZE (1..200)), + utf8String UTF8String (SIZE (1..200)) } + + + + + + +Housley, et. al. Standards Track [Page 32] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.2.1.6 Policy Mappings + + This extension is used in CA certificates. It lists one or more + pairs of OIDs; each pair includes an issuerDomainPolicy and a + subjectDomainPolicy. The pairing indicates the issuing CA considers + its issuerDomainPolicy equivalent to the subject CA's + subjectDomainPolicy. + + The issuing CA's users might accept an issuerDomainPolicy for certain + applications. The policy mapping defines the list of policies + associated with the subject CA that may be accepted as comparable to + the issuerDomainPolicy. + + Each issuerDomainPolicy named in the policy mapping extension SHOULD + also be asserted in a certificate policies extension in the same + certificate. Policies SHOULD NOT be mapped either to or from the + special value anyPolicy (section 4.2.1.5). + + This extension MAY be supported by CAs and/or applications, and it + MUST be non-critical. + + id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } + + PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + issuerDomainPolicy CertPolicyId, + subjectDomainPolicy CertPolicyId } + +4.2.1.7 Subject Alternative Name + + The subject alternative names extension allows additional identities + to be bound to the subject of the certificate. Defined options + include an Internet electronic mail address, a DNS name, an IP + address, and a uniform resource identifier (URI). Other options + exist, including completely local definitions. Multiple name forms, + and multiple instances of each name form, MAY be included. Whenever + such identities are to be bound into a certificate, the subject + alternative name (or issuer alternative name) extension MUST be used; + however, a DNS name MAY be represented in the subject field using the + domainComponent attribute as described in section 4.1.2.4. + + Because the subject alternative name is considered to be definitively + bound to the public key, all parts of the subject alternative name + MUST be verified by the CA. + + Further, if the only subject identity included in the certificate is + an alternative name form (e.g., an electronic mail address), then the + subject distinguished name MUST be empty (an empty sequence), and the + + + + +Housley, et. al. Standards Track [Page 33] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + subjectAltName extension MUST be present. If the subject field + contains an empty sequence, the subjectAltName extension MUST be + marked critical. + + When the subjectAltName extension contains an Internet mail address, + the address MUST be included as an rfc822Name. The format of an + rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An + addr-spec has the form "local-part@domain". Note that an addr-spec + has no phrase (such as a common name) before it, has no comment (text + surrounded in parentheses) after it, and is not surrounded by "<" and + ">". Note that while upper and lower case letters are allowed in an + RFC 822 addr-spec, no significance is attached to the case. + + When the subjectAltName extension contains a iPAddress, the address + MUST be stored in the octet string in "network byte order," as + specified in RFC 791 [RFC 791]. The least significant bit (LSB) of + each octet is the LSB of the corresponding byte in the network + address. For IP Version 4, as specified in RFC 791, the octet string + MUST contain exactly four octets. For IP Version 6, as specified in + RFC 1883, the octet string MUST contain exactly sixteen octets [RFC + 1883]. + + When the subjectAltName extension contains a domain name system + label, the domain name MUST be stored in the dNSName (an IA5String). + The name MUST be in the "preferred name syntax," as specified by RFC + 1034 [RFC 1034]. Note that while upper and lower case letters are + allowed in domain names, no signifigance is attached to the case. In + addition, while the string " " is a legal domain name, subjectAltName + extensions with a dNSName of " " MUST NOT be used. Finally, the use + of the DNS representation for Internet mail addresses (wpolk.nist.gov + instead of wpolk@nist.gov) MUST NOT be used; such identities are to + be encoded as rfc822Name. + + Note: work is currently underway to specify domain names in + international character sets. Such names will likely not be + accommodated by IA5String. Once this work is complete, this profile + will be revisited and the appropriate functionality will be added. + + When the subjectAltName extension contains a URI, the name MUST be + stored in the uniformResourceIdentifier (an IA5String). The name + MUST NOT be a relative URL, and it MUST follow the URL syntax and + encoding rules specified in [RFC 1738]. The name MUST include both a + scheme (e.g., "http" or "ftp") and a scheme-specific-part. The + scheme-specific-part MUST include a fully qualified domain name or IP + address as the host. + + + + + + +Housley, et. al. Standards Track [Page 34] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + As specified in [RFC 1738], the scheme name is not case-sensitive + (e.g., "http" is equivalent to "HTTP"). The host part is also not + case-sensitive, but other components of the scheme-specific-part may + be case-sensitive. When comparing URIs, conforming implementations + MUST compare the scheme and host without regard to case, but assume + the remainder of the scheme-specific-part is case sensitive. + + When the subjectAltName extension contains a DN in the directoryName, + the DN MUST be unique for each subject entity certified by the one CA + as defined by the issuer name field. A CA MAY issue more than one + certificate with the same DN to the same subject entity. + + The subjectAltName MAY carry additional name types through the use of + the otherName field. The format and semantics of the name are + indicated through the OBJECT IDENTIFIER in the type-id field. The + name itself is conveyed as value field in otherName. For example, + Kerberos [RFC 1510] format names can be encoded into the otherName, + using using a Kerberos 5 principal name OID and a SEQUENCE of the + Realm and the PrincipalName. + + Subject alternative names MAY be constrained in the same manner as + subject distinguished names using the name constraints extension as + described in section 4.2.1.11. + + If the subjectAltName extension is present, the sequence MUST contain + at least one entry. Unlike the subject field, conforming CAs MUST + NOT issue certificates with subjectAltNames containing empty + GeneralName fields. For example, an rfc822Name is represented as an + IA5String. While an empty string is a valid IA5String, such an + rfc822Name is not permitted by this profile. The behavior of clients + that encounter such a certificate when processing a certificication + path is not defined by this profile. + + Finally, the semantics of subject alternative names that include + wildcard characters (e.g., as a placeholder for a set of names) are + not addressed by this specification. Applications with specific + requirements MAY use such names, but they must define the semantics. + + id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } + + SubjectAltName ::= GeneralNames + + GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName + + + + + + + + +Housley, et. al. Standards Track [Page 35] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + GeneralName ::= CHOICE { + otherName [0] OtherName, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] ORAddress, + directoryName [4] Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id } + + EDIPartyName ::= SEQUENCE { + nameAssigner [0] DirectoryString OPTIONAL, + partyName [1] DirectoryString } + +4.2.1.8 Issuer Alternative Names + + As with 4.2.1.7, this extension is used to associate Internet style + identities with the certificate issuer. Issuer alternative names + MUST be encoded as in 4.2.1.7. + + Where present, this extension SHOULD NOT be marked critical. + + id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } + + IssuerAltName ::= GeneralNames + +4.2.1.9 Subject Directory Attributes + + The subject directory attributes extension is used to convey + identification attributes (e.g., nationality) of the subject. The + extension is defined as a sequence of one or more attributes. This + extension MUST be non-critical. + + id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } + + SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute + +4.2.1.10 Basic Constraints + + The basic constraints extension identifies whether the subject of the + certificate is a CA and the maximum depth of valid certification + paths that include this certificate. + + + + +Housley, et. al. Standards Track [Page 36] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + The cA boolean indicates whether the certified public key belongs to + a CA. If the cA boolean is not asserted, then the keyCertSign bit in + the key usage extension MUST NOT be asserted. + + The pathLenConstraint field is meaningful only if the cA boolean is + asserted and the key usage extension asserts the keyCertSign bit + (section 4.2.1.3). In this case, it gives the maximum number of non- + self-issued intermediate certificates that may follow this + certificate in a valid certification path. A certificate is self- + issued if the DNs that appear in the subject and issuer fields are + identical and are not empty. (Note: The last certificate in the + certification path is not an intermediate certificate, and is not + included in this limit. Usually, the last certificate is an end + entity certificate, but it can be a CA certificate.) A + pathLenConstraint of zero indicates that only one more certificate + may follow in a valid certification path. Where it appears, the + pathLenConstraint field MUST be greater than or equal to zero. Where + pathLenConstraint does not appear, no limit is imposed. + + This extension MUST appear as a critical extension in all CA + certificates that contain public keys used to validate digital + signatures on certificates. This extension MAY appear as a critical + or non-critical extension in CA certificates that contain public keys + used exclusively for purposes other than validating digital + signatures on certificates. Such CA certificates include ones that + contain public keys used exclusively for validating digital + signatures on CRLs and ones that contain key management public keys + used with certificate enrollment protocols. This extension MAY + appear as a critical or non-critical extension in end entity + certificates. + + CAs MUST NOT include the pathLenConstraint field unless the cA + boolean is asserted and the key usage extension asserts the + keyCertSign bit. + + id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } + + BasicConstraints ::= SEQUENCE { + cA BOOLEAN DEFAULT FALSE, + pathLenConstraint INTEGER (0..MAX) OPTIONAL } + +4.2.1.11 Name Constraints + + The name constraints extension, which MUST be used only in a CA + certificate, indicates a name space within which all subject names in + subsequent certificates in a certification path MUST be located. + Restrictions apply to the subject distinguished name and apply to + subject alternative names. Restrictions apply only when the + + + +Housley, et. al. Standards Track [Page 37] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + specified name form is present. If no name of the type is in the + certificate, the certificate is acceptable. + + Name constraints are not applied to certificates whose issuer and + subject are identical (unless the certificate is the final + certificate in the path). (This could prevent CAs that use name + constraints from employing self-issued certificates to implement key + rollover.) + + Restrictions are defined in terms of permitted or excluded name + subtrees. Any name matching a restriction in the excludedSubtrees + field is invalid regardless of information appearing in the + permittedSubtrees. This extension MUST be critical. + + Within this profile, the minimum and maximum fields are not used with + any name forms, thus minimum MUST be zero, and maximum MUST be + absent. + + For URIs, the constraint applies to the host part of the name. The + constraint MAY specify a host or a domain. Examples would be + "foo.bar.com"; and ".xyz.com". When the the constraint begins with + a period, it MAY be expanded with one or more subdomains. That is, + the constraint ".xyz.com" is satisfied by both abc.xyz.com and + abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied + by "xyz.com". When the constraint does not begin with a period, it + specifies a host. + + A name constraint for Internet mail addresses MAY specify a + particular mailbox, all addresses at a particular host, or all + mailboxes in a domain. To indicate a particular mailbox, the + constraint is the complete mail address. For example, "root@xyz.com" + indicates the root mailbox on the host "xyz.com". To indicate all + Internet mail addresses on a particular host, the constraint is + specified as the host name. For example, the constraint "xyz.com" is + satisfied by any mail address at the host "xyz.com". To specify any + address within a domain, the constraint is specified with a leading + period (as with URIs). For example, ".xyz.com" indicates all the + Internet mail addresses in the domain "xyz.com", but not Internet + mail addresses on the host "xyz.com". + + DNS name restrictions are expressed as foo.bar.com. Any DNS name + that can be constructed by simply adding to the left hand side of the + name satisfies the name constraint. For example, www.foo.bar.com + would satisfy the constraint but foo1.bar.com would not. + + Legacy implementations exist where an RFC 822 name is embedded in the + subject distinguished name in an attribute of type EmailAddress + (section 4.1.2.6). When rfc822 names are constrained, but the + + + +Housley, et. al. Standards Track [Page 38] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + certificate does not include a subject alternative name, the rfc822 + name constraint MUST be applied to the attribute of type EmailAddress + in the subject distinguished name. The ASN.1 syntax for EmailAddress + and the corresponding OID are supplied in Appendix A. + + Restrictions of the form directoryName MUST be applied to the subject + field in the certificate and to the subjectAltName extensions of type + directoryName. Restrictions of the form x400Address MUST be applied + to subjectAltName extensions of type x400Address. + + When applying restrictions of the form directoryName, an + implementation MUST compare DN attributes. At a minimum, + implementations MUST perform the DN comparison rules specified in + Section 4.1.2.4. CAs issuing certificates with a restriction of the + form directoryName SHOULD NOT rely on implementation of the full ISO + DN name comparison algorithm. This implies name restrictions MUST be + stated identically to the encoding used in the subject field or + subjectAltName extension. + + The syntax of iPAddress MUST be as described in section 4.2.1.7 with + the following additions specifically for Name Constraints. For IPv4 + addresses, the ipAddress field of generalName MUST contain eight (8) + octets, encoded in the style of RFC 1519 (CIDR) to represent an + address range [RFC 1519]. For IPv6 addresses, the ipAddress field + MUST contain 32 octets similarly encoded. For example, a name + constraint for "class C" subnet 10.9.8.0 is represented as the octets + 0A 09 08 00 FF FF FF 00, representing the CIDR notation + 10.9.8.0/255.255.255.0. + + The syntax and semantics for name constraints for otherName, + ediPartyName, and registeredID are not defined by this specification. + + id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } + + NameConstraints ::= SEQUENCE { + permittedSubtrees [0] GeneralSubtrees OPTIONAL, + excludedSubtrees [1] GeneralSubtrees OPTIONAL } + + GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree + + GeneralSubtree ::= SEQUENCE { + base GeneralName, + minimum [0] BaseDistance DEFAULT 0, + maximum [1] BaseDistance OPTIONAL } + + BaseDistance ::= INTEGER (0..MAX) + + + + + +Housley, et. al. Standards Track [Page 39] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.2.1.12 Policy Constraints + + The policy constraints extension can be used in certificates issued + to CAs. The policy constraints extension constrains path validation + in two ways. It can be used to prohibit policy mapping or require + that each certificate in a path contain an acceptable policy + identifier. + + If the inhibitPolicyMapping field is present, the value indicates the + number of additional certificates that may appear in the path before + policy mapping is no longer permitted. For example, a value of one + indicates that policy mapping may be processed in certificates issued + by the subject of this certificate, but not in additional + certificates in the path. + + If the requireExplicitPolicy field is present, the value of + requireExplicitPolicy indicates the number of additional certificates + that may appear in the path before an explicit policy is required for + the entire path. When an explicit policy is required, it is + necessary for all certificates in the path to contain an acceptable + policy identifier in the certificate policies extension. An + acceptable policy identifier is the identifier of a policy required + by the user of the certification path or the identifier of a policy + which has been declared equivalent through policy mapping. + + Conforming CAs MUST NOT issue certificates where policy constraints + is a empty sequence. That is, at least one of the + inhibitPolicyMapping field or the requireExplicitPolicy field MUST be + present. The behavior of clients that encounter a empty policy + constraints field is not addressed in this profile. + + This extension MAY be critical or non-critical. + + id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } + + PolicyConstraints ::= SEQUENCE { + requireExplicitPolicy [0] SkipCerts OPTIONAL, + inhibitPolicyMapping [1] SkipCerts OPTIONAL } + + SkipCerts ::= INTEGER (0..MAX) + +4.2.1.13 Extended Key Usage + + This extension indicates one or more purposes for which the certified + public key may be used, in addition to or in place of the basic + purposes indicated in the key usage extension. In general, this + extension will appear only in end entity certificates. This + extension is defined as follows: + + + +Housley, et. al. Standards Track [Page 40] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } + + ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId + + KeyPurposeId ::= OBJECT IDENTIFIER + + Key purposes may be defined by any organization with a need. Object + identifiers used to identify key purposes MUST be assigned in + accordance with IANA or ITU-T Recommendation X.660 [X.660]. + + This extension MAY, at the option of the certificate issuer, be + either critical or non-critical. + + If the extension is present, then the certificate MUST only be used + for one of the purposes indicated. If multiple purposes are + indicated the application need not recognize all purposes indicated, + as long as the intended purpose is present. Certificate using + applications MAY require that a particular purpose be indicated in + order for the certificate to be acceptable to that application. + + If a CA includes extended key usages to satisfy such applications, + but does not wish to restrict usages of the key, the CA can include + the special keyPurposeID anyExtendedKeyUsage. If the + anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT + be critical. + + If a certificate contains both a key usage extension and an extended + key usage extension, then both extensions MUST be processed + independently and the certificate MUST only be used for a purpose + consistent with both extensions. If there is no purpose consistent + with both extensions, then the certificate MUST NOT be used for any + purpose. + + The following key usage purposes are defined: + + anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } + + id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } + + id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } + -- TLS WWW server authentication + -- Key usage bits that may be consistent: digitalSignature, + -- keyEncipherment or keyAgreement + + id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } + -- TLS WWW client authentication + -- Key usage bits that may be consistent: digitalSignature + -- and/or keyAgreement + + + +Housley, et. al. Standards Track [Page 41] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } + -- Signing of downloadable executable code + -- Key usage bits that may be consistent: digitalSignature + + id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } + -- E-mail protection + -- Key usage bits that may be consistent: digitalSignature, + -- nonRepudiation, and/or (keyEncipherment or keyAgreement) + + id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } + -- Binding the hash of an object to a time + -- Key usage bits that may be consistent: digitalSignature + -- and/or nonRepudiation + + id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } + -- Signing OCSP responses + -- Key usage bits that may be consistent: digitalSignature + -- and/or nonRepudiation + +4.2.1.14 CRL Distribution Points + + The CRL distribution points extension identifies how CRL information + is obtained. The extension SHOULD be non-critical, but this profile + RECOMMENDS support for this extension by CAs and applications. + Further discussion of CRL management is contained in section 5. + + The cRLDistributionPoints extension is a SEQUENCE of + DistributionPoint. A DistributionPoint consists of three fields, + each of which is optional: distributionPoint, reasons, and cRLIssuer. + While each of these fields is optional, a DistributionPoint MUST NOT + consist of only the reasons field; either distributionPoint or + cRLIssuer MUST be present. If the certificate issuer is not the CRL + issuer, then the cRLIssuer field MUST be present and contain the Name + of the CRL issuer. If the certificate issuer is also the CRL issuer, + then the cRLIssuer field MUST be omitted and the distributionPoint + field MUST be present. If the distributionPoint field is omitted, + cRLIssuer MUST be present and include a Name corresponding to an + X.500 or LDAP directory entry where the CRL is located. + + When the distributionPoint field is present, it contains either a + SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. + If the cRLDistributionPoints extension contains a general name of + type URI, the following semantics MUST be assumed: the URI is a + pointer to the current CRL for the associated reasons and will be + issued by the associated cRLIssuer. The expected values for the URI + are those defined in 4.2.1.7. Processing rules for other values are + not defined by this specification. + + + + +Housley, et. al. Standards Track [Page 42] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + If the DistributionPointName contains multiple values, each name + describes a different mechanism to obtain the same CRL. For example, + the same CRL could be available for retrieval through both LDAP and + HTTP. + + If the DistributionPointName contains the single value + nameRelativeToCRLIssuer, the value provides a distinguished name + fragment. The fragment is appended to the X.500 distinguished name + of the CRL issuer to obtain the distribution point name. If the + cRLIssuer field in the DistributionPoint is present, then the name + fragment is appended to the distinguished name that it contains; + otherwise, the name fragment is appended to the certificate issuer + distinguished name. The DistributionPointName MUST NOT use the + nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than + one distinguished name. + + If the DistributionPoint omits the reasons field, the CRL MUST + include revocation information for all reasons. + + The cRLIssuer identifies the entity who signs and issues the CRL. If + present, the cRLIssuer MUST contain at least one an X.500 + distinguished name (DN), and MAY also contain other name forms. + Since the cRLIssuer is compared to the CRL issuer name, the X.501 + type Name MUST follow the encoding rules for the issuer name field in + the certificate (section 4.1.2.4). + + id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } + + CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint + + DistributionPoint ::= SEQUENCE { + distributionPoint [0] DistributionPointName OPTIONAL, + reasons [1] ReasonFlags OPTIONAL, + cRLIssuer [2] GeneralNames OPTIONAL } + + DistributionPointName ::= CHOICE { + fullName [0] GeneralNames, + nameRelativeToCRLIssuer [1] RelativeDistinguishedName } + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 43] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + ReasonFlags ::= BIT STRING { + unused (0), + keyCompromise (1), + cACompromise (2), + affiliationChanged (3), + superseded (4), + cessationOfOperation (5), + certificateHold (6), + privilegeWithdrawn (7), + aACompromise (8) } + +4.2.1.15 Inhibit Any-Policy + + The inhibit any-policy extension can be used in certificates issued + to CAs. The inhibit any-policy indicates that the special anyPolicy + OID, with the value { 2 5 29 32 0 }, is not considered an explicit + match for other certificate policies. The value indicates the number + of additional certificates that may appear in the path before + anyPolicy is no longer permitted. For example, a value of one + indicates that anyPolicy may be processed in certificates issued by + the subject of this certificate, but not in additional certificates + in the path. + + This extension MUST be critical. + + id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } + + InhibitAnyPolicy ::= SkipCerts + + SkipCerts ::= INTEGER (0..MAX) + +4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) + + The freshest CRL extension identifies how delta CRL information is + obtained. The extension MUST be non-critical. Further discussion of + CRL management is contained in section 5. + + The same syntax is used for this extension and the + cRLDistributionPoints extension, and is described in section + 4.2.1.14. The same conventions apply to both extensions. + + id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } + + FreshestCRL ::= CRLDistributionPoints + + + + + + + +Housley, et. al. Standards Track [Page 44] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +4.2.2 Private Internet Extensions + + This section defines two extensions for use in the Internet Public + Key Infrastructure. These extensions may be used to direct + applications to on-line information about the issuing CA or the + subject. As the information may be available in multiple forms, each + extension is a sequence of IA5String values, each of which represents + a URI. The URI implicitly specifies the location and format of the + information and the method for obtaining the information. + + An object identifier is defined for the private extension. The + object identifier associated with the private extension is defined + under the arc id-pe within the arc id-pkix. Any future extensions + defined for the Internet PKI are also expected to be defined under + the arc id-pe. + + id-pkix OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) } + + id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } + +4.2.2.1 Authority Information Access + + The authority information access extension indicates how to access CA + information and services for the issuer of the certificate in which + the extension appears. Information and services may include on-line + validation services and CA policy data. (The location of CRLs is not + specified in this extension; that information is provided by the + cRLDistributionPoints extension.) This extension may be included in + end entity or CA certificates, and it MUST be non-critical. + + id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } + + AuthorityInfoAccessSyntax ::= + SEQUENCE SIZE (1..MAX) OF AccessDescription + + AccessDescription ::= SEQUENCE { + accessMethod OBJECT IDENTIFIER, + accessLocation GeneralName } + + id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } + + id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } + + id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } + + + + + +Housley, et. al. Standards Track [Page 45] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + Each entry in the sequence AuthorityInfoAccessSyntax describes the + format and location of additional information provided by the CA that + issued the certificate in which this extension appears. The type and + format of the information is specified by the accessMethod field; the + accessLocation field specifies the location of the information. The + retrieval mechanism may be implied by the accessMethod or specified + by accessLocation. + + This profile defines two accessMethod OIDs: id-ad-caIssuers and + id-ad-ocsp. + + The id-ad-caIssuers OID is used when the additional information lists + CAs that have issued certificates superior to the CA that issued the + certificate containing this extension. The referenced CA issuers + description is intended to aid certificate users in the selection of + a certification path that terminates at a point trusted by the + certificate user. + + When id-ad-caIssuers appears as accessMethod, the accessLocation + field describes the referenced description server and the access + protocol to obtain the referenced description. The accessLocation + field is defined as a GeneralName, which can take several forms. + Where the information is available via http, ftp, or ldap, + accessLocation MUST be a uniformResourceIdentifier. Where the + information is available via the Directory Access Protocol (DAP), + accessLocation MUST be a directoryName. The entry for that + directoryName contains CA certificates in the crossCertificatePair + attribute. When the information is available via electronic mail, + accessLocation MUST be an rfc822Name. The semantics of other + id-ad-caIssuers accessLocation name forms are not defined. + + The id-ad-ocsp OID is used when revocation information for the + certificate containing this extension is available using the Online + Certificate Status Protocol (OCSP) [RFC 2560]. + + When id-ad-ocsp appears as accessMethod, the accessLocation field is + the location of the OCSP responder, using the conventions defined in + [RFC 2560]. + + Additional access descriptors may be defined in other PKIX + specifications. + +4.2.2.2 Subject Information Access + + The subject information access extension indicates how to access + information and services for the subject of the certificate in which + the extension appears. When the subject is a CA, information and + services may include certificate validation services and CA policy + + + +Housley, et. al. Standards Track [Page 46] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + data. When the subject is an end entity, the information describes + the type of services offered and how to access them. In this case, + the contents of this extension are defined in the protocol + specifications for the suported services. This extension may be + included in subject or CA certificates, and it MUST be non-critical. + + id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } + + SubjectInfoAccessSyntax ::= + SEQUENCE SIZE (1..MAX) OF AccessDescription + + AccessDescription ::= SEQUENCE { + accessMethod OBJECT IDENTIFIER, + accessLocation GeneralName } + + Each entry in the sequence SubjectInfoAccessSyntax describes the + format and location of additional information provided by the subject + of the certificate in which this extension appears. The type and + format of the information is specified by the accessMethod field; the + accessLocation field specifies the location of the information. The + retrieval mechanism may be implied by the accessMethod or specified + by accessLocation. + + This profile defines one access method to be used when the subject is + a CA, and one access method to be used when the subject is an end + entity. Additional access methods may be defined in the future in + the protocol specifications for other services. + + The id-ad-caRepository OID is used when the subject is a CA, and + publishes its certificates and CRLs (if issued) in a repository. The + accessLocation field is defined as a GeneralName, which can take + several forms. Where the information is available via http, ftp, or + ldap, accessLocation MUST be a uniformResourceIdentifier. Where the + information is available via the directory access protocol (dap), + accessLocation MUST be a directoryName. When the information is + available via electronic mail, accessLocation MUST be an rfc822Name. + The semantics of other name forms of of accessLocation (when + accessMethod is id-ad-caRepository) are not defined by this + specification. + + The id-ad-timeStamping OID is used when the subject offers + timestamping services using the Time Stamp Protocol defined in + [PKIXTSA]. Where the timestamping services are available via http or + ftp, accessLocation MUST be a uniformResourceIdentifier. Where the + timestamping services are available via electronic mail, + accessLocation MUST be an rfc822Name. Where timestamping services + + + + + +Housley, et. al. Standards Track [Page 47] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + are available using TCP/IP, the dNSName or ipAddress name forms may + be used. The semantics of other name forms of accessLocation (when + accessMethod is id-ad-timeStamping) are not defined by this + specification. + + Additional access descriptors may be defined in other PKIX + specifications. + + id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } + + id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } + + id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } + +5 CRL and CRL Extensions Profile + + As discussed above, one goal of this X.509 v2 CRL profile is to + foster the creation of an interoperable and reusable Internet PKI. + To achieve this goal, guidelines for the use of extensions are + specified, and some assumptions are made about the nature of + information included in the CRL. + + CRLs may be used in a wide range of applications and environments + covering a broad spectrum of interoperability goals and an even + broader spectrum of operational and assurance requirements. This + profile establishes a common baseline for generic applications + requiring broad interoperability. The profile defines a set of + information that can be expected in every CRL. Also, the profile + defines common locations within the CRL for frequently used + attributes as well as common representations for these attributes. + + CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs + publish CRLs to provide status information about the certificates + they issued. However, a CA may delegate this responsibility to + another trusted authority. Whenever the CRL issuer is not the CA + that issued the certificates, the CRL is referred to as an indirect + CRL. + + Each CRL has a particular scope. The CRL scope is the set of + certificates that could appear on a given CRL. For example, the + scope could be "all certificates issued by CA X", "all CA + certificates issued by CA X", "all certificates issued by CA X that + have been revoked for reasons of key compromise and CA compromise", + or could be a set of certificates based on arbitrary local + information, such as "all certificates issued to the NIST employees + located in Boulder". + + + + + +Housley, et. al. Standards Track [Page 48] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + A complete CRL lists all unexpired certificates, within its scope, + that have been revoked for one of the revocation reasons covered by + the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta + CRL only lists those certificates, within its scope, whose revocation + status has changed since the issuance of a referenced complete CRL. + The referenced complete CRL is referred to as a base CRL. The scope + of a delta CRL MUST be the same as the base CRL that it references. + + This profile does not define any private Internet CRL extensions or + CRL entry extensions. + + Environments with additional or special purpose requirements may + build on this profile or may replace it. + + Conforming CAs are not required to issue CRLs if other revocation or + certificate status mechanisms are provided. When CRLs are issued, + the CRLs MUST be version 2 CRLs, include the date by which the next + CRL will be issued in the nextUpdate field (section 5.1.2.5), include + the CRL number extension (section 5.2.3), and include the authority + key identifier extension (section 5.2.1). Conforming applications + that support CRLs are REQUIRED to process both version 1 and version + 2 complete CRLs that provide revocation information for all + certificates issued by one CA. Conforming applications are NOT + REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs + with a scope other than all certificates issued by one CA. + +5.1 CRL Fields + + The X.509 v2 CRL syntax is as follows. For signature calculation, + the data that is to be signed is ASN.1 DER encoded. ASN.1 DER + encoding is a tag, length, value encoding system for each element. + + CertificateList ::= SEQUENCE { + tbsCertList TBSCertList, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING } + + + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 49] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + TBSCertList ::= SEQUENCE { + version Version OPTIONAL, + -- if present, MUST be v2 + signature AlgorithmIdentifier, + issuer Name, + thisUpdate Time, + nextUpdate Time OPTIONAL, + revokedCertificates SEQUENCE OF SEQUENCE { + userCertificate CertificateSerialNumber, + revocationDate Time, + crlEntryExtensions Extensions OPTIONAL + -- if present, MUST be v2 + } OPTIONAL, + crlExtensions [0] EXPLICIT Extensions OPTIONAL + -- if present, MUST be v2 + } + + -- Version, Time, CertificateSerialNumber, and Extensions + -- are all defined in the ASN.1 in section 4.1 + + -- AlgorithmIdentifier is defined in section 4.1.1.2 + + The following items describe the use of the X.509 v2 CRL in the + Internet PKI. + +5.1.1 CertificateList Fields + + The CertificateList is a SEQUENCE of three required fields. The + fields are described in detail in the following subsections. + +5.1.1.1 tbsCertList + + The first field in the sequence is the tbsCertList. This field is + itself a sequence containing the name of the issuer, issue date, + issue date of the next list, the optional list of revoked + certificates, and optional CRL extensions. When there are no revoked + certificates, the revoked certificates list is absent. When one or + more certificates are revoked, each entry on the revoked certificate + list is defined by a sequence of user certificate serial number, + revocation date, and optional CRL entry extensions. + +5.1.1.2 signatureAlgorithm + + The signatureAlgorithm field contains the algorithm identifier for + the algorithm used by the CRL issuer to sign the CertificateList. + The field is of type AlgorithmIdentifier, which is defined in section + 4.1.1.2. [PKIXALGS] lists the supported algorithms for this + specification, but other signature algorithms MAY also be supported. + + + +Housley, et. al. Standards Track [Page 50] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + This field MUST contain the same algorithm identifier as the + signature field in the sequence tbsCertList (section 5.1.2.2). + +5.1.1.3 signatureValue + + The signatureValue field contains a digital signature computed upon + the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList + is used as the input to the signature function. This signature value + is encoded as a BIT STRING and included in the CRL signatureValue + field. The details of this process are specified for each of the + supported algorithms in [PKIXALGS]. + + CAs that are also CRL issuers MAY use one private key to digitally + sign certificates and CRLs, or MAY use separate private keys to + digitally sign certificates and CRLs. When separate private keys are + employed, each of the public keys associated with these private keys + is placed in a separate certificate, one with the keyCertSign bit set + in the key usage extension, and one with the cRLSign bit set in the + key usage extension (section 4.2.1.3). When separate private keys + are employed, certificates issued by the CA contain one authority key + identifier, and the corresponding CRLs contain a different authority + key identifier. The use of separate CA certificates for validation + of certificate signatures and CRL signatures can offer improved + security characteristics; however, it imposes a burden on + applications, and it might limit interoperability. Many applications + construct a certification path, and then validate the certification + path (section 6). CRL checking in turn requires a separate + certification path to be constructed and validated for the CA's CRL + signature validation certificate. Applications that perform CRL + checking MUST support certification path validation when certificates + and CRLs are digitally signed with the same CA private key. These + applications SHOULD support certification path validation when + certificates and CRLs are digitally signed with different CA private + keys. + +5.1.2 Certificate List "To Be Signed" + + The certificate list to be signed, or TBSCertList, is a sequence of + required and optional fields. The required fields identify the CRL + issuer, the algorithm used to sign the CRL, the date and time the CRL + was issued, and the date and time by which the CRL issuer will issue + the next CRL. + + Optional fields include lists of revoked certificates and CRL + extensions. The revoked certificate list is optional to support the + case where a CA has not revoked any unexpired certificates that it + + + + + +Housley, et. al. Standards Track [Page 51] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + has issued. The profile requires conforming CRL issuers to use the + CRL number and authority key identifier CRL extensions in all CRLs + issued. + +5.1.2.1 Version + + This optional field describes the version of the encoded CRL. When + extensions are used, as required by this profile, this field MUST be + present and MUST specify version 2 (the integer value is 1). + +5.1.2.2 Signature + + This field contains the algorithm identifier for the algorithm used + to sign the CRL. [PKIXALGS] lists OIDs for the most popular + signature algorithms used in the Internet PKI. + + This field MUST contain the same algorithm identifier as the + signatureAlgorithm field in the sequence CertificateList (section + 5.1.1.2). + +5.1.2.3 Issuer Name + + The issuer name identifies the entity who has signed and issued the + CRL. The issuer identity is carried in the issuer name field. + Alternative name forms may also appear in the issuerAltName extension + (section 5.2.2). The issuer name field MUST contain an X.500 + distinguished name (DN). The issuer name field is defined as the + X.501 type Name, and MUST follow the encoding rules for the issuer + name field in the certificate (section 4.1.2.4). + +5.1.2.4 This Update + + This field indicates the issue date of this CRL. ThisUpdate may be + encoded as UTCTime or GeneralizedTime. + + CRL issuers conforming to this profile MUST encode thisUpdate as + UTCTime for dates through the year 2049. CRL issuers conforming to + this profile MUST encode thisUpdate as GeneralizedTime for dates in + the year 2050 or later. + + Where encoded as UTCTime, thisUpdate MUST be specified and + interpreted as defined in section 4.1.2.5.1. Where encoded as + GeneralizedTime, thisUpdate MUST be specified and interpreted as + defined in section 4.1.2.5.2. + + + + + + + +Housley, et. al. Standards Track [Page 52] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +5.1.2.5 Next Update + + This field indicates the date by which the next CRL will be issued. + The next CRL could be issued before the indicated date, but it will + not be issued any later than the indicated date. CRL issuers SHOULD + issue CRLs with a nextUpdate time equal to or later than all previous + CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. + + This profile requires inclusion of nextUpdate in all CRLs issued by + conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList + describes this field as OPTIONAL, which is consistent with the ASN.1 + structure defined in [X.509]. The behavior of clients processing + CRLs which omit nextUpdate is not specified by this profile. + + CRL issuers conforming to this profile MUST encode nextUpdate as + UTCTime for dates through the year 2049. CRL issuers conforming to + this profile MUST encode nextUpdate as GeneralizedTime for dates in + the year 2050 or later. + + Where encoded as UTCTime, nextUpdate MUST be specified and + interpreted as defined in section 4.1.2.5.1. Where encoded as + GeneralizedTime, nextUpdate MUST be specified and interpreted as + defined in section 4.1.2.5.2. + +5.1.2.6 Revoked Certificates + + When there are no revoked certificates, the revoked certificates list + MUST be absent. Otherwise, revoked certificates are listed by their + serial numbers. Certificates revoked by the CA are uniquely + identified by the certificate serial number. The date on which the + revocation occurred is specified. The time for revocationDate MUST + be expressed as described in section 5.1.2.4. Additional information + may be supplied in CRL entry extensions; CRL entry extensions are + discussed in section 5.3. + +5.1.2.7 Extensions + + This field may only appear if the version is 2 (section 5.1.2.1). If + present, this field is a sequence of one or more CRL extensions. CRL + extensions are discussed in section 5.2. + +5.2 CRL Extensions + + The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 + CRLs [X.509] [X9.55] provide methods for associating additional + attributes with CRLs. The X.509 v2 CRL format also allows + communities to define private extensions to carry information unique + to those communities. Each extension in a CRL may be designated as + + + +Housley, et. al. Standards Track [Page 53] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + critical or non-critical. A CRL validation MUST fail if it + encounters a critical extension which it does not know how to + process. However, an unrecognized non-critical extension may be + ignored. The following subsections present those extensions used + within Internet CRLs. Communities may elect to include extensions in + CRLs which are not defined in this specification. However, caution + should be exercised in adopting any critical extensions in CRLs which + might be used in a general context. + + Conforming CRL issuers are REQUIRED to include the authority key + identifier (section 5.2.1) and the CRL number (section 5.2.3) + extensions in all CRLs issued. + +5.2.1 Authority Key Identifier + + The authority key identifier extension provides a means of + identifying the public key corresponding to the private key used to + sign a CRL. The identification can be based on either the key + identifier (the subject key identifier in the CRL signer's + certificate) or on the issuer name and serial number. This extension + is especially useful where an issuer has more than one signing key, + either due to multiple concurrent key pairs or due to changeover. + + Conforming CRL issuers MUST use the key identifier method, and MUST + include this extension in all CRLs issued. + + The syntax for this CRL extension is defined in section 4.2.1.1. + +5.2.2 Issuer Alternative Name + + The issuer alternative names extension allows additional identities + to be associated with the issuer of the CRL. Defined options include + an rfc822 name (electronic mail address), a DNS name, an IP address, + and a URI. Multiple instances of a name and multiple name forms may + be included. Whenever such identities are used, the issuer + alternative name extension MUST be used; however, a DNS name MAY be + represented in the issuer field using the domainComponent attribute + as described in section 4.1.2.4. + + The issuerAltName extension SHOULD NOT be marked critical. + + The OID and syntax for this CRL extension are defined in section + 4.2.1.8. + + + + + + + + +Housley, et. al. Standards Track [Page 54] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +5.2.3 CRL Number + + The CRL number is a non-critical CRL extension which conveys a + monotonically increasing sequence number for a given CRL scope and + CRL issuer. This extension allows users to easily determine when a + particular CRL supersedes another CRL. CRL numbers also support the + identification of complementary complete CRLs and delta CRLs. CRL + issuers conforming to this profile MUST include this extension in all + CRLs. + + If a CRL issuer generates delta CRLs in addition to complete CRLs for + a given scope, the complete CRLs and delta CRLs MUST share one + numbering sequence. If a delta CRL and a complete CRL that cover the + same scope are issued at the same time, they MUST have the same CRL + number and provide the same revocation information. That is, the + combination of the delta CRL and an acceptable complete CRL MUST + provide the same revocation information as the simultaneously issued + complete CRL. + + If a CRL issuer generates two CRLs (two complete CRLs, two delta + CRLs, or a complete CRL and a delta CRL) for the same scope at + different times, the two CRLs MUST NOT have the same CRL number. + That is, if the this update field (section 5.1.2.4) in the two CRLs + are not identical, the CRL numbers MUST be different. + + Given the requirements above, CRL numbers can be expected to contain + long integers. CRL verifiers MUST be able to handle CRLNumber values + up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber + values longer than 20 octets. + + id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } + + CRLNumber ::= INTEGER (0..MAX) + +5.2.4 Delta CRL Indicator + + The delta CRL indicator is a critical CRL extension that identifies a + CRL as being a delta CRL. Delta CRLs contain updates to revocation + information previously distributed, rather than all the information + that would appear in a complete CRL. The use of delta CRLs can + significantly reduce network load and processing time in some + environments. Delta CRLs are generally smaller than the CRLs they + update, so applications that obtain delta CRLs consume less network + bandwidth than applications that obtain the corresponding complete + CRLs. Applications which store revocation information in a format + other than the CRL structure can add new revocation information to + the local database without reprocessing information. + + + + +Housley, et. al. Standards Track [Page 55] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + The delta CRL indicator extension contains the single value of type + BaseCRLNumber. The CRL number identifies the CRL, complete for a + given scope, that was used as the starting point in the generation of + this delta CRL. A conforming CRL issuer MUST publish the referenced + base CRL as a complete CRL. The delta CRL contains all updates to + the revocation status for that same scope. The combination of a + delta CRL plus the referenced base CRL is equivalent to a complete + CRL, for the applicable scope, at the time of publication of the + delta CRL. + + When a conforming CRL issuer generates a delta CRL, the delta CRL + MUST include a critical delta CRL indicator extension. + + When a delta CRL is issued, it MUST cover the same set of reasons and + the same set of certificates that were covered by the base CRL it + references. That is, the scope of the delta CRL MUST be the same as + the scope of the complete CRL referenced as the base. The referenced + base CRL and the delta CRL MUST omit the issuing distribution point + extension or contain identical issuing distribution point extensions. + Further, the CRL issuer MUST use the same private key to sign the + delta CRL and any complete CRL that it can be used to update. + + An application that supports delta CRLs can construct a CRL that is + complete for a given scope by combining a delta CRL for that scope + with either an issued CRL that is complete for that scope or a + locally constructed CRL that is complete for that scope. + + When a delta CRL is combined with a complete CRL or a locally + constructed CRL, the resulting locally constructed CRL has the CRL + number specified in the CRL number extension found in the delta CRL + used in its construction. In addition, the resulting locally + constructed CRL has the thisUpdate and nextUpdate times specified in + the corresponding fields of the delta CRL used in its construction. + In addition, the locally constructed CRL inherits the issuing + distribution point from the delta CRL. + + A complete CRL and a delta CRL MAY be combined if the following four + conditions are satisfied: + + (a) The complete CRL and delta CRL have the same issuer. + + (b) The complete CRL and delta CRL have the same scope. The two + CRLs have the same scope if either of the following conditions are + met: + + (1) The issuingDistributionPoint extension is omitted from + both the complete CRL and the delta CRL. + + + + +Housley, et. al. Standards Track [Page 56] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (2) The issuingDistributionPoint extension is present in both + the complete CRL and the delta CRL, and the values for each of + the fields in the extensions are the same in both CRLs. + + (c) The CRL number of the complete CRL is equal to or greater + than the BaseCRLNumber specified in the delta CRL. That is, the + complete CRL contains (at a minimum) all the revocation + information held by the referenced base CRL. + + (d) The CRL number of the complete CRL is less than the CRL + number of the delta CRL. That is, the delta CRL follows the + complete CRL in the numbering sequence. + + CRL issuers MUST ensure that the combination of a delta CRL and any + appropriate complete CRL accurately reflects the current revocation + status. The CRL issuer MUST include an entry in the delta CRL for + each certificate within the scope of the delta CRL whose status has + changed since the generation of the referenced base CRL: + + (a) If the certificate is revoked for a reason included in the + scope of the CRL, list the certificate as revoked. + + (b) If the certificate is valid and was listed on the referenced + base CRL or any subsequent CRL with reason code certificateHold, + and the reason code certificateHold is included in the scope of + the CRL, list the certificate with the reason code removeFromCRL. + + (c) If the certificate is revoked for a reason outside the scope + of the CRL, but the certificate was listed on the referenced base + CRL or any subsequent CRL with a reason code included in the scope + of this CRL, list the certificate as revoked but omit the reason + code. + + (d) If the certificate is revoked for a reason outside the scope + of the CRL and the certificate was neither listed on the + referenced base CRL nor any subsequent CRL with a reason code + included in the scope of this CRL, do not list the certificate on + this CRL. + + The status of a certificate is considered to have changed if it is + revoked, placed on hold, released from hold, or if its revocation + reason changes. + + It is appropriate to list a certificate with reason code + removeFromCRL on a delta CRL even if the certificate was not on hold + in the referenced base CRL. If the certificate was placed on hold in + + + + + +Housley, et. al. Standards Track [Page 57] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + any CRL issued after the base but before this delta CRL and then + released from hold, it MUST be listed on the delta CRL with + revocation reason removeFromCRL. + + A CRL issuer MAY optionally list a certificate on a delta CRL with + reason code removeFromCRL if the notAfter time specified in the + certificate precedes the thisUpdate time specified in the delta CRL + and the certificate was listed on the referenced base CRL or in any + CRL issued after the base but before this delta CRL. + + If a certificate revocation notice first appears on a delta CRL, then + it is possible for the certificate validity period to expire before + the next complete CRL for the same scope is issued. In this case, + the revocation notice MUST be included in all subsequent delta CRLs + until the revocation notice is included on at least one explicitly + issued complete CRL for this scope. + + An application that supports delta CRLs MUST be able to construct a + current complete CRL by combining a previously issued complete CRL + and the most current delta CRL. An application that supports delta + CRLs MAY also be able to construct a current complete CRL by + combining a previously locally constructed complete CRL and the + current delta CRL. A delta CRL is considered to be the current one + if the current time is between the times contained in the thisUpdate + and nextUpdate fields. Under some circumstances, the CRL issuer may + publish one or more delta CRLs before indicated by the nextUpdate + field. If more than one current delta CRL for a given scope is + encountered, the application SHOULD consider the one with the latest + value in thisUpdate to be the most current one. + + id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } + + BaseCRLNumber ::= CRLNumber + +5.2.5 Issuing Distribution Point + + The issuing distribution point is a critical CRL extension that + identifies the CRL distribution point and scope for a particular CRL, + and it indicates whether the CRL covers revocation for end entity + certificates only, CA certificates only, attribute certificates only, + + or a limited set of reason codes. Although the extension is + critical, conforming implementations are not required to support this + extension. + + + + + + + +Housley, et. al. Standards Track [Page 58] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + The CRL is signed using the CRL issuer's private key. CRL + Distribution Points do not have their own key pairs. If the CRL is + stored in the X.500 Directory, it is stored in the Directory entry + corresponding to the CRL distribution point, which may be different + than the Directory entry of the CRL issuer. + + The reason codes associated with a distribution point MUST be + specified in onlySomeReasons. If onlySomeReasons does not appear, + the distribution point MUST contain revocations for all reason codes. + CAs may use CRL distribution points to partition the CRL on the basis + of compromise and routine revocation. In this case, the revocations + with reason code keyCompromise (1), cACompromise (2), and + aACompromise (8) appear in one distribution point, and the + revocations with other reason codes appear in another distribution + point. + + If the distributionPoint field is present and contains a URI, the + following semantics MUST be assumed: the object is a pointer to the + most current CRL issued by this CRL issuer. The URI schemes ftp, + http, mailto [RFC1738] and ldap [RFC1778] are defined for this + purpose. The URI MUST be an absolute pathname, not a relative + pathname, and MUST specify the host. + + If the distributionPoint field is absent, the CRL MUST contain + entries for all revoked unexpired certificates issued by the CRL + issuer, if any, within the scope of the CRL. + + The CRL issuer MUST assert the indirectCRL boolean, if the scope of + the CRL includes certificates issued by authorities other than the + CRL issuer. The authority responsible for each entry is indicated by + the certificate issuer CRL entry extension (section 5.3.4). + + id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } + + issuingDistributionPoint ::= SEQUENCE { + distributionPoint [0] DistributionPointName OPTIONAL, + onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, + onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, + onlySomeReasons [3] ReasonFlags OPTIONAL, + indirectCRL [4] BOOLEAN DEFAULT FALSE, + onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } + +5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) + + The freshest CRL extension identifies how delta CRL information for + this complete CRL is obtained. The extension MUST be non-critical. + This extension MUST NOT appear in delta CRLs. + + + + +Housley, et. al. Standards Track [Page 59] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + The same syntax is used for this extension as the + cRLDistributionPoints certificate extension, and is described in + section 4.2.1.14. However, only the distribution point field is + meaningful in this context. The reasons and CRLIssuer fields MUST be + omitted from this CRL extension. + + Each distribution point name provides the location at which a delta + CRL for this complete CRL can be found. The scope of these delta + CRLs MUST be the same as the scope of this complete CRL. The + contents of this CRL extension are only used to locate delta CRLs; + the contents are not used to validate the CRL or the referenced delta + CRLs. The encoding conventions defined for distribution points in + section 4.2.1.14 apply to this extension. + + id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } + + FreshestCRL ::= CRLDistributionPoints + +5.3 CRL Entry Extensions + + The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for + X.509 v2 CRLs provide methods for associating additional attributes + with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also + allows communities to define private CRL entry extensions to carry + information unique to those communities. Each extension in a CRL + entry may be designated as critical or non-critical. A CRL + validation MUST fail if it encounters a critical CRL entry extension + which it does not know how to process. However, an unrecognized non- + critical CRL entry extension may be ignored. The following + subsections present recommended extensions used within Internet CRL + entries and standard locations for information. Communities may + elect to use additional CRL entry extensions; however, caution should + be exercised in adopting any critical extensions in CRL entries which + might be used in a general context. + + All CRL entry extensions used in this specification are non-critical. + Support for these extensions is optional for conforming CRL issuers + and applications. However, CRL issuers SHOULD include reason codes + (section 5.3.1) and invalidity dates (section 5.3.3) whenever this + information is available. + +5.3.1 Reason Code + + The reasonCode is a non-critical CRL entry extension that identifies + the reason for the certificate revocation. CRL issuers are strongly + encouraged to include meaningful reason codes in CRL entries; + however, the reason code CRL entry extension SHOULD be absent instead + of using the unspecified (0) reasonCode value. + + + +Housley, et. al. Standards Track [Page 60] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } + + -- reasonCode ::= { CRLReason } + + CRLReason ::= ENUMERATED { + unspecified (0), + keyCompromise (1), + cACompromise (2), + affiliationChanged (3), + superseded (4), + cessationOfOperation (5), + certificateHold (6), + removeFromCRL (8), + privilegeWithdrawn (9), + aACompromise (10) } + +5.3.2 Hold Instruction Code + + The hold instruction code is a non-critical CRL entry extension that + provides a registered instruction identifier which indicates the + action to be taken after encountering a certificate that has been + placed on hold. + + id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } + + holdInstructionCode ::= OBJECT IDENTIFIER + + The following instruction codes have been defined. Conforming + applications that process this extension MUST recognize the following + instruction codes. + + holdInstruction OBJECT IDENTIFIER ::= + { iso(1) member-body(2) us(840) x9-57(10040) 2 } + + id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} + id-holdinstruction-callissuer + OBJECT IDENTIFIER ::= {holdInstruction 2} + id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} + + Conforming applications which encounter an id-holdinstruction- + callissuer MUST call the certificate issuer or reject the + certificate. Conforming applications which encounter an id- + holdinstruction-reject MUST reject the certificate. The hold + instruction id-holdinstruction-none is semantically equivalent to the + absence of a holdInstructionCode, and its use is strongly deprecated + for the Internet PKI. + + + + + +Housley, et. al. Standards Track [Page 61] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +5.3.3 Invalidity Date + + The invalidity date is a non-critical CRL entry extension that + provides the date on which it is known or suspected that the private + key was compromised or that the certificate otherwise became invalid. + This date may be earlier than the revocation date in the CRL entry, + which is the date at which the CA processed the revocation. When a + revocation is first posted by a CRL issuer in a CRL, the invalidity + date may precede the date of issue of earlier CRLs, but the + revocation date SHOULD NOT precede the date of issue of earlier CRLs. + Whenever this information is available, CRL issuers are strongly + encouraged to share it with CRL users. + + The GeneralizedTime values included in this field MUST be expressed + in Greenwich Mean Time (Zulu), and MUST be specified and interpreted + as defined in section 4.1.2.5.2. + + id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } + + invalidityDate ::= GeneralizedTime + +5.3.4 Certificate Issuer + + This CRL entry extension identifies the certificate issuer associated + with an entry in an indirect CRL, that is, a CRL that has the + indirectCRL indicator set in its issuing distribution point + extension. If this extension is not present on the first entry in an + indirect CRL, the certificate issuer defaults to the CRL issuer. On + subsequent entries in an indirect CRL, if this extension is not + present, the certificate issuer for the entry is the same as that for + the preceding entry. This field is defined as follows: + + id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } + + certificateIssuer ::= GeneralNames + + If used by conforming CRL issuers, this extension MUST always be + critical. If an implementation ignored this extension it could not + correctly attribute CRL entries to certificates. This specification + RECOMMENDS that implementations recognize this extension. + +6 Certification Path Validation + + Certification path validation procedures for the Internet PKI are + based on the algorithm supplied in [X.509]. Certification path + processing verifies the binding between the subject distinguished + name and/or subject alternative name and subject public key. The + binding is limited by constraints which are specified in the + + + +Housley, et. al. Standards Track [Page 62] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + certificates which comprise the path and inputs which are specified + by the relying party. The basic constraints and policy constraints + extensions allow the certification path processing logic to automate + the decision making process. + + This section describes an algorithm for validating certification + paths. Conforming implementations of this specification are not + required to implement this algorithm, but MUST provide functionality + equivalent to the external behavior resulting from this procedure. + Any algorithm may be used by a particular implementation so long as + it derives the correct result. + + In section 6.1, the text describes basic path validation. Valid + paths begin with certificates issued by a trust anchor. The + algorithm requires the public key of the CA, the CA's name, and any + constraints upon the set of paths which may be validated using this + key. + + The selection of a trust anchor is a matter of policy: it could be + the top CA in a hierarchical PKI; the CA that issued the verifier's + own certificate(s); or any other CA in a network PKI. The path + validation procedure is the same regardless of the choice of trust + anchor. In addition, different applications may rely on different + trust anchor, or may accept paths that begin with any of a set of + trust anchor. + + Section 6.2 describes methods for using the path validation algorithm + in specific implementations. Two specific cases are discussed: the + case where paths may begin with one of several trusted CAs; and where + compatibility with the PEM architecture is required. + + Section 6.3 describes the steps necessary to determine if a + certificate is revoked or on hold status when CRLs are the revocation + mechanism used by the certificate issuer. + +6.1 Basic Path Validation + + This text describes an algorithm for X.509 path processing. A + conformant implementation MUST include an X.509 path processing + procedure that is functionally equivalent to the external behavior of + this algorithm. However, support for some of the certificate + extensions processed in this algorithm are OPTIONAL for compliant + implementations. Clients that do not support these extensions MAY + omit the corresponding steps in the path validation algorithm. + + + + + + + +Housley, et. al. Standards Track [Page 63] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + For example, clients are NOT REQUIRED to support the policy mapping + extension. Clients that do not support this extension MAY omit the + path validation steps where policy mappings are processed. Note that + clients MUST reject the certificate if it contains an unsupported + critical extension. + + The algorithm presented in this section validates the certificate + with respect to the current date and time. A conformant + implementation MAY also support validation with respect to some point + in the past. Note that mechanisms are not available for validating a + certificate with respect to a time outside the certificate validity + period. + + The trust anchor is an input to the algorithm. There is no + requirement that the same trust anchor be used to validate all + certification paths. Different trust anchors MAY be used to validate + different paths, as discussed further in Section 6.2. + + The primary goal of path validation is to verify the binding between + a subject distinguished name or a subject alternative name and + subject public key, as represented in the end entity certificate, + based on the public key of the trust anchor. This requires obtaining + a sequence of certificates that support that binding. The procedure + performed to obtain this sequence of certificates is outside the + scope of this specification. + + To meet this goal, the path validation process verifies, among other + things, that a prospective certification path (a sequence of n + certificates) satisfies the following conditions: + + (a) for all x in {1, ..., n-1}, the subject of certificate x is + the issuer of certificate x+1; + + (b) certificate 1 is issued by the trust anchor; + + (c) certificate n is the certificate to be validated; and + + (d) for all x in {1, ..., n}, the certificate was valid at the + time in question. + + When the trust anchor is provided in the form of a self-signed + certificate, this self-signed certificate is not included as part of + the prospective certification path. Information about trust anchors + are provided as inputs to the certification path validation algorithm + (section 6.1.1). + + + + + + +Housley, et. al. Standards Track [Page 64] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + A particular certification path may not, however, be appropriate for + all applications. Therefore, an application MAY augment this + algorithm to further limit the set of valid paths. The path + validation process also determines the set of certificate policies + that are valid for this path, based on the certificate policies + extension, policy mapping extension, policy constraints extension, + and inhibit any-policy extension. To achieve this, the path + validation algorithm constructs a valid policy tree. If the set of + certificate policies that are valid for this path is not empty, then + the result will be a valid policy tree of depth n, otherwise the + result will be a null valid policy tree. + + A certificate is self-issued if the DNs that appear in the subject + and issuer fields are identical and are not empty. In general, the + issuer and subject of the certificates that make up a path are + different for each certificate. However, a CA may issue a + certificate to itself to support key rollover or changes in + certificate policies. These self-issued certificates are not counted + when evaluating path length or name constraints. + + This section presents the algorithm in four basic steps: (1) + initialization, (2) basic certificate processing, (3) preparation for + the next certificate, and (4) wrap-up. Steps (1) and (4) are + performed exactly once. Step (2) is performed for all certificates + in the path. Step (3) is performed for all certificates in the path + except the final certificate. Figure 2 provides a high-level + flowchart of this algorithm. + + + + + + + + + + + + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 65] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + +-------+ + | START | + +-------+ + | + V + +----------------+ + | Initialization | + +----------------+ + | + +<--------------------+ + | | + V | + +----------------+ | + | Process Cert | | + +----------------+ | + | | + V | + +================+ | + | IF Last Cert | | + | in Path | | + +================+ | + | | | + THEN | | ELSE | + V V | + +----------------+ +----------------+ | + | Wrap up | | Prepare for | | + +----------------+ | Next Cert | | + | +----------------+ | + V | | + +-------+ +--------------+ + | STOP | + +-------+ + + + Figure 2. Certification Path Processing Flowchart + +6.1.1 Inputs + + This algorithm assumes the following seven inputs are provided to the + path processing logic: + + (a) a prospective certification path of length n. + + (b) the current date/time. + + + + + + + +Housley, et. al. Standards Track [Page 66] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (c) user-initial-policy-set: A set of certificate policy + identifiers naming the policies that are acceptable to the + certificate user. The user-initial-policy-set contains the + special value any-policy if the user is not concerned about + certificate policy. + + (d) trust anchor information, describing a CA that serves as a + trust anchor for the certification path. The trust anchor + information includes: + + (1) the trusted issuer name, + + (2) the trusted public key algorithm, + + (3) the trusted public key, and + + (4) optionally, the trusted public key parameters associated + with the public key. + + The trust anchor information may be provided to the path + processing procedure in the form of a self-signed certificate. + The trusted anchor information is trusted because it was delivered + to the path processing procedure by some trustworthy out-of-band + procedure. If the trusted public key algorithm requires + parameters, then the parameters are provided along with the + trusted public key. + + (e) initial-policy-mapping-inhibit, which indicates if policy + mapping is allowed in the certification path. + + (f) initial-explicit-policy, which indicates if the path must be + valid for at least one of the certificate policies in the user- + initial-policy-set. + + (g) initial-any-policy-inhibit, which indicates whether the + anyPolicy OID should be processed if it is included in a + certificate. + +6.1.2 Initialization + + This initialization phase establishes eleven state variables based + upon the seven inputs: + + (a) valid_policy_tree: A tree of certificate policies with their + optional qualifiers; each of the leaves of the tree represents a + valid policy at this stage in the certification path validation. + If valid policies exist at this stage in the certification path + validation, the depth of the tree is equal to the number of + + + +Housley, et. al. Standards Track [Page 67] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + certificates in the chain that have been processed. If valid + policies do not exist at this stage in the certification path + validation, the tree is set to NULL. Once the tree is set to + NULL, policy processing ceases. + + Each node in the valid_policy_tree includes four data objects: the + valid policy, a set of associated policy qualifiers, a set of one + or more expected policy values, and a criticality indicator. If + the node is at depth x, the components of the node have the + following semantics: + + (1) The valid_policy is a single policy OID representing a + valid policy for the path of length x. + + (2) The qualifier_set is a set of policy qualifiers associated + with the valid policy in certificate x. + + (3) The criticality_indicator indicates whether the + certificate policy extension in certificate x was marked as + critical. + + (4) The expected_policy_set contains one or more policy OIDs + that would satisfy this policy in the certificate x+1. + + The initial value of the valid_policy_tree is a single node with + valid_policy anyPolicy, an empty qualifier_set, an + expected_policy_set with the single value anyPolicy, and a + criticality_indicator of FALSE. This node is considered to be at + depth zero. + + Figure 3 is a graphic representation of the initial state of the + valid_policy_tree. Additional figures will use this format to + describe changes in the valid_policy_tree during path processing. + + +----------------+ + | anyPolicy | <---- valid_policy + +----------------+ + | {} | <---- qualifier_set + +----------------+ + | FALSE | <---- criticality_indicator + +----------------+ + | {anyPolicy} | <---- expected_policy_set + +----------------+ + + Figure 3. Initial value of the valid_policy_tree state variable + + + + + + +Housley, et. al. Standards Track [Page 68] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (b) permitted_subtrees: A set of root names for each name type + (e.g., X.500 distinguished names, email addresses, or ip + addresses) defining a set of subtrees within which all subject + names in subsequent certificates in the certification path MUST + fall. This variable includes a set for each name type: the + initial value for the set for Distinguished Names is the set of + all Distinguished names; the initial value for the set of RFC822 + names is the set of all RFC822 names, etc. + + (c) excluded_subtrees: A set of root names for each name type + (e.g., X.500 distinguished names, email addresses, or ip + addresses) defining a set of subtrees within which no subject name + in subsequent certificates in the certification path may fall. + This variable includes a set for each name type, and the initial + value for each set is empty. + + (d) explicit_policy: an integer which indicates if a non-NULL + valid_policy_tree is required. The integer indicates the number of + non-self-issued certificates to be processed before this + requirement is imposed. Once set, this variable may be decreased, + but may not be increased. That is, if a certificate in the path + requires a non-NULL valid_policy_tree, a later certificate can not + remove this requirement. If initial-explicit-policy is set, then + the initial value is 0, otherwise the initial value is n+1. + + (e) inhibit_any-policy: an integer which indicates whether the + anyPolicy policy identifier is considered a match. The integer + indicates the number of non-self-issued certificates to be + processed before the anyPolicy OID, if asserted in a certificate, + is ignored. Once set, this variable may be decreased, but may not + be increased. That is, if a certificate in the path inhibits + processing of anyPolicy, a later certificate can not permit it. + If initial-any-policy-inhibit is set, then the initial value is 0, + otherwise the initial value is n+1. + + (f) policy_mapping: an integer which indicates if policy mapping + is permitted. The integer indicates the number of non-self-issued + certificates to be processed before policy mapping is inhibited. + Once set, this variable may be decreased, but may not be + increased. That is, if a certificate in the path specifies policy + mapping is not permitted, it can not be overridden by a later + certificate. If initial-policy-mapping-inhibit is set, then the + initial value is 0, otherwise the initial value is n+1. + + (g) working_public_key_algorithm: the digital signature algorithm + used to verify the signature of a certificate. The + working_public_key_algorithm is initialized from the trusted + public key algorithm provided in the trust anchor information. + + + +Housley, et. al. Standards Track [Page 69] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (h) working_public_key: the public key used to verify the + signature of a certificate. The working_public_key is initialized + from the trusted public key provided in the trust anchor + information. + + (i) working_public_key_parameters: parameters associated with the + current public key, that may be required to verify a signature + (depending upon the algorithm). The working_public_key_parameters + variable is initialized from the trusted public key parameters + provided in the trust anchor information. + + (j) working_issuer_name: the issuer distinguished name expected + in the next certificate in the chain. The working_issuer_name is + initialized to the trusted issuer provided in the trust anchor + information. + + (k) max_path_length: this integer is initialized to n, is + decremented for each non-self-issued certificate in the path, and + may be reduced to the value in the path length constraint field + within the basic constraints extension of a CA certificate. + + Upon completion of the initialization steps, perform the basic + certificate processing steps specified in 6.1.3. + +6.1.3 Basic Certificate Processing + + The basic path processing actions to be performed for certificate i + (for all i in [1..n]) are listed below. + + (a) Verify the basic certificate information. The certificate + MUST satisfy each of the following: + + (1) The certificate was signed with the + working_public_key_algorithm using the working_public_key and + the working_public_key_parameters. + + (2) The certificate validity period includes the current time. + + (3) At the current time, the certificate is not revoked and is + not on hold status. This may be determined by obtaining the + appropriate CRL (section 6.3), status information, or by out- + of-band mechanisms. + + (4) The certificate issuer name is the working_issuer_name. + + + + + + + +Housley, et. al. Standards Track [Page 70] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (b) If certificate i is self-issued and it is not the final + certificate in the path, skip this step for certificate i. + Otherwise, verify that the subject name is within one of the + permitted_subtrees for X.500 distinguished names, and verify that + each of the alternative names in the subjectAltName extension + (critical or non-critical) is within one of the permitted_subtrees + for that name type. + + (c) If certificate i is self-issued and it is not the final + certificate in the path, skip this step for certificate i. + Otherwise, verify that the subject name is not within one of the + excluded_subtrees for X.500 distinguished names, and verify that + each of the alternative names in the subjectAltName extension + (critical or non-critical) is not within one of the + excluded_subtrees for that name type. + + (d) If the certificate policies extension is present in the + certificate and the valid_policy_tree is not NULL, process the + policy information by performing the following steps in order: + + (1) For each policy P not equal to anyPolicy in the + certificate policies extension, let P-OID denote the OID in + policy P and P-Q denote the qualifier set for policy P. + Perform the following steps in order: + + (i) If the valid_policy_tree includes a node of depth i-1 + where P-OID is in the expected_policy_set, create a child + node as follows: set the valid_policy to OID-P; set the + qualifier_set to P-Q, and set the expected_policy_set to + {P-OID}. + + For example, consider a valid_policy_tree with a node of + depth i-1 where the expected_policy_set is {Gold, White}. + Assume the certificate policies Gold and Silver appear in + the certificate policies extension of certificate i. The + Gold policy is matched but the Silver policy is not. This + rule will generate a child node of depth i for the Gold + policy. The result is shown as Figure 4. + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 71] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + +-----------------+ + | Red | + +-----------------+ + | {} | + +-----------------+ node of depth i-1 + | FALSE | + +-----------------+ + | {Gold, White} | + +-----------------+ + | + | + | + V + +-----------------+ + | Gold | + +-----------------+ + | {} | + +-----------------+ node of depth i + | uninitialized | + +-----------------+ + | {Gold} | + +-----------------+ + + Figure 4. Processing an exact match + + (ii) If there was no match in step (i) and the + valid_policy_tree includes a node of depth i-1 with the + valid policy anyPolicy, generate a child node with the + following values: set the valid_policy to P-OID; set the + qualifier_set to P-Q, and set the expected_policy_set to + {P-OID}. + + For example, consider a valid_policy_tree with a node of + depth i-1 where the valid_policy is anyPolicy. Assume the + certificate policies Gold and Silver appear in the + certificate policies extension of certificate i. The Gold + policy does not have a qualifier, but the Silver policy has + the qualifier Q-Silver. If Gold and Silver were not matched + in (i) above, this rule will generate two child nodes of + depth i, one for each policy. The result is shown as Figure + 5. + + + + + + + + + + +Housley, et. al. Standards Track [Page 72] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + +-----------------+ + | anyPolicy | + +-----------------+ + | {} | + +-----------------+ node of depth i-1 + | FALSE | + +-----------------+ + | {anyPolicy} | + +-----------------+ + / \ + / \ + / \ + / \ + +-----------------+ +-----------------+ + | Gold | | Silver | + +-----------------+ +-----------------+ + | {} | | {Q-Silver} | + +-----------------+ nodes of +-----------------+ + | uninitialized | depth i | uninitialized | + +-----------------+ +-----------------+ + | {Gold} | | {Silver} | + +-----------------+ +-----------------+ + + Figure 5. Processing unmatched policies when a leaf node + specifies anyPolicy + + (2) If the certificate policies extension includes the policy + anyPolicy with the qualifier set AP-Q and either (a) + inhibit_any-policy is greater than 0 or (b) i. The + binaries for the certificates and CRLs are available at + . + +C.1 Certificate + + This section contains an annotated hex dump of a 699 byte version 3 + certificate. The certificate contains the following information: + (a) the serial number is 23 (17 hex); + + + +Housley, et. al. Standards Track [Page 115] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (b) the certificate is signed with DSA and the SHA-1 hash algorithm; + (c) the issuer's distinguished name is OU=NIST; O=gov; C=US + (d) and the subject's distinguished name is OU=NIST; O=gov; C=US + (e) the certificate was issued on June 30, 1997 and will expire on + December 31, 1997; + (f) the certificate contains a 1024 bit DSA public key with + parameters; + (g) the certificate contains a subject key identifier extension + generated using method (1) of section 4.2.1.2; and + (h) the certificate is a CA certificate (as indicated through the + basic constraints extension.) + + 0 30 699: SEQUENCE { + 4 30 635: SEQUENCE { + 8 A0 3: [0] { + 10 02 1: INTEGER 2 + : } + 13 02 1: INTEGER 17 + 16 30 9: SEQUENCE { + 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } + 27 30 42: SEQUENCE { + 29 31 11: SET { + 31 30 9: SEQUENCE { + 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 38 13 2: PrintableString 'US' + : } + : } + 42 31 12: SET { + 44 30 10: SEQUENCE { + 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) + 51 13 3: PrintableString 'gov' + : } + : } + 56 31 13: SET { + 58 30 11: SEQUENCE { + 60 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 65 13 4: PrintableString 'NIST' + : } + : } + : } + 71 30 30: SEQUENCE { + 73 17 13: UTCTime '970630000000Z' + 88 17 13: UTCTime '971231000000Z' + : } +103 30 42: SEQUENCE { +105 31 11: SET { + + + +Housley, et. al. Standards Track [Page 116] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +107 30 9: SEQUENCE { +109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) +114 13 2: PrintableString 'US' + : } + : } +118 31 12: SET { +120 30 10: SEQUENCE { +122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) +127 13 3: PrintableString 'gov' + : } + : } +132 31 13: SET { +134 30 11: SEQUENCE { +136 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) +141 13 4: PrintableString 'NIST' + : } + : } + : } +147 30 440: SEQUENCE { +151 30 300: SEQUENCE { +155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) +164 30 287: SEQUENCE { +168 02 129: INTEGER + : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC + : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC + : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F + : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 + : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A + : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD + : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E + : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A + : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 + : 63 FE 43 +300 02 21: INTEGER + : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA + : 55 F7 7D 57 74 81 E5 +323 02 129: INTEGER + : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 + : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 + : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 + : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC + : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A + : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C + : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 + : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF + : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE + : 1E 57 18 + + + +Housley, et. al. Standards Track [Page 117] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + : } + : } +455 03 133: BIT STRING 0 unused bits, encapsulates { +459 02 129: INTEGER + : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 + : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 + : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 + : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D + : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 + : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 + : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E + : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A + : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 + : 7B C9 55 + : } + : } +591 A3 50: [3] { +593 30 48: SEQUENCE { +595 30 29: SEQUENCE { +597 06 3: OBJECT IDENTIFIER + : subjectKeyIdentifier (2 5 29 14) +602 04 22: OCTET STRING, encapsulates { +604 04 20: OCTET STRING + : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 + : 2C 29 49 F4 86 56 + : } + : } +626 30 15: SEQUENCE { +628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) +633 01 1: BOOLEAN TRUE +636 04 5: OCTET STRING, encapsulates { +638 30 3: SEQUENCE { +640 01 1: BOOLEAN TRUE + : } + : } + : } + : } + : } + : } +643 30 9: SEQUENCE { +645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } +654 03 47: BIT STRING 0 unused bits, encapsulates { +657 30 44: SEQUENCE { +659 02 20: INTEGER + : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 + : 66 4C 83 CF 2D 77 +681 02 20: INTEGER + + + +Housley, et. al. Standards Track [Page 118] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 + : E1 8D A5 CC 3A D4 + : } + : } + : } + +C.2 Certificate + + This section contains an annotated hex dump of a 730 byte version 3 + certificate. The certificate contains the following information: + (a) the serial number is 18 (12 hex); + (b) the certificate is signed with DSA and the SHA-1 hash algorithm; + (c) the issuer's distinguished name is OU=nist; O=gov; C=US + (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; + O=gov; C=US + (e) the certificate was valid from July 30, 1997 through December 1, + 1997; + (f) the certificate contains a 1024 bit DSA public key; + (g) the certificate is an end entity certificate, as the basic + constraints extension is not present; + (h) the certificate contains an authority key identifier extension + matching the subject key identifier of the certificate in Appendix + C.1; and + (i) the certificate includes one alternative name - an RFC 822 + address of "wpolk@nist.gov". + + 0 30 730: SEQUENCE { + 4 30 665: SEQUENCE { + 8 A0 3: [0] { + 10 02 1: INTEGER 2 + : } + 13 02 1: INTEGER 18 + 16 30 9: SEQUENCE { + 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } + 27 30 42: SEQUENCE { + 29 31 11: SET { + 31 30 9: SEQUENCE { + 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 38 13 2: PrintableString 'US' + : } + : } + 42 31 12: SET { + 44 30 10: SEQUENCE { + 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) + 51 13 3: PrintableString 'gov' + : } + : } + + + +Housley, et. al. Standards Track [Page 119] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + 56 31 13: SET { + 58 30 11: SEQUENCE { + 60 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 65 13 4: PrintableString 'NIST' + : } + : } + : } + 71 30 30: SEQUENCE { + 73 17 13: UTCTime '970730000000Z' + 88 17 13: UTCTime '971201000000Z' + : } + 103 30 61: SEQUENCE { + 105 31 11: SET { + 107 30 9: SEQUENCE { + 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 114 13 2: PrintableString 'US' + : } + : } + 118 31 12: SET { + 120 30 10: SEQUENCE { + 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) + 127 13 3: PrintableString 'gov' + : } + : } + 132 31 13: SET { + 134 30 11: SEQUENCE { + 136 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 141 13 4: PrintableString 'NIST' + : } + : } + 147 31 17: SET { + 149 30 15: SEQUENCE { + 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 156 13 8: PrintableString 'Tim Polk' + : } + : } + : } + 166 30 439: SEQUENCE { + 170 30 300: SEQUENCE { + 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) + 183 30 287: SEQUENCE { + 187 02 129: INTEGER + : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC + : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC + : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F + : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 + + + +Housley, et. al. Standards Track [Page 120] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A + : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD + : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E + : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A + : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 + : 63 FE 43 + 319 02 21: INTEGER + : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA + : 55 F7 7D 57 74 81 E5 + 342 02 129: INTEGER + : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 + : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 + : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 + : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC + : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A + : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C + : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 + : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF + : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE + : 1E 57 18 + : } + : } + 474 03 132: BIT STRING 0 unused bits, encapsulates { + 478 02 128: INTEGER + : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB + : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C + : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 + : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A + : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7 + : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61 + : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24 + : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC + : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 + : 95 BE + : } + : } + 609 A3 62: [3] { + 611 30 60: SEQUENCE { + 613 30 25: SEQUENCE { + 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) + 620 04 18: OCTET STRING, encapsulates { + 622 30 16: SEQUENCE { + 624 81 14: [1] 'wpolk@nist.gov' + : } + : } + : } + 640 30 31: SEQUENCE { + 642 06 3: OBJECT IDENTIFIER + + + +Housley, et. al. Standards Track [Page 121] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + : authorityKeyIdentifier (2 5 29 35) + 647 04 24: OCTET STRING, encapsulates { + 649 30 22: SEQUENCE { + 651 80 20: [0] + : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 + : 41 2C 29 49 F4 86 56 + : } + : } + : } + : } + : } + : } + 673 30 9: SEQUENCE { + 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } + 684 03 48: BIT STRING 0 unused bits, encapsulates { + 687 30 45: SEQUENCE { + 689 02 20: INTEGER + : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC + : 22 92 9F F4 F5 87 + 711 02 21: INTEGER + : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 + : B4 A0 2E FF 22 5A 73 + : } + : } + : } + +C.3 End Entity Certificate Using RSA + + This section contains an annotated hex dump of a 654 byte version 3 + certificate. The certificate contains the following information: + (a) the serial number is 256; + (b) the certificate is signed with RSA and the SHA-1 hash algorithm; + (c) the issuer's distinguished name is OU=NIST; O=gov; C=US + (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; + O=gov; C=US + (e) the certificate was issued on May 21, 1996 at 09:58:26 and + expired on May 21, 1997 at 09:58:26; + (f) the certificate contains a 1024 bit RSA public key; + (g) the certificate is an end entity certificate (not a CA + certificate); + (h) the certificate includes an alternative subject name of + "" and an + alternative issuer name of "" - both are URLs; + (i) the certificate include an authority key identifier extension + and a certificate policies extension specifying the policy OID + 2.16.840.1.101.3.2.1.48.9; and + + + + +Housley, et. al. Standards Track [Page 122] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + (j) the certificate includes a critical key usage extension + specifying that the public key is intended for verification of + digital signatures. + + 0 30 654: SEQUENCE { + 4 30 503: SEQUENCE { + 8 A0 3: [0] { + 10 02 1: INTEGER 2 + : } + 13 02 2: INTEGER 256 + 17 30 13: SEQUENCE { + 19 06 9: OBJECT IDENTIFIER + : sha1withRSAEncryption (1 2 840 113549 1 1 5) + 30 05 0: NULL + : } + 32 30 42: SEQUENCE { + 34 31 11: SET { + 36 30 9: SEQUENCE { + 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 43 13 2: PrintableString 'US' + : } + : } + 47 31 12: SET { + 49 30 10: SEQUENCE { + 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) + 56 13 3: PrintableString 'gov' + : } + : } + 61 31 13: SET { + 63 30 11: SEQUENCE { + 65 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 70 13 4: PrintableString 'NIST' + : } + : } + : } + 76 30 30: SEQUENCE { + 78 17 13: UTCTime '960521095826Z' + 93 17 13: UTCTime '970521095826Z' + : } +108 30 61: SEQUENCE { +110 31 11: SET { +112 30 9: SEQUENCE { +114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) +119 13 2: PrintableString 'US' + : } + : } +123 31 12: SET { + + + +Housley, et. al. Standards Track [Page 123] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +125 30 10: SEQUENCE { +127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) +132 13 3: PrintableString 'gov' + : } + : } +137 31 13: SET { +139 30 11: SEQUENCE { +141 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) +146 13 4: PrintableString 'NIST' + : } + : } +152 31 17: SET { +154 30 15: SEQUENCE { +156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) +161 13 8: PrintableString 'Tim Polk' + : } + : } + : } +171 30 159: SEQUENCE { +174 30 13: SEQUENCE { +176 06 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) +187 05 0: NULL + : } +189 03 141: BIT STRING 0 unused bits, encapsulates { +193 30 137: SEQUENCE { +196 02 129: INTEGER + : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E + : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 + : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77 + : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D + : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A + : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9 + : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36 + : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 + : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 + : 95 FF 23 +328 02 3: INTEGER 65537 + : } + : } + : } +333 A3 175: [3] { +336 30 172: SEQUENCE { +339 30 63: SEQUENCE { +341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) +346 04 56: OCTET STRING, encapsulates { +348 30 54: SEQUENCE { + + + +Housley, et. al. Standards Track [Page 124] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +350 86 52: [6] + : 'http://www.itl.nist.gov/div893/staff/' + : 'polk/index.html' + : } + : } + : } +404 30 31: SEQUENCE { +406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) +411 04 24: OCTET STRING, encapsulates { +413 30 22: SEQUENCE { +415 86 20: [6] 'http://www.nist.gov/' + : } + : } + : } +437 30 31: SEQUENCE { +439 06 3: OBJECT IDENTIFIER + : authorityKeyIdentifier (2 5 29 35) +444 04 24: OCTET STRING, encapsulates { +446 30 22: SEQUENCE { +448 80 20: [0] + : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E + : 70 6A 4A 20 84 2C 32 + : } + : } + : } +470 30 23: SEQUENCE { +472 06 3: OBJECT IDENTIFIER + : certificatePolicies (2 5 29 32) +477 04 16: OCTET STRING, encapsulates { +479 30 14: SEQUENCE { +481 30 12: SEQUENCE { +483 06 10: OBJECT IDENTIFIER + : '2 16 840 1 101 3 2 1 48 9' + : } + : } + : } + : } +495 30 14: SEQUENCE { +497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) +502 01 1: BOOLEAN TRUE +505 04 4: OCTET STRING, encapsulates { +507 03 2: BIT STRING 7 unused bits + : '1'B (bit 0) + : } + : } + : } + : } + : } + + + +Housley, et. al. Standards Track [Page 125] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +511 30 13: SEQUENCE { +513 06 9: OBJECT IDENTIFIER + : sha1withRSAEncryption (1 2 840 113549 1 1 5) +524 05 0: NULL + : } +526 03 129: BIT STRING 0 unused bits + : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 + : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 + : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 + : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE + : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 + : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 + : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 + : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 + : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B + : 77 F3 + : } + +C.4 Certificate Revocation List + + This section contains an annotated hex dump of a version 2 CRL with + one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; + C=US on August 7, 1997; the next scheduled issuance was September 7, + 1997. The CRL includes one revoked certificates: serial number 18 + (12 hex), which was revoked on July 31, 1997 due to keyCompromise. + The CRL itself is number 18, and it was signed with DSA and SHA-1. + + 0 30 203: SEQUENCE { + 3 30 140: SEQUENCE { + 6 02 1: INTEGER 1 + 9 30 9: SEQUENCE { + 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } + 20 30 42: SEQUENCE { + 22 31 11: SET { + 24 30 9: SEQUENCE { + 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 31 13 2: PrintableString 'US' + : } + : } + 35 31 12: SET { + 37 30 10: SEQUENCE { + 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) + 44 13 3: PrintableString 'gov' + : } + : } + 49 31 13: SET { + 51 30 11: SEQUENCE { + + + +Housley, et. al. Standards Track [Page 126] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + + 53 06 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 58 13 4: PrintableString 'NIST' + : } + : } + : } + 64 17 13: UTCTime '970807000000Z' + 79 17 13: UTCTime '970907000000Z' + 94 30 34: SEQUENCE { + 96 30 32: SEQUENCE { + 98 02 1: INTEGER 18 +101 17 13: UTCTime '970731000000Z' +116 30 12: SEQUENCE { +118 30 10: SEQUENCE { +120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) +125 04 3: OCTET STRING, encapsulates { +127 0A 1: ENUMERATED 1 + : } + : } + : } + : } + : } +130 A0 14: [0] { +132 30 12: SEQUENCE { +134 30 10: SEQUENCE { +136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) +141 04 3: OCTET STRING, encapsulates { +143 02 1: INTEGER 12 + : } + : } + : } + : } + : } +146 30 9: SEQUENCE { +148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) + : } +157 03 47: BIT STRING 0 unused bits, encapsulates { +160 30 44: SEQUENCE { +162 02 20: INTEGER + : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 + : 80 05 C0 3A 29 47 +184 02 20: INTEGER + : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B + : 96 16 B1 1F 46 5A + : } + : } + : } + + + + +Housley, et. al. Standards Track [Page 127] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +Author Addresses + + Russell Housley + RSA Laboratories + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + + EMail: rhousley@rsasecurity.com + + Warwick Ford + VeriSign, Inc. + 401 Edgewater Place + Wakefield, MA 01880 + USA + + EMail: wford@verisign.com + + Tim Polk + NIST + Building 820, Room 426 + Gaithersburg, MD 20899 + USA + + EMail: wpolk@nist.gov + + David Solo + Citigroup + 909 Third Ave, 16th Floor + New York, NY 10043 + USA + + EMail: dsolo@alum.mit.edu + + + + + + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 128] + +RFC 3280 Internet X.509 Public Key Infrastructure April 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Housley, et. al. Standards Track [Page 129] + diff --git a/doc/standardisation/rfc3281.txt b/doc/standardisation/rfc3281.txt new file mode 100644 index 000000000..91266ee98 --- /dev/null +++ b/doc/standardisation/rfc3281.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group S. Farrell +Request for Comments: 3281 Baltimore Technologies +Category: Standards Track R. Housley + RSA Laboratories + April 2002 + + + An Internet Attribute Certificate + Profile for Authorization + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This specification defines a profile for the use of X.509 Attribute + Certificates in Internet Protocols. Attribute certificates may be + used in a wide range of applications and environments covering a + broad spectrum of interoperability goals and a broader spectrum of + operational and assurance requirements. The goal of this document is + to establish a common baseline for generic applications requiring + broad interoperability as well as limited special purpose + requirements. The profile places emphasis on attribute certificate + support for Internet electronic mail, IPSec, and WWW security + applications. + +Table of Contents + + 1. Introduction................................................. 2 + 1.1 Delegation and AC chains............................... 4 + 1.2 Attribute Certificate Distribution ("push" vs. "pull"). 4 + 1.3 Document Structure..................................... 6 + 2. Terminology.................................................. 6 + 3. Requirements................................................. 7 + 4. Attribute Certificate Profile................................ 7 + 4.1 X.509 Attribute Certificate Definition................. 8 + 4.2 Profile of Standard Fields............................. 10 + 4.2.1 Version.......................................... 10 + 4.2.2 Holder........................................... 11 + + + +Farrell & Housley Standards Track [Page 1] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + 4.2.3 Issuer........................................... 12 + 4.2.4 Signature........................................ 12 + 4.2.5 Serial Number.................................... 12 + 4.2.6 Validity Period.................................. 13 + 4.2.7 Attributes....................................... 13 + 4.2.8 Issuer Unique Identifier......................... 14 + 4.2.9 Extensions....................................... 14 + 4.3 Extensions............................................. 14 + 4.3.1 Audit Identity................................... 14 + 4.3.2 AC Targeting..................................... 15 + 4.3.3 Authority Key Identifier......................... 17 + 4.3.4 Authority Information Access..................... 17 + 4.3.5 CRL Distribution Points.......................... 17 + 4.3.6 No Revocation Available.......................... 18 + 4.4 Attribute Types........................................ 18 + 4.4.1 Service Authentication Information............... 19 + 4.4.2 Access Identity.................................. 19 + 4.4.3 Charging Identity................................ 20 + 4.4.4 Group............................................ 20 + 4.4.5 Role............................................. 20 + 4.4.6 Clearance........................................ 21 + 4.5 Profile of AC issuer's PKC............................. 22 + 5. Attribute Certificate Validation............................. 23 + 6. Revocation................................................... 24 + 7. Optional Features............................................ 25 + 7.1 Attribute Encryption................................... 25 + 7.2 Proxying............................................... 27 + 7.3 Use of ObjectDigestInfo................................ 28 + 7.4 AA Controls............................................ 29 + 8. Security Considerations...................................... 30 + 9. IANA Considerations.......................................... 32 + 10. References.................................................. 32 + Appendix A: Object Identifiers.................................. 34 + Appendix B: ASN.1 Module........................................ 35 + Author's Addresses.............................................. 39 + Acknowledgements................................................ 39 + Full Copyright Statement........................................ 40 + +1. Introduction + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119. + + X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, + PKIXPROF] bind an identity and a public key. An attribute + certificate (AC) is a structure similar to a PKC; the main difference + being that the AC contains no public key. An AC may contain + + + +Farrell & Housley Standards Track [Page 2] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + attributes that specify group membership, role, security clearance, + or other authorization information associated with the AC holder. + The syntax for the AC is defined in Recommendation X.509, making the + term "X.509 certificate" ambiguous. + + Some people constantly confuse PKCs and ACs. An analogy may make the + distinction clear. A PKC can be considered to be like a passport: it + identifies the holder, tends to last for a long time, and should not + be trivial to obtain. An AC is more like an entry visa: it is + typically issued by a different authority and does not last for as + long a time. As acquiring an entry visa typically requires + presenting a passport, getting a visa can be a simpler process. + + Authorization information may be placed in a PKC extension or placed + in a separate attribute certificate (AC). The placement of + authorization information in PKCs is usually undesirable for two + reasons. First, authorization information often does not have the + same lifetime as the binding of the identity and the public key. + When authorization information is placed in a PKC extension, the + general result is the shortening of the PKC useful lifetime. Second, + the PKC issuer is not usually authoritative for the authorization + information. This results in additional steps for the PKC issuer to + obtain authorization information from the authoritative source. + + For these reasons, it is often better to separate authorization + information from the PKC. Yet, authorization information also needs + to be bound to an identity. An AC provides this binding; it is + simply a digitally signed (or certified) identity and set of + attributes. + + An AC may be used with various security services, including access + control, data origin authentication, and non-repudiation. + + PKCs can provide an identity to access control decision functions. + However, in many contexts the identity is not the criterion that is + used for access control decisions, rather the role or group- + membership of the accessor is the criterion used. Such access + control schemes are called role-based access control. + + When making an access control decision based on an AC, an access + control decision function may need to ensure that the appropriate AC + holder is the entity that has requested access. One way in which the + linkage between the request or identity and the AC can be achieved is + the inclusion of a reference to a PKC within the AC and the use of + the private key corresponding to the PKC for authentication within + the access request. + + + + + +Farrell & Housley Standards Track [Page 3] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + ACs may also be used in the context of a data origin authentication + service and a non-repudiation service. In these contexts, the + attributes contained in the AC provide additional information about + the signing entity. This information can be used to make sure that + the entity is authorized to sign the data. This kind of checking + depends either on the context in which the data is exchanged or on + the data that has been digitally signed. + +1.1 Delegation and AC chains + + The X.509 standard [X.509-2000] defines authorization as the + "conveyance of privilege from one entity that holds such privilege, + to another entity". An AC is one authorization mechanism. + + An ordered sequence of ACs could be used to verify the authenticity + of a privilege asserter's privilege. In this way, chains or paths of + ACs could be employed to delegate authorization. + + Since the administration and processing associated with such AC + chains is complex and the use of ACs in the Internet today is quite + limited, this specification does NOT RECOMMEND the use of AC chains. + Other (future) specifications may address the use of AC chains. This + specification deals with the simple cases, where one authority issues + all of the ACs for a particular set of attributes. However, this + simplification does not preclude the use of several different + authorities, each of which manages a different set of attributes. + For example, group membership may be included in one AC issued by one + authority, and security clearance may be included in another AC + issued by another authority. + + This means that conformant implementations are only REQUIRED to be + able to process a single AC at a time. Processing of more than one + AC, one after another, may be necessary. Note however, that + validation of an AC MAY require validation of a chain of PKCs, as + specified in [PKIXPROF]. + +1.2 Attribute Certificate Distribution ("push" vs. "pull") + + As discussed above, ACs provide a mechanism to securely provide + authorization information to, for example, access control decision + functions. However, there are a number of possible communication + paths for ACs. + + In some environments, it is suitable for a client to "push" an AC to + a server. This means that no new connections between the client and + server are required. It also means that no search burden is imposed + on servers, which improves performance and that the AC verifier is + + + + +Farrell & Housley Standards Track [Page 4] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + only presented with what it "needs to know." The "push" model is + especially suitable in inter-domain cases where the client's rights + should be assigned within the client's "home" domain. + + In other cases, it is more suitable for a client to simply + authenticate to the server and for the server to request or "pull" + the client's AC from an AC issuer or a repository. A major benefit + of the "pull" model is that it can be implemented without changes to + the client or to the client-server protocol. The "pull" model is + especially suitable for inter-domain cases where the client's rights + should be assigned within the server's domain, rather than within the + client's domain. + + There are a number of possible exchanges involving three entities: + the client, the server, and the AC issuer. In addition, a directory + service or other repository for AC retrieval MAY be supported. + + Figure 1 shows an abstract view of the exchanges that may involve + ACs. This profile does not specify a protocol for these exchanges. + + +--------------+ + | | Server Acquisition + | AC issuer +----------------------------+ + | | | + +--+-----------+ | + | | + | Client | + | Acquisition | + | | + +--+-----------+ +--+------------+ + | | AC "push" | | + | Client +-------------------------+ Server | + | | (part of app. protocol) | | + +--+-----------+ +--+------------+ + | | + | Client | Server + | Lookup +--------------+ | Lookup + | | | | + +---------------+ Repository +---------+ + | | + +--------------+ + + Figure 1: AC Exchanges + + + + + + + + +Farrell & Housley Standards Track [Page 5] + +RFC 3281 An Internet Attribute Certificate April 2002 + + +1.3 Document Structure + + Section 2 defines some terminology. Section 3 specifies the + requirements that this profile is intended to meet. Section 4 + contains the profile of the X.509 AC. Section 5 specifies rules for + AC validation. Section 6 specifies rules for AC revocation checks. + Section 7 specifies optional features which MAY be supported; + however, support for these features is not required for conformance + to this profile. Finally, appendices contain the list of OIDs + required to support this specification and an ASN.1 module. + +2. Terminology + + For simplicity, we use the terms client and server in this + specification. This is not intended to indicate that ACs are only to + be used in client-server environments. For example, ACs may be used + in the S/MIME v3 context, where the mail user agent would be both a + "client" and a "server" in the sense the terms are used here. + + Term Meaning + + AA Attribute Authority, the entity that issues the + AC, synonymous in this specification with "AC + issuer" + AC Attribute Certificate + AC user any entity that parses or processes an AC + AC verifier any entity that checks the validity of an AC and + then makes use of the result + AC issuer the entity which signs the AC, synonymous in this + specification with "AA" + AC holder the entity indicated (perhaps indirectly) in the + holder field of the AC + Client the entity which is requesting the action for + which authorization checks are to be made + Proxying In this specification, Proxying is used to mean + the situation where an application server acts as + an application client on behalf of a user. + Proxying here does not mean granting of authority. + PKC Public Key Certificate - uses the type ASN.1 + Certificate defined in X.509 and profiled in RFC + 2459. This (non-standard) acronym is used in order + to avoid confusion about the term "X.509 + certificate". + Server the entity which requires that the authorization + checks are made + + + + + + +Farrell & Housley Standards Track [Page 6] + +RFC 3281 An Internet Attribute Certificate April 2002 + + +3. Requirements + + This AC profile meets the following requirements. + + Time/Validity requirements: + + 1. Support for short-lived as well as long-lived ACs. Typical + short-lived validity periods might be measured in hours, as + opposed to months for PKCs. Short validity periods allow ACs to + be useful without a revocation mechanism. + + Attribute Types: + + 2. Issuers of ACs should be able to define their own attribute types + for use within closed domains. + + 3. Some standard attribute types, which can be contained within ACs, + should be defined. Examples include "access identity," "group," + "role," "clearance," "audit identity," and "charging identity." + + 4. Standard attribute types should be defined in a manner that + permits an AC verifier to distinguish between uses of the same + attribute in different domains. For example, the "Administrators + group" as defined by Baltimore and the "Administrators group" as + defined by SPYRUS should be easily distinguished. + + Targeting of ACs: + + 5. It should be possible to "target" an AC at one, or a small number + of, servers. This means that a trustworthy non-target server will + reject the AC for authorization decisions. + + Push vs. Pull + + 6. ACs should be defined so that they can either be "pushed" by the + client to the server, or "pulled" by the server from a repository + or other network service, including an online AC issuer. + +4. Attribute Certificate Profile + + ACs may be used in a wide range of applications and environments + covering a broad spectrum of interoperability goals and a broader + spectrum of operational and assurance requirements. The goal of this + document is to establish a common baseline for generic applications + requiring broad interoperability and limited special purpose + + + + + + +Farrell & Housley Standards Track [Page 7] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + requirements. In particular, the emphasis will be on supporting the + use of attribute certificates for informal Internet electronic mail, + IPSec, and WWW applications. + + This section presents a profile for ACs that will foster + interoperability. This section also defines some private extensions + for the Internet community. + + While the ISO/IEC/ITU documents use the 1993 (or later) version of + ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for + PKCs [PKIXPROF]. The encoded certificates and extensions from either + ASN.1 version are bit-wise identical. + + Where maximum lengths for fields are specified, these lengths refer + to the DER encoding and do not include the ASN.1 tag or length + fields. + + Conforming implementations MUST support the profile specified in this + section. + +4.1 X.509 Attribute Certificate Definition + + X.509 contains the definition of an AC given below. All types that + are not defined in this document can be found in [PKIXPROF]. + + AttributeCertificate ::= SEQUENCE { + acinfo AttributeCertificateInfo, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING + } + + AttributeCertificateInfo ::= SEQUENCE { + version AttCertVersion -- version is v2, + holder Holder, + issuer AttCertIssuer, + signature AlgorithmIdentifier, + serialNumber CertificateSerialNumber, + attrCertValidityPeriod AttCertValidityPeriod, + attributes SEQUENCE OF Attribute, + issuerUniqueID UniqueIdentifier OPTIONAL, + extensions Extensions OPTIONAL + } + + AttCertVersion ::= INTEGER { v2(1) } + Holder ::= SEQUENCE { + baseCertificateID [0] IssuerSerial OPTIONAL, + -- the issuer and serial number of + -- the holder's Public Key Certificate + + + +Farrell & Housley Standards Track [Page 8] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + entityName [1] GeneralNames OPTIONAL, + -- the name of the claimant or role + objectDigestInfo [2] ObjectDigestInfo OPTIONAL + -- used to directly authenticate the holder, + -- for example, an executable + } + + ObjectDigestInfo ::= SEQUENCE { + digestedObjectType ENUMERATED { + publicKey (0), + publicKeyCert (1), + otherObjectTypes (2) }, + -- otherObjectTypes MUST NOT + -- be used in this profile + otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, + digestAlgorithm AlgorithmIdentifier, + objectDigest BIT STRING + } + + AttCertIssuer ::= CHOICE { + v1Form GeneralNames, -- MUST NOT be used in this + -- profile + v2Form [0] V2Form -- v2 only + } + + V2Form ::= SEQUENCE { + issuerName GeneralNames OPTIONAL, + baseCertificateID [0] IssuerSerial OPTIONAL, + objectDigestInfo [1] ObjectDigestInfo OPTIONAL + -- issuerName MUST be present in this profile + -- baseCertificateID and objectDigestInfo MUST NOT + -- be present in this profile + } + + IssuerSerial ::= SEQUENCE { + issuer GeneralNames, + serial CertificateSerialNumber, + issuerUID UniqueIdentifier OPTIONAL + } + + AttCertValidityPeriod ::= SEQUENCE { + notBeforeTime GeneralizedTime, + notAfterTime GeneralizedTime + } + + + + + + + +Farrell & Housley Standards Track [Page 9] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Although the Attribute syntax is defined in [PKIXPROF], we repeat + the definition here for convenience. + + Attribute ::= SEQUENCE { + type AttributeType, + values SET OF AttributeValue + -- at least one value is required + } + + AttributeType ::= OBJECT IDENTIFIER + + AttributeValue ::= ANY DEFINED BY AttributeType + + Implementers should note that the DER encoding (see [X.509- + 1988],[X.208-1988]) of the SET OF values requires ordering of the + encodings of the values. Though this issue arises with respect to + distinguished names, and has to be handled by [PKIXPROF] + implementations, it is much more significant in this context, since + the inclusion of multiple values is much more common in ACs. + +4.2 Profile of Standard Fields + + GeneralName offers great flexibility. To achieve interoperability, + in spite of this flexibility, this profile imposes constraints on the + use of GeneralName. + + Conforming implementations MUST be able to support the dNSName, + directoryName, uniformResourceIdentifier, and iPAddress options. + This is compatible with the GeneralName requirements in [PKIXPROF] + (mainly in section 4.2.1.7). + + Conforming implementations MUST NOT use the x400Address, + ediPartyName, or registeredID options. + + Conforming implementations MAY use the otherName option to convey + name forms defined in Internet Standards. For example, Kerberos + [KRB] format names can be encoded into the otherName, using a + Kerberos 5 principal name OID and a SEQUENCE of the Realm and the + PrincipalName. + +4.2.1 Version + + The version field MUST have the value of v2. That is, the version + field is present in the DER encoding. + + + + + + + +Farrell & Housley Standards Track [Page 10] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Note: This version (v2) is not backwards compatible with the previous + attribute certificate definition (v1) from the 1997 X.509 standard + [X.509-1997], but is compatible with the v2 definition from X.509 + (2000) [X.509-2000]. + +4.2.2 Holder + + The Holder field is a SEQUENCE allowing three different (optional) + syntaxes: baseCertificateID, entityName and objectDigestInfo. Where + only one option is present, the meaning of the Holder field is clear. + However, where more than one option is used, there is a potential for + confusion as to which option is "normative", which is a "hint" etc. + Since the correct position is not clear from [X.509-2000], this + specification RECOMMENDS that only one of the options be used in any + given AC. + + For any environment where the AC is passed in an authenticated + message or session and where the authentication is based on the use + of an X.509 PKC, the holder field SHOULD use the baseCertificateID. + + With the baseCertificateID option, the holder's PKC serialNumber and + issuer MUST be identical to the AC holder field. The PKC issuer MUST + have a non-empty distinguished name which is to be present as the + single value of the holder.baseCertificateID.issuer construct in the + directoryName field. The AC holder.baseCertificateID.issuerUID field + MUST only be used if the holder's PKC contains an issuerUniqueID + field. If both the AC holder.baseCertificateID.issuerUID and the PKC + issuerUniqueID fields are present, the same value MUST be present in + both fields. Thus, the baseCertificateID is only usable with PKC + profiles (like [PKIXPROF]) which mandate that the PKC issuer field + contain a non-empty distinguished name value. + + Note: An empty distinguished name is a distinguished name where the + SEQUENCE OF relative distinguished names is of zero length. In a DER + encoding, this has the value '3000'H. + + If the holder field uses the entityName option and the underlying + authentication is based on a PKC, the entityName MUST be the same as + the PKC subject field or one of the values of the PKC subjectAltName + field extension (if present). Note that [PKIXPROF] mandates that the + subjectAltName extension be present if the PKC subject is an empty + distinguished name. See the security considerations section which + mentions some name collision problems that may arise when using the + entityName option. + + In any other case where the holder field uses the entityName option, + only one name SHOULD be present. + + + + +Farrell & Housley Standards Track [Page 11] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Implementations conforming to this profile are not required to + support the use of the objectDigest field. However, section 7.3 + specifies how this optional feature MAY be used. + + Any protocol conforming to this profile SHOULD specify which AC + holder option is to be used and how this fits with the supported + authentication schemes defined in that protocol. + +4.2.3 Issuer + + ACs conforming to this profile MUST use the v2Form choice, which MUST + contain one and only one GeneralName in the issuerName, which MUST + contain a non-empty distinguished name in the directoryName field. + This means that all AC issuers MUST have non-empty distinguished + names. ACs conforming to this profile MUST omit the + baseCertificateID and objectDigestInfo fields. + + Part of the reason for the use of the v2Form containing only an + issuerName is that it means that the AC issuer does not have to know + which PKC the AC verifier will use for it (the AC issuer). Using the + baseCertificateID field to reference the AC issuer would mean that + the AC verifier would have to trust the PKC that the AC issuer chose + (for itself) at AC creation time. + +4.2.4 Signature + + Contains the algorithm identifier used to validate the AC signature. + + This MUST be one of the signing algorithms defined in [PKIXALGS]. + Conforming implementations MUST honor all MUST/SHOULD/MAY signing + algorithm statements specified in [PKIXALGS]. + +4.2.5 Serial Number + + For any conforming AC, the issuer/serialNumber pair MUST form a + unique combination, even if ACs are very short-lived. + + AC issuers MUST force the serialNumber to be a positive integer, that + is, the sign bit in the DER encoding of the INTEGER value MUST be + zero - this can be done by adding a leading (leftmost) '00'H octet if + necessary. This removes a potential ambiguity in mapping between a + string of octets and an integer value. + + Given the uniqueness and timing requirements above, serial numbers + can be expected to contain long integers. AC users MUST be able to + handle serialNumber values longer than 4 octets. Conformant ACs MUST + NOT contain serialNumber values longer than 20 octets. + + + + +Farrell & Housley Standards Track [Page 12] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + There is no requirement that the serial numbers used by any AC issuer + follow any particular ordering. In particular, they need not be + monotonically increasing with time. Each AC issuer MUST ensure that + each AC that it issues contains a unique serial number. + +4.2.6 Validity Period + + The attrCertValidityPeriod (a.k.a. validity) field specifies the + period for which the AC issuer certifies that the binding between the + holder and the attributes fields will be valid. + + The generalized time type, GeneralizedTime, is a standard ASN.1 type + for variable precision representation of time. The GeneralizedTime + field can optionally include a representation of the time + differential between the local time zone and Greenwich Mean Time. + + For the purposes of this profile, GeneralizedTime values MUST be + expressed in Coordinated universal time (UTC) (also known as + Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times + are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. + GeneralizedTime values MUST NOT include fractional seconds. + + (Note: this is the same as specified in [PKIXPROF], section + 4.1.2.5.2.) + + AC users MUST be able to handle an AC which, at the time of + processing, has parts of its validity period or all its validity + period in the past or in the future (a post-dated AC). This is valid + for some applications, such as backup. + +4.2.7 Attributes + + The attributes field gives information about the AC holder. When the + AC is used for authorization, this will often contain a set of + privileges. + + The attributes field contains a SEQUENCE OF Attribute. Each + Attribute MAY contain a SET OF values. For a given AC, each + AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That + is, only one instance of each attribute can occur in a single AC, but + each instance can be multi-valued. + + AC users MUST be able to handle multiple values for all attribute + types. + + An AC MUST contain at least one attribute. That is, the SEQUENCE OF + Attributes MUST NOT be of zero length. + + + + +Farrell & Housley Standards Track [Page 13] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Some standard attribute types are defined in section 4.4. + +4.2.8 Issuer Unique Identifier + + This field MUST NOT be used unless it is also used in the AC issuer's + PKC, in which case it MUST be used. Note that [PKIXPROF] states that + this field SHOULD NOT be used by conforming CAs, but that + applications SHOULD be able to parse PKCs containing the field. + +4.2.9 Extensions + + The extensions field generally gives information about the AC as + opposed to information about the AC holder. + + An AC that has no extensions conforms to the profile; however, + section 4.3 defines the extensions that MAY be used with this + profile, and whether or not they may be marked critical. If any + other critical extension is used, the AC does not conform to this + profile. However, if any other non-critical extension is used, the + AC does conform to this profile. + + The extensions defined for ACs provide methods for associating + additional attributes with holders. This profile also allows + communities to define private extensions to carry information unique + to those communities. Each extension in an AC may be designated as + critical or non-critical. An AC using system MUST reject an AC if it + encounters a critical extension it does not recognize; however, a + non-critical extension may be ignored if it is not recognized. + Section 4.3 presents recommended extensions used within Internet ACs + and standard locations for information. Communities may elect to use + additional extensions; however, caution should be exercised in + adopting any critical extensions in ACs which might prevent use in a + general context. + +4.3 Extensions + +4.3.1 Audit Identity + + In some circumstances, it is required (e.g. by data protection/data + privacy legislation) that audit trails not contain records which + directly identify individuals. This circumstance may make the use of + the AC holder field unsuitable for use in audit trails. + + To allow for such cases, an AC MAY contain an audit identity + extension. Ideally it SHOULD be infeasible to derive the AC holder's + identity from the audit identity value without the cooperation of the + AC issuer. + + + + +Farrell & Housley Standards Track [Page 14] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + The value of the audit identity, along with the AC issuer/serial, + SHOULD then be used for audit/logging purposes. If the value of the + audit identity is suitably chosen, a server/service administrator can + use audit trails to track the behavior of an AC holder without being + able to identify the AC holder. + + The server/service administrator in combination with the AC issuer + MUST be able to identify the AC holder in cases where misbehavior is + detected. This means that the AC issuer MUST be able to determine + the actual identity of the AC holder from the audit identity. + + Of course, auditing could be based on the AC issuer/serial pair; + however, this method does not allow tracking of the same AC holder + with multiple ACs. Thus, an audit identity is only useful if it + lasts for longer than the typical AC lifetime. Auditing could also + be based on the AC holder's PKC issuer/serial; however, this will + often allow the server/service administrator to identify the AC + holder. + + As the AC verifier might otherwise use the AC holder or some other + identifying value for audit purposes, this extension MUST be critical + when used. + + Protocols that use ACs will often expose the identity of the AC + holder in the bits on-the-wire. In such cases, an opaque audit + identity does not make use of the AC anonymous; it simply ensures + that the ensuing audit trails do not contain identifying information. + + The value of an audit identity MUST be longer than zero octets. The + value of an audit identity MUST NOT be longer than 20 octets. + + name id-pe-ac-auditIdentity + OID { id-pe 4 } + syntax OCTET STRING + criticality MUST be TRUE + +4.3.2 AC Targeting + + To target an AC, the target information extension, imported from + [X.509-2000], MAY be used to specify a number of servers/services. + The intent is that the AC SHOULD only be usable at the specified + servers/services. An (honest) AC verifier who is not amongst the + named servers/services MUST reject the AC. + + If this extension is not present, the AC is not targeted and may be + accepted by any server. + + + + + +Farrell & Housley Standards Track [Page 15] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + In this profile, the targeting information simply consists of a list + of named targets or groups. + + The following syntax is used to represent the targeting information: + + Targets ::= SEQUENCE OF Target + + Target ::= CHOICE { + targetName [0] GeneralName, + targetGroup [1] GeneralName, + targetCert [2] TargetCert + } + + TargetCert ::= SEQUENCE { + targetCertificate IssuerSerial, + targetName GeneralName OPTIONAL, + certDigestInfo ObjectDigestInfo OPTIONAL + } + + The targetCert CHOICE within the Target structure is only present to + allow future compatibility with [X.509-2000] and MUST NOT be used. + + The targets check passes if the current server (recipient) is one of + the targetName fields in the Targets SEQUENCE, or if the current + server is a member of one of the targetGroup fields in the Targets + SEQUENCE. In this case, the current server is said to "match" the + targeting extension. + + How the membership of a target within a targetGroup is determined is + not defined here. It is assumed that any given target "knows" the + names of the targetGroups to which it belongs or can otherwise + determine its membership. For example, the targetGroup specifies a + DNS domain, and the AC verifier knows the DNS domain to which it + belongs. For another example, the targetGroup specifies "PRINTERS," + and the AC verifier knows whether or not it is a printer or print + server. + + Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF + Targets". Conforming AC issuer implementations MUST only produce one + "Targets" element. Confirming AC users MUST be able to accept a + "SEQUENCE OF Targets". If more than one Targets element is found in + an AC, the extension MUST be treated as if all Target elements had + been found within one Targets element. + + name id-ce-targetInformation + OID { id-ce 55 } + syntax SEQUENCE OF Targets + criticality MUST be TRUE + + + +Farrell & Housley Standards Track [Page 16] + +RFC 3281 An Internet Attribute Certificate April 2002 + + +4.3.3 Authority Key Identifier + + The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY + be used to assist the AC verifier in checking the signature of the + AC. The [PKIXPROF] description should be read as if "CA" meant "AC + issuer." As with PKCs, this extension SHOULD be included in ACs. + + Note: An AC, where the issuer field used the baseCertificateID + CHOICE, would not need an authorityKeyIdentifier extension, as it is + explicitly linked to the key in the referred certificate. However, + as this profile states (in section 4.2.3), ACs MUST use the v2Form + with issuerName CHOICE, this duplication does not arise. + + name id-ce-authorityKeyIdentifier + OID { id-ce 35 } + syntax AuthorityKeyIdentifier + criticality MUST be FALSE + +4.3.4 Authority Information Access + + The authorityInformationAccess extension, as defined in [PKIXPROF], + MAY be used to assist the AC verifier in checking the revocation + status of the AC. Support for the id-ad-caIssuers accessMethod is + NOT REQUIRED by this profile since AC chains are not expected. + + The following accessMethod is used to indicate that revocation status + checking is provided for this AC, using the OCSP protocol defined in + [OCSP]: + + id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } + + The accessLocation MUST contain a URI, and the URI MUST contain an + HTTP URL [URL] that specifies the location of an OCSP responder. The + AC issuer MUST, of course, maintain an OCSP responder at this + location. + + name id-ce-authorityInfoAccess + OID { id-pe 1 } + syntax AuthorityInfoAccessSyntax + criticality MUST be FALSE + +4.3.5 CRL Distribution Points + + The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY + be used to assist the AC verifier in checking the revocation status + of the AC. See section 6 for details on revocation. + + + + + +Farrell & Housley Standards Track [Page 17] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + If the crlDistributionPoints extension is present, then exactly one + distribution point MUST be present. The crlDistributionPoints + extension MUST use the DistributionPointName option, which MUST + contain a fullName, which MUST contain a single name form. That name + MUST contain either a distinguished name or a URI. The URI MUST be + either an HTTP URL or an LDAP URL [URL]. + + name id-ce-cRLDistributionPoints + OID { id-ce 31 } + syntax CRLDistPointsSyntax + criticality MUST be FALSE + +4.3.6 No Revocation Available + + The noRevAvail extension, defined in [X.509-2000], allows an AC + issuer to indicate that no revocation information will be made + available for this AC. + + This extension MUST be non-critical. An AC verifier that does not + understand this extension might be able to find a revocation list + from the AC issuer, but the revocation list will never include an + entry for the AC. + + name id-ce-noRevAvail + OID { id-ce 56 } + syntax NULL (i.e. '0500'H is the DER encoding) + criticality MUST be FALSE + +4.4 Attribute Types + + Some of the attribute types defined below make use of the + IetfAttrSyntax type, also defined below. The reasons for using this + type are: + + 1. It allows a separation between the AC issuer and the attribute + policy authority. This is useful for situations where a single + policy authority (e.g. an organization) allocates attribute + values, but where multiple AC issuers are deployed for performance + or other reasons. + + 2. The syntaxes allowed for values are restricted to OCTET STRING, + OBJECT IDENTIFIER, and UTF8String, which significantly reduces the + complexity associated with matching more general syntaxes. All + multi-valued attributes using this syntax are restricted so that + each value MUST use the same choice of value syntax. For example, + AC issuers must not use one value with an oid and a second value + with a string. + + + + +Farrell & Housley Standards Track [Page 18] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + IetfAttrSyntax ::= SEQUENCE { + policyAuthority [0] GeneralNames OPTIONAL, + values SEQUENCE OF CHOICE { + octets OCTET STRING, + oid OBJECT IDENTIFIER, + string UTF8String + } + } + + In the descriptions below, each attribute type is either tagged + "Multiple Allowed" or "One Attribute value only; multiple values + within the IetfAttrSyntax". This refers to the SET OF + AttributeValues; the AttributeType still only occurs once, as + specified in section 4.2.7. + +4.4.1 Service Authentication Information + + The SvceAuthInfo attribute identifies the AC holder to the + server/service by a name, and the attribute MAY include optional + service specific authentication information. Typically this will + contain a username/password pair for a "legacy" application. + + This attribute provides information that can be presented by the AC + verifier to be interpreted and authenticated by a separate + application within the target system. Note that this is a different + use to that intended for the accessIdentity attribute in 4.4.2 below. + + This attribute type will typically be encrypted when the authInfo + field contains sensitive information, such as a password. + + name id-aca-authenticationInfo + OID { id-aca 1 } + Syntax SvceAuthInfo + values: Multiple allowed + + SvceAuthInfo ::= SEQUENCE { + service GeneralName, + ident GeneralName, + authInfo OCTET STRING OPTIONAL + } + +4.4.2 Access Identity + + The accessIdentity attribute identifies the AC holder to the + server/service. For this attribute the authInfo field MUST NOT be + present. + + + + + +Farrell & Housley Standards Track [Page 19] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + This attribute is intended to be used to provide information about + the AC holder, that can be used by the AC verifier (or a larger + system of which the AC verifier is a component) to authorize the + actions of the AC holder within the AC verifier's system. Note that + this is a different use to that intended for the svceAuthInfo + attribute described in 4.4.1 above. + + name id-aca-accessIdentity + OID { id-aca 2 } + syntax SvceAuthInfo + values: Multiple allowed + +4.4.3 Charging Identity + + The chargingIdentity attribute identifies the AC holder for charging + purposes. In general, the charging identity will be different from + other identities of the holder. For example, the holder's company + may be charged for service. + + name id-aca-chargingIdentity + OID { id-aca 3 } + syntax IetfAttrSyntax + values: One Attribute value only; multiple values within the + IetfAttrSyntax + +4.4.4 Group + + The group attribute carries information about group memberships of + the AC holder. + + name id-aca-group + OID { id-aca 4 } + syntax IetfAttrSyntax + values: One Attribute value only; multiple values within the + IetfAttrSyntax + +4.4.5 Role + + The role attribute, specified in [X.509-2000], carries information + about role allocations of the AC holder. + + The syntax used for this attribute is: + + RoleSyntax ::= SEQUENCE { + roleAuthority [0] GeneralNames OPTIONAL, + roleName [1] GeneralName + } + + + + +Farrell & Housley Standards Track [Page 20] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + The roleAuthority field MAY be used to specify the issuing authority + for the role specification certificate. There is no requirement that + a role specification certificate necessarily exists for the + roleAuthority. This differs from [X.500-2000], where the + roleAuthority field is assumed to name the issuer of a role + specification certificate. For example, to distinguish the + administrator role as defined by "Baltimore" from that defined by + "SPYRUS", one could put the value "urn:administrator" in the roleName + field and the value "Baltimore" or "SPYRUS" in the roleAuthority + field. + + The roleName field MUST be present, and roleName MUST use the + uniformResourceIdentifier CHOICE of the GeneralName. + + name id-at-role + OID { id-at 72 } + syntax RoleSyntax + values: Multiple allowed + +4.4.6 Clearance + + The clearance attribute, specified in [X.501-1993], carries clearance + (associated with security labeling) information about the AC holder. + + The policyId field is used to identify the security policy to which + the clearance relates. The policyId indicates the semantics of the + classList and securityCategories fields. + + This specification includes the classList field exactly as it is + specified in [X.501-1993]. Additional security classification + values, and their position in the classification hierarchy, may be + defined by a security policy as a local matter or by bilateral + agreement. The basic security classification hierarchy is, in + ascending order: unmarked, unclassified, restricted, confidential, + secret, and top-secret. + + An organization can develop its own security policy that defines + security classification values and their meanings. However, the BIT + STRING positions 0 through 5 are reserved for the basic security + classification hierarchy. + + If present, the SecurityCategory field provides further authorization + information. The security policy identified by the policyId field + indicates the syntaxes that are allowed to be present in the + securityCategories SET. An OBJECT IDENTIFIER identifies each of the + allowed syntaxes. When one of these syntaxes is present in the + securityCategories SET, the OBJECT IDENTIFIER associated with that + syntax is carried in the SecurityCategory.type field. + + + +Farrell & Housley Standards Track [Page 21] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Clearance ::= SEQUENCE { + policyId [0] OBJECT IDENTIFIER, + classList [1] ClassList DEFAULT {unclassified}, + securityCategories + [2] SET OF SecurityCategory OPTIONAL + } + + ClassList ::= BIT STRING { + unmarked (0), + unclassified (1), + restricted (2) + confidential (3), + secret (4), + topSecret (5) + } + + SecurityCategory ::= SEQUENCE { + type [0] IMPLICIT OBJECT IDENTIFIER, + value [1] ANY DEFINED BY type + } + + -- This is the same as the original syntax which was defined + -- using the MACRO construct, as follows: + -- SecurityCategory ::= SEQUENCE { + -- type [0] IMPLICIT SECURITY-CATEGORY, + -- value [1] ANY DEFINED BY type + -- } + -- + -- SECURITY-CATEGORY MACRO ::= + -- BEGIN + -- TYPE NOTATION ::= type | empty + -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) + -- END + + + + name { id-at-clearance } + OID { joint-iso-ccitt(2) ds(5) module(1) + selected-attribute-types(5) clearance (55) } + syntax Clearance - imported from [X.501-1993] + values Multiple allowed + +4.5 Profile of AC issuer's PKC + + The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage + extension in the PKC MUST NOT explicitly indicate that the AC + issuer's public key cannot be used to validate a digital signature. + In order to avoid confusion regarding serial numbers and revocations, + + + +Farrell & Housley Standards Track [Page 22] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer + cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a + basicConstraints extension with the cA BOOLEAN set to TRUE. + +5. Attribute Certificate Validation + + This section describes a basic set of rules that all valid ACs MUST + satisfy. Some additional checks are also described which AC + verifiers MAY choose to implement. + + To be valid an AC MUST satisfy all of the following: + + 1. Where the holder uses a PKC to authenticate to the AC verifier, + the AC holder's PKC MUST be found, and the entire certification + path of that PKC MUST be verified in accordance with [PKIXPROF]. + As noted in the security considerations section, if some other + authentication scheme is used, AC verifiers need to be very + careful mapping the identities (authenticated identity, holder + field) involved. + + 2. The AC signature must be cryptographically correct, and the AC + issuer's entire PKC certification path MUST be verified in + accordance with [PKIXPROF]. + + 3. The AC issuer's PKC MUST also conform to the profile specified in + section 4.5 above. + + 4. The AC issuer MUST be directly trusted as an AC issuer (by + configuration or otherwise). + + 5. The time for which the AC is being evaluated MUST be within the AC + validity. If the evaluation time is equal to either notBeforeTime + or notAfterTime, then the AC is timely and this check succeeds. + Note that in some applications, the evaluation time MAY not be the + same as the current time. + + 6. The AC targeting check MUST pass as specified in section 4.3.2. + + 7. If the AC contains an unsupported critical extension, the AC MUST + be rejected. + + Support for an extension in this context means: + + 1. The AC verifier MUST be able to parse the extension value. + + 2. Where the extension value SHOULD cause the AC to be rejected, the + AC verifier MUST reject the AC. + + + + +Farrell & Housley Standards Track [Page 23] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Additional Checks: + + 1. The AC MAY be rejected on the basis of further AC verifier + configuration. For example, an AC verifier may be configured to + reject ACs which contain or lack certain attributes. + + 2. If the AC verifier provides an interface that allows applications + to query the contents of the AC, then the AC verifier MAY filter + the attributes from the AC on the basis of configured information. + For example, an AC verifier might be configured not to return + certain attributes to certain servers. + +6. Revocation + + In many environments, the validity period of an AC is less than the + time required to issue and distribute revocation information. + Therefore, short-lived ACs typically do not require revocation + support. However, long-lived ACs and environments where ACs enable + high value transactions MAY require revocation support. + + Two revocation schemes are defined, and the AC issuer should elect + the one that is best suited to the environment in which the AC will + be employed. + + "Never revoke" scheme: + + ACs may be marked so that the relying party understands that no + revocation status information will be made available. The + noRevAvail extension is defined in section 4.3.6, and the + noRevAvail extension MUST be present in the AC to indicate use of + this scheme. + + Where no noRevAvail is present, the AC issuer is implicitly + stating that revocation status checks are supported, and some + revocation method MUST be provided to allow AC verifiers to + establish the revocation status of the AC. + + "Pointer in AC" scheme: + + ACs may "point" to sources of revocation status information, using + either an authorityInfoAccess extension or a crlDistributionPoints + extension within the AC. + + For AC users, the "never revoke" scheme MUST be supported, and the + "pointer in AC" scheme SHOULD be supported. If only the "never + revoke" scheme is supported, then all ACs that do not contain a + noRevAvail extension, MUST be rejected. + + + + +Farrell & Housley Standards Track [Page 24] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + For AC issuers, the "never revoke" scheme MUST be supported. If all + ACs that will ever be issued by that AC issuer, contains a noRevAvail + extension, the "pointer in AC" scheme need not be supported. If any + AC can be issued that does not contain the noRevAvail extension, the + "pointer in AC" scheme MUST be supported. + + An AC MUST NOT contain both a noRevAvail and a "pointer in AC". + + An AC verifier MAY use any source for AC revocation status + information. + +7. Optional Features + + This section specifies features that MAY be implemented. Conformance + to this profile does NOT require support for these features; however, + if these features are offered, they MUST be offered as described + below. + +7.1 Attribute Encryption + + Where an AC will be carried in clear within an application protocol + or where an AC contains some sensitive information like a legacy + application username/password, then encryption of AC attributes MAY + be needed. + + When a set of attributes are to be encrypted within an AC, the + Cryptographic Message Syntax, EnvelopedData structure [CMS] is used + to carry the ciphertext and associated per-recipient keying + information. + + This type of attribute encryption is targeted. Before the AC is + signed, the attributes are encrypted for a set of predetermined + recipients. + + The AC then contains the ciphertext inside its signed data. The + EnvelopedData (id-envelopedData) ContentType is used, and the content + field will contain the EnvelopedData type. + + The ciphertext is included in the AC as the value of an encAttrs + attribute. Only one encAttrs attribute can be present in an AC; + however, the encAttrs attribute MAY be multi-valued, and each of its + values will contain an independent EnvelopedData. + + Each value can contain a set of attributes (each possibly a multi- + valued attribute) encrypted for a set of predetermined recipients. + + + + + + +Farrell & Housley Standards Track [Page 25] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + The cleartext that is encrypted has the type: + + ACClearAttrs ::= SEQUENCE { + acIssuer GeneralName, + acSerial INTEGER, + attrs SEQUENCE OF Attribute + } + + The DER encoding of the ACClearAttrs structure is used as the + encryptedContent field of the EnvelopedData. The DER encoding MUST + be embedded in an OCTET STRING. + + The acIssuer and acSerial fields are present to prevent ciphertext + stealing. When an AC verifier has successfully decrypted an + encrypted attribute, it MUST then check that the AC issuer and + serialNumber fields contain the same values. This prevents a + malicious AC issuer from copying ciphertext from another AC (without + knowing its corresponding plaintext). + + The procedure for an AC issuer when encrypting attributes is + illustrated by the following (any other procedure that gives the same + result MAY be used): + + 1. Identify the sets of attributes that are to be encrypted for + each set of recipients. + 2. For each attribute set which is to be encrypted: + 2.1. Create an EnvelopedData structure for the data for this + set of recipients. + 2.2. Encode the ContentInfo containing the EnvelopedData as a + value of the encAttrs attribute. + 2.3. Ensure the cleartext attributes are not present in the + to-be-signed AC. + 3. Add the encAttrs (with its multiple values) to the AC. + + Note that there may be more than one attribute of the same type (the + same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain + the same attribute type both in clear and in encrypted form (and + indeed several times if the same recipient is associated with more + than one EnvelopedData). One approach implementers may choose, would + be to merge attribute values following decryption in order to re- + establish the "once only" constraint. + + name id-aca-encAttrs + OID { id-aca 6} + Syntax ContentInfo + values Multiple Allowed + + + + + +Farrell & Housley Standards Track [Page 26] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + If an AC contains attributes, apparently encrypted for the AC + verifier, the decryption process MUST not fail. If decryption does + fail, the AC MUST be rejected. + +7.2 Proxying + + When a server acts as a client for another server on behalf of the AC + holder, the server MAY need to proxy an AC. Such proxying MAY have + to be done under the AC issuer's control, so that not every AC is + proxiable and so that a given proxiable AC can be proxied in a + targeted fashion. Support for chains of proxies (with more than one + intermediate server) MAY also be required. Note that this does not + involve a chain of ACs. + + In order to meet this requirement we define another extension, + ProxyInfo, similar to the targeting extension. + + When this extension is present, the AC verifier must check that the + entity from which the AC was received was allowed to send it and that + the AC is allowed to be used by this verifier. + + The proxying information consists of a set of proxy information, each + of which is a set of targeting information. If the verifier and the + sender of the AC are both named in the same proxy set, the AC can + then be accepted (the exact rule is given below). + + The effect is that the AC holder can send the AC to any valid target + which can then only proxy to targets which are in one of the same + proxy sets as itself. + + The following data structure is used to represent the + targeting/proxying information. + + ProxyInfo ::= SEQUENCE OF Targets + + As in the case of targeting, the targetCert CHOICE MUST NOT be used. + + A proxy check succeeds if either one of the conditions below is met: + + 1. The identity of the sender, as established by the underlying + authentication service, matches the holder field of the AC, and + the current server "matches" any one of the proxy sets. Recall + that "matches" is as defined section 4.3.2. + + + + + + + + +Farrell & Housley Standards Track [Page 27] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + 2. The identity of the sender, as established by the underlying + authentication service, "matches" one of the proxy sets (call it + set "A"), and the current server is one of the targetName fields + in the set "A", or the current server is a member of one of the + targetGroup fields in set "A". + + When an AC is proxied more than once, a number of targets will be on + the path from the original client, which is normally, but not always, + the AC holder. In such cases, prevention of AC "stealing" requires + that the AC verifier MUST check that all targets on the path are + members of the same proxy set. It is the responsibility of the AC- + using protocol to ensure that a trustworthy list of targets on the + path is available to the AC verifier. + + name id-pe-ac-proxying + OID { id-pe 10 } + syntax ProxyInfo + criticality MUST be TRUE + +7.3 Use of ObjectDigestInfo + + In some environments, it may be required that the AC is not linked + either to an identity (via entityName) or to a PKC (via + baseCertificateID). The objectDigestInfo CHOICE in the holder field + allows support for this requirement. + + If the holder is identified with the objectDigestInfo field, then the + AC version field MUST contain v2 (the integer 1). + + The idea is to link the AC to an object by placing a hash of that + object into the holder field of the AC. For example, this allows + production of ACs that are linked to public keys rather than names. + It also allows production of ACs which contain privileges associated + with an executable object such as a Java class. However, this + profile only specifies how to use a hash over a public key or PKC. + That is, conformant ACs MUST NOT use the otherObjectTypes value for + the digestedObjectType. + + To link an AC to a public key, the hash must be calculated over the + representation of that public key which would be present in a PKC, + specifically, the input for the hash algorithm MUST be the DER + encoding of a SubjectPublicKeyInfo representation of the key. Note: + This includes the AlgorithmIdentifier as well as the BIT STRING. The + rules given in [PKIXPROF] for encoding keys MUST be followed. In + this case, the digestedObjectType MUST be publicKey and the + otherObjectTypeID field MUST NOT be present. + + + + + +Farrell & Housley Standards Track [Page 28] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Note that if the public key value used as input to the hash function + has been extracted from a PKC, it is possible that the + SubjectPublicKeyInfo from that PKC is NOT the value which should be + hashed. This can occur if DSA Dss-parms are inherited as described + in section 7.3.3 of [PKIXPROF]. The correct input for hashing in + this context will include the value of the parameters inherited from + the CA's PKC, and thus may differ from the SubjectPublicKeyInfo + present in the PKC. + + Implementations which support this feature MUST be able to handle the + representations of public keys for the algorithms specified in + section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST + be publicKey and the otherObjectTypeID field MUST NOT be present. + + In order to link an AC to a PKC via a digest, the digest MUST be + calculated over the DER encoding of the entire PKC, including the + signature value. In this case the digestedObjectType MUST be + publicKeyCert and the otherObjectTypeID field MUST NOT be present. + +7.4 AA Controls + + During AC validation a relying party has to answer the question: is + this AC issuer trusted to issue ACs containing this attribute? The + AAControls PKC extension MAY be used to help answer the question. + The AAControls extension is intended to be used in CA and AC issuer + PKCs. + + id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } + + AAControls ::= SEQUENCE { + pathLenConstraint INTEGER (0..MAX) OPTIONAL, + permittedAttrs [0] AttrSpec OPTIONAL, + excludedAttrs [1] AttrSpec OPTIONAL, + permitUnSpecified BOOLEAN DEFAULT TRUE + } + + AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER + + The AAControls extension is used as follows: + + The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. + It restricts the allowed distance between the AA CA (a CA directly + trusted to include AAControls in its PKCs), and the AC issuer. + + The permittedAttrs field specifies a set of attribute types that any + AC issuer below this AA CA is allowed to include in ACs. If this + field is not present, it means that no attribute types are explicitly + allowed. + + + +Farrell & Housley Standards Track [Page 29] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + The excludedAttrs field specifies a set of attribute types that no AC + issuer is allowed to include in ACs. If this field is not present, + it means that no attribute types are explicitly disallowed. + + The permitUnSpecified field specifies how to handle attribute types + which are not present in either the permittedAttrs or excludedAttrs + fields. TRUE (the default) means that any unspecified attribute type + is allowed in ACs; FALSE means that no unspecified attribute type is + allowed. + + When AAControls are used, the following additional checks on an AA's + PKC chain MUST all succeed for the AC to be valid: + + 1. Some CA on the ACs certificate path MUST be directly trusted to + issue PKCs which precede the AC issuer in the certification path; + call this CA the "AA CA". + + 2. All PKCs on the path from the AA CA, down to and including the AC + issuer's PKC, MUST contain an AAControls extension; however, the + AA CA's PKC need not contain this extension. + + 3. Only those attributes in the AC which are allowed, according to + all of the AAControls extension values in all of the PKCs from the + AA CA to the AC issuer, may be used for authorization decisions; + all other attributes MUST be ignored. This check MUST be applied + to the set of attributes following attribute decryption, and the + id-aca-encAttrs type MUST also be checked. + + name id-pe-aaControls + OID { id-pe 6 } + syntax AAControls + criticality MAY be TRUE + +8. Security Considerations + + The protection afforded for private keys is a critical factor in + maintaining security. Failure of AC issuers to protect their private + keys will permit an attacker to masquerade as them, potentially + generating false ACs or revocation status. Existence of bogus ACs + and revocation status will undermine confidence in the system. If + the compromise is detected, all ACs issued by the AC issuer MUST be + revoked. Rebuilding after such a compromise will be problematic, so + AC issuers are advised to implement a combination of strong technical + measures (e.g., tamper-resistant cryptographic modules) and + appropriate management procedures (e.g., separation of duties) to + avoid such an incident. + + + + + +Farrell & Housley Standards Track [Page 30] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Loss of an AC issuer's private signing key may also be problematic. + The AC issuer would not be able to produce revocation status or + perform AC renewal. AC issuers are advised to maintain secure backup + for signing keys. The security of the key backup procedures is a + critical factor in avoiding key compromise. + + The availability and freshness of revocation status will affect the + degree of assurance that should be placed in a long-lived AC. While + long-lived ACs expire naturally, events may occur during its natural + lifetime which negate the binding between the AC holder and the + attributes. If revocation status is untimely or unavailable, the + assurance associated with the binding is clearly reduced. + + The binding between an AC holder and attributes cannot be stronger + than the cryptographic module implementation and algorithms used to + generate the signature. Short key lengths or weak hash algorithms + will limit the utility of an AC. AC issuers are encouraged to note + advances in cryptology so they can employ strong cryptographic + techniques. + + Inconsistent application of name comparison rules may result in + acceptance of invalid targeted or proxied ACs, or rejection of valid + ones. The X.500 series of specifications defines rules for comparing + distinguished names. These rules require comparison of strings + without regard to case, character set, multi-character white space + substrings, or leading and trailing white space. This specification + and [PKIXPROF] relaxes these requirements, requiring support for + binary comparison at a minimum. + + AC issuers MUST encode the distinguished name in the AC + holder.entityName field identically to the distinguished name in the + holder's PKC. If different encodings are used, implementations of + this specification may fail to recognize that the AC and PKC belong + to the same entity. + + If an attribute certificate is tied to the holder's PKC using the + baseCertificateID component of the Holder field and the PKI in use + includes a rogue CA with the same issuer name specified in the + baseCertificateID component, this rogue CA could issue a PKC to a + malicious party, using the same issuer name and serial number as the + proper holder's PKC. Then the malicious party could use this PKC in + conjunction with the AC. This scenario SHOULD be avoided by properly + managing and configuring the PKI so that there cannot be two CAs with + the same name. Another alternative is to tie ACs to PKCs using the + publicKeyCert type in the ObjectDigestInfo field. Failing this, AC + verifiers have to establish (using other means) that the potential + collisions cannot actually occur, for example, the CPSs of the CAs + involved may make it clear that no such name collisions can occur. + + + +Farrell & Housley Standards Track [Page 31] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + Implementers MUST ensure that following validation of an AC, only + attributes that the issuer is trusted to issue are used in + authorization decisions. Other attributes, which MAY be present MUST + be ignored. Given that the AA controls PKC extension is optional to + implement, AC verifiers MUST be provided with this information by + other means. Configuration information is a likely alternative + means. This becomes very important if an AC verifier trusts more + than one AC issuer. + + There is often a requirement to map between the authentication + supplied by a particular security protocol (e.g. TLS, S/MIME) and the + AC holder's identity. If the authentication uses PKCs, then this + mapping is straightforward. However, it is envisaged that ACs will + also be used in environments where the holder may be authenticated + using other means. Implementers SHOULD be very careful in mapping + the authenticated identity to the AC holder. + +9. IANA Considerations + + Attributes and attribute certificate extensions are identified by + object identifiers (OIDs). Many of the OIDs used in this document + are copied from X.509 [X.509-2000]. Other OIDs were assigned from an + arc delegated by the IANA. No further action by the IANA is + necessary for this document or any anticipated updates. + +10. References + + [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, + "Certificate Management Messages over CMS", RFC 2797, + April 2000. + + [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key + Infrastructure - Certificate Management Protocols", RFC + 2510, March 1999. + + [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, + June 1999. + + [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", + RFC 2634, June 1999. + + [KRB] Kohl, J. and C. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September 1993. + + [LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + + + + +Farrell & Housley Standards Track [Page 32] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. + Adams, "X.509 Internet Public Key Infrastructure - + Online Certificate Status Protocol - OCSP", RFC 2560, + June 1999. + + [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + Lists CRL Profile", RFC 3279, April 2002. + + [PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [X.208-1988] CCITT Recommendation X.208: Specification of Abstract + Syntax Notation One (ASN.1). 1988. + + [X.209-88] CCITT Recommendation X.209: Specification of Basic + Encoding Rules for Abstract Syntax Notation One (ASN.1). + 1988. + + [X.501-88] CCITT Recommendation X.501: The Directory - Models. + 1988. + + [X.501-1993] ITU-T Recommendation X.501 : Information Technology - + Open Systems Interconnection - The Directory: Models, + 1993. + + [X.509-1988] CCITT Recommendation X.509: The Directory - + Authentication Framework. 1988. + + [X.509-1997] ITU-T Recommendation X.509: The Directory - + Authentication Framework. 1997. + + [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key + and Attribute Certificate Frameworks. 2000 + + + + + +Farrell & Housley Standards Track [Page 33] + +RFC 3281 An Internet Attribute Certificate April 2002 + + +Appendix A: Object Identifiers + + This (normative) appendix lists the new object identifiers which are + defined in this specification. Some of these are required only for + support of optional features and are not required for conformance to + this profile. This specification mandates support for OIDs which + have arc elements with values that are less than 2^32, (i.e. they + MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less + than 2^31 (i.e. less than or equal to 2,147,483,647). This allows + each arc element to be represented within a single 32 bit word. + Implementations MUST also support OIDs where the length of the dotted + decimal (see [LDAP], section 4.1.2) string representation can be up + to 100 bytes (inclusive). Implementations MUST be able to handle + OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs + which contain OIDs that breach these requirements. + + The following OIDs are imported from [PKIXPROF]: + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } + id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } + id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } + id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } + id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } + + The following new ASN.1 module OID is defined: + + id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } + + The following AC extension OIDs are defined: + + id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } + id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } + id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } + + The following PKC extension OIDs are defined: + + id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } + + + + + + + + + + + + +Farrell & Housley Standards Track [Page 34] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + The following attribute OIDs are defined: + + id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } + id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } + id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } + id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } + id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } + id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } + id-at-role OBJECT IDENTIFIER ::= { id-at 72 } + id-at-clearance OBJECT IDENTIFIER ::= + { joint-iso-ccitt(2) ds(5) module(1) + selected-attribute-types(5) clearance (55) } + +Appendix B: ASN.1 Module + + PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-attribute-cert(12)} + + DEFINITIONS IMPLICIT TAGS ::= + + BEGIN + + -- EXPORTS ALL -- + + IMPORTS + + -- IMPORTed module OIDs MAY change if [PKIXPROF] changes + -- PKIX Certificate Extensions + Attribute, AlgorithmIdentifier, CertificateSerialNumber, + Extensions, UniqueIdentifier, + id-pkix, id-pe, id-kp, id-ad, id-at + FROM PKIX1Explicit88 {iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) + pkix(7) id-mod(0) id-pkix1-explicit-88(1)} + + GeneralName, GeneralNames, id-ce + FROM PKIX1Implicit88 {iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) + pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; + + id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } + id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } + id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } + id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } + + id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } + + + + +Farrell & Housley Standards Track [Page 35] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } + id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } + id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } + id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } + -- { id-aca 5 } is reserved + id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } + + id-at-role OBJECT IDENTIFIER ::= { id-at 72} + id-at-clearance OBJECT IDENTIFIER ::= + { joint-iso-ccitt(2) ds(5) module(1) + selected-attribute-types(5) clearance (55) } + + -- Uncomment this if using a 1988 level ASN.1 compiler + -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING + + AttributeCertificate ::= SEQUENCE { + acinfo AttributeCertificateInfo, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING + } + + AttributeCertificateInfo ::= SEQUENCE { + version AttCertVersion -- version is v2, + holder Holder, + issuer AttCertIssuer, + signature AlgorithmIdentifier, + serialNumber CertificateSerialNumber, + attrCertValidityPeriod AttCertValidityPeriod, + attributes SEQUENCE OF Attribute, + issuerUniqueID UniqueIdentifier OPTIONAL, + extensions Extensions OPTIONAL + } + + AttCertVersion ::= INTEGER { v2(1) } + + Holder ::= SEQUENCE { + baseCertificateID [0] IssuerSerial OPTIONAL, + -- the issuer and serial number of + -- the holder's Public Key Certificate + entityName [1] GeneralNames OPTIONAL, + -- the name of the claimant or role + objectDigestInfo [2] ObjectDigestInfo OPTIONAL + -- used to directly authenticate the + -- holder, for example, an executable + } + + + + + + +Farrell & Housley Standards Track [Page 36] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + ObjectDigestInfo ::= SEQUENCE { + digestedObjectType ENUMERATED { + publicKey (0), + publicKeyCert (1), + otherObjectTypes (2) }, + -- otherObjectTypes MUST NOT + -- MUST NOT be used in this profile + otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, + digestAlgorithm AlgorithmIdentifier, + objectDigest BIT STRING + } + + AttCertIssuer ::= CHOICE { + v1Form GeneralNames, -- MUST NOT be used in this + -- profile + v2Form [0] V2Form -- v2 only + } + + V2Form ::= SEQUENCE { + issuerName GeneralNames OPTIONAL, + baseCertificateID [0] IssuerSerial OPTIONAL, + objectDigestInfo [1] ObjectDigestInfo OPTIONAL + -- issuerName MUST be present in this profile + -- baseCertificateID and objectDigestInfo MUST + -- NOT be present in this profile + } + + IssuerSerial ::= SEQUENCE { + issuer GeneralNames, + serial CertificateSerialNumber, + issuerUID UniqueIdentifier OPTIONAL + } + + AttCertValidityPeriod ::= SEQUENCE { + notBeforeTime GeneralizedTime, + notAfterTime GeneralizedTime + } + + Targets ::= SEQUENCE OF Target + + Target ::= CHOICE { + targetName [0] GeneralName, + targetGroup [1] GeneralName, + targetCert [2] TargetCert + } + + + + + + +Farrell & Housley Standards Track [Page 37] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + TargetCert ::= SEQUENCE { + targetCertificate IssuerSerial, + targetName GeneralName OPTIONAL, + certDigestInfo ObjectDigestInfo OPTIONAL + } + + IetfAttrSyntax ::= SEQUENCE { + policyAuthority[0] GeneralNames OPTIONAL, + values SEQUENCE OF CHOICE { + octets OCTET STRING, + oid OBJECT IDENTIFIER, + string UTF8String + } + } + + SvceAuthInfo ::= SEQUENCE { + service GeneralName, + ident GeneralName, + authInfo OCTET STRING OPTIONAL + } + + RoleSyntax ::= SEQUENCE { + roleAuthority [0] GeneralNames OPTIONAL, + roleName [1] GeneralName + } + + Clearance ::= SEQUENCE { + policyId [0] OBJECT IDENTIFIER, + classList [1] ClassList DEFAULT {unclassified}, + securityCategories + [2] SET OF SecurityCategory OPTIONAL + } + + ClassList ::= BIT STRING { + unmarked (0), + unclassified (1), + restricted (2), + confidential (3), + secret (4), + topSecret (5) + } + + SecurityCategory ::= SEQUENCE { + type [0] IMPLICIT OBJECT IDENTIFIER, + value [1] ANY DEFINED BY type + } + + + + + +Farrell & Housley Standards Track [Page 38] + +RFC 3281 An Internet Attribute Certificate April 2002 + + + AAControls ::= SEQUENCE { + pathLenConstraint INTEGER (0..MAX) OPTIONAL, + permittedAttrs [0] AttrSpec OPTIONAL, + excludedAttrs [1] AttrSpec OPTIONAL, + permitUnSpecified BOOLEAN DEFAULT TRUE + } + + AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER + + ACClearAttrs ::= SEQUENCE { + acIssuer GeneralName, + acSerial INTEGER, + attrs SEQUENCE OF Attribute + } + + ProxyInfo ::= SEQUENCE OF Targets + + END + +Author's Addresses + + Stephen Farrell + Baltimore Technologies + 39/41 Parkgate Street + Dublin 8 + IRELAND + + EMail: stephen.farrell@baltimore.ie + + Russell Housley + RSA Laboratories + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + + EMail: rhousley@rsasecurity.com + +Acknowledgements + + Russ Housley thanks the management at SPYRUS, who supported the + development of this specification while he was employed at SPYRUS. + Russ Housley also thanks the management at RSA Laboratories, who + supported the completion of the specification after a job change. + + + + + + + + +Farrell & Housley Standards Track [Page 39] + +RFC 3281 An Internet Attribute Certificate April 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Farrell & Housley Standards Track [Page 40] + diff --git a/doc/standardisation/rfc3820.txt b/doc/standardisation/rfc3820.txt new file mode 100644 index 000000000..f4e60737f --- /dev/null +++ b/doc/standardisation/rfc3820.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group S. Tuecke +Request for Comments: 3820 ANL +Category: Standards Track V. Welch + NCSA + D. Engert + ANL + L. Pearlman + USC/ISI + M. Thompson + LBNL + June 2004 + + + Internet X.509 Public Key Infrastructure (PKI) + Proxy Certificate Profile + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document forms a certificate profile for Proxy Certificates, + based on X.509 Public Key Infrastructure (PKI) certificates as + defined in RFC 3280, for use in the Internet. The term Proxy + Certificate is used to describe a certificate that is derived from, + and signed by, a normal X.509 Public Key End Entity Certificate or by + another Proxy Certificate for the purpose of providing restricted + proxying and delegation within a PKI based authentication system. + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 1] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5 + 2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7 + 2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8 + 2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9 + 2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10 + 3. Certificate and Certificate Extensions Profile . . . . . . . . 12 + 3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12 + 3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12 + 3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13 + 3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13 + 3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14 + 3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14 + 4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17 + 4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19 + 4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23 + 5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 5.1. Relationship to Attribute Certificates . . . . . . . . . 24 + 5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28 + 5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28 + 5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30 + 6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30 + 6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31 + 6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31 + 6.4. Protecting Against Denial of Service with Key Generation 32 + 6.5. Use of Proxy Certificates in a Central Repository. . . . 32 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 8.2. Informative References . . . . . . . . . . . . . . . . . 33 + 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34 + Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 + Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37 + + + + + + + + + +Tuecke, et al. Standards Track [Page 2] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +1. Introduction + + Use of a proxy credential [i7] is a common technique used in 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 words, + entity B is acting as a proxy on behalf of entity A. This document + forms a certificate profile for Proxy Certificates, based on the RFC + 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL + Profile" [n2]. + + In addition to simple, unrestricted proxying, this profile defines: + + * A framework for carrying policies in Proxy Certificates that + allows proxying to be limited (perhaps completely disallowed) + through either restrictions or enumeration of rights. + + * Proxy Certificates with unique names, derived from the name of the + end entity certificate name. This allows the Proxy Certificates + to be used in conjunction with attribute assertion approaches such + as Attribute Certificates [i3] and have their own rights + independent of their issuer. + + Section 2 provides a non-normative overview of the approach. It + begins by defining terminology, motivating Proxy Certificates, and + giving a brief overview of the approach. It then introduces the + notion of a Proxy Issuer, as distinct from a Certificate Authority, + to describe how end entity signing of a Proxy Certificate is + different from end entity signing of another end entity certificate, + and therefore why this approach does not violate the end entity + signing restrictions contained in the X.509 keyCertSign field of the + keyUsage extension. It then continues with discussions of how + subject names are used by this proxying approach, and features of + this approach. + + Section 3 defines requirements on information content in Proxy + Certificates. This profile addresses two fields in the basic + certificate as well as five certificate extensions. The certificate + fields are the subject and issuer fields. The certificate extensions + are subject alternative name, issuer alternative name, key usage, + basic constraints, and extended key usage. A new certificate + extension, Proxy Certificate Information, is introduced. + + Section 4 defines path validation rules for Proxy Certificates. + + Section 5 provides non-normative commentary on Proxy Certificates. + + Section 6 discusses security considerations relating to Proxy + Certificates. + + + +Tuecke, et al. Standards Track [Page 3] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + References, listed in Section 8, are sorted into normative and + information references. Normative references, listed in Section 8.1, + are in the form [nXX]. Informative references, listed in Section + 8.2, are in the form [iXX]. + + Section 9 contains acknowledgements. + + Following Section 9, contains the Appendix, the contact information + for the authors, the intellectual property information, and the + copyright information for this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [n1]. + +2. Overview of Approach + + This section provides non-normative commentary on Proxy Certificates. + + The goal of this specification is to develop a X.509 Proxy + Certificate profile and to facilitate their use within Internet + applications for those communities wishing to make use of restricted + proxying and delegation within an X.509 Public Key Infrastructure + (PKI) authentication based system. + + This section provides relevant background, motivation, an overview of + the approach, and related work. + +2.1. Terminology + + This document uses the following terms: + + * CA: A "Certification Authority", as defined by X.509 [n2] + + * EEC: An "End Entity Certificate", as defined by X.509. That is, + it is an X.509 Public Key Certificate issued to an end entity, + such as a user or a service, by a CA. + + * PKC: An end entity "Public Key Certificate". This is synonymous + with an EEC. + + * PC: A "Proxy Certificate", the profile of which is defined by this + document. + + + + + + + + +Tuecke, et al. Standards Track [Page 4] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * PI: A "Proxy Issuer" is an entity with an End Entity Certificate + or Proxy Certificate that issues a Proxy Certificate. The Proxy + Certificate is signed using the private key associated with the + public key in the Proxy Issuer's certificate. + + * AC: An "Attribute Certificate", as defined by "An Internet + Attribute Certificate Profile for Authorization" [i3]. + + * AA: An "Attribute Authority", as defined in [i3]. + +2.2. Background + + Computational and Data "Grids" have emerged as a common approach to + constructing dynamic, inter-domain, distributed computing + environments. As explained in [i5], large research and development + efforts starting around 1995 have focused on the question of what + protocols, services, and APIs are required for effective, coordinated + use of resources in these Grid environments. + + In 1997, the Globus Project (www.globus.org) introduced the Grid + Security Infrastructure (GSI) [i4]. This library provides for public + key based authentication and message protection, based on standard + X.509 certificates and public key infrastructure, the SSL/TLS + protocol [i2], and delegation using proxy certificates similar to + those profiled in this document. GSI has been used, in turn, to + build numerous middleware libraries and applications, which have been + deployed in large-scale production and experimental Grids [i1]. GSI + has emerged as the dominant security solution used by Grid efforts + worldwide. + + This experience with GSI has proven the viability of restricted + proxying as a basis for authorization within Grids, and has further + proven the viability of using X.509 Proxy Certificates, as defined in + this document, as the basis for that proxying. This document is one + part of an effort to migrate this experience with GSI into standards, + and in the process clean up the approach and better reconcile it with + existing and recent standards. + +2.3. Motivation for Proxying + + A motivating example will assist in understanding the role proxying + can play in building Internet based applications. + + Steve is an engineer who wants to use a reliable file transfer + service to manage the movement of a number of large files around + between various hosts on his company's Intranet-based Grid. From his + laptop he wants to submit a number of transfer requests to the + service and have the files transferred while he is doing other + + + +Tuecke, et al. Standards Track [Page 5] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + things, including being offline. The transfer service may queue the + requests for some time (e.g., until after hours or a period of low + resource usage) before initiating the transfers. The transfer + service will then, for each file, connect to each of the source and + destination hosts, and instruct them to initiate a data connection + directly from the source to the destination in order to transfer the + file. Steve will leave an agent running on his laptop that will + periodically check on progress of the transfer by contacting the + transfer service. Of course, he wants all of this to happen securely + on his company's resources, which requires that he initiate all of + this using his PKI smartcard. + + This scenario requires authentication and delegation in a variety of + places: + + * Steve needs to be able to mutually authenticate with the reliable + file transfer service to submit the transfer request. + + * Since the storage hosts know nothing about the file transfer + service, the file transfer service needs to be delegated the + rights to mutually authenticate with the various storage hosts + involved directly in the file transfer, in order to initiate the + file transfer. + + * The source and destination hosts of a particular transfer must be + able to mutual authenticate with each other, to ensure the file is + being transferred to and from the proper parties. + + * The agent running on Steve's laptop must mutually authenticate + with the file transfer service in order to check the result of the + transfers. + + Proxying is a viable approach to solving two (related) problems in + this scenario: + + * Single sign-on: Steve wants to enter his smartcard password (or + pin) once, and then run a program that will submit all the file + transfer requests to the transfer service, and then periodically + check on the status of the transfer. This program needs to be + given the rights to be able to perform all of these operations + securely, without requiring repeated access to the smartcard or + Steve's password. + + * Delegation: Various remote processes in this scenario need to + perform secure operations on Steve's behalf, and therefore must be + delegated the necessary rights. For example, the file transfer + + + + + +Tuecke, et al. Standards Track [Page 6] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + service needs to be able to authenticate on Steve's behalf with + the source and destination hosts, and must in turn delegate rights + to those hosts so that they can authenticate with each other. + + Proxying can be used to secure all of these interactions: + + * Proxying allows for the private key stored on the smartcard to be + accessed just once, in order to create the necessary proxy + credential, which allows the client/agent program to be authorized + as Steve when submitting the requests to the transfer service. + Access to the smartcard and Steve's password is not required after + the initial creation of the proxy credential. + + * The client program on the laptop can delegate to the file transfer + service the right to act on Steve's behalf. This, in turn, allows + the service to authenticate to the storage hosts and inherit + Steve's privileges in order to start the file transfers. + + * When the transfer service authenticates to hosts to start the file + transfer, the service can delegate to the hosts the right to act + on Steve's behalf so that each pair of hosts involved in a file + transfer can mutually authenticate to ensure the file is securely + transferred. + + * When the agent on the laptop reconnects to the file transfer + service to check on the status of the transfer, it can perform + mutual authentication. The laptop may use a newly generated proxy + credential, which is just created anew using the smartcard. + + This scenario, and others similar to it, is being built today within + the Grid community. The Grid Security Infrastructure's single sign- + on and delegation capabilities, built on X.509 Proxy Certificates, + are being employed to provide authentication services to these + applications. + +2.4. Motivation for Restricted Proxies + + One concern that arises is what happens if a machine that has been + delegated the right to inherit Steve's privileges has been + compromised? For example, in the above scenario, what if the machine + running the file transfer service is compromised, such that the + attacker can gain access to the credential that Steve delegated to + that service? Can the attacker now do everything that Steve is + allowed to do? + + A solution to this problem is to allow for restrictions to be placed + on the proxy by means of policies on the proxy certificates. For + example, the machine running the reliable file transfer service in + + + +Tuecke, et al. Standards Track [Page 7] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + the above example might only be given Steve's right for the purpose + of reading the source files and writing the destination files. + Therefore, if that file transfer service is compromised, the attacker + cannot modify source files, cannot create or modify other files to + which Steve has access, cannot start jobs on behalf of Steve, etc. + All that an attacker would be able to do is read the specific files + to which the file transfer service has been delegated read access, + and write bogus files in place of those that the file transfer + service has been delegated write access. Further, by limiting the + lifetime of the credential that is delegated to the file transfer + service, the effects of a compromise can be further mitigated. + + Other potential uses for restricted proxy credentials are discussed + in [i7]. + +2.5. Motivation for Unique Proxy Name + + The dynamic creation of entities (e.g., processes and services) is an + essential part of Grid computing. These entities will require rights + in order to securely perform their function. While it is possible to + obtain rights solely through proxying as described in previous + sections, this has limitations. For example what if an entity should + have rights that are granted not just from the proxy issuer but from + a third party as well? While it is possible in this case for the + entity to obtain and hold two proxy certifications, in practice it is + simpler for subsequent credentials to take the form of attribute + certificates. + + It is also desirable for these entities to have a unique identity so + that they can be explicitly discussed in policy statements. For + example, a user initiating a third-party FTP transfer could grant + each FTP server a PC with a unique identity and inform each server of + the identity of the other, then when the two servers connected they + could authenticate themselves and know they are connected to the + proper party. + + In order for a party to have rights of it's own it requires a unique + identity. Possible options for obtaining an unique identity are: + + 1) Obtain an identity from a traditional Certification Authority + (CA). + + 2) Obtain a new identity independently - for example by using the + generated public key and a self-signed certificate. + + 3) Derive the new identity from an existing identity. + + + + + +Tuecke, et al. Standards Track [Page 8] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + In this document we describe an approach to option #3, because: + + * It is reasonably light-weight, as it can be done without + interacting with a third party. This is important when + creating identities dynamically. + + * As described in the previous section, a common use for PCs is + for restricted proxying, so deriving their identity from the + identity of the EEC makes this straightforward. Nonetheless + there are circumstances where the creator does not wish to + delegate all or any of its rights to a new entity. Since the + name is unique, this is easily accomplished by #3 as well, by + allowing the application of a policy to limit proxying. + +2.6. Description Of Approach + + This document defines an X.509 "Proxy Certificate" or "PC" as a means + of providing for restricted proxying within an (extended) X.509 PKI + based authentication system. + + A Proxy Certificate is an X.509 public key certificate with the + following properties: + + 1) It is signed by either an X.509 End Entity Certificate (EEC), or + by another PC. This EEC or PC is referred to as the Proxy Issuer + (PI). + + 2) It can sign only another PC. It cannot sign an EEC. + + 3) It has its own public and private key pair, distinct from any + other EEC or PC. + + 4) It has an identity derived from the identity of the EEC that + signed the PC. When a PC is used for authentication, in may + inherit rights of the EEC that signed the PC, subject to the + restrictions that are placed on that PC by the EEC. + + 5) Although its identity is derived from the EEC's identity, it is + also unique. This allows this identity to be used for + authorization as an independent identity from the identity of the + issuing EEC, for example in conjunction with attribute assertions + as defined in [i3]. + + 6) It contains a new X.509 extension to identify it as a PC and to + place policies on the use of the PC. This new extension, along + with other X.509 fields and extensions, are used to enable proper + path validation and use of the PC. + + + + +Tuecke, et al. Standards Track [Page 9] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + The process of creating a PC is as follows: + + 1) A new public and private key pair is generated. + + 2) That key pair is used to create a request for a Proxy Certificate + that conforms to the profile described in this document. + + 3) A Proxy Certificate, signed by the private key of the EEC or by + another PC, is created in response to the request. During this + process, the PC request is verified to ensure that the requested + PC is valid (e.g., it is not an EEC, the PC fields are + appropriately set, etc). + + When a PC is created as part of a delegation from entity A to entity + B, this process is modified by performing steps #1 and #2 within + entity B, then passing the PC request from entity B to entity A over + an authenticated, integrity checked channel, then entity A performs + step #3 and passes the PC back to entity B. + + Path validation of a PC is very similar to normal path validation, + with a few additional checks to ensure, for example, proper PC + signing constraints. + +2.7. Features Of This Approach + + Using Proxy Certificates to perform delegation has several features + that make it attractive: + + * Ease of integration + + o Because a PC requires only a minimal change to path validation, + it is very easy to incorporate support for Proxy Certificates + into existing X.509 based software. For example, SSL/TLS + requires no protocol changes to support authentication using a + PC. Further, an SSL/TLS implementation requires only minor + changes to support PC path validation, and to retrieve the + authenticated subject of the signing EEC instead of the subject + of the PC for authorization purposes. + + o Many existing authorization systems use the X.509 subject name + as the basis for access control. Proxy Certificates can be + used with such authorization systems without modification, + since such a PC inherits its name and rights from the EEC that + signed it and the EEC name can be used in place of the PC name + for authorization decisions. + + + + + + +Tuecke, et al. Standards Track [Page 10] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * Ease of use + + o Using PC for single sign-on helps make X.509 PKI authentication + easier to use, by allowing users to "login" once and then + perform various operations securely. + + o For many users, properly managing their own EEC private key is + a nuisance at best, and a security risk at worst. One option + easily enabled with a PC is to manage 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. Then the + repository can delegate a PC to the user with proxy rights, but + continue to protect the EEC private key in the repository. + + * Protection of private keys + + o By using the remote delegation approach outlined above, entity + A can delegate a PC to entity B, without entity B ever seeing + the private key of entity A, and without entity A ever seeing + the private key of the newly delegated PC held by entity B. In + other words, private keys never need to be shared or + communicated by the entities participating in a delegation of a + PC. + + o When implementing single sign-on, using a PC helps protect the + private key of the EEC, because it minimizes the exposure and + use of that private key. For example, when an EEC private key + is password protected on disk, the password and unencrypted + private key need only be available during the creation of the + PC. That PC can then be used for the remainder of its valid + lifetime, without requiring access to the EEC password or + private key. Similarly, when the EEC private key lives on a + smartcard, the smartcard need only be present in the machine + during the creation of the PC. + + * Limiting consequences of a compromised key + + o When creating a PC, the PI can limit the validity period of the + PC, the depth of the PC path that can be created by that PC, + and key usage of the PC and its descendents. Further, fine- + grained policies can be carried by a PC to even further + restrict the operations that can be performed using the PC. + These restrictions permit the PI to limit damage that could be + done by the bearer of the PC, either accidentally or + maliciously. + + + + + +Tuecke, et al. Standards Track [Page 11] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + o A compromised PC private key does NOT compromise the EEC + private key. This makes a short term, or an otherwise + restricted PC attractive for day-to-day use, since a + compromised PC does not require the user to go through the + usually cumbersome and time consuming process of having the EEC + with a new private key reissued by the CA. + + See Section 5 below for more discussion on how Proxy Certificates + relate to Attribute Certificates. + +3. Certificate and Certificate Extensions Profile + + This section defines the usage of X.509 certificate fields and + extensions in Proxy Certificates, and defines one new extension for + Proxy Certificate Information. + + All Proxy Certificates MUST include the Proxy Certificate Information + (ProxyCertInfo) extension defined in this section and the extension + MUST be critical. + +3.1. Issuer + + The Proxy Issuer of a Proxy Certificate MUST be either an End Entity + Certificate, or another Proxy Certificate. + + The Proxy Issuer MUST NOT have an empty subject field. + + The issuer field of a Proxy Certificate MUST contain the subject + field of its Proxy Issuer. + + If the Proxy Issuer certificate has the KeyUsage extension, the + Digital Signature bit MUST be asserted. + +3.2. Issuer Alternative Name + + The issuerAltName extension MUST NOT be present in a Proxy + Certificate. + +3.3. Serial Number + + The serial number of a Proxy Certificate (PC) SHOULD be unique + amongst all Proxy Certificates issued by a particular Proxy Issuer. + However, a Proxy Issuer MAY use an approach to assigning serial + numbers that merely ensures a high probability of uniqueness. + + + + + + + +Tuecke, et al. Standards Track [Page 12] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + For example, a Proxy Issuer MAY use a sequentially assigned integer + or a UUID to assign a unique serial number to a PC it issues. Or a + Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a + serial number with a high probability of uniqueness. + +3.4. Subject + + The subject field of a Proxy Certificate MUST be the issuer field + (that is the subject of the Proxy Issuer) appended with a single + Common Name component. + + The value of the Common Name SHOULD be unique to each Proxy + Certificate bearer amongst all Proxy Certificates with the same + issuer. + + If a Proxy Issuer issues two proxy certificates to the same bearer, + the Proxy Issuer MAY choose to use the same Common Name for both. + Examples of this include Proxy Certificates for different uses (e.g., + signing vs encryption) or the re-issuance of an expired Proxy + Certificate. + + The Proxy Issuer MAY use an approach to assigning Common Name values + that merely ensures a high probability of uniqueness. This value MAY + be the same value used for the serial number. + + The result of this approach is that all subject names of Proxy + Certificates are derived from the name of the issuing EEC (it will be + the first part of the subject name appended with one or more CN + components) and are unique to each bearer. + +3.5. Subject Alternative Name + + The subjectAltName extension MUST NOT be present in a Proxy + Certificate. + +3.6. Key Usage and Extended Key Usage + + If the Proxy Issuer certificate has a Key Usage extension, the + Digital Signature bit MUST be asserted. + + This document places no constraints on the presence or contents of + the key usage and extended key usage extension. However, section 4.2 + explains what functions should be allowed a proxy certificate by a + relying party. + + + + + + + +Tuecke, et al. Standards Track [Page 13] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +3.7. Basic Constraints + + The cA field in the basic constraints extension MUST NOT be TRUE. + +3.8. The ProxyCertInfo Extension + + A new extension, ProxyCertInfo, is defined in this subsection. + Presence of the ProxyCertInfo extension indicates that a certificate + is a Proxy Certificate and whether or not the issuer of the + certificate has placed any restrictions on its use. + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } + + id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } + + ProxyCertInfo ::= SEQUENCE { + pCPathLenConstraint INTEGER (0..MAX) OPTIONAL, + proxyPolicy ProxyPolicy } + + + ProxyPolicy ::= SEQUENCE { + policyLanguage OBJECT IDENTIFIER, + policy OCTET STRING OPTIONAL } + + If a certificate is a Proxy Certificate, then the proxyCertInfo + extension MUST be present, and this extension MUST be marked as + critical. + + If a certificate is not a Proxy Certificate, then the proxyCertInfo + extension MUST be absent. + + The ProxyCertInfo extension consists of one required and two optional + fields, which are described in detail in the following subsections. + +3.8.1. pCPathLenConstraint + + The pCPathLenConstraint field, if present, specifies the maximum + depth of the path of Proxy Certificates that can be signed by this + Proxy Certificate. A pCPathLenConstraint of 0 means that this + certificate MUST NOT be used to sign a Proxy Certificate. If the + pCPathLenConstraint field is not present then the maximum proxy path + length is unlimited. End entity certificates have unlimited maximum + proxy path lengths. + + + + + +Tuecke, et al. Standards Track [Page 14] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +3.8.2. proxyPolicy + + The proxyPolicy field specifies a policy on the use of this + certificate for the purposes of authorization. Within the + proxyPolicy, the policy field is an expression of policy, and the + policyLanguage field indicates the language in which the policy is + expressed. + + The proxyPolicy field in the proxyCertInfo extension does not define + a policy language to be used for proxy restrictions; rather, it + places the burden on those parties using that extension to define an + appropriate language, and to acquire an OID for that language (or to + select an appropriate previously-defined language/OID). Because it + is essential for the PI that issues a certificate with a proxyPolicy + field and the relying party that interprets that field to agree on + its meaning, the policy language OID must correspond to a policy + language (including semantics), not just a policy grammar. + + The policyLanguage field has two values of special importance, + defined in Appendix A, that MUST be understood by all parties + accepting Proxy Certificates: + + * id-ppl-inheritAll indicates that this is an unrestricted proxy + that inherits all rights from the issuing PI. An unrestricted + proxy is a statement that the Proxy Issuer wishes to delegate all + of its authority to the bearer (i.e., to anyone who has that proxy + certificate and can prove possession of the associated private + key). For purposes of authorization, this an unrestricted proxy + effectively impersonates the issuing PI. + + * id-ppl-independent indicates that this is an independent proxy + that inherits no rights from the issuing PI. This PC MUST be + treated as an independent identity by relying parties. The only + rights this PC has are those granted explicitly to it. + + For either of the policyLanguage values listed above, the policy + field MUST NOT be present. + + Other values for the policyLanguage field indicates that this is a + restricted proxy certification and have some other policy limiting + its ability to do proxying. In this case the policy field MAY be + present and it MUST contain information expressing the policy. If + the policy field is not present the policy MUST be implicit in the + 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 7). + + + + + +Tuecke, et al. Standards Track [Page 15] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + Proxy policies are used to limit the amount of authority delegated, + for example to assert that the proxy certificate may be used only to + make requests to a specific server, or only to authorize specific + operations on specific resources. This document is agnostic to the + policies that can be placed in the policy field. + + Proxy policies impose additional requirements on the relying party, + because only the relying party is in a position to ensure that those + policies are enforced. When making an authorization decision based + on a proxy certificate based on rights that proxy certificate + inherited from its issuer, it is the relying party's responsibility + to verify that the requested authority is compatible with all + policies in the PC's certificate path. In other words, the relying + party MUST verify that the following three conditions are all met: + + 1) The relying party MUST know how to interpret the proxy policy and + the request is allowed under that policy. + + 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 + EEC. + + 3) If the Proxy Issuer is another PC, then one of the following MUST + be true: + + a. The relying party's local policies authorize the Proxy Issuer + 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 verified + by verifying these three conditions on the Proxy Issuer in a + recursive manner. + + If these conditions are not met, the relying party MUST either deny + authorization, or ignore the PC and the whole certificate chain + including the EEC entirely when making its authorization decision + (i.e., make the same decision that it would have made had the PC and + it's certificate chain never been presented). + + The relying party MAY impose additional restrictions as to which + proxy certificates it accepts. For example, a relying party MAY + choose to reject all proxy certificates, or MAY choose to accept + proxy certificates only for certain operations, etc. + + Note that since a proxy certificate has a unique identity it MAY also + have rights granted to it by means other than inheritance from it's + issuer via its proxy policy. The rights granted to the bearer of a + PC are the union of the rights granted to the PC identity and the + + + +Tuecke, et al. Standards Track [Page 16] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + inherited rights. The inherited rights consist of the intersection + of the rights granted to the PI identity intersected with the proxy + policy in the PC. + + For example, imagine that Steve is authorized to read and write files + A and B on a file server, and that he uses his EEC to create a PC + that includes the policy that it can be used only to read or write + files A and C. Then a trusted attribute authority grants an + Attribute Certificate granting the PC the right to read file D. This + would make the rights of the PC equal to the union of the rights + granted to the PC identity (right to read file D) with the + intersection of the rights granted to Steve, the PI, (right to read + files A and B) with the policy in the PC (can only read files A and + C). This would mean the PC would have the following rights: + + * Right to read file A: Steve has this right and he issued the PC + and his policy grants this right to the PC. + + * Right to read file D: This right is granted explicitly to the PC + by a trusted authority. + + The PC would NOT have the following rights: + + * Right to read file B: Although Steve has this right, it is + excluded by his policy on the PC. + + * Right to read file C: Although Steve's policy grants this right, + he does not have this right himself. + + In many cases, the relying party will not have enough information to + evaluate the above criteria at the time that the certificate path is + validated. For example, if a certificate is used to authenticate a + connection to some server, that certificate is typically validated + during that authentication step, before any requests have been made + of the server. In that case, the relying party MUST either have some + authorization mechanism in place that will check the proxy policies, + or reject any certificate that contains proxy policies (or that has a + parent certificate that contains proxy policies). + +4. Proxy Certificate Path Validation + + Proxy Certification path processing verifies the binding between the + proxy certificate distinguished name and proxy certificate public + key. The binding is limited by constraints which are specified in + the certificates which comprise the path and inputs which are + specified by the relying party. + + + + + +Tuecke, et al. Standards Track [Page 17] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + This section describes an algorithm for validating proxy + certification paths. Conforming implementations of this + specification are not required to implement this algorithm, but MUST + provide functionality equivalent to the external behavior resulting + from this procedure. Any algorithm may be used by a particular + implementation so long as it derives the correct result. + + The algorithm presented in this section validates the proxy + certificate with respect to the current date and time. A conformant + implementation MAY also support validation with respect to some point + in the past. Note that mechanisms are not available for validating a + proxy certificate with respect to a time outside the certificate + validity period. + + Valid paths begin with the end entity certificate (EEC) that has + already been validated by public key certificate validation + procedures in RFC 3280 [n2]. The algorithm requires the public key + of the EEC and the EEC's subject distinguished name. + + To meet the goal of verifying the proxy certificate, the proxy + certificate path validation process verifies, among other things, + that a prospective certification path (a sequence of n certificates) + satisfies the following conditions: + + (a) for all x in {1, ..., n-1}, the subject of certificate x is the + issuer of proxy certificate x+1 and the subject distinguished + name of certificate x+1 is a legal subject distinguished name to + have been issued by certificate x; + + (b) certificate 1 is valid proxy certificate issued by the end entity + certificate whose information is given as input to the proxy + certificate path validation process; + + (c) certificate n is the proxy certificate to be validated; + + (d) for all x in {1, ..., n}, the certificate was valid at the time + in question; and + + (e) for all certificates in the path with a pCPathLenConstraint + field, the number of certificates in the path following that + certificate does not exceed the length specified in that field. + + At this point there is no mechanism defined for revoking proxy + certificates. + + + + + + + +Tuecke, et al. Standards Track [Page 18] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +4.1. Basic Proxy Certificate Path Validation + + This section presents the algorithm in four basic steps to mirror the + description of public key certificate path validation in RFC 3280: + (1) initialization, (2) basic proxy certificate processing, (3) + preparation for the next proxy certificate, and (4) wrap-up. Steps + (1) and (4) are performed exactly once. Step (2) is performed for + all proxy certificates in the path. Step (3) is performed for all + proxy certificates in the path except the final proxy certificate. + + Certificate path validation as described in RFC 3280 MUST have been + done prior to using this algorithm to validate the end entity + certificate. This algorithm then processes the proxy certificate + chain using the end entity certificate information produced by RFC + 3280 path validation. + +4.1.1. Inputs + + This algorithm assumes the following inputs are provided to the path + processing logic: + + (a) information about the entity certificate already verified using + RFC 3280 path validation. This information includes: + + (1) the end entity name, + + (2) the working_public_key output from RFC 3280 path validation, + + (3) the working_public_key_algorithm output from RFC 3280, + + (4) and the working_public_key_parameters output from RFC 3280 + path validation. + + (b) prospective proxy certificate path of length n. + + (c) acceptable-pc-policy-language-set: A set of proxy certificate + policy languages understood by the policy evaluation code. The + acceptable-pc-policy-language-set MAY contain the special value + id-ppl-anyLanguage (as defined in Appendix A) if the path + validation code should not check the proxy certificate policy + languages (typically because the set of known policy languages is + not known yet and will be checked later in the authorization + process). + + (d) the current date and time. + + + + + + +Tuecke, et al. Standards Track [Page 19] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +4.1.2. Initialization + + This initialization phase establishes the following state variables + based upon the inputs: + + (a) working_public_key_algorithm: the digital signature algorithm + used to verify the signature of a proxy certificate. The + working_public_key_algorithm is initialized from the input + information provided from RFC 3280 path validation. + + (b) working_public_key: the public key used to verify the signature + of a proxy certificate. The working_public_key is initialized + from the input information provided from RFC 3280 path + validation. + + (c) working_public_key_parameters: parameters associated with the + current public key, that may be required to verify a signature + (depending upon the algorithm). The + proxy_issuer_public_key_parameters variable is initialized from + the input information provided from RFC 3280 path validation. + + (d) working_issuer_name: the issuer distinguished name expected in + the next proxy certificate in the chain. The working_issuer_name + is initialized to the distinguished name in the end entity + certificate validated by RFC 3280 path validation. + + (e) max_path_length: this integer is initialized to n, is decremented + for each proxy certificate in the path. This value may also be + reduced by the pcPathLenConstraint value of any proxy certificate + in the chain. + + (f) proxy_policy_list: this list is empty to start and will be filled + in with the key usage extensions, extended key usage extensions + and proxy policies in the chain. + + Upon completion of the initialization steps, perform the basic + certificate processing steps specified in 4.1.3. + +4.1.3. Basic Proxy Certificate Processing + + The basic path processing actions to be performed for proxy + certificate i (for all i in [1..n]) are listed below. + + (a) Verify the basic certificate information. The certificate MUST + satisfy each of the following: + + + + + + +Tuecke, et al. Standards Track [Page 20] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + (1) The certificate was signed with the + working_public_key_algorithm using the working_public_key and + the working_public_key_parameters. + + (2) The certificate validity period includes the current time. + + (3) The certificate issuer name is the working_issuer_name. + + (4) The certificate subject name is the working_issuer_name with a + CN component appended. + + (b) The proxy certificate MUST have a ProxyCertInfo extension. + Process the extension as follows: + + (1) If the pCPathLenConstraint field is present in the + ProxyCertInfo field and the value it contains is less than + max_path_length, set max_path_length to its value. + + (2) If acceptable-pc-policy-language-set is not id-ppl- + anyLanguage, the OID in the policyLanguage field MUST be + present in acceptable-pc-policy-language-set. + + (c) The tuple containing the certificate subject name, policyPolicy, + key usage extension (if present) and extended key usage extension + (if present) must be appended to proxy_policy_list. + + (d) Process other certificate extensions, as described in [n2]: + + (1) Recognize and process any other critical extensions present in + the proxy certificate. + + (2) Process any recognized non-critical extension present in the + proxy certificate. + + If either step (a), (b) or (d) fails, the procedure terminates, + returning a failure indication and an appropriate reason. + + If i is not equal to n, continue by performing the preparatory steps + listed in 4.1.4. If i is equal to n, perform the wrap-up steps + listed in 4.1.5. + +4.1.4. Preparation for next Proxy Certificate + + (a) Verify max_path_length is greater than zero and decrement + max_path_length. + + (b) Assign the certificate subject name to working_issuer_name. + + + + +Tuecke, et al. Standards Track [Page 21] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + (c) Assign the certificate subjectPublicKey to working_public_key. + + (d) If the subjectPublicKeyInfo field of the certificate contains an + algorithm field with non-null parameters, assign the parameters + to the working_public_key_parameters variable. + + If the subjectPublicKeyInfo field of the certificate contains an + algorithm field with null parameters or parameters are omitted, + compare the certificate subjectPublicKey algorithm to the + working_public_key_algorithm. If the certificate + subjectPublicKey algorithm and the working_public_key_algorithm + are different, set the working_public_key_parameters to null. + + (e) Assign the certificate subjectPublicKey algorithm to the + working_public_key_algorithm variable. + + (f) If a key usage extension is present, verify that the + digitalSignature bit is set. + + If either check (a) or (f) fails, the procedure terminates, returning + a failure indication and an appropriate reason. + + If (a) and (f) complete successfully, increment i and perform the + basic certificate processing specified in 4.1.3. + +4.1.5. Wrap-up Procedures + + (a) Assign the certificate subject name to working_issuer_name. + + (b) Assign the certificate subjectPublicKey to working_public_key. + + (c) If the subjectPublicKeyInfo field of the certificate contains an + algorithm field with non-null parameters, assign the parameters + to the proxy_issuer_public_key_parameters variable. + + If the subjectPublicKeyInfo field of the certificate contains an + algorithm field with null parameters or parameters are omitted, + compare the certificate subjectPublicKey algorithm to the + proxy_issuer_public_key_algorithm. If the certificate + subjectPublicKey algorithm and the + proxy_issuer_public_key_algorithm are different, set the + proxy_issuer_public_key_parameters to null. + + (d) Assign the certificate subjectPublicKey algorithm to the + proxy_issuer_public_key_algorithm variable. + + + + + + +Tuecke, et al. Standards Track [Page 22] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +4.1.6. Outputs + + If path processing succeeds, the procedure terminates, returning a + success indication together with final value of the + working_public_key, the working_public_key_algorithm, the + working_public_key_parameters, and the proxy_policy_list. + +4.2. Using the Path Validation Algorithm + + Each Proxy Certificate contains a ProxyCertInfo extension, which + always contains a policy language OID, and may also contain a policy + OCTET STRING. These policies serve to indicate the desire of each + issuer in the proxy certificate chain, starting with the EEC, to + delegate some subset of their rights to the issued proxy certificate. + This chain of policies is returned by the algorithm to the + application. + + The application MAY make authorization decisions based on the subject + distinguished name of the proxy certificate or on one of the proxy + certificates in it's issuing chain or on the EEC that serves as the + root of the chain. If an application chooses to use the subject + distinguished name of a proxy certificate in the issuing chain or the + EEC it MUST use the returned policies to restrict the rights it + grants to the proxy certificate. If the application does not know + how to parse any policy in the policy chain it MUST not use, for the + purposes of making authorization decisions, the subject distinguished + name of any certificate in the chain prior to the certificate in + which the unrecognized policy appears. + + Application making authorization decisions based on the contents of + the proxy certificate key usage or extended key usage extensions MUST + examine the list of key usage, extended key usage and proxy policies + resulting from proxy certificate path validation and determine the + effective key usage functions of the proxy certificate as follows: + + * If a certificate is a proxy certificate with a proxy policy of + id-ppl-independent or an end entity certificate, the effective key + usage functions of that certificate is as defined by the key usage + and extended key usage extensions in that certificate. The key + usage functionality of the issuer has no bearing on the effective + key usage functionality. + + * If a certificate is a proxy certificate with a policy other than + id-ppl-independent, the effective key usage and extended key usage + functionality of the proxy certificate is the intersection of the + functionality of those extensions in the proxy certificate and the + effective key usage functionality of the proxy issuer. + + + + +Tuecke, et al. Standards Track [Page 23] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +5. Commentary + + This section provides non-normative commentary on Proxy Certificates. + +5.1. Relationship to Attribute Certificates + + An Attribute Certificate [i3] can be used to grant to one identity, + the holder, some attribute such as a role, clearance level, or + alternative identity such as "charging identity" or "audit identity". + This is accomplished by way of a trusted Attribute Authority (AA), + which issues signed Attribute Certificates (AC), each of which binds + an identity to a particular set of attributes. Authorization + decisions can then be made by combining information from the + authenticated End Entity Certificate providing the identity, with the + signed Attribute Certificates providing binding of that identity to + attributes. + + There is clearly some overlap between the capabilities provided by + Proxy Certificates and Attribute Certificates. However, the + combination of the two approaches together provides a broader + spectrum of solutions to authorization in X.509 based systems, than + either solution alone. This section seeks to clarify some of the + overlaps, differences, and synergies between Proxy Certificate and + Attribute Certificates. + +5.1.1. Types of Attribute Authorities + + For the purposes of this discussion, Attribute Authorities, and the + uses of the Attribute Certificates that they produce, can be broken + down into two broad classes: + + 1) End entity AA: An End Entity Certificate may be used to sign an + AC. This can be used, for example, to allow an end entity to + delegate some of its privileges to another entity. + + 2) Third party AA: A separate entity, aside from the end entity + involved in an authenticated interaction, may sign ACs in order to + bind the authenticated identity with additional attributes, such + as role, group, etc. For example, when a client authenticates + with a server, the third party AA may provide an AC that binds the + client identity to a particular group, which the server then uses + for authorization purposes. + + This second type of Attribute Authority, the third party AA, works + equally well with an EEC or a PC. For example, unrestricted Proxy + Certificates can be used to delegate the EEC's identity to various + other parties. Then when one of those other parties uses the PC to + authenticate with a service, that service will receive the EEC's + + + +Tuecke, et al. Standards Track [Page 24] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + identity via the PC, and can apply any ACs that bind that identity to + attributes in order to determine authorization rights. Additionally + PC with policies could be used to selectively deny the binding of ACs + to a particular proxy. An AC could also be bound to a particular PC + using the subject or issuer and serial number of the proxy + certificate. There would appear to be great synergies between the + use of Proxy Certificates and Attribute Certificates produced by + third party Attribute Authorities. + + However, the uses of Attribute Certificates that are granted by the + first type of Attribute Authority, the end entity AA, overlap + considerably with the uses of Proxy Certificates as described in the + previous sections. Such Attribute Certificates are generally used + for delegation of rights from one end entity to others, which clearly + overlaps with the stated purpose of Proxy Certificates, namely single + sign-on and delegation. + +5.1.2. Delegation Using Attribute Certificates + + In the motivating example in Section 2, PCs are used to delegate + Steve's identity to the various other jobs and entities that need to + act on Steve's behalf. This allows those other entities to + authenticate as if they were Steve, for example to the mass storage + system. + + A solution to this example could also be cast using Attribute + Certificates that are signed by Steve's EEC, which grant to the other + entities in this example the right to perform various operations on + Steve's behalf. In this example, the reliable file transfer service + and all the hosts involved in file transfers, the starter program, + the agent, the simulation jobs, and the post-processing job would + each have their own EECs. Steve's EEC would therefore issue ACs to + bind each of those other EEC identities to attributes that grant the + necessary privileges allow them to, for example, access the mass + storage system. + + However, this AC based solution to delegation has some disadvantages + as compared to the PC based solution: + + * All protocols, authentication code, and identity based + authorization services must be modified to understand ACs. With + the PC solution, protocols (e.g., TLS) likely need no + modification, authentication code needs minimal modification + (e.g., to perform PC aware path validation), and identity based + authorization services need minimal modification (e.g., possibly + to find the EEC name and to check for any proxy policies). + + + + + +Tuecke, et al. Standards Track [Page 25] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * ACs need to be created by Steve's EEC, which bind attributes to + each of the other identities involved in the distributed + application (i.e., the agent, simulation jobs, and post-processing + job the file transfer service, the hosts transferring files). + This implies that Steve must know in advance which other + identities may be involved in this distributed application, in + order to generate the appropriate ACs which are signed by Steve's + ECC. On the other hand, the PC solution allows for much more + flexibility, since parties can further delegate a PC without a + priori knowledge by the originating EEC. + + There are many unexplored tradeoffs and implications in this + discussion of delegation. However, reasonable arguments can be made + in favor of either an AC based solution to delegation or a PC based + solution to delegation. The choice of which approach should be taken + in a given instance may depend on factors such as the software that + it needs to be integrated into, the type of delegation required, and + other factors. + +5.1.3. Propagation of Authorization Information + + One possible use of Proxy Certificates is to carry authorization + information associated with a particular identity. + + The merits of placing authorization information into End Entity + Certificates (also called a Public Key Certificate or PKC) have been + widely debated. For example, Section 1 of "An Internet Attribute + Certificate Profile for Authorization" [i3] states: + + "Authorization information may be placed in a PKC extension or + placed in a separate attribute certificate (AC). The placement of + authorization information in PKCs is usually undesirable for two + reasons. First, authorization information often does not have the + same lifetime as the binding of the identity and the public key. + When authorization information is placed in a PKC extension, the + general result is the shortening of the PKC useful lifetime. + Second, the PKC issuer is not usually authoritative for the + authorization information. This results in additional steps for + the PKC issuer to obtain authorization information from the + authoritative source. + + For these reasons, it is often better to separate authorization + information from the PKC. Yet, authorization information also + needs to be bound to an identity. An AC provides this binding; it + is simply a digitally signed (or certified) identity and set of + attributes." + + + + + +Tuecke, et al. Standards Track [Page 26] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + Placing authorization information in a PC mitigates the first + undesirable property cited above. Since a PC has a lifetime that is + mostly independent of (always shorter than) its signing EEC, a PC + becomes a viable approach for carrying authorization information for + the purpose of delegation. + + The second undesirable property cited above is true. If a third + party AA is authoritative, then using ACs issued by that third party + AA is a natural approach to disseminating authorization information. + However, this is true whether the identity being bound by these ACs + comes from an EEC (PKC), or from a PC. + + There is one case, however, that the above text does not consider. + When performing delegation, it is usually the EEC itself that is + authoritative (not the EEC issuer, or any third party AA). That is, + it is up to the EEC to decide what authorization rights it is willing + to grant to another party. In this situation, including such + authorization information into PCs that are generated by the EEC + seems a reasonable approach to disseminating such information. + +5.1.4. Proxy Certificate as Attribute Certificate Holder + + In a system that employs both PCs and ACs, one can imagine the + utility of allowing a PC to be the holder of an AC. This would allow + for a particular delegated instance of an identity to be given an + attribute, rather than all delegated instances of that identity being + given the attribute. + + However, the issue of how to specify a PC as the holder of an AC + remains open. An AC could be bound to a particular instance of a PC + using the unique subject name of the PC, or it's issuer and serial + number combination. + + Unrestricted PCs issued by that PC would then inherit those ACs and + independent PCs would not. PCs issued with a policy would depend on + the policy as to whether or not they inherit the issuing PC's ACs + (and potentially which ACs they inherit). + + While an AC can be bound to one PC by the AA, how can the AA restrict + that PC from passing it on to a subsequently delegated PC? One + possible solution would be to define an extension to attribute + certificates that allows the attribute authority to state whether an + issued AC is to apply only to the particular entity to which it is + bound, or if it may apply to PCs issued by that entity. + + One issue that an AA in this circumstance would need to be aware of + is that the PI of the PC that the AA bound the AC to, could issue + another PC with the same name as the original PC to a different + + + +Tuecke, et al. Standards Track [Page 27] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + entity, effectively stealing the AC. This implies that an AA issuing + an AC to a PC need to not only trust the entity holding the PC, but + the entity holding the PC's issuer as well. + +5.2. Kerberos 5 Tickets + + The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a + widely used authentication system based on conventional (shared + secret key) cryptography. It provides support for single sign-on via + creation of "Ticket Granting Tickets" or "TGT", and support for + delegation of rights via "forwardable tickets". + + Kerberos 5 tickets have informed many of the ideas surrounding X.509 + Proxy Certificates. For example, the local creation of a short-lived + PC can be used to provide single sign-on in an X.509 PKI based + system, just as creation of short-lived TGT allows for single sign-on + in a Kerberos based system. And just as a TGT can be forwarded + (i.e., delegated) to another entity to allow for proxying in a + Kerberos based system, so can a PC can be delegated to allow for + proxying in an X.509 PKI based system. + + A major difference between a Kerberos TGT and an X.509 PC is that + while creation and delegation of a TGT requires the involvement of a + third party (Key Distribution Center), a PC can be unilaterally + created without the active involvement of a third party. That is, a + user can directly create a PC from an EEC for single sign-on + capability, without requiring communication with a third party. And + an entity with a PC can delegate the PC to another entity (i.e., by + creating a new PC, signed by the first) without requiring + communication with a third party. + + The method used by Kerberos implementations to protect a TGT can also + be used to protect the private key of a PC. For example, some Unix + implementations of Kerberos use standard Unix file system security to + protect a user's TGT from compromise. Similarly, the Globus + Toolkit's Grid Security Infrastructure implementation of Proxy + Certificates protects a user's PC private key using this same + approach. + +5.3. Examples of usage of Proxy Restrictions + + This section gives some examples of Proxy Certificate usage and some + examples of how the Proxy policy can be used to restrict Proxy + Certificates. + + + + + + + +Tuecke, et al. Standards Track [Page 28] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +5.3.1. Example use of proxies without Restrictions + + Steve wishes to perform a third-party FTP transfer between two FTP + servers. Steve would use an existing PC to authenticate to both + servers and delegate a PC to both hosts. He would inform each host + of the unique subject name of the PC given to the other host. When + the servers establish the data channel connection to each other, they + use these delegated credentials to perform authentication and verify + they are talking to the correct entity by checking the result of the + authentication matches the name as provided by Steve. + +5.3.2. Example use of proxies with Restrictions + + Steve wishes to delegate to a process the right to perform a transfer + of a file from host H1 to host H2 on his behalf. Steve would + delegate a PC to the process and he would use Proxy Policy to + restrict the delegated PC to two rights - the right to read file F1 + on host H1 and the right to write file F2 on host H2. + + The process then uses this restricted PC to authenticate to servers + H1 and H2. The process would also delegate a PC to both servers. + Note that these delegated PCs would inherit the restrictions of their + parents, though this is not relevant to this example. As in the + example in the previous Section, each host would be provided with the + unique name of the PC given to the other server. + + Now when the process issues the command to transfer the file F1 on H1 + and to F2 on H2, these two servers perform an authorization check + based on the restrictions in the PC that the process used to + authenticate with them (in addition to any local policy they have). + Namely H1 checks that the PC gives the user the right to read F1 and + H2 checks that the PC gives the user the right to write F2. When + setting up the data channel the servers would again verify the names + resulting from the authentication match the names provided by Steve + as in the example in the previous Section. + + The extra security provided by these restrictions is that now if the + PC delegated to the process by Steve is stolen, its use is greatly + limited. + +5.4. Delegation Tracing + + A relying party accepting a Proxy Certificate may have an interest in + knowing which parties issued earlier Proxy Certificates in the + certificate chain and to whom they delegated them. For example it + may know that a particular service or resource is known to have been + + + + + +Tuecke, et al. Standards Track [Page 29] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + compromised and if any part of a Proxy Certificate's chain was issued + to the compromised service a relying party may wish to disregard the + chain. + + A delegation tracing mechanism was considered by the authors as + additional information to be carried in the ProxyCertInfo extension. + However at this time agreement has not been reached as to what this + information should include so it was left out of this document, and + will instead be considered in future revisions. The debate mainly + centers on whether the tracing information should simply contain the + identity of the issuer and receiver or it should also contain all the + details of the delegated proxy and a signed statement from the + receiver that the proxy was actually acceptable to it. + +5.4.1. Site Information in Delegation Tracing + + In some cases, it may be desirable to know the hosts involved in a + delegation transaction (for example, a relying party may wish to + reject proxy certificates that were created on a specific host or + domain). An extension could be modified to include the PA's and + Acceptor's IP addresses; however, IP addresses are typically easy to + spoof, and in some cases the two parties to a transaction may not + agree on the IP addresses being used (e.g., if the Acceptor is on a + host that uses NAT, the Acceptor and the PA may disagree about the + Acceptor's IP address). + + Another suggestion was, in those cases where domain information is + needed, to require that the subject names of all End Entities + involved (the Acceptor(s) and the End Entity that appears in a PC's + certificate path) include domain information. + +6. Security Considerations + + In this Section we discuss security considerations related to the use + of Proxy Certificates. + +6.1. Compromise of a Proxy Certificate + + A Proxy Certificate is generally less secure than the EEC that issued + it. This is due to the fact that the private key of a PC is + generally not protected as rigorously as that of the EEC. For + example, the private key of a PC is often protected using only file + system security, in order to allow that PC to be used for single + sign-on purposes. This makes the PC more susceptible to compromise. + + However, the risk of a compromised PC is only the misuse of a single + user's privileges. Due to the PC path validation checks, a PC cannot + be used to sign an EEC or PC for another user. + + + +Tuecke, et al. Standards Track [Page 30] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + Further, a compromised PC can only be misused for the lifetime of the + PC, and within the bound of the restriction policy carried by the PC. + Therefore, one common way to limit the misuse of a compromised PC is + to limit its validity period to no longer than is needed, and/or to + include a restriction policy in the PC that limits the use of the + (compromised) PC. + + In addition, if a PC is compromised, it does NOT compromise the EEC + that created the PC. This property is of great utility in protecting + the highly valuable, and hard to replace, public key of the EEC. In + other words, the use of Proxy Certificates to provide single sign-on + capabilities in an X.509 PKI environment can actually increase the + security of the end entity certificates, because creation and use of + the PCs for user authentication limits the exposure of the EEC + private key to only the creation of the first level PC. + +6.2. Restricting Proxy Certificates + + The pCPathLenConstraint field of the proxyCertInfo extension can be + used by an EEC to limit subsequent delegation of the PC. A service + may choose to only authorize a request if a valid PC can be delegated + to it. An example of such as service is a job starter, which may + choose to reject a job start request if a valid PC cannot be + delegated to it. By limiting the pCPathLenConstraint, an EEC can + ensure that a compromised PC of one job cannot be used to start + additional jobs elsewhere. + + An EEC or PC can limit what a new PC can be used for by turning off + bits in the Key Usage and Extended Key Usage extensions. Once a key + usage or extended key usage has been removed, the path validation + algorithm ensures that it cannot be added back in a subsequent PC. + In other words, key usage can only be decreased in PC chains. + + The EEC could use the CRL Distribution Points extension and/or OCSP + to take on the responsibility of revoking PCs that it had issued, if + it felt that they were being misused. + +6.3. Relying Party Trust of Proxy Certificates + + The relying party that is going to authorize some actions on the + basis of a PC will be aware that it has been presented with a PC, and + can determine the depth of the delegation and the time that the + delegation took place. It may want to use this information in + addition to the information from the signing EEC. Thus a highly + secure resource might refuse to accept a PC at all, or maybe only a + single level of delegation, etc. + + + + + +Tuecke, et al. Standards Track [Page 31] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + The relying party should also be aware that since the policy + restricting the rights of a PC is the intersection of the policy of + 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 no + mechanism in place to enforce unique subject names of PCs, if an + issuer were to issue two PCs with identical names and keys, but + different 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 + chain. Ultimately, this means the relying party places trust in the + entities that are acting as Proxy Issuers in the chain to behave + properly. + +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). + + + + + +Tuecke, et al. Standards Track [Page 32] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +7. IANA Considerations + + IANA has established a registry for policy languages. Registration + under IETF space is by IETF standards action as described in [i8]. + 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. + + OID Description + --- ----------- + 1.3.6.1.5.5.7.21.1 id-ppl-inheritALL + 1.3.6.1.5.5.7.21.2 id-ppl-independent + +8. References + +8.1. Normative References + + [n1] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [n2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + +8.2. Informative References + + [i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. + Tuecke, "A National-Scale Authentication Infrastructure", + IEEE Computer, vol. 33, pp. 60-66, 2000. + + [i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [i3] Farrell, S. and R. Housley, "An Internet Attribute + Certificate Profile for Authorization", RFC 3281, April 2002. + + [i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A + Security Architecture for Computational Grids", presented at + Proceedings of the 5th ACM Conference on Computer and + Communications Security, 1998. + + [i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the + Grid: Enabling Scalable Virtual Organizations", International + Journal of Supercomputer Applications, 2001. + + [i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993. + + + + +Tuecke, et al. Standards Track [Page 33] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + [i7] Neuman, B. Clifford, "Proxy-Based Authorization and + Accounting for Distributed Systems", In Proceedings of the + 13th International Conference on Distributed Computing + Systems, pages 283-291, May 1993. + + [i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA + Considerations Section in RFC", RFC 2434, October 1998. + +9. Acknowledgments + + We are pleased to acknowledge significant contributions to this + document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, + Sam Meder, Jim Schaad, and Frank Siebenlist. + + We are grateful to numerous colleagues for discussions on the topics + covered in this paper, in particular (in alphabetical order, with + apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy + Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill + Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, + Gene Tsudik. + + We are also grateful to members of the Global Grid Forum (GGF) Grid + Security Infrastructure working group (GSI-WG), and the Internet + Engineering Task Force (IETF) Public-Key Infrastructure (X.509) + working group (PKIX) for feedback on this document. + + This work was supported in part by the Mathematical, Information, and + Computational Sciences Division subprogram of the Office of Advanced + Scientific Computing Research, U.S. Department of Energy, under + Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense + Advanced Research Projects Agency under contract N66001-96-C-8523; by + the National Science Foundation; and by the NASA Information Power + Grid project. + + + + + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 34] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Appendix A. 1988 ASN.1 Module + + PKIXproxy88 { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + proxy-cert-extns(25) } + + DEFINITIONS EXPLICIT TAGS ::= + + BEGIN + + -- EXPORTS ALL -- + + -- IMPORTS NONE -- + + -- PKIX specific OIDs + + id-pkix OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + -- private certificate extensions + id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } + + -- Locally defined OIDs + + -- The proxy certificate extension + id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } + + -- Proxy certificate policy languages + id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 } + + -- Proxy certificate policies languages defined in + id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 } + id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 } + id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 } + + -- The ProxyCertInfo Extension + ProxyCertInfoExtension ::= SEQUENCE { + pCPathLenConstraint ProxyCertPathLengthConstraint + OPTIONAL, + proxyPolicy ProxyPolicy } + + ProxyCertPathLengthConstraint ::= INTEGER + ProxyPolicy ::= SEQUENCE { + policyLanguage OBJECT IDENTIFIER, + policy OCTET STRING OPTIONAL } + + END + + + +Tuecke, et al. Standards Track [Page 35] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Authors' Addresses + + Steven Tuecke + Distributed Systems Laboratory + Mathematics and Computer Science Division + Argonne National Laboratory + Argonne, IL 60439 + + Phone: 630-252-8711 + EMail: tuecke@mcs.anl.gov + + + Von Welch + National Center for Supercomputing Applications + University of Illinois + + EMail: vwelch@ncsa.uiuc.edu + + + Doug Engert + Argonne National Laboratory + + EMail: deengert@anl.gov + + + Laura Pearlman + University of Southern California, Information Sciences Institute + + EMail: laura@isi.edu + + + Mary Thompson + Lawrence Berkeley National Laboratory + + EMail: mrthompson@lbl.gov + + + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 36] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Tuecke, et al. Standards Track [Page 37] +