[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 2587

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/