RFC 4810

Long-Term Archive Service Requirements

📅 published March 2007, from ietf

RFC 4810: Long-Term Archive Service Requirements 🎀

okay bestie, so this is RFC 4810, and it's Informational, which means it's giving "here's some useful info" and not "you MUST do this" 💅 It's from the Network Working Group and dated March 2007. Three authors wrote it: C. Wallace from Cygnacom Solutions, U. Pordesch from Fraunhofer Gesellschaft, and R. Brandner from InterComponentWare AG. The title block has no Obsoletes or Updates entry, so it doesn't list any other RFC it replaces or changes 🌸

Status of This Memo

this memo is for the Internet community as info. it does not specify an Internet standard of any kind 🫶 and distribution of it is unlimited ✨

the copyright line reads Copyright (C) The IETF Trust (2007). 💜

Abstract

okay so the big idea is that people often need to prove that some data existed at a specific moment, and then show later that it hasn't been messed with, even if that "later" is years and years away 😭 they also need to check digital signatures long after those signatures were made 🔥 this doc describes a kind of long-term archive service built for exactly that, plus the technical requirements for talking to one 🦋

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  General Principles . . . . . . . . . . . . . . . . . . . . . .  5
4.  Technical Requirements . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Enable Submission, Retrieval, and Deletion of Archived
        Data Objects . . . . . . . . . . . . . . . . . . . . . . .  6
    4.1.1.  Functional Requirements  . . . . . . . . . . . . . . .  7
    4.1.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . .  7
  4.2.  Operate in accordance with a long-term archive policy  . .  8
    4.2.1.  Functional Requirements  . . . . . . . . . . . . . . .  8
    4.2.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . .  9
  4.3.  Enable Management of Archived Data Objects . . . . . . . .  9
    4.3.1.  Functional Requirements  . . . . . . . . . . . . . . .  9
    4.3.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . .  9
  4.4.  Provide Evidence Records that Support Demonstration of
        Data Integrity . . . . . . . . . . . . . . . . . . . . . . 10
    4.4.1.  Functional Requirements  . . . . . . . . . . . . . . . 10
    4.4.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 10
  4.5.  Support Data Confidentiality . . . . . . . . . . . . . . . 11
    4.5.1.  Functional Requirements  . . . . . . . . . . . . . . . 11
    4.5.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 11
  4.6.  Provide Means to Transfer Data and Evidence from One
        Service to Another . . . . . . . . . . . . . . . . . . . . 11
    4.6.1.  Functional Requirements  . . . . . . . . . . . . . . . 11
    4.6.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 11
  4.7.  Support Operations on Groups of Data Objects . . . . . . . 12
    4.7.1.  Functional Requirements  . . . . . . . . . . . . . . . 12
    4.7.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 12
5.  Operational Considerations . . . . . . . . . . . . . . . . . . 12
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8.  Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A.  Application Scenarios . . . . . . . . . . . . . . . . 15
  A.1.  Archive Service Supporting Long-Term Non-Repudiation . . . 15
  A.2.  Pure Long-Term Non-Repudiation Service . . . . . . . . . . 15
  A.3.  Long-Term Archive Service as Part of an Internal
        Network  . . . . . . . . . . . . . . . . . . . . . . . . . 15
  A.4.  Long-Term Archive External Service . . . . . . . . . . . . 15

1. Introduction ✨

okay so digital data durability gets wrecked by constant progress and change on a bunch of fronts 💀 the useful life of your data can outlast the formats and tools used to store it, and the life of digitally signed data can outlast both the validity period of the public-key certificates used to check the signatures and the cryptanalysis period of the algorithms used to make them. that cryptanalysis period is basically the point after which an algorithm stops giving the security properties it was meant to give 🙈 so you need both technical and operational fixes, and a real solution has to deal with things like storage media lifetime, disaster planning, cryptanalysis or computing power getting better, software tech changing, and legal stuff too 🫶

