2.6.3 Long-Term Archive and Notary Services (ltans)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-18

Chair(s):
Carl Wallace <cwallace@orionsec.com>
Tobias Gondrom <tobias.gondrom@ixos.de>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell 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 accordingly.

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
Dec 03  Initial protocol for long-term archive I-D
Done  Revised requirements for long-term archive I-D
Done  Initial data structures for long-term archive I-D
Feb 04  Last call requirements for long-term archive I-D
Mar 04  Submit requirements for long-term archive to IESG as informational
Mar 04  Revised data structures for long-term archive I-D
Mar 04  Revised protocol for long-term archive I-D
Apr 04  Last call data structures for long-term archive I-D
Apr 04  Last call protocol for long-term archive I-D
May 04  Submit data structures for long-term archive to IESG as proposed standard
May 04  Submit protocol for long-term archive to IESG as proposed standard
Jul 04  Initial requirements for notary services I-D
Sep 04  Revised requirements for notary services I-D
Sep 04  Last call requirements for notary services I-D
Dec 04  Submit requirements for notary services to IESG as proposed standard
Internet-Drafts:
  • - draft-ietf-ltans-reqs-00.txt
  • - draft-ietf-ltans-ers-00.txt
  • No Request For Comments

    Current Meeting Report

    LTANS WG Meeting Minutes (59th IETF)
    
    WG Summary 11:04-11:09 : Santosh
    	See LTANS WG Status Summary ppt for the agenda and schedule
    - no additional items to agenda were added by the participants
    - a little behind in schedule
    
    LTANS Requirements 11:10 – 11:26: Santosh
    	See LTANS Requirements-summary ppt
    - timestamps
      [Larry] requirements does not call for 3161, so should not be an issue for 
    requirements
      [Russ] we should be ok with what the current doc says, in regards to 
    patents
    - emulator
      Suggestion was to permit including applications that were used to 
    generate the archived data and/or can be used to view the data as part of 
    requirement
    - long-term identification, authentication, and authorization:
      How to define this over such a long time.
      Some suggested that it be discussed as part of requirements
      [Santosh] this could be part of signed or unsigned attributes, as part of 
    metadata.  We don’t want to mandate it in the protocol, leave optional 
      [Stefan]Authentication of access, and policies on information 
    objects, XML work XRML in OASIS
      [Santosh and Larry] this does not deals with long term I&A and 
    authorization issues.
    - New comments from the floor
      Need to separate out archive service requirements and archive 
    protocol requirements.
      No major 
    
    ERS
    - Suggestion was to use multiple hash trees (using different hash algs)
    - [Larry] Why do we need the hash trees at all 
    - [Larry] Security considerations sections should address the time based 
    threats and need to re-hash.
    
    Protocol 11:53 – 12:45 – Santosh for Peter and Alex
    - summary of protocol doc from Peter, Alex and Carl
    - [Larry] This 6 step infrastructure is confusing. 
    - [Larry] Is what to audit a protocol concern or a policy issue?  If it is a 
    protocol concern, then protocol should include audit service related 
    objects/functions.
    - In response to question, should replay attacks and idemtpotence be 
    handled in the protocol, [Larry] Protocol should protect against all 
    security threats that exist.  But without a clearly defined threat model, 
    this is tough to determine.
    - [Larry] There seems to be some presumptions in slides.  Does URI allow 
    anonymous access and how can someone get access to someone else’s 
    archived data.
    - [Santosh in response to the above]: It is assumed that both URI and TAA 
    access will require appropriate I&A and Authorization checks. But, this 
    points to additional requirements on the protocol
    - [Larry] Some metadata should also be archived.  If the archived 
    metadata can change, that points to the need to apply security services at 
    the TAA for data and metadata separately.
    - [Brian] We need to have some sort of definition of what metadata will be.
    - [Santosh] We have defined some examples, and leave it open for adding new 
    metadata types.  This provides extensibility.
    - [Larry] Slide 12: Initiate searches is concerning.  Proper scoping of the 
    searching language in the protocol should occur.
    - Slide 13: Not sure of the intent of the integrity comments.
    - [Santosh] Decision of whether link hashing should be pursued needs to be 
    first discussed off-list.
    - [Santosh] Should archival service be agnostic to signed data objects?
    - [Brian] Archive service should not validate signed data objects.
    - [Santosh] I agree.
    - [Larry] Is the index to the archived data object part of the 
    protocol?
    - [Larry] Internal archive service operations should be hidden from 
    client, should be opaque.  In the long term, this architecture will 
    change and not suitable for a client to know.
    - [Santosh] We agree.  But there are some advantages of giving back a hint to 
    retrieve the document, or evidence record.
    - [Larry] As long as they are hints and not tied to how the service 
    performs its function, we are fine.
    - [Santosh] I find their proposal good in terms of the three classes of 
    transaction
    
    Other comments
    - [Larry] I don’t know whether the results of these efforts will be 
    sufficient for a long term archival.  I don’t see the threat analysis 
    being properly discussed.
    - [Santosh] I think we did a deep security consideration in the TAP Feb 
    2003, which give a coverage of the threat analysis, for the protocol and 
    data structure.
    - [Larry] Long term issues such as loss of identity are not covered.
    - [Santosh] True.  Those are not yet covered.  If there are holes in the 
    current threat analysis, please bring it up.
    - [Larry, off-line] May be instead of this n of m (Shamir splitting) 
    technique should be 

    Slides

    LTANS Requirements
    LTANS WG Status Summary
    Introduction
    Evidence Record Syntax