Application Working Group Bruce Greenblatt Internet Draft Expires in six months LDAP Object Class for Holding Certificate Information Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, andits working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "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. Distribution of this document is unlimited. Abstract This draft describes a means for LDAP applications to store large numbers of certificates for a single user, and to still have individual certificates easily retrievable without the need for any extensions to the LDAP v2 or v3 protocols. 1. Mechanism When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 [2], it is normally only possible to read either the attribute type, or the attribute type and all its values. It is not possible to selectively read just a few of the attribute values using the basic structures of Greenblatt [Page 1] Internet Draft January 2000 the protocol defined in [1] or [2]. Certain information that belongs to a user may have many different values. For example, some users may have quite a large number of certificates that need to be stored in the directory. If a user has 1000s of certificates, then it may be diffi- cult to find the exact one that is needed. If only one certificate is needed by the LDAP client, then retrieving the entire userCertificate attribute that has 1000s of values is a waste of time. If numerous application services are going to want to selectively retrieve certificates (which is perfectly valid), a general solution in the schema should be provided. The following solution is given: RFC 2587 defines a schema for holding certificate information, but assumes that all of a user's certificates are attached to that user's LDAP entry. Use this structural class to indicate that an object in the directory is a specific type of certificate. Each certificateType object in the directory appears directly beneath the owner of the cer- tificate in the directory hierarchy. RFC 2459 [3] specifies a profile for X.509 v3 certificates. It's definitions are used to define the attributes that can be placed in a certificateType object. ( o.i.d.m.i.s.s.i.n.g. NAME 'certificateType' SUP top STRUCTURAL MUST typeName MAY ( serialNumber $ issuer $ validityNotBefore $ vallidityNo- tAfter $ subject $ subjectPublicKeyInfo) certificateExtension $ other- Info ) ) The attributes are defined as follows: ( NAME 'typeName' SUP name SINGLE-VALUE ) The typeName attribute specifies the application defined type of the certificate that is attached to this entry using the strongAuthenti- cationUser auxiliary object class. Note that there may not be any cer- tificates attached to this entry if the user has no certificates of the specified type. Each type name uniquely identifies an entry within the container. The following attributes are the LDAP representations of the cer- tificate attributes defined in RFC 2459, and have been pulled out as separate attributes to ease searching. ( NAME 'serialNumber' SUP name SINGLE-VALUE ) Rather than using the ASN.1 integer type as is used in RC 2459, the serialNumber attribute represents the value in string format representa- tion of the decimal format of the serial number. Greenblatt [Page 2] Internet Draft January 2000 ( NAME 'issuer' SUP distinguishedName SINGLE-VALUE ) ( NAME 'validityNotBefore' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( NAME 'validityNotAfter' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) The 'validityNotBefore" and 'validityNotAfter' attributes have split the 'validity' attribute defined in RFC 2459 which uses an ASN.1 sequence containing a "notBefore" and a "notAfter" value. Instead of using an ASN.1 Sequence, the character string representation of each time as defined in section 6.14 of RFC 2252 is used for each time. For example, if the 'validityNotBefore' attribute held the time value: "199412161032Z" and the 'validityNotAfter' attribute held the time val- uee: "199512161032Z", then that would indicate that the certificate described by this entry was valid from December 16, 1994 to December 16, 1995. ( NAME 'subject' SUP distinguishedName SINGLE-VALUE ) ( NAME 'subjectPublicKeyInfo' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} SINGLE-VALUE ) The certificateExtension attribute is used to store whatever inter- esting extension from the certifcate that are pulled out of the stored certificate. Note that it is the only multi-valued attribute of the certificateType object class. ( NAME 'certificateExtension' octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) The format of the certificate extension attribute value is a string representation of an OID according to the specifications of RFC 2252 [4], followed by a '$' as the separation character, followed by the value. Octets following the dollar sign may be binary data. For exam- ple, the keyUsage extension defined in RFC 2459 is a bitString. For extensions that are ASN.1 encoded (such as the keyUsage extension), the entire ASN.1 encoding MUST immediately follow the separation character. Other certificate formats that allow non ASN.1 encoded extensions MUST place their values immediately following the separation character as well. Greenblatt [Page 3] Internet Draft January 2000 ( NAME 'otherInfo' SUP name ) The purpose of the otherInfo attribute is to allow descriptive information to be placed in entry that does not appear in the certifi- cate itself. The values of this attribute are free form text strings, e.g. "this certificate gets me into the IETF web site". Note that the certificateType object class does not include an attribute for holding the actual certificate. This is due to the fact that the certificate will be held in an attribute of an auxiliary object class that will be attached to the entry. 2. Comparison with Matched Values Only Control A control has been defined that allows for only certain values of a specified attribute to be returned from a matching entry [5]. In this section, these two approaches are compared. The major benefit of the Matched Values Only Control is that it does not require any changes to the DIT. If a customer has deployed certificate information in such a way that individual entries have numerous certificates attached to them then the Matched Values Only Control is useful. While it is a simple matter to modify the DIT in such a way that all certificate information is removed from the entries, and placed in the container directly beneath the entries according to the definitions of this specification, it is less simple to simultaneously modify all of the applications that depend on certificates being stored in the entry. Thus, it may be desirable to duplicate the certificate information, by having it appear in the entry, as well as in the container beneath the entry for a short period of time, in order to allow for migration of the applications to the new LDAP schema. As in any situation in which information is dupli- cated, great care must be taken in order to insure the integrity of the information. There are several advantages to using the certificateType object class. No special matching rules are needed to retrieve a specific cer- tificate. Any field in the certificate can be used in the search fil- ter. Even information that doesn't appear in the certificate can be used in a search filter. It is easier to remove certificates from the DIT, since the entire certificate DER does not have to be supplied in the modify operation. 3. Examples Using the certificate given in Section D.2 of RFC 2459, the follow- ing values would be used for the attributes defined in this draft: Greenblatt [Page 4] Internet Draft January 2000 typeName - "General Purpose Certificate" serialNumber - "18" issuer - "OU=nist; O=gov; C=US" subject - "CN=Tim Polk; OU=nist; O=gov; C=US" validityNotBefore - "970730000000Z" validityNotAfter - "971231000000Z" certificateExtension: "2.5.29.17: " + 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76 otherInfo - "contains a 1024 bit DSA public key", "this was issued for test purposes only" 4. References [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Proto- col" RFC 1777, March 1995. [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Proto- col, (v3)" RFC 2251, December 1997. [3] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459, January 1999. [4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions" RFC 2252, December 1997. [5] D. Chadwick, Sean Mullan, "Returning Matched Values with LDAPv3", Internet Draft (work in progress), September 1999. 5. Author's Address Bruce Greenblatt Directory Tools and Application Services, Inc. 6841 Heaton Moor Drive San Jose, CA 95119 USA Email: bgreenblatt@directory-applications.com Greenblatt [Page 5]