The LDAP inetOrgPerson Object Class Mark Smith INTERNET-DRAFT Netscape Communications Intended Category: Informational 11 March 1998 Expires: 11 September 1998 Definition of the inetOrgPerson LDAP Object Class Filename: draft-smith-ldap-inetorgperson-00.txt 1. Status of this Memo This draft document will be submitted to the RFC Editor as an Informa- tional document. Distribution of this memo is unlimited. Please send comments to the author . This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering 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. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright (C) The Internet Society (1998). All Rights Reserved. Please see the Copyright section near the end of this document for more information. This Internet Draft expires on 11 September 1998. 2. Abstract While the X.500 standards [X500] define many useful attribute types and object classes, 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. Smith Network Working Group [Page 1] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 3. 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. The attribute type and object class definitions are written using the BNF form of AttributeTypeDescription and ObjectClassDescription given in [RFC2252]. Lines have been folded for readability. Attributes that are referenced but not defined in this document are included in the standard and pilot attribute definitions [RFC2256] or in the labeledURI object class [RFC2079] 4. New Attribute Types Used in the inetOrgPerson Object Class 4.1. Vehicle license plate tag. This multivalued field is used to record the license plate tags associ- ated with an individual. ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'vehicle license plate tag' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) 4.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 SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) M. Smith Network Working Group [Page 2] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 4.3. 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 SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' SINGLE-VALUE ) 4.4. 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. ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'a person's type of employment' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) 4.5. Preferred Language Used to indicate an individual's preferred written or spoken language. This is useful for international correspondence or human-computer interaction. Values for this attribute type MUST conform to the defini- tion 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 'a person's preferred written or spoken language' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' SINGLE-VALUE ) M. Smith Network Working Group [Page 3] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 4.6. User S/MIME Certificate S/MIME [RFC1847] signed message with a zero-length body. This attribute is to be stored and requested in binary form, as 'userSMIMECertificate;binary'. It contains the person's entire certifi- cate chain and the signed attribute that describes their algorithm capa- bilities, stored as an octetString. If available, this attribute is preferred over the userCertificate attribute for S/MIME applications. ( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC 'signed message used to support S/MIME" SYNTAX 'octetString' ) 4.7. 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 octetStrings. ( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal identity information' SYNTAX 'octetString' ) 5. Definition of the inetOrgPerson Object Class The inetOrgPerson represents people who are associated with an organiza- tion in some way. It is a structural class and is derived from the organizationalPerson class. ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) M. Smith Network Working Group [Page 4] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 ) For reference, we list the following additional attribute types which are inherited from organizationalPerson (which in turn is derived from the person object class): MUST ( objectClass $ sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ title $ x121Address $ ) 6. Example of an inetOrgPerson Entry The following example is expressed using the LDIF notation defined in [LDIF]. dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen sn: Jensen givenName: Barbara initials: BJJ title: manager, product development uid: bjensen mail: bjensen@aceindustry.com telephoneNumber: +1 408 555 1862 facsimileTelephoneNumber: +1 408 555 1992 mobile: +1 408 555 1941 roomNumber: 0209 carLicense: 6ABC246 departmentNumber: 2604 employeeNumber: 42 employeeType: full time preferredLanguage: fr, en-gb;q=0.8, en;q=0.7 labeledURI: http://www.aceindustry.com/users/bjensen My Home Page M. Smith Network Working Group [Page 5] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 7. Security Considerations Attributes of directory entries are used to provide descriptive informa- tion 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. 8. 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. 9. Copyright Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, 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 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 6] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- NESS FOR A PARTICULAR PURPOSE. 10. Bibliography [X500]ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification" "The LDAP Data Interchange Format (LDIF)", INTERNET-DRAFT , 30 July 1997. [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 2068, 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 Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, Janu- ary 1997. [PKCS12] "PKCS #12: Personal Information Exchange Standard", Version 1.0 DRAFT, 30 April 1997. M. Smith Network Working Group [Page 7] INTERNET-DRAFT The LDAP inetOrgPerson Object Class 11 March 1998 11. 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.com 11.1. Appendix A - Change History Changes since draft-ietf-asid-inetorgperson-01.txt: Renamed draft (The ASID group is going away). Added userPKCS12 attribute type and reference to PKCS #12. Changed syntax of userSMIMECertificate attribute type and clarified usage. Changed description of employeeNumber and departmentNumber attribute type to allow alphanumeric codes to be used as well as strictly numeric ones. Updated references (LDAPv3 drafts are now RFCs). Added Copyright information. Removed Appendrix A - Open Issues. This Internet Draft expires on 11 September 1998. M. Smith Network Working Group [Page 8]