From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2559.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc2559.txt (limited to 'doc/rfc/rfc2559.txt') diff --git a/doc/rfc/rfc2559.txt b/doc/rfc/rfc2559.txt new file mode 100644 index 0000000..3768a2a --- /dev/null +++ b/doc/rfc/rfc2559.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group S. Boeyen +Request for Comments: 2559 Entrust +Updates: 1778 T. Howes +Category: Standards Track Netscape + P. Richard + Xcert + April 1999 + + + Internet X.509 Public Key Infrastructure + Operational Protocols - LDAPv2 + +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 (1999). All Rights Reserved. + +1. Abstract + + The protocol described in this document is designed to satisfy some + of the operational requirements within the Internet X.509 Public Key + Infrastructure (IPKI). Specifically, this document addresses + requirements to provide access to Public Key Infrastructure (PKI) + repositories for the purposes of retrieving PKI information and + managing that same information. The mechanism described in this + document is based on the Lightweight Directory Access Protocol (LDAP) + v2, defined in RFC 1777, defining a profile of that protocol for use + within the IPKI and updates encodings for certificates and revocation + lists from RFC 1778. Additional mechanisms addressing PKIX + operational requirements are specified in separate documents. + + The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' + in this document are to be interpreted as described in RFC 2119. + +2. Introduction + + This specification is part of a multi-part standard for development + of a Public Key Infrastructure (PKI) for the Internet. This + specification addresses requirements to provide retrieval of X.509 + PKI information, including certificates and CRLs from a repository. + This specification also addresses requirements to add, delete and + + + +Boeyen, et al. Standards Track [Page 1] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + modify PKI information in a repository. A profile based on the LDAP + version 2 protocol is provided to satisfy these requirements. + +3. Model + + The PKI components, as defined in PKIX Part 1, which are involved in + PKIX operational protocol interactions include: + + - End Entities + - Certification Authorities (CA) + - Repository + + End entities and CAs using LDAPv2, retrieve PKI information from the + repository using a subset of the LDAPv2 protocol. + + CAs populate the repository with PKI information using a subset of + the LDAPv2 protocol. + +4. Lightweight Directory Access Protocol (LDAP) + + The following sections examine the retrieval of PKI information from + a repository and management of PKI information in a repository. A + profile of the LDAPv2 protocol is defined for providing these + services. + + Section 5 satisfies the requirement to retrieve PKI information (a + certificate, CRL, or other information of interest) from an entry in + the repository, where the retrieving entity (either an end entity or + a CA) has knowledge of the name of the entry. This is termed + "repository read". + + Section 6 satisfies the same requirement as 5 for the situation where + the name of the entry is not known, but some other related + information which may optionally be used as a filter against + candidate entries in the repository, is known. This is termed + "repository search". + + Section 7 satisfies the requirement of CAs to add, delete and modify + PKI information information (a certificate, CRL, or other information + of interest)in the repository. This is termed "repository modify". + + The subset of LDAPv2 needed to support each of these functions is + described below. Note that the repository search service is a + superset of the repository read service in terms of the LDAPv2 + functionality needed. + + Note that all tags are implicit by default in the ASN.1 definitions + that follow. + + + +Boeyen, et al. Standards Track [Page 2] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +5. LDAP Repository Read + + To retrieve information from an entry corresponding to the subject or + issuer name of a certificate, requires a subset of the following + three LDAP operations: + + BindRequest (and BindResponse) + SearchRequest (and SearchResponse) + UnbindRequest + + The subset of each REQUIRED operation is given below. + +5.1. Bind + +5.1.1. Bind Request + + The full LDAP v2 Bind Request is defined in RFC 1777. + + An application providing a LDAP repository read service MUST + implement the following subset of this operation: + + BindRequest ::= + [APPLICATION 0] SEQUENCE { + version INTEGER (2), + name LDAPDN, -- MUST accept NULL LDAPDN + simpleauth [0] OCTET STRING -- MUST accept NULL simple + } + + An application providing a LDAP repository read service MAY implement + other aspects of the BindRequest as well. + + Different services may have different security requirements. Some + services may allow anonymous search, others may require + authentication. Those services allowing anonymous search may choose + only to allow search based on certain criteria and not others. + + A LDAP repository read service SHOULD implement some level of + anonymous search access. A LDAP repository read service MAY implement + authenticated search access. + +5.1.2. Bind Response + + The full LDAPv2 BindResponse is described in RFC 1777. + + An application providing a LDAP repository read service MUST + implement this entire protocol element, though only the following + error codes may be returned from a Bind operation: + + + + +Boeyen, et al. Standards Track [Page 3] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + success (0), + operationsError (1), + protocolError (2), + authMethodNotSupported (7), + noSuchObject (32), + invalidDNSyntax (34), + inappropriateAuthentication (48), + invalidCredentials (49), + busy (51), + unavailable (52), + unwillingToPerform (53), + other (80) + +5.2. Search + +5.2.1. Search Request + + The full LDAPv2 SearchRequest is defined in RFC 1777. + + An application providing a LDAP repository read service MUST + implement the following subset of the SearchRequest. + + SearchRequest ::= + [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + }, + derefAliases ENUMERATED { + neverDerefAliases (0), + }, + sizeLimit INTEGER (0), + timeLimit INTEGER (0), + attrsOnly BOOLEAN, -- FALSE only + filter Filter, + attributes SEQUENCE OF AttributeType + } + + Filter ::= + CHOICE { + present [7] AttributeType, -- "objectclass" only + } + + This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read" + operation: a base object search with a filter testing for the + existence of the objectClass attribute. + + + + + +Boeyen, et al. Standards Track [Page 4] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + An application providing a LDAP repository read service MAY implement + other aspects of the SearchRequest as well. + +5.2.2. + + The full LDAPv2 SearchResponse is defined in RFC 1777. + + An application providing a LDAP repository read service over LDAPv2 + MUST implement the full SearchResponse. + + Note that in the case of multivalued attributes such as + userCertificate a SearchResponse containing this attribute will + include all values, assuming the requester has sufficient access + permissions. The application/relying party may need to select an + appropriate value to be used. Also note that retrieval of a + certificate from a named entry does not guarantee that the + certificate will include that same Distinguished Name (DN) and in + some cases the subject DN in the certificate may be NULL. + +5.3. Unbind + + The full LDAPv2 UnbindRequest is defined in RFC 1777. + + An application providing a LDAP repository read service MUST + implement the full UnbindRequest. + +6. LDAP Repository Search + + To search, using arbitrary criteria, for an entry in a repository + containing a certificate, CRL, or other information of interest, + requires a subset of the following three LDAP operations: + + BindRequest (and BindResponse) + SearchRequest (and SearchResponse) + UnbindRequest + + The subset of each operation REQUIRED is given below. + +6.1. Bind + + The BindRequest and BindResponse subsets needed are the same as those + described in Section 5.1. + + The full LDAP v2 Bind Request is defined in RFC 1777. + + + + + + + +Boeyen, et al. Standards Track [Page 5] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +6.2. Search + +6.2.1. Search Request + + The full LDAPv2 SearchRequest is defined in RFC 1777. + + An application providing a LDAP repository search service MUST + implement the following subset of the SearchRequest protocol unit. + + SearchRequest ::= + [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + singleLevel (1), + wholeSubtree (2) + }, + derefAliases ENUMERATED { + neverDerefAliases (0), + }, + sizeLimit INTEGER (0 .. maxInt), + timeLimit INTEGER (0 .. maxInt), + attrsOnly BOOLEAN, -- FALSE only + filter Filter, + attributes SEQUENCE OF AttributeType + } + + All aspects of the SearchRequest MUST be supported, except for the + following: + + - Only the neverDerefAliases value of derefAliases needs to be + supported + + - Only the FALSE value for attrsOnly needs to be supported + + This subset provides a more general search capability. It is a + superset of the SearchRequest subset defined in Section 5.2.1. The + elements added to this service are: + + - singleLevel and wholeSubtree scope needs to be supported + + - sizeLimit is included + + - timeLimit is included + + - Enhanced filter capability + + + + + +Boeyen, et al. Standards Track [Page 6] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + An application providing a LDAP repository search service MAY + implement other aspects of the SearchRequest as well. + +6.2.2. Search Response + + The full LDAPv2 SearchResponse is defined in RFC 1777. + + An application providing a LDAP repository search service over LDAPv2 + MUST implement the full SearchResponse. + +6.3. Unbind + + An application providing a LDAP repository search service MUST + implement the full UnbindRequest. + +7. LDAP Repository Modify + + To add, delete and modify PKI information in a repository requires a + subset of the following LDAP operations: + + BindRequest (and BindResponse) + ModifyRequest (and ModifyResponse) + AddRequest (and AddResponse) + DelRequest (and DelResponse + UnbindRequest + + The subset of each operation REQUIRED is given below. + +7.1. Bind + + The full LDAP v2 Bind Request is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the following subset of this operation: + + BindRequest ::= + [APPLICATION 0] SEQUENCE { + version INTEGER (2), + name LDAPDN, + simpleauth [0] OCTET STRING + } + + A LDAP repository modify service MUST implement authenticated access. + + The BindResponse subsets needed are the same as those described in + Section 5.1.2. + + + + + +Boeyen, et al. Standards Track [Page 7] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +7.2. Modify + +7.2.1. Modify Request + + The full LDAPv2 ModifyRequest is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the following subset of the ModifyRequest protocol unit. + + ModifyRequest ::= + [APPLICATION 6] SEQUENCE { + object LDAPDN, + modification SEQUENCE OF SEQUENCE { + operation ENUMERATED { + add (0), + delete (1) + }, + modification SEQUENCE { + type AttributeType, + values SET OF + AttributeValue + } + } + } + + All aspects of the ModifyRequest MUST be supported, except for the + following: + + - Only the add and delete values of operation need to be supported + +7.2.2. Modify Response + + The full LDAPv2 ModifyResponse is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the full ModifyResponse. + +7.3. Add + +7.3.1. Add Request + + The full LDAPv2 AddRequest is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the full AddRequest. + + + + + + +Boeyen, et al. Standards Track [Page 8] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +7.3.2. Add Response + + The full LDAPv2 AddResponse is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the full AddResponse. + +7.4. Delete + +7.4.1. Delete Request + + The full LDAPv2 DelRequest is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the full DelRequest. + +7.4.2. Delete Response + + The full LDAPv2 DelResponse is defined in RFC 1777. + + An application providing a LDAP repository modify service MUST + implement the full DelResponse. + +7.5. Unbind + + An application providing a LDAP repository modify service MUST + implement the full UnbindRequest. + +8. Non-standard attribute value encodings + + When conveyed in LDAP requests and results, attributes defined in + X.500 are to be encoded using string representations defined in RFC + 1778, The String Representation of Standard Attribute Syntaxes. + These string encodings were based on the attribute definitions from + X.500(1988). Thus, the string representations of the PKI information + elements are for version 1 certificates and version 1 revocation + lists. Since this specification uses version 3 certificates and + version 2 revocation lists, as defined in X.509(1997), the RFC 1778 + string encoding of these attributes is inappropriate. + + For this reason, these attributes MUST be encoded using a syntax + similar to the syntax "Undefined" from section 2.1 of RFC 1778: + values of these attributes are encoded as if they were values of type + "OCTET STRING", with the string value of the encoding being the DER- + encoding of the value itself. For example, when writing a + userCertificate to the repository, the CA generates a DER-encoding of + the certificate and uses that encoding as the value of the + userCertificate attribute in the LDAP Modify request.This encoding + + + +Boeyen, et al. Standards Track [Page 9] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + style is consistent with the encoding scheme proposed for LDAPv3, + which is now being defined within the IETF. + + Note that certificates and revocation lists will be transferred using + this mechanism rather than the string encodings in RFC 1778 and + client systems which do not understand this encoding may experience + problems with these attributes. + +9. Transport + + An application providing a LDAP repository read service, LDAP + repository search service, or LDAP repository modify service MUST + support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC + 1777. + + An application providing a LDAP repository read service, LDAP + repository search service, or LDAP repository modify service MAY + support LDAPv2 transport over other reliable transports as well. + +10. Security Considerations + + Since the elements of information which are key to the PKI service + (certificates and CRLs) are both digitally signed pieces of + information, additional integrity service is NOT REQUIRED. As + neither information element need be kept secret and anonymous access + to such information, for retrieval purposes is generally acceptable, + privacy service is NOT REQUIRED for information retrieval requests. + + CAs have additional requirements, including modification of PKI + information. Simple authentication alone is not sufficient for these + purposes. It is RECOMMENDED that some stronger means of + authentication and/or (if simple authentication is used) some means + of protecting the privacy of the password is used, (e.g. accept + modifications only via physically secure networks, use IPsec, use SSH + or TLS or SSL tunnel). Without such authentication, it is possible + that a denial-of-service attack could occur where the attacker + replaces valid certificates with bogus ones. + + For the LDAP repository modify service, profiled in section 7, there + are some specific security considerations with respect to access + control. These controls apply to a repository which is under the same + management control as the CA. Organizations operating directories are + NOT REQUIRED to provide external CAs access permission to their + directories. + + + + + + + +Boeyen, et al. Standards Track [Page 10] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + + The CA MUST have access control permissions allowing it to: + + For CA entries: + - add, modify and delete all PKI attributes for its own + directory entry; + - add, modify and delete all values of these attributes. + + For CRL distribution point entries (if used): + - create, modify and delete entries of object class + cRLDistributionPoint immediately subordinate to its own + entry; + - add, modify and delete all attributes, and all values of + these attributes for these entries. + + For subscriber (end-entity) entries: + - add, modify and delete the attribute userCertificate and all + values of that attribute, issued by this CA to/from these + entries. + + The CA is the ONLY entity with these permissions. + + An application providing LDAP repository read, LDAP repository + search, or LDAP repository modify service as defined in this + specification is NOT REQUIRED to implement any additional security + features other than those described herein, however an implementation + SHOULD do so. + +11. References + + [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol", RFC 1777, March 1995. + + [2] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String + Representation of Standard Attribute Syntaxes", RFC 1778, March + 1995. + + [3] Bradner, S., "Key Words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + +Boeyen, et al. Standards Track [Page 11] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +12. Authors' Addresses + + Sharon Boeyen + Entrust Technologies Limited + 750 Heron Road + Ottawa, Ontario + Canada K1V 1A7 + + EMail: sharon.boeyen@entrust.com + + + Tim Howes + Netscape Communications Corp. + 501 E. Middlefield Rd. + Mountain View, CA 94043 + USA + + EMail: howes@netscape.com + + + Patrick Richard + Xcert Software Inc. + Suite 1001, 701 W. Georgia Street + P.O. Box 10145 + Pacific Centre + Vancouver, B.C. + Canada V7Y 1C6 + + EMail: patr@xcert.com + + + + + + + + + + + + + + + + + + + + + + +Boeyen, et al. Standards Track [Page 12] + +RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Boeyen, et al. Standards Track [Page 13] + -- cgit v1.2.3