Internet DRAFT - draft-ietf-ltans-notareqs
draft-ietf-ltans-notareqs
Network Working Group A. Schmidt
Internet-Draft Fraunhofer SIT
Expires: June 23, 2006 T. Gondrom
Open Text Corporation
L. Masinter
Adobe Systems
December 20, 2005
Requirements for Data Validation and Certification Services
draft-ietf-ltans-notareqs-03.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 June 23, 2006.
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 June 23, 2006 [Page 1]
Internet-Draft Data Certification Requirements December 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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. Logging of proceedings . . . . . . . . . . . . . . . . . . 8
5.4. Long-term archives of records . . . . . . . . . . . . . . 9
5.5. Validation of Digital Signatures and X.509 certificates . 9
6. Operational Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Schmidt, et al. Expires June 23, 2006 [Page 2]
Internet-Draft Data Certification Requirements December 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.
Mitigating human error is a prime motivation to look for standardized
methods which lend themselves to automation. In particular in
complex scenarios the use of certification services can increase
Schmidt, et al. Expires June 23, 2006 [Page 3]
Internet-Draft Data Certification Requirements December 2005
trust in and the probative force of certified documents.
3. Use cases
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.
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;
Schmidt, et al. Expires June 23, 2006 [Page 4]
Internet-Draft Data Certification Requirements December 2005
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.
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:
Schmidt, et al. Expires June 23, 2006 [Page 5]
Internet-Draft Data Certification Requirements December 2005
((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.
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
Schmidt, et al. Expires June 23, 2006 [Page 6]
Internet-Draft Data Certification Requirements December 2005
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.
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
Schmidt, et al. Expires June 23, 2006 [Page 7]
Internet-Draft Data Certification Requirements December 2005
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 to
authenticate the certified assertion. Additionally, the identity,
role, and authorisation of the certifier can be of importance, e.g.,
notary public, authorised translator, or public official. Attribute
certificates could be used in conjunction with object identifiers to
satisfy this requirement. The appropriate credentials are determined
by the use-case.
To fix the semantic connection to the application context, the
assertion of the service must qualify its meaning. That is, the
purpose of the certification is to be noted correctly, in accordance
with the intended use of the target documents and certifications.
Only this enables the verification of the correctness of operations
at later times.
To be specific, consider the case of general transformations
including format conversions, partial copies, and even authorized
translations. There, the assertion is that of a certain agreement of
contents between original and certified target data. The required
kind and degree of agreement must be made explicit.
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. Logging of proceedings
The ability to re-trace the certified events is crucial to the trust
in certification services. To enable such forensic inspection of the
proceedings carried out, the certification service should keep a log
or protocol of them. This log, or an excerpt thereof, should be
included in the signed assertion. The integrity of the log must be
maintained during the operation of the service. The log should be
detailed and explicit enough to allow for the re-tracing of the
certified events independently of the certification service.
Schmidt, et al. Expires June 23, 2006 [Page 8]
Internet-Draft Data Certification Requirements December 2005
5.4. 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.5. 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.) The details of a verification policy used by the
certification service should be determined by the use case.
It should be noted that signer authentication of handwritten
signatures is hardly ever done in practice. For instance in the case
of contract notarization the problem is resolved by the physical
presence of the signers.
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
Schmidt, et al. Expires June 23, 2006 [Page 9]
Internet-Draft Data Certification Requirements December 2005
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.
In many cases personal and other data must be collected in the course
of operation of a certification service. Some times it is necessary
to keep permanent records of such data for later inspection. In any
such case, personal data should be disclosed only to authorised
persons or entities. Personal data should be encrypted wherever
possible during and after operation of the service.
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.
Schmidt, et al. Expires June 23, 2006 [Page 10]
Internet-Draft Data Certification Requirements December 2005
Authors' Addresses
Andreas U. Schmidt
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
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
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 June 23, 2006 [Page 11]
Internet-Draft Data Certification Requirements December 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 June 23, 2006 [Page 12]
