WDIFF

draft-ietf-pkix-ldapv2-schema-02.txt --> rfc2587.txt

PKIX

Network Working Group Sharon S. Boeyen (Entrust)
draft-ietf-pkix-LDAPv2-schema-02.txt Tim
Request for Comments: 2587 Entrust
Category: Standards Track T. Howes (Netscape)
Expires in 6 months Pat
Netscape
P. Richard (Xcert)
September 1998
Xcert
June 1999

Internet X.509 Public Key Infrastructure
LDAPv2 Schema
<draft-ietf-pkix-LDAPv2-schema-02.txt>

Status of this Memo

This document is specifies an Internet-Draft. Internet-Drafts are working
documents of Internet standards track protocol for the
Internet Engineering Task Force (IETF), its areas, community, 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 requests discussion 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 suggestions for
improvements. Please refer to cite them other than as "work in pro-
gress."

To learn the current status edition of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in "Internet
Official Protocol Standards" (STD 1) for 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. standardization state
and status of this protocol. Distribution of this memo is unlimited.

1. 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. RFC 2559. Only PKIX-specific PKIX-
specific components are specified here. LDAP servers, acting as PKIX
repositories should support the auxi-
liary auxiliary object classes defined in
this specification and integrate this schema specification with the
generic and other application-
specific 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

2. 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, mechanisms,
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

Boeyen, et al. Standards Track [Page 1]

RFC 2587 PKIX LDAPv2 Schema June 1999

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 understood
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. completeness. For end
entities and Certification Authorities (CA), the ear-
lier earlier X.509
defined object classes mandated inclusion of attributes which are
optional for PKIX. Also, because of the mandatory attri-
bute attribute
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.

3. 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. RFC 2459.

3.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 outside the scope of this specification.

The following auxiliary object class MAY be used to represent cer-
tificate
certificate subjects:

Boeyen, et al. Standards Track [Page 2]

RFC 2587 PKIX LDAPv2 Schema June 1999

pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {userCertificate}
--ID {
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.

3.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
organizational 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
Certification Authorities:

pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
--ID {
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)}

Boeyen, et al. Standards Track [Page 3]

RFC 2587 PKIX LDAPv2 Schema June 1999

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 attribute 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. RFC 2459.

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 et al. Standards Track [Page 4]

INTERNET DRAFT September 1998

4.2.1.

RFC 2587 PKIX LDAPv2 Schema June 1999

3.2.1. CRL distribution points

CRL distribution points are an optional mechanism, specified in
draft-ietf-pkix-ipki-part1-09.txt, RFC
2459, 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 attributes
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.

3.2.2. Delta CRLs

Delta CRLs are an optional mechanism, specified in draft-ietf-
pkix-ipki-part1-09.txt, RFC 2459, which
MAY be used to enhance the distribu-
tion distribution of revocation information.

If a CA elects to use delta CRLs, the following object class is used
to represent these.

Boeyen, et al. Standards Track [Page 5]

RFC 2587 PKIX LDAPv2 Schema June 1999

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

4. 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,
information, no additional integrity service is REQUIRED.

Security considerations with respect to retrieval, addition, dele-
tion,
deletion, and modification of the information supported by this
schema definition are addressed in draft-ietf-pkix-ipki-ldapv2-08.txt.

6. RFC 2559.

5. References

[1] Lightweight Directory Access Protocol. Y. Yeong, T. Y., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.

[2] Key Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels, S.
Bradner,
Levels", BCP 14, RFC 2119, March 1997.

7. Patent Statements

This schema includes elements to store data items associated with
patented technology.

6 Intellectual Property Rights

The Internet Standards Process as defined IETF has been notified of intellectual property rights claimed 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
regard to approving a specification as a Proposed,
Draft some or Internet Standard

A patent statement for CRL Distribution Points follows. This state-
ment has been supplied by all of the patent holder, not specification contained in this
document. For more information consult the authors online list of
this specification. claimed
rights.

The Internet Society, Internet Architecture Board, Internet
Engineering Steering Group and the Corporation for National
Research Initiatives take IETF takes no position on regarding 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 property or other rights which may apply that might be claimed to
pertain to the practice of this standard. Any
further consideration implementation or use 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 technology described in
this patent:

Entrust Technologies Incorporated advises document or the IETF extent to which any license under such rights
might or might not be available; neither does it represent that it holds
the Patent (as defined herein) which may relate
has made any effort to identify any such rights. Information on the ITU-T. In
accordance
IETF's procedures with the Intellectual Property respect to rights procedures in standards-track and
standards-related documentation can be found in BCP-11. Copies of the
ITU-T standards process, Entrust Technologies Incorporated,
claims of rights made available 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 publication 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 assurances of
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 available, or the result of an invention known as attempt made to
obtain a "Method for Efficient Management of Certi-
ficate Revocation Lists and Update Information", which invention is
owned general license or controlled by Entrust and permission for the use of which may such
proprietary rights by implementors or users of this specification can
be required
in conjunction with obtained from 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 IETF Secretariat.

Boeyen, et al. Standards Track [Page 6]

RFC 2587 PKIX LDAPv2 Schema June 1999

7. Authors' Addresses

Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7

EMail: sharon.boeyen@entrust.com

Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA

EMail: 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

EMail: patr@xcert.com

Boeyen, Howes & Richard et al. Standards Track [Page 7]

RFC 2587 PKIX LDAPv2 Schema June 1999

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Boeyen, et al. Standards Track [Page 8]

----