a long-term archive service helps keep data around for long stretches by running a whole system of technical and procedural steps meant to back up claims about a data object 🦋 for example, it might regularly work to keep the data's integrity intact and prove the data existed by a certain point in time, or take steps to keep the data available. the regular stuff can include refreshing time stamps or moving data onto a new storage medium 🧚

a long-term archive service can also give evidence to help validate that documents or agreements (originally backed by digital signatures) existed. that validation might happen way past the validity period of the private key used to create the signature 😭 or even after the algorithms for digital signatures, message digests, or data encryption have stopped offering real protection, because computers got faster and methods got better 🔥

the archive service can live inside an enterprise network, talking to local storage and other apps, or it can be an external service you reach over the Internet 🌸 it can also lean on stuff like time stamping that comes from independent service providers 💅

the main goal is to support the credible assertion of a claim that's being made right now, at points well into the future 👑 an archive like this can hold things like wills, land records, medical data, criminal case files, personnel files, and contracts 📜 pretty much any kind of entity can use it, like organizations, citizens, or notaries 🍓 here are some examples of how submitters use it:

  • A company stores contracts using a third party service.
  • A hospital stores medical data using an internal service.
  • 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 every example above, there's a matching one for retrievers 🌈 like a company pulling up a contract during a dispute, or a law enforcement officer preparing info for a criminal trial ⭐

this document covers the technical requirements for a long-term archive service 🎀

2. Terminology 📖

okay so we're defining these terms based on how the archiving community uses them 💖 that gives us a shared vocab for describing the requirements and the standards around them 🫶

Arbitrator: Principal for whom the validity of archived data characteristics, e.g., origin, integrity or time of existence, must be demonstrated.

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

Cryptographic Maintenance Policy: A set of rules that defines how to maintain the validity of digitally signed objects should one of the hash or asymmetric algorithms used to create a digital signature become weak, or one of the private keys used to create a digital signature be compromised or become weak.

Evidence: Information that may be used to demonstrate the validity of an archived data object or related attestations.

Evidence Record: Collection of evidence compiled for one or more archived data objects. An Evidence Record may include acknowledgements from a long-term archive service, time stamps and verification data, such as public-key certificates, revocation information, trust anchors, policy details and role information.

Long-Term Archive Policy: A set of rules that define operational characteristics of a long-term archive service.

Long-Term Archive Service (LTA): A service that is responsible for preserving data for long periods.

Modifier: Principal who modifies attributes associated with an archived data object and/or Evidence Record held by a long-term archive service.

Originator: Principal who produces, and possibly digitally 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 archived data objects and/or Evidence Records from a long-term archive service.

Submitter: Principal who submits data objects for archiving.

Time Stamp: An attestation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. For example, [RFC3161] specifies a structure for signed time stamp tokens as part of a protocol for communicating with a TSA.

Time Stamping Authority (TSA): A trusted service that provides attestations of existence of data at particular points in time. For example, [RFC3161] defines protocol elements for interacting with a TSA.

part 2 picks up with Section 3 (General Principles) and Section 4 (Technical Requirements) 🦋💜

3. General Principles ✨

okay so bestie, an LTA (long-term archive service) can accept basically any kind of data 🦋 text, images, documents, apps, or whole compound packages with a bunch of pieces inside. the data might be digitally signed, time stamped, encrypted, or not cryptographically processed at all. no judgment 💅

an LTA may preserve archived data objects as opaque collections of bytes, with the main goal being data integrity 🔒 so it's basically a super careful vault that doesn't need to read what's inside.

an LTA is not required to operate upon evidence related to the content of archived data objects. content-focused stuff like data format migration or translation can be handled by another service 🧚 but an LTA may incorporate support for those services too.

different LTAs can set their own policies and procedures for archiving over different lengths of time. like, an LTA may refuse to preserve archived data objects for periods longer than 30 years 💀 and LTAs may set policies that limit which types of data they'll accept for deposit.

an LTA gives you evidence that can show an archived data object existed at a given time, and that its integrity has been intact since then ✨ the evidence also identifies the LTA(s) that took part in preserving the object. if the object itself contains digitally signed data, authenticating the signer is also possible 🫶

