2.6.8 Long-Term Archive and Notary Services (ltans)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-28


Carl Wallace <cwallace@orionsec.com>
Tobias Gondrom <tobias.gondrom@ixos.de>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion: ietf-ltans@imc.org
To Subscribe: ietf-ltans-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ltans

Description of Working Group:

In many scenarios, users need to be able to ensure and prove the
existence and validity of data, especially digitally signed data, in a
common and reproducible way over a long and possibly undetermined period
of time.

Cryptographic means are useful, but they do not provide the whole
solution. For example, digital signatures (generated with a particular
key size) might become weak over time due to improved computational
capabilities, new cryptanalytic attacks might "break" a digital
signature algorithm, public key certificates might be revoked or expire,
and so on.

Complementary methods covering potential weaknesses are necessary.

Long-term non-repudiation of digitally signed data is an important
aspect of PKI-related standards. Standard mechanisms are needed to
handle routine events, such as expiry of signer's public key certificate
and expiry of trusted time stamp authority certificate. A single
timestamp is not sufficient for this purpose. Additionally, the reliable
preservation of content across change of formats, application of
electronic notarizations, and subsequent notary services require
standard solutions.

The objective of the LTANS working group is to define requirements, data
structures and protocols for the secure usage of the necessary archive
and notary services. First, the requirements for the long-term archive
will be collected. Based on that information we will develop a protocol
to access archive services supplying long-term non-repudiation for
signed documents and define common data structures and formats. Upon
completion of the archive-related specifications, we will address
'notary services' in a similar way. The term 'notary services' is not
clearly defined. The working group will determine which functions need
standards, including transformation of documents from one format to
another without losing the value of evidence, electronic notarization,
and further verification of legal validity of signed documents. We will
determine the needs via the requirements paper and act upon the results

Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be
used as the basis to define those structures and protocols. For example,
the Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted
Archive Protocol (TAP)" and RFC 3029, "Data Validation and Certificate
Server Protocols (DVCS)", contain applicable concepts.

Goals and Milestones:

