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]