an LTA may be an adjunct component of a document management system. in that case, the Evidence Record the LTA generates and maintains is a property of data that the document management system otherwise manages 🌸

4. Technical Requirements 💜

this section is all about the requirements for the protocol used to access a long-term archive system, and the data formats used for data preservation 📋

4.1. Enable Submission, Retrieval, and Deletion of Archived Data Objects 📥

4.1.1. Functional Requirements

a long-term archive service must let clients request these basic operations:

  • submit data objects for archive
  • retrieve archived data objects
  • delete archived data objects

after submission, the service must give you an identifier you can use to retrieve the archived data and/or its evidence. for example, you might be able to fetch archive packages using a hash value of an archived data object 🔑 but having that value is not necessarily permission to access the archived data object or evidence record 🙅

it must be possible to authenticate requests and responses, e.g., so LTAs can make an authorization decision 🛡️ this may be done with transport security mechanisms. requests (especially retrieval or deletion ones) may be rejected if the requestor isn't authorized. an authorization policy must be defined and observed by the long-term archive service. an LTA may disallow deletion as a matter of policy.

the format for the acknowledgements must allow identification of the archiving provider and the participating client.

the LTA must provide an acknowledgement of the deposit that lets the submitter confirm the correct data was accepted by the LTA. this proof doesn't need to show up immediately ⏳

4.1.2. Rationale

submission, retrieval, query state, and deletion are necessary basic functions of a long-term archive service 🧠

deletion may be disallowed because of procedural difficulties. for example, an archived data object might sit on write-once media alongside other records that aren't subject to deletion 📀

acknowledgements may not be provided immediately because of a grace period. a generic query state mechanism should be provided to address these situations. for example, a submission response might say a submission has been accepted, and a later query state response might say it has completed all the necessary preservation steps ✅

4.2. Operate in accordance with a long-term archive policy 📜

4.2.1. Functional Requirements

a long-term archive service must operate in accordance with a long-term archive service policy that defines the characteristics of the implementation of the service. a policy has several components, including:

  • Archived data object maintenance policy
  • Authorization policy
  • Service policy

a long-term archive service policy must include specifications of the preservation activities performed for archived data objects subject to the policy. a maintenance policy should define rules for these operational aspects: preservation activity triggers, default archival period, and default handling upon expiration of archival period.

maintenance policies should include mechanism-specific details describing LTA operation. for example, where cryptographic mechanisms are employed, a cryptographic maintenance policy ought to be defined.

an authorization policy should define the entities permitted to exercise services provided by the LTA, including who is permitted to submit, retrieve, or manage specific archived data objects.

a service policy defines the types of services provided by an LTA, including acceptable data types, a description of requests that may be accepted, and deletion procedures.

policies must be unambiguously identified, e.g., by an object identifier. alternatively, an LTA may support a protocol that permits clients to specify policy parameters explicitly instead of by reference to a policy.

a long-term archive service must be able to provide information identifying the policies relevant for a given archived data object.

4.2.2. Rationale

similar to certificate policies [RFC3647], which are identified using object identifiers, a long-term archive policy is a shorthand way of technically identifying a set of rules that govern how a long-term archive service operates 🏷️

over the course of many years, the policies an LTA operates under may change. so an evidence record may feature multiple indications of policies that were active at various points during the life of an archived data object ⏳

4.3. Enable Management of Archived Data Objects 🗂️

4.3.1. Functional Requirements

a long-term archive service must let clients request these basic operations:

  • specify an archival period for submitted data objects
  • extend or shorten the archival period for an archived data object
  • specify metadata associated with an archived data object
  • specify an archive policy under which the submitted data should be handled

it should be possible to express an archival period in terms of time, an event, or a combination of time and event 🕰️

submitters should be able to specify metadata that, for example, can be used to help retrievers render the data correctly, locate data in an archive, or place data in a particular context. examples include classification codes, type of format, contributors, title, author, and date. alternatively, such information may be included in the content of an archived data object.

