upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-01 19:39:29 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Zap RFCs being moved to Historical status

Browse source
This commit is contained in:
Kurt Zeilenga 2001-12-20 18:20:34 +00:00
parent 9a000a86bd
commit 6905533757
8 changed files with 0 additions and 4934 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
doc/rfc/INDEX
View file

@ -1,19 +1,13 @@
This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc1275.txt X.500 Replication Requirements (I)
rfc1279.txt X.500 and Domains (E)
rfc1308.txt Executive Intro to Directory Services - X.500 (FYI)
rfc1309.txt Technical Overview of Directory Services - X.500 (FYI)
rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I)
rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I)
rfc1777.txt Lightweight Directory Access Protocol (DS)
rfc1778.txt LDAP String Representation of Attribute Types (DS/updated)
rfc1779.txt LDAP String Representation of DNs (DS/obsolete)
rfc1781.txt Using the OSI Directory to Achieve User Friendly Naming (PS)
rfc1798.txt Connection-less LDAP (PS)
rfc1823.txt LDAP C API (I)
rfc1960.txt LDAP String Representation of Search Filters (PS/obsolete)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2119.txt Key words (BCP)
rfc2164.txt X.500/LDAP MIXER address mapping (PS)
@ -31,7 +25,6 @@ rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
rfc2559.txt Internet X.509 PKI Operational Protocols - LDAPv2 (PS,updates)
rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2596.txt Use of Language Codes in LDAP (PS)

202
doc/rfc/rfc1275.txt
View file

@ -1,202 +0,0 @@
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1275 University College London
November 1991
Replication Requirements to provide an Internet Directory using X.500
Status of this Memo
This memo provides information for the Internet community. It
does not specify an Internet standard. Distribution of this memo
is unlimited.
Abstract
This RFCconsiders certain deficiencies of the 1988 X.500
standard, which need to be addressed before an effective open
Internet Directory can be established using these protocols and
services [CCI88]. The only areas considered are primary
problems, to which solutions must be found before a pilot can be
deployed. This RFCconcerns itself with deficiencies which can
only be addressed by use of additional protocol or procedures for
distributed operation.
RFC 1275 Replication Requirements November 1991
1 Distributed Operation Extensions
The Internet Directory will operate DSAs over TCP/IP using RFC 1006
[RC87], and DSAs over the an ISO Network Service. Distributed
operation procedures should not require full connectivity.
2 Knowledge Replication
Knowledge information is critical to resolution of names, and
performing searches. Knowledge information high up the tree needs to
be widely available. Consider resolving a name below ``Country=US''.
To do this, a DSA needs to have full knowledge at this point. Many
DSAs need to be able to do this, in order to give reasonable response
and availability. It would be an unacceptable bottleneck to force
such resolution to a single or small number of DSAs. To replicate
this knowledge widely, a systematic approach to replication is needed.
3 Data Replication
Searches are often made at the root and country level, and this is a
vital service (e.g., an approximate match of an organisation name).
Data needs to be collected in such a way that this sort of searching
is reasonably efficient. The usual X.500 approach of subordinate
references militates against this. At a node in the DIT, subordinate
references to the entries below are held. These entries will be in
many DSAs, each of which needs to be accessed in order to perform the
single level search. It is suggested that replication of data is
necessary to achieve this.
The major requirement for this replication is high up the DIT, where
information must be replicated between different implementations. At
lower levels of the DIT, it is reasonable for DSAs to be of the same
implementation and to use implementation specific techniques in order
to achieve performance and availability.
4 Alternate DSAs
When a DSA Referral is returned, only the master DSA is indicated.
This will lead to a single point of failure. It seems important to
allow for additional references to slave copies, in order to get
Hardcastle-Kille Page 1
RFC 1275 Replication Requirements November 1991
better availability. This needs to be solved in conjunction with the
problem described in the previous section.
5 Guidelines for use of Replication
To be effective, the replication specification needs to provide
guidelines for deployment in the pilot, in order to meet the desired
service criteria.
6 Some scaling targets
Most techniques for replication have scaling limits. It is important
that mechanisms used do not stress the limits of the mechanism. The
order of magnitude envisioned in the pilot is 100 000 non-leaf entries
and several million leaf entries.
References
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services
on top of the TCP. Request for Comments 1006, Northrop
Corporation Technology Center, May 1987.
7 Security Considerations
Security considerations are not discussed in this memo.
8 Author's Address
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Hardcastle-Kille Page 2
RFC 1275 Replication Requirements November 1991
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 3

