[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4810

Long-term Archive And Notary                                  C. Wallace
Services (LTANS)                                Orion Security Solutions
Internet-Draft                                               U. Pordesch
Expires: April 13, 2006                          Fraunhofer Gesellschaft
                                                             R. Brandner
                                                   InterComponentWare AG
                                                        October 10, 2005


                 Long-Term Archive Service Requirements
                      draft-ietf-ltans-reqs-05.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 April 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   There are many scenarios in which users must be able to prove the
   existence of data at a specific point in time and be able to
   demonstrate the integrity of data since that time, even when the
   duration from time of existence to time of demonstration spans a
   large period of time.  Additionally, users must be able to verify



Wallace, et al.          Expires April 13, 2006                 [Page 1]

Internet-Draft            Archive Requirements              October 2005


   signatures on digitally signed data many years after the generation
   of the signature.  This document describes a class of long-term
   archive services to support such scenarios and the technical
   requirements for interacting with such services.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  General Principles . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Technical Requirements . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Enable submission, retrieval and deletion of archived
           data objects . . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Functional Requirements  . . . . . . . . . . . . . . .  9
       4.1.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Enable management of archived data objects . . . . . . . . 10
       4.2.1.  Functional Requirements  . . . . . . . . . . . . . . . 10
       4.2.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Provide evidence records that support demonstration of
           data integrity . . . . . . . . . . . . . . . . . . . . . . 11
       4.3.1.  Functional Requirements  . . . . . . . . . . . . . . . 11
       4.3.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Operate per a long-term archive policy . . . . . . . . . . 11
       4.4.1.  Functional Requirements  . . . . . . . . . . . . . . . 12
       4.4.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 12
     4.5.  Support data confidentiality . . . . . . . . . . . . . . . 13
       4.5.1.  Functional Requirements  . . . . . . . . . . . . . . . 13
       4.5.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 13
     4.6.  Provide means to transfer data and evidence from one
           service to another . . . . . . . . . . . . . . . . . . . . 13
       4.6.1.  Functional Requirements  . . . . . . . . . . . . . . . 13
       4.6.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 13
     4.7.  Support operations on groups of data objects . . . . . . . 14
       4.7.1.  Functional Requirements  . . . . . . . . . . . . . . . 14
       4.7.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Operational Considerations . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Application scenarios . . . . . . . . . . . . . . . . 19
     A.1.  Archive service supporting long-term non-repudiation . . . 19
     A.2.  Pure long-term non-repudiation service . . . . . . . . . . 19
     A.3.  Long-term Archive Service as part of an internal
           network  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     A.4.  Long-term Archive External Service . . . . . . . . . . . . 19



Wallace, et al.          Expires April 13, 2006                 [Page 2]

Internet-Draft            Archive Requirements              October 2005


   Appendix B.  Cryptographic Maintenance Policy requirements . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22
















































Wallace, et al.          Expires April 13, 2006                 [Page 3]

Internet-Draft            Archive Requirements              October 2005


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 through a regimen of technical and procedural
   mechanisms designed to support claims regarding a data object.  For
   example, it might periodically perform activities to preserve data
   integrity and the non-reputability of data existence by a particular
   point in time as well as ensuring the availability of data.  Examples
   of periodic activities include refreshing time-stamps or transferring
   data to a new storage medium.

   A long-term archive service may be used to provide evidence that
   supports validation of the existence of documents or assertions of
   agreements that were 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 implemented as an
   external service accessible via the 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 a claim 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:





Wallace, et al.          Expires April 13, 2006                 [Page 4]

Internet-Draft            Archive Requirements              October 2005


      - 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 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 prepares information for a
   criminal trial.

   This document addresses the technical requirements for a long-term
   archive service.  The requirements for certification services will be
   covered by a separate draft.






























Wallace, et al.          Expires April 13, 2006                 [Page 5]

Internet-Draft            Archive Requirements              October 2005


2.  Terminology

   We define the following terms based on their usage in the archiving
   community, in order to provide a vocabulary for describing
   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.



   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.





   Cryptographic Maintenance Policy:  A named 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
      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



Wallace, et al.          Expires April 13, 2006                 [Page 6]

Internet-Draft            Archive Requirements              October 2005


      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 (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 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,
      [RFC 3161] specifies a structure for signed time-stamp tokens as
      part of a protocol for communicating with a Time-Stamp Authority
      (TSA).



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



Wallace, et al.          Expires April 13, 2006                 [Page 7]

Internet-Draft            Archive Requirements              October 2005


3.  General Principles

   A long-term archive service may accept any type of data for
   preservation.  The data might be in any format, whether textual data,
   images, documents, applications, or compound packages of multiple
   components.  The data may be digitally signed, time-stamped,
   encrypted, or not subject to any cryptographic processing.

   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 is not required to operate upon evidence
   related to the content of archived data objects.  Content-focused
   operations, including data format migration or translation, may be
   performed by a other services, e.g., certification services.
   However, an LTA may incorporate support for such services.

   Different long-term archive services may establish policies and
   procedures for archiving data objects over different lengths of time.
   For example, an LTA may refuse to preserve archived data objects for
   periods longer than 30 years.  Similarly, LTAs may establish policies
   that limit the types of data that will be accepted for deposit by a
   particular LTA.

   A long-term archive service provides a evidence that may be used to
   demonstrate the existence of archived data object at a given time and
   the integrity of the archived data object since that time.
   Additionally, the evidence identifies the LTA(s) that have
   participated in the preservation of the archived data object.  If the
   archived data object itself contains digitally signed data,
   authentication of the signer is also possible.

   A long-term archive service may be an adjunct component of a document
   management system.  In such cases, the evidence record generated and
   maintained by the LTA is a property of data that is otherwise managed
   by the document management system.














Wallace, et al.          Expires April 13, 2006                 [Page 8]

Internet-Draft            Archive Requirements              October 2005


4.  Technical Requirements

   This section describes the requirements for the protocol for
   accessing a long-term archive system and for the data formats
   associated with data preservation.

4.1.  Enable submission, retrieval and deletion of archived data objects

4.1.1.  Functional Requirements

   A long-term archive service must permit clients to request the
   following basic operations:

      - submit data objects for archive

      - retrieve archived data objects

      - delete archived data objects

   Following submission, the service must provide a value that can be
   used to retrieve the archived data and/or associated evidence.  For
   example, it may be possible to retrieve archive packages by using a
   hash value of an archived data object.  Possession of this value is
   not necessarily an authorization to access the associated archived
   data object or evidence record.

   It must be possible to authenticate requests and responses, e.g. to
   enable LTAs to render an authorization decision.  This may be
   accomplished using transport security mechanisms.  Requests, in
   particular retrieval or deletion requests, may be rejected if the
   requestor is not authorized.  An authorization policy must be defined
   and observed by the long-term archive service.  An LTA may disallow
   physical deletion as a matter of policy.

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

   The LTA must provide an acknowledgement of deposit that permits the
   submitter to confirm the correct data was accepted by the LTA.  This
   proof need not be provided immediately.

4.1.2.  Rationale

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

   Deletion may be disallowed due to procedural difficulties in
   fulfilling the request.  For example, an archived data object may be



Wallace, et al.          Expires April 13, 2006                 [Page 9]

Internet-Draft            Archive Requirements              October 2005


   storage on write-once media along with other records that are not
   subject to deletion.

   Acknowledgements may not be provided immediately due to
   implementation of a grace period.  A generic query state mechanism
   should be provided to address such situations.  For example, a
   submission response may indicate that a submission has been accepted
   and a subsequent query state response may indicate a submission has
   completed all necessary preservation steps.

4.2.  Enable management of archived data objects

4.2.1.  Functional Requirements

   A long-term archive service must permit clients to request the
   following basic operations:

      - specify an archivation period for submitted data objects

      - extend or shorten the archivation 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 extend or shorten the archivation period
   after the initial submission.  It should be possible to express an
   archivation 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 enable retrievers to render the data correctly, to locate
   data in an archive or to place data in a particular context.
   Examples include, classification codes, type of format, contributors,
   title, author, 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.2.2.  Rationale

   Submission, retrieval and deletion of archived data objects are
   necessary basic functions of a long-term archive service.
   Specification and management of the archivation period is necessary



Wallace, et al.          Expires April 13, 2006                [Page 10]

Internet-Draft            Archive Requirements              October 2005


   to avoid unnecessary preservation activities.

4.3.  Provide evidence records that support demonstration of data
      integrity

4.3.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 archivation period of the data.

   This may be achieved by providing evidence records that support the
   long-term non-repudiation of data existence at and integrity since 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.

   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.

4.3.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
   records verified using those trust anchors.

   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.  Certification services support cases in which
   data must be modified, e.g. translation or format migration.  An LTA
   may provide certification services.  The requirements for
   certification services are defined in [CERTSRV]

4.4.  Operate per a long-term archive policy





Wallace, et al.          Expires April 13, 2006                [Page 11]

Internet-Draft            Archive Requirements              October 2005


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
   the long-term archive service.  A long-term archive service policy
   contains 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 the
   following operational aspects: preservation activity triggers,
   default archivation period, default handling upon expiration of
   archivation period.

   Maintenance policies should include mechanism-specific details
   describing LTA operation.  For example, where cryptographic
   mechanisms are employed, a cryptographic maintenance policy should be
   defined.  Requirements for cryptographic maintenance policies are
   provided in Appendix B.

   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, 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 named policy.

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

4.4.2.  Rationale

   Similar to a certificate policies [RFC3647], which are identified
   using object identifiers, a long-term archive policy provides a
   shorthand means of technically identifying a set of rules that govern
   operation of a long-term archive service.



Wallace, et al.          Expires April 13, 2006                [Page 12]

Internet-Draft            Archive Requirements              October 2005


   Over the course of many years, the policies under which an LTA
   operates may undergo modification.  Thus, an evidence record may
   feature multiple indications of policies active at various points
   during the life of an archived data object.

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

   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.



Wallace, et al.          Expires April 13, 2006                [Page 13]

Internet-Draft            Archive Requirements              October 2005


   Submitters may change service providers before the end of an archived
   data object's archivation period.  In such cases, 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 such 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 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 or certification service)

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












Wallace, et al.          Expires April 13, 2006                [Page 14]

Internet-Draft            Archive Requirements              October 2005


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, it may be desirable to minimize the
   use of trusted third parties, e.g.  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 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 April 13, 2006                [Page 15]

Internet-Draft            Archive Requirements              October 2005


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.

   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, e.g. collection of revocation information after a
   grace period during which compromise can be reported or preservation
   of subsequent revocation information.

   When selecting access control mechanisms associated with data stored
   by a 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 lifespan of an archived data object, formats may cease to be
   supported.  Software components to process data, including content or
   signatures, may no longer 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 the data and re-submit it
   in new format.  Additional mechanisms, applications or tools may be
   needed to preserve the value of evidence records associated with
   original archived data object.  Other specifications of LTANS, in
   particular certification services will address these problems.

   Some applications may require processing of a chain of archive
   policies present in an evidence record, e.g. to ensure that
   compatible policies were used throughout the lifetime of an archived
   data object.
















Wallace, et al.          Expires April 13, 2006                [Page 16]

Internet-Draft            Archive Requirements              October 2005


7.  Acknowledgements

   Thanks to members of the LTANS mailing list for review of earlier
   drafts and many suggestions.  In particular, thanks to Larry
   Masinter, Denis Pinkas and Peter Sylvester for review and
   suggestions.













































Wallace, et al.          Expires April 13, 2006                [Page 17]

Internet-Draft            Archive Requirements              October 2005


8.  References

8.1.  Normative References

   [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
              February 2004.

8.2.  Informative References

   [CERTSRV]  Schmidt, A., Gondrom, T., and L. Masinter, "Requirements
              for Certification Services", October 2004.

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

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





















Wallace, et al.          Expires April 13, 2006                [Page 18]

Internet-Draft            Archive Requirements              October 2005


Appendix A.  Application scenarios

   Below are several example application scenarios demonstrating 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
   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 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 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
   organization and its own technical infrastructure without using
   external services.














Wallace, et al.          Expires April 13, 2006                [Page 19]

Internet-Draft            Archive Requirements              October 2005


Appendix B.  Cryptographic Maintenance Policy requirements

   A cryptographic maintenance policy:

      must be unambiguously identified, e.g., by an object identifier,

      must include a validity period,

      must specify the Time-Stamping Units (TSU) recognized under that
      policy,

      may reference a sequence of one or more other cryptographic
      maintenance policies.

   A cryptographic maintenance policy will be defined in terms of
   parameters including acceptable algorithms, validity period for
   algorithms and acceptable key lengths.  A cryptographic maintenance
   policy may also require maintenance activities simply due to the
   passage of time independent of events such as certificate expiration
   or algorithm compromise.































Wallace, et al.          Expires April 13, 2006                [Page 20]

Internet-Draft            Archive Requirements              October 2005


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


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

   Email: ralf.brandner@intercomponentware.com

























Wallace, et al.          Expires April 13, 2006                [Page 21]

Internet-Draft            Archive Requirements              October 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.




Wallace, et al.          Expires April 13, 2006                [Page 22]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/