From owner-ietf-ltans Tue Oct 7 09:54:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97GsJKP035313 for ; Tue, 7 Oct 2003 09:54:19 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97GsJf0035312 for ietf-ltans-bks; Tue, 7 Oct 2003 09:54:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97GsFKP035307 for ; Tue, 7 Oct 2003 09:54:18 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11466; Tue, 7 Oct 2003 12:54:04 -0400 (EDT) Message-Id: <200310071654.MAA11466@ietf.org> From: The IESG To: IETF-Announce: ; Cc: new-work@ietf.org, ietf-ltans@imc.org Subject: WG Review: Long-Term Archive and Notary Services (ltans) Date: Tue, 07 Oct 2003 12:54:03 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 14th. Long-Term Archive and Notary Services (ltans) --------------------------------------------- Current Status: Proposed Working Group 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. From owner-ietf-ltans Thu Oct 9 10:26:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99HQgKP078078 for ; Thu, 9 Oct 2003 10:26:42 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h99HQgxF078077 for ietf-ltans-bks; Thu, 9 Oct 2003 10:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from vsmtp2.tin.it (vsmtp2.tin.it [212.216.176.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h99HQdKP078057 for ; Thu, 9 Oct 2003 10:26:40 -0700 (PDT) (envelope-from tho@congo.homeunix.net) Received: from congo (80.117.16.115) by vsmtp2.tin.it (7.0.019) id 3F85701A00022BAD; Thu, 9 Oct 2003 19:25:26 +0200 Received: (nullmailer pid 6215 invoked by uid 1001); Thu, 09 Oct 2003 17:25:11 -0000 Date: Thu, 9 Oct 2003 19:25:10 +0200 From: Thomas Fossati To: IESG Cc: LTANS Subject: WG Review: Long-Term Archive and Notary Services (ltans) Message-ID: <20031009192510.A6134@congo.homeunix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, IETF seems to me the most proper venue to host LTANS wg, and I'd like to see it starting as quick as possible. Some sparse reasons follow: - The subject matter is 'hot' but requisites are not completely clear. - At present there is no open forum where to discuss the long-term non-repudiation topic and propose technical solutions (as far as I can tell). - LTANS would boost some very interesting work items started by the PKIX wg which, for one reason or another, has not reached full maturity/deployment. - Last but not least, the company I work with is going to invest in the long-term archival area for the next 2 years, and they know that an open(ly discussed) and standard interface is very desirable. Thomas From owner-ietf-ltans Tue Oct 21 07:05:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LE5YI7025752 for ; Tue, 21 Oct 2003 07:05:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LE5YwP025751 for ietf-ltans-bks; Tue, 21 Oct 2003 07:05:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LE5WI7025746 for ; Tue, 21 Oct 2003 07:05:33 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18078; Tue, 21 Oct 2003 10:05:12 -0400 (EDT) Message-Id: <200310211405.KAA18078@ietf.org> From: The IESG To: IETF-Announce: ; Cc: Carl Wallace , T Gondrom , ietf-ltans@imc.org Subject: WG Action: Long-Term Archive and Notary Services (ltans) Date: Tue, 21 Oct 2003 10:05:12 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Long-Term Archive and Notary Services (ltans) --------------------------------------------- Current Status: Active Working Group Chair(s): Carl Wallace T Gondrom Security Area Director(s): Russell Housley Steven Bellovin Security Area Advisor: Russell Housley Mailing Lists: General Discussion: ietf-ltans@imc.org To Subscribe: subscribe-ietf-ltans@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 Nov 04 Last call requirements for notary services I-D Dec 04 Submit requirements for notary services to IESG as proposed standard From owner-ietf-ltans Tue Oct 21 07:27:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEReI7026601 for ; Tue, 21 Oct 2003 07:27:40 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LERe7C026600 for ietf-ltans-bks; Tue, 21 Oct 2003 07:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LERcI7026595 for ; Tue, 21 Oct 2003 07:27:39 -0700 (PDT) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA08874 for ; Tue, 21 Oct 2003 16:27:38 +0200 (MET DST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 21 Oct 2003 16:27:39 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id h9LERbv03118 for ietf-ltans@imc.org; Tue, 21 Oct 2003 16:27:37 +0200 (MEST) Date: Tue, 21 Oct 2003 16:27:37 +0200 (MEST) From: Peter Sylvester Message-Id: <200310211427.h9LERbv03118@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: document repository - http://ltans.edelweb.fr X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is to inform you that in agreement with the chairmen the site http://ltans.edelweb.fr will contain all relevant documents concerning the activities of the groups. Best effort will be made to keep the contents up to date. Peter Sylvester From owner-ietf-ltans Tue Oct 21 07:42:46 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEgkI7027194 for ; Tue, 21 Oct 2003 07:42:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LEgknI027193 for ietf-ltans-bks; Tue, 21 Oct 2003 07:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEgjI7027186 for ; Tue, 21 Oct 2003 07:42:45 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9LEggE9005537; Tue, 21 Oct 2003 10:42:42 -0400 From: "Carl Wallace" To: "'The IESG'" , Cc: "'T Gondrom'" , Subject: RE: WG Action: Long-Term Archive and Notary Services (ltans) Date: Tue, 21 Oct 2003 10:42:37 -0400 Message-ID: <002101c397e1$95a218d0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200310211405.KAA18078@ietf.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, please note the email address for me given below is incorrect. It should be cwallace@orionsec.com. Carl -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of The IESG Sent: Tuesday, October 21, 2003 10:05 AM To: IETF-Announce: Cc: Carl Wallace; T Gondrom; ietf-ltans@imc.org Subject: WG Action: Long-Term Archive and Notary Services (ltans) A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Long-Term Archive and Notary Services (ltans) --------------------------------------------- Current Status: Active Working Group Chair(s): Carl Wallace T Gondrom Security Area Director(s): Russell Housley Steven Bellovin Security Area Advisor: Russell Housley Mailing Lists: General Discussion: ietf-ltans@imc.org To Subscribe: subscribe-ietf-ltans@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 Nov 04 Last call requirements for notary services I-D Dec 04 Submit requirements for notary services to IESG as proposed standard From owner-ietf-ltans Mon Oct 27 22:56:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S6uFI7019928 for ; Mon, 27 Oct 2003 22:56:15 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S6uFI8019926 for ietf-ltans-bks; Mon, 27 Oct 2003 22:56:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S6uDI7019901 for ; Mon, 27 Oct 2003 22:56:13 -0800 (PST) (envelope-from y-honda@sdl.hitachi.co.jp) Received: from mc3.mcg.hitachi.co.jp by hitpro.hitachi.co.jp (8.12.9p1/eHI-hitpro) id h9S6uGmW026529; Tue, 28 Oct 2003 15:56:16 +0900 (JST) Received: (from root@localhost) by mc3.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id h9S6uED08555 for ; Tue, 28 Oct 2003 15:56:14 +0900 (JST) Received: from unknown [192.168.2.1] by mc3.mcg.hitachi.co.jp with SMTP id RAA08550 ; Tue, 28 Oct 2003 15:56:14 +0900 Received: from navsg2.hitachi.co.jp by navsg2.hitachi.co.jp (8.9.3/3.7W-navsg2) id PAA25288; Tue, 28 Oct 2003 15:56:12 +0900 (JST) Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by navsg2.hitachi.co.jp (NAVGW 2.5.2.17) with SMTP id M2003102815561118087 for ; Tue, 28 Oct 2003 15:56:11 +0900 Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id PAA26829; Tue, 28 Oct 2003 15:56:11 +0900 Received: from maila.sdl.hitachi.co.jp ([133.144.14.196]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2003102815541911151 for ; Tue, 28 Oct 2003 15:54:19 +0900 Received: from jinro.sdl.hitachi.co.jp (ip06128.sdl.hitachi.co.jp [133.144.6.128]) by maila.sdl.hitachi.co.jp (8.9.3/3.7W02021014) with SMTP id PAA17139 for ; Tue, 28 Oct 2003 15:56:11 +0900 Message-Id: <200310280656.AA00285@jinro.sdl.hitachi.co.jp> From: Yoshinori HONDA Date: Tue, 28 Oct 2003 15:56:58 +0900 To: ietf-ltans@imc.org MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: $BK\B?$G$9!#(B [Tue, 28 Oct 2003 15:56:51 +0900] From owner-ietf-ltans Fri Oct 31 03:57:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VBvhkT086510 for ; Fri, 31 Oct 2003 03:57:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VBvhEc086509 for ietf-ltans-bks; Fri, 31 Oct 2003 03:57:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VBvekT086503 for ; Fri, 31 Oct 2003 03:57:41 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id h9VBvWEY003661; Fri, 31 Oct 2003 12:57:33 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 12:58:38 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D517F@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Cc: "Carl Wallace (E-mail)" Subject: LTANS - WG: last call for topics for the agenda for WG meeting at IETF conference 11/11/2003 Date: Fri, 31 Oct 2003 12:58:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9VBvgkT086505 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, as we already start with our first WG meeting on November 11, I would like to announce the last call for topics for the agenda. If you have something you want to adress or propose, please contact me and Carl until November 4th. (please also provide some detailed information about the motivation and the content of the presentation) To offer a first glance on the proposed agenda, here is the current preliminary version. Agenda: Role of the LTANS group within the Security Area (Russ Housley - 5 minutes) General introduction to technical, legal, other issues (Tobias Gondrom - 15 minutes) Review of LTANS charter (Tobias Gondrom/Carl Wallace - 10 minutes) Aerospace perspective (Jacqueline Knoll - 15 minutes) Draft requirements document (Carl Wallace - 15 minutes) Open Discussion of requirements (Group, Moderation: Tobias Gondrom - 15 minutes) ATS (Ulrich Pordesch - 15 minutes) TAP (Carl Wallace - 15 minutes) Open discussion on mechanisms (Group - 25 minutes) WG document production plan (Tobias Gondrom - 10 minutes) The final version of the agenda will be available on November 5th. Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/München E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielfältigung oder Weitergabe ist nicht gestattet. From owner-ietf-ltans Fri Oct 31 11:51:57 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJpvkT004406 for ; Fri, 31 Oct 2003 11:51:57 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJpvps004405 for ietf-ltans-bks; Fri, 31 Oct 2003 11:51:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJpukT004392 for ; Fri, 31 Oct 2003 11:51:56 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9VJpvXB001006 for ; Fri, 31 Oct 2003 14:51:57 -0500 From: "Carl Wallace" To: Subject: draft requirements doc Date: Fri, 31 Oct 2003 14:51:52 -0500 Message-ID: <00d301c39fe8$7125d640$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01C39FBE.884FCE40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00D4_01C39FBE.884FCE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit An initial draft of the long-term archive service requirements document has been posted to http://ltans.edelweb.fr/draft-ietf-ltans-reqs-00.txt. Please review and post any comments to the list. We will discuss the draft at the WG session in Minneapolis next month. ------=_NextPart_000_00D4_01C39FBE.884FCE40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
An = initial draft of=20 the long-term archive service requirements document has been posted to = http://ltan= s.edelweb.fr/draft-ietf-ltans-reqs-00.txt.   =20 Please review and post any comments to the list.  We will discuss = the draft=20 at the WG session in Minneapolis next month.
 
 
------=_NextPart_000_00D4_01C39FBE.884FCE40-- From owner-ietf-ltans Sat Nov 1 04:28:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSYkT008555 for ; Sat, 1 Nov 2003 04:28:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1CSYO5008554 for ietf-ltans-bks; Sat, 1 Nov 2003 04:28:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSWkT008548 for ; Sat, 1 Nov 2003 04:28:33 -0800 (PST) (envelope-from Hannes.Tschofenig@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVF29118 for ; Sat, 1 Nov 2003 13:28:32 +0100 (MET) Received: from joe (lnxekv1-07.esn.sbs.de [149.246.36.7]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVs27566 for ; Sat, 1 Nov 2003 13:28:31 +0100 (MET) From: "Hannes Tschofenig" To: Subject: Date: Sat, 1 Nov 2003 13:27:43 +0100 Message-ID: <000001c3a073$8d72f3b0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: subscribe From owner-ietf-ltans Mon Nov 3 08:39:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3GdAkT040365 for ; Mon, 3 Nov 2003 08:39:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3GdApE040364 for ietf-ltans-bks; Mon, 3 Nov 2003 08:39:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3Gd8kT040357 for ; Mon, 3 Nov 2003 08:39:08 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA15265; Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Gd0U02088; Mon, 3 Nov 2003 17:39:00 +0100 (MET) Date: Mon, 3 Nov 2003 17:39:00 +0100 (MET) From: Peter Sylvester Message-Id: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> To: ulrich.pordesch@sit.fraunhofer.de, cwallace@orionsec.com, ralf_brandner@med.uni-heideberg.de Subject: draft-ietf-ltans-reqs-00.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here some comments: For the German collegues, I use a rather "French style" of writing The difference is essentially: Pb: a German and a French person talk about the first initial draft and the goal is that it is a starting point and one needs to continue. - The French would say: "This draft is a completely unacceptable way to solve the problem." ==> The German would stop working (believing that everything is bad). - The German would say: "This is already a good starting point." ==> The French would stop working 'believing that everything is ok). :-) So now, a bit of brain storming: > It is anticipated that a timestamp containing a digital signature > will be obtained for data submitted to a long-term archive service. > Thus, for all types of data, i.e. signed and unsigned, one or more > digital signatures will exist that require preservation by the long- > term archive service. I do not think that this phrase is good in the introduction, in particular the wording of 'time stamp containing a digital signature'. Why do 'signatures require preservation'? The data itself need it. > This document aims to identify the technical requirements for a long- > term archive service charged with preservation of digitally signed > data in an X.509 certificate-based PKI. I disagree with this definition, i.e. with the second part staring with 'charged with ...' > Operational requirements, such as storage media concerns, individual > legal requirements and questions dealing with accountability are not > addressed by this document. I disagree that questions concerning accountability are not addressed. At least clients should be probperly identifiable. There may be just wording problem 'accountability" vs "accounting and billing techniques". At least a requeirement must be: "The transaction data and protocols must allow to carry either directly or indirectly information that allow to associate each transaction to some accounting and billing meachnism, examples are identifiers for individual clients and/or large customers. Some raw requirements (oops, I saw that some of them are already in), soory I didn't read all while I was writing. - An archive service provider MUST NOT be able to insert data in a non chronological way, i.e., if some data are archived and time stamped, no data with a older time stamp can be inserted. - An archive service MUST NOt be able to delete data from the archive with detecting, or in other words, the service must be able to prove that nothing has been deleted. - An archive service MUST allow to transfer completely or partially, archived data to another services provider without loss of the global integrity property defined above. - An archive service MUST allow to delete completely or partially, archived data to another services provider without loss of the global integrity property defined above. (This can for example be accomplished by transfering data to a fictious "archiver"). Deleting may becontrolled by a policy, but needs exceptions. I think the previous can be deduced from several of the existing text, in particular, about evidence for groups etc. - The archive service MUST be able to provide evidence about the policies that have been used at any time. - The format for the evidence/acknowledgements MUST allow to identify the archiving provider. - The format for the evidence/acknowledgements MUST allow (at least the creating the archiving provider) to identify the participating client. - A client or other relying parties MUST be able to prove that a particular acknowledgement (attestation) belongs to a request may by the client. I an simple case, a gloabl identifier of the client is used, for example. - It MUST be possible to include metadata concerning the data, for example a mime type, a short description in clear in the acknowlegments (attestations). - A broker style service provider should be able to relay requests to back end service providers. - A provider should be able to provide the service in a staged way, i.e. provide initial acknowledgements for by final ones. This is important in order to avoid a simgle point of failure. - A client may obtain final acknoledgements either by an asynch method, e.g. mail, or by a polling technique (maybe combined with a notification), cf. SAML - An acknowledgement/attestion is a verifyable statement from the archive provider confirming the acceptance and (maybe partial) fulfillment of the requested action. Short term verifiability needs to be ensured for the requesting client but also for other relying parties (e.g. signature shared secret authentication, ...) Long term authenticity can be ensured by a particular service. Comment about: - The protocol MUST define interactions with a Long-term Archive Service including, at a minimum: submission of data or groups of data for preservation, retrieval of archive packages and deletion of archived data and associated evidence records. I think the protocol should allow the validation of a acknowledge. Or, this would be a "confirm existence" vs "retrieval" of archive packages. - The protocol must allow that a "confirm existance" may return a reference of another archive provider. Chapter 3: - The model should allow for relays. - If I understand it right, the TSA is used as a security mechanism by the TAA. I think one should not restrict this and open this to other mechanisms, e.g. an service provider can use another backend archive, can archive just all its transaction logs (or acknowledgements), - The text makes a lot of assumption about timestamps, in particular that a time stamp has a signature. I think one should weaken this. time stamping using hash linking is a technique that allows independance of secrets, and also, as a side effect, links all time stamps together, thus, is a good mesure to protect against undetected loss of archived data, or against false inclusions etc. to resumee: Good start :-) Regards Peter From owner-ietf-ltans Mon Nov 3 09:56:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HugkT043858 for ; Mon, 3 Nov 2003 09:56:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3HugK6043857 for ietf-ltans-bks; Mon, 3 Nov 2003 09:56:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HuekT043850 for ; Mon, 3 Nov 2003 09:56:41 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA15871 for ; Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Hudg02285 for ietf-ltans@imc.org; Mon, 3 Nov 2003 18:56:39 +0100 (MET) Date: Mon, 3 Nov 2003 18:56:39 +0100 (MET) From: Peter Sylvester Message-Id: <200311031756.hA3Hudg02285@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: long term Archive Architecture X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I have received a docuiment from two colleagues Libor and Marta in the Czech republic. So far, awaiting some comment from the chairmen, I have put the document in the ltans web server into the "related documents" section. --- forwarded message : From: "Marta.Vohnoutova@pvt.cz" Date: Mon, 3 Nov 2003 18:13:15 +0100 Dear Peter, I am very glad that I can send you the Long-term archiving - draft proposal which we (Libor Dostalek and Marta Vohnoutova) have made. You can see that we worked hard to help our ietf-ltans-arch group to progress. We put there our experiences with the "special world" of real archivists who will unavoidably talk to the long-term archiving project. This is a draft proposal and we expect and we would be very glad if other authors thing over our material. But we think it could be a very good starting point. Please bo so kind - read the attached material throroughly, put it on your web site and announce to the conference participants that new draft proposal exists. Looking forward to any comments Best regards Cordially Libor and Marta P.S. Because of necessary pictures we transformed the file into the PDF form (because of the rastr - the best view is if the scale is 100%. From owner-ietf-ltans Wed Nov 5 06:13:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDikT081544 for ; Wed, 5 Nov 2003 06:13:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5EDiDL081543 for ietf-ltans-bks; Wed, 5 Nov 2003 06:13:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDgkT081534 for ; Wed, 5 Nov 2003 06:13:43 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-138-88-47-253.res.east.verizon.net [138.88.47.253]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA5EDZKJ018447; Wed, 5 Nov 2003 09:13:35 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , , Cc: Subject: RE: draft-ietf-ltans-reqs-00.txt Date: Wed, 5 Nov 2003 09:13:36 -0500 Message-ID: <000301c3a3a7$01496900$6501a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5EDhkT081535 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the comments and additional requirements. A few comments are inline below... > I do not think that this phrase is good in the introduction, > in particular the wording of 'time stamp containing a digital > signature'. Why do 'signatures require preservation'? The > data itself need it. I agree the wording is a little awkward and in general the draft may be overly prescriptive w.r.t. to timestamps as a mechanism, though this is based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there will always be one or more digital signatures present is based on assumptions that data submitted to an archive will be timestamped and that timestamps include a signature. Signatures require preservation due to the decreasing value of the objects used to verify the signature, etc., etc. > I disagree with this definition, i.e. with the second part > staring with 'charged with ...' OK. We can strike the reference to the environment and leave that to the mechanism specs. > - An archive service provider MUST NOT be able to insert data in a > non chronological way, i.e., if some data are archived and > time stamped, > no data with a older time stamp can be inserted. I not sure I agree with this. If I have a document with timestamp 1 and you have a document with timestamp 2, I shouldn't be prevented from archiving my document because you submitted your doc first. If you mean that the archive itself must never apply a timestamp older than a previously applied timestamp, then I agree. > - An archive service MUST NOt be able to delete data from the > archive with > detecting, or in other words, the service must be able to prove that > nothing has been deleted. > > - An archive service MUST allow to transfer completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. > > - An archive service MUST allow to delete completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. (This can for example > be accomplished by transfering data to a fictious "archiver"). > Deleting may becontrolled by a policy, but needs exceptions. Perhaps we need a section addressing operational requirements. > - A provider should be able to provide the service in a staged way, > i.e. provide initial acknowledgements for by final ones. This is > important in order to avoid a simgle point of failure. This may also be important if there is to be support for a grace period to accommodate compromise declaration after submission. > - If I understand it right, the TSA is used as a security > mechanism by the TAA. I think one should not restrict this > and open this to other mechanisms, e.g. an service > provider can use another backend archive, can archive just > all its transaction logs (or acknowledgements), In this case the TAA is acting as a client to another TAA. There's nothing in the draft to restrict this type of interaction. > - The text makes a lot of assumption about > timestamps, in particular that a time stamp has a signature. I think > one should weaken this. time stamping using hash linking is > a technique > that allows independance of secrets, and also, as a side effect, > links all time stamps together, thus, is a good mesure to protect > against undetected loss of archived data, or against false > inclusions etc. Are there any timestamp formats that should be considered that don't feature digital signatures? RFC3161 and ATS both feature signatures. From owner-ietf-ltans Wed Nov 5 07:40:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeOkT085262 for ; Wed, 5 Nov 2003 07:40:24 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FeO8X085261 for ietf-ltans-bks; Wed, 5 Nov 2003 07:40:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeMkT085252 for ; Wed, 5 Nov 2003 07:40:23 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA29551 for ; Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA5FeHj06929 for ietf-ltans@imc.org; Wed, 5 Nov 2003 16:40:17 +0100 (MET) Date: Wed, 5 Nov 2003 16:40:17 +0100 (MET) From: Peter Sylvester Message-Id: <200311051540.hA5FeHj06929@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: draft-ietf-ltans-reqs-00.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > I do not think that this phrase is good in the introduction, > > in particular the wording of 'time stamp containing a digital > > signature'. Why do 'signatures require preservation'? The > > data itself need it. > > I agree the wording is a little awkward and in general the draft may be > overly prescriptive w.r.t. to timestamps as a mechanism, though this is > based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there > will always be one or more digital signatures present is based on > assumptions that data submitted to an archive will be timestamped and that > timestamps include a signature. Signatures require preservation due to the > decreasing value of the objects used to verify the signature, etc., etc. I think we are able to find a wording which is sufficiently neutral. > > > I disagree with this definition, i.e. with the second part > > staring with 'charged with ...' > > OK. We can strike the reference to the environment and leave that to the > mechanism specs. Ok. > > > > > - An archive service provider MUST NOT be able to insert data in a > > non chronological way, i.e., if some data are archived and > > time stamped, > > no data with a older time stamp can be inserted. > > I not sure I agree with this. If I have a document with timestamp 1 and you > have a document with timestamp 2, I shouldn't be prevented from archiving my > document because you submitted your doc first. If you mean that the archive > itself must never apply a timestamp older than a previously applied > timestamp, then I agree. the usage of the overloaded word time stamp (as you mention, the client data may already have one in some way, and the server may add another) is perhaps a problem. Indeed I mean basically the second thing. In fact, I am not sure whether strict linear order is required in the global sense, if you have trees of hashes. indeed, a client may have obtained some time stamp or "file seal" much earlier in order to have a proof of the existance, and this is not related to the time of archiving. > > > - An archive service MUST NOt be able to delete data from the > > archive with > > detecting, or in other words, the service must be able to prove that > > nothing has been deleted. > > > > - An archive service MUST allow to transfer completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. > > > > - An archive service MUST allow to delete completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. (This can for example > > be accomplished by transfering data to a fictious "archiver"). > > Deleting may becontrolled by a policy, but needs exceptions. > > Perhaps we need a section addressing operational requirements. I think input from some real archiving providers may be helpful. > > > > - A provider should be able to provide the service in a staged way, > > i.e. provide initial acknowledgements for by final ones. This is > > important in order to avoid a simgle point of failure. > > This may also be important if there is to be support for a grace period to > accommodate compromise declaration after submission. Yes. > > > > > - If I understand it right, the TSA is used as a security > > mechanism by the TAA. I think one should not restrict this > > and open this to other mechanisms, e.g. an service > > provider can use another backend archive, can archive just > > all its transaction logs (or acknowledgements), > > In this case the TAA is acting as a client to another TAA. There's nothing > in the draft to restrict this type of interaction. Right > > - The text makes a lot of assumption about > > timestamps, in particular that a time stamp has a signature. I think > > one should weaken this. time stamping using hash linking is > > a technique > > that allows independance of secrets, and also, as a side effect, > > links all time stamps together, thus, is a good mesure to protect > > against undetected loss of archived data, or against false > > inclusions etc. > > Are there any timestamp formats that should be considered that don't feature > digital signatures? RFC3161 and ATS both feature signatures. Yes. At least in a second step: A client only needs a strong authentication method to validate a server when the time stamp is obtained. This is in general done by a signature. If you use hash linking, and if you publish in regular intervals the last hash, a client can ask for an extended time stamp which includes a hash chain up to the published one. This extended time stamp no longer depends on the security of keys, only on the hash function. See: http://ltans.edelweb.fr/Cybernetica-OpenEvidence-TimeStamping.pdf or at the http://www.cyber.ee Peter ----- End Included Message ----- From owner-ietf-ltans Thu Nov 20 06:48:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmYkT034255 for ; Thu, 20 Nov 2003 06:48:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKEmYfo034254 for ietf-ltans-bks; Thu, 20 Nov 2003 06:48:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmTkT034244 for ; Thu, 20 Nov 2003 06:48:32 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA05195 for ; Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hAKEmOn08990 for ietf-ltans@imc.org; Thu, 20 Nov 2003 15:48:24 +0100 (MET) Date: Thu, 20 Nov 2003 15:48:24 +0100 (MET) From: Peter Sylvester Message-Id: <200311201448.hAKEmOn08990@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: draft minutes X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The draft minutes of the IETF58 meeting are avialable in the web server. Since I was not able to participate, here some comments concerning several items mentioned in the minutes. It is really nice to see comments and questions in a raw form, this gives a better impression of the discusson, and allows to better ask for clarifications than with a 'summary by the chairman' approach. Thus: Agenda 1) : > Stated that the group is concerned with signed data as opposed to unsigned, general purpose archive. What exactly is meant by 'signed data'. I think the purpose is to 'archive and/or notarize authentifiable representations of information'. If signed data means that the data to be archived need to have some characteristics that can be considered as an equivalent of all aspects of what is called 'signature' for a paper document, then ok. The difference between archive and notoarize may be floating. If the archive provider cares a little bit of the semnatics of the document, for example when seome future conversion may be planned, then this can be considered as the first step of a notarisation operation; A real notarisation (depending on which culture you think about) can just end here (public notary) or continue to validate and assert the conformance to some legal procedure (EU continent). Agenda 3) : Having siad the previous, I don't think that one should even try to address the long term validaty of digital signature chains by using any cryptographic approach that includes secrets. Digital signatures are for strong authentication (IMHO) and not a sufficintly stable means for long term. It seems important to me that the underlying service model assumes that there is at least one additional redundant mechanism that can be used to prove the "existance" of some data at:before a certain time, e.g. physical protection with strong ordering of the storage media. > "Complicated problem of establishing validity of a chain of signatures over 100 years." Can someone give a paper equvalent example? 5) The requireemnts doc is a first attempt. "deleting data from archive without detection" : The requirement is not that one must not be able to delete without detecting, but rather that the archiver may be interested to prove at any time the global integrity of the data he has, or that if some data are not there, then they had never been there. This can be done in different ways, in a simple way by never deleting anything. > Hillary: You can't force archiving service to really archive, i.e. the bits can always be lost. Deletion requires authentication. I am not sure what is meant here. > 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. For whatever type of document, the inclusion of metadata describing the actual format (like a mime type, or oid, or schema, ...) should not be excluded as part of the input. Some of these metadata may provide sufficient redundancy information concerning the 'information structure' allowing a conversion in the future. Such a conversion can occur either on request of some client, or by some global service action, in this case the service provider can convert the data, and keep a history of the actions. The service provider is able to return the archived information in a representation which is 'state of the art' plus, optionally traces about the orginal formats and the conversions that had been done (like copied from hand written paper to machine written paper and signed by some authority). regards Peter From owner-ietf-ltans Wed Dec 17 13:11:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBZib096360 for ; Wed, 17 Dec 2003 13:11:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHLBZIt096359 for ietf-ltans-bks; Wed, 17 Dec 2003 13:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBYib096354 for ; Wed, 17 Dec 2003 13:11:34 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hBHLBV2L027493; Wed, 17 Dec 2003 16:11:31 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , Subject: RE: draft minutes Date: Wed, 17 Dec 2003 16:11:26 -0500 Message-ID: <000801c3c4e2$5877b900$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200311201448.hAKEmOn08990@chandon.edelweb.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBHLBZib096355 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Peter, Sorry the response is so delayed - some comments are inline below. > Agenda 1) : > > Stated that the group is concerned with signed data as opposed to > > unsigned, general purpose archive. > > What exactly is meant by 'signed data'. I think the purpose is to > > 'archive and/or notarize authentifiable representations of > information'. > > If signed data means that the data to be archived need to > have some characteristics that can be considered as an > equivalent of all aspects of what is called 'signature' for a > paper document, > then ok. I think the comment was simply distinguishing between archiving in the sense this group is considering and a backup solution. > The difference between archive and notoarize may be floating. > If the archive provider cares a little bit of the semnatics > of the document, for example when seome future conversion may > be planned, then this can be considered as the first step of > a notarisation operation; A real notarisation (depending on > which culture you think about) can just end here (public > notary) or continue to validate and assert the conformance to > some legal procedure (EU continent). > > Agenda 3) : > > Having siad the previous, I don't think that one should even > try to address > the long term validaty of digital signature chains by using > any cryptographic > approach that includes secrets. Digital signatures are for > strong authentication (IMHO) and not a sufficintly stable > means for long term. > It seems important to me that the underlying service model > assumes that there is at least one additional redundant > mechanism that can be used to prove the "existance" of some > data at:before a certain > time, e.g. physical protection with strong ordering of the > storage media. At what point would you deem verification of digital signatures not worthy of consideration? One of the comments in the minutes offered 7, 30 and 100 years as benchmarks. Would any of those qualify? Given that the accrual of signatures is due to timestamp refresh (in the specs that served as input to this group anyway), it may be sufficient to define archive structures that are timestamp format agnostic to accommodate non-signature-based timestamp solutions. There seems to be some general agreement regarding refreshed timestamps as a tool useful for archiving. The applicability of the linking hash approach to IETF work is not clear to me due to patent issues. > > "Complicated problem of establishing validity of a chain of > signatures > > over 100 years." > > Can someone give a paper equvalent example? The "Long Term Archive Architecture" gave a comic counterexample. In any case, whether or not a chain of digital signatures would ever be verified to prove the validity of a signature that is hundreds of years old or to make claims regarding the content of the associated data isn't necessarily relevant. It's just an extreme extension of the mechanisms that have been presented so far. From owner-ietf-ltans Thu Dec 18 14:18:27 2003 Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMIPib039986 for ; Thu, 18 Dec 2003 14:18:26 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Fri, 19 Dec 2003 01:24:08 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Fri, 19 Dec 2003 01:24:08 $B0l?MJk$i$7$O; Fri, 19 Dec 2003 07:53:51 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBJFrp1m056086 for ietf-ltans-bks; Fri, 19 Dec 2003 07:53:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJFrnib056081 for ; Fri, 19 Dec 2003 07:53:50 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA09394; Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hBJFrmY15369; Fri, 19 Dec 2003 16:53:48 +0100 (MET) Date: Fri, 19 Dec 2003 16:53:48 +0100 (MET) From: Peter Sylvester Message-Id: <200312191553.hBJFrmY15369@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, cwallace@orionsec.com Subject: Re: draft minutes Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Did you intend to respond offlist? If not, feel free to forward my response > to the list. Comments below... A bug in my mail reader's reply function, it didn't detect the list. Thanks, Sun. > > > I think the comment was simply distinguishing between archiving in the > sense > > > this group is considering and a backup solution. > > > > The distinction seems not not to explain to me, technically the > > difference may be very small. > > Yes, the difference may be very small. I was only giving my interpretation > of what Russ said during the introduction. I never considered unsigned data > as beyond out concern. ok. > > > "not worthy of consideration" is not exactly what I had in mind. "Not > being > > able anymore by definition". the cryptographic validation of a signature > > aginst a certificate as the ONLY means to validate it can only be done > > rather shortly after the signature. > > I took your point to be that we should define a solution that does not use > any cryptographic mechanism that relies on secrets and agree completely. I > don't agree (at least not yet) that secret based, e.g. signature, mechanisms > can not be part of the solution. Ok. > > Just an example: > > SMIME contains a linking of hashes, i.e. > sign(hash(hash(data),attributes)), > > and if you consider that the data can be a hash+time, then there is > > even an additional indirection. > > I don't think that so far, any of the hash linking patent holders has > > tried to challenge this, or at least they lost as far as I remember. > > OK. .. > > > I know only one (other?) person convinced, and trying to convince that > > refreshed time stamps are *THE* tool. The difference is whether it > > is one of possible security measures, or whether this is consider > > as a 100% secure measure and no others are necessary since no redunancy > > problem exist. > > I've not heard anyone assert that refreshed timestamps are *THE* tool, in > the sense that they are sufficient alone to provide the solution. I have > heard folks who favor procedural controls over such mechanisms entirely. In > any case, there are multiple references, in IETF alone, asserting refreshed > timestamps as *A* tool. A slippery road. I tend to be careful to say anything abut the validity of 30 or 100 years, except that microfilm and paper have known qualities. > > It doesn't seem very important to make a decision about whether > > this or that mechanism is the right one, it would even be a disaster > > since it seems desirable to able to change/add new technologies, > > in order to avoid surprises like with "all you need is to > > make magnetic tapes" or else. > > It is important that we make decisions regarding mechanisms (and > procedures/processes/etc?) if we intend to produce standards in this area. I used bad wording. The decision cn be about a currently selection of techniques and a framework allowing enhancements that won't make previous techniques obsolete and may allow even migration. > > > 100 years later or, what counts > > is the statement of the archiver/notariser telling whether a document > > is valid. In general, you don't challenge the notary if it follows a > > correct procedure etc.; it is in our interest to define architectures > > and principles that have security characteristics similar to existing > > paper techniques. > > It is also in our interest to define evidence to support claims by > archivers/notaries. Yes. I think that we are sufficiently in phase now. I wonder whether the people who are mentioned in the minutes could repeat or explain their comments (if they are subscribed to the list). My capacity of listening distant conversations or telepathy are somewhat limited. :-) regards From owner-ietf-ltans Sat Dec 20 07:35:52 2003 Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBKFZoib094348 for ; Sat, 20 Dec 2003 07:35:51 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Sun, 21 Dec 2003 00:35:41 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Sun, 21 Dec 2003 00:35:41 $B0l?MJk$i$7$O; Wed, 24 Dec 2003 15:34:30 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Thu, 25 Dec 2003 08:34:22 Subject: =?ISO-2022-JP?B?GyRCMj8kLDklJC0kSiROISkbKEI=?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: <5hf52mdyvmncgrz.251220030834@203.141.35.113> Date: Thu, 25 Dec 2003 08:34:22 $B$$$$$h!y$J$s$G$b:n$C$F$"$2$k$h!!:#EY2q$&$H$-$^$G$K7h$a$F$*$$$F$M(B(^_^)v From owner-ietf-ltans Tue Dec 30 04:34:07 2003 Received: from 203.141.35.113 (142.232.109.219.ap.yournet.ne.jp [219.109.232.142]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUCY5ib058730 for ; Tue, 30 Dec 2003 04:34:06 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Tue, 30 Dec 2003 21:03:49 Subject: =?ISO-2022-JP?B?GyRCJEQkXiRzJEokJCRoJCkbKEI=?=(T_T)/~~~ From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Tue, 30 Dec 2003 21:03:49 $B$+$J$j2K$7$F$k$N$)!#%a%#%k$A$g!#(B From owner-ietf-ltans Fri Jan 2 23:01:59 2004 Received: from netscape105.com (a64021.upc-a.chello.nl [62.163.64.21]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0371sib054186 for ; Fri, 2 Jan 2004 23:01:55 -0800 (PST) (envelope-from zuka2006@netscape.net) Message-Id: <200401030701.i0371sib054186@above.proper.com> From: Zuka To: ietf-ltans-bks@above.proper.com Reply-To: zuka2006@netscape.net Subject: MR.MUDIWA ZUKA Date: Sat, 03 Jan 2004 08:02:30 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5009bf94-5f1f-4a2f-b67a-faef2ea52bf7" This is a multi-part message in MIME format --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable DEAR SIR. HAPPY NEW YEAR .I AM A GIRL OF 25 YEARS OLD AND I AM LOOKING FOR INVESTMENT = OPPORTUNITY. I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS = INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE = NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME THROUGH = THIS EMAIL zuka2008@excite.com BEST REGARDS MS. MUDIWA ZUKA --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7-- From owner-ietf-ltans Mon Jan 12 09:41:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHfBib096845; Mon, 12 Jan 2004 09:41:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CHfBDt096844; Mon, 12 Jan 2004 09:41:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.89.ixos.de [149.235.31.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHf2ib096817 for ; Mon, 12 Jan 2004 09:41:09 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i0CHeswI004219 for ; Mon, 12 Jan 2004 18:40:55 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Mon, 12 Jan 2004 18:40:54 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Subject: Initial requirements for long-term archive I-D Date: Mon, 12 Jan 2004 18:40:52 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3D933.398CBCB0" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D933.398CBCB0" ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D " (first milestone, unfortunately 6 weeks behind schedule) <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data = structures and protocol) will be targeting to fulfill the discussed requirements. = The initial drafts for these 2 documents are also behind schedule but = initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind: - discuss the different sections for the document individually - if possible list the chapter you want to change and the old and the = new text to make it easier for the others to follow the discussion and for = the editor. At the moment there are even topics for dicusiion open from the writing = of the initial paper. Best regards Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/M=FCnchen E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com =20 Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Initial requirements for long-term archive I-D

Hello,

Thanks to Carl, Uli and Ralf we = finished the
"Initial requirements for long-term archive I-D "
(first milestone, unfortunately 6 = weeks behind schedule)
= <<draft-ietf-ltans-reqs-01.txt>>

I would like to encourage now the = discussion for this draft on the mailing-list as fast as possible as = the following standards (data structures and protocol)  will be = targeting to fulfill the discussed requirements. The initial drafts for = these 2 documents are also behind schedule but initial documents shall = be available for discussion end of january.

Please keep best practices for the = discussion in mind:
- discuss the different sections for = the document individually
- if possible list the chapter you = want to change and the old and the new text to make it easier for the = others to follow the discussion and for the editor.

At the moment there are even topics = for dicusiion open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may = contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the sender immediately and destroy this eMail. Any use, disclosure or = distribution of the material in this eMail is strictly = forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie bitte sofort den Absender und vernichten Sie diese = eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe = ist nicht gestattet.

------_=_NextPart_001_01C3D933.398CBCB0-- ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: text/plain; name="draft-ietf-ltans-reqs-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltans-reqs-01.txt" Internet Draft Carl Wallace=20 draft-ietf-ltans-reqs-01.txt Orion Security Solutions=20 January 2004 Ralf Brandner=20 Expires July 2004 InterComponentWare AG Walldorf Ulrich Pordesch=20 Fraunhofer Institute=20 Secure Telecooperation=20 =20 =20 Long-term Archive Service Requirements=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of [RFC2026]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced or made obsolete by other documents at=20 any time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2004). All Rights Reserved.=20 =20 Abstract=20 =20 In many scenarios, users need to be able to ensure and prove the=20 existence and integrity of data, especially digitally signed data, = in a common and reproducible way over a long and possibly undetermined=20 period of time. This document specifies the technical requirements=20 for a long-term archive service to support such scenarios.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in [RFC2119].=20 Wallace Expires July 2004 [Page 1] =0C Long-term archive service requirements January 2004=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Terminology....................................................3=20 3. Application scenarios and general requirements.................4=20 3.1 Long-term archive problems and tasks.......................4=20 3.2 Long-term Archive Service..................................5=20 3.3 Instances and overall architecture.........................7=20 4. Long-term Archive Service functional and quality requirements..8=20 5. Long-term Archive Service data structure requirements..........9=20 6. Long-term Archive Service Protocol requirements...............10=20 7. Security Considerations.......................................11=20 8. Acknowledgements..............................................11=20 9. Normative References..........................................11=20 10. Authors' Addresses...........................................13=20 =20 =20 1. Introduction=20 =20 Various scenarios require the ability to preserve digital data and=20 its value as evidence for long periods of time. If data is = important=20 and will be needed in the future, it is necessary to store it in a=20 highly secure and persistent way. If the data is needed as evidence=20 in court, it may be necessary to prove that the existed at a certain = time in the past and has not been modified since then. If data is=20 signed or timestamped it is necessary to prove that it existed = before=20 cryptographic algorithms used to generate its signatures became weak = or the certificates expired or were revoked. =20 =20 A long-term archive service aids in the preservation of data over=20 long periods of time. In particular, it periodically performs=20 activities to preserve the non-repudiation of existence and = integrity=20 as well as ensuring the availability of data.=20 =20 A variety of technical and operational means are required to achieve = this goal and technical issues beyond cryptography, such as storage=20 media lifetime, disaster planning, changes in processing or software = technology, etc., as well as legal issues must be addressed.=20 =20 It is anticipated that a timestamp will be obtained for data = submitted to a long-term archive service. Thus, for all types of data, i.e.=20 signed and unsigned, will require preservation of evidence value by=20 the long-term archive service. =20 =20 Any digital signature that may need to be verified at points in time = well into the future, e.g. past the certificate validity period or=20 past the cryptoperiod of the signature private key, is a candidate=20 for preservation using a long-term archive service. Examples = include=20 =20 =20 Wallace Expires July 2004 [Page 2] =0C Long-term archive service requirements January 2004=20 signed contracts or agreements, wills, property deeds, CRLs and=20 timestamps over any type of data. The service will provide means to = prove the integrity and time of existence of the data at a given=20 point in time. It must be provable that the data is reliable,=20 because it existed at a point in time in the past when e.g. the=20 embedded hash and signature algorithms were still strong and the=20 included certificates were not revoked.=20 =20 This document aims to identify the technical requirements for a = long- term archive service. The=20 requirements analysis is divided into two parts.=20 The first part presents several application=20 scenarios. The second part addresses more specific requirements for = functions of the service, data structures to support preservation of data integrity using cryptographic mechanisms and at least protocol=20 requirements for interacting with a long-term archive service.=20 =20 Operational requirements, such as storage media concerns, individual = legal requirements and questions dealing with accounting and billing = techniques are not addressed by this document. However, the=20 transaction data and protocols must allow information to be carried=20 either directly or indirectly to facilitate association of=20 transactions with some accounting and billing mechanism, e.g.=20 identifiers for individual clients and/or large customers.=20 =20 =20 2. Terminology=20 =20 Arbitrator: Person, who has to be convinced of various aspects of=20 authenticity (originator, integrity, time of existence) of archived=20 data objects.=20 =20 Archived data object: Data unit that is archived and has to be=20 preserved for a long time by the Long-term Archive Service. =20 =20 Archive package: Collection of information including archived data=20 objects and the associated evidence record.=20 =20 Evidence: Information that may be used to resolve a dispute about=20 various aspects of authenticity of archived data objects. =20 =20 Evidence record: Collection of evidence compiled for one or more=20 given archived data objects over time. An evidence record may=20 include timestamps and additional verification data, like=20 certificates, revocation information, trust anchors, policy details, = role information, etc.=20 =20 Originator: Role (person or process) who produces, and possibly=20 signs, a data object that is to be archived. The Originator does=20 not necessarily generate or request generation of an evidence record = for the data.=20 =20 =20 Wallace Expires July 2004 [Page = 3] =0C Long-term archive service requirements January 2004=20 Timestamp: A signed confirmation generated by a Time Stamping=20 Authority (TSA) that a data item existed at a certain time. =20 [RFC3161] specifies a good structure for timestamps and a protocol=20 for communicating with a Timestamp Authority (TSA). =20 =20 Trusted Archiving: A process that includes storing of data objects=20 for long periods of time preserving its integrity, periodic=20 generation of timestamps and collection of evidence in support of=20 long-term preservation of data integrity.=20 =20 Trusted archive authority (TAA): A service responsible for=20 preserving data for long periods of time, including generation and=20 collection of evidence, storage of archived data objects and=20 evidence, etc. A.K.A. Long-term archive service. =20 =20 User: Role (person or process), who submit data objects for=20 archiving, request archive packages and verify the evidence of an=20 archived data object using the associated evidence record,=20 optionally including the verification of any signatures within the=20 archived data object itself. =20 =20 =20 3. Application scenarios and general requirements=20 =20 =20 3.1 Long-term archive problems and tasks=20 =20 A Long-term Archive Service has to be designed to cover several=20 problems in the area of long-term archiving of data objects. The=20 following sections describe some of these problems.=20 =20 3.1.1 Availability and integrity of data for long periods of time=20 =20 Individuals, companies and organisations are facing the problem of=20 how to store electronic documents in a safe way for sometimes even=20 undetermined spans of time. Examples include digital contracts, tax = declarations or electronic birth certificates. These documents need = special care in order to ensure persistent readability, permanent=20 availability, integrity and proper protection of confidentiality. =20 While some large organisations may be capable of supporting=20 appropriate backup, archive and protection mechanisms citizens and=20 small enterprises lack the technical prerequisites for this task. =20 Service providers offering external services for such documents are=20 thus needed.=20 =20 3.1.2 Demonstration of proof of existence and integrity for court=20 =20 Many archived documents are valuable and may be used as evidence in=20 court at some point in the future, e.g. to prove entitlements to=20 =20 =20 Wallace Expires July 2004 [Page 4] =0C Long-term archive service requirements January 2004=20 benefits or damages. In this case, it might be required to prove=20 that these documents existed at a certain time in the past and where = not modified since that time. =20 =20 3.1.3 Preservation of evidence for signed or timestamped data=20 =20 Archived data objects may contain digital signatures or time stamps=20 to be able to prove the origin and the time of existence of these=20 objects and signatures. In the course of time the value of evidence = of these signatures or timestamps can decrease or can get lost for=20 many reasons:=20 =20 - Revocation information is no longer available due to the=20 decommissioning of a CA or OCSP responder;=20 =20 - Lack of availability of certificates necessary to verify a=20 digital signature;=20 =20 - Expiration or Revocation of a certificate associated with a=20 digital signature;=20 =20 - Cryptanalytic or computational advances make it possible to=20 forge documents and signatures or to compute secret keys.=20 =20 In order to avoid problems in case of disputes in the future it is=20 necessary to preserve a digitally signed document, as well as=20 certificates, revocations lists, OCSP responses and time stamps, = even=20 if these elements are not included in the signed document itself. =20 Preservation may be achieved by periodic review of evidence. Upon=20 review, updated evidence may be obtained and stored or additional=20 cryptographic mechanisms may be applied, e.g. a new timestamp=20 obtained possibly using a stronger algorithm. =20 =20 By periodically inspecting and acting upon stored evidence, it is=20 possible to generate a cryptographically protected history for a = data item that contains no periods of time during which an algorithm was=20 thought to be weak, an authority thought to be compromised, etc.=20 =20 =20 3.2 Long-term Archive Service=20 =20 A Long-term Archive Service is to be designed to solve essential=20 parts of these problems by providing a specialized service:=20 =20 - The Long-term Archive Service is to store archived data objects=20 over a long, optionally undefined, period of time. Recovery methods, = redundant storage and disaster management and other measures have to = guarantee the availability of the data objects.=20 =20 Wallace Expires July 2004 [Page 5] =0C Long-term archive service requirements January 2004=20 - The Long-term Archive Service provides material needed to prove = the=20 existence and integrity of data objects for users as well as in=20 court. These means especially are time-stamps, periodically=20 generated during the archiving period of the data objects. = Additional=20 verification data, to verify these time-stamps after a long period = of=20 time (CRLS, OCSP responses and certificates) need also be provided. = =20 - The Long-term Archive Service provides means to preserve the value = of evidence of the archived data objects that are signed. These = means=20 are also time-stamps but with regard to possible special legal=20 requirements for the use as mechanism for the renewal of signatures. = =20 By using these means a signature application can verify that a=20 document, which contains signatures, existed before algorithms got=20 weak or certificates got invalid.=20 =20 A Long-term Archive Service is to not be designed to solve all=20 thinkable problems of long-term-verification of digital signatures. = It does not provide data necessary to verify signatures which are=20 part of the archived data object itself. This has to be done by=20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20 Protocol) or DVCS (Data Validation and Certification Server). This=20 is done, in part, so the archive service can operate without=20 knowledge of numerous signed data formats, document formats, etc. = It=20 also does not provide any means to integrate verification data in=20 data objects and verify embedded signatures. This has to be done on = the basis of other specifications, like RFC 3029 and with regard to=20 specifications of document formats. Of course it is recommended to=20 use such specifications together with a Long-term Archive Service.=20 =20 Several application scenarios providing one or more of these basic=20 service features are to be supported, including:=20 =20 - Archive service assuring long-term Non-Repudiation =20 =20 Long-term Archive Service stores data objects like signed or=20 unsigned documents for identified and authenticated users. It=20 generates time stamps for these data objects and obtains necessary=20 verification data over a given time or until a request of deletion = by=20 this authorized user is sent.=20 =20 - Pure long-term non-repudiation Service=20 =20 Long-term Archive Service only guarantees non-repudiation of=20 existence of data. It periodically generates time stamps and = obtains=20 additional verification data for a given period of time. It stores=20 data objects (e.g. documents, but also relevant parts of documents=20 containing signatures) locally only for the purpose of non- repudiation. It is not a document-archive for users and therefore=20 does not provide retrieval of documents and no deletion of data=20 objects. Therefore it does not need any access control.=20 =20 Wallace Expires July 2004 [Page 6] =0C Long-term archive service requirements January 2004=20 =20 3.3 Instances and overall architecture=20 =20 =20 The basic functions of a Long-term Archive Service are realized by=20 several instances:=20 =20 =20 +-------------+=20 | |=20 | User |=20 | |=20 +-------------+=20 |=20 ----------- Long-term Archive Protocol=20 |=20 +-------------+=20 | |=20 | TAA |=20 | |=20 +-------------+=20 |=20 ----------- Time Stamp Protocol=20 |=20 +-------------+=20 | |=20 | TSA |=20 | |=20 +-------------+=20 =20 Users transfer the data objects that shall be archived at the = Trusted=20 Archive Authority (TAA) using their application of choice. After=20 that, the user or application can request archive packages = containing=20 the stored data objects and the associated evidence record. This is = done by using the Long-term Archive Service Protocol and the data=20 format of archive package to be specified. The TAA stores the=20 documents, and obtains necessary verification data, especially time=20 stamps consulting a Time Stamp Authority using a special Protocol,=20 especially Time Stamp Protocol (RFC 3161). TAA also uses other=20 protocols (e.g. SCVP) to get additional verification data necessary=20 to verify generated time-stamps.=20 =20 A TAA may also provide the functions of a TSA, but separation must = be=20 possible. A TAA may store the archived data objects locally or may=20 use external archive services.=20 =20 Long-term Archive Service may allow for relays using Long-term=20 Archive Protocol. The use of external archive services may be also=20 possible. But Relaying must be transparent to the client. =20 =20 Wallace Expires July 2004 [Page 7] =0C Long-term archive service requirements January 2004=20 A TAA may be a server within an enterprise network communicating = with=20 local archive servers and other applications or an external service=20 accessible via internet.=20 =20 =20 4. Long-term Archive Service functional and quality requirements=20 =20 A Long-term Archive Service MUST provide following basic functions:=20 =20 - Accept data objects or groups of data objects for preservation; = =20 - Store submitted data objects for a given period of time;=20 =20 - Generate, store and maintain evidence records (i.e. by=20 periodically obtaining timestamps) for data objects submitted for=20 preservation;=20 =20 - Collect and store additional verification data necessary to=20 verify evidence records;=20 =20 - Provide archive packages containing archived data, evidence=20 record or both;=20 =20 - Provide service according to a long-term archive policy;=20 - The archive service MUST be able to provide evidence about the policies that have been used at any time. =20 - Be able to provide archive packages even if the storage,=20 software or processing technology changes during the lifetime of an=20 archived data object;=20 =20 - Be able to provide an acknowledgement that a data object = existed=20 at a certain time, as an alternative, if user is not able to=20 interpret the evidence record;=20 =20 - Operate per an archive policy, which at least determines = quality=20 of time-stamps and conditions for there renewal and etc;=20 =20 - If data objects are not stored by the Long-term-Archive-Service = itself, there must exist mechanisms to make these data objects later available to the service if necessary in case of renewal of time-stamps. A long-term archive service must be able to work efficiently even = for=20 large amounts of archived data objects. In order to limit expenses, = costs and dependency on high performance, time-stamp services, the=20 number of necessary time stamps MUST be minimized and a time stamp=20 should include a large number of signatures and documents;=20 =20 =20 =20 =20 Wallace Expires July 2004 [Page 8] =0C Long-term archive service requirements January 2004=20 =20 Necessity to access stored archived data object SHOULD be minimized. = =20 It SHOULD only be necessary access to the archived data objects only = if the archived data objects are requested by users or if applied=20 hash algorithms become insecure. =20 =20 A Long-term Archive Service may implement additional features, such=20 as validation of data objects, if they are signed documents.=20 5. Long-term Archive Service data structure requirements=20 =20 Standardization of data structures and processing procedures for an=20 archive package will simplify the job of TAAs and enable = verification=20 by any user.=20 =20 The data structure for archive package should include the archived=20 data objects and the evidence record. Archived data objects may be=20 included as part of the archive package so that it is possible to=20 request only the evidence record.=20 =20 The data structure for the evidence record itself should have the=20 following properties:=20 =20 - It MUST be possible to include all timestamps necessary to=20 verify the existence of the archived data objects.=20 =20 - The timestamp data structure SHOULD be defined in such a way=20 that it is possible to provide evidence for many archived data=20 objects in an efficient way.=20 =20 - It SHOULD be possible to provide evidence for groups of = archived=20 data objects. For example, it should be possible to archive a=20 document file and a signature file together such that they get the=20 same evidence record.=20 =20 - Where groups of data objects are submitted, non-repudiation=20 proof MUST still be available for each archived data object=20 separately.=20 =20 - The deletion of archived data objects MUST NOT put the=20 provability of other archived data at risk.=20 =20 - It SHOULD be possible to create timestamps without the need to=20 access the archived data objects. The access to the archived data=20 SHOULD only be necessary if the security suitability of employed = hash=20 algorithm is menaced.=20 =20 - All hash algorithms applied to archived data over time SHOULD = be=20 identified in a single location to facilitate single pass=20 verification.=20 =20 - It SHOULD be possible to package all evidence along with the=20 archived data objects in a single data item or to package evidence=20 =20 Wallace Expires July 2004 [Page 9] =0C Long-term archive service requirements January 2004=20 and archived data objects in separate items.=20 =20 - It SHOULD be possible to provide evidence for encrypted = archived=20 data objects. It SHOULD be possible to integrate information for = the=20 reconstruction of the archived data objects of the unencrypted data=20 objects (key, algorithm, etc.).=20 =20 - It SHOULD be possible to integrate additional information for=20 the verification of timestamps within the evidence record or the=20 archived data object itself such as certificates and revocation=20 information, the security suitability of applied algorithms and = trust=20 anchors. =20 =20 =20 6. Long-term Archive Service Protocol requirements=20 =20 Standardization of a protocol for interactions with a Long-term=20 Archive Service is desirable. The protocol should have the = following=20 properties:=20 =20 - The protocol MUST define interactions with a Long-term Archive=20 Service including, at a minimum: submission of data or groups of=20 data for preservation, retrieval of archive packages and deletion=20 of archived data and associated evidence records. =20 - The protocol MUST provide a response indicating successful=20 submission or deletion of data. The acknowledgement of successful=20 submission SHOULD permit a submitter to verify that the correct data = was received by the service for preservation, e.g. the=20 acknowledgement could include an index, a signature or a timestamp=20 obtained for the archived data object.=20 =20 - The protocol MUST response an index to retrieve the archive=20 package. It also should be possible to retrieve archive packages by = using hash values of the archived data objects.=20 - The protocol SHOULD support some basic Metadata (Mime-Type, key = words,etc.), i.e. the client should be able to provide metadata=20 along with the archived data to facilitate future search operations=20 based on the metadata.=20 =20 - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an = error.=20 =20 - A Long-term Archive Service MUST provide an indication of the=20 long-term archive policy under which the service operates.=20 =20 - The protocol MUST prevent replay attacks. =20 - The protocol SHOULD permit encryption of data before submission = in such a way that there exists non-repudiation evidence for the=20 unencrypted data.=20 =20 Wallace Expires July 2004 [Page 10] =0C Long-term archive service requirements January 2004=20 - The protocol SHOULD provide means of associating submitted data = objects with previously submitted data objects, i.e. to facilitate=20 retrieval based on aggregation of objects over time.=20 - The protocol SHOULD provide means for specifying a point in = time=20 at which an archived data object need no longer be preserved. It=20 also should be possible to extend the archiving period.=20 =20 - The protocol SHOULD provide the submission of evidence records=20 previously generated by a different TAA.=20 - The format for the acknowledgements MUST allow the=20 identification of the archiving provider.=20 - The format for the acknowledgements MUST allow (at least from the creating archiving provider) the identification of the=20 participating client. - Responses must uniquely reference corresponding requests - It should be possible to sign requests and responses. It is=20 recommended that in particular acknowledgements are signed. - Deletion must be authenticated.=20 =20 - The archive service MUST be able to provide evidence about the policies that have been used at any time - The protocol SHOULD be as simple to use as possible.=20 =20 Means to enable accountability, access control, confidentiality of=20 communication between applications and TAA need additional=20 precautions (like SSL) that are outside the scope of these=20 requirements.=20 7. Security Considerations=20 =20 Where non-standard formats are used or proprietary processing is=20 employed, verification of signatures on or in archived data may=20 require the availability of specific applications or tools.=20 =20 Certificate revocation could retroactively invalidate previously=20 verified signatures. Measures may be implemented to support such=20 claims by an alleged signer, e.g. collection of revocation=20 information after a grace period during which compromise can be=20 reported or preservation of subsequent revocation information. =20 =20 Access control mechanisms associated with data stored by a TAA = should=20 consider the lifespan of the data object. For example, the=20 credentials of an entity that submitted data to an archive may not = be=20 available or valid when the data needs to be retrieved.=20 Wallace Expires July 2004 [Page 11] =0C Long-term archive service requirements January 2004=20 To achieve accountability, local means should be employed to ensure that all data is inserted in chronological order, e.g. by using write-once media. Similarly, methods should be deployed to ensure that all deletions are detectable. =20 =20 8. Acknowledgements=20 =20 Thanks to Peter Sylvester for sharing information from the=20 OpenEvidence project.=20 =20 =20 9. Normative References=20 =20 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision=20 3", BCP 9, RFC 2026, October 1996.=20 =20 [RFC2028] Bradner, S. and R. Hovey, "The Organizations Involved in=20 the IETF Standards Process", BCP 11, RFC 2028, October=20 1996.=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 [RFC3029] Adams, C., Sylvester, P., Zolotarev, M. and R.=20 Zuccherato, "Internet X.509 Public Key Infrastructure=20 Data Validation and Certification Server Protocols", RFC=20 3029, August 2001.=20 =20 [RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,=20 "Internet X.509 Public Key Infrastructure Time-Stamp=20 Protocol (TSP)", RFC 3161, August 2001.=20 =20 =20 Wallace Expires July 2004 [Page 12] = =0C Long-term archive service requirements January 2004=20 10. Authors' Addresses=20 =20 Carl Wallace=20 Orion Security Solutions=20 Suite 300=20 1489 Chain Bridge Road=20 McLean, VA 22101=20 E-Mail : cwallace@orionsec.com=20 =20 Ralf Brandner=20 Otto-Hahn-Str. 3 =20 D-69190 Walldorf, Germany=20 E-Mail: ralf.brandner@intercomponentware.com=20 Ulrich Pordesch=20 Fraunhofer Gesellschaft=20 Institute Secure Telecooperation=20 Dolivostrasse 15=20 D-64293 Darmstadt, Germany=20 E-Mail: ulrich.pordesch@sit.fraunhofer.de=20 Wallace Expires July 2004 [Page 13] ------_=_NextPart_000_01C3D933.398CBCB0-- From owner-ietf-ltans Tue Jan 13 08:59:29 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DGxTib050400; Tue, 13 Jan 2004 08:59:29 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DGxTnP050399; Tue, 13 Jan 2004 08:59:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0DGxNib050388 for ; Tue, 13 Jan 2004 08:59:23 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 17249 invoked from network); 13 Jan 2004 16:54:23 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:23 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15667-10 for ; Tue, 13 Jan 2004 17:54:23 +0100 (CET) Received: (qmail 17239 invoked from network); 13 Jan 2004 16:54:22 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:22 -0000 From: "A. Jerman Blazic" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D Date: Tue, 13 Jan 2004 17:59:14 +0100 Message-ID: <00ac01c3d9f6$92db8cb0$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C3D9FE.F49FF4B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> X-Virus-Scanned: by amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C3D9FE.F49FF4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tobias and others =20 First of all, I am pleased LTANS did produce one of the first discussable drafts. =20 In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management". I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... =20 Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. =20 User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems... =20 On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy? =20 Hope this will trigger some discussion... =20 Regards =20 Aleksej -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, January 12, 2004 6:41 PM To: 'ietf-ltans@imc.org' Subject: Initial requirements for long-term archive I-D=20 Importance: High Hello,=20 Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D "=20 (first milestone, unfortunately 6 weeks behind schedule)=20 <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data structures and protocol) will be targeting to fulfill the discussed requirements. The initial drafts for these 2 documents are also behind schedule but initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind:=20 - discuss the different sections for the document individually=20 - if possible list the chapter you want to change and the old and the new text to make it easier for the others to follow the discussion and for the editor. At the moment there are even topics for dicusiion open from the writing of the initial paper.=20 Best regards=20 Tobias=20 Tobias Gondrom=20 Senior Software Architect=20 Engineering=20 IXOS Software AG=20 Technopark Neukeferloh=20 Bretonischer Ring 12=20 D-85630 Grasbrunn/M=FCnchen=20 E-Mail: Tobias.Gondrom@ixos.de=20 WWW: http://www.ixos.com=20 Tel: +49-89-4629-1816=20 Fax: +49-89-4629-33-1816=20 This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------=_NextPart_000_00AD_01C3D9FE.F49FF4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first = discussable=20 drafts.
 
