view Side-By-Side changes
Network Working Group M. SmithINTERNET-DRAFTRequest for Comments: 2798 Netscape CommunicationsIntendedCategory: Informational22April1999 Expires: 22 October 19992000 Definition of the inetOrgPerson LDAP Object ClassFilename: draft-smith-ldap-inetorgperson-03.txt 1.Status of this Memo Thisdocument is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docu- ments ofmemo provides information for the InternetEngineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft document will be submitted to the RFC Editor asdoes not specify anInforma- tional document.Internet standard of any kind. Distribution of this memo is unlimited.Please send comments to the author <mcs@netscape.com>.Copyright Notice Copyright (C) The Internet Society(1996-1999).(2000). All Rights Reserved.Please see the Copyright section near the end of this document for more information. This Internet Draft expires on 22 October 1999. 2.Abstract While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs.M.SmithNetwork Working GroupInformational [Page 1]INTERNET-DRAFTRFC 2798 The LDAP inetOrgPerson Object Class22April1999 3.2000 Table of Contents 1.Status of this Memo............................................1 2. Abstract.......................................................1 3. Table of Contents..............................................2 4.Background and IntendedUsage..................................3 5.Usage...............................2 2. New Attribute Types Used in the inetOrgPerson ObjectClass.....3 5.1.Class..3 2.1. Vehicle license or registrationplate.......................3 5.2.plate....................3 2.2. Departmentnumber...........................................4 5.3.number........................................3 2.3. DisplayName................................................4 5.4.Name.............................................4 2.4. EmployeeNumber.............................................4 5.5.Number..........................................4 2.5. EmployeeType...............................................4 5.6.Type............................................4 2.6. JPEGPhotograph.............................................5 5.7.Photograph..........................................5 2.7. PreferredLanguage..........................................5 5.8.Language.......................................5 2.8. User S/MIMECertificate.....................................5 5.9.Certificate..................................5 2.9. User PKCS#12...............................................6 6.#12............................................6 3. Definition of the inetOrgPerson ObjectClass...................6 7.Class................6 4. Example of an inetOrgPersonEntry..............................7 8.Entry...........................7 5. SecurityConsiderations........................................8 9. Acknowledgments................................................8 10. Copyright......................................................8 11. Bibliography...................................................9 12.Considerations.....................................8 6. Acknowledgments.............................................8 7. Bibliography................................................8 8. Author'sAddress...............................................10 13.Address............................................9 9. Appendix A - inetOrgPerson SchemaSummary......................10 13.1.Summary..................10 9.1. AttributeTypes.............................................10 13.1.1.Types..........................................10 9.1.1. New attribute types that are defined in thisdocument....10 13.1.2.document.10 9.1.2. Attribute types from RFC2256............................12 13.1.3.2256.........................12 9.1.3. Attribute types from RFC1274............................15 13.1.4.1274.........................15 9.1.4. Attribute type from RFC2079.............................17 13.2. Syntaxes....................................................17 13.2.1.2079..........................16 9.2. Syntaxes.................................................17 9.2.1. Syntaxes from RFC2252...................................17 13.2.2.2252................................17 9.2.2. Syntaxes from RFC2256...................................17 13.3.2256................................17 9.3. MatchingRules..............................................18 13.3.1.Rules...........................................17 9.3.1. Matching rules from RFC2252.............................18 13.3.2.2252..........................17 9.3.2. Matching rule from RFC2256..............................18 13.3.3.2256...........................18 9.3.3. Additional matching rules fromX.520.....................19 13.3.4.X.520..................18 9.3.4. Matching rules not defined in any referenceddocument....19 14. Appendix B - Change History....................................20 M. Smith Network Working Group [Page 2] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999 4.document.19 10. Full Copyright Statement...................................20 1. Background and Intended Usage The inetOrgPerson object class is a general purpose object class that holds attributes about people. The attributes it holds were chosen to accommodate information requirements found in typical Internet and Intranet directory service deployments. The inetOrgPerson object class is designed to be used within directory services based on the LDAP [RFC2251] and the X.500 family of protocols, and it should be useful in other contexts as well. There is no requirement for directory services implementors to use the inetOrgPerson object class; it is simply presented as well-documented class that implementors can choose to use if they find it useful. Smith Informational [Page 2] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 The attribute type and object class definitions in this document are written using the BNF form of AttributeTypeDescription and ObjectClassDescription given in [RFC2252]. In some cases lines have been folded for readability. Attributes that are referenced but not defined in this document are included in one of the following documents: The COSINE and Internet X.500 Schema [RFC1274] Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) [RFC2079] A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256] See Appendix A for a summary of the attribute types, associatedsyn- taxes,syntaxes, and matching rules used in this document.5.2. New Attribute Types Used in the inetOrgPerson Object Class5.1.2.1. Vehicle license or registration plate. This multivalued field is used to record the values of the license or registration plate associated with an individual. ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )M. Smith Network Working Group [Page 3] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999 5.2.2.2. Department number Code for department to which a person belongs. This can also be strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123). ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5.3.Smith Informational [Page 3] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 2.3. Display Name When displaying an entry, especially within a one-line summary list, it is useful to be able to identify a name to be used. Since otherattri- buteattribute types such as 'cn' are multivalued, an additional attribute type is needed. Display name is defined for this purpose. ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'preferred name of a person to be used when displaying entries' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.4.2.4. Employee Number Numeric or alphanumeric identifier assigned to a person, typically based on order of hire or association with an organization. Single valued. ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )5.5.2.5. Employee Type Used to identify the employer to employee relationship. Typical values used will be "Contractor", "Employee", "Intern", "Temp", "External", and "Unknown" but any value may be used.M. Smith Network Working Group [Page 4] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'type of employment for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5.6.Smith Informational [Page 4] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 2.6. JPEG Photograph Used to store one or more images of a person using the JPEG FileInter- changeInterchange Format [JFIF]. ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'a JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) Note that the jpegPhoto attribute type was defined for use in theInter- netInternet X.500 pilots but no referencable definition for it could be located.5.7.2.7. Preferred Language Used to indicate an individual's preferred written or spoken language. This is useful for international correspondence orhuman-computerhuman- computer interaction. Values for this attribute type MUST conform to thedefini- tiondefinition of the Accept-Language header field defined in [RFC2068] with one exception: the sequence "Accept-Language" ":" should be omitted. This is a single valued attribute type. ( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'preferred written or spoken language for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) )5.8.2.8. User S/MIME CertificateAn S/MIME [RFC1847]A PKCS#7 [RFC2315] SignedData, where the content that is signedmessage with a zero-length body. This attri- buteisto be stored and requested in binary form, as 'userSMIMECertificate;binary'.ignored by consumers of userSMIMECertificate values. Itcontains the person's entire certifi- cate chain and the signedis recommended that values have a `contentType' of data with an absent `content' field. Values of this attribute contain a person's entire certificate chain and an smimeCapabilities field [RFC2633] that at a minimum describes their SMIME algorithmcapa- bilities,capabilities. Values for this attribute are to be storedasand requested in binarydata.form, as 'userSMIMECertificate;binary'. If available, this attribute isM. Smith Network Working Group [Page 5] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999preferred over the userCertificate attribute for S/MIME applications. ( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC'signed message'PKCS#7 SignedData used to support S/MIME' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )5.9.Smith Informational [Page 5] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 2.9. User PKCS #12 PKCS #12 [PKCS12] provides a format for exchange of personal identity information. When such information is stored in a directory service, the userPKCS12 attribute should be used. This attribute is to be stored and requested in binary form, as 'userPKCS12;binary'. The attribute values are PFX PDUs stored as binary data. ( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal identity information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )) 6.3. Definition of the inetOrgPerson Object Class The inetOrgPerson represents people who are associated with anorganiza- tionorganization in some way. It is a structural class and is derived from the organizationalPerson class which is defined in X.521 [X521]. ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) For reference, we list the following additional attribute types that are part of the inetOrgPerson object class. These attribute types are inherited from organizationalPerson (which in turn is derived from theM.person object class): SmithNetwork Working GroupInformational [Page 6]INTERNET-DRAFTRFC 2798 The LDAP inetOrgPerson Object Class22April1999 person object class):2000 MUST ( cn $ objectClass $ sn ) MAY ( description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ title $ userPassword $ x121Address )7.4. Example of an inetOrgPerson Entry The following example is expressed using the LDIF notation defined in [LDIF]. version: 1 dn: cn=Barbara Jensen,ou=ProductDevelopment,dc=airius,dc=comDevelopment,dc=siroe,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen displayName: Babs Jensen sn: Jensen givenName: Barbara initials: BJJ title: manager, product development uid: bjensen mail:bjensen@airius.combjensen@siroe.com telephoneNumber: +1 408 555 1862 facsimileTelephoneNumber: +1 408 555 1992 mobile: +1 408 555 1941 roomNumber: 0209 carLicense: 6ABC246 o:AiriusSiroe ou: Product Development departmentNumber: 2604 employeeNumber: 42 employeeType: full time preferredLanguage: fr, en-gb;q=0.8, en;q=0.7 labeledURI:http://www.airius.com/users/bjensenhttp://www.siroe.com/users/bjensen My Home PageM.SmithNetwork Working GroupInformational [Page 7]INTERNET-DRAFTRFC 2798 The LDAP inetOrgPerson Object Class22April1999 8.2000 5. Security Considerations Attributes of directory entries are used to provide descriptiveinforma- tioninformation about the real-world objects they represent, which can be people, organizations or devices. Most countries have privacy laws regarding the publication of information about people. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.9.6. Acknowledgments The Netscape Directory Server team created the inetOrgPerson object class based on experience and customer requirements. Anil Bhavnani and John Kristian in particular deserve credit for all of the early design work. Many members of the Internet community, in particular those in the IETF ASID and LDAPEXT groups, also contributed to the design of this object class.10. Copyright Copyright (C) The Internet Society (1996-1999). All Rights Reserved. This document7. Bibliography [JFIF] E. Hamilton, "JPEG File Interchange Format (Version 1.02)", C-Cube Microsystems, Milpitas, CA, September 1, 1992. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification", Work in Progress. [PKCS12] "PKCS #12: Personal Information Exchange Standard", Version 1.0 Draft, 30 April 1997. [RFC1274] Barker, P. andtranslations of it may be copiedS. Kille, "The COSINE andfurnished to oth- ers,Internet X.500 Schema", RFC 1274, November 1991. [RFC1847] Galvin, J., Murphy, S., Crocker, S. andderivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedN. Freed, "Security Multiparts for MIME: Multipart/Signed anddis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright noticeMultipart/Encrypted", RFC 1847, October 1995. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. andthis 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 Stan- dards 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 M. Smith Network Working Group [Page 8] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- NESS FOR A PARTICULAR PURPOSE. 11. Bibliography [JFIF] E. Hamilton, "JPEG File Interchange Format (Version 1.02)", C-Cube Microsystems, Milpitas, CA, September 1, 1992. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification" INTERNET-DRAFT <draft-good-ldap-ldif-02.txt>, 1 February 1999. [PKCS12] "PKCS #12: Personal Information Exchange Standard", Version 1.0 DRAFT, 30 April 1997. [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991. [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2079] M. Smith, "Definition of an X.500 Attribute TypeT. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079,Janu- aryJanuary 1997. Smith Informational [Page 8] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 [RFC2251]M.Wahl,T.M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252]M.Wahl,A.M., Coulbeck,T.A., Howes,S.T., Kille,W.S., Yeong, W. and C. Robbins, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.M. Smith Network Working Group [Page 9] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999[RFC2256]M.Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [X520] ITU-T Rec. X.520, "The Directory: Selected Attribute Types", 1996. [X521] ITU-T Rec. X.521, "The Directory: Selected Object Classes", 1996.12.8. Author's Address Mark Smith Netscape Communications Corp. 501 E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043, USA Phone: +1 650 937-3477 EMail: mcs@netscape.com13.Smith Informational [Page 9] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 9. Appendix A - inetOrgPerson Schema Summary This appendix provides definitions of all the attribute types included in the inetOrgPerson object class along with their associated syntaxes and matching rules.13.1.9.1. Attribute Types13.1.1.9.1.1. New attribute types that are defined in this document ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.16.840.1.113730.3.1.241 NAME 'displayName'M. Smith Network Working Group [Page 10] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999DESC 'preferred name of a person to be used when displaying entries' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'type of employment for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Smith Informational [Page 10] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'a JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) Note: The jpegPhoto attribute type was defined for use in the Internet X.500 pilots but no referencable definition for it could be located. ( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'preferred written or spoken language for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC 'signed message used to support S/MIME' SYNTAX1.3.6.1.4.1.1466.115.121.1.401.3.6.1.4.1.1466.115.121.1.5 ) ( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal identity information' SYNTAX1.3.6.1.4.1.1466.115.121.1.401.3.6.1.4.1.1466.115.121.1.5 )M. Smith Network Working Group [Page 11] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999 13.1.2.9.1.2. Attribute types from RFC 2256 Note that the original definitions of these types can be found in X.520. ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) ( 2.5.4.3 NAME 'cn' SUP name ) ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) Smith Informational [Page 11] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) ( 2.5.4.23 NAME 'facsimileTelephoneNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) ( 2.5.4.42 NAME 'givenName' SUP name ) ( 2.5.4.43 NAME 'initials' SUP name ) ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) ( 2.5.4.7 NAME 'l' SUP name )M. Smith Network Working Group [Page 12] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.4.10 NAME 'o' SUP name ) ( 2.5.4.11 NAME 'ou' SUP name ) ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) Smith Informational [Page 12] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) ( 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE ) ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ( 2.5.4.34M. Smith Network Working Group [Page 13] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999NAME 'seeAlso' SUP distinguishedName ) ( 2.5.4.4 NAME 'sn' SUP name ) ( 2.5.4.8 NAME 'st' SUP name ) ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) Smith Informational [Page 13] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} ) ( 2.5.4.22 NAME 'teletexTerminalIdentifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) ( 2.5.4.12 NAME 'title' SUP name ) ( 2.5.4.36 NAME 'userCertificate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatchM. Smith Network Working Group [Page 14] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) Some attribute types included in inetOrgPerson are derived from the 'name' and 'distinguishedName' attribute supertypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) Smith Informational [Page 14] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )13.1.3.9.1.3. Attribute types from RFC 1274 ( 0.9.2342.19200300.100.1.55 NAME 'audio' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{250000} ) Note: The syntax used here for the audio attribute type is Octet String. RFC 1274 uses a syntax called audio which is not defined in RFC 1274. ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) Note: RFC 1274 uses the longer name 'homeTelephoneNumber'. ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ( 0.9.2342.19200300.100.1.3 NAME 'mail' EQUALITY caseIgnoreIA5MatchM. Smith Network Working Group [Page 15] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID of 0.9.2342.19200300.100.3.5.The newerAll recent LDAP documents and most deployed LDAPRFCsimplementations refer to thisthisattribute as 'mail' and define the IA5 String syntax using using the OID 1.3.6.1.4.1.1466.115.121.1.26, as is done here. ( 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) Smith Informational [Page 15] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 0.9.2342.19200300.100.1.41 NAME 'mobile' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'. ( 0.9.2342.19200300.100.1.42 NAME 'pager' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'. ( 0.9.2342.19200300.100.1.7 NAME 'photo' ) Note: Photo attribute values are encoded in G3 fax format with an ASN.1 wrapper. Please refer to RFC 1274 section 9.3.7 for detailed syntax information for this attribute. ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) ( 0.9.2342.19200300.100.1.21 NAME 'secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )M. Smith Network Working Group [Page 16] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999Note: RFC 1274 uses the longer name 'userid'.13.1.4.9.1.4. Attribute type from RFC 2079 ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )13.2.Smith Informational [Page 16] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 9.2. Syntaxes13.2.1.9.2.1. Syntaxes from RFC 2252 ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )13.2.2.9.2.2. Syntaxes from RFC 2256 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )M. Smith Network Working Group [Page 17] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' ) ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )13.3.9.3. Matching Rules13.3.1.9.3.1. Matching rules from RFC 2252 Note that the original definition of many of these matching rules can be found in X.520. Smith Informational [Page 17] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )13.3.2.9.3.2. Matching rule from RFC 2256 Note that the original definition of this matching rule can be found in X.520. ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )M. Smith Network Working Group [Page 18] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999 13.3.3.9.3.3. Additional matching rules from X.520 caseExactMatch ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) This rule determines whether a presented string exactly matches an attribute value of syntax DirectoryString. It is identical tocaseIg- noreMatchcaseIgnoreMatch except that case is not ignored. Multiple adjoiningwhi- tespacewhitespace characters are treated the same as an individual space, and leading and trailing whitespace is ignored. Smith Informational [Page 18] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 caseExactSubstringsMatch ( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX1.3.6.1.4.1.1466.115.121.1.151.3.6.1.4.1.1466.115.121.1.58 ) This rules determines whether the initial, any and final substringele- mentselements in a presented value are present in an attribute value of syntax DirectoryString. It is identical to caseIgnoreSubstringsMatch except that case is not ignored. caseIgnoreListSubstringsMatch ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' SYNTAX1.3.6.1.4.1.1466.115.121.1.411.3.6.1.4.1.1466.115.121.1.58 ) This rule compares a presented substring with an attribute value which is a sequence of DirectoryStrings, but where the case of letters is not significant for comparison purposes. A presented value matches a stored value if and only if the presented value matches the string formed by concatenating the strings of the stored value. Matching is doneaccord- ingaccording to the caseIgnoreSubstringsMatch rule except that none of theini- tial,initial, final, or any values of the presented value match a substring of the concatenated string which spans more than one of the strings of the stored value.13.3.4.9.3.4. Matching rules not defined in any referenced document caseIgnoreIA5SubstringsMatch ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX1.3.6.1.4.1.1466.115.121.1.261.3.6.1.4.1.1466.115.121.1.58 )M. Smith Network Working Group [Page 19] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 22 April 1999This rules determines whether the initial, any and final substringele- mentselements in a presented value are present in an attribute value of syntax IA5 String without regard to the case of the letters in the strings. It is expected that this matching rule will be added to an update of RFC 2252.14. Appendix B - Change History Changes since draft-smith-ldap-inetorgperson-02.txt: Added the 'o' (organization) attribute as an optional attribute type. Changed the displayName attribute type from multi-valued to single- valued. Changed the syntaxSmith Informational [Page 19] RFC 2798 The LDAP inetOrgPerson Object Class April 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations ofthe userPKCS12it may be copied anduserSMIMECertificate attri- bute types from Octet Stringfurnished toBinary. Added syntaxesothers, andmatching rules to Appendix A. Replaced "SUBSTRINGS" with "SUBSTR"derivative works that comment on or otherwise explain it or assist inattribute type definitionsits implementation may be prepared, copied, published and distributed, inorder to comply with the syntax definedwhole or inRFC 2252. Updated the example to remove spaces from the DN, to show sample usepart, without restriction of any kind, provided that theo, ou,above copyright notice anddisplayName typesthis 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 toreplacethedomain names inInternet Society or other Internet organizations, except as needed for themail and labeledURI sample values with a legally cleaner value. Updatedpurpose of developing Internet standards in which case theX.500 referencesprocedures for copyrights defined in thebibliography from 1993 to 1996; removed referenceInternet Standards process must be followed, or as required toX.500. Improved the formatting oftranslate 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 documentslightly by adding vertical white spaceandmy movingthetable of contents close toinformation 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. Acknowledgement Funding for the RFC Editor function is currently provided by thebegin- ning. ThisInternetDraft expires on 22 October 1999. M.Society. SmithNetwork Working GroupInformational [Page 20] ----