rfc3029.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,647 行 · 第 1/5 页

Network Working Group                                           C. Adams
Request for Comments: 3029                          Entrust Technologies
Category: Experimental                                      P. Sylvester
                                     EdelWeb SA - Groupe ON-X Consulting
                                                            M. Zolotarev
                                      Baltimore Technologies Pty Limited
                                                           R. Zuccherato
                                                    Entrust Technologies
                                                           February 2001


                Internet X.509 Public Key Infrastructure
           Data Validation and Certification Server Protocols

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a general Data Validation and Certification
   Server (DVCS) and the protocols to be used when communicating with
   it.  The Data Validation and Certification Server is a Trusted Third
   Party (TTP) that can be used as one component in building reliable
   non-repudiation services.

   Useful Data Validation and Certification Server responsibilities in a
   PKI are to assert the validity of signed documents, public key
   certificates, and the possession or existence of data.

   Assertions created by this protocol are called Data Validation
   Certificates (DVC).

   We give examples of how to use the Data Validation and Certification
   Server to extend the lifetime of a signature beyond key expiry or
   revocation and to query the Data Validation and Certification Server
   regarding the status of a public key certificate.  The document
   includes a complete example of a time stamping transaction.






Adams, et al.                 Experimental                      [Page 1]

RFC 3029                     DVCS Protocols                February 2001


Table of Contents

   1. Introduction .................................................  2
   2. Services provided by DVCS ....................................  4
    2.1 Certification of Possession of Data ........................  4
    2.2 Certification of Claim of Possession of Data ...............  4
    2.3 Validation of Digitally Signed Documents ...................  4
    2.4 Validation of Public Key Certificates ......................  5
   3. Data Certification Server Usage and Scenarii .................  5
   4. Functional Requirements for DVCS .............................  7
   5. Data Certification Server Transactions .......................  7
   6. Identification of the DVCS ...................................  8
   7. Common Data Types ............................................  9
    7.1 Version ....................................................  9
    7.2 DigestInfo ................................................. 10
    7.3. Time Values ............................................... 10
    7.4. PKIStatusInfo ............................................. 11
    7.5. TargetEtcChain ............................................ 11
    7.6. DVCSRequestInformation .................................... 12
    7.7. GeneralName and GeneralNames .............................. 13
   8. Data Validation and Certification Requests ................... 13
   9. DVCS Responses ............................................... 17
    9.1. Data Validation Certificate ............................... 18
    9.2. DVCS Error Notification ................................... 21
   10. Transports .................................................. 22
    10.1 DVCS Protocol via HTTP or HTTPS ........................... 22
    10.2 DVCS Protocol Using Email ................................. 22
   11. Security Considerations ..................................... 23
   12. Patent Information .......................................... 23
   13. References .................................................. 25
   14. Authors' Addresses .......................................... 26
   APPENDIX A - PKCS #9 Attribute .................................. 27
   APPENDIX B - Signed document validation ......................... 27
   APPENDIX C - Verifying the Status of a Public Key Certificate ... 28
   Appendix D - MIME Registration .................................. 30
   Appendix E - ASN.1 Module using 1988 Syntax ..................... 31
   Appendix F - Examples ........................................... 34
   Appendix G - Acknowledgements ................................... 50
   Full Copyright Statement ........................................ 51

1. Introduction

   This document is the result of work that has been proposed and
   discussed within the IETF PKIX working group.  The authors and some
   members of the group felt that promoting the rather new concepts into
   the standards process seemed premature.  The concepts presented have
   been stable for some time and partially implemented.  It was agreed
   that a publication as experimental RFC was an appropriate means to



Adams, et al.                 Experimental                      [Page 2]

RFC 3029                     DVCS Protocols                February 2001


   get a stable reference document to permit other implementations to
   occur.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

   A Data Validation and Certification Server (DVCS) is a Trusted Third
   Party (TTP) providing data validation services, asserting correctness
   of digitally signed documents, validity of public key certificates,
   and possession or existence of data.

   As a result of the validation, a DVCS generates a Data Validation
   Certificate (DVC).  The data validation certificate can be used for
   constructing evidence of non-repudiation relating to the validity and
   correctness of an entity's claim to possess data, the validity and
   revocation status of an entity's public key certificate and the
   validity and correctness of a digitally signed document.

   Services provided by a DVCS do not replace the usage of CRLs and OCSP
   for public key certificate revocation checking in large open
   environments, due to concerns about the scalability of the protocol.

   It should be rather used to support non-repudiation or to supplement
   more traditional services concerning paperless document environments.
   The presence of a data validation certificate supports
   non-repudiation by providing evidence that a digitally signed
   document or public key certificate was valid at the time indicated in
   the DVC.

   A DVC validating a public key certificate can for example be used
   even after the public key certificate expires and its revocation
   information is no longer or not easily available.  Determining the
   validity of a DVC is assumed to be a simpler task, for example, if
   the population of DVCS is significantly smaller than the population
   of public key certificate owners.

   An important feature of the protocol is that DVCs can be validated by
   using the same protocol (not necessarily using the same service), and
   the validity of a signed document, in particular a DVC, can also be
   determined by means other than by verifying its signature(s), e.g.,
   by comparing against an archive.

   The production of a data validation certificate in response to a
   signed request for validation of a signed document or public key
   certificate also provides evidence that due diligence was performed
   by the requester in validating a digital signature or public key
   certificate.