In the first place I do have some views on the = general document=20 structure, which is very "Trusted Archive Protocol" oriented. In my = view, one=20 has to distinguish two main logical parts of the archive, which is = protocol=20 interaction mechanisms, i.e. trusted archive protocol or a point of = user's=20 interaction with an archive. The other is archive itself and integrated=20 mechanisms for assuring object validity over defined or undefined period = of time=20 (I do distinguish at least two measures of archiving period, although=20 e-archiving is tightly related to needs/requirements/obligations on = content=20 archiving, so many "time-frame" definitions are possible) in combination = with=20 archived object "management". I guess data structures are trying to = focus on=20 later but conservation mechanisms seems like missing or at least no = indirect linkage to additional specifications are mentioned, of course = if there=20 are some (XAdES??)....
 
Next, in the document (page 4) = redundant storage,=20 disaster recovery, etc. are mentioned. Data storage mechanisms = should be=20 out of the scope of the e-archive, since back-up mechanisms and systems = are=20 something which one can find on, let's say, "lower" infrastructure=20 layer and should be dealt as = is.
 
User authentication is another problem in = wide scale=20 deployment of archive services. Bearing in mind that privacy is one of = the (more=20 and more) important factor in open infrastructure, confidentiality is = even more=20 important in case of formal content handling (contracts, invoices!!).=20 Furthermore, DVCS exposes the content to authority at least, and has = serious=20 confidentiality problems...
 
