Requirements for Data Validation and Certification Services

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 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.

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.

This section gives some examples workflows where data certification services and assertions by trusted third parties might be used, as a way of motivating the subsequent requirements. 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. 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. 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. 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. 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. 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.

This sections describes some concrete scenarios based on the use cases introduced in the previous section.

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 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.

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. 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.

This section describes some of technical requirements associated with certification services

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.

Secondarily, there should be protocols for requesting services, monitoring the progress of the service, participating in services that require contemporaneous participation, cancelling ongoing services.

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.

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.)

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.

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 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.

Thanks to members of the LTANS mailing list for review of earlier drafts and many suggestions.