1235
doc/rfc/rfc1777.txt
View file

File diff suppressed because it is too large Load diff

675
doc/rfc/rfc1778.txt
View file

@ -1,675 +0,0 @@
Network Working Group T. Howes
Request for Comments: 1778 University of Michigan
Obsoletes: 1488 S. Kille
Category: Standards Track ISODE Consortium
W. Yeong
Performance Systems International
C. Robbins
NeXor Ltd.
March 1995
The String Representation of Standard Attribute Syntaxes
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.
Abstract
The Lightweight Directory Access Protocol (LDAP) [9] requires that
the contents of AttributeValue fields in protocol elements be octet
strings. This document defines the requirements that must be
satisfied by encoding rules used to render X.500 Directory attribute
syntaxes into a form suitable for use in the LDAP, then goes on to
define the encoding rules for the standard set of attribute syntaxes
defined in [1,2] and [3].
1. Attribute Syntax Encoding Requirements.
This section defines general requirements for lightweight directory
protocol attribute syntax encodings. All documents defining attribute
syntax encodings for use by the lightweight directory protocols are
expected to conform to these requirements.
The encoding rules defined for a given attribute syntax must produce
octet strings. To the greatest extent possible, encoded octet
strings should be usable in their native encoded form for display
purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing the
lightweight directory protocols.
Howes, Kille, Yeong & Robbins [Page 1]
RFC 1778 Syntax Encoding March 1995
2. Standard Attribute Syntax Encodings
For the purposes of defining the encoding rules for the standard
attribute syntaxes, the following auxiliary BNF definitions will be
used:
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
'A' | 'B' | 'C' | 'D' | 'E' | 'F'
<k> ::= <a> | <d> | '-'
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
'/' | ':' | '?' | ' '
<CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
<letterstring> ::= <a> | <a> <letterstring>
<numericstring> ::= <d> | <d> <numericstring>
<keystring> ::= <a> | <a> <anhstring>
<anhstring> ::= <k> | <k> <anhstring>
<printablestring> ::= <p> | <p> <printablestring>
<space> ::= ' ' | ' ' <space>
2.1. Undefined
Values of type Undefined are encoded as if they were values of type
Octet String, with the string value being the BER-encoded version of
the value.
2.2. Case Ignore String
A string of type caseIgnoreStringSyntax is encoded as the string
value itself.
Howes, Kille, Yeong & Robbins [Page 2]
RFC 1778 Syntax Encoding March 1995
2.3. Case Exact String
The encoding of a string of type caseExactStringSyntax is the string
value itself.
2.4. Printable String
The encoding of a string of type printableStringSyntax is the string
value itself.
2.5. Numeric String
The encoding of a string of type numericStringSyntax is the string
value itself.
2.6. Octet String
The encoding of a string of type octetStringSyntax is the string
value itself.
2.7. Case Ignore IA5 String
The encoding of a string of type caseIgnoreIA5String is the string
value itself.
2.8. IA5 String
The encoding of a string of type iA5StringSyntax is the string value
itself.
2.9. T61 String
The encoding of a string of type t61StringSyntax is the string value
itself.
2.10. Case Ignore List
Values of type caseIgnoreListSyntax are encoded according to the
following BNF:
<caseignorelist> ::= <caseignorestring> |
<caseignorestring> '$' <caseignorelist>
<caseignorestring> ::= a string encoded according to the rules for Case
Ignore String as above.
Howes, Kille, Yeong & Robbins [Page 3]
RFC 1778 Syntax Encoding March 1995
2.11. Case Exact List
Values of type caseExactListSyntax are encoded according to the
following BNF:
<caseexactlist> ::= <caseexactstring> |
<caseexactstring> '$' <caseexactlist>
<caseexactstring> ::= a string encoded according to the rules for Case
Exact String as above.
2.12. Distinguished Name
Values of type distinguishedNameSyntax are encoded to have the
representation defined in [5].
2.13. Boolean
Values of type booleanSyntax are encoded according to the following
BNF:
<boolean> ::= "TRUE" | "FALSE"
Boolean values have an encoding of "TRUE" if they are logically true,
and have an encoding of "FALSE" otherwise.
2.14. Integer
Values of type integerSyntax are encoded as the decimal
representation of their values, with each decimal digit represented
by the its character equivalent. So the digit 1 is represented by the
character
2.15. Object Identifier
Values of type objectIdentifierSyntax are encoded according to the
following BNF:
<oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
<descr> ::= <keystring>
<numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
In the above BNF, <descr> is the syntactic representation of an
object descriptor. When encoding values of type
objectIdentifierSyntax, the first encoding option should be used in
preference to the second, which should be used in preference to the
Howes, Kille, Yeong & Robbins [Page 4]
RFC 1778 Syntax Encoding March 1995
third wherever possible. That is, in encoding object identifiers,
object descriptors (where assigned and known by the implementation)
should be used in preference to numeric oids to the greatest extent
possible. For example, in encoding the object identifier representing
an organizationName, the descriptor "organizationName" is preferable
to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
2.16. Telephone Number
Values of type telephoneNumberSyntax are encoded as if they were
Printable String types.
2.17. Telex Number
Values of type telexNumberSyntax are encoded according to the
following BNF:
<telex-number> ::= <actual-number> '$' <country> '$' <answerback>
<actual-number> ::= <printablestring>
<country> ::= <printablestring>
<answerback> ::= <printablestring>
In the above, <actual-number> is the syntactic representation of the
number portion of the TELEX number being encoded, <country> is the
TELEX country code, and <answerback> is the answerback code of a
TELEX terminal.
2.18. Teletex Terminal Identifier
Values of type teletexTerminalIdentifier are encoded according to the
following BNF:
<teletex-id> ::= <printablestring> 0*('$' <ttx-parm>)
<ttx-param> ::= <ttx-key> ':' <ttx-value>
<ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
<ttx-value> ::= <octetstring>
In the above, the first <printablestring> is the encoding of the
first portion of the teletex terminal identifier to be encoded, and
the subsequent 0 or more <printablestrings> are subsequent portions
of the teletex terminal identifier.
Howes, Kille, Yeong & Robbins [Page 5]
RFC 1778 Syntax Encoding March 1995
2.19. Facsimile Telephone Number
Values of type FacsimileTelephoneNumber are encoded according to the
following BNF:
<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
In the above, the first <printablestring> is the actual fax number,
and the <faxparm> tokens represent fax parameters.
2.20. Presentation Address
Values of type PresentationAddress are encoded to have the
representation described in [6].
2.21. UTC Time
Values of type uTCTimeSyntax are encoded as if they were Printable
Strings with the strings containing a UTCTime value.
2.22. Guide (search guide)
Values of type Guide, such as values of the searchGuide attribute,
are encoded according to the following BNF:
<guide-value> ::= [ <object-class> '#' ] <criteria>
<object-class> ::= an encoded value of type objectIdentifierSyntax
<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
<criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
[ '(' ] <criteria> '|' <criteria-set> [ ')' ]
<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
Howes, Kille, Yeong & Robbins [Page 6]
RFC 1778 Syntax Encoding March 1995
2.23. Postal Address
Values of type PostalAddress are encoded according to the following
BNF:
<postal-address> ::= <t61string> | <t61string> '$' <postal-address>
In the above, each <t61string> component of a postal address value is
encoded as a value of type t61StringSyntax.
2.24. User Password
Values of type userPasswordSyntax are encoded as if they were of type
octetStringSyntax.
2.25. User Certificate
Values of type userCertificate are encoded according to the following
BNF:
<certificate> ::= <version> '#' <serial> '#' <signature-algorithm-id>
'#' <issuer> '#' <validity> '#' <subject>
'#' <public-key-info> '#' <encrypted-sign-value>
<version> ::= <integervalue>
<serial> ::= <integervalue>
<signature-algorithm-id> ::= <algorithm-id>
<issuer> ::= an encoded Distinguished Name
<validity> ::= <not-before-time> '#' <not-after-time>
<not-before-time> ::= <utc-time>
<not-after-time> ::= <utc-time>
<algorithm-parameters> ::= <null> | <integervalue> |
'{ASN}' <hex-string>
<subject> ::= an encoded Distinguished Name
<public-key-info> ::= <algorithm-id> '#' <encrypted-sign-value>
<encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
<algorithm-id> ::= <oid> '#' <algorithm-parameters>
Howes, Kille, Yeong & Robbins [Page 7]
RFC 1778 Syntax Encoding March 1995
<utc-time> ::= an encoded UTCTime value
<hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
2.26. CA Certificate
Values of type cACertificate are encoded as if the values were of
type userCertificate.
2.27. Authority Revocation List
Values of type authorityRevocationList are encoded according to the
following BNF:
<certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time>
[ '#' <revoked-certificates> ]
'#' <signature-algorithm-id>
'#' <encrypted-sign-value>
<revoked-certificates> ::= 1*( '#' <revoked-certificate> )
<signature-algorithm-id> '#' <encrypted-sign-value>
<revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#'
<serial> '#' <utc-time>
The syntactic components <signature-algorithm-id>, <issuer>,
<encrypted-sign-value>, <utc-time>, <subject> and <serial> have the
same definitions as in the BNF for the userCertificate attribute
syntax.
2.28. Certificate Revocation List
Values of type certificateRevocationList are encoded as if the values
were of type authorityRevocationList.
2.29. Cross Certificate Pair
Values of type crossCertificatePair are encoded according to the
following BNF:
<certificate-pair> ::= <forward> '#' <reverse>
| <forward>
| <reverse>
<forward> ::= 'forward:' <certificate>
<reverse> ::= 'reverse:' <certificate>
Howes, Kille, Yeong & Robbins [Page 8]
RFC 1778 Syntax Encoding March 1995
The syntactic component <certificate> has the same definition as in
the BNF for the userCertificate attribute syntax.
2.30. Delivery Method
Values of type deliveryMethod are encoded according to the following
BNF:
<delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
<pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
2.31. Other Mailbox
Values of the type otherMailboxSyntax are encoded according to the
following BNF:
<otherMailbox> ::= <mailbox-type> '$' <mailbox>
<mailbox-type> ::= an encoded Printable String
<mailbox> ::= an encoded IA5 String
In the above, <mailbox-type> represents the type of mail system in
which the mailbox resides, for example "Internet" or "MCIMail"; and
<mailbox> is the actual mailbox in the mail system defined by
<mailbox-type>.
2.32. Mail Preference
Values of type mailPreferenceOption are encoded according to the
following BNF:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
2.33. MHS OR Address
Values of type MHS OR Address are encoded as strings, according to
the format defined in [10].
Howes, Kille, Yeong & Robbins [Page 9]
RFC 1778 Syntax Encoding March 1995
2.34. Distribution List Submit Permission
Values of type DLSubmitPermission are encoded as strings, according
to the following BNF:
<dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
| <dl-label> ':' <dl-value>
<dlgroup-label> ::= 'group_member'
<dlgroup-value> ::= <name>
<name> ::= an encoded Distinguished Name
<dl-label> ::= 'individual' | 'dl_member' | 'pattern'
<dl-value> ::= <orname>
<orname> ::= <address> '#' <dn>
| <address>
<address> ::= <add-label> ':' <oraddress>
<dn> ::= <dn-label> ':' <name>
<add-label> = 'X400'
<dn-label> = 'X500'
where <oraddress> is as defined in RFC 1327.
2.35. Photo
Values of type Photo are encoded as if they were octet strings
containing JPEG images in the JPEG File Interchange Format (JFIF), as
described in [8].
2.36. Fax
Values of type Fax are encoded as if they were octet strings
containing Group 3 Fax images as defined in [7].
Howes, Kille, Yeong & Robbins [Page 10]
RFC 1778 Syntax Encoding March 1995
3. Security Considerations
Security issues are not discussed in this memo.
4. Acknowledgements
Many of the attribute syntax encodings defined in this document are
adapted from those used in the QUIPU X.500 implementation. The
contributions of the authors of the QUIPU implementation in the
specification of the QUIPU syntaxes [4] are gratefully acknowledged.
5. Bibliography
[1] The Directory: Selected Attribute Syntaxes. CCITT,
Recommendation X.520.
[2] Information Processing Systems -- Open Systems Interconnection --
The Directory: Selected Attribute Syntaxes.
[3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
RFC 1274, University College London, November 1991.
[4] The ISO Development Environment: User's Manual -- Volume 5:
QUIPU. Colin Robbins, Stephen E. Kille.
[5] Kille, S., "A String Representation of Distinguished Names", RFC
1779, ISODE Consortium, March 1995.
[6] Kille, S., "A String Representation for Presentation Addresses",
RFC 1278, University College London, November 1991.
[7] Terminal Equipment and Protocols for Telematic Services -
Standardization of Group 3 facsimile apparatus for document
transmission. CCITT, Recommendation T.4.
[8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-
Cube Microsystems, Milpitas, CA, September 1, 1992.
[9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, Performance Systems International,
University of Michigan, ISODE Consortium, March 1995.
[10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
"Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach
Consulting, Inc., Soft*Switch, Inc., August 1993.
Howes, Kille, Yeong & Robbins [Page 11]
RFC 1778 Syntax Encoding March 1995
6. Authors' Addresses
Tim Howes
University of Michigan
ITD Research Systems
535 W William St.
Ann Arbor, MI 48103-4943
USA
Phone: +1 313 747-4454
EMail: tim@umich.edu
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
UK
Phone: +44-71-223-4062
EMail: S.Kille@isode.com
Wengyik Yeong
PSI Inc.
510 Huntmar Park Drive
Herndon, VA 22070
USA
Phone: +1 703-450-8001
EMail: yeongw@psilink.com
Colin Robbins
NeXor Ltd
University Park
Nottingham
NG7 2RD
UK
Howes, Kille, Yeong & Robbins [Page 12]

454
doc/rfc/rfc1779.txt
View file

@ -1,454 +0,0 @@
Network Working Group S. Kille
Request for Comments: 1779 ISODE Consortium
Obsoletes: 1485 March 1995
Category: Standards Track
A 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.
Abstract
The OSI Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1.
When a distinguished name is communicated between to users not using
a directory protocol (e.g., in a mail message), there is a need to
have a user-oriented string representation of distinguished name.
This specification defines a string format for representing names,
which is designed to give a clean representation of commonly used
names, whilst being able to represent any distinguished name.
Table of Contents
1. Why a notation is needed ................................... 2
2. A notation for Distinguished Name .......................... 2
2.1 Goals ................................................ 2
2.2 Informal definition .................................. 2
2.3 Formal definition .................................... 4
3. Examples ................................................... 6
4. Acknowledgements ........................................... 7
5. References ................................................. 7
6. Security Considerations .................................... 8
7. Author's Address ........................................... 8
Kille [Page 1]
RFC 1779 DN Representation March 1995
1. Why a notation is needed
Many OSI Applications make use of Distinguished Names (DN) as defined
in the OSI Directory, commonly known as X.500 [1]. This
specification assumes familiarity with X.500, and the concept of
Distinguished Name. It is important to have a common format to be
able to unambiguously represent a distinguished name. This might be
done to represent a directory name on a business card or in an email
message. There is a need for a format to support human to human
communication, which must be string based (not ASN.1) and user
oriented. This notation is targeted towards a general user oriented
system, and in particular to represent the names of humans. Other
syntaxes may be more appropriate for other uses of the directory.
For example, the OSF Syntax may be more appropriate for some system
oriented uses. (The OSF Syntax uses "/" as a separator, and forms
names in a manner intended to resemble UNIX filenames).
2. A notation for Distinguished Name
2.1 Goals
The following goals are laid out:
o To provide an unambiguous representation of a distinguished name
o To be an intuitive format for the majority of names
o To be fully general, and able to represent any distinguished name
o To be amenable to a number of different layouts to achieve an
attractive representation.
o To give a clear representation of the contents of the
distinguished name
2.2 Informal definition
This notation is designed to be convenient for common forms of name.
Some examples are given. The author's directory distinguished name
would be written:
CN=Steve Kille,
O=ISODE Consortium, C=GB
Kille [Page 2]
RFC 1779 DN Representation March 1995
This may be folded, perhaps to display in multi-column format. For
example:
CN=Steve Kille,
O=ISODE Consortium,
C=GB
Another name might be:
CN=Christian Huitema, O=INRIA, C=FR
Semicolon (";") may be used as an alternate separator. The
separators may be mixed, but this usage is discouraged.
CN=Christian Huitema; O=INRIA; C=FR
In running text, this would be written as <CN=Christian Huitema;
O=INRIA; C=FR>. Another example, shows how different attribute types
are handled:
CN=James Hacker,
L=Basingstoke,
O=Widget Inc,
C=GB
Here is an example of a multi-valued Relative Distinguished Name,
where the namespace is flat within an organisation, and department is
used to disambiguate certain names:
OU=Sales + CN=J. Smith, O=Widget Inc., C=US
The final examples show both methods quoting of a comma in an
Organisation name:
CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
Kille [Page 3]
RFC 1779 DN Representation March 1995
2.3 Formal definition
A formal definition can now be given. The structure is specified in
a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC
822, with the terminals enclosed in <> [2]. This definition is in an
abstract character set, and so may be written in any character set
supporting the explicitly defined special characters. The quoting
mechanism is used for the following cases:
o Strings containing ",", "+", "=" or """ , <CR>, "<",
">", "#", or ";".
o Strings with leading or trailing spaces
o Strings containing consecutive spaces
There is an escape mechanism from the normal user oriented form, so
that this syntax may be used to print any valid distinguished name.
This is ugly. It is expected to be used only in pathological cases.
There are two parts to this mechanism:
1. Attributes types are represented in a (big-endian) dotted
notation. (e.g., OID.2.6.53).
2. Attribute values are represented in hexadecimal (e.g. #0A56CF).
Each pair of hex digits defines an octet, which is the ASN.1 Basic
Encoding Rules value of the Attribute Value.
The keyword specification is optional in the BNF, but mandatory for
this specification. This is so that the same BNF may be used for the
related specification on User Friendly Naming [5]. When this
specification is followed, the attribute type keywords must always be
present.
A list of valid keywords for well known attribute types used in
naming is given in Table 1. Keywords may contain spaces, but shall
not have leading or trailing spaces. This is a list of keywords
which must be supported. These are chosen because they appear in
common forms of name, and can do so in a place which does not
correspond to the default schema used. A register of valid keywords
is maintained by the IANA.
Kille [Page 4]
RFC 1779 DN Representation March 1995
<name> ::= <name-component> ( <spaced-separator> )
| <name-component> <spaced-separator> <name>
<spaced-separator> ::= <optional-space>
<separator>
<optional-space>
<separator> ::= "," | ";"
<optional-space> ::= ( <CR> ) *( " " )
<name-component> ::= <attribute>
| <attribute> <optional-space> "+"
<optional-space> <name-component>
<attribute> ::= <string>
| <key> <optional-space> "=" <optional-space> <string>
<key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
<keychar> ::= letters, numbers, and space
<oid> ::= <digitstring> | <digitstring> "." <oid>
<digitstring> ::= 1*<digit>
<digit> ::= digits 0-9
<string> ::= *( <stringchar> | <pair> )
| '"' *( <stringchar> | <special> | <pair> ) '"'
| "#" <hex>
<special> ::= "," | "=" | <CR> | "+" | "<" | ">"
| "#" | ";"
<pair> ::= "\" ( <special> | "\" | '"')
<stringchar> ::= any character except <special> or "\" or '"'
<hex> ::= 2*<hexchar>
<hexchar> ::= 0-9, a-f, A-F
Figure 1: BNF Grammar for Distinguished Name
Kille [Page 5]
RFC 1779 DN Representation March 1995
Key Attribute (X.520 keys)
------------------------------
CN CommonName
L LocalityName
ST StateOrProvinceName
O OrganizationName
OU OrganizationalUnitName
C CountryName
STREET StreetAddress
Table 1: Standardised Keywords
Only string type attributes are considered, but other attribute
syntaxes could be supported locally (e.g., by use of the syntexes
defined in [3].) It is assumed that the interface will translate
from the supplied string into an appropriate Directory String
encoding. The "+" notation is used to specify multi-component RDNs.
In this case, the types for attributes in the RDN must be explicit.
The name is presented/input in a little-endian order (most
significant component last). When an address is written in a context
where there is a need to delimit the entire address (e.g., in free
text), it is recommended that the delimiters <> are used. The
terminator > is a special in the notation to facilitate this
delimitation.
3. Examples
This section gives a few examples of distinguished names written
using this notation:
CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
ST=California, C=US
CN=FTAM Service, CN=Bells, OU=Computer Science,
O=University College London, C=GB
CN=Markus Kuhn, O=University of Erlangen, C=DE
CN=Steve Kille,
O=ISODE Consortium,
C=GB
Kille [Page 6]
RFC 1779 DN Representation March 1995
CN=Steve Kille ,
O = ISODE Consortium,
C=GB
CN=Steve Kille, O=ISODE Consortium, C=GB
4. Acknowledgements
This work was based on research work done at University College
London [4], and evolved by the IETF OSI-DS WG.
Input for this version of the document was received from: Allan
Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone
(Onsett); John Hawthorne (US Air Force); Roland Hedberg (University
of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn
(University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE
Consortium).
5. References
[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
[2] Crocker, D., "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, Performance Systems International,
University of Michigan, ISODE Consortium, March 1995.
[4] S.E. Kille. Using the OSI directory to achieve user friendly
naming. Research Note RN/20/29, Department of Computer Science,
University College London, February 1990.
[5] Kille, S., "Using the OSI Directory to Achieve User Friendly
Naming", RFC 1781, ISODE Consortium, March 1995.
Kille [Page 7]
RFC 1779 DN Representation March 1995
6. Security Considerations
Security issues are not discussed in this memo.
7. Author's Address
Steve Kille
ISODE Consortium
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille,
ISODE Consortium, GB
Kille [Page 8]

1459
doc/rfc/rfc1781.txt
View file

File diff suppressed because it is too large Load diff

171
doc/rfc/rfc1960.txt
View file

@ -1,171 +0,0 @@
Network Working Group T. Howes
Request for Comments: 1960 University of Michigan
Obsoletes: 1558 June 1996
Category: Standards Track
A String Representation of LDAP Search Filters
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.
1. Abstract
The Lightweight Directory Access Protocol (LDAP) [1] defines a
network representation of a search filter transmitted to an LDAP
server. Some applications may find it useful to have a common way of
representing these search filters in a human-readable form. This
document defines a human-readable string format for representing LDAP
search filters.
2. LDAP Search Filter Definition
An LDAP search filter is defined in [1] as follows:
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion
}
SubstringFilter ::= SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
Howes Standards Track [Page 1]
RFC 1960 LDAP Search Filters June 1996
AttributeValueAssertion ::= SEQUENCE {
attributeType AttributeType,
attributeValue AttributeValue
}
AttributeType ::= LDAPString
AttributeValue ::= OCTET STRING
LDAPString ::= OCTET STRING
where the LDAPString above is limited to the IA5 character set. The
AttributeType is a string representation of the attribute type name
and is defined in [1]. The AttributeValue OCTET STRING has the form
defined in [2]. The Filter is encoded for transmission over a
network using the Basic Encoding Rules defined in [3], with
simplifications described in [1].
3. String Search Filter Definition
The string representation of an LDAP search filter is defined by the
following grammar. It uses a prefix format.
<filter> ::= '(' <filtercomp> ')'
<filtercomp> ::= <and> | <or> | <not> | <item>
<and> ::= '&' <filterlist>
<or> ::= '|' <filterlist>
<not> ::= '!' <filter>
<filterlist> ::= <filter> | <filter> <filterlist>
<item> ::= <simple> | <present> | <substring>
<simple> ::= <attr> <filtertype> <value>
<filtertype> ::= <equal> | <approx> | <greater> | <less>
<equal> ::= '='
<approx> ::= '~='
<greater> ::= '>='
<less> ::= '<='
<present> ::= <attr> '=*'
<substring> ::= <attr> '=' <initial> <any> <final>
<initial> ::= NULL | <value>
<any> ::= '*' <starval>
<starval> ::= NULL | <value> '*' <starval>
<final> ::= NULL | <value>
<attr> is a string representing an AttributeType, and has the format
defined in [1]. <value> is a string representing an AttributeValue,
or part of one, and has the form defined in [2]. If a <value> must
contain one of the characters '*' or '(' or ')', these characters
should be escaped by preceding them with the backslash '\' character.
Howes Standards Track [Page 2]
RFC 1960 LDAP Search Filters June 1996
Note that although both the <substring> and <present> productions can
produce the 'attr=*' construct, this construct is used only to denote
a presence filter.
4. Examples
This section gives a few examples of search filters written using
this notation.
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
5. Security Considerations
Security considerations are not discussed in this memo.
6. Bibliography
[1] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
[2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String
Representation of Standard Attribute Syntaxes", RFC 1778,
March 1995.
[3] Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1). CCITT Recommendation X.209, 1988.
7. Author's Address
Tim Howes
University of Michigan
ITD Research Systems
535 W William St.
Ann Arbor, MI 48103-4943
USA
Phone: +1 313 747-4454
EMail: tim@umich.edu
Howes Standards Track [Page 3]

731
doc/rfc/rfc2559.txt
View file

@ -1,731 +0,0 @@
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]