7 Network Working Group S. Kille
8 Request for Comments: 1779 ISODE Consortium
9 Obsoletes: 1485 March 1995
10 Category: Standards Track
13 A String Representation of Distinguished Names
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 The OSI Directory uses distinguished names as the primary keys to
26 entries in the directory. Distinguished Names are encoded in ASN.1.
27 When a distinguished name is communicated between to users not using
28 a directory protocol (e.g., in a mail message), there is a need to
29 have a user-oriented string representation of distinguished name.
30 This specification defines a string format for representing names,
31 which is designed to give a clean representation of commonly used
32 names, whilst being able to represent any distinguished name.
36 1. Why a notation is needed ................................... 2
37 2. A notation for Distinguished Name .......................... 2
38 2.1 Goals ................................................ 2
39 2.2 Informal definition .................................. 2
40 2.3 Formal definition .................................... 4
41 3. Examples ................................................... 6
42 4. Acknowledgements ........................................... 7
43 5. References ................................................. 7
44 6. Security Considerations .................................... 8
45 7. Author's Address ........................................... 8
60 RFC 1779 DN Representation March 1995
63 1. Why a notation is needed
65 Many OSI Applications make use of Distinguished Names (DN) as defined
66 in the OSI Directory, commonly known as X.500 [1]. This
67 specification assumes familiarity with X.500, and the concept of
68 Distinguished Name. It is important to have a common format to be
69 able to unambiguously represent a distinguished name. This might be
70 done to represent a directory name on a business card or in an email
71 message. There is a need for a format to support human to human
72 communication, which must be string based (not ASN.1) and user
73 oriented. This notation is targeted towards a general user oriented
74 system, and in particular to represent the names of humans. Other
75 syntaxes may be more appropriate for other uses of the directory.
76 For example, the OSF Syntax may be more appropriate for some system
77 oriented uses. (The OSF Syntax uses "/" as a separator, and forms
78 names in a manner intended to resemble UNIX filenames).
80 2. A notation for Distinguished Name
84 The following goals are laid out:
86 o To provide an unambiguous representation of a distinguished name
88 o To be an intuitive format for the majority of names
90 o To be fully general, and able to represent any distinguished name
92 o To be amenable to a number of different layouts to achieve an
93 attractive representation.
95 o To give a clear representation of the contents of the
98 2.2 Informal definition
100 This notation is designed to be convenient for common forms of name.
101 Some examples are given. The author's directory distinguished name
105 O=ISODE Consortium, C=GB
116 RFC 1779 DN Representation March 1995
119 This may be folded, perhaps to display in multi-column format. For
126 Another name might be:
128 CN=Christian Huitema, O=INRIA, C=FR
130 Semicolon (";") may be used as an alternate separator. The
131 separators may be mixed, but this usage is discouraged.
133 CN=Christian Huitema; O=INRIA; C=FR
135 In running text, this would be written as <CN=Christian Huitema;
136 O=INRIA; C=FR>. Another example, shows how different attribute types
144 Here is an example of a multi-valued Relative Distinguished Name,
145 where the namespace is flat within an organisation, and department is
146 used to disambiguate certain names:
148 OU=Sales + CN=J. Smith, O=Widget Inc., C=US
150 The final examples show both methods quoting of a comma in an
153 CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
155 CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
172 RFC 1779 DN Representation March 1995
175 2.3 Formal definition
177 A formal definition can now be given. The structure is specified in
178 a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC
179 822, with the terminals enclosed in <> [2]. This definition is in an
180 abstract character set, and so may be written in any character set
181 supporting the explicitly defined special characters. The quoting
182 mechanism is used for the following cases:
184 o Strings containing ",", "+", "=" or """ , <CR>, "<",
187 o Strings with leading or trailing spaces
189 o Strings containing consecutive spaces
191 There is an escape mechanism from the normal user oriented form, so
192 that this syntax may be used to print any valid distinguished name.
193 This is ugly. It is expected to be used only in pathological cases.
194 There are two parts to this mechanism:
196 1. Attributes types are represented in a (big-endian) dotted
197 notation. (e.g., OID.2.6.53).
199 2. Attribute values are represented in hexadecimal (e.g. #0A56CF).
200 Each pair of hex digits defines an octet, which is the ASN.1 Basic
201 Encoding Rules value of the Attribute Value.
203 The keyword specification is optional in the BNF, but mandatory for
204 this specification. This is so that the same BNF may be used for the
205 related specification on User Friendly Naming [5]. When this
206 specification is followed, the attribute type keywords must always be
209 A list of valid keywords for well known attribute types used in
210 naming is given in Table 1. Keywords may contain spaces, but shall
211 not have leading or trailing spaces. This is a list of keywords
212 which must be supported. These are chosen because they appear in
213 common forms of name, and can do so in a place which does not
214 correspond to the default schema used. A register of valid keywords
215 is maintained by the IANA.
228 RFC 1779 DN Representation March 1995
231 <name> ::= <name-component> ( <spaced-separator> )
232 | <name-component> <spaced-separator> <name>
234 <spaced-separator> ::= <optional-space>
238 <separator> ::= "," | ";"
240 <optional-space> ::= ( <CR> ) *( " " )
242 <name-component> ::= <attribute>
243 | <attribute> <optional-space> "+"
244 <optional-space> <name-component>
246 <attribute> ::= <string>
247 | <key> <optional-space> "=" <optional-space> <string>
249 <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
250 <keychar> ::= letters, numbers, and space
252 <oid> ::= <digitstring> | <digitstring> "." <oid>
253 <digitstring> ::= 1*<digit>
254 <digit> ::= digits 0-9
256 <string> ::= *( <stringchar> | <pair> )
257 | '"' *( <stringchar> | <special> | <pair> ) '"'
261 <special> ::= "," | "=" | <CR> | "+" | "<" | ">"
264 <pair> ::= "\" ( <special> | "\" | '"')
265 <stringchar> ::= any character except <special> or "\" or '"'
268 <hex> ::= 2*<hexchar>
269 <hexchar> ::= 0-9, a-f, A-F
273 Figure 1: BNF Grammar for Distinguished Name
284 RFC 1779 DN Representation March 1995
287 Key Attribute (X.520 keys)
288 ------------------------------
291 ST StateOrProvinceName
293 OU OrganizationalUnitName
298 Table 1: Standardised Keywords
301 Only string type attributes are considered, but other attribute
302 syntaxes could be supported locally (e.g., by use of the syntexes
303 defined in [3].) It is assumed that the interface will translate
304 from the supplied string into an appropriate Directory String
305 encoding. The "+" notation is used to specify multi-component RDNs.
306 In this case, the types for attributes in the RDN must be explicit.
308 The name is presented/input in a little-endian order (most
309 significant component last). When an address is written in a context
310 where there is a need to delimit the entire address (e.g., in free
311 text), it is recommended that the delimiters <> are used. The
312 terminator > is a special in the notation to facilitate this
317 This section gives a few examples of distinguished names written
320 CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
323 CN=FTAM Service, CN=Bells, OU=Computer Science,
324 O=University College London, C=GB
326 CN=Markus Kuhn, O=University of Erlangen, C=DE
340 RFC 1779 DN Representation March 1995
345 O = ISODE Consortium,
348 CN=Steve Kille, O=ISODE Consortium, C=GB
352 This work was based on research work done at University College
353 London [4], and evolved by the IETF OSI-DS WG.
355 Input for this version of the document was received from: Allan
356 Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone
357 (Onsett); John Hawthorne (US Air Force); Roland Hedberg (University
358 of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn
359 (University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE
364 [1] The Directory --- overview of concepts, models and services,
365 1993. CCITT X.500 Series Recommendations.
367 [2] Crocker, D., "Standard of the Format of ARPA-Internet Text
368 Messages", STD 11, RFC 822, University of Delaware, August 1982.
370 [3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
371 Protocol", RFC 1777, Performance Systems International,
372 University of Michigan, ISODE Consortium, March 1995.
374 [4] S.E. Kille. Using the OSI directory to achieve user friendly
375 naming. Research Note RN/20/29, Department of Computer Science,
376 University College London, February 1990.
378 [5] Kille, S., "Using the OSI Directory to Achieve User Friendly
379 Naming", RFC 1781, ISODE Consortium, March 1995.
396 RFC 1779 DN Representation March 1995
399 6. Security Considerations
401 Security issues are not discussed in this memo.
413 Phone: +44-181-332-9091
414 EMail: S.Kille@ISODE.COM
417 O=ISODE Consortium, C=GB