rfc2377.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   will require the auxiliary class uidObject to permit the uid
   attribute to be used. In the cases where organizationalUnit or
   organization is the base class for a CA, use of the auxiliary class
   dcObject will permit the RDN of the CA to be a domain component.

5.2.5 Server and Server Application Schema

   Servers and server applications are typically represented, for want
   of anything better, by entries of the object class applicationProcess
   (or a class derived from it).  Sometimes the class applicationEntity
   is used.  In either case, the uid attribute should probably not be
   employed to construct the RDN of a server or server application
   object.  The standard schema uses the attribute cn for such RDNs.

   Suppose one wants to use this naming plan both in the construction of
   DNs for SSL server certificates and for their storage in a directory.
   It is customary for clients connecting via SSL to compare the
   server's domain name (e.g. from the URL used to contact the server)
   with the value of the cn attribute in the subject field (i.e.
   subject's DN) of the server's certificate. For this reason, it is
   common practice to set the cn attribute to the server's domain name.

   The naming and schema to handle this situation is best explained by
   an example. Consider the server "host.acme.com". Following the
   algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
   dc=host, dc=acme, dc=com is constructed. To conform to the existing
   practices just described, the server's subject DN for the SSL server
   certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
   the server's certificate should be stored in a directory entry with
   this name. This entry should use application process or application
   entity as its structural object class and strong authentication user
   as is auxiliary class.

5.2.6 Name Forms

   For X.500 servers or LDAP servers following the X.500 model, our
   schema requires the definition of new name forms, structure rules,
   and DIT content rules.  Structure rules and DIT content rules are
   locally defined, and do not involve a globally significant object
   identifier.

   The following name forms are defined using the syntax of section 6.22
   of [14] for the convenience of those using such servers.

   Note that since the structural object classes organization,
   organizationalUnit, locality and organizationalPerson do not permit
   inclusion of the dc attribute, an auxiliary object class such as
   dcObject [1] must be used for instances of these classes.)



Grimstad, et. al.            Informational                     [Page 13]

RFC 2377                A Directory Naming Plan           September 1998


5.2.6.1 Name Form for Domain Objects

   The OIDs in this group are under the
   iso.org.dod.internet.directory.NameForm branch of the OID tree
   (1.3.6.1.1.2).

   ( 1.3.6.1.1.2.1
     NAME domainNameForm
     OC domain
     MUST dc )

   The domainNameForm name form indicates that objects of structural
   object class domain have their RDN constructed from a value of the
   attribute dc.

5.2.6.2 Name Form for Organization Objects

   ( 1.3.6.1.1.2.2
     NAME dcOrganizationNameForm
     OC organization
     MUST dc )

   The dcOrganizationNameForm name form indicates that objects of
   structural object class organization have their RDN constructed from
   a value of the attribute dc.

5.2.6.3 Name Form for Organizational Unit Objects

   ( 1.3.6.1.1.2.3
     NAME dcOrganizationalUnitNameForm
     OC organizationalUnit
     MUST dc )

   The dcOrganizationalUnitNameForm name form indicates that objects of
   structural object class organizationalUnit have their RDN constructed
   from a value of the attribute dc.

5.2.6.4 Name Form for Locality Objects

   ( 1.3.6.1.1.2.4
     NAME dcLocalityNameForm
     OC locality
     MUST dc )

   The dcLocalityNameForm name form indicates that objects of structural
   object class locality have their RDN constructed from a value of the
   attribute dc.




Grimstad, et. al.            Informational                     [Page 14]

RFC 2377                A Directory Naming Plan           September 1998


5.2.6.5 Name Form for Organizational Person Objects

   ( 1.3.6.1.1.2.5
     NAME uidOrganizationalPersonNameForm
     OC organizationalPerson
     MUST uid )

   The uidOrganizationalPersonNameForm name form indicates that objects
   of structural object class organizationalPerson have their RDN
   constructed from a value of the attribute uid.

6.0 Security Considerations

   Although access controls may be placed on portions of the DIT to deny
   browse access to unauthorized clients, it may be possible to infer
   directory names and DIT structure in such sensitive portions of the
   DIT from the results of DNS queries. Providing public visibility to
   some portions of the DIT may assist those make such inferences.

7.0 Acknowledgments

   This plan has emerged in the course of a number of fruitful
   discussions, especially with David Chadwick, John Dale, Joe Gajewski,
   Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.

8.0 References

   [1]     Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
           Sataluri, "Using Domains in LDAP Distinguished Names", RFC
           2247, January 1998.

   [2]     X.500: The Directory -- Overview of Concepts, Models, and
           Service, CCITT Recommendation X.500, December, 1988.

   [3]     Barker, P., and S. Kille, "The COSINE and Internet X.500
           Schema", RFC 1274, November 1991.

   [4]     The North American Directory Forum, "A Naming Scheme for
           c=US", RFC 1255, September 1991.

   [5]     The North American Directory Forum, "NADF Standing Documents:
           A Brief Overview", RFC 1417, February 1993.

   [6]     Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
           Access Protocol", RFC 1777, March 1995.

   [7]     Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
           Access Protocol (v3)", RFC 2251, December 1997.



Grimstad, et. al.            Informational                     [Page 15]

RFC 2377                A Directory Naming Plan           September 1998


   [8]     Kille, S., "A String Representation of Distinguished Names",
           RFC 1779, March 1995.

   [9]     Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
           Access Protocol (v3): UTF-8 String Representation of
           Distinguished Names", RFC 2253, December 1997.

   [10]    Wahl, M., "A Summary of the Pilot X.500 Schema for use
           in LDAPv3", Work in Progress.

   [11]    Wahl, M., "A Summary of the X.500 User Schema for use with
           LDAPv3", RFC 2256, December 1997.

   [12]    Howes, T., and M. Wahl, "Referrals and Knowledge References
           in LDAP Directories", Work in Progress.

   [13]    Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
           December 1997.

   [14]    Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
           "Lightweight Directory Access Protocol (v3): Attribute Syntax
           Definitions", RFC 2252, December 1997.

   [15]    Smith, M., "Definition of the inetOrgPerson Object Class",
           Work in Progress.


























Grimstad, et. al.            Informational                     [Page 16]

RFC 2377                A Directory Naming Plan           September 1998


12.  Authors' Addresses

   Al Grimstad
   AT&T
   Room 1C-429, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail:  [e-mail]


   Rick Huber
   AT&T
   Room 1B-433, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail:  [e-mail]


   Sri Sataluri
   Lucent Technologies
   Room 4D-335, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail:  [e-mail]


   Mark Wahl
   Critical Angle Inc.
   4815 W Braker Lane #502-385
   Austin, TX 78759
   USA

   EMail:  [e-mail]















Grimstad, et. al.            Informational                     [Page 17]

RFC 2377                A Directory Naming Plan           September 1998


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Grimstad, et. al.            Informational                     [Page 18]