PKIX Working Group Sharon Boeyen (Entrust)

draft-ietf-pkix-LDAPv2-schema-02.txt Tim Howes (Netscape)

Expires in 6 months Pat Richard (Xcert)

September 1998

Internet X.509 Public Key Infrastructure

LDAPv2 Schema

\<draft-ietf-pkix-LDAPv2-schema-02.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), ftp.ietf.org (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-

ipki2opp-07.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\', \'SHALL\', \'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@imc.org mail

list.

Boeyen, Howes & Richard \[Page 1\]

INTERNET DRAFT September 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 ear-

lier X.509 defined object classes mandated inclusion of attributes

which are optional for PKIX. Also, because of the mandatory attri-

bute specification, this would have required dynamic modification

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 for use 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-09.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

represent organizational persons, may vary, depending on the

Boeyen, Howes & Richard \[Page 2\]

INTERNET DRAFT September 1998

particular environment and set of applications served and are out-

side 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 { joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}

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.

4.2. 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 { joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}

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 September 1998

crossCertificatePairATTRIBUTE::={

WITH SYNTAX CertificatePair

EQUALITY MATCHING RULE certificatePairExactMatch

ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}

The cACertificate attribute of a CA\'s directory entry shall be used

to store self-issued certificates (if any) and certificates issued

to this CA by CAs in the same realm as this CA.

The forward elements of the crossCertificatePair attribute of a

CA\'s directory entry shall be used to store all, except self-issued

certificates issued to this CA. Optionally, the reverse elements

of the crossCertificatePair attribute, of a CA\'s directory entry

may contain a subset of certificates issued by this CA to other

CAs. When both the forward and the reverse elements are present in

a single attribute value, issuer name in one certificate shall

match the subject name in the other and vice versa, and the subject

public key in one certificate shall be capable of verifying the

digital signature on the other certificate and vice versa.

When a reverse element is present, the forward element value and

the reverse element value need not be stored in the same attribute

value; in other words, they can be stored in either a single attri-

bute value or two attribute values.

In the case of V3 certificates, none of the above CA certificates

shall include a basicConstraints extension with the cA value set to

FALSE.

The definition of realm is purely a matter of local policy.

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-08.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.

Boeyen, Howes & Richard \[Page 4\]

INTERNET DRAFT September 1998

4.2.1. CRL distribution points

CRL distribution points are an optional mechanism, specified in

draft-ietf-pkix-ipki-part1-09.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.

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 \|

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) }

4.2.2. Delta CRLs

Delta CRLs are an optional mechanism, specified in draft-ietf-

pkix-ipki-part1-09.txt, which MAY be used to enhance the distribu-

tion of revocation information.

If a CA elects to use delta CRLs, the following object class is

used to represent these.

deltaCRL OBJECT-CLASS::= {

SUBCLASS OF { top }

Boeyen, Howes & Richard \[Page 5\]

INTERNET DRAFT September 1998

KIND auxiliary

MAY CONTAIN { deltaRevocationList }

ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }

5\. 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-08.txt.

6\. 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.

7\. Patent Statements

This schema includes elements to store data items associated with

patented technology. The Internet Standards Process as defined in

RFC 1310 requires a written statement from the Patent holder that a

license will be made available to applicants under reasonable terms

and conditions prior to approving a specification as a Proposed,

Draft or Internet Standard

A patent statement for CRL Distribution Points follows. This state-

ment has been supplied by the patent holder, not the authors of

this specification.

The Internet Society, Internet Architecture Board, Internet

Engineering Steering Group and the Corporation for National

Research Initiatives take no position on the validity or scope of

the following patent nor on the appropriateness of the terms of the

assurance. The Internet Society and other groups mentioned above

have not made any determination as to any other intellectual pro-

perty rights which may apply to the practice of this standard. Any

further consideration of these matters is the user\'s responsibil-

ity.

7.1. CRL Distribution Points

Entrust Technologies Incorporated has provided the following

Boeyen, Howes & Richard \[Page 6\]

INTERNET DRAFT September 1998

statement with regard to this patent:

Entrust Technologies Incorporated advises the IETF that it holds

the Patent (as defined herein) which may relate to the ITU-T. In

accordance with the Intellectual Property rights procedures of the

ITU-T standards process, Entrust Technologies Incorporated, for

itself and its subsidiaries (hereinafter called \"Entrust\") will

offer licenses under its Patent on a perpetual, royalty-free, non-

exclusive basis and on non-discriminatory, fair and equitable terms

to all parties solely for their use in complying with the Standard

(as defined herein), but on condition that any such party offers to

Entrust and its corporate affiliates similar licenses under such

party\'s patents, if any, for use in complying with the Standard.

Any application for a license under Entrust\'s Patent pursuant to

this Patent Disclosure Statement should be made to:

Stephen Samson

Entrust Technologies Limited

750 Heron Road, Ottawa, Ontario, Canada, K1V 1A7

voice: (613) 247 3725

As used herein:

\"Patent\" means US Patent 5,699,431 issued on 16 December, 1997 for

an invention known as a \"Method for Efficient Management of Certi-

ficate Revocation Lists and Update Information\", which invention is

owned or controlled by Entrust and the use of which may be required

in conjunction with the Standard.

\"Standard\" means ITU-T Recommendation X.509 (1997 E): Information

Technology, Open systems interconnection - The Directory: authenti-

cation framework.

8\. Author\'s Address

Sharon Boeyen

Entrust Technologies Limited

750 Heron Road

Ottawa, Ontario

Canada K1V 1A7

sharon.boeyen@entrust.com

Tim Howes

Netscape Communications Corp.

501 E. Middlefield Rd.

Mountain View, CA 94043

USA

howes@netscape.com

Boeyen, Howes & Richard \[Page 7\]

INTERNET DRAFT September 1998

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 8\]