rfc3379.txt

RFC 的详细文档！

7.3. Revocation Requirements

   Revocation information might be obtained through CRLs, delta CRLs or
   OCSP responses.  Certificate revocation requirements are specified in
   terms of checks required on the end-entity certificate and CA
   certificates.

   Revocation requirements for the end-entity certificate may not be the
   same as the requirements for the CA certificates.  For example, an
   OCSP response may be needed for the end-entity certificate while CRLs
   may be sufficient for the CA certificates.

   The validation policy MUST specify the source of revocation
   information:

   - full CRLs (or full Authority Revocation Lists) have to be
     collected.

   - OCSP responses, using [OCSP], have to be collected.

   - delta CRLs and the relevant associated full CRLs (or full Authority
     Revocation Lists) are to be collected.

   - any available revocation information has to be collected.

   - no revocation information need be collected.

7.4. End-entity Certificate Specific Requirements

   The validation policy might require the end-entity certificate to
   contain specific extensions with specific types or values (it does
   not matter whether they are critical or non-critical).  For example,
   the validation policy might require an end-entity certificate that
   contains an electronic mail address (either in the rfc822 subject alt
   name or in the emailAddress naming attribute in the subject name).

8. Path Discovery Policy

   A path discovery policy is a set of rules against which the discovery
   of a certification path is performed.  A path discovery policy is a
   subset of a validation policy.  A path discovery policy MAY either be
   a reference to a validation policy or contain only some major
   elements from a validation policy, such as the trust anchors.

   Since the DPD client is "PKI aware", it can locally apply additional
   selection criteria to the certification paths returned by the server.
   Thus, a simpler policy can be defined and used for path discovery.




Pinkas & Housley             Informational                     [Page 11]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


8.1. Components for a Path Discovery Policy

   The path discovery policy includes certification path requirements,
   revocation requirements, and end-entity certificate specific
   requirements.  These requirements are the same as those specified in
   sections 7.2, 7.3, and 7.4, respectively.

9. Security Considerations

   A DPV client must trust a DPV server to provide the correct answer.
   However, this does not mean that all DPV clients will trust the same
   DPV servers.  While a positive answer might be sufficient for one DPV
   client, that same positive answer will not necessarily convince
   another DPV client.

   Other clients may trust their own DPV servers, or they might perform
   certification path validation themselves.  DPV clients operating
   under an organizational validation policy must ensure that each of
   the DPV servers they trust is operating under that organizational
   validation policy.

   When no policy reference is present in the DPV request, the DPV
   client ought to verify that the policy selected by the DPV server is
   appropriate.

   The revocation status information is obtained for the validation
   time.  In case of a digital signature, it is not necessarily
   identical to the time when the private key was used.  The validation
   time ought to be adjusted by the DPV client to compensate for:

   1) time for the end-entity to realize that its private key has been
      or could possibly be compromised, and/or

   2) time for the end-entity to report the key compromise, and/or

   3) time for the revocation authority to process the revocation
      request from the end-entity, and/or

   4) time for the revocation authority to update and distribute the
      revocation status information.

10. Acknowledgments

   These requirements have been refined after some valuable inputs from
   Trevor Freeman, Paul Hoffman, Ambarish Malpani, Mike Myers, Tim Polk,
   and Peter Sylvester.





Pinkas & Housley             Informational                     [Page 12]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


11. References

11.1. Normative References

   [PKIX-1]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 3280, April 2002.

   [OCSP]     Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

11.2. Informative References

   [ES-F]     Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
              Formats for long term electronic signatures", RFC 3126,
              September 2001.

   [ES-P]     Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
              Policies", RFC 3125, September 2001.

   [ESS]      Hoffman, P., "Enhanced Security Services for S/MIME", RFC
              2634, June 1999.

   [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
              Technology - Open Systems Interconnection: The Directory:
              Authentication Framework," 1997 edition.

   [FTP&HTTP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure. Operational Protocols: FTP and HTTP", RFC
              2585, May 1999.

   [LDAP]     Boeyen, S., Howes, T. and P. Richard, "Internet X.509
              Public Key Infrastructure Operational Protocols LDAPv2",
              RFC 2559, April 1999.
















Pinkas & Housley             Informational                     [Page 13]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


12. Authors' Addresses

   Denis Pinkas
   Bull
   Rue Jean-Jaures - BP 68
   78340 Les Clayes-sous-Bois
   FRANCE

   EMail: [e-mail]


   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: [e-mail]

































Pinkas & Housley             Informational                     [Page 14]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Pinkas & Housley             Informational                     [Page 15]