As per Relevance of the word providing, we have this rfc below:
Network Working Group S.
Request for Comments: 2559
Updates: 1778 T.
Category: Standards Track
P.
April 1999
Internet X.509 Public Key
Operational Protocols - LDAPv
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
The protocol described in this document is designed to satisfy
of the operational requirements within the Internet X.509 Public
Infrastructure (IPKI). Specifically, this document
requirements to provide access to Public Key Infrastructure (PKI
repositories for the purposes of retrieving PKI information
managing that same information. The mechanism described in
document is based on the Lightweight Directory Access Protocol (LDAP
v2, defined in RFC 1777, defining a profile of that protocol for
within the IPKI and updates encodings for certificates and
lists from RFC 1778. Additional mechanisms addressing
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.
This specification is part of a multi-part standard for
of a Public Key Infrastructure (PKI) for the Internet.
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
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
version 2 protocol is provided to satisfy these requirements
3.
The PKI components, as defined in PKIX Part 1, which are involved
PKIX operational protocol interactions include
- End
- Certification Authorities (CA
-
End entities and CAs using LDAPv2, retrieve PKI information from
repository using a subset of the LDAPv2 protocol
CAs populate the repository with PKI information using a subset
the LDAPv2 protocol
4. Lightweight Directory Access Protocol (LDAP
The following sections examine the retrieval of PKI information
a repository and management of PKI information in a repository.
profile of the LDAPv2 protocol is defined for providing
services
Section 5 satisfies the requirement to retrieve PKI information (
certificate, CRL, or other information of interest) from an entry
the repository, where the retrieving entity (either an end entity
a CA) has knowledge of the name of the entry. This is
"repository read".
Section 6 satisfies the same requirement as 5 for the situation
the name of the entry is not known, but some other
information which may optionally be used as a filter
candidate entries in the repository, is known. This is
"repository search".
Section 7 satisfies the requirement of CAs to add, delete and
PKI information information (a certificate, CRL, or other
of interest)in the repository. This is termed "repository modify".
The subset of LDAPv2 needed to support each of these functions
described below. Note that the repository search service is
superset of the repository read service in terms of the LDAPv
functionality needed
Note that all tags are implicit by default in the ASN.1
that follow
Boeyen, et al. Standards Track [Page 2]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
5. LDAP Repository
To retrieve information from an entry corresponding to the subject
issuer name of a certificate, requires a subset of the
three LDAP operations
BindRequest (and BindResponse
SearchRequest (and SearchResponse
The subset of each REQUIRED operation is given below
5.1.
5.1.1. Bind
The full LDAP v2 Bind Request is defined in RFC 1777.
An application providing a LDAP repository read service
implement the following subset of this operation
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (2),
name LDAPDN, -- MUST accept NULL
simpleauth [0] OCTET STRING -- MUST accept NULL
}
An application providing a LDAP repository read service MAY
other aspects of the BindRequest as well
Different services may have different security requirements.
services may allow anonymous search, others may
authentication. Those services allowing anonymous search may
only to allow search based on certain criteria and not others
A LDAP repository read service SHOULD implement some level
anonymous search access. A LDAP repository read service MAY
authenticated search access
5.1.2. Bind
The full LDAPv2 BindResponse is described in RFC 1777.
An application providing a LDAP repository read service
implement this entire protocol element, though only the
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.
5.2.1. Search
The full LDAPv2 SearchRequest is defined in RFC 1777.
An application providing a LDAP repository read service
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
filter Filter
attributes SEQUENCE OF
}
Filter ::=
CHOICE {
present [7] AttributeType, -- "objectclass"
}
This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read
operation: a base object search with a filter testing for
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
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 LDAPv
MUST implement the full SearchResponse
Note that in the case of multivalued attributes such
userCertificate a SearchResponse containing this attribute
include all values, assuming the requester has sufficient
permissions. The application/relying party may need to select
appropriate value to be used. Also note that retrieval of
certificate from a named entry does not guarantee that
certificate will include that same Distinguished Name (DN) and
some cases the subject DN in the certificate may be NULL
5.3.
The full LDAPv2 UnbindRequest is defined in RFC 1777.
An application providing a LDAP repository read service
implement the full UnbindRequest
6. LDAP Repository
To search, using arbitrary criteria, for an entry in a
containing a certificate, CRL, or other information of interest
requires a subset of the following three LDAP operations
BindRequest (and BindResponse
SearchRequest (and SearchResponse
The subset of each operation REQUIRED is given below
6.1.
The BindRequest and BindResponse subsets needed are the same as
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.
6.2.1. Search
The full LDAPv2 SearchRequest is defined in RFC 1777.
An application providing a LDAP repository search service
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
filter Filter
attributes SEQUENCE OF
}
All aspects of the SearchRequest MUST be supported, except for
following
- Only the neverDerefAliases value of derefAliases needs to
- Only the FALSE value for attrsOnly needs to be
This subset provides a more general search capability. It is
superset of the SearchRequest subset defined in Section 5.2.1.
elements added to this service are
- singleLevel and wholeSubtree scope needs to be
- sizeLimit is
- timeLimit is
- Enhanced filter
Boeyen, et al. Standards Track [Page 6]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
An application providing a LDAP repository search service
implement other aspects of the SearchRequest as well
6.2.2. Search
The full LDAPv2 SearchResponse is defined in RFC 1777.
An application providing a LDAP repository search service over LDAPv
MUST implement the full SearchResponse
6.3.
An application providing a LDAP repository search service
implement the full UnbindRequest
7. LDAP Repository
To add, delete and modify PKI information in a repository requires
subset of the following LDAP operations
BindRequest (and BindResponse
ModifyRequest (and ModifyResponse
AddRequest (and AddResponse
DelRequest (and
The subset of each operation REQUIRED is given below
7.1.
The full LDAP v2 Bind Request is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the following subset of this operation
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (2),
name LDAPDN
simpleauth [0] OCTET
}
A LDAP repository modify service MUST implement authenticated access
The BindResponse subsets needed are the same as those described
Section 5.1.2.
Boeyen, et al. Standards Track [Page 7]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
7.2.
7.2.1. Modify
The full LDAPv2 ModifyRequest is defined in RFC 1777.
An application providing a LDAP repository modify service
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
}
}
}
All aspects of the ModifyRequest MUST be supported, except for
following
- Only the add and delete values of operation need to be
7.2.2. Modify
The full LDAPv2 ModifyResponse is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the full ModifyResponse
7.3.
7.3.1. Add
The full LDAPv2 AddRequest is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the full AddRequest
Boeyen, et al. Standards Track [Page 8]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
7.3.2. Add
The full LDAPv2 AddResponse is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the full AddResponse
7.4.
7.4.1. Delete
The full LDAPv2 DelRequest is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the full DelRequest
7.4.2. Delete
The full LDAPv2 DelResponse is defined in RFC 1777.
An application providing a LDAP repository modify service
implement the full DelResponse
7.5.
An application providing a LDAP repository modify service
implement the full UnbindRequest
8. Non-standard attribute value
When conveyed in LDAP requests and results, attributes defined
X.500 are to be encoded using string representations defined in
1778, The String Representation of Standard Attribute Syntaxes
These string encodings were based on the attribute definitions
X.500(1988). Thus, the string representations of the PKI
elements are for version 1 certificates and version 1
lists. Since this specification uses version 3 certificates
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
similar to the syntax "Undefined" from section 2.1 of RFC 1778:
values of these attributes are encoded as if they were values of
"OCTET STRING", with the string value of the encoding being the DER
encoding of the value itself. For example, when writing
userCertificate to the repository, the CA generates a DER-encoding
the certificate and uses that encoding as the value of
userCertificate attribute in the LDAP Modify request.This
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
this mechanism rather than the string encodings in RFC 1778
client systems which do not understand this encoding may
problems with these attributes
9.
An application providing a LDAP repository read service,
repository search service, or LDAP repository modify service
support LDAPv2 transport over TCP, as defined in Section 3.1 of
1777.
An application providing a LDAP repository read service,
repository search service, or LDAP repository modify service
support LDAPv2 transport over other reliable transports as well
10. Security
Since the elements of information which are key to the PKI
(certificates and CRLs) are both digitally signed pieces
information, additional integrity service is NOT REQUIRED.
neither information element need be kept secret and anonymous
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
information. Simple authentication alone is not sufficient for
purposes. It is RECOMMENDED that some stronger means
authentication and/or (if simple authentication is used) some
of protecting the privacy of the password is used, (e.g.
modifications only via physically secure networks, use IPsec, use
or TLS or SSL tunnel). Without such authentication, it is
that a denial-of-service attack could occur where the
replaces valid certificates with bogus ones
For the LDAP repository modify service, profiled in section 7,
are some specific security considerations with respect to
control. These controls apply to a repository which is under the
management control as the CA. Organizations operating directories
NOT REQUIRED to provide external CAs access permission to
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
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
cRLDistributionPoint immediately subordinate to its
entry
- add, modify and delete all attributes, and all values
these attributes for these entries
For subscriber (end-entity) entries
- add, modify and delete the attribute userCertificate and
values of that attribute, issued by this CA to/from
entries
The CA is the ONLY entity with these permissions
An application providing LDAP repository read, LDAP
search, or LDAP repository modify service as defined in
specification is NOT REQUIRED to implement any additional
features other than those described herein, however an
SHOULD do so
11.
[1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory
Protocol", RFC 1777, March 1995.
[2] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The
Representation of Standard Attribute Syntaxes", RFC 1778,
1995.
[3] Bradner, S., "Key Words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Boeyen, et al. Standards Track [Page 11]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
12. Authors'
Sharon
Entrust Technologies
750 Heron
Ottawa,
Canada K1V 1A
EMail: sharon.boeyen@entrust.
Tim
Netscape Communications Corp
501 E. Middlefield Rd
Mountain View, CA 94043
EMail: howes@netscape.
Patrick
Xcert Software Inc
Suite 1001, 701 W. Georgia
P.O. Box 10145
Pacific
Vancouver, B.C
Canada V7Y 1C
EMail: patr@xcert.
Boeyen, et al. Standards Track [Page 12]
RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
13. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Boeyen, et al. Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
