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]. Adams, et al. Experimental [Page 6] RFC 3029 DVCS Protocols February 2001 4. Functional Requirements for DVCS The DVCS MUST 1. provide a signed response in the form of a data validation certificate to the requester, as defined by policy, or an error response. The DVCS service definition and the policy define how much information that has been used by the DVCS to generate the response will be included in a data validation certificate, e.g., public key certificates, CRLs, and responses from other OCSP servers, DVCS, or others. 2. indicate in the data validation certificate whether or not the signed document, the public key certificate(s), or the data were validated, and, if not, the reason why the verification failed. 3. include a strictly monotonically increasing serial number in each data validation certificate. 4. include a time of day value or a time stamp token into each data validation certificate. 5. sign each data certification token using a key that has been certified with a dvcs signing extended key purpose, and include a reference to this certificate as a signed attribute in the signature. 6. check the validity of its own signing key and certificate before delivering data