As per Relevance of the word represent, we have this rfc below:
Network Working Group M.
Request for Comments: 2253 Critical Angle Inc
Obsoletes: 1779 S.
Category: Standards Track Isode Ltd
T.
Netscape Communications Corp
December 1997
Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished
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 (1997). All Rights Reserved
IESG
This document describes a directory access protocol that
both read and update access. Update access requires
authentication, but this document does not mandate implementation
any satisfactory authentication mechanisms
In accordance with RFC 2026, section 4.4.1, this specification
being approved by IESG as a Proposed Standard despite
limitation, for the following reasons
a. to encourage implementation and interoperability testing
these protocols (with or without update access) before
are deployed,
b. to encourage deployment and use of these protocols in read-
applications. (e.g. applications where LDAPv3 is used
a query language for directories which are updated by
secure mechanism other than LDAP),
c. to avoid delaying the advancement and deployment of other
standards-track protocols which require the ability to query,
not update, LDAPv3 directory servers
Wahl, et. al. Proposed Standard [Page 1]
RFC 2253 LADPv3 Distinguished Names December 1997
Readers are hereby warned that until mandatory
mechanisms are standardized, clients and servers written according
this specification which make use of update functionality
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL
Implementors are hereby discouraged from deploying LDAPv3 clients
servers which implement the update functionality, until a
Standard for mandatory authentication in LDAPv3 has been approved
published as an RFC
The X.500 Directory uses distinguished names as the primary keys
entries in the directory. Distinguished Names are encoded in ASN.1
in the X.500 Directory protocols. In the Lightweight
Access Protocol, a string representation of distinguished names
transferred. This specification defines the string format
representing names, which is designed to give a clean
of commonly used distinguished names, while being able to
any distinguished name
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [6].
1.
This specification assumes familiarity with X.500 [1], and
concept of Distinguished Name. It is important to have a
format to be able to unambiguously represent a distinguished name
The primary goal of this specification is ease of encoding
decoding. A secondary goal is to have names that are human readable
It is not expected that LDAP clients with a human user
would display these strings directly to the user, but would
likely be performing translations (such as expressing attribute
names in one of the local national languages).
2. Converting DistinguishedName from ASN.1 to a
In X.501 [2] the ASN.1 structure of distinguished name is defined as
DistinguishedName ::=
RDNSequence ::= SEQUENCE OF
Wahl, et. al. Proposed Standard [Page 2]
RFC 2253 LADPv3 Distinguished Names December 1997
RelativeDistinguishedName ::= SET SIZE (1..MAX)
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType
value AttributeValue }
The following sections define the algorithm for converting from
ASN.1 structured representation to a UTF-8 string representation
2.1. Converting the
If the RDNSequence is an empty sequence, the result is the empty
zero length string
Otherwise, the output consists of the string encodings of
RelativeDistinguishedName in the RDNSequence (according to 2.2),
starting with the last element of the sequence and moving
toward the first
The encodings of adjoining RelativeDistinguishedNames are
by a comma character (',' ASCII 44).
2.2. Converting
When converting from an ASN.1 RelativeDistinguishedName to a string
the output consists of the string encodings of
AttributeTypeAndValue (according to 2.3), in any order
Where there is a multi-valued RDN, the outputs from
AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
character
2.3. Converting
The AttributeTypeAndValue is encoded as the string representation
the AttributeType, followed by an equals character ('=' ASCII 61),
followed by the string representation of the AttributeValue.
encoding of the AttributeValue is given in section 2.4.
If the AttributeType is in a published table of attribute
associated with LDAP [4], then the type name string from that
is used, otherwise it is encoded as the dotted-decimal encoding
the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation
described in [3]. As an example, strings for a few of the
types frequently seen in RDNs include
Wahl, et. al. Proposed Standard [Page 3]
RFC 2253 LADPv3 Distinguished Names December 1997
String X.500
------------------------------
CN
L
ST
O
OU
C
STREET
DC
UID
2.4. Converting an AttributeValue from ASN.1 to a
If the AttributeValue is of a type which does not have a
representation defined for it, then it is simply encoded as
octothorpe character ('#' ASCII 35) followed by the
representation of each of the bytes of the BER encoding of the X.500
AttributeValue. This form SHOULD be used if the AttributeType is
the dotted-decimal form
Otherwise, if the AttributeValue is of a type which has a
representation, the value is converted first to a UTF-8
according to its syntax specification (see for example section 6
[4]).
If the UTF-8 string does not have any of the following
which need escaping, then that string can be used as the
representation of the value
o a space or "#" character occurring at the beginning of
o a space character occurring at the end of the
o one of the characters ",", "+", """, "\", "<", ">" or ";"
Implementations MAY escape other characters
If a character to be escaped is one of the list shown above, then
is prefixed by a backslash ('\' ASCII 92).
Otherwise the character to be escaped is replaced by a backslash
two hex digits, which form a single byte in the code of
character
Examples of the escaping mechanism are shown in section 5.
Wahl, et. al. Proposed Standard [Page 4]
RFC 2253 LADPv3 Distinguished Names December 1997
3. Parsing a String back to a Distinguished
The structure of the string is specified in a BNF grammar, based
the grammar defined in RFC 822 [5]. Server implementations parsing
DN string generated by an LDAPv2 client MUST also accept (and ignore
the variants given in section 4 of this document
distinguishedName = [name] ; may be empty
name = name-component *("," name-component
name-component = attributeTypeAndValue *("+" attributeTypeAndValue
attributeTypeAndValue = attributeType "="
attributeType = (ALPHA 1*keychar) /
keychar = ALPHA / DIGIT / "-"
oid = 1*DIGIT *("." 1*DIGIT
attributeValue =
string = *( stringchar / pair )
/ "#"
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v
quotechar = character except "\" or QUOTATION >
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
pair = "\" ( special / "\" / QUOTATION / hexpair )
stringchar = character except one of special, "\" or QUOTATION >
hexstring = 1*
hexpair = hexchar
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F
/ "a" / "b" / "c" / "d" / "e" / "f
ALPHA = character
; (decimal 65-90 and 97-122)
DIGIT = ; (decimal 48-57)
QUOTATION = character '"' decimal 34>
Wahl, et. al. Proposed Standard [Page 5]
RFC 2253 LADPv3 Distinguished Names December 1997
4. Relationship with RFC 1779 and LDAPv
The syntax given in this document is more restrictive than the
in RFC 1779. Implementations parsing a string generated by an LDAPv
client MUST accept the syntax of RFC 1779. Implementations MUST NOT
however, generate any of the RFC 1779 encodings which are
described above in section 2.
Implementations MUST allow a semicolon character to be used
of a comma to separate RDNs in a distinguished name, and MUST
allow whitespace characters to be present on either side of the
or semicolon. The whitespace characters are ignored, and
semicolon replaced with a comma
Implementations MUST allow an oid in the attribute type to
prefixed by one of the character strings "oid." or "OID.".
Implementations MUST allow for space (' ' ASCII 32) characters to
present between name-component and ',', between
and '+', between attributeType and '=', and between '='
attributeValue. These space characters are ignored when parsing
Implementations MUST allow a value to be surrounded by quote ('"'
ASCII 34) characters, which are not part of the value. Inside
quoted value, the following characters can occur without
escaping
",", "=", "+", "<", ">", "#" and ";"
5.
This notation is designed to be convenient for common forms of name
This section gives a few examples of distinguished names
using this notation. First is a name containing three
distinguished names (RDNs):
CN=Steve Kille,O=Isode Limited,C=
Here is an example name containing three RDNs, in which the first
is multi-valued
OU=Sales+CN=J. Smith,O=Widget Inc.,C=
This example shows the method of quoting of a comma in
organization name
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=
Wahl, et. al. Proposed Standard [Page 6]
RFC 2253 LADPv3 Distinguished Names December 1997
An example name in which a value contains a carriage
character
CN=Before\0DAfter,O=Test,C=
An example name in which an RDN was of an unrecognized type.
value is the BER encoding of an OCTET STRING containing two
0x48 and 0x69.
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=
Finally, an example of an RDN surname value consisting of 5 letters
Unicode Letter Description 10646 code UTF-8
=============================== ========== ====== =======
LATIN CAPITAL LETTER L U0000004C 0x4C
LATIN SMALL LETTER U U00000075 0x75
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8
LATIN SMALL LETTER I U00000069 0x69
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
Could be written in printable ASCII (useful for debugging purposes):
SN=Lu\C4\8Di\C4\87
6.
[1] The Directory -- overview of concepts, models and services
ITU-T Rec. X.500(1993).
[2] The Directory -- Models. ITU-T Rec. X.501(1993).
[3] Wahl, M., Howes, T., and S. Kille, "Lightweight
Access Protocol (v3)", RFC 2251, December 1997.
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Crocker, D., "Standard of the Format of ARPA-Internet
Messages", STD 11, RFC 822, August 1982.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119.
Wahl, et. al. Proposed Standard [Page 7]
RFC 2253 LADPv3 Distinguished Names December 1997
7. Security
7.1.
Distinguished Names typically consist of descriptive
about the entries they name, which can be people, organizations
devices or other real-world objects. This frequently includes
of the following kinds of information
- the common name of the object (i.e. a person's full name
- an email or TCP/IP
- its physical location (country, locality, city, street address
- organizational attributes (such as department name or affiliation
Most countries have privacy laws regarding the publication
information about people
7.2. Use of Distinguished Names in Security
The transformations of an AttributeValue value from its X.501 form
an LDAP string representation are not always reversible back to
same BER or DER form. An example of a situation which requires
DER form of a distinguished name is the verification of an X.509
certificate
For example, a distinguished name consisting of one RDN with one AVA
in which the type is commonName and the value is of the
choice with the letters 'Sam' would be represented in LDAP as
string CN=Sam. Another distinguished name in which the value
still 'Sam' but of the PrintableString choice would have the
representation CN=Sam
Applications which require the reconstruction of the DER form of
value SHOULD NOT use the string representation of attribute
when converting a distinguished name to the LDAP format. Instead
they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
as described in the first paragraph of section 2.4.
8. Authors'
Mark
Critical Angle Inc
4815 W. Braker Lane #502-385
Austin, TX 78759
EMail: M.Wahl@critical-angle.
Wahl, et. al. Proposed Standard [Page 8]
RFC 2253 LADPv3 Distinguished Names December 1997
Steve
Isode Ltd
The
The
Richmond,
TW9 1
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.
Tim
Netscape Communications Corp
501 E. Middlefield Rd, MS MV068
Mountain View, CA 94043
Phone: +1 650 937-3419
EMail: howes@netscape.
Wahl, et. al. Proposed Standard [Page 9]
RFC 2253 LADPv3 Distinguished Names December 1997
9. Full Copyright
Copyright (C) The Internet Society (1997). 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
Wahl, et. al. Proposed Standard [Page 10]
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