if a long-term archive service does not support a requested policy, it must return an error indication. a service must provide an indication of the archive policy enforced by the service.

4.3.2. Rationale

submission, retrieval, and deletion of archived data objects are necessary basic functions of a long-term archive service.

specifying and managing the archival period is necessary to avoid unnecessary preservation activities 🧹

4.4. Provide Evidence Records that Support Demonstration of Data Integrity 🔍

4.4.1. Functional Requirements

a long-term archive service must be capable of providing 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 archival period of the data 🔐

this may be achieved by providing evidence records that support the long-term non-repudiation of data existence at a point in time, e.g., in the case of legal disputes. the evidence record should contain sufficient information to enable the validity of an archived data object's characteristics to be demonstrated to an arbitrator. the characteristics subject to verification will vary. for example, authentication of an originator may not be possible in all cases, e.g., where the object submitted to the archive is not signed or where the object does not include the necessary information to authenticate the object's signer.

evidence records must be structured such that modifications to an archived data object or its evidence record can be detected, including modifications made by administrators of an LTA. no sneaky edits allowed 🚨

4.4.2. Rationale

supporting non-repudiation of data existence, integrity, and origin is a primary purpose of a long-term archive service. evidence may be generated, or otherwise obtained, by the service providing the evidence to a retriever. a long-term archive service need not be capable of providing all evidence necessary to produce a non-repudiation proof, and in some cases, should not be trusted to provide all necessary information. for example, trust anchors [RFC3280] and algorithm security policies should be provided by other services. an LTA that is trusted to provide trust anchors could forge an evidence record verified by using those trust anchors 😬

demonstrating 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. certification services support cases in which data must be modified, e.g., translation or format migration. an LTA may provide certification services.

4.5. Support 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. an LTA must provide a means for accepting encrypted data such that future preservation activities apply to the original, unencrypted data. encryption, or other methods of providing confidentiality, must not pose a risk to the associated evidence record.

a long-term archive service should maintain contact information for the parties responsible for each archived data object so warning messages can be sent when encryption algorithms require maintenance 📨

4.5.2. Rationale

individuals may wish to use the services of a commercial long-term service without disclosing data to the commercial service. however, access to the original data may be necessary to perform some preservation activities.

4.6. Provide Means to Transfer Data and Evidence from One Service to Another 🚚

4.6.1. Functional Requirements

it must be possible to submit data along with previously generated evidence, i.e., to support transfer of data from one archive to another. a long-term archive service must support the transfer of archived data objects, evidence, and evidence records from one service to another. it must be possible for evidence records to span multiple providers over the course of time, without losing value as evidence 🦋

4.6.2. Rationale ✨

okay so, before an archived data object's archival period is over, a long-term archive service might just... stop operating 😭. when that happens, it must be possible for the archived data object (and any associated evidence) to be transferred to another service that will keep preserving the data until the archival period ends 🫶.

submitters can also switch service providers before the archival period ends 💅. in that case, it must be possible for the submitter to transfer an archived data object and all associated evidence from the original LTA to a new LTA 🦋.

4.7. Support Operations on Groups of Data Objects 🧚

4.7.1. Functional Requirements

an LTA should support submission of groups of data objects. submitters should be able to indicate which data objects belong together, i.e. comprise a group, and retrievers should be able to retrieve one, some or 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 so that they are covered by the same evidence record ✨.

where an LTA operates upon groups of data objects, non-repudiation proof must still be available for each archived data object separately 🔥.

4.7.2. Rationale

in so 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 LTA)
  • a document and its translation to another format or language

in these cases, it is to the best advantage to handle these data objects as a group 💜.

5. Operational Considerations 🌈

a long-term archive service must be able to work efficiently even when there are large amounts of archived data objects 💪. to limit expenses and get high performance, it may be desirable to minimize the use of trusted third parties. for example, LTA operations should be designed to limit the number of time stamps required to provide the desired level of service ⏱️.

necessity to access archived data objects should be minimized 🙈. it may only be necessary to access the archived data objects if they are requested by users, or if hash algorithms used for indexing or evidence record generation become insecure.

