[Date Prev][Date Next] [Chronological] [Thread] [Top]

draft-greenblatt-ldap-certinfo-schema-01

To: internet-drafts@ietf.org
Subject: draft-greenblatt-ldap-certinfo-schema-01
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Date: Sun, 16 Jan 2000 12:16:40 -0800
Cc: ietf-ldapext@netscape.com
Resent-date: Sun, 16 Jan 2000 12:19:04 -0800 (PST)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <-uCWR.A.kMG.Weig4@glacier>
Resent-sender: ietf-ldapext-request@netscape.com

I-D editor:

please replace draft-greenblatt-ldap-certinfo-schema-00 with the
following draft-greenblatt-ldap-certinfo-schema-01.  

LDAPEXT:

Attached is a personal draft that defines a new object class to hold
information
about certificates, so that all of a user's certificates don't need to be
directly attached 
to the user's entry in LDAP.  It has been updated with comments I've
received over the
last few months.  Enjoy...

Ryan






Application Working Group                               Bruce Greenblatt
Internet Draft
<draft-greenblatt-ldap-certinfo-schema-01>
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]

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

Prev by Date: ACCEPT CREDIT CARDS NOW (FREE SIGN UP) !!!!!fgd
Next by Date: Re: draft-greenblatt-ldap-certinfo-schema-01
Index(es):
- Chronological
- Thread