Minutes of LTANS meeting August 1, 2005 16:30 - 18:00 (attendees: ~40) ============= Action items ============= * 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 ============= Agenda Topics: ============= Administrivia ============= (file ltans.ppt) * after decrese of speed of WG from 61st IETF, take up normal schedule again * revised milestones after IETF Short update on archive requirements (reqs-04) ============= (file ltans-reqs.ppt) Comments on Archive Requirements (reqs-04). ============= (file Comments_LTANS-reqs.ppt) * idea of an attestation of deposit has been raised: a user (Client) should recieve a ticket (that might even be used for authorization) as an attestation for the deposition of the archived date. * need to store meta data * Denis expressed the need to manage accounts for the LTAP -> this has been objected by several persons deferring the management of accounts to already existing mechanisms. Cryptographic Maintenance Policy ============= (file LTANS_crypto_maintenance_policy.ppt) * encryption algorithms schould be stored to meta data, so that the server can react upon this information, e.g. send warnings when the used algorithms get insecure * Concerning Cryptography: the question has been rised wether 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 aslo losing its value by time.) * Cryptographic Maintenance Policy will change with time - 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: is one of the goals to process signatures inside the archived data packets, e.g. signature verification? Clear answer from Denis and the editors: No. * Larry: 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. introduce additional parameter Presentation of LTAP Protocol ============= (file LTAP.ppt) * Peter made the point to make the Protocol as small as possible to make it easy to implement and roll-out even minimal implementetations -> defer account management to other technology * Larry: accounts don't live very long, most probably not as long as the documents are stored. * Denis, audience: suggestion to change the retriever to "public" e.g. after 5 years - so that expired accounts might not be a problem for access... * Shall the LTA certify that certain AC has been applied? * David Black: AC could also be role based * M.T: Carrasco: design a simple level of archive so that it can be implemented easily * Peter: LTAP design is an asynchronous protocol (message send, message received and message archived) - 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 managed * also important is the mechanism to transfer data from one LTA to an other LTA and from one "policy space" 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. ltans-notareq-04, ============= (file ltans-notareqs-02.ppt) * Larry & Tobias: the draft is very slim and we urgently need input from the community about use case and real needs for the scenarios - otherwise we are unsure how to proceed Remarks: ============= Denis also referred to CAdES and the RFC3126 Tobias, Chair of LTANS