an LTA must be capable of operating in accordance with any applicable legal regime ⚖️. for example, an LTA may be required to reject a deletion request from an authorized requestor if the target of the request has been subpoenaed by law enforcement authorities.

some applications may require processing of a chain of archive policies present in an evidence record. for example, this can help ensure that compatible policies were used throughout the lifetime of the archived data objects 🧐.

6. Security Considerations 🚨

okay this section is serious, bestie 😤. data is the principal asset protected by a long-term archive service. the principle threat that must be addressed by a long-term archive service is an undetected loss of data integrity 💀.

in cases where signature verification relies on a PKI, certificate revocation could retroactively invalidate previously verified signatures. an LTA may implement measures to support such claims by an alleged signer. for example, it could collect revocation information after a grace period during which compromise can be reported, or preserve subsequent revocation information 🔐.

when selecting access control mechanisms associated with data stored by an LTA, the lifespan of the archived data object should be considered. 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 the lifespan of an archived data object, formats may cease to be supported. software components to process data, including content or signatures, may no longer be available. this could be a problem particularly if non-standard formats are used or proprietary processing is employed. the submitter should take care to avoid such problems 👀. for example, the submitter (or other authorized entity) could periodically retrieve data, convert it, and re-submit it in a new format. additional mechanisms, applications, or tools may be needed to preserve the value of evidence records associated with the original archived data object 🛠️.

a long-term archive system may require correlation of different identities that represent the same entity at different points in time. for example, an individual's identity may be represented by different employers at different points in time 🪪.

a long-term archive system must perform maintenance activities on a schedule that considers factors such as the strength of relevant cryptographic algorithms, the lifespan of relevant certification authorities, and the revocation status of relevant entities, e.g., timestamp authorities 🗓️. standards for use of cryptographic algorithms are expected to be established by organizations or governmental bodies, not by individual LTAs 🙅‍♀️.

7. Acknowledgements 🫶

thanks to members of the LTANS mailing list for reviewing earlier drafts and making so many suggestions 💖. special thanks to Larry Masinter, Denis Pinkas, and Peter Sylvester for their review and suggestions 👑.

8. Informative References 📚

[RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
           "Internet X.509 Public Key Infrastructure Time-Stamp
           Protocol (TSP)", RFC 3161, August 2001.

[RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
           X.509 Public Key Infrastructure Certificate and
           Certificate Revocation List (CRL) Profile", RFC 3280,
           April 2002.

[RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
           Wu, "Internet X.509 Public Key Infrastructure Certificate
           Policy and Certification Practices Framework", RFC 3647,
           November 2003.

Appendix A. Application Scenarios 🎀

below are several example application scenarios that show off 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, such as signed or unsigned documents, for authenticated users. it may generate time stamps for these data objects and obtain verification data during the archival 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 it 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 service may be part of the same institution. in this case, the service should obtain non-repudiation evidence from a third party. an internally generated acknowledgement may be viewed as 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 carried out by one organization and its own technical infrastructure, without using external services 🌐.

Authors' Addresses 🖋️

Carl Wallace
Cygnacom Solutions
Suite 5200
7925 Jones Branch Drive
McLean, VA  22102

Fax:   +1(703)848-0960
EMail: cwallace@cygnacom.com


Ulrich Pordesch
Fraunhofer Gesellschaft
Rheinstrasse 75
Darmstadt, Germany  D-64295

EMail: ulrich.pordesch@zv.fraunhofer.de


Ralf Brandner
InterComponentWare AG
Otto-Hahn-Strabe 3
Walldorf, Germany  69190

EMail: ralf.brandner@intercomponentware.com

Copyright (C) The IETF Trust (2007).

this document is subject to the rights, licenses and restrictions contained in BCP 78. except as set forth therein, the authors retain all their rights.

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, THE IETF TRUST 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.

Intellectual Property 🦋

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. it also doesn't 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 required to implement this standard. please address the information to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 💐

Funding for the RFC Editor function is currently provided by the Internet Society 🌷.

📦 where this page comes from