Last Modified: 2005-06-28
| 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 |
|
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 |