2.6.6 Long-Term Archive and Notary Services (ltans)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-11-03

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:
Nov 03  Initial requirements for long-term archive I-D
Dec 03  Revised requirements for long-term archive I-D
Dec 03  Initial data structures for long-term archive I-D
Dec 03  Initial protocol 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
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

1) Role of the LTANS group within the Security Area  		(Russ Housley - 5 
2) General introduction to technical, legal, other issues 	(Tobias 
Gondrom - 15 minutes)
3) Review of LTANS charter 					(Tobias Gondrom/Carl Wallace - 10 
4) Aerospace perspective 					(Jacqueline Knoll - did not attend)
5) Draft requirements document 					(Carl Wallace - 15 minutes)
6) Open Discussion of requirements 				(Group, Moderation: Tobias 
Gondrom - 15 minutes)
7) ATS 								(Ulrich Pordesch - 15 minutes)
8) TAP 								(Carl Wallace - 15 minutes)
9) Open discussion on mechanisms				(Group - 25 minutes)
10) WG document production plan 				(Tobias Gondrom - 10 minutes)

1) Role of the LTANS group within the Security Area  	(Russ Housley - 5 
Russ presented regarding history of the group, including background on not 
conducting this business under PKIX.  Discussion of charter's dual 
aspects, i.e. archive work based on existing drafts vs. 
investigative notary aspect.  Identifies two goals: solve the archive 
problem and investigate notary problem.  Stated that the group is 
concerned with signed data as opposed to unsigned, general purpose 

2) General introduction to technical, legal, other issues 	(Tobias 
Gondrom - 15 minutes)
3) Review of LTANS charter 					(Tobias Gondrom/Carl Wallace - 10 
Some customers have legal requirements for signed documents.  What to do 
when CA is not available or hashing algorithm is compromised, etc.  
Presented info regarding the mailing list and web site.  Questioned how to 
prove validity in 100 years, i.e. after all parties to a document are 
deceased, algorithms are weak, etc.  Presented a flow chart decribing the 
lifetime of signed data.  

	Perry: Raised a question regarding the applicability of this effort to the 
legal world.  Tobias responded that he had been narrowing the topic to 
contracts, which may not be the best example.  Point re-iterated that 
number of legal cases decided on the basis of document 
authentication is very small.  

Resumed presentation with discussion of using a notary as a trusted third 
party vs. relying on existing timestamp authority.  Notary service is 
document by document.  Timestamp-based archive is more industrial.  

	Russell: Question was asked regarding the inclusion of OCSP 
responses, certs, crls, etc.?  Answer was it depends but it is 

	Richard: Point was made that archiving the result is different than 
archiving signed data.  Suggested 7, 30 and 100 years as relevant 
landmarks to target.  Noted that spliting up data into n of m type scheme is a 
completely different aspect.  

	Larry: Point was made that IETF is in business of protocols for 
permitting different services to talk to each other.  Pointed out that 
operational means may be sufficient.  Archiving signed data is a subset of 
archiving data.  Tobias points out that the target of the group is 
somewhat different.  Problem is how to establish confidence in signed data 
that uses algorithms that grow weak.  Questions regarding format 
migration of data were asked (e.g. WordStar vs. Word).

	Hillary: Need to be clearer about scenarios.  She cited a scenario of 
ordinances that were stored in someone's basement are questioned after the 
passage of time.  Complicated problem of establishing validity of a chain of 
signatures over 100 years.  Do we expect technology that will be used for 
100 years or is it targeting a shorter time period?  Response is that the 
plan is that it would be valid in 100 years.

	Richard: So problem is verifiability of signatures after periods of time.  
Task is eliminating refutability.  

	Steve: Another way to think about it is that any involvement of the 
original parties cannot be part of the longterm solution.  Make clear the 
kinds of data that need to be acquired.  Clarify what archive needs to 
obtain and including for self-contained verification later.

	Russ: What's the format of the bits?  Operational concerns such as that are 
beyond the scope.  

	Stefan: Will protocol itself be ASN.1 or XML?  

5) Draft requirements document 				(Carl Wallace - 15 minutes)
Questions to functional req. (slide 8):
	Hillary: The requirements are not adressing the future, e.g. types of 
evidence might be changing.

	Larry: Questioned why some items were stated as MUST in the 