Adams, et al.                 Experimental                      [Page 3]

RFC 3029                     DVCS Protocols                February 2001


   This document defines the use of digital signatures to insure the
   authenticity of documents and DVCs, and uses a corresponding
   terminology; the use of other methods to provide evidence for
   authenticity is not excluded, in particular it is possible to replace
   a SignedData security envelope by another one.

2. Services provided by DVCS

   The current specification defines 4 types of validation and
   certification services:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

   A DVCS MUST support at least a subset of these services.  A DVCS may
   support a restricted vsd service allowing to validate data validation
   certificates.

   On completion of each service, the DVCS produces a data validation
   certificate - a signed document containing the validation results and
   trustworthy time information.

2.1 Certification of Possession of Data

   The Certification of Possession of Data service provides evidence
   that the requester possessed data at the time indicated and that the
   actual data were presented to the Data Validation Server.

2.2 Certification of Claim of Possession of Data

   The Certification of Claim of Possession of Data service is similar
   to the previous one, except that the requester does not present the
   data itself but a message digest.

2.3 Validation of Digitally Signed Documents

   The Validation of Digitally Signed Document service is used when
   validity of a signed document is to be asserted.

   The DVCS verifies all signatures attached to the signed document
   using all appropriate status information and public key certificates.
   The DVCS verifies the mathematical correctness of all signatures
   attached to the document and also checks whether the signing entities
   can be trusted, for example by validating the full certification path
   from the signing entities to a trusted point (e.g., the DVCS's CA, or
   the root CA in a hierarchy).



Adams, et al.                 Experimental                      [Page 4]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS may be able to rely on relevant CRLs or may need to
   supplement this with access to more current status information from
   the CAs for example by accessing an OCSP service, a trusted directory
   service, or other DVCS services.

   The DVCS will perform verification of all signatures attached to the
   signed document.  A failure of the verification of one of the
   signatures does not necessarily result in the failure of the entire
   validation, and vice versa, a global failure may occur if the
   document has an insufficient number of signatures.

2.4 Validation of Public Key Certificates

   The Validation of Public Key Certificates service is used to verify
   and assert the validity (according to [RFC2459]) of one or more
   public key certificates at the specified time.

   When verifying a public key certificate, the DVCS verifies that the
   certificate included in the request is a valid certificate and
   determines its revocation status at a specified time.  DVS checks the
   full certification path from the certificate's issuer to a trusted
   point.  Again, the DVCS MAY be able to rely on external information
   (CRL, OCSP, DVCS).

3. Data Certification Server Usage and Scenarii.

   It is outside the scope of this document to completely describe
   different operational scenarii or usages for DVCS.

   See Appendix B and C for a set of some basic examples and use cases.

   The Validate Signed Document service can be used to support non-
   repudiation services, to allow use of the signed document beyond
   public key certificate revocation or expiry, or simply to delegate
   signature validation to a trusted central (company wide) service.

   The Validate Public Key Certificate service can be used when timely
   information regarding a certificate's revocation status is required
   (e.g., high value funds transfer or the compromise of a highly
   sensitive key) or when evidence supporting non-repudiation is
   required.

   A data validation certificate may be used to simplify the validation
   of a signature beyond the expiry or subsequent revocation of the
   signing certificate: a Data validation certificate used as an
   authenticated attribute in a signature includes an additional





Adams, et al.                 Experimental                      [Page 5]

RFC 3029                     DVCS Protocols                February 2001


   assertion about the usability of a certificate that was used for
   signing.  In order to validate such a signature it may be sufficient
   to only validate the data validation certificate.

   A DVCS may include additional key exchange certificates in a data
   validation certificate to validate a key exchange certificate in
   order to provide to an application a set of additional authorised
   recipients for which a session key should also be encrypted.  This
   can be used for example to provide central management of a company
   wide recovery scheme.  Note, that the additional certificates may not
   only depend on the requested certificate, but also on the requester's
   identity.

   The Certification of Claim of Possession of Data service is also
   known as time stamping.

   The Certification of Possession of Data service can be used to assert
   legal deposit of documents, or to implement archival services as a
   trusted third party service.

   The Data Validation and Certification Server Protocols can be used in
   different service contexts.  Examples include company-wide
   centralised services (verification of signatures, certification of
   company certificates), services to cooperate in a multi-organization
   community, or general third party services for time stamping or data
   archival.

   An important application of DVCS is an enterprise environment where
   all security decisions are based on company wide rules.  A company
   wide DVCS service can be used to delegate all technical decisions
   (e.g., path validation, trust configuration) to a centrally managed
   service.

   In all cases, the trust that PKI entities have in the Data Validation
   and Certification Server is transferred to the contents of the Data
   Validation Certificate  (just as trust in a CA is transferred to the
   public key certificates that it issues).

   A DVCS service may be combined with or use archiving and logging
   systems, in order to serve as a strong building block in non-
   repudiation services.  In this sense it can be regarded as an
   Evidence Recording Authority [ISO-NR].