rfc2587.txt

RFC 的详细文档！


RFC 2587                   PKIX LDAPv2 Schema                  June 1999


3.2.1.  CRL distribution points

   CRL distribution points are an optional mechanism, specified in 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 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) }

3.2.2.  Delta CRLs

   Delta CRLs are an optional mechanism, specified in RFC 2459, which
   MAY be used to enhance the 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 }
         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
   information, no additional integrity service is REQUIRED.

   Security considerations with respect to retrieval, addition,
   deletion, and modification of the information supported by this
   schema definition are addressed in RFC 2559.

5.  References

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

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

6  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the 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: [e-mail]


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

   EMail: [e-mail]


   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6

   EMail: [e-mail]






















Boeyen, et al.              Standards Track                     [Page 7]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   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]