On page 5 and 6, TAA is presented as a = document storage=20 service, which in certain case doesn't have to. My personal view is, = that=20 archiving does not mean only archiving service but extended = functionality of=20 existing document warehouses or management systems. In this case, TAA is = a=20 service maintaining only archiving related data and not content by = itself,=20 i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means = single=20 point of interaction for many content related services. Do we really = need such=20 content redundancy?
 
Hope this will trigger some=20 discussion...
 
Regards
 
Aleksej
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Tobias Gondrom
Sent: Monday, January 12, 2004 = 6:41=20 PM
To: 'ietf-ltans@imc.org'
Subject: Initial = requirements=20 for long-term archive I-D
Importance: = High

Hello,

Thanks to Carl, Uli and Ralf we = finished the=20
"Initial requirements for long-term archive = I-D=20 "
(first milestone,=20 unfortunately 6 weeks behind schedule)
<<draft-ietf-ltans-reqs-01.txt>> =

I would like to encourage now the = discussion for=20 this draft on the mailing-list as fast as possible as the following = standards=20 (data structures and protocol)  will be targeting to fulfill the=20 discussed requirements. The initial drafts for these 2 documents are = also=20 behind schedule but initial documents shall be available for = discussion end of=20 january.

Please keep best practices for the = discussion in=20 mind:
- discuss the different = sections for=20 the document individually
- if = possible=20 list the chapter you want to change and the old and the new text to = make it=20 easier for the others to follow the discussion and for the = editor.

At the moment there are even topics for = dicusiion=20 open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG =
Technopark Neukeferloh
Bretonischer=20 Ring 12
D-85630 = Grasbrunn/M=FCnchen=20

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com =
Tel: +49-89-4629-1816