Last Modified: 2003-11-03
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.
|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|
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.