home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2587.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  15.2 KB  |  452 lines
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  452.