git.sur5r.net Git - openldap/blob - doc/rfc/rfc2587.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                     S. Boeyen
   8 Request for Comments: 2587                                  Entrust
   9 Category: Standards Track                                  T. Howes
  10                                                            Netscape
  11                                                          P. Richard
  12                                                               Xcert
  13                                                           June 1999
  14
  15
  16
  17                 Internet X.509 Public Key Infrastructure
  18                              LDAPv2 Schema
  19
  20 Status of this Memo
  21
  22    This document specifies an Internet standards track protocol for the
  23    Internet community, and requests discussion and suggestions for
  24    improvements.  Please refer to the current edition of the "Internet
  25    Official Protocol Standards" (STD 1) for the standardization state
  26    and status of this protocol.  Distribution of this memo is unlimited.
  27
  28 Copyright Notice
  29
  30    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  31
  32 1.  Abstract
  33
  34    The schema defined in this document is a minimal schema to support
  35    PKIX in an LDAPv2 environment, as defined in RFC 2559.  Only PKIX-
  36    specific components are specified here.  LDAP servers, acting as PKIX
  37    repositories should support the auxiliary object classes defined in
  38    this specification and integrate this schema specification with the
  39    generic and other application-specific schemas as appropriate,
  40    depending on the services to be supplied by that server.
  41
  42    The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
  43    and 'MAY' in this document are to be interpreted as described in RFC
  44    2119.
  45
  46 2.  Introduction
  47
  48    This specification is part of a multi-part standard for development
  49    of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
  50    mechanism defined for access to a PKI repository. Other mechanisms,
  51    such as http, are also defined. If an LDAP server, accessed by LDAPv2
  52    is used to provide a repository, the minimum requirement is that the
  53    repository support the addition of X.509 certificates to directory
  54
  55
  56
  57
  58 Boeyen, et al.              Standards Track                     [Page 1]
  59 \f
  60 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
  61
  62
  63    entries.  Certificate Revocation List (CRL)is one mechanism for
  64    publishing revocation information in a repository.  Other mechanisms,
  65    such as http, are also defined.
  66
  67    This specification defines the attributes and object classes to be
  68    used by LDAP servers acting as PKIX repositories and to be understood
  69    by LDAP clients communicating with such repositories to query, add,
  70    modify and delete PKI information. Some object classes and attributes
  71    defined in X.509 are duplicated here for completeness. For end
  72    entities and Certification Authorities (CA), the earlier X.509
  73    defined object classes mandated inclusion of attributes which are
  74    optional for PKIX. Also, because of the mandatory attribute
  75    specification, this would have required dynamic modification of the
  76    object class attribute should the attributes not always be present in
  77    entries. For these reasons, alternative object classes are defined in
  78    this document for use by LDAP servers acting as PKIX repositories.
  79
  80 3.  PKIX Repository Objects
  81
  82    The primary PKIX objects to be represented in a repository are:
  83
  84       -  End Entities
  85       -  Certification Authorities (CA)
  86
  87    These objects are defined in RFC 2459.
  88
  89 3.1.  End Entities
  90
  91    For purposes of PKIX schema definition, the role of end entities as
  92    subjects of certificates is the major aspect relevant to this
  93    specification. End entities may be human users, or other types of
  94    entities to which certificates may be issued. In some cases, the
  95    entry for the end entity may already exist and the PKI-specific
  96    information is added to the existing entry. In other cases the entry
  97    may not exist prior to the issuance of a certificate, in which case
  98    the entity adding the certificate may also need to create the entry.
  99    Schema elements used to represent the non PKIX aspects of an entry,
 100    such as the structural object class used to represent organizational
 101    persons, may vary, depending on the particular environment and set of
 102    applications served and are outside the scope of this specification.
 103
 104    The following auxiliary object class MAY be used to represent
 105    certificate subjects:
 106
 107
 108
 109
 110
 111
 112
 113
 114 Boeyen, et al.              Standards Track                     [Page 2]
 115 \f
 116 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 117
 118
 119 pkiUser   OBJECT-CLASS   ::= {
 120    SUBCLASS OF   { top}
 121    KIND          auxiliary
 122    MAY CONTAIN   {userCertificate}
 123    ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
 124
 125 userCertificate    ATTRIBUTE  ::=  {
 126      WITH SYNTAX   Certificate
 127      EQUALITY MATCHING RULE   certificateExactMatch
 128      ID  joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
 129
 130    An end entity may obtain one or more certificates from one or more
 131    Certification Authorities.  The userCertificate attribute MUST be
 132    used to represent these certificates in the directory entry
 133    representing that user.
 134
 135 3.2.  Certification Authorities
 136
 137    As with end entities, Certification Authorities are typically
 138    represented in directories as auxiliary components of entries
 139    representing a more generic object, such as organizations,
 140    organizational units etc. The non PKIX-specific schema elements for
 141    these entries, such as the structural object class of the object, are
 142    outside the scope of this specification.
 143
 144    The following auxiliary object class MAY be used to represent
 145    Certification Authorities:
 146
 147 pkiCA   OBJECT-CLASS   ::= {
 148    SUBCLASS OF   { top}
 149    KIND          auxiliary
 150    MAY CONTAIN   {cACertificate |
 151                   certificateRevocationList |
 152                   authorityRevocationList |
 153                   crossCertificatePair }
 154    ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
 155
 156 cACertificate    ATTRIBUTE  ::=  {
 157      WITH SYNTAX   Certificate
 158      EQUALITY MATCHING RULE   certificateExactMatch
 159      ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
 160
 161 crossCertificatePairATTRIBUTE::={
 162    WITH SYNTAX   CertificatePair
 163    EQUALITY MATCHING RULE certificatePairExactMatch
 164  ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
 165
 166
 167
 168
 169
 170 Boeyen, et al.              Standards Track                     [Page 3]
 171 \f
 172 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 173
 174
 175    The cACertificate attribute of a CA's directory entry shall be used
 176    to store self-issued certificates (if any) and certificates issued to
 177    this CA by CAs in the same realm as this CA.
 178
 179    The forward elements of the crossCertificatePair attribute of a CA's
 180    directory entry shall be used to store all, except self-issued
 181    certificates issued to this CA.  Optionally, the reverse elements of
 182    the crossCertificatePair attribute, of a CA's directory entry may
 183    contain a subset of certificates issued by this CA to other CAs.
 184    When both the forward and the reverse elements are present in a
 185    single attribute value, issuer name in one certificate shall match
 186    the subject name in the other and vice versa, and the subject public
 187    key in one certificate shall be capable of verifying the digital
 188    signature on the other certificate and vice versa.
 189
 190    When a reverse element is present, the forward element value and the
 191    reverse element value need not be stored in the same attribute value;
 192    in other words, they can be stored in either a single attribute value
 193    or two attribute values.
 194
 195    In the case of V3 certificates, none of the above CA certificates
 196    shall include a basicConstraints extension with the cA value set to
 197    FALSE.
 198
 199    The definition of realm is purely a matter of local policy.
 200
 201       certificateRevocationListATTRIBUTE::={
 202            WITH SYNTAX  CertificateList
 203            EQUALITY MATCHING RULE certificateListExactMatch
 204         ID joint-iso-ccitt(2) ds(5) attributeType(4)
 205            certificateRevocationList(39)}
 206
 207    The certificateRevocationList attribute, if present in a particular
 208    CA's entry, contains CRL(s) as defined in RFC 2459.
 209
 210       authorityRevocationListATTRIBUTE::={
 211          WITH SYNTAX   CertificateList
 212          EQUALITY MATCHING RULE certificateListExactMatch
 213        ID joint-iso-ccitt(2) ds(5) attributeType(4)
 214           authorityRevocationList(38)}
 215
 216    The authorityRevocationList attribute, if present in a particular
 217    CA's entry, includes revocation information regarding certificates
 218    issued to other CAs.
 219
 220
 221
 222
 223
 224
 225
 226 Boeyen, et al.              Standards Track                     [Page 4]
 227 \f
 228 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 229
 230
 231 3.2.1.  CRL distribution points
 232
 233    CRL distribution points are an optional mechanism, specified in RFC
 234    2459, which MAY be used to distribute revocation information.
 235
 236    A patent statement regarding CRL distribution points can be found at
 237    the end of this document.
 238
 239    If a CA elects to use CRL distribution points, the following object
 240    class is used to represent these.
 241
 242  cRLDistributionPoint   OBJECT-CLASS::= {
 243     SUBCLASS OF     { top }
 244     KIND            structural
 245     MUST CONTAIN    { commonName }
 246     MAY CONTAIN     { certificateRevocationList |
 247                       authorityRevocationList |
 248                       deltaRevocationList }
 249     ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
 250
 251    The certificateRevocationList and authorityRevocationList attributes
 252    are as defined above.
 253
 254    The commonName attribute and deltaRevocationList attributes, defined
 255    in X.509, are duplicated below.
 256
 257       commonName   ATTRIBUTE::={
 258          SUBTYPE OF     name
 259          WITH SYNTAX   DirectoryString
 260          ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
 261
 262       deltaRevocationList        ATTRIBUTE ::= {
 263          WITH SYNTAX             CertificateList
 264          EQUALITY MATCHING RULE  certificateListExactMatch
 265          ID joint-iso-ccitt(2) ds(5) attributeType(4)
 266             deltaRevocationList(53) }
 267
 268 3.2.2.  Delta CRLs
 269
 270    Delta CRLs are an optional mechanism, specified in RFC 2459, which
 271    MAY be used to enhance the distribution of revocation information.
 272
 273    If a CA elects to use delta CRLs, the following object class is used
 274    to represent these.
 275
 276
 277
 278
 279
 280
 281
 282 Boeyen, et al.              Standards Track                     [Page 5]
 283 \f
 284 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 285
 286
 287       deltaCRL   OBJECT-CLASS::= {
 288          SUBCLASS OF     { top }
 289          KIND            auxiliary
 290          MAY CONTAIN     { deltaRevocationList }
 291          ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
 292
 293 4.  Security Considerations
 294
 295    Since the elements of information which are key to the PKI service
 296    (certificates and CRLs) are both digitally signed pieces of
 297    information, no additional integrity service is REQUIRED.
 298
 299    Security considerations with respect to retrieval, addition,
 300    deletion, and modification of the information supported by this
 301    schema definition are addressed in RFC 2559.
 302
 303 5.  References
 304
 305    [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
 306         Protocol", RFC 1777, March 1995.
 307
 308    [2]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
 309         Levels", BCP 14, RFC 2119, March 1997.
 310
 311 6  Intellectual Property Rights
 312
 313    The IETF has been notified of intellectual property rights claimed in
 314    regard to some or all of the specification contained in this
 315    document.  For more information consult the online list of claimed
 316    rights.
 317
 318    The IETF takes no position regarding the validity or scope of any
 319    intellectual property or other rights that might be claimed to
 320    pertain to the implementation or use of the technology described in
 321    this document or the extent to which any license under such rights
 322    might or might not be available; neither does it represent that it
 323    has made any effort to identify any such rights. Information on the
 324    IETF's procedures with respect to rights in standards-track and
 325    standards-related documentation can be found in BCP-11. Copies of
 326    claims of rights made available for publication and any assurances of
 327    licenses to be made available, or the result of an attempt made to
 328    obtain a general license or permission for the use of such
 329    proprietary rights by implementors or users of this specification can
 330    be obtained from the IETF Secretariat.
 331
 332
 333
 334
 335
 336
 337
 338 Boeyen, et al.              Standards Track                     [Page 6]
 339 \f
 340 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 341
 342
 343 7.  Authors' Addresses
 344
 345    Sharon Boeyen
 346    Entrust Technologies Limited
 347    750 Heron Road
 348    Ottawa, Ontario
 349    Canada K1V 1A7
 350
 351    EMail: sharon.boeyen@entrust.com
 352
 353
 354    Tim Howes
 355    Netscape Communications Corp.
 356    501 E. Middlefield Rd.
 357    Mountain View, CA 94043
 358    USA
 359
 360    EMail: howes@netscape.com
 361
 362
 363    Patrick Richard
 364    Xcert Software Inc.
 365    Suite 1001, 701 W. Georgia Street
 366    P.O. Box 10145
 367    Pacific Centre
 368    Vancouver, B.C.
 369    Canada V7Y 1C6
 370
 371    EMail: patr@xcert.com
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Boeyen, et al.              Standards Track                     [Page 7]
 395 \f
 396 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 402
 403    This document and translations of it may be copied and furnished to
 404    others, and derivative works that comment on or otherwise explain it
 405    or assist in its implementation may be prepared, copied, published
 406    and distributed, in whole or in part, without restriction of any
 407    kind, provided that the above copyright notice and this paragraph are
 408    included on all such copies and derivative works.  However, this
 409    document itself may not be modified in any way, such as by removing
 410    the copyright notice or references to the Internet Society or other
 411    Internet organizations, except as needed for the purpose of
 412    developing Internet standards in which case the procedures for
 413    copyrights defined in the Internet Standards process must be
 414    followed, or as required to translate it into languages other than
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assigns.
 419
 420    This document and the information contained herein is provided on an
 421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 426
 427 Acknowledgement
 428
 429    Funding for the RFC Editor function is currently provided by the
 430    Internet Society.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Boeyen, et al.              Standards Track                     [Page 8]
 451 \f