Long-term Archive And Notary C. Wallace
Services (LTANS) Orion Security Solutions
Internet-Draft U. Pordesch
Expires: November 1, 2004 Fraunhofer Gesellschaft
R. Brandner
InterComponentWare AG
May 3, 2004
Long term archive service requirements
draft-ietf-ltans-reqs-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 November 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
In many scenarios, users need to be able to ensure and prove the
existence and integrity of data, especially digitally signed data, in
a common and reproducible way over an arbitrarily long period. This
document specifies the technical requirements for a long-term archive
service to support such scenarios.
Wallace, et al. Expires November 1, 2004 [Page 1]
Internet-Draft Long term archive service requirements May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 7
4. Technical Requirements . . . . . . . . . . . . . . . . . . . . 8
4.1 Enable submission,retrieval and deletion . . . . . . . . . 8
4.2 Provide evidence records . . . . . . . . . . . . . . . . . 9
4.3 Support Demonstration of Data Integrity . . . . . . . . . 9
4.4 Operate per a long-term archive policy . . . . . . . . . . 9
4.5 Data confidentiality . . . . . . . . . . . . . . . . . . . 10
4.6 Data and evidence transferability . . . . . . . . . . . . 10
4.7 Supporting Groups of Data . . . . . . . . . . . . . . . . 11
5. Operational Considerations . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. Application scenarios . . . . . . . . . . . . . . . . . . . . 16
A.1 Archive service supporting long-term non-repudiation . . . 16
A.2 Pure long-term non-repudiation service . . . . . . . . . . 16
A.3 Long-term Archive Service as part of an internal
network . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.4 Long-term Archive External Service . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Wallace, et al. Expires November 1, 2004 [Page 2]
Internet-Draft Long term archive service requirements May 2004
1. Introduction
Digital data durability is undermined by continual progress and
change on a number of fronts. The useful lifetime of data may exceed
the life span of formats and mechanisms used to store the data. The
lifetime of digitally signed data may exceed the validity periods of
public-key certificates used to verify signatures or the
cryptanalysis period of the cryptographic algorithms used to generate
the signatures. Technical and operational means are required to
mitigate these issues. A solution must address issues such as
storage media lifetime, disaster planning, advances in cryptanalysis
or computational capabilities, changes in software technology and
legal issues.
A long-term archive service aids in the preservation of data over
long periods of time. For example, it might periodically perform
activities to preserve data integrity and the non-reputability of
data existence as well as ensuring the availability of data. Examples
of periodic activities include refreshing timestamps or transferring
data to a new storage medium.
A long-term archive service may be used to support validation of the
existence of documents, or assertions of agreements, originally
asserted with digital signatures. Validation may occur at times in
the future well beyond the validity period of the private key
originally used to generate the signature, or even the validity of
the algorithms available for digital signatures, message digesting or
data encryption.
A long-term archive service may be located within an enterprise
network, communicating with local storage mechanisms and other
applications, or a long-term archive service may be an external
service accessible via internet. A long-term archive service may use
functionality, e.g. time stamping, provided by independent service
providers.
A primary goal of a long-term archive service is to support the
credible assertion of something that is currently asserted at points
well into the future. A long-term archive service may support a
range of applications, including: wills, land records, medical data,
criminal case files, personnel files, contracts. A long-term archive
service may be used by any type of entity, e.g. organizations,
citizens, notaries. Examples of long-term archive service usage by
submitters include:
- A company stores contracts using a third party service
- A hospital stores medical data using an internal service
Wallace, et al. Expires November 1, 2004 [Page 3]
Internet-Draft Long term archive service requirements May 2004
- An individual wants to generate evidence of data possession at a
particular point in time, e.g. for intellectual property purposes
or endorsement of a contract
- A law enforcement officer wants to store criminal data such that
integrity of the data can be demonstrated years later
For each of the above examples, there is a corresponding example
involving retrievers, e.g. a company retrieves a contract in the case
of a dispute or a law enforcement officer assembles information for a
criminal trial.
This document aims to identify the technical requirements for a
long-term archive service. The requirements for long-term
notarization services will be covered by a separate draft.
Wallace, et al. Expires November 1, 2004 [Page 4]
Internet-Draft Long term archive service requirements May 2004
2. Terminology
Arbitrator: Principal for whom the validity of archived data
characteristics, e.g., origin, integrity or time of existence,
must be demonstrated.
Archivation period: The period during which an archived data
object is preserved by a long-term archive service.
Archived data object: Data unit to be preserved by a long-term
archive service.
Archive package: Collection of information including archived data
objects and associated evidence record.
Evidence: Information that may be used to demonstrate the validity
an archived data object or related attestations.
Evidence record: Collectionof evidence compiled for one or more
archived data objects. An evidence record may include
acknowledgements of TAA, timestamps and verification data, such as
public-key certificates, revocation information, trust anchors,
policy details and role information.
Long-term archive policy: A named set of rules that define
operational characteristics of a long-term archive service.
Long-term archive service: See Trusted Archive Authority.
Originator: Principal who produces, and possibly signs, an
archived data object.The Originator does not necessarily have any
relationship with a long-term archive service or any awareness of
an evidence record associated with the archived data object.
Retriever: Principal who retrieves an archived data objects and/or
evidence record from a long-term archive service.
Submitter: Principal who submits data objects for archiving.
Timestamp: A signed attestation generated by a Time Stamping
Authority (TSA) that a data item existed at a certain
time.[RFC3161] specifies a structure for timestamps and a protocol
for communicating with a Timestamp Authority (TSA).
Time Stamping Authority (TSA): A service that generates
timestamps.
Wallace, et al. Expires November 1, 2004 [Page 5]
Internet-Draft Long term archive service requirements May 2004
Trusted Archive Authority (TAA): A service that is responsible for
preserving data for long periods.
Wallace, et al. Expires November 1, 2004 [Page 6]
Internet-Draft Long term archive service requirements May 2004
3. General Principles
A long-term archive service may accept any type of data for
preservation, including digitally signed data, encrypted data, time
stamped data, data that has not been the subject of any cryptographic
processing, textual data or images.
A long-term archive service may preserve archived data objects as
opaque collections of bytes with the primary aim being demonstration
of data integrity.
A long-term archive service does not collect evidence related to the
content of archived data objects.Content-focused operations,
including data format migration or translation, may be performed by a
notary or notarization service.
A long-term archive service stores archived data objects over
arbitrarily long periods of time.
A long-term archive service provides material needed to demonstrate
the existence and integrity of data objects.
Wallace, et al. Expires November 1, 2004 [Page 7]
Internet-Draft Long term archive service requirements May 2004
4. Technical Requirements
This section describes requirements for a long-term archive system.
4.1 Enable submission,retrieval and deletion
4.1.1 Functional Requirements
A long-term archive service must permit clients to perform the
following basic operations:
- submit data
- retrieve data,
- delete data/terminate archivation period.
Submitters must be able to specify an archivation period. It should
be possible to extend the archiving period. Submitters should be able
to specify metadata that, for example, can be used to provide enable
retrievers to render the data correctly.
Following submission, the service must provide a value that can be
used to retrieve the archived data and/or associated evidence. It may
be possible to retrieve archive packages by using a hash value of the
archived data objects.
Deletion requests must be authorized and an authorization policy must
be defined and observed by the long-term archive service (as part of
an archive policy). In some cases, deletion may not involve physical
deletion and instead may simply be an early termination of the
archivation period.
It must be possible to authenticate requests and responses. This may
be accomplished using transport security mechanisms.
The format for the acknowledgements must allow the identification of
the archiving provider.
The format for the acknowledgements must allow the identification of
the participating client.
The acknowledgement of a successful submission should permit the
submitter to verify that the correct data was received by the service
for preservation, e.g. the acknowledgement could include an index, a
signature or a timestamp obtained for the archived data object.
4.1.2 Rationale
Submission, retrieval and deletion of archived data are necessary
Wallace, et al. Expires November 1, 2004 [Page 8]
Internet-Draft Long term archive service requirements May 2004
basic functions of a long-term archive service.
4.2 Provide evidence records
4.2.1 Functional Requirements
A long-term archive service must be capable of providing evidence
records to support the long-term non-repudiation of data, e.g. in the
case of legal disputes.
It must be possible to submit data along with previously generated
evidence, i.e. to support transfer of data from one archive to
another. Submitters must be able to specify metadata that, for
example, can be used to provide enable retrievers to render the data
correctly.
4.2.2 Rationale
Supporting non-repudiation of data is the primary purpose of a
long-term archive service. Evidence may be generated by or otherwise
obtained by the service providing them to a retriever. A long-term
archive service need not be capable of providing all evidence
necessary to produce a non-repudiation proof. In particular, trust
anchors and algorithm security policies have to be provided by other
services.
4.3 Support Demonstration of Data Integrity
4.3.1 Functional Requirements
A longterm archive service must be capable of producing evidence that
can be used to demonstrate the integrity of data for which it is
responsible from the time it received the data until the expiration
of the archivation period of the data.
4.3.2 Rationale
Demonstration that data has not been altered while in the care of a
long-term archive service is a first step towards supporting
non-repudiation of data. Content-focused operations will be the
function of a notarization service.
4.4 Operate per a long-term archive policy
4.4.1 Functional Requirements
A long-term archive service must operate per a long-term archive
service policy that defines characteristics of the implementation of
Wallace, et al. Expires November 1, 2004 [Page 9]
Internet-Draft Long term archive service requirements May 2004
the long-term archive service. The policy may define characteristic
such as the quality of timestamps obtained or generated by the
long-term archive service or triggers for preservation activities,
e.g. timestamp refresh or data format migration.
A long-term archive service must be able to provide information
identifying the policies in use at any point in time. Submitters must
be able to indicate the archive policy under which the submitted data
should be handled. The service must provide an indication of the
archive policy observed by the service. If a long-term archive
service does not support a client-requested policy, it must return an
error indication.
4.4.2 Rationale
Similar to a certificate policy, a long-term archive policy provides
a shorthand means of technically expressing a set of rules that
govern operation of a long-term archive service.
4.5 Data confidentiality
4.5.1 Functional Requirements
A long-term archive service must provide means to ensure
confidentiality of archived data objects, including confidentiality
between the submitter and the long term archive service.
Traditional standardized encrypting methods and formats, e.g. CMS,
should be supported.
The concept should be open to add other methods for confidentiality,
like sharing secrets between different archive providers
Encryption or other methods must not pose a risk to evidence.
4.5.2 Rationale
Individuals may wish to use the services of a commercial long-term
service without disclosing data to the commercial service.
4.6 Data and evidence transferability
4.6.1 Functional Requirements
A long-term archive service must support the transfer of archived
data objects, evidence and evidence records from one service to
another.
Wallace, et al. Expires November 1, 2004 [Page 10]
Internet-Draft Long term archive service requirements May 2004
4.6.2 Rationale
Before the end of an archived data object's archivation period, a
long-term archive service may cease operation. In such cases, it must
be possible for the archived data object (and any associated
evidence) to be transferred to another service that will continue
preservation of the data until the end of the archivation period.
4.7 Supporting Groups of Data
4.7.1 Functional Requirements
The service should support groups of data objects.
Submitters should be able to indicate which data objects belong
together, i.e. comprise a group. Retrievers should be able to
retrieve all members of a group of data objects.
It should be possible to provide evidence for groups of archived data
objects. For example, it should be possible to archive a document
file and a signature file together such that they are covered by the
same evidence record.
Where groups of data objects are submitted, non-repudiation proof
must still be available for each archived data object separately.
4.7.2 Rationale
In many cases data objects belong together. Examples include:
- a document file and an associated signature file, which are two
separate objects
- TIF-files representing pages of a document
- a document file and an evidence file (possibly generated by another
TAA or notary service)
In these cases, it is to the best advantage to handle these data
objects as a group.
Wallace, et al. Expires November 1, 2004 [Page 11]
Internet-Draft Long term archive service requirements May 2004
5. Operational Considerations
A long-term archive service must be able to work efficiently even for
large amounts of archived data objects. In order to limit expenses
and to achieve high performance, the involvement of trusted third
parties should be minimized.
Necessity to access archived data objects should be minimized. It may
only be necessary access to the archived data objects if the archived
data objects are requested by users or if hash algorithms used for
indexing or evidence record generation become insecure.
Wallace, et al. Expires November 1, 2004 [Page 12]
Internet-Draft Long term archive service requirements May 2004
6. Security Considerations
Data is the principal asset protected by a long-term archive service.
The principle threat addressed by a long-term archive service is
undetected loss of data integrity.
Certificate revocation could retroactively invalidate previously
verified signatures. Measures may be implemented to support such
claims by an alleged signer, e.g. collection of revocation
information after a grace period during which compromise can be
reported or preservation of subsequent revocation information.
Access control mechanisms associated with data stored by a TAA should
consider the lifespan of the data object. For example, the
credentials of an entity that submitted data to an archive may not be
available or valid when the data needs to be retrieved.
During archiving period data format may not be no longer supported.
Software components to process data, its content or signatures, may
no longer available, in particular if non-standard formats are used
or proprietary processing is employed. Submitter has to take care
about this potential problem. E.g. he has to retrieve data in time,
convert them and re-submit it in new format. Of course additional
mechanisms, applications or tools are needed in order to conserve
evidence value. Other specifications of LTANS, in particular to
notary services will adress these problems.
Wallace, et al. Expires November 1, 2004 [Page 13]
Internet-Draft Long term archive service requirements May 2004
7. Acknowledgements
Thanks to members of the LTANS mailing list for review of earlier
drafts and many suggestions.
8 References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3029] 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.
[RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
Authors' Addresses
Carl Wallace
Orion Security Solutions
Suite 300
1489 Chain Bridge Road
McLean, VA 22101
Fax: +1(703)917-0260
EMail: cwallace@orionsec.com
Ulrich Pordesch
Fraunhofer Gesellschaft
Dolivostrasse 15
Darmstadt, Germany D-64293
EMail: ulrich.pordesch@zv.fraunhofer.de
Wallace, et al. Expires November 1, 2004 [Page 14]
Internet-Draft Long term archive service requirements May 2004
Ralf Brandner
InterComponentWare AG
Otto-Hahn-Strabe 3
Walldorf, Germany 69190
EMail: ralf.brandner@intercomponentware.com
Wallace, et al. Expires November 1, 2004 [Page 15]
Internet-Draft Long term archive service requirements May 2004
Appendix A. Application scenarios
Below are several example application scenarios providing one or more
of the basic service features mentioned above.
A.1 Archive service supporting long-term non-repudiation
A long-term archive service may store data objects, like signed or
unsigned documents, for authenticated users. It may generate time
stamps for these data objects and obtain verification data during the
archivation period or until a deletion request is received from an
authorized entity.
A.2 Pure long-term non-repudiation service
A long-term archive service may only guarantee non-repudiation of
existence of data by periodically generating time stamps and
obtaining verification data. It stores data objects (e.g. documents
and signatures) locally only for the purpose of non-repudiation and
does not function as a document archive for users. It does not
support retrieval and deletion of data objects.
A.3 Long-term Archive Service as part of an internal network
A long-term archive service may be part of an enterprise network.
The network provider and archive provider may be the same
institution. In this case, the provider will use an external TSA, to
generate non-repudiation evidence from a third party. An internally
generated acknowledgement would be worthless.
A.4 Long-term Archive External Service
A long-term archive service may be provided over the internet for
enterprises or consumers. In this case, archiving and providing
evidence (via time-stamps or other means) may be adduced by one
organisation and its own technical infrastructure without using
external services.
Wallace, et al. Expires November 1, 2004 [Page 16]
Internet-Draft Long term archive service requirements May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Wallace, et al. Expires November 1, 2004 [Page 17]
Internet-Draft Long term archive service requirements May 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wallace, et al. Expires November 1, 2004 [Page 18]