rfc4514.txt

samba最新软件


RFC 4514               LDAP: Distinguished Names               June 2006


         %x3D / %x3F-5B / %x5D-7F

      stringchar = SUTF1 / UTFMB
      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

      pair = ESC ( ESC / special / hexpair )
      special = escaped / SPACE / SHARP / EQUALS
      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
      hexstring = SHARP 1*hexpair
      hexpair = HEX HEX

   where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
   <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
   <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].

   Each <attributeType>, either a <descr> or a <numericoid>, refers to
   an attribute type of an attribute value assertion (AVA).  The
   <attributeType> is followed by an <EQUALS> and an <attributeValue>.
   The <attributeValue> is either in <string> or <hexstring> form.

   If in <string> form, a LDAP string representation asserted value can
   be obtained by replacing (left to right, non-recursively) each <pair>
   appearing in the <string> as follows:

      replace <ESC><ESC> with <ESC>;
      replace <ESC><special> with <special>;
      replace <ESC><hexpair> with the octet indicated by the <hexpair>.

   If in <hexstring> form, a BER representation can be obtained from
   converting each <hexpair> of the <hexstring> to the octet indicated
   by the <hexpair>.

   There is one or more attribute value assertions, separated by <PLUS>,
   for a relative distinguished name.

   There is zero or more relative distinguished names, separated by
   <COMMA>, for a distinguished name.

   Implementations MUST recognize AttributeType name strings
   (descriptors) listed in the following table, but MAY recognize other
   name strings.









Zeilenga                    Standards Track                     [Page 6]

RFC 4514               LDAP: Distinguished Names               June 2006


      String  X.500 AttributeType
      ------  --------------------------------------------
      CN      commonName (2.5.4.3)
      L       localityName (2.5.4.7)
      ST      stateOrProvinceName (2.5.4.8)
      O       organizationName (2.5.4.10)
      OU      organizationalUnitName (2.5.4.11)
      C       countryName (2.5.4.6)
      STREET  streetAddress (2.5.4.9)
      DC      domainComponent (0.9.2342.19200300.100.1.25)
      UID     userId (0.9.2342.19200300.100.1.1)

   These attribute types are described in [RFC4519].

   Implementations MAY recognize other DN string representations.
   However, as there is no requirement that alternative DN string
   representations be recognized (and, if so, how), implementations
   SHOULD only generate DN strings in accordance with Section 2 of this
   document.

4.  Examples

   This notation is designed to be convenient for common forms of name.
   This section gives a few examples of distinguished names written
   using this notation.  First is a name containing three relative
   distinguished names (RDNs):

      UID=jsmith,DC=example,DC=net

   Here is an example of a name containing three RDNs, in which the
   first RDN is multi-valued:

      OU=Sales+CN=J.  Smith,DC=example,DC=net

   This example shows the method of escaping of a special characters
   appearing in a common name:

      CN=James \"Jim\" Smith\, III,DC=example,DC=net

   The following shows the method for encoding a value that contains a
   carriage return character:

      CN=Before\0dAfter,DC=example,DC=net

   In this RDN example, the type in the RDN is unrecognized, and the
   value is the BER encoding of an OCTET STRING containing two octets,
   0x48 and 0x69.




Zeilenga                    Standards Track                     [Page 7]

RFC 4514               LDAP: Distinguished Names               June 2006


      1.3.6.1.4.1.1466.0=#04024869

   Finally, this example shows an RDN whose commonName value consists of
   5 letters:

      Unicode Character                Code       UTF-8   Escaped
      -------------------------------  ------     ------  --------
      LATIN CAPITAL LETTER L           U+004C     0x4C    L
      LATIN SMALL LETTER U             U+0075     0x75    u
      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
      LATIN SMALL LETTER I             U+0069     0x69    i
      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87

   This could be encoded in printable ASCII [ASCII] (useful for
   debugging purposes) as:

      CN=Lu\C4\8Di\C4\87

5.  Security Considerations

   The following security considerations are specific to the handling of
   distinguished names.  LDAP security considerations are discussed in
   [RFC4511] and other documents comprising the LDAP Technical
   Specification [RFC4510].

5.1.  Disclosure

   Distinguished Names typically consist of descriptive information
   about the entries they name, which can be people, organizations,
   devices, or other real-world objects.  This frequently includes some
   of the following kinds of information:

      - the common name of the object (i.e., a person's full name)
      - an email or TCP/IP address
      - its physical location (country, locality, city, street address)
      - organizational attributes (such as department name or
        affiliation)

   In some cases, such information can be considered sensitive.  In many
   countries, privacy laws exist that prohibit disclosure of certain
   kinds of descriptive information (e.g., email addresses).  Hence,
   server implementers are encouraged to support Directory Information
   Tree (DIT) structural rules and name forms [RFC4512], as these
   provide a mechanism for administrators to select appropriate naming
   attributes for entries.  Administrators are encouraged to use
   mechanisms, access controls, and other administrative controls that
   may be available to restrict use of attributes containing sensitive
   information in naming of entries.   Additionally, use of



Zeilenga                    Standards Track                     [Page 8]

RFC 4514               LDAP: Distinguished Names               June 2006


   authentication and data security services in LDAP [RFC4513][RFC4511]
   should be considered.

5.2.  Use of Distinguished Names in Security Applications

   The transformations of an AttributeValue value from its X.501 form to
   an LDAP string representation are not always reversible back to the
   same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
   form.  An example of a situation that requires the 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 TeletexString
   choice with the letters 'Sam', would be represented in LDAP as the
   string <CN=Sam>.  Another distinguished name in which the value is
   still 'Sam', but is of the PrintableString choice, would have the
   same representation <CN=Sam>.

   Applications that require the reconstruction of the DER form of the
   value SHOULD NOT use the string representation of attribute syntaxes
   when converting a distinguished name to the LDAP format.  Instead,
   they SHOULD use the hexadecimal form prefixed by the number sign ('#'
   U+0023) as described in the first paragraph of Section 2.4.

6.  Acknowledgements

   This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
   Steve Kille.  RFC 2253 was a product of the IETF ASID Working Group.

   This document is a product of the IETF LDAPBIS Working Group.

7.  References

7.1.  Normative References

   [REGISTRY]    IANA, Object Identifier Descriptors Registry,
                 <http://www.iana.org/assignments/ldap-parameters>.

   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
                 3.2.0" is defined by "The Unicode Standard, Version
                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
                 61633-5), as amended by the "Unicode Standard Annex
                 #27: Unicode 3.1"
                 (http://www.unicode.org/reports/tr27/) and by the
                 "Unicode Standard Annex #28: Unicode 3.2"
                 (http://www.unicode.org/reports/tr28/).





Zeilenga                    Standards Track                     [Page 9]

RFC 4514               LDAP: Distinguished Names               June 2006


   [X.501]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
                 2:1994).

   [X.680]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "Abstract
                 Syntax Notation One (ASN.1) - Specification of Basic
                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", RFC 4234, October 2005.

   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Technical Specification Road Map", RFC
                 4510, June 2006.

   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
                 (LDAP): Directory Information Models", RFC 4512, June
                 2006.

   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Authentication Methods and Security
                 Mechanisms", RFC 4513, June 2006.

   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
                 2006.

   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Schema for User Applications", RFC
                 4519, June 2006.

   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
                 (IANA) Considerations for the Lightweight Directory
                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.






Zeilenga                    Standards Track                    [Page 10]

RFC 4514               LDAP: Distinguished Names               June 2006