Application Working Group Bruce Greenblatt Internet Draft draft-greenblatt-ldap-certinfo-schema-00.txt 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. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Direc- tories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 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 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 Greenblatt [Page 1] Internet Draft August 1999 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 AUXILIARY MUST typeName MAY ( serialNumber $ issuer $ validity $ subject $ subjectPub- licKeyInfo) certificateExtension $ otherInfo ) ) The attributes are defined as follows: ( NAME 'certificateType' SUP name SINGLE-VALUE ) The certificateType attribute specifies the application defined type of the certificate that is attached to this entry using the stron- gAuthenticationUser auxiliary object class. Note that there may not be any certificates 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 ) ( NAME 'issuer' SUP distinguishedName SINGLE-VALUE ) ( NAME 'validity' SUP name SINGLE-VALUE ) ( NAME 'subject' SUP distinguishedName SINGLE-VALUE ) Greenblatt [Page 2] Internet Draft August 1999 ( 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 [5], 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. ( 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 [6]. 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 Greenblatt [Page 3] Internet Draft August 1999 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. References To be supplied. 4. 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 4]