git.sur5r.net Git - openldap/blob - doc/rfc/rfc1779.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           S. Kille
   8 Request for Comments: 1779                              ISODE Consortium
   9 Obsoletes: 1485                                               March 1995
  10 Category: Standards Track
  11
  12
  13              A String Representation of Distinguished Names
  14
  15 Status of this Memo
  16
  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.
  22
  23 Abstract
  24
  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.
  33
  34 Table of Contents
  35
  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
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Kille                                                           [Page 1]
  59 \f
  60 RFC 1779                   DN Representation                  March 1995
  61
  62
  63 1.  Why a notation is needed
  64
  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).
  79
  80 2.  A notation for Distinguished Name
  81
  82 2.1  Goals
  83
  84    The following goals are laid out:
  85
  86     o  To provide an unambiguous representation of a distinguished name
  87
  88     o  To be an intuitive format for the majority of names
  89
  90     o  To be fully general, and able to represent any distinguished name
  91
  92     o  To be amenable to a number of different layouts to achieve an
  93        attractive representation.
  94
  95     o  To give a clear representation of the contents of the
  96        distinguished name
  97
  98 2.2  Informal definition
  99
 100    This notation is designed to be convenient for common forms of name.
 101    Some examples are given.  The author's directory distinguished name
 102    would be written:
 103
 104    CN=Steve Kille,
 105    O=ISODE Consortium, C=GB
 106
 107
 108
 109
 110
 111
 112
 113
 114 Kille                                                           [Page 2]
 115 \f
 116 RFC 1779                   DN Representation                  March 1995
 117
 118
 119    This may be folded, perhaps to display in multi-column format.  For
 120    example:
 121
 122    CN=Steve Kille,
 123    O=ISODE Consortium,
 124    C=GB
 125
 126    Another name might be:
 127
 128    CN=Christian Huitema, O=INRIA, C=FR
 129
 130    Semicolon (";") may be used as an alternate separator.  The
 131    separators may be mixed, but this usage is discouraged.
 132
 133    CN=Christian Huitema; O=INRIA; C=FR
 134
 135    In running text, this would be written as <CN=Christian Huitema;
 136    O=INRIA; C=FR>.  Another example, shows how different attribute types
 137    are handled:
 138
 139    CN=James Hacker,
 140    L=Basingstoke,
 141    O=Widget Inc,
 142    C=GB
 143
 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:
 147
 148    OU=Sales + CN=J. Smith, O=Widget Inc., C=US
 149
 150    The final examples show both methods quoting of a comma in an
 151    Organisation name:
 152
 153    CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
 154
 155    CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Kille                                                           [Page 3]
 171 \f
 172 RFC 1779                   DN Representation                  March 1995
 173
 174
 175 2.3  Formal definition
 176
 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:
 183
 184     o  Strings containing ",", "+", "=" or """ , <CR>, "<",
 185        ">", "#", or ";".
 186
 187     o  Strings with leading or trailing spaces
 188
 189     o  Strings containing consecutive spaces
 190
 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:
 195
 196    1.  Attributes types are represented in a (big-endian) dotted
 197        notation.  (e.g., OID.2.6.53).
 198
 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.
 202
 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
 207    present.
 208
 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.
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Kille                                                           [Page 4]
 227 \f
 228 RFC 1779                   DN Representation                  March 1995
 229
 230
 231    <name> ::= <name-component> ( <spaced-separator> )
 232           | <name-component> <spaced-separator> <name>
 233
 234    <spaced-separator> ::= <optional-space>
 235                    <separator>
 236                    <optional-space>
 237
 238    <separator> ::=  "," | ";"
 239
 240    <optional-space> ::= ( <CR> ) *( " " )
 241
 242    <name-component> ::= <attribute>
 243            | <attribute> <optional-space> "+"
 244              <optional-space> <name-component>
 245
 246    <attribute> ::= <string>
 247            | <key> <optional-space> "=" <optional-space> <string>
 248
 249    <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
 250    <keychar> ::= letters, numbers, and space
 251
 252    <oid> ::= <digitstring> | <digitstring> "." <oid>
 253    <digitstring> ::= 1*<digit>
 254    <digit> ::= digits 0-9
 255
 256    <string> ::= *( <stringchar> | <pair> )
 257             | '"' *( <stringchar> | <special> | <pair> ) '"'
 258             | "#" <hex>
 259
 260
 261    <special> ::= "," | "=" | <CR> | "+" | "<" |  ">"
 262             | "#" | ";"
 263
 264    <pair> ::= "\" ( <special> | "\" | '"')
 265    <stringchar> ::= any character except <special> or "\" or '"'
 266
 267
 268    <hex> ::= 2*<hexchar>
 269    <hexchar> ::= 0-9, a-f, A-F
 270
 271
 272
 273                Figure 1:  BNF Grammar for Distinguished Name
 274
 275
 276
 277
 278
 279
 280
 281
 282 Kille                                                           [Page 5]
 283 \f
 284 RFC 1779                   DN Representation                  March 1995
 285
 286
 287                        Key     Attribute (X.520 keys)
 288                        ------------------------------
 289                        CN      CommonName
 290                        L       LocalityName
 291                        ST      StateOrProvinceName
 292                        O       OrganizationName
 293                        OU      OrganizationalUnitName
 294                        C       CountryName
 295                        STREET  StreetAddress
 296
 297
 298                       Table 1:  Standardised Keywords
 299
 300
 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.
 307
 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
 313    delimitation.
 314
 315 3.  Examples
 316
 317    This section gives a few examples of distinguished names written
 318    using this notation:
 319
 320    CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
 321    ST=California, C=US
 322
 323    CN=FTAM Service, CN=Bells, OU=Computer Science,
 324    O=University College London, C=GB
 325
 326    CN=Markus Kuhn, O=University of Erlangen, C=DE
 327
 328    CN=Steve Kille,
 329    O=ISODE Consortium,
 330    C=GB
 331
 332
 333
 334
 335
 336
 337
 338 Kille                                                           [Page 6]
 339 \f
 340 RFC 1779                   DN Representation                  March 1995
 341
 342
 343    CN=Steve Kille ,
 344
 345    O =   ISODE Consortium,
 346    C=GB
 347
 348    CN=Steve Kille, O=ISODE Consortium, C=GB
 349
 350 4.  Acknowledgements
 351
 352    This work was based on research work done at University College
 353    London [4], and evolved by the IETF OSI-DS WG.
 354
 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
 360    Consortium).
 361
 362 5.  References
 363
 364    [1] The Directory --- overview of concepts, models and services,
 365        1993. CCITT X.500 Series Recommendations.
 366
 367    [2] Crocker, D., "Standard of the Format of ARPA-Internet Text
 368        Messages", STD 11, RFC 822, University of Delaware, August 1982.
 369
 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.
 373
 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.
 377
 378    [5] Kille, S., "Using the OSI Directory to Achieve User Friendly
 379        Naming", RFC 1781, ISODE Consortium, March 1995.
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Kille                                                           [Page 7]
 395 \f
 396 RFC 1779                   DN Representation                  March 1995
 397
 398
 399 6.  Security Considerations
 400
 401    Security issues are not discussed in this memo.
 402
 403 7.  Author's Address
 404
 405    Steve Kille
 406    ISODE Consortium
 407    The Dome
 408    The Square
 409    Richmond, Surrey
 410    TW9 1DT
 411    England
 412
 413    Phone:  +44-181-332-9091
 414    EMail:  S.Kille@ISODE.COM
 415
 416    DN: CN=Steve Kille,
 417    O=ISODE Consortium, C=GB
 418
 419    UFN: S. Kille,
 420    ISODE Consortium, GB
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Kille                                                           [Page 8]
 451 \f
 452
 453
 454