Agenda: 
1) Role of the LTANS group within the Security Area  		(Russ Housley - 5 
minutes) 
2) General introduction to technical, legal, other issues 	(Tobias 
Gondrom - 15 minutes)
3) Review of LTANS charter 					(Tobias Gondrom/Carl Wallace - 10 
minutes)
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 
minutes) 
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 
archive.

2) General introduction to technical, legal, other issues 	(Tobias 
Gondrom - 15 minutes)
3) Review of LTANS charter 					(Tobias Gondrom/Carl Wallace - 10 
minutes)
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 
recommended.

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

	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 
least)?

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

	Larry: Provided some references to distributed archive system 
research.

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

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

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

	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.