requirements, e.g. deleting data from archive without detection. Is that 
required in all cases?

	?: Should there be some mandatory and some optional requirements?

Questions Data Structure (11):
	Uli: no must of authentication of client due to data protection 

	Uli: replay attacks (14): concerning only retrieval access

	?: is this really necessary: The protocol MUST include a means of 
indicating the long-term archive policy under which the service 

	Richard: (long disucussion regarding receipts) What must be included in a 
receipt?  Should the receipt itself be archived?  What to do: 
verifiability of signature or secure storage of bits ?

	Larry: What about metadata ?
	Hillary: You can't force archiving service to really archive, i.e. the 
bits can always be lost.  Deletion requires authentication.

	Tobias: Is it OK to focus/rely on hash-algorithm/Pk-algs (for now at 

	Richard: Receipts - only thing needed ?  Why can't receipt contain 
everything that is ever needed?

	Larry: Provided some references to distributed archive system 

	?: If the lifetime of the parties is shorted than the storage time, 

	Larry: The are questions regarding the the timelessnes of identity of 
signers etc. If data is not included the lifetime of references to data is 
questionable, e.g. URNs.

	Pat: Advise against pursuing legal requirements.  It would take too long 
and we are the wrong place to do this.

	Richard: Suggestion to limit the scope of concern to 7 to 10 years.  
Soften the references to algorithms as we may not have 
hash-functions, etc.

	Tobias: Suggest we not limit by years but limit by what we depend on, i.e. 
acknowledge that we assume that hash algorithms and PK algorithms will 
exist and be available in the future.

	Hillary: Clients may have trouble locating the archive service, e.g. the 
service may have been sold, etc.

7) ATS 							(Ulrich Pordesch - 15 minutes)
Overview of ATS, mention of ArchiSig.  Signatures, hash algorithms or 
parameters get weak.  Statement of requirements.  practical, 
effective, law conformant.  archives containing millions of documents 
exist.  minimize need to access data.  independent of blended 
document/signature formats (i.e. PDF).  must be possible to 
optionally encrypt data submitted to an archive.  no new trusted third 
parties.  discussion of issues with rfc3126.  ats is not a service 
protocol (not necessary in context in which ATS was produced).  
discussion of hash trees, etc.  discussion of timestamp renewal.  
discussion of hash tree renewal.

	Richard: Question raised regarding intellectual property, patents, etc.

8) TAP 								(Carl Wallace - 15 minutes)

	No questions.

9) Open discussion on mechanisms				(Group - 25 minutes)

	Larry: Why are formats out of scope?  

	Russ: Don't want to deal with problem because we seek closure.  We can 
insure that the bits have not changed without breaking the signature.  

	Larry: Format issues are hard.  So are archive issues.  Might not be 
unreasonable to include some format support, i.e. indications that 
formats were changed at some point during the lifetime of the object.  
Perhaps it ought to be in scope even if solving the format problem is not in 

	Ulrich: Format conversion was considered - signature format, document 
format, etc.  Considered it as a separate service distinct from archive 
services and notary services.  It is not necessary to bundle such 
service as part of an archive.

	Larry: General question raised, in favor or against, including some 
support for formats (i.e. format conversion history).  

	Tobias: Is this work useful?  1 person yes.  No people no.  Everyone else no 

	Ulrich: There is a problem where people must renew signatures.  Every 
company, public service, etc. that wishes to use qualified signatures must 
have a solution.  Different solutions are in play.  It is an urgent 
problem to standardize formats and verification steps related to 
signature preservation.

10) WG document production plan 				(Tobias Gondrom - 10 minutes)

	Archive Requirements	- Need editor(s)
	Data structures 	- Need author(s)
	Protocol structures 	- Need author(s)
	Notary requirements	- Need author(s)

	(Larry) Questions how realistic the schedule is.  Questions has 
reasonable it is to address archiving independent of notary 
investigation.  Suggests that data structures and protocols be 
addressed in a single doc.  Also suggests that a draft of the notary 
should be begun earlier as a parking place.


Long-term Archive and Notary Services (LTANS) Working Group
Long-term Archive Service Requirements
Archive Time-Stamps-Syntax
Trusted Archive Protocol (TAP)
WG document production plan