Done  Initial requirements for long-term archive I-D
Done  Initial data structures for long-term archive I-D
Apr 04  Last call requirements for long-term archive I-D
Apr 04  Revised requirements for long-term archive I-D
May 04  Revised data structures for long-term archive I-D
May 04  Initial requirements for notary services I-D
Jun 04  Initial protocol for long-term archive I-D
Jun 04  Last call data structures for long-term archive I-D
Jul 04  Submit requirements for long-term archive to IESG as informational
Jul 04  Submit data structures for long-term archive to IESG as proposed standard
Aug 04  Revised requirements for notary services I-D
Aug 04  Protocol revisions for long-term archive I-D
Sep 04  Last call protocol for long-term archive I-D
Sep 04  Last call requirements for notary services I-D
Oct 04  Submit protocol for long-term archive to IESG as proposed standard
Oct 04  Submit requirements for notary services to IESG as proposed standard


  • draft-ietf-ltans-reqs-04.txt
  • draft-ietf-ltans-ers-02.txt
  • draft-ietf-ltans-notareqs-02.txt
  • draft-ietf-ltans-ltap-00.txt

    No Request For Comments

    Current Meeting Report

    Minutes of LTANS WG meeting at the 63rd IETF conference
    August 1, 2005 16:30 - 18:00
    A total of approximately 40 individuals participated in the meeting.

    Edited by Tobias Gondrom

    Chairs: Tobias Gondrom <tgondrom@opentext.com> & Carl Wallace <cwallace@orionsec.com>

    Agenda Topics:

    Administrivia and document status - Tobias Gondrom
    After decreasing the speed of the WG after 61st IETF WG takes up normal schedule again.
    Currently 4 documents in work. Due to the weakening of SHA-1 the results of LTANS got more attention in the last months and the need for standards seems to become more urgent. As a result two independent implementations of ERS will be out at the market in December-05.
    A revised list of milestones will be submitted after the WG meeting.

    Short update on archive requirements (reqs-04) - Tobias Gondrom
    A short update on the technical and functional requirements in the document has been presented to prepare the later discussion about the comments and suggestions for improvement.
    Most of its chapters are stable and in good state. Only the cryptography maintenance policies and the chapter for the data confidentiality need more input and refinement.

    Comments on Archive Requirements (reqs-04) - Denis Pinkas
    - Denis raised the idea of an attestation of deposit, i.e. a user (Client) should recieve a ticket (that might even be used for authorization) as an attestation for the deposition of the archived data. This ticket should also contain the attestation of other documents stored in a given period so that the user does not have to keep tickets for individual documents but can keep tickets for specific time frames.
    - It is also necessary to be able to store meta data (this is especially helpful as a criteria for later applied Cryptographic Maintenance Policies)
    - Denis expressed the need to manage accounts for the LTAP so that it can e.g. bill the parties submitting data for archiving.
    The need for managing accounts in general is agreed upon. But it has been disagreed by several persons that this needs to be specified by LTAP. Instead the LTAP should not specify this and each implementation should make use of already existing mechanisms for account management.

    Cryptographic Maintenance Policy (reqs-04) - Denis Pinkas
    - Concerning Cryptography: The question has been rised whether encryption of data on the LTA makes any sense - as the encryption mechanisms will become insecure on the long run (5-30 years+) anyway. Denis made the point that he wants to be able to make the normal Systems Engineers (running the LTA) incapable to disclose or read information that is stored currently. Anyway he recognizes that data that might be stored today will be possibly decrypted in several years. Nonetheless the possibility to store encrypted data limits the possibilities for disclosure by the System Engineer working on the LTA. (and the confidentiality of the information might decrease in importance after several years, as data is generally also losing its value by time.)
    - The encryption algorithms schould be stored in the meta data, so that the server can react upon this information, e.g. send warnings to the user when the used algorithms get insecure or can be broken.
    - A cryptographic maintenance policy will change with time. It could be some kind of linked list as the future maintenance policies will not be known at the time of archiving as it is unknown at what time relevant cryptographic algorithms are becoming insecure and what new algorithms are developed in the future...
    - Stephan Santesson aksed if it is one of the goals to process signatures inside the archived data packets, e.g. signature verification? Clear answer from Denis, the editors and the audience: No.
    - Larry recommended that we should also keep the application of the maintenance policies so flexible that we can also start a maintenance process when e.g. the certificates expire (simply by time not by broken algorithms) - e.g. by introducing an additional parameter

    Presentation of LTAP Protocol (ltap-00) - Peter Sylvester
    - Peter made the point to make the Protocol as small as possible to make it easy to implement and roll-out even minimal implementetations. This way he recommends to solve the account management by the use of other common technologies and not specify its implementation.
    - Larry also commented that usually accounts don't live very long, most probably not as long as the documents are stored (30 years and more)
    - Denis suggested the option to change the retriever to "public" e.g. after 5 years. This would solve the problem with possibly expired accounts and with this no longer granted access to the documents
    - The question whether the LTA shall also certify that certain access control mechanisms and levels have been applied during the archiving period. The overall answer was no.
    - David Black suggested that the access control could also be role based and with this be less problematic with lost accounts.
    - M.T: Carrasco also recommended to design a simple level of archive so that it can be implemented easily
    - Peter highlighted that the LTAP design is based on an asynchronous protocol (first the request "message send" to archive, second the synchronous answer of the Long-term archive that the message has been received and third the asynchronous answer that the message has been archived correctly) - getting the asynchronous message "message archived" has been realized in LTAP by using the poll-mechanism so that no back cahnnel to the client has to be handled.
    - It is also important to provide a mechanism to transfer data from one LTA to an other LTA and from one "policy space" within a LTA to another, e.g. when a inspection is on the way and data must be kept until it is completed, although the applied policy would no longer require that the data be kept or maintained.

    Requirements for Data Validation and Certification Services (notareqs-04) - Larry Masinter
    - Larry presented the draft and its drafted use cases.
    The editors emphasized that the draft is very slim and we urgently need input from the community about use cases and real needed scenarios - otherwise we are unsure how to proceed.

    Further remarks:
    During the meeting Denis also referred to CAdES and the RFC3126

    Action items
    From the WG meeting the following action items result:
    - update milestones
    - update reqs draft concerning comments from Denis and the meeting
    - proceed and finish ers-02
    - proceed and refine ltap-00
    - get input from community for notareqs-02


    Long-Term Archive Service Requirements
    Cryptographic Maintenance Policy
    LTAP presentation
    Requirements for Data Validation and Certification Services