RFC 1485

RFC 1485: A String Representation of Distinguished Names (OSI-DS 23 (v5)) 💖

Okay bestie, here's the vibe check 🎀. This is Request for Comments 1485 from the Network Working Group, dated July 1993. The author is S. Hardcastle-Kille of the ISODE Consortium, and the category is an IAB standards track protocol. The title block doesn't list anything it obsoletes or updates. ✨

---

Status of this Memo ✨

This RFC is an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🙌. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚. Distribution of this memo is unlimited 🦋.

Abstract 🌸

The OSI Directory uses distinguished names as the primary keys to entries in the directory 🔑. Those names are encoded in ASN.1 🫠. When a distinguished name gets passed between users who aren't using a directory protocol (like in a mail message), you need a string version that people can actually read ✉️. This spec defines that string format. It's built to make common names look clean, and it can still represent any distinguished name 💅. Send comments to the author or to the discussion group <osi-ds@CS.UCL.AC.UK> 💌.

Table of Contents 📋

   1.  Why a notation is needed...................................... 1
   2.  A notation for Distinguished Name............................. 2
   2.1 Goals......................................................... 2
   2.2 Informal definition........................................... 2
   2.3 Formal definition............................................. 3
   3.  Examples...................................................... 6
   4.  References.................................................... 6
   5.  Security Considerations....................................... 6
   6.  Author's Address.............................................. 7

1. Why a notation is needed 🧚

Lots of OSI applications use Distinguished Names (DN) from the OSI Directory, which is commonly known as X.500 [CCI88]. This spec assumes you already know X.500 and what a Distinguished Name is 🤓. It's important to have a common format so a distinguished name can be represented unambiguously. That might happen on a business card or in an email message. We need a format that's string-based (not ASN.1) and user-oriented so humans can talk to humans 🫶. This notation is aimed at general, user-oriented systems, especially for naming people. Other syntaxes may be more appropriate for other directory uses. For example, the OSF Syntax may suit some system-oriented uses better. (The OSF Syntax uses "/" as a separator, and forms names in a way meant to look like UNIX filenames 🗂️.)

2. A notation for Distinguished Name 💜

2.1 Goals 🎯

The following goals are laid out:

• To provide an unambiguous representation of a distinguished name
• To be an intuitive format for the majority of names
• To be fully general, and able to represent any distinguished name
• To be amenable to a number of different layouts to achieve an attractive representation
• 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. Here are some examples. The author's directory distinguished name would be written:

   CN=Steve Hardcastle-Kille, OU=Computer Science, O=University
   College London, C=GB

It can be folded, perhaps to display in multi-column format. For example:

   CN=Steve Hardcastle-Kille,
   OU=Computer Science,
   O=University College London,
   C=GB

Another name might be:

   CN=Christian Huitema, O=INRIA, C=FR

Semicolon (";") may be used as an alternate separator:

   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,
   CN=GB

Here's 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 example shows quoting of a comma in an Organisation name:

   CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB

2.3 Formal definition 🧪

Now we can give the formal definition. 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 <> [Cro82]. The definition is in an abstract character set, so it can be written in any character set that supports the explicitly defined special characters. The quoting mechanism is used for the following cases:

• Strings containing ",", "+", "=", """, <CR>, "<", ">", "#", or ";".
• Strings with leading or trailing spaces
• Strings containing consecutive spaces

There's an escape mechanism from the normal user-oriented form, so this syntax can be used to print any valid distinguished name. This is ugly 😬. It's expected to be used only in pathological cases. It has two parts:

1. Attribute 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).

The keyword specification is optional in the BNF, but mandatory for this specification. That's so the same BNF can be used for the related User Friendly Naming specification [HK93]. 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. This is a list of keywords which must be supported. These were chosen because they appear in common forms of name, and can appear in a place that doesn't match the default schema used. A register of valid keywords is maintained by the IANA 🗒️.

   <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>
   <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> ::= "
   <stringchar> ::= any char except <special> or "

   <hex> ::= 2*<hexchar>
   <hexchar> ::= 0-9, a-f, A-F

               Figure 1:  BNF Grammar for Distinguished Name

                        Key  Attribute (X.520 keys)
                        ______________________________
                        CN   CommonName
                        L    LocalityName
                        ST   StateOrProvinceName
                        O    OrganizationName
                        OU   OrganizationalUnitName
                        C    CountryName

                      Table 1:  Standardised Keywords

Only string type attributes are considered, but other attribute syntaxes could be supported locally. It is assumed that the interface will translate from the supplied string into PrintableString or T.61 🔄.

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 it needs to be delimited as a whole (e.g., in free text), it is recommended that the delimiters <> are used. The terminator > is a special in the notation to make that delimitation easier 🫧.

---

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=Steve Hardcastle-Kille, OU=Computer Science, O=University
   College London, C=GB

   CN=Steve Hardcastle-Kille, OU=Computer Science, O=University
   College London, C=GB

4. References 📚

   [CCI88] The Directory --- overview of concepts, models and services,
           December 1988. CCITT X.500 Series Recommendations.

   [Cro82] D.H. Crocker. Standard of the format of ARPA internet text
           messages.  STD 11, RFC 822, University of Delaware,
           August 1982.

   [HK93]  S.E. Hardcastle-Kille. Using the OSI directory to achieve
           user friendly naming.  RFC 1484, Department of Computer
           Science, University College London, July 1993.

5. Security Considerations 😱

Security issues are not discussed in this memo. Zero security discussion, bestie 💀. Plan accordingly and don't assume anything the spec doesn't say 🔒.

6. Author's Address 📮

   Steve Hardcastle-Kille
   ISODE Consortium
   P.O. Box 505
   London
   SW11 1DX
   England

   Phone:+44-71-223-4062
   EMail:  S.Kille@ISODE.COM

   DN: CN=Steve Hardcastle-Kille,
   O=ISODE Consortium, C=GB

   UFN: S. Hardcastle-Kille,
   ISODE Consortium, GB