Network Working Group A. Schmidt Internet-Draft Fraunhofer SIT Expires: December 22, 2005 T. Gondrom Open Text Corporation L. Masinter Adobe Systems June 20, 2005 Requirements for Data Validation and Certification Services draft-ietf-ltans-notareqs-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. The data being validated may correspond to assertions about real-world facts Schmidt, et al. Expires December 22, 2005 [Page 1] Internet-Draft Data Certification Requirements June 2005 or events. This document establishes the need for components to be used in addition to or in conjunction with long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Requirements . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Specific workflows . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Record transactions . . . . . . . . . . . . . . . . . . . 5 4.2 Archiving signed document . . . . . . . . . . . . . . . . 6 5. Technical Requirements . . . . . . . . . . . . . . . . . . . . 7 5.1 Representations for Assertions . . . . . . . . . . . . . . 7 5.2 Protocols for interaction . . . . . . . . . . . . . . . . 8 5.3 Long-term archives of records . . . . . . . . . . . . . . 8 5.4 Validation of Digital Signatures and X.509 certificates . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 11 Schmidt, et al. Expires December 22, 2005 [Page 2] Internet-Draft Data Certification Requirements June 2005 1. Introduction In many scenarios, users need to be able to ensure and prove the existance and validity of documents and data, including digitally signed data, in a common and reproducible way, over a long period of time. A long-term archive service[3] may provide assurances about the integrity of data and past validity of digital signatures. However, additional mechanisms are required, in real workflows, to provide the technical means to satisfy user requirements. In many circumstances, the documents or data being validated or signed corresponds to assertions about real-world facts or events; for example, a contract or a business record. Usually, the scenarios for long-term validation involve a trusted third party who is willing, over a period of time, to accept data and validate it, or to witness events; the trusted third party offers to subsequently make assertions about those events or data. In many legal jurisdictions, a 'notary' is a person with credentials recognized by that jurisdiction to perform these services, in a way that gives their certification a special legal standing. Indeed, some types of transactions may require an official certification by someone with specific notary credentials. This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. 2. General Requirements It is desirable that the protocols and data structures established be usable by an official notary to provide appropriate assertions for electronic documents. Of course, nothing in a technical document can provide for legal standing of any such assertions. Requirements for data certification services may vary widely across different processes and jurisdictions. For this reason, the technical standards for data certification should provide a common base of mechanisms, useful across jurisdictions and work processes, and the means for extending these to support particular additional workflows. 3. Use cases This section gives some examples workflows where data certification services and assertions by trusted third parties might be used, as a Schmidt, et al. Expires December 22, 2005 [Page 3] Internet-Draft Data Certification Requirements June 2005 way of motivating the subsequent requirements. record transactions: In the case of an agreement between two (or more) parties, a trusted third party records the transaction, and the fact that all of the parties agreed to the final documents and that all of the necessary information has been provided to all of the involved parties. The trusted third party acts as a witness to the agreement at the time it is made, and, at a later date, may be called upon to attest to the validity of the agreement. This kind of service might be used for a contract between individuals, e.g., a private transfer of ownership of private property, or a public transfer of ownership of land. negotiation support: In some cases, a trusted third party is used during the negotiation of a complex agreement in order to support the mechanisms of coming to the agreement. For example, a trusted third party might gather and store the documents during the course of a negotiation, making it impossible for any party to delete the document or repudiate a partial agreement; there might be time deadlines established for submitting information or approvals, or information may be held back from release until a particular time. For example, this kind of service might be used for the awarding of public contracts based on private bids. certification of copies and conversions: In many cases, a trusted third party or service is used to certify the validity of a transformation or translation of a document from one form to another. Classically, a notary might attest to the validity of a paper copy of a document. The ability to attest to the validity of a wide variety of transformations are important, including the transformation of documents from one electronic format to another, or possibly the validity of conversion between paper and electronic forms. The third party should be able to attest that one document contains the same information as another and the validity of all contained digital signatures and the identity of the signers. record events: In this case, a trusted third party or service is used to document and later provide proof that a certain event has happened. Initially, the service identifies the involved entities and verifies that all necessary preconditions are met. After this, an event or ceremony is held; during the event, the service ensures that all entities understood and received all appropriate information about the event and its consequences. After the event, a record of the event is issued to all of the entities; additional copies are retained for later documentation. administering of oaths: In some cases, the event being recorded is the performance, by an individual, of a particular agreement or 'oath'. The trusted third party is used to document and later provide proof that an individual has made a particular statement or agreement, in a specified ceremony or event. Schmidt, et al. Expires December 22, 2005 [Page 4] Internet-Draft Data Certification Requirements June 2005 evidence management: Transactions between parties over the Internet may have records of those transactions. In general, it is desirable to have services which accept, verify, record, and later provide evidence of those records. In many cases, this may involve creating a certified archive of detailed and signed logs. 4. Specific workflows This sections describes some concrete scenarios based on the use cases introduced in the previous section. 4.1 Record transactions The following example will show the additional benefits of a certification service in the case of private transactions. We start with a basic protocol that achieves, upon completion, a state of mutual non-repudiation between two parties, A and B. Suppose, A wants to offer an electronic contract (contract_A) to B, where "contract_A" means that A has digitally signed the contract with her private key. This is sent as an offer to B: contract_A -> B B, after receiving and accepting contract_A, counter-signs the contract and sends it back to A as an acceptance of A's offer: (contract_A)_B -> A Now, A has to confirm reception of the acceptance. He signs (contract_A)_B and sends it back to B: ((contract_A)_B)_A -> B After that, both parties have a document with at least two signatures, and neither party can succeed in repudiating the validity of the contract. Now let's see what happens when we put a certification service N as a trusted third party between A and B. When B gets the contract from A and accepts it, he signs the contract and sends it to N: (contract_A)_B -> N The certification service confirms receipt of the contract with a signature and sends it to both A and B: ((contract_A)_B)_N -> A, B After that, both parties have a document signed by A, B, and N. Since N is trusted, A and B can be sure that the other party has a contract which is signed by both. We have the same level of trust as in the scenario without the certification service. However, an additional benefit of using a certification service in this case can be the Schmidt, et al. Expires December 22, 2005 [Page 5] Internet-Draft Data Certification Requirements June 2005 archiving of the contract, as may be required by the law for certain types of contracts. In order to allow for N to provide documentation that all necessary information has been provided to both parties, the scenario can be extended as follows: When A and B get the confirmation ((contract_A)_B)_N from N, both A and B send an acknowledgement to N: ack_A -> N ack_B -> N After N received the two acknowledgements he sends a notification to both A and B that confirms that the transaction is completed: not_N -> A, B For both ack_A/B and not_N it suffices to contain (sufficiently secure) hash values of the pertaining original documents, and the same is true for the third message sent from N in the protocol above, but not for the second one, if the contract is to be archived by N. The utility of certification services in these generic scenarios is twofold: They can accomplish the fulfillment of technical requirements, e.g., archiving of transaction records, which may in turn be entailed by legal requirements. And they can be instrumental in the fulfillment of genuine legal requirements, like documentation that all necessary information has been provided to all involved parties. 4.2 Archiving signed document A signed document enters an archive. Initially, the signature is validated (there is not much point to archive a document with invalid signatures, although such scenarios are also possible). We need is a fixation in time that signature (and document) existed at some point in time (the archiving time). Providing evidence for a document is not a problem; a signature there are some sequence issues. Preserving signatures is based on reference information and evidence record. Let's start with T1, when a CRL has been issued and the next time the CRL is issued is marked with T5. Now we need to collect some reference information (certificates, CRLs, etc.), validate the signature and pack everything together before creating the evidence record (timestamp). At time T2 a timestamp is requested for collected data following by timestamp issued at T3. Until T5 we have enough time to revoke the certificate related to digital signature archived, which happens at T4 and we can end up with archived invalid signature, although it was submitted to the archive before revocation happened. Schmidt, et al. Expires December 22, 2005 [Page 6] Internet-Draft Data Certification Requirements June 2005 The problem with CRLs is that they might not be synchronized with revocation mechanisms and there is no real information whether a signature is valid or not at specific point in time. In theory CRLs should be issued immediately after a certificate is revoked, but in practice things are not the same, since the procedure itself already has some timeframe (the ideal solution is to stop the time during the validation process). Now, there are options to use more than one evidence record for a single data (signature) but such procedures might get overall concept very complicated and bulky, especially when performing procedures over groups of data. The archive package should contain the CRL used to verify the transaction. That coupled with other times will show when the transaction was received and processed. When speed is of not essence, the relying party can always wait for a CRL issued after the transaction was received to verify. This will ensure that the certificate was not revoked in the interim. Relying party can use the later CRL for archiving the transaction. An evidence record is relative to a single time T1, e.g. the time of submission to the archive. Retroactive revocation would need to be considered before committing the data to an archive and initiating an evidence record. Even if a CRL were issued immediately when a cert was revoked, it's revocation time might be before T1. It is unlikely that retroactive revocation applied after several periodic refresh operations (which should be relatively infrequent) at time T4 should invalidate a signature generated at, or before, time T1. 5. Technical Requirements This section describes some of technical requirements associated with certification services 5.1 Representations for Assertions The primary technical requirement is for a data structure that can represent the assertion, by the certification service, that a particular service has been performed. The data structure should include the identity (as known) of the participants, the credentials of the certification service and its operator, the date and time that the service was performed, and other information relevant to the acknowledgement of the service. The data structure should be signed by the certification service. Schmidt, et al. Expires December 22, 2005 [Page 7] Internet-Draft Data Certification Requirements June 2005 5.2 Protocols for interaction Secondarily, there should be protocols for requesting services, monitoring the progress of the service, participating in services that require contemporaneous participation, cancelling ongoing services. 5.3 Long-term archives of records Some services also require the certification service to maintain a long-term archive of records of events that it has certified; the users of a certification service may request operations that cause archived certificates to be accessed, forwarded, or possibly even deleted. 5.4 Validation of Digital Signatures and X.509 certificates One way in which participants in a transaction, negotation, or event conducted over the Internet signal their intentions is through the use of digital signatures. Digital signatures may use X.509 certificates to assert the validity of the public key of a named participant in the transaction. A validation service should be able to represent the fact of its testing the validity of digital signatures, including the non-revocation of X.509 certificates used within those signatures, as part of validating a transaction. This way it might provide proof that the signatures attached to a given document had been verified at a given date (different from the signature date.) 6. Operational Considerations Data validation and certification services may have strong performance and scalability requirements. A certification service must be able to work efficiently even for large amounts of data objects and requests. In order to limit expenses and to achieve high performance, the involvement of other trusted third parties should be minimized. 7. Security Considerations Trust is the principal asset of a certification service. The implementation of such a service must be very careful so that no data integrity can be lost or manipulation of the system can be done. The protocols and data structures described in this document are primarily intended to be useful to increase the trustworthiness of networked transactions. As such, their primary value is in Schmidt, et al. Expires December 22, 2005 [Page 8] Internet-Draft Data Certification Requirements June 2005 resistance to any imaginable security threats. The nature of the threats for long-term services are signficantly greater and more difficult to protect against. In particular, it is necessary to design protocols and data structures so that even if currently acceptable secure one-way hash algorithms and encryption algorithms are compromised, either through advancements in analysis of their algorithms or through increased computational power and novel computing architectures, that the overall security of the application can be protected. 8. Acknowledgements Thanks to members of the LTANS mailing list for review of earlier drafts and many suggestions. 9. Informative References [1] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", RFC 3029, February 2001. [2] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [3] Wallace, C., "Long-Term Archive Service Requirements", draft-ietf-ltans-reqs-03 (work in progress), October 2004. [4] Brandner, R., "Evidence Record Syntax (ERS)", draft-ietf-ltans-ers-02 (work in progress), April 2005. Authors' Addresses Andreas U. Schmidt Fraunhofer SIT Dolivostrasse 15 Darmstadt 64293 Germany Phone: +49 (6151) 869 60 227 Fax: +49 (6151) 869 704 Email: Andreas.U.Schmidt@sit.fraunhofer.de URI: http://www.math.uni-frankfurt.de/~aschmidt Schmidt, et al. Expires December 22, 2005 [Page 9] Internet-Draft Data Certification Requirements June 2005 Tobias Gondrom Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 Grasbrunn, Munich D-85630 Germany Phone: +49 (0) 89 4629-1816 Fax: +49 (0) 89 4629-33-1816 Email: tobias.gondrom@opentext.com Larry Masinter Adobe Systems 345 Park Ave San Jose, CA 95110 US Phone: +1 408 536 3024 Email: LMM@acm.org URI: http://larry.masinter.net Schmidt, et al. Expires December 22, 2005 [Page 10] Internet-Draft Data Certification Requirements June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schmidt, et al. Expires December 22, 2005 [Page 11]