PKIX Working Group Sharon Boeyen (Entrust)
draft-ietf-pkix-ldapv2-schema-00.txt Tim Howes (Netscape)
Expires in 6 months Pat Richard (Xcert)
March 1998
Internet X.509 Public Key Infrastructure
LDAPv2 Schema
<draft-ietf-pkix-ldapv2-schema-00.txt>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents 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 docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in pro-
gress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
The schema defined in this document is a minimal schema to support
PKIX in an LDAPv2 environment, as defined in draft-ietf-pkix-ipki-
ldapv2-06.txt. Only PKIX-specific components are specified here.
LDAP servers, acting as PKIX repositories should support the auxi-
liary object classes defined in this specification and integrate
this schema specification with the generic and other application-
specific schemas as appropriate, depending on the services to be
supplied by that server.
The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'', and
''MAY'' in this document are to be interpreted as described in RFC
2119.
Please send comments on this document to the ietf-pkix@tandem.com
mail list.
Boeyen, Howes & Richard [Page 1]
INTERNET DRAFT March 1998
3. Introduction
This specification is part of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is
one mechanism defined for access to a PKI repository. Other mechan-
isms, such as http, are also defined. If an LDAP server, accessed
by LDAPv2 is used to provide a repository, the minimum requirement
is that the repository support the addition of X.509 certificates
to directory entries. Certificate Revocation List (CRL)is one
mechanism for publishing revocation information in a repository.
Other mechanisms, such as http, are also defined.
This specification defines the attributes and object classes to be
used by LDAP servers acting as PKIX repositories and to be under-
stood by LDAP clients communicating with such repositories to
query, add, modify and delete PKI information. Some object classes
and attributes defined in X.509 are duplicated here for complete-
ness. For end entities and Certification Authorities (CA), the
relevant X.509 defined object classes mandate inclusion of attri-
butes which are optional for PKIX. Also, because of the mandatory
attribute specification, this would have required dynamic modifica-
tion of the object class attribute should the attributes not always
be present in entries. For these reasons, alternative object
classes are defined in this document to be used for these objects,
rather than the X.509 defined classes, by LDAP servers acting as
PKIX repositories.
4. PKIX Repository Objects
The primary PKIX objects to be represented in a repository are:
- End Entities
- Certification Authorities (CA)
These objects are defined in draft-ietf-pkix-ipki-part1-06.txt.
4.1. End Entities
For purposes of PKIX schema definition, the role of end entities as
subjects of certificates is the major aspect relevant to this
specification. End entities may be human users, or other types of
entities to which certificates may be issued. In some cases, the
entry for the end entity may already exist and the PKI-specific
information is added to the existing entry. In other cases the
entry may not exist prior to the issuance of a certificate, in
which case the entity adding the certificate may also need to
create the entry. Schema elements used to represent the non PKIX
aspects of an entry, such as the structural object class used to
Boeyen, Howes & Richard [Page 2]
INTERNET DRAFT March 1998
represent organizational persons, may vary, depending on the par-
ticular environment and set of applications served and are outside
the scope of this specification.
The following auxiliary object class MAY be used to represent cer-
tificate subjects:
pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {userCertificate}
--ID { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) t.b.s }
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
An end entity may obtain one or more certificates from one or more
Certification Authorities. The userCertificate attribute MUST be
used to represent these certificates in the directory entry
representing that user.
5. Certification Authorities
As with end entities, Certification Authorities are typically
represented in directories as auxiliary components of entries
representing a more generic object, such as organizations, organi-
zational units etc. The non PKIX-specific schema elements for these
entries, such as the structural object class of the object, are
outside the scope of this specification.
The following auxiliary object class MAY be used to represent Cer-
tification Authorities:
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
--ID { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) t.b.s. }
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
Boeyen, Howes & Richard [Page 3]
INTERNET DRAFT March 1998
The cACertificate attribute, held in a particular CA's directory
entry, may be used to store self-signed certificates.
certificateRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) certificateRevocationList(39) }
The certificateRevocationList attribute, if present in a particular
CA's entry, contains CRL(s) as defined in draft-ietf-pkix-ipki-
part1-06.txt.
authorityRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) authorityRevocationList(38) }
The authorityRevocationList attribute, if present in a particular
CA's entry, includes revocation information regarding certificates
issued to other CAs.
crossCertificatePairATTRIBUTE::={
WITH SYNTAX CertificatePair
EQUALITY MATCHING RULE certificatePairExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }
The crossCertificatePair attribute, held in a particular CA's
directory entry, may be used to store certificates issued by this
CA to other CAs, as well as certificates issued for this CA by
other CAs. Values held in the forward element are certificates
issued for this CA by other CAs, while values in the reverse ele-
ment are certificates issued by this CA for other CAs. Either cer-
tificate, if present, may be used in building certificate paths
for validation and may be published in the directory entries of
either CA or both.
5.0.1. CRL distribution points
CRL distribution points are an optional mechanism, specified in
draft-ietf-pkix-ipki-part1-06.txt, which MAY be used to distribute
revocation information.
A patent statement regarding CRL distribution points can be found
at the end of this document (t.b.s.).
If a CA elects to use CRL distribution points, the following object
class is used to represent these.
cRLDistributionPoint OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN { commonName }
MAY CONTAIN { certificateRevocationList |
Boeyen, Howes & Richard [Page 4]
INTERNET DRAFT March 1998
authorityRevocationList |
deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
The certificateRevocationList and authorityRevocationList attri-
butes are as defined above.
The commonName attribute and deltaRevocationList attributes,
defined in X.509, are duplicated below.
commonName ATTRIBUTE::={
SUBTYPE OF name
WITH SYNTAX DirectoryString
ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) deltaRevocationList(53) }
6. Security Considerations
Since the elements of information which are key to the PKI service
(certificates and CRLs) are both digitally signed pieces of infor-
mation, no additional integrity service is REQUIRED.
Security considerations with respect to retrieval, addition, dele-
tion, and modification of the information supported by this schema
definition are addressed in draft-ietf-pkix-ipki-ldapv2-06.txt.
7. References
[1] Lightweight Directory Access Protocol. Y. Yeong, T. Howes, S.
Kille, RFC 1777, March 1995.
[2] Key Words for use in RFCs to Indicate Requirement Levels, S.
Bradner, RFC 2119, March 1997.
8. Author's Address
Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7
sharon.boeyen@entrust.com
Tim Howes
Boeyen, Howes & Richard [Page 5]
INTERNET DRAFT March 1998
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
howes@netscape.com
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
patr@xcert.com
Boeyen, Howes & Richard [Page 6]