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
Fax: +49-89-4629-33-1816

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

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

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0-- From owner-ietf-ltans Tue Jan 27 09:11:50 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RHBoi2040670; Tue, 27 Jan 2004 09:11:50 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RHBocJ040667; Tue, 27 Jan 2004 09:11:50 -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.11/8.12.8) with ESMTP id i0RHBlEd040642 for ; Tue, 27 Jan 2004 09:11:48 -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 i0RHBaeX018377; Tue, 27 Jan 2004 18:11:41 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 18:12:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5308@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej Date: Tue, 27 Jan 2004 18:11:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4F8.A54F3600" 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_001_01C3E4F8.A54F3600 Content-Type: text/plain Dear Aleksej, Dear Tobias and others First of all, I am pleased LTANS did produce one of the first discussable drafts. Thanks. The same for me. 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". Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself). 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??).... For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored. 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. Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand) 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... I see the authentication problem quite similar and have at the moment not the optimal solution for it. :( On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied. On the other hand how can one achieve authentication across very long times spans of decades ? Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.) [see also page 9 bottom: "protocol should permit encryption of data before submission..." ] 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? It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5] Hope this will trigger some discussion... Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....) For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list. Regards Tobias ------_=_NextPart_001_01C3E4F8.A54F3600 Content-Type: text/html Message
Dear Aleksej,
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first discussable drafts.
 
Thanks. The same for me.
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".  
Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself).
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??).... 
For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored.
 
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. 
 
Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand)
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...
 
I see the authentication problem quite similar and have at the moment not the optimal solution for it. :(
On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied.
On the other hand how can one achieve authentication across very long times spans of decades ?
 
Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.)
[see also page 9 bottom: "protocol should permit encryption of data before submission..." ]
 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?
It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5]
Hope this will trigger some discussion...
 
Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....)
 
For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list.
 
Regards
 
    Tobias
 
------_=_NextPart_001_01C3E4F8.A54F3600-- From owner-ietf-ltans Tue Jan 27 10:20:31 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIKU6N046948; Tue, 27 Jan 2004 10:20:30 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RIKUfD046947; Tue, 27 Jan 2004 10:20:30 -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.11/8.12.8) with ESMTP id i0RIKQXe046936 for ; Tue, 27 Jan 2004 10:20:29 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0RIKLqC019146 for ; Tue, 27 Jan 2004 19:20:21 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 19:20:42 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? Date: Tue, 27 Jan 2004 19:20:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E502.40D91650" 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_001_01C3E502.40D91650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA: This name "Trusted" is somehow confusing for me. For me "Trusted" = implies that the archive is a somehow trusted third party that needs some = evalutions by some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous). Of course the documents have to be stored and it has to be taken care = that the needed steps of resigning are taken but all this is normal = business. For that I would prefer if we could change the names from : "Trusted Archiving" to "Archiving"=20 And from: "Trusted Archive Authority" to "Archive Authority" or = "Archive Service" 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_01C3E502.40D91650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Initial requirements for long-term archive I-D - wording: = Trusted archiving ?

Hello,

I would like to discuss in section 2 = "Terminology" the name "Trusted Archiving" and = TAA:

This name "Trusted" is = somehow confusing for me. For me "Trusted" implies that the = archive is a somehow trusted third party that needs some evalutions by = some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the = trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous).

Of course the documents have to be = stored and it has to be taken care that the needed steps of resigning = are taken but all this is normal business.

For that I would prefer if we could = change the names from :

"Trusted Archiving" to = "Archiving"
And from: "Trusted Archive = Authority" to "Archive Authority" or "Archive = Service"

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_01C3E502.40D91650-- From owner-ietf-ltans Tue Jan 27 10:33:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIXv62047866; Tue, 27 Jan 2004 10:33:57 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RIXvnq047865; Tue, 27 Jan 2004 10:33:57 -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.11/8.12.8) with ESMTP id i0RIXtmf047856 for ; Tue, 27 Jan 2004 10:33:55 -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 TAA19930; Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIXoN05349; Tue, 27 Jan 2004 19:33:50 +0100 (MET) Date: Tue, 27 Jan 2004 19:33:50 +0100 (MET) From: Peter Sylvester Message-Id: <200401271833.i0RIXoN05349@chandon.edelweb.fr> To: aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej 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: As suggested, I just take a subpart of the messages and add some centimes in a brain storming way. > 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... If you think about a chain of a notary that validates formal content and then needs to store the data at some external service, there is no formal way to ensure either encryption or splitting so that the assertions from the backend service can be matched with the statement from the notary. Needs some work ... > I see the authentication problem quite similar and have at the moment not > the optimal solution for it. :( User authentication doesn't seem for me a particular problem for the archive service, it may or may not be a problem for any large scale service. That's why I think we should not try and mandate a particular way but allow for different techniques, including: - Access control on the transport level (e.g. SSL). - Signatures in order to keep some proof. - asynchronous staged processing for certain operations where requests need to be confirmed by someone else. The meaning of 'Optimal' depends on the goals. > On the one side you have to be able to store data and with this the > retrieval has to authenticated and access control has somehow to be applied. > > On the other hand how can one achieve authentication across very long times > spans of decades ? Isn't Authentication 'at distance' but not 'in time'. But we talk about authorisation? It may be necessary to handle in some way particular roles like 'a judge/relevant authority' and then the access control may require some 'entitlement'. This entity from the fiscal service is entitled to access to data from company identified by XXX'. how these meachnisms are implement now or in future is not in our scope, I think what remains is that the exchanged and stored information contain sufficient 'metadata' indicating to whom the belong using good identifiers. Either a client should explicitely set some identifiers in requests, which need then matched against the authenticated client id, or they are added by the server based on the client id or maybe additional parameters in the request. > Confidentiality is something that will be probably one of the very important > issues when independent Archive Providers want to offe this service to end > users and smaller companies. (One mechanism I could imagine is that the > users are submitting encrypted data/documents and solve most of there urgent > problems with that.) To what degree do you trust your provider of the operating system and the machine processor to not have a backdoor in the system which will be activated when things happen in a environment of a 'competitor'. Encryption may be a solution for short term, otherwise in real paranoia you need to physically split the data and store then at places where you are reasonably sure that the operators cannot cheat together without leaving some trace. There are also various possible combinations of in/out-sourcing. what seems important is that the provider/operator of the service has an auditable system in a very large sense. From owner-ietf-ltans Tue Jan 27 10:42:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIg2cr048474; Tue, 27 Jan 2004 10:42:02 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RIg2d5048473; Tue, 27 Jan 2004 10:42:02 -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.11/8.12.8) with ESMTP id i0RIfw4g048464 for ; Tue, 27 Jan 2004 10:42:01 -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 TAA19969; Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIfv105360; Tue, 27 Jan 2004 19:41:57 +0100 (MET) Date: Tue, 27 Jan 2004 19:41:57 +0100 (MET) From: Peter Sylvester Message-Id: <200401271841.i0RIfv105360@chandon.edelweb.fr> To: ietf-ltans@imc.org, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > This name "Trusted" is somehow confusing for me. For me "Trusted" implies > that the archive is a somehow trusted third party that needs some evalutions > by some government authority. I don't think that such is necessary. All the > mechanisms to ensure the integrity of the data can be based on the > trustworthyness of the TSP (that has to be a trusted third party as changing > e.g. the time of the server would be disasterous). You loose integrity of data when you loose the data. I guess you need to trust that the archive service 'does its best'. From owner-ietf-ltans Tue Jan 27 11:10:37 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJAbdr050374; Tue, 27 Jan 2004 11:10:37 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RJAbPT050373; Tue, 27 Jan 2004 11:10:37 -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.11/8.12.8) with ESMTP id i0RJAXto050366 for ; Tue, 27 Jan 2004 11:10:34 -0800 (PST) (envelope-from paul-andre.pays@edelweb.fr) Received: from edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA20324; Tue, 27 Jan 2004 20:10:32 +0100 (MET) Received: from edelweb.fr (pap2002.edelweb.fr [193.51.14.21]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 20:10:32 +0100 (MET) Message-ID: <4016B7B3.8090605@edelweb.fr> Date: Tue, 27 Jan 2004 20:10:43 +0100 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? References: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070309030606060405030308" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070309030606060405030308 Content-Type: multipart/alternative; boundary="------------080302060304000808090501" This is a multi-part message in MIME format. --------------080302060304000808090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable My 2 cts, * on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party=20 (no capital letters, but 100% independant from B). * on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "*trusted archiving*" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party". In short, I feel confortable with today terminology as long as a=20 glossary is provided which explains the semantic attached to each of=20 these terms (for example along the line of my above understanding), and=20 pinpoints the fact that the actual official nature (appropriately=20 separate archival service in some cases, effective trusted third party=20 in others) is completely context dependant. The context is the legal=20 context with the requirements for "evidence creation". LTANS should focus on technical solutions and not on these "legal"=20 environments. I you consider that the term "trusted" conveys too much third party=20 meening, I would accept "reliable archive" as long as it is explained=20 that reliable is not only related technical reliability but also=20 includes the appropriate independance (buwinesswise and legaly wise) -- PAP Tobias Gondrom wrote: > Hello, > > I would like to discuss in section 2 "Terminology" the name "Trusted=20 > Archiving" and TAA: > > This name "Trusted" is somehow confusing for me. For me "Trusted"=20 > implies that the archive is a somehow trusted third party that needs=20 > some evalutions by some government authority. I don't think that such=20 > is necessary. All the mechanisms to ensure the integrity of the data=20 > can be based on the trustworthyness of the TSP (that has to be a=20 > trusted third party as changing e.g. the time of the server would be=20 > disasterous). > > Of course the documents have to be stored and it has to be taken care=20 > that the needed steps of resigning are taken but all this is normal=20 > business. > > For that I would prefer if we could change the names from : > > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or=20 > "Archive Service" > > 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=20 > you are not the intended recipient or have received this eMail in=20 > error, please notify the sender immediately and destroy this eMail.=20 > Any use, disclosure or distribution of the material in this eMail is=20 > strictly forbidden. > > Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte=20 > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese=20 > eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den=20 > Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung,=20 > Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. > --=20 Paul-Andr=E9 PAYS pays@edelweb.fr ou papays@on-x.com Directeur EdelWeb & P=F4le S=E9curit=E9 Groupe ON-X http://www.edelweb.fr/ http://www.on-x.com/ tel: +33 1 40 99 29 55 fax : +33 1 40 99 03 30 ----- Pour v=E9rifier la signature : https://www.openevidence.org/OEROOT-ca.der= --------------080302060304000808090501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My 2 cts,

  • on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party  (no capital letters, but 100% independant from B).
  • on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "trusted archiving" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party".
In short, I feel confortable with today terminology as long as a glossary is provided which explains the semantic attached to each of these terms (for example along the line of my above understanding), and pinpoints the fact that the actual official nature (appropriately separate archival service in some cases, effective trusted third party in others) is completely context dependant. The context is the legal context with the requirements for "evidence creation".
LTANS should focus on technical solutions and not on these "legal" environments.
I you consider that the term "trusted" conveys too much third party meening, I would accept "reliable archive" as long as it is explained that reliable is not only related technical reliability but also includes the appropriate independance (buwinesswise and legaly wise)

-- PAP


Tobias Gondrom wrote:
RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ?

Hello,

I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA:

This name "Trusted" is somehow confusing for me. For me "Trusted" implies that the archive is a somehow trusted third party that needs some evalutions by some government authority. I don't think that such is necessary. All the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as changing e.g. the time of the server would be disasterous).

Of course the documents have to be stored and it has to be taken care that the needed steps of resigning are taken but all this is normal business.

For that I would prefer if we could change the names from :

"Trusted Archiving" to "Archiving"
And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service"

Best regards

        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.


-- 
Paul-André PAYS                 pays@edelweb.fr   ou  papays@on-x.com
Directeur 			EdelWeb & Pôle Sécurité Groupe ON-X
http://www.edelweb.fr/          http://www.on-x.com/
tel: +33 1 40 99 29 55          fax : +33 1 40 99 03 30
-----
Pour vérifier la signature : https://www.openevidence.org/OEROOT-ca.der
--------------080302060304000808090501-- --------------ms070309030606060405030308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCC AvgwggHgoAMCAQICBD7XZsYwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCV1cxFTATBgNV BAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGljaXBhbnRzIEF1dGhvcml0eTAeFw0w MzA1MzAxNDEyMzJaFw0wNDEwMTExNDEyMzJaMCgxCzAJBgNVBAYTAk5OMRkwFwYDVQQDFBBQ YXVsLUFuZHLDqSBQQVlTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtYu5hSua01K5B b63LMSSr/Tr2MQKjDRzEojvW/6tckP0sjJu7pOOCEvXca8EMUNRT4wF5ss/hOA2Mhn9gQsya kdimzAhLyX/2DxwXESlCCIC9JNPK3H9YZPSTspY4922XPR9np5brErHjw9B9ll474YLg1abi 5xpq+HQ2D/pcgQIDAQABo4GQMIGNMCUGA1UdEQQeMByBGnBhdWwtYW5kcmUucGF5c0BlZGVs d2ViLmZyMDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwBIYcaHR0cHM6Ly93d3cub3BlbmV2 aWRlbmNlLm9yZzALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MA0GCSqGSIb3DQEBBAUAA4IBAQCzdZBQHrV+iuyxyP7YSVCsUKgOhXKwYfV1BKl+1bJvw11L rZzUmGaPrg0BUm3ETqrtEzvMq7yXkPUfRaDoEy0pmbRszvDPGjNKaGrP3/JaH9bXJtKxC1er 8ewCxCNcXH4mZwUhITUyHUoA6cSoShcW/elhbGQWhVnsxUHy82A4cFOH/G4lhVE9/tpnLOKS S1jmuW08Ic8/o4VUKeJlv3z7+Q+lyYQpbSpKs/N3qiAz7yhbeWU6GAOaX+iY9tTm2T1wXK69 72uqZbp31sxAlFjs/2q7FGk2FCwb/Pst20aUM4dDauK+vi5FV9XokI80YH/IpMxO+T+o+sPu Zh4TnrohMIIC+DCCAeCgAwIBAgIEPtdmxjANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJX VzEVMBMGA1UEChMMT3BlbkV2aWRlbmNlMR8wHQYDVQQDExZQYXJ0aWNpcGFudHMgQXV0aG9y aXR5MB4XDTAzMDUzMDE0MTIzMloXDTA0MTAxMTE0MTIzMlowKDELMAkGA1UEBhMCTk4xGTAX BgNVBAMUEFBhdWwtQW5kcsOpIFBBWVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK1i 7mFK5rTUrkFvrcsxJKv9OvYxAqMNHMSiO9b/q1yQ/SyMm7uk44IS9dxrwQxQ1FPjAXmyz+E4 DYyGf2BCzJqR2KbMCEvJf/YPHBcRKUIIgL0k08rcf1hk9JOyljj3bZc9H2enlusSsePD0H2W XjvhguDVpuLnGmr4dDYP+lyBAgMBAAGjgZAwgY0wJQYDVR0RBB4wHIEacGF1bC1hbmRyZS5w YXlzQGVkZWx3ZWIuZnIwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzAEhhxodHRwczovL3d3 dy5vcGVuZXZpZGVuY2Uub3JnMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwDQYJKoZIhvcNAQEEBQADggEBALN1kFAetX6K7LHI/thJUKxQqA6FcrBh9XUE qX7Vsm/DXUutnNSYZo+uDQFSbcROqu0TO8yrvJeQ9R9FoOgTLSmZtGzO8M8aM0poas/f8lof 1tcm0rELV6vx7ALEI1xcfiZnBSEhNTIdSgDpxKhKFxb96WFsZBaFWezFQfLzYDhwU4f8biWF UT3+2mcs4pJLWOa5bTwhzz+jhVQp4mW/fPv5D6XJhCltKkqz83eqIDPvKFt5ZToYA5pf6Jj2 1ObZPXBcrr3va6plunfWzECUWOz/arsUaTYULBv8+y3bRpQzh0Nq4r6+LkVX1eiQjzRgf8ik zE75P6j6w+5mHhOeuiEwggNAMIICKKADAgECAgcQIHgomHZRMA0GCSqGSIb3DQEBBAUAMDgx CzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxEjAQBgNVBAMTCUF1dGhvcml0 eTAeFw0wMjA1MDcxNDQ4MjFaFw0xMjA1MDQxNDQ4MjFaMEUxCzAJBgNVBAYTAldXMRUwEwYD VQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRZ0ovIMoH0rNd3Kh5108NViqZ3OkpU4Ze 1EkvwSEMab+tpLKPxijhM8fHW89W1ZvCRPfNvGyliDavK/rwp2EeeB0POTBjxjuHkYsFjFgE pAU2qpiikptBd0K5HvtYDksIapCTbzBB5/77Kh+X8g7NxETqt7rZDTnns0VmJrJGI/6m8GUP FEPV0ulDwOEk4uutdPE4vNkadAbe8OrBVhMgVs5M0Y6/wCYDt7tzu3dUWi6cws7PQiFFjEI1 N0LHaR7kcODOOoJSNG6WuQmRQRZGRQqYsE9316DpEqEOYpXjxLtj9TI1HmrYtJjeDRdNM7qV MgCdhhMc6DjqD+9pf0yFAgMBAAGjQjBAMA8GA1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBSwGAKKzw/hQilrVrPW1UxszLdAWzANBgkqhkiG9w0BAQQFAAOCAQEA +D1M7ixKqQ7eN3HsXl9+dULna7sMZ07/7AnGgHjIltM7oelpftJUwW2/zHUaTxy9sxSXiKTr fuTxwvNOANQN6BM1h0EJxSqYiKyRzzxYCohmfgllStIU3U3Q+mCvaUma5FLhzBfkfOk/VtFy 6jK+6WqUluftBtx7/gXmvA8fbtcxcvTJ80rQHM+bR26VQhPwVXUP7k5ED8EBVee2TUa/117B 6lFQAL3V4XJuRVUJ+UMUAJBc7VN/eJfPOOpTn3l+gMuhoSZP+oLEXG1+eTK/ht8kjo+jXZPV Op+G0tVXibWmepsTHj+ahH6b7u4/Zbe6V2M4H2L+rhRahM0/7BwUtzGCAmYwggJiAgEBME0w RTELMAkGA1UEBhMCV1cxFTATBgNVBAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGlj aXBhbnRzIEF1dGhvcml0eQIEPtdmxjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAxMjcxOTEwNDNaMCMGCSqGSIb3DQEJBDEW BBSqJJNNrvysQxk0a+YUja1A/S0FRzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBc BgkrBgEEAYI3EAQxTzBNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2Ux HzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwXgYLKoZIhvcNAQkQAgsx T6BNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBh cnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwDQYJKoZIhvcNAQEBBQAEgYA23Zr7+yEn/2Ql UIPx2Icq0GIMPvsdHY5xCs8LA+P+knQUqRjhyDFjmxjUl+69gLe4IExuOES2URkooFTX+B3R u/KoDSDKcoX2YpET9iyE/7rOmf3To1NG7yXprl5rK0NMarM+UEiVDWm4Pj7UavU9vbW0Q1+S BOkMq64g602iWQAAAAAAAA== --------------ms070309030606060405030308-- From owner-ietf-ltans Tue Jan 27 11:22:44 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJMicq051109; Tue, 27 Jan 2004 11:22:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RJMibK051108; Tue, 27 Jan 2004 11:22: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.11/8.12.8) with ESMTP id i0RJMcZC051101 for ; Tue, 27 Jan 2004 11:22:39 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-141-156-225-56.res.east.verizon.net [141.156.225.56]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0RJMdh2025494; Tue, 27 Jan 2004 14:22:39 -0500 From: "Carl Wallace" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Tue, 27 Jan 2004 14:22:40 -0500 Message-ID: <002401c3e50a$ee8f0590$6601a8c0@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 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> 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: > For that I would prefer if we could change the names from : > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service" The word "trusted" provides a hint that something more than simple storage of the data is going on (even if the actual trust is in the TSA). Also, an Archive Authority must be trusted if it is providing trust anchor information. From owner-ietf-ltans Wed Jan 28 05:25:24 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDPOdW028250; Wed, 28 Jan 2004 05:25:24 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SDPO43028249; Wed, 28 Jan 2004 05:25:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDPMel028234 for ; Wed, 28 Jan 2004 05:25:23 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id OAA04449; Wed, 28 Jan 2004 14:25:05 +0100 (MET) Message-ID: <4017B89E.4010801@sit.fraunhofer.de> Date: Wed, 28 Jan 2004 14:26:54 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl Wallace CC: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ? References: <002401c3e50a$ee8f0590$6601a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl Wallace wrote: >>For that I would prefer if we could change the names from : >>"Trusted Archiving" to "Archiving" >>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive > > Service" > > The word "trusted" provides a hint that something more than simple storage > of the data is going on (even if the actual trust is in the TSA). Also, an I agree. The differentiation between a simple archive service (only document storage) and an archive service that obtains evidence of document existence is important. > Archive Authority must be trusted if it is providing trust anchor > information. I am not sure I follow this point. What would this trust anchor information be? Regards, Brian From owner-ietf-ltans Wed Jan 28 05:41:14 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDfEr1029083; Wed, 28 Jan 2004 05:41:14 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SDfERi029081; Wed, 28 Jan 2004 05:41:14 -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.11/8.12.8) with ESMTP id i0SDfBKT029074 for ; Wed, 28 Jan 2004 05:41:12 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDf3aL025070; Wed, 28 Jan 2004 14:41:04 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:41:26 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5319@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - Confidentiality Date: Wed, 28 Jan 2004 14:41:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Confidentiality is something that will be probably one of the very > > important issues when independent Archive Providers want to offe this > > service to end users and smaller companies. (One mechanism I could > > imagine is that the users are submitting encrypted data/documents and > > solve most of there urgent problems with that.) > > To what degree do you trust your provider of the operating > system and the machine processor to not have a backdoor in > the system which will be activated when things happen in a > environment of a 'competitor'. My personal answer would be to trust only things that can be evaluated and that are actually evaluated (e.g. source from LINUX, large community working with Windows and ISV-Firewalls). In general I would say that customers rely on the reputation of a system, on results of independent tests (including hackers and audits) and some of the promises of the provider. > Encryption may be a solution for short term, otherwise in > real paranoia you need to physically split the data and store > then at places where you are reasonably sure that the > operators cannot cheat together without leaving some trace. > There are also various possible combinations of > in/out-sourcing. what seems important is that the > provider/operator of the service has an auditable system in a > very large sense. Maybe Peter is right and you simply have to trust your provider. :-/ (at least you have a contract and probably pay your provider for the service and the provider could gain some additional trust by independent audits) Still I am very sure we have to provide the ability to store (and provide evidence for) encrypted data. For many people this will be the first way to trust an external provider. (And in some countries it might also be forbidden to let the data even only theoretically be accessible to other persons) From owner-ietf-ltans Wed Jan 28 05:53:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDrseD030452; Wed, 28 Jan 2004 05:53:54 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SDrsle030451; Wed, 28 Jan 2004 05:53:54 -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.11/8.12.8) with ESMTP id i0SDrpfL030445 for ; Wed, 28 Jan 2004 05:53:52 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDrjOB025703; Wed, 28 Jan 2004 14:53:46 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:54:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D531A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Wed, 28 Jan 2004 14:54:02 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As suggested, I just take a subpart of the messages and add > some centimes in a brain storming way. > > > 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... > > If you think about a chain of a notary that validates formal > content and then needs to store the data at some external > service, there is no formal way to ensure either encryption > or splitting so that the assertions from the backend service > can be matched with the statement from the > notary. Needs some work ... > > > I see the authentication problem quite similar and have at the moment > > not the optimal solution for it. :( > > User authentication doesn't seem for me a particular problem > for the archive service, it may or may not be a problem for > any large scale service. > > That's why I think we should not try and mandate a > particular way but allow for different techniques, including: > > - Access control on the transport level (e.g. SSL). > - Signatures in order to keep some proof. > - asynchronous staged processing for certain operations > where requests need to be confirmed by someone else. > > The meaning of 'Optimal' depends on the goals. I agree with you Peter. Seems to be better to allow authentication but we don't need to specify the used technique so that different services are free to implement what fits best. > > On the one side you have to be able to store data and with this the > > retrieval has to authenticated and access control has somehow to be > > applied. > > > > On the other hand how can one achieve authentication across very long > > times spans of decades ? > > Isn't Authentication 'at distance' but not 'in time'. Basically I see a problem concerning the time too. The methods of authentification may change during the lifetime of a document (even more than once). And with that you might get problems. Let's e.g. say you archived a contract about your newly bought house or something and used at the beginning user/password authentication. For the next 20 years you are basically probably not interested in the document and might even forget your password, although you still have the URL of the document with all the evidence records. In the future maybe even user/password authentication is no longer accepted by the server so you need something different - but what is important for the system: are you the same person that stored the document 20 years ago ? > But we talk about authorisation? It may be necessary to handle in > some way particular roles > like 'a judge/relevant authority' and then the access control > may require some 'entitlement'. This entity from the fiscal > service is entitled to access to data from company identified > by XXX'. how these meachnisms are implement now or in future > is not in our scope, I think what remains is that the > exchanged and stored information contain sufficient > 'metadata' indicating to whom the belong using good identifiers. > Either a client should explicitely set some identifiers in > requests, which need then matched against the authenticated > client id, or they are added by the server based on the > client id or maybe additional parameters in the request. Authorisation: In my understanding authorisation comes after some kind of authentication (i.e. at first you know the identity of the other and then you think about to allow him access to the data). A role based access control seems feasable and hopefully not to complicated. (Maybe added with some sercret (document id ?) generated at the time of storage.) The "judge/relevant authority" is of course on. A second one will be the user who stored the data. (Of course he wants to be able to receive the evidence and maybe even the data he stored.) Small remark: If the trusted archive does not provide the data itself to normal requests, the authorisation topic might be easy, as I think the retrieval of evidence to a document might not be a security issue. The request for evidence could contain either the data or a hash-value of the data (as long as the hash-algorithm is still secure). From owner-ietf-ltans Wed Jan 28 06:16:05 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEG58c031639; Wed, 28 Jan 2004 06:16:05 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEG5MW031638; Wed, 28 Jan 2004 06:16:05 -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.11/8.12.8) with ESMTP id i0SEG3qO031631 for ; Wed, 28 Jan 2004 06:16:03 -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 i0SEG4h2021817; Wed, 28 Jan 2004 09:16:04 -0500 From: "Carl Wallace" To: "'Brian Hunter'" Cc: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Wed, 28 Jan 2004 09:15:59 -0500 Message-ID: <000701c3e5a9$43b7ab50$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4017B89E.4010801@sit.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SEG4qO031632 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Archive Authority must be trusted if it is providing trust > anchor > information. > > I am not sure I follow this point. What would this trust anchor > information be? When verifying signatures that accrue over time, trust anchors may be necessary that are not active at the time of verification. An archive could serve as a repository for past trust anchors. An archive acting in this capacity would need to be trusted. From owner-ietf-ltans Wed Jan 28 06:52:26 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEqQTk034198; Wed, 28 Jan 2004 06:52:26 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEqQE0034197; Wed, 28 Jan 2004 06:52:26 -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.11/8.12.8) with ESMTP id i0SEqO9r034191 for ; Wed, 28 Jan 2004 06:52:24 -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 PAA29343; Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0SEqMK07506; Wed, 28 Jan 2004 15:52:22 +0100 (MET) Date: Wed, 28 Jan 2004 15:52:22 +0100 (MET) From: Peter Sylvester Message-Id: <200401281452.i0SEqMK07506@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > > > Isn't Authentication 'at distance' but not 'in time'. > > Basically I see a problem concerning the time too. The methods of > authentification may change during the lifetime of a document (even more > than once). And with that you might get problems. > Let's e.g. say you archived a contract about your newly bought house or > something and used at the beginning user/password authentication. For the > next 20 years you are basically probably not interested in the document and > might even forget your password, although you still have the URL of the > document with all the evidence records. In the future maybe even > user/password authentication is no longer accepted by the server so you need > something different > - but what is important for the system: are you the same person that stored > the document 20 years ago ? Even with user/password you don't make a proof that you are the person that stored, only that some accesses who knows these values. There is a difference betwenn identification and authentication. The 'user' is not your 'identification', but an means for authentication. You long term identification are the data on your birth certificate; thus, when you register to such a service, you have probably always to provide some information about who you are, a copy of your national id card or whatever. This identification (potentially in an anonymous form) is then associated by the provider with some authentication method: You get a user/password. 20 years later (and even earlier) you should be able to provide the same identification information (or better, the the id of your grandparents) to access. > > Authorisation: > In my understanding authorisation comes after some kind of authentication > (i.e. at first you know the identity of the other and then you think about > to allow him access to the data). > A role based access control seems feasable and hopefully not to complicated. > (Maybe added with some sercret (document id ?) generated at the time of > storage.) > > The "judge/relevant authority" is of course on. > A second one will be the user who stored the data. (Of course he wants to be > able to receive the evidence and maybe even the data he stored.) You almost never have the situation that some data only belongs to one person durng a long period in time. The most simplistic authorisation model which just has a 1=1 correspondance is not sufficient. You can die at any moment, you can delegate your power to someone else at any time etc. > Small remark: If the trusted archive does not provide the data itself to > normal requests, the authorisation topic might be easy, as I think the > retrieval of evidence to a document might not be a security issue. The > request for evidence could contain either the data or a hash-value of the > data (as long as the hash-algorithm is still secure). A not so small response :-) A request to an archiver may live the following way: - someone has archived data and received an attestions that contains the relevant metadata like: "Person XYZ has archived a contract between A, B, C concerning xxx at date D in the city of L conforming to law ZZZ and application degree GGG etc. The concerned parties are fiscally related to FFF. The content of the document has the hash H1 with hashes h2 to Hn for the chapters 2 to n", all that (most likely), digitally signed by the archive provider at the moment you receive it. - the digital signature can be confirmed with a hash link to a published daily hash next day or there is an ability to present the attestation to the archive provider asking whether this attestation is a good one by looking at his archive log. - If the relying parties can't agree, or when this is a fiscal control, etc a service needs to return the data. For this case one cannot depend on the good will of the initial client if the archived data are not in favor of his claim. Thus, a judge or even the other party may access. This may bring us to a requieremnt where the initial archiver should be able to indicate "identification information" of all the potential concerned relying parties. This identification information can be persons or companies, but also "done at Paris" in order to indicate that a judge in some court in Paris may access. (If hash algs are not secure, you still have physical copies that are dated.) From owner-ietf-ltans Thu Jan 29 02:20:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TAKREd094158; Thu, 29 Jan 2004 02:20:27 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TAKRMp094157; Thu, 29 Jan 2004 02:20:27 -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.11/8.12.8) with SMTP id i0TAKPIW094138 for ; Thu, 29 Jan 2004 02:20:25 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 19210 invoked from network); 29 Jan 2004 10:14:44 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:44 -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 17829-09 for ; Thu, 29 Jan 2004 11:14:25 +0100 (CET) Received: (qmail 19176 invoked from network); 29 Jan 2004 10:14:25 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:25 -0000 From: "A. Jerman Blazic" To: "'Peter Sylvester'" , Cc: Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Thu, 29 Jan 2004 11:21:58 +0100 Message-ID: <006301c3e651$b9e1ac60$1b018ac1@arthur> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200401281452.i0SEqMK07506@chandon.edelweb.fr> Importance: Normal 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: > > > > > > Isn't Authentication 'at distance' but not 'in time'. > > > > Basically I see a problem concerning the time too. The methods of > > authentification may change during the lifetime of a document (even > > more than once). And with that you might get problems. > Let's e.g. say > > you archived a contract about your newly bought house or > something and > > used at the beginning user/password authentication. For the next 20 > > years you are basically probably not interested in the document and > > might even forget your password, although you still have the URL of > > the document with all the evidence records. In the future > maybe even > > user/password authentication is no longer accepted by the server so > > you need something different > > - but what is important for the system: are you the same > person that > > stored the document 20 years ago ? > > Even with user/password you don't make a proof that you are > the person that stored, only that some accesses who knows > these values. > > There is a difference betwenn identification and authentication. > > The 'user' is not your 'identification', but an means for > authentication. You long term identification are the data on > your birth certificate; thus, when you register to such a > service, you have probably always to provide some information > about who you are, a copy of your national id card or whatever. > > This identification (potentially in an anonymous form) is then > associated by the provider with some authentication method: > You get a user/password. 20 years later (and even earlier) you > should be able to provide the same identification information > (or better, the the id of your grandparents) to access. I agree with peter completely. I also think one needs to clarify what procedures are we discussing about. Authorization is something that gives you power (or not) to access or use something. While identification is something else. So in case of archival services authorization is seen through rights to use the service or not (and of course the level of usage). However we still must keep the fact in mind that whatever we are archiving always belongs to somebody (something??). So the major question is: who has the rights to access the archived item? And after that: how do we identify the person with the acess rights? I think this should be clarified before we can even discuss the operational steages of the service. My wiev is, that this two main functions might be separated (although tightly corelated to the service), i.e. an authority identifying subjects in an open environment or mapping the rights to a subject. For example, as Peter stated, if I put something in the archive on behalf of my company, who will access the same archive once I change my job? Where are the connections between former and present employee? Aleksej > > > > Authorisation: > > In my understanding authorisation comes after some kind of > authentication > > (i.e. at first you know the identity of the other and then > you think about > > to allow him access to the data). > > > A role based access control seems feasable and hopefully not to > > complicated. (Maybe added with some sercret (document id ?) > generated > > at the time of > > storage.) > > > > The "judge/relevant authority" is of course on. > > A second one will be the user who stored the data. (Of > course he wants to be > > able to receive the evidence and maybe even the data he stored.) > > You almost never have the situation that some data only > belongs to one person durng a long period in time. The most > simplistic authorisation model which just has a 1=1 > correspondance is not sufficient. You can die at any moment, > you can delegate your power to someone else at any time etc. > > > Small remark: If the trusted archive does not provide the > data itself > > to normal requests, the authorisation topic might be easy, > as I think > > the retrieval of evidence to a document might not be a > security issue. > > The request for evidence could contain either the data or a > hash-value > > of the data (as long as the hash-algorithm is still secure). > > A not so small response :-) > > A request to an archiver may live the following way: > > - someone has archived data and received an attestions that > contains the relevant metadata like: > "Person XYZ has archived a contract between A, B, C concerning xxx > at date D in the city of L conforming to law ZZZ and application > degree GGG etc. The concerned parties are fiscally related to FFF. > > The content of the document has the hash H1 with hashes h2 to Hn > for the chapters 2 to n", > all that (most likely), digitally signed by the archive provider > at the moment you receive it. > > - the digital signature can be confirmed with a hash link to > a published daily hash next day or there is an ability to present > the attestation to the archive provider asking whether this > attestation > is a good one by looking at his archive log. > > - If the relying parties can't agree, > or when this is a fiscal control, etc > a service needs to return the data. For this case > one cannot depend on the good will of the initial > client if the archived data are not in favor of his > claim. Thus, a judge or even the other party may > access. This may bring us to a requieremnt where > the initial archiver should be able to indicate > "identification information" of all the > potential concerned relying parties. This > identification information can be persons or > companies, but also "done at Paris" in order > to indicate that a judge in some court in Paris > may access. > > (If hash algs are not secure, you still have physical copies > that are dated.) > > > > > From owner-ietf-ltans Thu Jan 29 03:36:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBaf2s001784; Thu, 29 Jan 2004 03:36:41 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TBafPB001783; Thu, 29 Jan 2004 03:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gilmore.ael.be (gilmore.ael.be [158.64.60.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBadhG001766 for ; Thu, 29 Jan 2004 03:36:39 -0800 (PST) (envelope-from adulau@foo.be) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id 3CCFB17347F; Thu, 29 Jan 2004 12:39:02 +0100 (CET) Received: by gilmore.ael.be (Postfix, from userid 519) id B814417347F; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id B258E17F402; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Date: Thu, 29 Jan 2004 12:39:01 +0100 (CET) From: Alexandre Dulaunoy X-X-Sender: adulau-conos@gilmore.ael.be To: "A. Jerman Blazic" Cc: "'Peter Sylvester'" , , Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication In-Reply-To: <006301c3e651$b9e1ac60$1b018ac1@arthur> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=7.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,WEIRD_PORT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004, A. Jerman Blazic wrote: > > This identification (potentially in an anonymous form) is then > > associated by the provider with some authentication method: > > You get a user/password. 20 years later (and even earlier) you > > should be able to provide the same identification information > > (or better, the the id of your grandparents) to access. > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. Yes, you are right. Just for an example, the freearchive.org is setting up and the authorization is working on two methods : - An open approach (as we gather free works) with a manual verification of the work (on the legal (if the work is free) and technical side (if the work permits a long-term storage)). - An authenticated approach where the manual verification is bypassed as the submission is coming from trusted sources (can be people or other digital repositories with an OAI or alike interface). On the two methods, an unique ID is generated by the repository for tracking the life of the digital work. Freearchive is a specific case where all work are frees and can be distributed without any restrictions. I think, this approach is well-known in various public domain digital libraries. I don't know if you can take this easily in the draft document. For the operational stages that seem more complicated to explain. Thanks a lot for your work, adulau -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov From owner-ietf-ltans Thu Jan 29 04:08:43 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TC8hSW004505; Thu, 29 Jan 2004 04:08:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TC8hTo004504; Thu, 29 Jan 2004 04:08:43 -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.11/8.12.8) with ESMTP id i0TC8fXc004489 for ; Thu, 29 Jan 2004 04:08:42 -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 NAA10061; Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0TC8Yt10628; Thu, 29 Jan 2004 13:08:34 +0100 (MET) Date: Thu, 29 Jan 2004 13:08:34 +0100 (MET) From: Peter Sylvester Message-Id: <200401291208.i0TC8Yt10628@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). Yes, and it seems that the question is to what degree the payload data are ... let's labelled or tainted with identification, types, roles, locations, etc. Such information need to be grouped in several categories depending on at least three interested parties: - the client itself, delegation of rights to employees or roles - the service (to distinguish groups of users, accounting, etc - other relying parties and external authorities (fiscal identification, locality, jurisdiction, ...) > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. There are many things which seems out of scope of this group. I am not sure whether one has to develop more than containers and type indications for identification data can be provided by/for a requester and for information can be associated to the request and response payloads so that these can be input for some decision making service using things like XACML SAML ... > My wiev is, that this two main functions might be separated (although > tightly corelated to the service), i.e. an authority identifying > subjects in an open environment or mapping the rights to a subject. For > example, as Peter stated, if I put something in the archive on behalf of > my company, who will access the same archive once I change my job? Where > are the connections between former and present employee? Just to remind another point: The authorition decision may not be possible 'on line' (as in many real life cases), thus a request to retrieve or validate cannot necessarily be answered immediately and may need manual intervention. Such a delay is not a problem, since it may be necessary to retrieve some disk from a bunker or else. Peter From owner-ietf-ltans Sat Jan 31 11:39:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJde1Z088984; Sat, 31 Jan 2004 11:39:40 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VJdeYB088983; Sat, 31 Jan 2004 11:39:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJdZSW088965 for ; Sat, 31 Jan 2004 11:39:38 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg1.isp.t-mobile.cz [62.141.25.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VJdX49002556 for ; Sat, 31 Jan 2004 20:39:47 +0100 (MET) From: To: Subject: My objections to the submitted draft Date: Sat, 31 Jan 2004 20:35:25 +0100 Message-ID: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C3E839.CF120370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_0046_01C3E839.CF120370 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >. > 2. Terminology > . > Timestamp: A signed confirmation generated by a Time Stamping > Authority (TSA) that a data item existed at a certain time. > [RFC3161] specifies a good structure for timestamps and a protocol > for communicating with a Timestamp Authority (TSA). It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps based on the linking hash principle. If we bind time stamp based on linking hash to the archived document, we could give to the court not one but two independent evidences of the document validity. I.e. digital signatures of archived documents would be added with nonsigned attribute - the enhanced time stamp based on other cryptographical principle - the linking hash. The base difference between time stamps based on linking hashes and those acc. to the RFC3161 is the fact that the time stamps based on the RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time stamps based on linking hashes expire when the used hash algorithm proves to be too week, which represents incomparably longer time. . > 3.2 Long-term Archive Service > > A Long-term Archive Service is to be designed to solve essential > parts of these problems by providing a specialized service: > > - The Long-term Archive Service is to store archived data objects > over a long, optionally undefined, period of time. . No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and canceling order which exactly defines the archiving time for every particular document type. (In most countries, it has been already legislated in 19th century.) But many of documents are archived permanently. This is the most complicated problem and the main aim of LTANS should be to solve problems of permanent archiving of digitally signed or timestamped documents. > - The Long-term Archive Service provides material needed to prove the > existence and integrity of data objects for users as well as in > court. The preceding sentence is not consistent with the following sentence: > A Long-term Archive Service is to not be designed to solve all > thinkable problems of long-term-verification of digital signatures. > It does not provide data necessary to verify signatures which are > part of the archived data object itself. This has to be done by > verifiers using PKI-Services like SCVP (Simple Certificate Validation > Protocol) or DVCS (Data Validation and Certification Server). How could the TAA give the evidence about the existence and integrity of a document without the data necessary for the verification of such evidence!? I think that we can discuss many things which the TAA standard should order or recommend, but it is no doubt that the TAA is obliged to give to a user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some type of data store. > This is done, in part, so the archive service can operate without > knowledge of numerous signed data formats, document formats, etc. It > also does not provide any means to integrate verification data in > data objects and verify embedded signatures. This has to be done on > the basis of other specifications, like RFC 3029 and with regard to > specifications of document formats. Of course it is recommended to > use such specifications together with a Long-term Archive Service. In this article of the draft, we can see that it is necessary to separate the draft work into several parallel standards. I.g. it is necessary either to make the RFC3029 into a form of an official standard or to define formats of archiving data. We cannot run the TAA without format specifications. The archive can accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to take care for the archived data formats. Let us have the following example: we have a record of important government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! The suggested draft does not take care about migration and emulation of archived documents. ------ The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. It does not take care for document cataloging, searching of documents, viewing of documents in undistorted form and document canceling. But document canceling seems to be very important archive functionality - it does not mean only destroying of the particular document but in some cases also export of the canceled document into another archive. ---- I am afraid that the submitted draft is only the idea of IT people how to archive documents and it should be discussed with real archivists which have their own idea about archiving. The archivists have a different approach and to create a useful digital archive we should listen to them. We must always keep in mind that the digital archive should offer al least the same services as the paper or parchment archive. Unfortunately the real archivist will decide about law and orders which will enable to replace paper archives with digital ones. Libor ------=_NextPart_000_0046_01C3E839.CF120370 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Zpráva

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.

 

>=20 2. Terminology

>=20 …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It is=20 a bit foolish to build everything on the “classical“ time = stamp.  Realize that the time stamp is = also only=20 a digitally signed structure… I do not understand why this draft = does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it is = not=20 more open to time stamps based on the linking hash principle. If we bind = time=20 stamp based on linking hash to the archived document, we could give to = the court=20 not one but two independent evidences of the document=20 validity.

 

I.e.=20 digital signatures of archived documents would be added with = nonsigned  attribute – the enhanced = time stamp=20 based on other cryptographical principle – the linking hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 expire = with=20 the expiration of their Time Stamping Authority certificate which issued = them=20 (see that we face exactly the same problem we faced in case of digital=20 signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, which=20 represents incomparably longer time.  

…   =20

>=20 3.2    Long-term = Archive=20 Service

>    =20

>   =20 A Long-term Archive Service is to be designed to solve essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>   -=20 The Long-term Archive Service is to store archived data objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for = undefined=20 time period. Every organization has its archiving and canceling order = which=20 exactly defines the archiving time for every particular document type. = (In most=20 countries, it has been already legislated in 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most complicated = problem=20 and the main aim of LTANS should be to solve problems of permanent = archiving of=20 digitally signed or timestamped documents.  

 

>   =20 - The Long-term Archive Service provides material needed to prove = the=20

>   =20 existence and integrity of data objects for users as well as in=20

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital = signatures.  =

>   =20 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

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document=20 without the data necessary for the verification of such evidence!? I = think that=20 we can discuss many things which the TAA standard should order or = recommend, but=20 it is no doubt that the TAA is obliged to give to a user all the = required data=20 necessary for existence and integrity proof of the appropriate document. = Without=20 this function the TAA would be only some type of data=20 store.

 

>   =20 This 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=20

>   =20 the basis of other specifications, like RFC 3029 and with regard = to=20

>   =20 specifications of document formats. =20 Of course it is recommended to =

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the draft=20 work into several parallel standards. I.g. it is necessary either to = make the=20 RFC3029 into a form of an official standard or to define formats of = archiving=20 data.

 

We=20 cannot run the TAA without format specifications. The archive can accept = only=20 data it can guarantee to be able to view them in undistorted form during = the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important government = meeting=20 stored in the MS Word 3.0. Such document should be archived permanently, = but=20 what to do with the document in MS Word 3.0 format (even now you = probably will=20 have a trouble to view it without distortion!) Obviously, the TAA could = not=20 accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According to=20 this draft, the archive only accepts and returns documents. It does not = take=20 care for document cataloging, searching of documents, viewing of = documents in=20 undistorted form and document = canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I am=20 afraid that the submitted draft is only the idea of IT people how to = archive=20 documents and it should be discussed with real archivists which have = their own=20 idea about archiving. The archivists have a different approach and to = create a=20 useful digital archive we should listen to them.=20

 

We must always keep in mind that the digital = archive=20 should offer al least the same services as the paper or parchment = archive.=20

 

Unfortunately the real archivist will decide = about law=20 and orders which will enable to replace paper archives with digital=20 ones.

 

Libor

------=_NextPart_000_0046_01C3E839.CF120370-- From owner-ietf-ltans Sat Jan 31 13:14:41 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEeUi093678; Sat, 31 Jan 2004 13:14:40 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VLEeiK093677; Sat, 31 Jan 2004 13:14:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEcJY093666 for ; Sat, 31 Jan 2004 13:14:39 -0800 (PST) (envelope-from marta.vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsh1.isp.t-mobile.cz [62.141.24.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VLF949003358 for ; Sat, 31 Jan 2004 22:15:11 +0100 (MET) From: "Marta.Vohnoutova@pvt.cz" To: Subject: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 22:11:00 +0100 Message-ID: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3E847.226C49B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_0001_01C3E847.226C49B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I am reading the archiving conference very carefuly and I hope that my idea abou attribute certification usage could be useful for your long term archiving standard creation. Identification of a user accessing the archive is interesting problem. But I think it is solved in the RFC-3281 and it is not necessary to specify it more. We should use the RFC-3281 which is of "Standard Track" category. It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree of this structure. It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive will be different (third party archiving service, specialized archive for company or for notaries etc.) Realize that the person storing the document into the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the document into an archive. The archived invoice is owned not by the accountant but by the company. The accountant cannot e.g. delete the invoice in the archive. During the archiving lifetime of the document, an inspection of a state tax office can come. Another company employee must pick up the invoice copy from the archive and submit it for the inspection. When the archived invoice lifetime is over, the invoice must be cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is in bankruptcy, it is required to archive documents later) or put the document for the permanent archiving (e.g. invoice for crown jewelry.) Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's certificate. The conclusion is: we can issue attribute certificates for (in this case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one day because the people roles and access rights can change quickly. The permanent bind of a concrete role to a concrete person does not exist. Cordially Marta Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_0001_01C3E847.226C49B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zpráva
Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I think = it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should use=20 the RFC-3281 which is of „Standard Track“ category. It would = be enough to solve=20 the structure of archived documents because the attribute certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries=20 etc.) Realize that the person storing the document into the archive is = rarely=20 the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant marks=20 the archiving time in the invoice and stores the document into an = archive. The=20 archived invoice is owned not by the accountant but by the company. The=20 accountant cannot e.g. delete the invoice in the archive.=20

 

During the archiving lifetime of the document, = an=20 inspection of a state tax office can come. Another company employee must = pick up=20 the invoice copy from the archive and submit it for the inspection.=20

 

When=20 the archived invoice lifetime is over, the invoice must be cancelled = (destroyed)=20 from the archive. And again another person of the company is responsible = for=20 canceling. This person must decide whether to cancel document or whether = to=20 archive it later (for example, if the company is in bankruptcy, it is = required=20 to archive documents later) or put the document for the permanent = archiving=20 (e.g. invoice for crown = jewelry…)

 

Attribute certificate can vary in time = according to e.g.=20 changes in some database of clients of archive. They are bound with the = user’s=20 certificate. The conclusion is: we can issue attribute certificates for = (in this=20 case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate (view=20 right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day because = the=20 people roles and access rights can change quickly. The permanent bind of = a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta Vohnoutova=20 PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_0001_01C3E847.226C49B0-- From owner-ietf-ltans Sat Jan 31 18:19:55 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112JtM7012474; Sat, 31 Jan 2004 18:19:55 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i112Jthm012473; Sat, 31 Jan 2004 18:19:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jste012463 for ; Sat, 31 Jan 2004 18:19:54 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102193611100elag3e>; Sun, 1 Feb 2004 02:19:39 +0000 From: "Santosh Chokhani" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3E83F.EEF911F0" 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: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> 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_000A_01C3E83F.EEF911F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marta: =20 There does not seem to be any benefit gained by using the attribute certificate format for archived data. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Marta.Vohnoutova@pvt.cz Sent: Saturday, January 31, 2004 4:11 PM To: ietf-ltans@imc.org Subject: Role of attribute certificates in long-term archiving Hi all, I am reading the archiving conference very carefuly and I hope that my = idea abou attribute certification usage could be useful for your long term archiving standard creation. =20 Identification of a user accessing the archive is interesting problem. = But I think it is solved in the RFC-3281 and it is not necessary to specify = it more. We should use the RFC-3281 which is of "Standard Track" category. = It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree = of this structure. =20 It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive = will be different (third party archiving service, specialized archive for = company or for notaries etc.) Realize that the person storing the document into = the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the = document into an archive. The archived invoice is owned not by the accountant but = by the company. The accountant cannot e.g. delete the invoice in the = archive.=20 =20 During the archiving lifetime of the document, an inspection of a state = tax office can come. Another company employee must pick up the invoice copy = from the archive and submit it for the inspection.=20 =20 When the archived invoice lifetime is over, the invoice must be = cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is = in bankruptcy, it is required to archive documents later) or put the = document for the permanent archiving (e.g. invoice for crown jewelry.) =20 Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's = certificate. The conclusion is: we can issue attribute certificates for (in this = case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute = certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one = day because the people roles and access rights can change quickly. The = permanent bind of a concrete role to a concrete person does not exist. =20 Cordially Marta =20 Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_000A_01C3E83F.EEF911F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Marta:
 
There=20 does not seem to be any benefit gained by using the attribute = certificate format=20 for archived data.
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Marta.Vohnoutova@pvt.cz
Sent: Saturday, = January 31,=20 2004 4:11 PM
To: ietf-ltans@imc.org
Subject: Role = of=20 attribute certificates in long-term archiving

Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I = think it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should=20 use the RFC-3281 which is of „Standard Track“ category. It = would be enough to=20 solve the structure of archived documents because the attribute = certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries etc.) Realize that the person storing the document into the = archive=20 is rarely the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant=20 marks the archiving time in the invoice and stores the document into = an=20 archive. The archived invoice is owned not by the accountant but by = the=20 company. The accountant cannot e.g. delete the invoice in the archive. =

 

During the archiving lifetime of the = document, an=20 inspection of a state tax office can come. Another company employee = must pick=20 up the invoice copy from the archive and submit it for the inspection. =

 

When the archived invoice lifetime is over, = the invoice=20 must be cancelled (destroyed) from the archive. And again another = person of=20 the company is responsible for canceling. This person must decide = whether to=20 cancel document or whether to archive it later (for example, if the = company is=20 in bankruptcy, it is required to archive documents later) or put the = document=20 for the permanent archiving (e.g. invoice for crown=20 jewelry…)

 

Attribute certificate can vary in time = according to=20 e.g. changes in some database of clients of archive. They are bound = with the=20 user’s certificate. The conclusion is: we can issue attribute = certificates for=20 (in this case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate=20 (view right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day = because the=20 people roles and access rights can change quickly. The permanent bind = of a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta=20 Vohnoutova PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_000A_01C3E83F.EEF911F0-- From owner-ietf-ltans Sat Jan 31 18:19:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jv1v012483; Sat, 31 Jan 2004 18:19:57 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i112Jvo5012481; Sat, 31 Jan 2004 18:19:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jstf012463 for ; Sat, 31 Jan 2004 18:19:56 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102194411100elag4e>; Sun, 1 Feb 2004 02:19:44 +0000 From: "Santosh Chokhani" To: Subject: RE: My objections to the submitted draft Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3E83F.F2461A10" 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: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> 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_000F_01C3E83F.F2461A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Libor: =20 See my responses in line -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Libor.Dostalek@pvt.cz Sent: Saturday, January 31, 2004 2:35 PM To: ietf-ltans@imc.org Subject: My objections to the submitted draft Hi,=20 I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >.=20 =20 > 2. Terminology > . > 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 It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I = do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps = based on the linking hash principle. If we bind time stamp based on linking = hash to the archived document, we could give to the court not one but two independent evidences of the document validity. [Santosh Chokhani] There may be some patent related concerns regarding = the linked time stamp (Surety in US).=20 =20 I.e. digital signatures of archived documents would be added with = nonsigned attribute - the enhanced time stamp based on other cryptographical = principle - the linking hash. =20 =20 The base difference between time stamps based on linking hashes and = those acc. to the RFC3161 is the fact that the time stamps based on the = RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time = stamps based on linking hashes expire when the used hash algorithm proves to be = too week, which represents incomparably longer time. =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. . =20 No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and = canceling order which exactly defines the archiving time for every particular = document type. (In most countries, it has been already legislated in 19th = century.) =20 But many of documents are archived permanently. This is the most = complicated problem and the main aim of LTANS should be to solve problems of = permanent archiving of digitally signed or timestamped documents. =20 [Santosh Chokhani] I think LTANS is trying to solve that problem=20 =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. =20 =20 The preceding sentence is not consistent with the following sentence: =20 > A Long-term Archive Service is to not be designed to solve all=20 > thinkable problems of long-term-verification of digital signatures. = =20 > 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).=20 =20 How could the TAA give the evidence about the existence and integrity of = a document without the data necessary for the verification of such = evidence!? [Santosh Chokhani] The party who archives the data is responsible for providing all the evidence that it might need. Thus, if some one wants = to archive digital signatures or digital signatures and SCVP responses, = they need to include the signed document, signed SCVP responses and SCVP = trust anchor in order to obtain these from the TAA at a later time and = demonstrate the signature was valid at some time in the past. =20 I think that we can discuss many things which the TAA standard should = order or recommend, but it is no doubt that the TAA is obliged to give to a = user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some = type of data store. [Santosh Chokhani] I think TAA needs to play back what the user = submitted and ensure the integrity of the user submission. If the data happens to = be signed data, the user can submit relevant trust anchors, certificates, = and revocation information to demonstrate the signature was valid when = applied. But, TAA need not gather all this; neither does TAA need to be limited = to archive signed data.=20 =20 > This 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 = > specifications of document formats. Of course it is recommended to = > use such specifications together with a Long-term Archive Service.=20 =20 In this article of the draft, we can see that it is necessary to = separate the draft work into several parallel standards. I.g. it is necessary = either to make the RFC3029 into a form of an official standard or to define = formats of archiving data. =20 We cannot run the TAA without format specifications. The archive can = accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to = take care for the archived data formats. =20 =20 Let us have the following example: we have a record of important = government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format = (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! =20 =20 The suggested draft does not take care about migration and emulation of archived documents. =20 ------ =20 The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. = It does not take care for document cataloging, searching of documents, = viewing of documents in undistorted form and document canceling. =20 But document canceling seems to be very important archive functionality = - it does not mean only destroying of the particular document but in some = cases also export of the canceled document into another archive. =20 =20 ---- I am afraid that the submitted draft is only the idea of IT people how = to archive documents and it should be discussed with real archivists which = have their own idea about archiving. The archivists have a different approach = and to create a useful digital archive we should listen to them.=20 =20 We must always keep in mind that the digital archive should offer al = least the same services as the paper or parchment archive.=20 =20 Unfortunately the real archivist will decide about law and orders which = will enable to replace paper archives with digital ones. =20 Libor ------=_NextPart_000_000F_01C3E83F.F2461A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Libor:
 
See my=20 responses in line
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Libor.Dostalek@pvt.cz
Sent: Saturday, January = 31, 2004=20 2:35 PM
To: ietf-ltans@imc.org
Subject: My = objections to=20 the submitted draft

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.=20

 

> 2. = Terminology

> = …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain = time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It=20 is a bit foolish to build everything on the “classical“ = time stamp.  Realize that the time stamp = is also=20 only a digitally signed structure… I do not understand why this = draft does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it = is not=20 more open to time stamps based on the linking hash principle. If we = bind time=20 stamp based on linking hash to the archived document, we could give to = the=20 court not one but two independent evidences of the document=20 validity.
[Santosh = Chokhani] There may=20 be some patent related concerns regarding the linked time stamp = (Surety in=20 US). 

 

I.e. digital signatures of archived documents = would be=20 added with nonsigned  = attribute –=20 the enhanced time stamp based on other cryptographical principle = – the linking=20 hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 = expire with=20 the expiration of their Time Stamping Authority certificate which = issued them=20 (see that we face exactly the same problem we faced in case of digital = signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, = which=20 represents incomparably longer time.  

…   =20

> 3.2    Long-term = Archive Service=20

>    =20

>   =20 A Long-term Archive Service is to be designed to solve = essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>  =20 - The Long-term Archive Service is to store archived data = objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for=20 undefined time period. Every organization has its archiving and = canceling=20 order which exactly defines the archiving time for every particular = document=20 type. (In most countries, it has been already legislated in = 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most = complicated=20 problem and the main aim of LTANS should be to solve problems of = permanent=20 archiving of digitally signed or timestamped documents.  
[Santosh Chokhani] I think = LTANS is=20 trying to solve that=20 problem 

 

>   =20 - The Long-term Archive Service provides material needed to = prove the=20

>   =20 existence and integrity of data objects for users as well as in =

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital=20 signatures. =20

>   =20 It does not provide data necessary to verify signatures which = are=20

>   =20 part of the archived data object itself.  This has to be done by=20

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document without the data necessary for the verification of such=20 evidence!?
[Santosh Chokhani] The party who archives the data is = responsible=20 for providing all the evidence that it might need.  Thus, if some = one=20 wants to archive digital signatures or digital signatures and SCVP = responses,=20 they need to include the signed document, signed SCVP responses and = SCVP trust=20 anchor in order to obtain these from the TAA at a later time and = demonstrate=20 the signature was valid at some time in the=20 past.

 

I=20 think that we can discuss many things which the TAA standard should = order or=20 recommend, but it is no doubt that the TAA is obliged to give to a = user all=20 the required data necessary for existence and integrity proof of the=20 appropriate document. Without this function the TAA would be only some = type of=20 data store.
[Santosh = Chokhani] I think=20 TAA needs to play back what the user submitted and ensure the = integrity of the=20 user submission.  If the data happens to be signed data, the user = can=20 submit relevant trust anchors, certificates, and revocation = information to=20 demonstrate the signature was valid when applied.  But, TAA = need not=20 gather all this; neither does TAA need to be limited to archive signed = data. 

 

>   =20 This is done, in part, so the archive service can operate = without=20

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It=20

>   =20 also does not provide any means to integrate verification data = in=20

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with = regard to=20

>   =20 specifications of document formats.  Of course it is recommended = to=20

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the=20 draft work into several parallel standards. I.g. it is necessary = either to=20 make the RFC3029 into a form of an official standard or to define = formats of=20 archiving data.

 

We=20 cannot run the TAA without format specifications. The archive can = accept only=20 data it can guarantee to be able to view them in undistorted form = during the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important = government=20 meeting stored in the MS Word 3.0. Such document should be archived=20 permanently, but what to do with the document in MS Word 3.0 format = (even now=20 you probably will have a trouble to view it without distortion!) = Obviously,=20 the TAA could not accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According=20 to this draft, the archive only accepts and returns documents. It does = not=20 take care for document cataloging, searching of documents, viewing of=20 documents in undistorted form and document=20 canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I=20 am afraid that the submitted draft is only the idea of IT people how = to=20 archive documents and it should be discussed with real archivists = which have=20 their own idea about archiving. The archivists have a different = approach and=20 to create a useful digital archive we should listen to them.

 

We must always keep in mind = that the=20 digital archive should offer al least the same services as the paper = or=20 parchment archive.

 

Unfortunately the real = archivist will=20 decide about law and orders which will enable to replace paper = archives with=20 digital ones.

 

Libor

------=_NextPart_000_000F_01C3E83F.F2461A10-- From owner-ietf-ltans Sat Jan 31 22:38:39 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116cdW3040712; Sat, 31 Jan 2004 22:38:39 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i116cdK1040711; Sat, 31 Jan 2004 22:38:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116caVm040620 for ; Sat, 31 Jan 2004 22:38:37 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116cm49013489 for ; Sun, 1 Feb 2004 07:38:51 +0100 (MET) From: To: Subject: RE: My objections to the submitted draft Date: Sun, 1 Feb 2004 07:34:38 +0100 Message-ID: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> 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.4024 Importance: Normal In-Reply-To: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Santosh Chokhani] There may be some patent related concerns regarding the linked time stamp (Surety in US). Why uses the submitted draft only time stmps based on RFC-3161? . > > 3.2 Long-term Archive Service > > > > A Long-term Archive Service is to be designed to solve essential > > parts of these problems by providing a specialized service: > > > > - The Long-term Archive Service is to store archived data objects > > over a long, optionally undefined, period of time. . > No reasonable company or organization will not archive its documents for > undefined time period. Every organization has its archiving and > canceling order which exactly defines the archiving time for every > particular document type. (In most countries, it has been already > legislated in 19th century.) > But many of documents are archived permanently. This is the most > complicated problem and the main aim of LTANS should be to solve > problems of permanent archiving of digitally signed or timestamped > documents. [Santosh Chokhani] I think LTANS is trying to solve that problem I am afraid it is not fully true. See the following example: Let us have a signed documnet archived for 200 yers. All signatures of this document are based on RSA algortithm with 1K keys. It means that every two years all the signatures are renewed. The problem is that I have chain of 100 timestamps (based on RFC-3161). Libor From owner-ietf-ltans Sat Jan 31 22:57:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vRZQ049104; Sat, 31 Jan 2004 22:57:27 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i116vR3b049103; Sat, 31 Jan 2004 22:57:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vPl9049030 for ; Sat, 31 Jan 2004 22:57:26 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116w349019043 for ; Sun, 1 Feb 2004 07:58:08 +0100 (MET) From: To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sun, 1 Feb 2004 07:53:53 +0100 Message-ID: <000101c3e890$306f48c0$314c18ac@pvt.cz> 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.4024 Importance: Normal In-Reply-To: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Marta: > > There does not seem to be any benefit gained by using the attribute certificate format > for archived data. I think the digital archive must have at least the same features as classical stone archive. My personal expirience is if you want to explore some old documents in archive you must first prove your identity, explain your purpose why you need these documents, and based on this the appropriate permitions for the specific part of archive is given to you. Analogically in digital world, you can prove your identity with certificate and attributte certificate represents appropriate permitions given to you. Identity of person who put document into archive 50 years ago could be irrelevant. Marta From owner-ietf-ltans Sat Jan 31 23:59:19 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xJtB070227; Sat, 31 Jan 2004 23:59:19 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i117xJ84070225; Sat, 31 Jan 2004 23:59:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xHuE070212 for ; Sat, 31 Jan 2004 23:59:18 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust250.tnt59.dfw5.da.uu.net ([67.203.43.250] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AnCVQ-0003iw-00; Sun, 01 Feb 2004 02:59:01 -0500 Message-ID: <401CCC88.597001E9@ix.netcom.com> Date: Sun, 01 Feb 2004 01:53:15 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Libor.Dostalek@pvt.cz CC: ietf-ltans@imc.org, Mark milone Subject: Re: My objections to the submitted draft References: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor and all, Your point below is well taken and has been and is being discussed on other venues/forums regarding legal documents or those that may be of some legal interest. Many have very long term life. RFC 3161 failed to recognize these factors, even though they were discussed at the time RFC 3161 was under consideration. Hence it's revision would seem to be in order... Libor.Dostalek@pvt.cz wrote: > [Santosh Chokhani] There may be some patent related concerns regarding > the linked time stamp (Surety in US). > > Why uses the submitted draft only time stmps based on RFC-3161? > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > No reasonable company or organization will not archive its documents > for > > undefined time period. Every organization has its archiving and > > canceling order which exactly defines the archiving time for every > > particular document type. (In most countries, it has been already > > legislated in 19th century.) > > > But many of documents are archived permanently. This is the most > > complicated problem and the main aim of LTANS should be to solve > > problems of permanent archiving of digitally signed or timestamped > > documents. > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > I am afraid it is not fully true. See the following example: > Let us have a signed documnet archived for 200 yers. All signatures > of this document are based on RSA algortithm with 1K keys. It means > that every two years all the signatures are renewed. The problem is > that I have chain of 100 timestamps (based on RFC-3161). > > Libor Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 01:19:08 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i119J8X7096556; Sun, 1 Feb 2004 01:19:08 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i119J7EC096552; Sun, 1 Feb 2004 01:19:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gilmore.ael.be (gilmore.ael.be [158.64.60.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i119J4OS096514 for ; Sun, 1 Feb 2004 01:19:05 -0800 (PST) (envelope-from adulau@foo.be) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id 997FC17347A; Sun, 1 Feb 2004 10:19:06 +0100 (CET) Received: by gilmore.ael.be (Postfix, from userid 519) id 3454F17347A; Sun, 1 Feb 2004 10:19:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id 32E0A17F402; Sun, 1 Feb 2004 10:19:06 +0100 (CET) Date: Sun, 1 Feb 2004 10:19:06 +0100 (CET) From: Alexandre Dulaunoy X-X-Sender: adulau-conos@gilmore.ael.be To: Marta.Vohnoutova@pvt.cz Cc: ietf-ltans@imc.org Subject: RE: Role of attribute certificates in long-term archiving In-Reply-To: <000101c3e890$306f48c0$314c18ac@pvt.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.6 required=7.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,WEIRD_PORT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 1 Feb 2004 Marta.Vohnoutova@pvt.cz wrote: > > > Marta: > > > > There does not seem to be any benefit gained by using the attribute > certificate format > > for archived data. > > I think the digital archive must have at least the same features as > classical stone archive. My personal expirience is if you want to > explore some old documents in archive you must first prove your > identity, explain your purpose why you need these documents, and based > on this the appropriate permitions for the specific part of archive is > given to you. Except for the public archive of the public administration or public domain archive/libraries. The only limitation is sometimes the conservative approach of the physical media/support (in the digital world, we don't have this issue but we have others ;-) but no proof is required for accessing the archive. The document should consider the both aspect of long-term archiving where a "proof" is required for accessing and where "proof" is not required for accessing. > Analogically in digital world, you can prove your identity with > certificate and attributte certificate represents appropriate permitions > given to you. Yes but sometimes is not required or optional. > > Identity of person who put document into archive 50 years ago could be > irrelevant. Yes. just my .02 EUR, adulau -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov From owner-ietf-ltans Sun Feb 1 06:49:47 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11EnlEE035779; Sun, 1 Feb 2004 06:49:47 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11EnlGR035778; Sun, 1 Feb 2004 06:49:47 -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.11/8.12.8) with ESMTP id i11Enkq4035772 for ; Sun, 1 Feb 2004 06:49:46 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (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 i11EnjjU009250 for ; Sun, 1 Feb 2004 09:49:45 -0500 From: "Santosh Chokhani" To: Subject: RE: My objections to the submitted draft Date: Sun, 1 Feb 2004 09:49:41 -0500 Message-ID: <004201c3e8d2$a3145220$a9414d0c@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: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The rate of refresh is not dependent on the original signature, but the cryptographic strength of the last signature by the TSA. Thus, as the technology advances TSA is expected to have stronger keys. Thus, in your example, there should be few refreshes. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Libor.Dostalek@pvt.cz Sent: Sunday, February 01, 2004 1:35 AM To: ietf-ltans@imc.org Subject: RE: My objections to the submitted draft [Santosh Chokhani] There may be some patent related concerns regarding the linked time stamp (Surety in US). Why uses the submitted draft only time stmps based on RFC-3161? . > > 3.2 Long-term Archive Service > > > > A Long-term Archive Service is to be designed to solve essential > > parts of these problems by providing a specialized service: > > > > - The Long-term Archive Service is to store archived data objects > > over a long, optionally undefined, period of time. . > No reasonable company or organization will not archive its documents for > undefined time period. Every organization has its archiving and > canceling order which exactly defines the archiving time for every > particular document type. (In most countries, it has been already > legislated in 19th century.) > But many of documents are archived permanently. This is the most > complicated problem and the main aim of LTANS should be to solve > problems of permanent archiving of digitally signed or timestamped > documents. [Santosh Chokhani] I think LTANS is trying to solve that problem I am afraid it is not fully true. See the following example: Let us have a signed documnet archived for 200 yers. All signatures of this document are based on RSA algortithm with 1K keys. It means that every two years all the signatures are renewed. The problem is that I have chain of 100 timestamps (based on RFC-3161). Libor From owner-ietf-ltans Sun Feb 1 07:55:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11Ft2Hj039970; Sun, 1 Feb 2004 07:55:02 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11Ft2X0039969; Sun, 1 Feb 2004 07:55:02 -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.11/8.12.8) with ESMTP id i11Ft1hi039960 for ; Sun, 1 Feb 2004 07:55:01 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (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 i11Ft2jU018658 for ; Sun, 1 Feb 2004 10:55:02 -0500 From: "Santosh Chokhani" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sun, 1 Feb 2004 10:54:57 -0500 Message-ID: <004801c3e8db$c0e34eb0$a9414d0c@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: <000101c3e890$306f48c0$314c18ac@pvt.cz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i11Ft1hi039962 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Marta: If you are talking about who has the authorizations to access the digital archive, we can discuss some of the options for authentication and authorization for retrieval. I interpreted your e-mail as saying that the archived document should be in the form of an attribute certificate. Now in terms of authentication and authorization, given the potential long life time of the archive, we have to be concerned with the following issues: -- Cryptographic strength of end entity certificate -- Cryptographic strength of authority (CA and attribute authority) certificate -- Stability of names asserted the certificates -- Stability of the attributes names asserted in the attribute certificate If the group decides that authentication and authorization standard should be included for retrieval (as opposed to retrieval being a matter of local archive policy), then we need to keep the above in mind to determine how the long-term identity validation and authorization should be done. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Marta.Vohnoutova@pvt.cz Sent: Sunday, February 01, 2004 1:54 AM To: ietf-ltans@imc.org Subject: RE: Role of attribute certificates in long-term archiving > Marta: > > There does not seem to be any benefit gained by using the attribute certificate format > for archived data. I think the digital archive must have at least the same features as classical stone archive. My personal expirience is if you want to explore some old documents in archive you must first prove your identity, explain your purpose why you need these documents, and based on this the appropriate permitions for the specific part of archive is given to you. Analogically in digital world, you can prove your identity with certificate and attributte certificate represents appropriate permitions given to you. Identity of person who put document into archive 50 years ago could be irrelevant. Marta From owner-ietf-ltans Sun Feb 1 09:31:15 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11HVFna046203; Sun, 1 Feb 2004 09:31:15 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11HVFXA046202; Sun, 1 Feb 2004 09:31:15 -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.11/8.12.8) with SMTP id i11HVDSI046194 for ; Sun, 1 Feb 2004 09:31:13 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 27678 invoked by uid 522); 1 Feb 2004 17:25:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Feb 2004 17:25:26 -0000 Date: Sun, 1 Feb 2004 18:25:26 +0100 (CET) From: Aleksej Blazic To: Libor.Dostalek@pvt.cz cc: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft In-Reply-To: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 31 Jan 2004 Libor.Dostalek@pvt.cz wrote: Libor, what we should try to avoid in the first place, is try to map an analogue archive to an e-archive, so the opinion of "real" archivist does not seem to be always of major importance while defining standards for TAS. It is also not the intention of LTANS to define document storage structures, but in my opinion to introduce mechanisms on how to assure the integrity of a record and validity of security attributes. Document storage is something that belongs to DMS systems or OAIS and it should be kept that way. TAS should focus on how to assemble the needed information and data to support the stored record for a defined period in time.. However I do agree and support the statement that several standards should come out within the LTANS initiative. So far we faced an approach of how to define an interaction with an archive and what is critically missing in the next step are archival data structures. TAS might always operate as a stand alone entity, mainly dealing with archival complementary data (not archived documents!!). And most importantly: why do we need data structures? To assure transparency and existence of an archive over undefined period of time. And finally, archivists play their general role in archiving records, but does a stand alone company need an archivist? Not really. Although laws dictates the archiving time of a document, a closet does perform more than perfect. So, before we are discussing further the main question remains: what is the purpose of the archive we are trying to define? Best regards Aleksej > Hi, > > I have several things in the submitted draft which are unclear to me. To > have a Berger orientation I put here also the unclear parts of the draft > marked with the leading >. > > > > > 2. Terminology > > > . > > > Timestamp: A signed confirmation generated by a Time Stamping > > > Authority (TSA) that a data item existed at a certain time. > > > [RFC3161] specifies a good structure for timestamps and a protocol > > > for communicating with a Timestamp Authority (TSA). > > > > It is a bit foolish to build everything on the "classical" time stamp. > Realize that the time stamp is also only a digitally signed structure. I > do not understand why this draft does not mention the time stamp acc. to > RFC3161 only as eventuality and why it is not more open to time stamps > based on the linking hash principle. If we bind time stamp based on > linking hash to the archived document, we could give to the court not > one but two independent evidences of the document validity. > > > > I.e. digital signatures of archived documents would be added with > nonsigned attribute - the enhanced time stamp based on other > cryptographical principle - the linking hash. > > > > The base difference between time stamps based on linking hashes and > those acc. to the RFC3161 is the fact that the time stamps based on the > RFC3161 expire with the expiration of their Time Stamping Authority > certificate which issued them (see that we face exactly the same problem > we faced in case of digital signature, what this draft should solve), > while time stamps based on linking hashes expire when the used hash > algorithm proves to be too week, which represents incomparably longer > time. > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > > > No reasonable company or organization will not archive its documents for > undefined time period. Every organization has its archiving and > canceling order which exactly defines the archiving time for every > particular document type. (In most countries, it has been already > legislated in 19th century.) > > > > But many of documents are archived permanently. This is the most > complicated problem and the main aim of LTANS should be to solve > problems of permanent archiving of digitally signed or timestamped > documents. > > > > > - The Long-term Archive Service provides material needed to prove > the > > > existence and integrity of data objects for users as well as in > > > court. > > > > The preceding sentence is not consistent with the following sentence: > > > > > A Long-term Archive Service is to not be designed to solve all > > > thinkable problems of long-term-verification of digital signatures. > > > > It does not provide data necessary to verify signatures which are > > > part of the archived data object itself. This has to be done by > > > verifiers using PKI-Services like SCVP (Simple Certificate > Validation > > > Protocol) or DVCS (Data Validation and Certification Server). > > > > How could the TAA give the evidence about the existence and integrity of > a document without the data necessary for the verification of such > evidence!? I think that we can discuss many things which the TAA > standard should order or recommend, but it is no doubt that the TAA is > obliged to give to a user all the required data necessary for existence > and integrity proof of the appropriate document. Without this function > the TAA would be only some type of data store. > > > > > This is done, in part, so the archive service can operate without > > > knowledge of numerous signed data formats, document formats, etc. > It > > > also does not provide any means to integrate verification data in > > > data objects and verify embedded signatures. This has to be done on > > > > the basis of other specifications, like RFC 3029 and with regard to > > > > specifications of document formats. Of course it is recommended to > > > > use such specifications together with a Long-term Archive Service. > > > > In this article of the draft, we can see that it is necessary to > separate the draft work into several parallel standards. I.g. it is > necessary either to make the RFC3029 into a form of an official standard > or to define formats of archiving data. > > > > We cannot run the TAA without format specifications. The archive can > accept only data it can guarantee to be able to view them in undistorted > form during the whole archiving time. It is not possible for the TAA not > to take care for the archived data formats. > > > > Let us have the following example: we have a record of important > government meeting stored in the MS Word 3.0. Such document should be > archived permanently, but what to do with the document in MS Word 3.0 > format (even now you probably will have a trouble to view it without > distortion!) Obviously, the TAA could not accept such document! > > > > The suggested draft does not take care about migration and emulation of > archived documents. > > > > ------ > > > > The lifetime of the archived document is also not solved in this draft. > According to this draft, the archive only accepts and returns documents. > It does not take care for document cataloging, searching of documents, > viewing of documents in undistorted form and document canceling. > > > > But document canceling seems to be very important archive functionality > - it does not mean only destroying of the particular document but in > some cases also export of the canceled document into another archive. > > > > ---- > > I am afraid that the submitted draft is only the idea of IT people how > to archive documents and it should be discussed with real archivists > which have their own idea about archiving. The archivists have a > different approach and to create a useful digital archive we should > listen to them. > > > > We must always keep in mind that the digital archive should offer al > least the same services as the paper or parchment archive. > > > > Unfortunately the real archivist will decide about law and orders which > will enable to replace paper archives with digital ones. > > > > Libor > > From owner-ietf-ltans Sun Feb 1 11:05:37 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11J5bCR051593; Sun, 1 Feb 2004 11:05:37 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11J5b1C051592; Sun, 1 Feb 2004 11:05:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11J5Z9k051585 for ; Sun, 1 Feb 2004 11:05:36 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust147.tnt36.dfw9.da.uu.net ([67.234.81.147] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AnMuR-0003Nz-00; Sun, 01 Feb 2004 14:05:31 -0500 Message-ID: <401D68C0.3FD593F1@ix.netcom.com> Date: Sun, 01 Feb 2004 12:59:46 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <004201c3e8d2$a3145220$a9414d0c@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh and all, Understood here. However this only in part addresses the problems or likely conflict with RFC 3161 as previously indicated.. Santosh Chokhani wrote: > The rate of refresh is not dependent on the original signature, but the > cryptographic strength of the last signature by the TSA. Thus, as the > technology advances TSA is expected to have stronger keys. > > Thus, in your example, there should be few refreshes. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Libor.Dostalek@pvt.cz > Sent: Sunday, February 01, 2004 1:35 AM > To: ietf-ltans@imc.org > Subject: RE: My objections to the submitted draft > > [Santosh Chokhani] There may be some patent related concerns regarding the > linked time stamp (Surety in US). > > Why uses the submitted draft only time stmps based on RFC-3161? > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > No reasonable company or organization will not archive its documents > for > > undefined time period. Every organization has its archiving and > > canceling order which exactly defines the archiving time for every > > particular document type. (In most countries, it has been already > > legislated in 19th century.) > > > But many of documents are archived permanently. This is the most > > complicated problem and the main aim of LTANS should be to solve > > problems of permanent archiving of digitally signed or timestamped > > documents. > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > I am afraid it is not fully true. See the following example: Let us have a > signed documnet archived for 200 yers. All signatures > of this document are based on RSA algortithm with 1K keys. It means that > every two years all the signatures are renewed. The problem is > that I have chain of 100 timestamps (based on RFC-3161). > > Libor Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 11:13:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11JDere052061; Sun, 1 Feb 2004 11:13:40 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11JDd2M052054; Sun, 1 Feb 2004 11:13:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11JDYab052029 for ; Sun, 1 Feb 2004 11:13:34 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust147.tnt36.dfw9.da.uu.net ([67.234.81.147] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AnN2E-0007Bh-00; Sun, 01 Feb 2004 14:13:34 -0500 Message-ID: <401D6AA4.C8D1A5AB@ix.netcom.com> Date: Sun, 01 Feb 2004 13:07:49 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-ltans@imc.org, Mark milone Subject: Re: Role of attribute certificates in long-term archiving References: <004801c3e8db$c0e34eb0$a9414d0c@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh and all, I fully agree with your list of concerning issues, Santosh. However there is also the issue of legal jurisdiction in multiple international jurisdictions. Has anyone else given this consideration given recent laws passed in some EU and Asian countries? Santosh Chokhani wrote: > Marta: > > If you are talking about who has the authorizations to access the digital > archive, we can discuss some of the options for authentication and > authorization for retrieval. I interpreted your e-mail as saying that the > archived document should be in the form of an attribute certificate. > > Now in terms of authentication and authorization, given the potential long > life time of the archive, we have to be concerned with the following issues: > > -- Cryptographic strength of end entity certificate > -- Cryptographic strength of authority (CA and attribute authority) > certificate > -- Stability of names asserted the certificates > -- Stability of the attributes names asserted in the attribute > certificate > > If the group decides that authentication and authorization standard should > be included for retrieval (as opposed to retrieval being a matter of local > archive policy), then we need to keep the above in mind to determine how the > long-term identity validation and authorization should be done. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Marta.Vohnoutova@pvt.cz > Sent: Sunday, February 01, 2004 1:54 AM > To: ietf-ltans@imc.org > Subject: RE: Role of attribute certificates in long-term archiving > > > Marta: > > > > There does not seem to be any benefit gained by using the attribute > certificate format > > for archived data. > > I think the digital archive must have at least the same features as > classical stone archive. My personal expirience is if you want to explore > some old documents in archive you must first prove your identity, explain > your purpose why you need these documents, and based on this the appropriate > permitions for the specific part of archive is given to you. > > Analogically in digital world, you can prove your identity with certificate > and attributte certificate represents appropriate permitions given to you. > > Identity of person who put document into archive 50 years ago could be > irrelevant. > > Marta > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 11:11:10 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11JBAmc051822; Sun, 1 Feb 2004 11:11:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11JBABH051821; Sun, 1 Feb 2004 11:11:10 -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.11/8.12.8) with ESMTP id i11JB90I051815 for ; Sun, 1 Feb 2004 11:11:09 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (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 i11JB9jU020189 for ; Sun, 1 Feb 2004 14:11:09 -0500 From: "Santosh Chokhani" To: Subject: RE: My objections to the submitted draft Date: Sun, 1 Feb 2004 14:11:03 -0500 Message-ID: <008e01c3e8f7$265e8280$a9414d0c@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: <401D68C0.3FD593F1@ix.netcom.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i11JB90I051816 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff: What is the problem with 3161 that is relevant to LTANS? -----Original Message----- From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] Sent: Sunday, February 01, 2004 4:00 PM To: Santosh Chokhani Cc: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft Santosh and all, Understood here. However this only in part addresses the problems or likely conflict with RFC 3161 as previously indicated.. Santosh Chokhani wrote: > The rate of refresh is not dependent on the original signature, but > the cryptographic strength of the last signature by the TSA. Thus, as > the technology advances TSA is expected to have stronger keys. > > Thus, in your example, there should be few refreshes. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Libor.Dostalek@pvt.cz > Sent: Sunday, February 01, 2004 1:35 AM > To: ietf-ltans@imc.org > Subject: RE: My objections to the submitted draft > > [Santosh Chokhani] There may be some patent related concerns regarding > the linked time stamp (Surety in US). > > Why uses the submitted draft only time stmps based on RFC-3161? > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > No reasonable company or organization will not archive its documents > for > > undefined time period. Every organization has its archiving and > > canceling order which exactly defines the archiving time for every > > particular document type. (In most countries, it has been already > > legislated in 19th century.) > > > But many of documents are archived permanently. This is the most > > complicated problem and the main aim of LTANS should be to solve > > problems of permanent archiving of digitally signed or timestamped > > documents. > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > I am afraid it is not fully true. See the following example: Let us > have a signed documnet archived for 200 yers. All signatures of this > document are based on RSA algortithm with 1K keys. It means that every > two years all the signatures are renewed. The problem is that I have > chain of 100 timestamps (based on RFC-3161). > > Libor Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 11:19:46 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11JJkHS052949; Sun, 1 Feb 2004 11:19:46 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11JJkpD052948; Sun, 1 Feb 2004 11:19:46 -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.11/8.12.8) with ESMTP id i11JJjIj052942 for ; Sun, 1 Feb 2004 11:19:45 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (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 i11JJkjU021818 for ; Sun, 1 Feb 2004 14:19:46 -0500 From: "Santosh Chokhani" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sun, 1 Feb 2004 14:19:41 -0500 Message-ID: <008f01c3e8f8$5a5f3bf0$a9414d0c@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: <401D6AA4.C8D1A5AB@ix.netcom.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i11JJjIj052943 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff: To my knowledge, LTANS is focusing on defining technical security mechanisms for archiving for long term. It is not addressing all the legal and technical issues involved in operating an archive service. -----Original Message----- From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] Sent: Sunday, February 01, 2004 4:08 PM To: Santosh Chokhani Cc: ietf-ltans@imc.org; Mark milone Subject: Re: Role of attribute certificates in long-term archiving Santosh and all, I fully agree with your list of concerning issues, Santosh. However there is also the issue of legal jurisdiction in multiple international jurisdictions. Has anyone else given this consideration given recent laws passed in some EU and Asian countries? Santosh Chokhani wrote: > Marta: > > If you are talking about who has the authorizations to access the > digital archive, we can discuss some of the options for authentication > and authorization for retrieval. I interpreted your e-mail as saying > that the archived document should be in the form of an attribute > certificate. > > Now in terms of authentication and authorization, given the potential > long life time of the archive, we have to be concerned with the > following issues: > > -- Cryptographic strength of end entity certificate > -- Cryptographic strength of authority (CA and attribute > authority) certificate > -- Stability of names asserted the certificates > -- Stability of the attributes names asserted in the attribute > certificate > > If the group decides that authentication and authorization standard > should be included for retrieval (as opposed to retrieval being a > matter of local archive policy), then we need to keep the above in > mind to determine how the long-term identity validation and > authorization should be done. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Marta.Vohnoutova@pvt.cz > Sent: Sunday, February 01, 2004 1:54 AM > To: ietf-ltans@imc.org > Subject: RE: Role of attribute certificates in long-term archiving > > > Marta: > > > > There does not seem to be any benefit gained by using the attribute > certificate format > > for archived data. > > I think the digital archive must have at least the same features as > classical stone archive. My personal expirience is if you want to > explore some old documents in archive you must first prove your > identity, explain your purpose why you need these documents, and based > on this the appropriate permitions for the specific part of archive is > given to you. > > Analogically in digital world, you can prove your identity with > certificate and attributte certificate represents appropriate > permitions given to you. > > Identity of person who put document into archive 50 years ago could be > irrelevant. > > Marta > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 16:10:51 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i120Ap2q068297; Sun, 1 Feb 2004 16:10:51 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i120ApV3068296; Sun, 1 Feb 2004 16:10:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i120An9R068283 for ; Sun, 1 Feb 2004 16:10:50 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust86.tnt36.dfw9.da.uu.net ([67.234.81.86] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1AnRfu-0004sD-00; Sun, 01 Feb 2004 19:10:50 -0500 Message-ID: <401DB050.8C6E1848@ix.netcom.com> Date: Sun, 01 Feb 2004 18:05:05 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <008e01c3e8f7$265e8280$a9414d0c@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh and all, I guess you have not read all of the comments and remarks on this thread. See earlier responses. Santosh Chokhani wrote: > Jeff: > > What is the problem with 3161 that is relevant to LTANS? > > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Sunday, February 01, 2004 4:00 PM > To: Santosh Chokhani > Cc: ietf-ltans@imc.org > Subject: Re: My objections to the submitted draft > > Santosh and all, > > Understood here. However this only in part addresses the problems or > likely conflict with RFC 3161 as previously indicated.. > > Santosh Chokhani wrote: > > > The rate of refresh is not dependent on the original signature, but > > the cryptographic strength of the last signature by the TSA. Thus, as > > the technology advances TSA is expected to have stronger keys. > > > > Thus, in your example, there should be few refreshes. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Libor.Dostalek@pvt.cz > > Sent: Sunday, February 01, 2004 1:35 AM > > To: ietf-ltans@imc.org > > Subject: RE: My objections to the submitted draft > > > > [Santosh Chokhani] There may be some patent related concerns regarding > > the linked time stamp (Surety in US). > > > > Why uses the submitted draft only time stmps based on RFC-3161? > > > > . > > > > 3.2 Long-term Archive Service > > > > > > > > A Long-term Archive Service is to be designed to solve essential > > > > parts of these problems by providing a specialized service: > > > > > > > > - The Long-term Archive Service is to store archived data objects > > > > over a long, optionally undefined, period of time. . > > > No reasonable company or organization will not archive its documents > > for > > > undefined time period. Every organization has its archiving and > > > canceling order which exactly defines the archiving time for every > > > particular document type. (In most countries, it has been already > > > legislated in 19th century.) > > > > > But many of documents are archived permanently. This is the most > > > complicated problem and the main aim of LTANS should be to solve > > > problems of permanent archiving of digitally signed or timestamped > > > documents. > > > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > > > I am afraid it is not fully true. See the following example: Let us > > have a signed documnet archived for 200 yers. All signatures of this > > document are based on RSA algortithm with 1K keys. It means that every > > two years all the signatures are renewed. The problem is that I have > > chain of 100 timestamps (based on RFC-3161). > > > > Libor > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be > precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact > Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Sun Feb 1 16:13:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i120D9sa068391; Sun, 1 Feb 2004 16:13:09 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i120D9Uj068390; Sun, 1 Feb 2004 16:13:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i120D8pN068384 for ; Sun, 1 Feb 2004 16:13:08 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust86.tnt36.dfw9.da.uu.net ([67.234.81.86] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1AnRi8-0000qs-00; Sun, 01 Feb 2004 19:13:09 -0500 Message-ID: <401DB0DA.A117BF08@ix.netcom.com> Date: Sun, 01 Feb 2004 18:07:24 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: Role of attribute certificates in long-term archiving References: <008f01c3e8f8$5a5f3bf0$a9414d0c@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh and all, Understood. However in not doing so, proper or reasonable technical security mechanisms cannot adequately be considered advisable... Santosh Chokhani wrote: > Jeff: > > To my knowledge, LTANS is focusing on defining technical security mechanisms > for archiving for long term. It is not addressing all the legal and > technical issues involved in operating an archive service. > > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Sunday, February 01, 2004 4:08 PM > To: Santosh Chokhani > Cc: ietf-ltans@imc.org; Mark milone > Subject: Re: Role of attribute certificates in long-term archiving > > Santosh and all, > > I fully agree with your list of concerning issues, Santosh. However there > is also the issue of legal jurisdiction in multiple international > jurisdictions. Has anyone else given this consideration given recent laws > passed in some EU and Asian countries? > > Santosh Chokhani wrote: > > > Marta: > > > > If you are talking about who has the authorizations to access the > > digital archive, we can discuss some of the options for authentication > > and authorization for retrieval. I interpreted your e-mail as saying > > that the archived document should be in the form of an attribute > > certificate. > > > > Now in terms of authentication and authorization, given the potential > > long life time of the archive, we have to be concerned with the > > following issues: > > > > -- Cryptographic strength of end entity certificate > > -- Cryptographic strength of authority (CA and attribute > > authority) certificate > > -- Stability of names asserted the certificates > > -- Stability of the attributes names asserted in the attribute > > certificate > > > > If the group decides that authentication and authorization standard > > should be included for retrieval (as opposed to retrieval being a > > matter of local archive policy), then we need to keep the above in > > mind to determine how the long-term identity validation and > > authorization should be done. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Marta.Vohnoutova@pvt.cz > > Sent: Sunday, February 01, 2004 1:54 AM > > To: ietf-ltans@imc.org > > Subject: RE: Role of attribute certificates in long-term archiving > > > > > Marta: > > > > > > There does not seem to be any benefit gained by using the attribute > > certificate format > > > for archived data. > > > > I think the digital archive must have at least the same features as > > classical stone archive. My personal expirience is if you want to > > explore some old documents in archive you must first prove your > > identity, explain your purpose why you need these documents, and based > > on this the appropriate permitions for the specific part of archive is > > given to you. > > > > Analogically in digital world, you can prove your identity with > > certificate and attributte certificate represents appropriate > > permitions given to you. > > > > Identity of person who put document into archive 50 years ago could be > > irrelevant. > > > > Marta > > > > > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be > precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact > Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Mon Feb 2 01:09:23 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1299NVQ060614; Mon, 2 Feb 2004 01:09:23 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1299NPV060613; Mon, 2 Feb 2004 01:09:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1299LIS060587 for ; Mon, 2 Feb 2004 01:09:22 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id KAA23419; Mon, 2 Feb 2004 10:08:50 +0100 (MET) Message-ID: <401E1410.1000407@sit.fraunhofer.de> Date: Mon, 02 Feb 2004 10:10:40 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Williams CC: Santosh Chokhani , ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <008e01c3e8f7$265e8280$a9414d0c@hq.orionsec.com> <401DB050.8C6E1848@ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff, I believe the only point that Santosh did not address was Libor's last point: First paragraph quote from reqs doc. > This is done, in part, so the archive service can operate without > knowledge of numerous signed data formats, document formats, etc. > also does not provide any means to integrate verification data in > data objects and verify embedded signatures. This has to be done on > the basis of other specifications, like RFC 3029 and with regard to > specifications of document formats. Of course it is recommended to > use such specifications together with a Long-term Archive Service. > >In this article of the draft, we can see that it is necessary to >separate the draft work into several parallel standards. I.g. it is >necessary either to make the RFC3029 into a form of an official >standard or to define formats of archiving data. > >We cannot run the TAA without format specifications. The archive can >accept only data it can guarantee to be able to view them in >undistorted form during the whole archiving time. It is not possible >for the TAA not to take care for the archived data formats. > >Let us have the following example: we have a record of important >government meeting stored in the MS Word 3.0. Such document should be >archived permanently, but what to do with the document in MS Word 3.0 >format (even now you probably will have a trouble to view it without >distortion!) Obviously, the TAA could not accept such document! I believe that the goal of LTANS is to archive evidence, possibly along with the document, that proves that the document existed at a certain time in the past. This goal was also illustrated by Aleksej in his last post. Although document format and its transition is important, I do not believe that is the goal of LTANS. Brian Jeff Williams wrote: > Santosh and all, > > I guess you have not read all of the comments and remarks on this thread. > See earlier responses. > > Santosh Chokhani wrote: > > >>Jeff: >> >>What is the problem with 3161 that is relevant to LTANS? >> >>-----Original Message----- >>From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] >>Sent: Sunday, February 01, 2004 4:00 PM >>To: Santosh Chokhani >>Cc: ietf-ltans@imc.org >>Subject: Re: My objections to the submitted draft >> >>Santosh and all, >> >> Understood here. However this only in part addresses the problems or >>likely conflict with RFC 3161 as previously indicated.. >> >>Santosh Chokhani wrote: >> >> >>>The rate of refresh is not dependent on the original signature, but >>>the cryptographic strength of the last signature by the TSA. Thus, as >>>the technology advances TSA is expected to have stronger keys. >>> >>>Thus, in your example, there should be few refreshes. >>> >>>-----Original Message----- >>>From: owner-ietf-ltans@mail.imc.org >>>[mailto:owner-ietf-ltans@mail.imc.org] >>>On Behalf Of Libor.Dostalek@pvt.cz >>>Sent: Sunday, February 01, 2004 1:35 AM >>>To: ietf-ltans@imc.org >>>Subject: RE: My objections to the submitted draft >>> >>>[Santosh Chokhani] There may be some patent related concerns regarding >>>the linked time stamp (Surety in US). >>> >>>Why uses the submitted draft only time stmps based on RFC-3161? >>> >>>. >>> >>>>>3.2 Long-term Archive Service >>>>> >>>>> A Long-term Archive Service is to be designed to solve essential >>>>> parts of these problems by providing a specialized service: >>>>> >>>>> - The Long-term Archive Service is to store archived data objects >>>>> over a long, optionally undefined, period of time. . >>>> >>>>No reasonable company or organization will not archive its documents >>> >>>for >>> >>>>undefined time period. Every organization has its archiving and >>>>canceling order which exactly defines the archiving time for every >>>>particular document type. (In most countries, it has been already >>>>legislated in 19th century.) >>> >>>>But many of documents are archived permanently. This is the most >>>>complicated problem and the main aim of LTANS should be to solve >>>>problems of permanent archiving of digitally signed or timestamped >>>>documents. >>> >>>[Santosh Chokhani] I think LTANS is trying to solve that problem >>> >>>I am afraid it is not fully true. See the following example: Let us >>>have a signed documnet archived for 200 yers. All signatures of this >>>document are based on RSA algortithm with 1K keys. It means that every >>>two years all the signatures are renewed. The problem is that I have >>>chain of 100 timestamps (based on RFC-3161). >>> >>>Libor >> >>Regards, >> >>-- >>Jeffrey A. Williams From owner-ietf-ltans Mon Feb 2 03:29:56 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12BTudN092243; Mon, 2 Feb 2004 03:29:56 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12BTuYg092242; Mon, 2 Feb 2004 03:29:56 -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.11/8.12.8) with ESMTP id i12BTtpE092234 for ; Mon, 2 Feb 2004 03:29:55 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i12BTujU013828 for ; Mon, 2 Feb 2004 06:29:56 -0500 From: "Santosh Chokhani" To: ietf-ltans@imc.org Subject: Re: Role of attribute certificates in long-term archiving Date: Mon, 2 Feb 2004 07:29:56 -0400 Message-Id: <20040202112956.M46849@orionsec.com> In-Reply-To: <401DB0DA.A117BF08@ix.netcom.com> References: <008f01c3e8f8$5a5f3bf0$a9414d0c@hq.orionsec.com> <401DB0DA.A117BF08@ix.netcom.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 68.49.170.70 (chokhani) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff: If some one defines additional legal or local policy requirements, they can add applicable enforcement mechanisms. As to 3161, I still do not recall any specific problem with it with respect to trusted archive. Remember that trusted archive will refresh the time stamp before its expiry. On Sun, 01 Feb 2004 18:07:24 -0800, Jeff Williams wrote > Santosh and all, > > Understood. However in not doing so, proper or reasonable > technical security mechanisms cannot adequately be considered > advisable... > > Santosh Chokhani wrote: > > > Jeff: > > > > To my knowledge, LTANS is focusing on defining technical security mechanisms > > for archiving for long term. It is not addressing all the legal and > > technical issues involved in operating an archive service. > > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Sunday, February 01, 2004 4:08 PM > > To: Santosh Chokhani > > Cc: ietf-ltans@imc.org; Mark milone > > Subject: Re: Role of attribute certificates in long-term archiving > > > > Santosh and all, > > > > I fully agree with your list of concerning issues, Santosh. However there > > is also the issue of legal jurisdiction in multiple international > > jurisdictions. Has anyone else given this consideration given recent laws > > passed in some EU and Asian countries? > > > > Santosh Chokhani wrote: > > > > > Marta: > > > > > > If you are talking about who has the authorizations to access the > > > digital archive, we can discuss some of the options for authentication > > > and authorization for retrieval. I interpreted your e-mail as saying > > > that the archived document should be in the form of an attribute > > > certificate. > > > > > > Now in terms of authentication and authorization, given the potential > > > long life time of the archive, we have to be concerned with the > > > following issues: > > > > > > -- Cryptographic strength of end entity certificate > > > -- Cryptographic strength of authority (CA and attribute > > > authority) certificate > > > -- Stability of names asserted the certificates > > > -- Stability of the attributes names asserted in the attribute > > > certificate > > > > > > If the group decides that authentication and authorization standard > > > should be included for retrieval (as opposed to retrieval being a > > > matter of local archive policy), then we need to keep the above in > > > mind to determine how the long-term identity validation and > > > authorization should be done. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of Marta.Vohnoutova@pvt.cz > > > Sent: Sunday, February 01, 2004 1:54 AM > > > To: ietf-ltans@imc.org > > > Subject: RE: Role of attribute certificates in long-term archiving > > > > > > > Marta: > > > > > > > > There does not seem to be any benefit gained by using the attribute > > > certificate format > > > > for archived data. > > > > > > I think the digital archive must have at least the same features as > > > classical stone archive. My personal expirience is if you want to > > > explore some old documents in archive you must first prove your > > > identity, explain your purpose why you need these documents, and based > > > on this the appropriate permitions for the specific part of archive is > > > given to you. > > > > > > Analogically in digital world, you can prove your identity with > > > certificate and attributte certificate represents appropriate > > > permitions given to you. > > > > > > Identity of person who put document into archive 50 years ago could be > > > irrelevant. > > > > > > Marta > > > > > > > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be > > precise in the use of words and expect precision from others" - > > Pierre Abelard > > > > "If the probability be called P; the injury, L; and the burden, B; liability > > depends upon whether B is less than L multiplied by > > P: i.e., whether B is less than PL." > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > =============================================================== > > Updated 1/26/04 > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > > Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact > > Number: 214-244-4827 > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders > strong!) "Be precise in the use of words and expect precision from > others" - Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 214-244-4827 From owner-ietf-ltans Mon Feb 2 03:55:07 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Bt7pf094643; Mon, 2 Feb 2004 03:55:07 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12Bt7ZP094641; Mon, 2 Feb 2004 03:55:07 -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.11/8.12.8) with SMTP id i12Bt4LQ094619 for ; Mon, 2 Feb 2004 03:55:06 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 23081 invoked from network); 2 Feb 2004 11:49:09 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 2 Feb 2004 11:49:09 -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 21514-07 for ; Mon, 2 Feb 2004 12:48:51 +0100 (CET) Received: (qmail 23061 invoked from network); 2 Feb 2004 11:48:51 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 2 Feb 2004 11:48:51 -0000 From: "A. Jerman Blazic" To: , Subject: RE: My objections to the submitted draft Date: Mon, 2 Feb 2004 12:56:34 +0100 Message-ID: <005a01c3e983$9af1eec0$1b018ac1@arthur> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> 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: > I have several things in the submitted draft which are unclear to me. To have a > Berger orientation I put here also the unclear parts of the draft marked with the > leading >. > >> 2. Terminology >> . >> Timestamp: A signed confirmation generated by a Time Stamping >> Authority (TSA) that a data item existed at a certain time. >> [RFC3161] specifies a good structure for timestamps and a protocol >> for communicating with a Timestamp Authority (TSA). > >It is a bit foolish to build everything on the "classical" time stamp. Realize >that the time stamp is also only a digitally signed structure. I do not understand >why this draft does not mention the time stamp acc. to RFC3161 only as eventuality >and why it is not more open to time stamps based on the linking hash principle. If >we bind time stamp based on linking hash to the archived document, we could give to >the court not one but two independent evidences of the document validity. > >I.e. digital signatures of archived documents would be added with nonsigned >attribute - the enhanced time stamp based on other cryptographical principle - the >linking hash. > >The base difference between time stamps based on linking hashes and those acc. to >the RFC3161 is the fact that the time stamps based on the RFC3161 expire with the >expiration of their Time Stamping Authority certificate which issued them (see that >we face exactly the same problem we faced in case of digital signature, what this >draft should solve), while time stamps based on linking hashes expire when the used >hash algorithm proves to be too week, which represents incomparably longer time. > You can achieve the same evidence presented to the court when using redundant timestamps, which is what any archive is suppose to do in any case (also bare in mind that if you want to keep "machine readable data" archived a backup and disaster recovery functions must be supported using redundancy mechanisms, which is again not the intention to be solved by LTANS). Also, as Santosh stated, trusted archive must ensure the use of long(er) keys and most importantly do the re-timestamping, so no problem with expired timestamps should foreseen. Regards aleksej From owner-ietf-ltans Mon Feb 2 04:10:34 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12CAYIq095646; Mon, 2 Feb 2004 04:10:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12CAYq6095645; Mon, 2 Feb 2004 04:10: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.11/8.12.8) with ESMTP id i12CAWoe095624 for ; Mon, 2 Feb 2004 04:10:33 -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 NAA12942; Mon, 2 Feb 2004 13:10:27 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 2 Feb 2004 13:10:27 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i12CAQG21329; Mon, 2 Feb 2004 13:10:26 +0100 (MET) Date: Mon, 2 Feb 2004 13:10:26 +0100 (MET) From: Peter Sylvester Message-Id: <200402021210.i12CAQG21329@chandon.edelweb.fr> To: jwkckid1@ix.netcom.com, brian.hunter@sit.fraunhofer.de Subject: Re: My objections to the submitted draft Cc: chokhani@orionsec.com, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I believe that the goal of LTANS is to archive evidence, possibly along > with the document, that proves that the document existed at a certain > time in the past. This goal was also illustrated by Aleksej in his last > post. Although document format and its transition is important, I do > not believe that is the goal of LTANS. > The equivalent of scanned copies of paper is the electronic version just before printing, archiving this, i.e. even a pdf form may be useful for an intermediate time and sufficient for some applications, but it does not make sense in the long term since the form or layout of a document is a security feature and not important for the information, e.g. a propietary act signed and sealed on particular support/paper. I see the following as some extreme points of some space may be multidimensional. - creating an assertion that something has been archived and will be safe for a defined time without looking at the actual content. Such data cannot be transformed since they are only a representation of a possible unknown structure (including the possibility the the representation is the result of data encipherment). - creating an assertion that something conformant to a certain structure and/or law etc has been validated and archived. such structures which are representations of some information can be transformed to another representation. As soon as the assertion is created the process is divided into two parts (at least): - - for how much time does the assertion remain reliably verifyable without the need of some third party ONLINE. (lifetime of a digital signature) - can one enhance the lifetime, for example by elimination of keys by public hash chains - the need to some service for the previous and/or for validation after a very long time - The operation of a service providing the attestations for the three cases above - - how does a service organise itself to be auditable, secure etc, etc. i.e. what internal and external mechanisms are used to ensure the medium and long term stability. The concrete operation is not our scope, but providing some external visibility through attestations from others is. - document formats is out of our scope to the same extend as it is for XML-DSIG. For notary operations and for the possibility of tranformation some general structuring approach seems at least useful though, i.e. treating the layer of abstract information vs representation. Peter From owner-ietf-ltans Mon Feb 2 04:56:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12CudrW000693; Mon, 2 Feb 2004 04:56:39 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12Cud63000692; Mon, 2 Feb 2004 04:56:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Cuc3D000674 for ; Mon, 2 Feb 2004 04:56:38 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id NAA11128; Mon, 2 Feb 2004 13:56:23 +0100 (MET) Message-ID: <401E4964.6000807@sit.fraunhofer.de> Date: Mon, 02 Feb 2004 13:58:12 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Sylvester CC: jwkckid1@ix.netcom.com, chokhani@orionsec.com, ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <200402021210.i12CAQG21329@chandon.edelweb.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, Peter Sylvester wrote: ... > I see the following as some extreme points of some space > may be multidimensional. > > - creating an assertion that something has been archived > and will be safe for a defined time without looking > at the actual content. Such data cannot be transformed > since they are only a representation of a possible > unknown structure (including the possibility the the > representation is the result of data encipherment). I believe this assertion would be represented through the archive policy, which the service provider or a local regulatory body defines. > - creating an assertion that something conformant to a certain > structure and/or law etc has been validated and archived. > such structures which are representations of some information > can be transformed to another representation. Again I think this is a policy defined issue. The transformations may be defined locally, or a standard could be defined for a general file format, e.g. base case could be a plain text file. > As soon as the assertion is created the process is divided into > two parts (at least): > > - - for how much time does the assertion remain reliably > verifyable without the need of some third party ONLINE. > (lifetime of a digital signature) > - can one enhance the lifetime, for example by elimination > of keys by public hash chains > - the need to some service for the previous and/or > for validation after a very long time > > - The operation of a service providing the attestations > for the three cases above Agree, and these points would be defined in the archive policy. > - - how does a service organise itself to be auditable, secure > etc, etc. i.e. what internal and external mechanisms are > used to ensure the medium and long term stability. The > concrete operation is not our scope, but providing > some external visibility through attestations from others > is. I think this would be a matter of local law, and not something that could be standardised. Every country will likely define its own definition of stability and require its own service provider accreditation. I believe this is similar to how each EU country defines its own version of accredited CAs, a regulatory body defines it, and not a standards body. > - document formats is out of our scope to the same extend as > it is for XML-DSIG. For notary operations and for the > possibility of tranformation some general structuring > approach seems at least useful though, i.e. treating > the layer of abstract information vs representation. I'm not sure I understand your point. As per LTANS, opaque data is to be archived. This opaque data could be an CMS object that contains a specific type of data, which has standardised forms, or transformations. But again, this structure and its transformations are irrelevant for the archive provider. Brian > > Peter > > > > > > > From owner-ietf-ltans Mon Feb 2 05:10:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12DAKVd002073; Mon, 2 Feb 2004 05:10:20 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12DAKxi002072; Mon, 2 Feb 2004 05:10:20 -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.11/8.12.8) with ESMTP id i12DAI7P002063 for ; Mon, 2 Feb 2004 05:10:18 -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 i12DADjU028087; Mon, 2 Feb 2004 08:10:18 -0500 From: "Carl Wallace" To: , Subject: RE: My objections to the submitted draft Date: Mon, 2 Feb 2004 08:10:07 -0500 Message-ID: <008001c3e98d$e8122670$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C3E963.FF3C1E70" 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: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> 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_0081_01C3E963.FF3C1E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable comments inline... -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Libor.Dostalek@pvt.cz Sent: Saturday, January 31, 2004 2:35 PM To: ietf-ltans@imc.org Subject: My objections to the submitted draft It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I = do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps = based on the linking hash principle. If we bind time stamp based on linking = hash to the archived document, we could give to the court not one but two independent evidences of the document validity. =20 I.e. digital signatures of archived documents would be added with = nonsigned attribute - the enhanced time stamp based on other cryptographical = principle - the linking hash. =20 =20 The base difference between time stamps based on linking hashes and = those acc. to the RFC3161 is the fact that the time stamps based on the = RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time = stamps based on linking hashes expire when the used hash algorithm proves to be = too week, which represents incomparably longer time. =20 [CW] The structures should be defined to accommodate different types of timestamps. Folks who had needs that could be met with RFC3161 or ATS = have those options available. Folks who want to use a linking hash approach without digital signatures could use such structures. =20 . =20 =20 How could the TAA give the evidence about the existence and integrity of = a document without the data necessary for the verification of such = evidence!? I think that we can discuss many things which the TAA standard should = order or recommend, but it is no doubt that the TAA is obliged to give to a = user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some = type of data store. [CW] This is another case where the specs must be flexible. In all = cases, the TAA must provide evidence that data has not changed while it was in = the care of the TAA. In some cases, upon acceptance, it may be necessary = for a TAA to collect or generate evidence about the integrity of the archived = data (possibly including a review of the content of the data). In other = cases, privacy concerns may dictate that the TAA may either never handle the = data directly or only handle the data in encrypted form. In some cases, the = data may not be signed at all and the act of archiving is the first step in generating integrity proof. =20 > This 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 = > specifications of document formats. Of course it is recommended to = > use such specifications together with a Long-term Archive Service.=20 =20 In this article of the draft, we can see that it is necessary to = separate the draft work into several parallel standards. I.g. it is necessary = either to make the RFC3029 into a form of an official standard or to define = formats of archiving data. =20 We cannot run the TAA without format specifications. The archive can = accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to = take care for the archived data formats. =20 Let us have the following example: we have a record of important = government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format = (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! =20 [CW] Maybe the TAA provides a 486 running MS Word 3.0 right next to the microfiche machine:-)=20 =20 The suggested draft does not take care about migration and emulation of archived documents. =20 ------ =20 The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. = It does not take care for document cataloging, searching of documents, = viewing of documents in undistorted form and document canceling. [CW] The focus is on extending the means to demonstrate integrity. A = TAA may provide very rich cataloging and searching capabilities but these capabilities are not related to the integrity preservation mechanisms. =20 Format migration is a related problem but not one we should try to solve initially. =20 =20 =20 ------=_NextPart_000_0081_01C3E963.FF3C1E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
comments inline...
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Libor.Dostalek@pvt.cz
Sent: Saturday, January = 31, 2004=20 2:35 PM
To: ietf-ltans@imc.org
Subject: My = objections to=20 the submitted draft

It=20 is a bit foolish to build everything on the “classical“ = time stamp.  Realize that the time stamp = is also=20 only a digitally signed structure… I do not understand why this = draft does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it = is not=20 more open to time stamps based on the linking hash principle. If we = bind time=20 stamp based on linking hash to the archived document, we could give to = the=20 court not one but two independent evidences of the document=20 validity.

 

I.e. digital signatures of archived documents = would be=20 added with nonsigned  = attribute –=20 the enhanced time stamp based on other cryptographical principle = – the linking=20 hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 = expire with=20 the expiration of their Time Stamping Authority certificate which = issued them=20 (see that we face exactly the same problem we faced in case of digital = signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, = which=20 represents incomparably longer time.  

[CW] The=20 structures should be defined to accommodate different types of=20 timestamps.  Folks who had needs that could be met with RFC3161 = or ATS=20 have those options available.  Folks who want to use a linking = hash=20 approach without digital signatures could use such=20 structures.    =

…    

 

How=20 could the TAA give the evidence about the existence and integrity of a = document without the data necessary for the verification of such = evidence!? I=20 think that we can discuss many things which the TAA standard should = order or=20 recommend, but it is no doubt that the TAA is obliged to give to a = user all=20 the required data necessary for existence and integrity proof of the=20 appropriate document. Without this function the TAA would be only some = type of=20 data store.

[CW]  This = is another=20 case where the specs must be flexible.  In all cases, the TAA = must=20 provide evidence that data has not changed while it was in the care of = the=20 TAA.  In some cases, upon = acceptance,=20 it may be necessary for a TAA to collect or generate evidence about = the=20 integrity of the archived data (possibly including a review of the = content of=20 the data).  In other cases, privacy concerns may dictate = that the=20 TAA may either never handle the data directly or only handle the data = in=20 encrypted form.  In some cases, the data may not be signed at all = and the=20 act of archiving is the first step in generating integrity=20 proof.

 

>   =20 This is done, in part, so the archive service can operate = without=20

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It=20

>   =20 also does not provide any means to integrate verification data = in=20

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with = regard to=20

>   =20 specifications of document formats.  Of course it is recommended = to=20

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the=20 draft work into several parallel standards. I.g. it is necessary = either to=20 make the RFC3029 into a form of an official standard or to define = formats of=20 archiving data.

 

We=20 cannot run the TAA without format specifications. The archive can = accept only=20 data it can guarantee to be able to view them in undistorted form = during the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats.  =

Let=20 us have the following example: we have a record of important = government=20 meeting stored in the MS Word 3.0. Such document should be archived=20 permanently, but what to do with the document in MS Word 3.0 format = (even now=20 you probably will have a trouble to view it without distortion!) = Obviously,=20 the TAA could not accept such document!  

[CW] Maybe=20 the TAA provides a 486 running MS Word 3.0 right next to the = microfiche=20 machine:-) 

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According=20 to this draft, the archive only accepts and returns documents. It does = not=20 take care for document cataloging, searching of documents, viewing of=20 documents in undistorted form and document = canceling.

[CW] The focus is on=20 extending the means to demonstrate integrity.  A TAA may provide = very=20 rich cataloging and searching capabilities but these capabilities are = not=20 related to the integrity preservation=20 = mechanisms.       

 

Format migration is a = related=20 problem but not one we should try to solve initially. =20

 

 

<= /FONT>
------=_NextPart_000_0081_01C3E963.FF3C1E70-- From owner-ietf-ltans Mon Feb 2 05:27:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12DR8Lu003657; Mon, 2 Feb 2004 05:27:08 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12DR8Ae003656; Mon, 2 Feb 2004 05:27:08 -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.11/8.12.8) with ESMTP id i12DR7J5003650 for ; Mon, 2 Feb 2004 05:27:08 -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 i12DR7jU030697 for ; Mon, 2 Feb 2004 08:27:07 -0500 From: "Carl Wallace" To: Subject: 59th IETF Date: Mon, 2 Feb 2004 08:27:02 -0500 Message-ID: <008d01c3e990$41c35a70$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 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The LTANS WG meeting at the 59th IETF is currently scheduled for Thursday, March 4th from 13:00-15:00. Send me an email if you are interested in giving a presentation during the session. Carl From owner-ietf-ltans Mon Feb 2 11:45:06 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Jj5Qh036655; Mon, 2 Feb 2004 11:45:05 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12Jj550036654; Mon, 2 Feb 2004 11:45:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Jj4gi036647 for ; Mon, 2 Feb 2004 11:45:04 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust132.tnt36.dfw9.da.uu.net ([67.234.81.132] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Ank0E-00042m-00; Mon, 02 Feb 2004 14:45:03 -0500 Message-ID: <401EC380.12E4CBA8@ix.netcom.com> Date: Mon, 02 Feb 2004 13:39:15 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian Hunter CC: Santosh Chokhani , ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <008e01c3e8f7$265e8280$a9414d0c@hq.orionsec.com> <401DB050.8C6E1848@ix.netcom.com> <401E1410.1000407@sit.fraunhofer.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian and all Brian Hunter wrote: > Jeff, > > I believe the only point that Santosh did not address was Libor's last > point: > > First paragraph quote from reqs doc. > > This is done, in part, so the archive service can operate without > > knowledge of numerous signed data formats, document formats, etc. > > also does not provide any means to integrate verification data in > > data objects and verify embedded signatures. This has to be done on > > the basis of other specifications, like RFC 3029 and with regard to > > specifications of document formats. Of course it is recommended to > > use such specifications together with a Long-term Archive Service. > > > >In this article of the draft, we can see that it is necessary to > >separate the draft work into several parallel standards. I.g. it is > >necessary either to make the RFC3029 into a form of an official > >standard or to define formats of archiving data. > > > >We cannot run the TAA without format specifications. The archive can > >accept only data it can guarantee to be able to view them in > >undistorted form during the whole archiving time. It is not possible > >for the TAA not to take care for the archived data formats. > > > >Let us have the following example: we have a record of important > >government meeting stored in the MS Word 3.0. Such document should be > >archived permanently, but what to do with the document in MS Word 3.0 > >format (even now you probably will have a trouble to view it without > >distortion!) Obviously, the TAA could not accept such document! Yes I agree. > > > I believe that the goal of LTANS is to archive evidence, possibly along > with the document, that proves that the document existed at a certain > time in the past. This goal was also illustrated by Aleksej in his last > post. Although document format and its transition is important, I do > not believe that is the goal of LTANS. Understood. Perhaps its transition should be a goal? If not I would ask, why not? > > > Brian > > Jeff Williams wrote: > > Santosh and all, > > > > I guess you have not read all of the comments and remarks on this thread. > > See earlier responses. > > > > Santosh Chokhani wrote: > > > > > >>Jeff: > >> > >>What is the problem with 3161 that is relevant to LTANS? > >> > >>-----Original Message----- > >>From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > >>Sent: Sunday, February 01, 2004 4:00 PM > >>To: Santosh Chokhani > >>Cc: ietf-ltans@imc.org > >>Subject: Re: My objections to the submitted draft > >> > >>Santosh and all, > >> > >> Understood here. However this only in part addresses the problems or > >>likely conflict with RFC 3161 as previously indicated.. > >> > >>Santosh Chokhani wrote: > >> > >> > >>>The rate of refresh is not dependent on the original signature, but > >>>the cryptographic strength of the last signature by the TSA. Thus, as > >>>the technology advances TSA is expected to have stronger keys. > >>> > >>>Thus, in your example, there should be few refreshes. > >>> > >>>-----Original Message----- > >>>From: owner-ietf-ltans@mail.imc.org > >>>[mailto:owner-ietf-ltans@mail.imc.org] > >>>On Behalf Of Libor.Dostalek@pvt.cz > >>>Sent: Sunday, February 01, 2004 1:35 AM > >>>To: ietf-ltans@imc.org > >>>Subject: RE: My objections to the submitted draft > >>> > >>>[Santosh Chokhani] There may be some patent related concerns regarding > >>>the linked time stamp (Surety in US). > >>> > >>>Why uses the submitted draft only time stmps based on RFC-3161? > >>> > >>>. > >>> > >>>>>3.2 Long-term Archive Service > >>>>> > >>>>> A Long-term Archive Service is to be designed to solve essential > >>>>> parts of these problems by providing a specialized service: > >>>>> > >>>>> - The Long-term Archive Service is to store archived data objects > >>>>> over a long, optionally undefined, period of time. . > >>>> > >>>>No reasonable company or organization will not archive its documents > >>> > >>>for > >>> > >>>>undefined time period. Every organization has its archiving and > >>>>canceling order which exactly defines the archiving time for every > >>>>particular document type. (In most countries, it has been already > >>>>legislated in 19th century.) > >>> > >>>>But many of documents are archived permanently. This is the most > >>>>complicated problem and the main aim of LTANS should be to solve > >>>>problems of permanent archiving of digitally signed or timestamped > >>>>documents. > >>> > >>>[Santosh Chokhani] I think LTANS is trying to solve that problem > >>> > >>>I am afraid it is not fully true. See the following example: Let us > >>>have a signed documnet archived for 200 yers. All signatures of this > >>>document are based on RSA algortithm with 1K keys. It means that every > >>>two years all the signatures are renewed. The problem is that I have > >>>chain of 100 timestamps (based on RFC-3161). > >>> > >>>Libor > >> > >>Regards, > >> > >>-- > >>Jeffrey A. Williams Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Mon Feb 2 15:21:23 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NLMpa050107; Mon, 2 Feb 2004 15:21:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12NLMhO050104; Mon, 2 Feb 2004 15:21:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NLKM1050088 for ; Mon, 2 Feb 2004 15:21:21 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust5.tnt36.dfw9.da.uu.net ([67.234.81.5] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AnnNX-0006hO-00; Mon, 02 Feb 2004 18:21:19 -0500 Message-ID: <401EF62E.598D2D49@ix.netcom.com> Date: Mon, 02 Feb 2004 17:15:30 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: Role of attribute certificates in long-term archiving References: <008f01c3e8f8$5a5f3bf0$a9414d0c@hq.orionsec.com> <401DB0DA.A117BF08@ix.netcom.com> <20040202112956.M46849@orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh and all, Santosh Chokhani wrote: > Jeff: > > If some one defines additional legal or local policy requirements, they can > add applicable enforcement mechanisms. I agree if the proposed standard provides adequately enough for such legal and/or policy requirements to be enforceable. > > > As to 3161, I still do not recall any specific problem with it with respect > to trusted archive. Remember that trusted archive will refresh the time > stamp before its expiry. Understood here. However I think you may have missed part of my original point. That being essentially this suggestion as you put it, encompass the definitions for which those archives are trusted based upon the content of said archive was originally valid and accurate as to it's real originator. > > > On Sun, 01 Feb 2004 18:07:24 -0800, Jeff Williams wrote > > Santosh and all, > > > > Understood. However in not doing so, proper or reasonable > > technical security mechanisms cannot adequately be considered > > advisable... > > > > Santosh Chokhani wrote: > > > > > Jeff: > > > > > > To my knowledge, LTANS is focusing on defining technical security > mechanisms > > > for archiving for long term. It is not addressing all the legal and > > > technical issues involved in operating an archive service. > > > > > > -----Original Message----- > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > Sent: Sunday, February 01, 2004 4:08 PM > > > To: Santosh Chokhani > > > Cc: ietf-ltans@imc.org; Mark milone > > > Subject: Re: Role of attribute certificates in long-term archiving > > > > > > Santosh and all, > > > > > > I fully agree with your list of concerning issues, Santosh. However > there > > > is also the issue of legal jurisdiction in multiple international > > > jurisdictions. Has anyone else given this consideration given recent laws > > > passed in some EU and Asian countries? > > > > > > Santosh Chokhani wrote: > > > > > > > Marta: > > > > > > > > If you are talking about who has the authorizations to access the > > > > digital archive, we can discuss some of the options for authentication > > > > and authorization for retrieval. I interpreted your e-mail as saying > > > > that the archived document should be in the form of an attribute > > > > certificate. > > > > > > > > Now in terms of authentication and authorization, given the potential > > > > long life time of the archive, we have to be concerned with the > > > > following issues: > > > > > > > > -- Cryptographic strength of end entity certificate > > > > -- Cryptographic strength of authority (CA and attribute > > > > authority) certificate > > > > -- Stability of names asserted the certificates > > > > -- Stability of the attributes names asserted in the attribute > > > > certificate > > > > > > > > If the group decides that authentication and authorization standard > > > > should be included for retrieval (as opposed to retrieval being a > > > > matter of local archive policy), then we need to keep the above in > > > > mind to determine how the long-term identity validation and > > > > authorization should be done. > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > > On Behalf Of Marta.Vohnoutova@pvt.cz > > > > Sent: Sunday, February 01, 2004 1:54 AM > > > > To: ietf-ltans@imc.org > > > > Subject: RE: Role of attribute certificates in long-term archiving > > > > > > > > > Marta: > > > > > > > > > > There does not seem to be any benefit gained by using the attribute > > > > certificate format > > > > > for archived data. > > > > > > > > I think the digital archive must have at least the same features as > > > > classical stone archive. My personal expirience is if you want to > > > > explore some old documents in archive you must first prove your > > > > identity, explain your purpose why you need these documents, and based > > > > on this the appropriate permitions for the specific part of archive is > > > > given to you. > > > > > > > > Analogically in digital world, you can prove your identity with > > > > certificate and attributte certificate represents appropriate > > > > permitions given to you. > > > > > > > > Identity of person who put document into archive 50 years ago could be > > > > irrelevant. > > > > > > > > Marta > > > > > > > > > > > > > > Regards, > > > > > > -- > > > Jeffrey A. Williams > > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be > > > precise in the use of words and expect precision from others" - > > > Pierre Abelard > > > > > > "If the probability be called P; the injury, L; and the burden, B; > liability > > > depends upon whether B is less than L multiplied by > > > P: i.e., whether B is less than PL." > > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > > =============================================================== > > > Updated 1/26/04 > > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. > of > > > Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact > > > Number: 214-244-4827 > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders > > strong!) "Be precise in the use of words and expect precision from > > others" - Pierre Abelard > > > > "If the probability be called P; the injury, L; and the burden, B; > > liability depends upon whether B is less than L multiplied by > > P: i.e., whether B is less than PL." > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > =============================================================== > > Updated 1/26/04 > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > IDNS. div. of Information Network Eng. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Mon Feb 2 15:44:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NiMC0051061; Mon, 2 Feb 2004 15:44:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12NiMlD051060; Mon, 2 Feb 2004 15:44:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NiKQh051054 for ; Mon, 2 Feb 2004 15:44:21 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust5.tnt36.dfw9.da.uu.net ([67.234.81.5] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Annjj-0001DV-00; Mon, 02 Feb 2004 18:44:15 -0500 Message-ID: <401EFB88.70933A6B@ix.netcom.com> Date: Mon, 02 Feb 2004 17:38:23 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian Hunter CC: Peter Sylvester , chokhani@orionsec.com, ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <200402021210.i12CAQG21329@chandon.edelweb.fr> <401E4964.6000807@sit.fraunhofer.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian and all, Thank you Brian for in part getting to the hart of the situation here. I agree with almost all of your comments/remarks/observations below. I still think that perhaps we should still get to the what is considered a trusted archive, how that is specifically as possible, defined, and what electronically signed CA's for those documents should or must be as well as how to determine their life of validity, before needing to be resigned, if at all... Note: [ I hope I stated this right and/or clearly ] If not or clarification is needed I shall try to restate same in a different and hopefully more clear manner... Brian Hunter wrote: > Peter, > > Peter Sylvester wrote: > ... > > I see the following as some extreme points of some space > > may be multidimensional. > > > > - creating an assertion that something has been archived > > and will be safe for a defined time without looking > > at the actual content. Such data cannot be transformed > > since they are only a representation of a possible > > unknown structure (including the possibility the the > > representation is the result of data encipherment). > > I believe this assertion would be represented through the archive > policy, which the service provider or a local regulatory body defines. > > > - creating an assertion that something conformant to a certain > > structure and/or law etc has been validated and archived. > > such structures which are representations of some information > > can be transformed to another representation. > > Again I think this is a policy defined issue. The transformations may > be defined locally, or a standard could be defined for a general file > format, e.g. base case could be a plain text file. > > > As soon as the assertion is created the process is divided into > > two parts (at least): > > > > - - for how much time does the assertion remain reliably > > verifyable without the need of some third party ONLINE. > > (lifetime of a digital signature) > > - can one enhance the lifetime, for example by elimination > > of keys by public hash chains > > - the need to some service for the previous and/or > > for validation after a very long time > > > > - The operation of a service providing the attestations > > for the three cases above > > Agree, and these points would be defined in the archive policy. > > > - - how does a service organise itself to be auditable, secure > > etc, etc. i.e. what internal and external mechanisms are > > used to ensure the medium and long term stability. The > > concrete operation is not our scope, but providing > > some external visibility through attestations from others > > is. > > I think this would be a matter of local law, and not something that > could be standardised. Every country will likely define its own > definition of stability and require its own service provider > accreditation. I believe this is similar to how each EU country defines > its own version of accredited CAs, a regulatory body defines it, and not > a standards body. > > > - document formats is out of our scope to the same extend as > > it is for XML-DSIG. For notary operations and for the > > possibility of tranformation some general structuring > > approach seems at least useful though, i.e. treating > > the layer of abstract information vs representation. > > I'm not sure I understand your point. As per LTANS, opaque data is to > be archived. This opaque data could be an CMS object that contains a > specific type of data, which has standardised forms, or transformations. > But again, this structure and its transformations are irrelevant for > the archive provider. > > Brian > > > > > Peter > > > > > > > > > > > > > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Mon Feb 2 15:59:04 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Nx4oX052738; Mon, 2 Feb 2004 15:59:04 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12Nx4qU052737; Mon, 2 Feb 2004 15:59:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Nx12i052728 for ; Mon, 2 Feb 2004 15:59:03 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust5.tnt36.dfw9.da.uu.net ([67.234.81.5] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Annxy-0001PK-00; Mon, 02 Feb 2004 18:58:59 -0500 Message-ID: <401EFEFD.6BCF29AC@ix.netcom.com> Date: Mon, 02 Feb 2004 17:53:09 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Carl Wallace CC: Libor.Dostalek@pvt.cz, ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <008001c3e98d$e8122670$9a00a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl and all, Carl Wallace wrote: > comments inline... > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Libor.Dostalek@pvt.cz > Sent: Saturday, January 31, 2004 2:35 PM > To: ietf-ltans@imc.org > Subject: My objections to the submitted draft > > > > > It is a bit foolish to build everything on the "classical" time stamp. > > Realize that the time stamp is also only a digitally signed structure. > I do > not understand why this draft does not mention the time stamp acc. to > RFC3161 only as eventuality and why it is not more open to time stamps > based > on the linking hash principle. If we bind time stamp based on linking > hash > to the archived document, we could give to the court not one but two > independent evidences of the document validity. I like your idea here Carl. > > > > > I.e. digital signatures of archived documents would be added with > nonsigned > attribute - the enhanced time stamp based on other cryptographical > principle > - the linking hash. > > > > The base difference between time stamps based on linking hashes and > those > acc. to the RFC3161 is the fact that the time stamps based on the > RFC3161 > expire with the expiration of their Time Stamping Authority > certificate > which issued them (see that we face exactly the same problem we faced > in > case of digital signature, what this draft should solve), while time > stamps > based on linking hashes expire when the used hash algorithm proves to > be too > week, which represents incomparably longer time. I agree here. And this in different terms was one of my objections as well. You stated better than I, however. > > > > [CW] The structures should be defined to accommodate different types > of > timestamps. Folks who had needs that could be met with RFC3161 or ATS > have > those options available. Folks who want to use a linking hash > approach > without digital signatures could use such structures. > > . > > > > > How could the TAA give the evidence about the existence and integrity > of a > document without the data necessary for the verification of such > evidence!? > I think that we can discuss many things which the TAA standard should > order > or recommend, but it is no doubt that the TAA is obliged to give to a > user > all the required data necessary for existence and integrity proof of > the > appropriate document. Without this function the TAA would be only some > type > of data store. Yes. > > > > [CW] This is another case where the specs must be flexible. In all > cases, > the TAA must provide evidence that data has not changed while it was > in the > care of the TAA. In some cases, upon acceptance, it may be necessary > for a > TAA to collect or generate evidence about the integrity of the > archived data > (possibly including a review of the content of the data). In other > cases, > privacy concerns may dictate that the TAA may either never handle the > data > directly or only handle the data in encrypted form. In some cases, > the data > may not be signed at all and the act of archiving is the first step in > > generating integrity proof. Good idea here as well... > > > > > > This is done, in part, so the archive service can operate without > > > knowledge of numerous signed data formats, document formats, > etc. It > > > also does not provide any means to integrate verification data in > > > data objects and verify embedded signatures. This has to be done > on > > > the basis of other specifications, like RFC 3029 and with regard > to > > > specifications of document formats. Of course it is recommended > to > > > use such specifications together with a Long-term Archive > Service. > > > > In this article of the draft, we can see that it is necessary to > separate > the draft work into several parallel standards. I.g. it is necessary > either > to make the RFC3029 into a form of an official standard or to define > formats > of archiving data. I believe that defining the expectable formats would be the better route to take. > > > > ------ > > > > The lifetime of the archived document is also not solved in this > draft. > According to this draft, the archive only accepts and returns > documents. It > does not take care for document cataloging, searching of documents, > viewing > of documents in undistorted form and document canceling. > > > [CW] The focus is on extending the means to demonstrate integrity. A > TAA > may provide very rich cataloging and searching capabilities but these > capabilities are not related to the integrity preservation mechanisms. > > > > > > Format migration is a related problem but not one we should try to > solve > initially. > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 From owner-ietf-ltans Tue Feb 3 02:10:17 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AAHNU063263; Tue, 3 Feb 2004 02:10:17 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13AAHCI063262; Tue, 3 Feb 2004 02:10:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from dns1.pvt.cz (f9.pvt.cz [194.149.101.199]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AAEKE063248 for ; Tue, 3 Feb 2004 02:10:15 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from PHAWEX02.pvt.cz (phaw02.pvt.cz [172.17.21.21]) by dns1.pvt.cz (8.11.2/8.11.2) with ESMTP id i13AAFW01327 for ; Tue, 3 Feb 2004 11:10:15 +0100 Received: from plzw00.pvt.cz ([172.17.22.11]) by PHAWEX02.pvt.cz with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Feb 2004 11:10:16 +0100 Subject: RE: Role of attribute certificates in long-term archiving MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Date: Tue, 3 Feb 2004 11:10:14 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Role of attribute certificates in long-term archiving Thread-Index: AcPpVdC/7H8NisKDQni+XNOWK6IxiQA5xM3g From: =?iso-8859-2?Q?Vohnoutov=E1_Marta?= To: X-OriginalArrivalTime: 03 Feb 2004 10:10:16.0530 (UTC) FILETIME=[EBBAD320:01C3EA3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i13AAFKE063255 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Santosh, > > If the group decides that authentication and authorization > standard should be included for retrieval (as opposed to > retrieval being a matter of local archive policy), then we > need to keep the above in mind to determine how the long-term > identity validation and authorization should be done. > I think that we must distinguish two identity types: - identity of person who digitally signed the document, this identity must be derived from original digital signature - identities of other persons who e.g. : - put document into archive - retrieves the document from archive - cancel the document in archive etc. The second identity seems to be good to derive from attribute certificates. Marta --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.516 / Virová báze: 313 - datum vydání: 1.9.2003 From owner-ietf-ltans Tue Feb 3 02:19:38 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AJcLg066652; Tue, 3 Feb 2004 02:19:38 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13AJcnx066650; Tue, 3 Feb 2004 02:19:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from dns1.pvt.cz (f9.pvt.cz [194.149.101.199]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AJaAx066635 for ; Tue, 3 Feb 2004 02:19:36 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from PHAWEX02.pvt.cz (phaw02.pvt.cz [172.17.21.21]) by dns1.pvt.cz (8.11.2/8.11.2) with ESMTP id i13AJbW03916 for ; Tue, 3 Feb 2004 11:19:37 +0100 Received: from plzw00.pvt.cz ([172.17.22.11]) by PHAWEX02.pvt.cz with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Feb 2004 11:19:38 +0100 Subject: RE: Role of attribute certificates in long-term archiving MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Feb 2004 11:19:36 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Role of attribute certificates in long-term archiving Thread-Index: AcPopHGNMeqpLfPbSSqd+u1yr9kfWgBmYniA From: =?iso-8859-1?Q?Vohnoutov=E1_Marta?= To: X-OriginalArrivalTime: 03 Feb 2004 10:19:38.0121 (UTC) FILETIME=[3A76CF90:01C3EA3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i13AJbAx066643 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Alexandre, I fully agree - the desired features of archives can vary, if to use certificates and attribute cerificates for identification and access rights for archive accessing can be optional. Marta > -----Original Message----- > From: Alexandre Dulaunoy [mailto:adulau@foo.be] > Sent: Sunday, February 01, 2004 10:19 AM > To: Vohnoutová Marta > Cc: ietf-ltans@imc.org > Subject: RE: Role of attribute certificates in long-term archiving > > On Sun, 1 Feb 2004 Marta.Vohnoutova@pvt.cz wrote: > > > > > > Marta: > > > > > > There does not seem to be any benefit gained by using the > attribute > > certificate format > > > for archived data. > > > > I think the digital archive must have at least the same features as > > classical stone archive. My personal expirience is if you want to > > explore some old documents in archive you must first prove your > > identity, explain your purpose why you need these > documents, and based > > on this the appropriate permitions for the specific part of > archive is > > given to you. > > Except for the public archive of the public administration or public > domain archive/libraries. The only limitation is sometimes the > conservative approach of the physical media/support (in > the digital world, we don't have this issue but we have > others ;-) but no proof is required for accessing the archive. > > The document should consider the both aspect of long-term > archiving where a "proof" is required for accessing and > where "proof" is not required for accessing. > > > > Analogically in digital world, you can prove your identity with > > certificate and attributte certificate represents appropriate > > permitions given to you. > > Yes but sometimes is not required or optional. > > > > > Identity of person who put document into archive 50 years > ago could be > > irrelevant. > > Yes. > > just my .02 EUR, > > adulau > > -- > -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ > -- http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD > -- "Knowledge can create problems, it is not through ignorance > -- that we can solve them" Isaac Asimov > > > > > > --- > Příchozí zpráva neobsahuje viry. > Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). > Verze: 6.0.516 / Virová báze: 313 - datum vydání: 1.9.2003 > > --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.516 / Virová báze: 313 - datum vydání: 1.9.2003 From owner-ietf-ltans Tue Feb 3 03:20:04 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13BK4Ns072851; Tue, 3 Feb 2004 03:20:04 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13BK4mv072850; Tue, 3 Feb 2004 03:20:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from dns1.pvt.cz (f9.pvt.cz [194.149.101.199]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13BK1eK072844 for ; Tue, 3 Feb 2004 03:20:02 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from PHAWEX01.pvt.cz (phaw01.pvt.cz [172.17.21.20]) by dns1.pvt.cz (8.11.2/8.11.2) with ESMTP id i13BK2W17148 for ; Tue, 3 Feb 2004 12:20:02 +0100 Received: from plzw00.pvt.cz ([172.17.22.11]) by PHAWEX01.pvt.cz with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Feb 2004 12:19:59 +0100 Subject: RE: Role of attribute certificates in long-term archiving MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Date: Tue, 3 Feb 2004 12:11:06 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Role of attribute certificates in long-term archiving Thread-Index: AcPp5HmwP2lD4s9FSRyu8xCnUPBFEQAXnhsw From: =?iso-8859-2?Q?Vohnoutov=E1_Marta?= To: X-OriginalArrivalTime: 03 Feb 2004 11:19:59.0919 (UTC) FILETIME=[A93953F0:01C3EA47] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i13BK3eK072845 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Understood here. However I think you may have missed part > of my original point. That being essentially this suggestion > as you put it, encompass the definitions for which those > archives are trusted based upon the content of said archive > was originally valid and accurate as to it's real originator. > As for me, I think we should distinguish two digital archive types: - relatively short term archives (up to e.g. 10-20 years) - many companies must solve this just now (e.g. Internal Digital archive for invoices)- in this case an originator of the document can be the same person with a man cancelling the document = simple access right model. It is enough to sign and time stamp once. It is also possible to use already existing archiving systems. I think we should not be involved in it. - long term archive (e.g. More than 20 years...forever - we should define this). We should be involver only in this type of archive. The time distance between originator and e.g. Archive research worker ... See http://ltans.edelweb.fr/draft-ietf-arch-00.pdf Marta --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.516 / Virová báze: 313 - datum vydání: 1.9.2003 From owner-ietf-ltans Tue Feb 3 03:33:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13BXBVG073973; Tue, 3 Feb 2004 03:33:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13BXBQc073972; Tue, 3 Feb 2004 03:33:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13BX9j9073941 for ; Tue, 3 Feb 2004 03:33:09 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i13BXRob002247 for ; Tue, 3 Feb 2004 12:33:44 +0100 (MET) From: To: Subject: RE: My objections to the submitted draft Date: Tue, 3 Feb 2004 12:29:16 +0100 Message-ID: <003b01c3ea49$04da8d90$1a4f18ac@pvt.cz> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej, > So far we faced an > approach of how to define an interaction with an archive and > what is critically missing in the next > step are archival data structures. TAS might always operate > as a stand > alone entity, mainly dealing with archival complementary data (not > archived documents!!). And most importantly: why do we need data > structures? To assure transparency and existence of an archive over > undefined period of time. And finally, archivists play their > general role > in archiving records, but does a stand alone company need an > archivist? > Not really. Although laws dictates the archiving time of a > document, a > closet does perform more than perfect. So, before we are discussing > further the main question remains: what is the purpose of the > archive we > are trying to define? We need to realize that the two archiving worlds exists: - stand-alone company archive - it does not need archivists, do not archive documents for more than 20years and it is sufficient for it to either create long term signatures or simply to use some existing commercial archiving product - long-term archives. Each document of permanent value finally ends in some archive of this type. We already have such archives for paper documents, films, audio and video. LTANS (if I understood well) aims to create mechanisms for archiving of digitally signed documents. Libor From owner-ietf-ltans Tue Feb 3 03:39:38 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13Bdcvj074359; Tue, 3 Feb 2004 03:39:38 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13BdcGh074358; Tue, 3 Feb 2004 03:39:38 -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.11/8.12.8) with SMTP id i13BdaJL074347 for ; Tue, 3 Feb 2004 03:39:37 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 15063 invoked from network); 3 Feb 2004 11:33:42 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 3 Feb 2004 11:33:42 -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 14810-03 for ; Tue, 3 Feb 2004 12:33:42 +0100 (CET) Received: (qmail 15058 invoked from network); 3 Feb 2004 11:33:42 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 3 Feb 2004 11:33:42 -0000 From: "A. Jerman Blazic" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Tue, 3 Feb 2004 12:41:28 +0100 Message-ID: <000201c3ea4a$a92f3a70$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: X-Virus-Scanned: by amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i13BdcJL074353 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As for me, I think we should distinguish two digital archive types: > - relatively short term archives (up to e.g. 10-20 years) - > many companies must solve this just now (e.g. Internal > Digital archive for invoices)- in this case an originator of > the document can be the same person with a man cancelling the > document = simple access right model. It is enough to sign > and time stamp once. It is also possible to use already > existing archiving systems. I think we should not be involved in it. > > - long term archive (e.g. More than 20 years...forever - we > should define this). We should be involver only in this type > of archive. The time distance between originator and e.g. > Archive research worker ... > See http://ltans.edelweb.fr/draft-ietf-arch-00.pdf > > Marta Now we are finally getting somewhere.... :) However, keep in mind that not the same procedures will be used for the two scenarios. I would distinguish two approaches as a trusted archive and as a trusted storage, which is what you can even map form the analogue environment if you want (pay also attention to legal interpretation of archive, which in Anglo-Saxon approach does not recognize other records as governmental). Accessing procedures might not play essential role in the first case, where the burden will need to be put on preserving the validity of attributes and integrity of records. By introduction of formal documents in electronic forms many organizations are struggling on haw to solve the main problem of records keeping (not archiving). This is why implementation of procedures does not play an important role but data structures to keep the records valid... Aleksej > > --- > Odchozí zpráva neobsahuje viry. > Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). > Verze: 6.0.516 / Virová báze: 313 - datum vydání: 1.9.2003 > > From owner-ietf-ltans Tue Feb 3 03:44:36 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13BianJ074988; Tue, 3 Feb 2004 03:44:36 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13BiZew074987; Tue, 3 Feb 2004 03:44:35 -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.11/8.12.8) with SMTP id i13BiY43074977 for ; Tue, 3 Feb 2004 03:44:34 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 15226 invoked from network); 3 Feb 2004 11:38:42 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 3 Feb 2004 11:38:42 -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 09799-05 for ; Tue, 3 Feb 2004 12:38:41 +0100 (CET) Received: (qmail 15216 invoked from network); 3 Feb 2004 11:38:41 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 3 Feb 2004 11:38:41 -0000 From: "A. Jerman Blazic" To: , Subject: RE: My objections to the submitted draft Date: Tue, 3 Feb 2004 12:46:27 +0100 Message-ID: <000301c3ea4b$5b624700$1b018ac1@arthur> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <003b01c3ea49$04da8d90$1a4f18ac@pvt.cz> 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: > Aleksej, > > > So far we faced an > > approach of how to define an interaction with an archive and > > what is critically missing in the next > > step are archival data structures. TAS might always operate > > as a stand > > alone entity, mainly dealing with archival complementary data (not > > archived documents!!). And most importantly: why do we need data > > structures? To assure transparency and existence of an archive over > > undefined period of time. And finally, archivists play their > > general role > > in archiving records, but does a stand alone company need an > > archivist? > > Not really. Although laws dictates the archiving time of a > > document, a > > closet does perform more than perfect. So, before we are discussing > > further the main question remains: what is the purpose of the > > archive we > > are trying to define? > > We need to realize that the two archiving worlds exists: > - stand-alone company archive - it does not need archivists, > do not archive documents for more than 20years and it is > sufficient for it to either create long term signatures or > simply to use some existing commercial archiving product > - long-term archives. Each document of permanent value > finally ends in some archive of this type. We already have > such archives for paper documents, films, audio and video. > LTANS (if I understood well) aims to create mechanisms for > archiving of digitally signed documents. Agree (see my previous post!). LTANS should give partial (or incremental) solutions to solve both problems (and not only digitally signed documents)... A nice example to this approach rfc3126 or XAdES. Regards aleksej From owner-ietf-ltans Tue Feb 3 06:34:24 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13EYOZO085729; Tue, 3 Feb 2004 06:34:24 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13EYOVE085728; Tue, 3 Feb 2004 06:34:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13EYMcP085701 for ; Tue, 3 Feb 2004 06:34:23 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id PAA12434; Tue, 3 Feb 2004 15:34:05 +0100 (MET) Message-ID: <401FB1C9.3090503@sit.fraunhofer.de> Date: Tue, 03 Feb 2004 15:35:53 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Williams CC: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <008e01c3e8f7$265e8280$a9414d0c@hq.orionsec.com> <401DB050.8C6E1848@ix.netcom.com> <401E1410.1000407@sit.fraunhofer.de> <401EC380.12E4CBA8@ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff, Jeff Williams wrote: >>I believe that the goal of LTANS is to archive evidence, possibly along >>with the document, that proves that the document existed at a certain >>time in the past. This goal was also illustrated by Aleksej in his last >>post. Although document format and its transition is important, I do >>not believe that is the goal of LTANS. > > > Understood. Perhaps its transition should be a goal? If not I would > ask, why not? You are correct, this is a goal of LTANS, which is covered under the milestone notary services requirements. However, I think for the current long-term archive requirements document, and its related protocol and data structures, that file format conversion is not an issue. Thus, I think discussions on file transitions will be valuable when the notary services requirements are written. Regards, Brian From owner-ietf-ltans Tue Feb 3 07:22:01 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13FM1Bh088245; Tue, 3 Feb 2004 07:22:01 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13FM1p4088244; Tue, 3 Feb 2004 07:22:01 -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.11/8.12.8) with ESMTP id i13FLx1x088233 for ; Tue, 3 Feb 2004 07:21:59 -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 QAA27117 for ; Tue, 3 Feb 2004 16:21:56 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 3 Feb 2004 16:21:56 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i13FLtJ26018 for ietf-ltans@imc.org; Tue, 3 Feb 2004 16:21:55 +0100 (MET) Date: Tue, 3 Feb 2004 16:21:55 +0100 (MET) From: Peter Sylvester Message-Id: <200402031521.i13FLtJ26018@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: ltans web site update X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I have updated our web site http://ltans.edelweb.fr with current information about meetings etc. but maybe more important, I have added several links in the related projects section. For those who speak French or can look at pictures, see the Afnor project about electronic proofs. The AFNOR is seeking comments. if you know other related things, please feel to give me the information. Peter From owner-ietf-ltans Tue Feb 3 08:08:37 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13G8bFX091386; Tue, 3 Feb 2004 08:08:37 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13G8bCb091385; Tue, 3 Feb 2004 08:08:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13G8ao8091377 for ; Tue, 3 Feb 2004 08:08:36 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id RAA03255; Tue, 3 Feb 2004 17:08:28 +0100 (MET) Message-ID: <401FC7E8.6030208@sit.fraunhofer.de> Date: Tue, 03 Feb 2004 17:10:16 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Williams CC: ietf-ltans@imc.org Subject: Re: My objections to the submitted draft References: <200402021210.i12CAQG21329@chandon.edelweb.fr> <401E4964.6000807@sit.fraunhofer.de> <401EFB88.70933A6B@ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff, Jeff Williams wrote: > Brian and all, > > Thank you Brian for in part getting to the hart of the situation here. > I agree with almost all of your comments/remarks/observations > below. > > I still think that perhaps we should still get to the what is considered > a trusted archive, how that is specifically as possible, defined, and what > electronically signed CA's for those documents should or must be as > well as how to determine their life of validity, before needing to be > resigned, > if at all... I agree that details of what a trusted archive is or must do, are important. If you have specific suggestions as to requirements, please post them. The data structure draft will specify that document evidence must be renewed before the expiration of the time-stamping certificate. Another criterion could be based on an algorithm strength report, released by local regulation bodies. That is, if the report states that a used algorithm will shortly be considered as weak, then a renewal is required. Brian From owner-ietf-ltans Tue Feb 3 08:15:31 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13GFV8k091977; Tue, 3 Feb 2004 08:15:31 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13GFV20091976; Tue, 3 Feb 2004 08:15:31 -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.11/8.12.8) with ESMTP id i13GFTI0091969 for ; Tue, 3 Feb 2004 08:15:29 -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 i13GFP40027952; Tue, 3 Feb 2004 17:15:26 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <1GY650Z1>; Tue, 3 Feb 2004 17:15:59 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5331@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Brian Hunter'" , Jeff Williams Cc: ietf-ltans@imc.org Subject: RE: My objections to the submitted draft - transitions planned fo r notary draft & no concern about document formats Date: Tue, 3 Feb 2004 17:15:54 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jeff and Brian, I fully agree with Brian and Carl: We want not to take the document format into account for the Trusted Archive. There are many troubles when an archive must interpret the files/formats sent to it - if it is even legal. (That's one of the reasons why AFAIK all big commercial archive providers (Filenet, IXOS, Documentum, ...) avoid that at their servers at all cost.) With the first 2 Ids (protocol and data structures) we hope to solve the long-term provability and the non-repudiation of (possibly signed) data - the transition shall be adressed with the notary services as this is one (of course only one of many) of their basic functions. An other argument for keeping transitions now out is to keep the problem/specification at a manageable size so that we can solve it with the first clearly planned step and benefit from it. And later add more and improve. Best regards Tobias Ps.: Btw. concerning the "transitions" and the notary draft planned for end of this year I would like to invite you to join everyone in May when we start the planning and requirements for that. > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Tuesday, February 03, 2004 15:36 > To: Jeff Williams > Cc: ietf-ltans@imc.org > Subject: Re: My objections to the submitted draft > > > > Jeff, > > Jeff Williams wrote: > >>I believe that the goal of LTANS is to archive evidence, possibly > >>along with the document, that proves that the document existed at a > >>certain time in the past. This goal was also illustrated > by Aleksej > >>in his last post. Although document format and its transition is > >>important, I do not believe that is the goal of LTANS. > > > > > > Understood. Perhaps its transition should be a goal? If > not I would > > ask, why not? > > You are correct, this is a goal of LTANS, which is covered under the > milestone notary services requirements. However, I think for the > current long-term archive requirements document, and its related > protocol and data structures, that file format conversion is not an > issue. Thus, I think discussions on file transitions will be > valuable > when the notary services requirements are written. > > Regards, > Brian > From owner-ietf-ltans Tue Feb 3 08:37:21 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13GbL1n093542; Tue, 3 Feb 2004 08:37:21 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13GbLqt093541; Tue, 3 Feb 2004 08:37:21 -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.11/8.12.8) with ESMTP id i13GbIMj093532 for ; Tue, 3 Feb 2004 08:37:19 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i13GbABN029458; Tue, 3 Feb 2004 17:37:11 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 17:37:43 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5332@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" , Libor.Dostalek@pvt.cz, ietf-ltans@imc.org Subject: RE: My objections to the submitted draft - company archive & long -term archive - comment to libor & Aleksej Date: Tue, 3 Feb 2004 17:37:35 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor and Aleksej, > > > So far we faced an > > > approach of how to define an interaction with an archive and > > > what is critically missing in the next > > > step are archival data structures. TAS might always operate as a stand > > > alone entity, mainly dealing with archival complementary data (not > > > archived documents!!). And most importantly: why do we need data > > > structures? To assure transparency and existence of an archive over > > > undefined period of time. As you can see at the milestones the data structures are planned for this spring - we are actually working on the initial draft to release it during the next days. > > > And finally, archivists play their general role > > > in archiving records, but does a stand alone company need an archivist? > > > Not really. Although laws dictates the archiving time of a document, a > > > closet does perform more than perfect. So, before we are discussing > > > further the main question remains: what is the purpose of the archive we > > > are trying to define? > > > > We need to realize that the two archiving worlds exists: > > - stand-alone company archive - it does not need archivists, > > do not archive documents for more than 20years and it is > > sufficient for it to either create long term signatures or > > simply to use some existing commercial archiving product Don't agree. Even or maybe especially on this scale the need for long-term (maybe even only 20 years) is not satisfied by long term signatures (I assume these should be signatures with extra-long keys ?). You alsways still depend on the algorithm used at signing time without possibility of extension. So for companies it is mission critical to be able to "renew the signatures" with timestamps. Second is: Commercial archiving products today rely on the Write-only functionality of some media when they try something like that. This way is based on some law interpretation that was developed some years ago when TSAs were not available. It is very problematic as you have to trust the company archive in some way that the data media's are not manipulated and you encounter problems when you have to migrate the data from an old media type e.g. CDs to something more convenient like DVDs, etc. > > - long-term archives. Each document of permanent value > > finally ends in some archive of this type. We already have > > such archives for paper documents, films, audio and video. > > LTANS (if I understood well) aims to create mechanisms for > > archiving of digitally signed documents. > > Agree (see my previous post!). LTANS should give partial (or > incremental) solutions to solve both problems (and not only > digitally signed documents)... A nice example to this > approach rfc3126 or XAdES. > Agree so far that LTANS should solve both. Comment: As long as we keep the formats, i.e. the content of the stored data unknown to the TAA the long term storage is basically solved for signed as well as unsigned data. Tobias From owner-ietf-ltans Tue Feb 3 12:49:51 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13KnouJ010990; Tue, 3 Feb 2004 12:49:50 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13Knok4010989; Tue, 3 Feb 2004 12:49:50 -0800 (PST) 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.11/8.12.8) with ESMTP id i13KnnFV010980 for ; Tue, 3 Feb 2004 12:49:49 -0800 (PST) (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 PAA00423; Tue, 3 Feb 2004 15:49:51 -0500 (EST) Message-Id: <200402032049.PAA00423@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-00.txt Date: Tue, 03 Feb 2004 15:49:50 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-term Archive Service Requirements Author(s) : C. Wallace Filename : draft-ietf-ltans-reqs-00.txt Pages : 13 Date : 2004-2-3 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the technical requirements for a long-term archive service to support such scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-3150125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3150125.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ltans Tue Feb 3 13:20:10 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13LKAJA012466; Tue, 3 Feb 2004 13:20:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13LKAho012465; Tue, 3 Feb 2004 13:20:10 -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.11/8.12.8) with ESMTP id i13LK94k012459 for ; Tue, 3 Feb 2004 13:20:09 -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 i13LKBjU000682 for ; Tue, 3 Feb 2004 16:20:11 -0500 From: "Carl Wallace" To: Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-00.txt Date: Tue, 3 Feb 2004 16:20:05 -0500 Message-ID: <000b01c3ea9b$81dd2490$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200402032049.PAA00423@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i13LK94k012460 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: An explanation is probably warranted. In November we posted the initial requirements doc (version -00) to the list because it was too late to submit it through IETF in advance of the Minneapolis meeting. Recently, we posted its successor (version -01) to the list prior to submission to IETF. IETF requires all drafts to be born at -00. Thus, the IETF -00 version is the same as the -01 version that was posted to the list. The -00 from November has no standing. The next version will be -01. Sorry for the mix-up. From owner-ietf-ltans Tue Feb 3 13:49:45 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13Lnj21014428; Tue, 3 Feb 2004 13:49:45 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13Lnjnw014427; Tue, 3 Feb 2004 13:49:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-8.adobe.com (smtp-relay-8.adobe.com [192.150.22.8]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13Lnegj014416 for ; Tue, 3 Feb 2004 13:49:40 -0800 (PST) (envelope-from LMM@acm.org) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i13Lmu6P008157; Tue, 3 Feb 2004 13:49:01 -0800 (PST) Received: from calsj-dev (mailsj [153.32.1.239]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i13Lmt3k015571; Tue, 3 Feb 2004 13:48:55 -0800 (PST) Received: from MasinterT40 (c-66-191.corp.adobe.com [153.32.66.191]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HSJ00BIF39J8M@mailsj-v1.corp.adobe.com>; Tue, 03 Feb 2004 13:48:55 -0800 (PST) Date: Tue, 03 Feb 2004 13:48:54 -0800 From: Larry Masinter Subject: RE: My objections to the submitted draft - transitions planned for notary draft & no concern about document formats In-reply-to: <077097E85A6BD3119E910800062786A9094D5331@muc-mail5.ixos.de> To: "'Tobias Gondrom'" , "'Brian Hunter'" , "'Jeff Williams'" Cc: ietf-ltans@imc.org Message-id: <0HSJ00BIG39J8M@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcPqceDJfkg77ICHRqGC8DluIhDqlAALTPrA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I fully agree with Brian and Carl: > We want not to take the document format into account for the Trusted > Archive. > There are many troubles when an archive must interpret the files/formats > sent to it - if it is even legal. (That's one of the reasons why AFAIK all > big commercial archive providers (Filenet, IXOS, Documentum, ...) avoid that > at their servers at all cost.) The archive might still track the format of the files in it, the relationship between the original archived file and some translation of it into a current format, whether the file format was considered an "archival" subset, etc. MIME types may not be enough to characterize file formats for archival formats, and you might need, for example, some standards for media features to describe archival properties. > With the first 2 Ids (protocol and data structures) we hope to solve the > long-term provability and the non-repudiation of (possibly signed) data - > the transition shall be adressed with the notary services as this is one (of > course only one of many) of their basic functions. > > An other argument for keeping transitions now out is to keep the > problem/specification at a manageable size so that we can solve it with the > first clearly planned step and benefit from it. And later add more and > improve. I think you can make a case for including standard metadata for file formats even if the system doesn't require or provide for translation. Larry From owner-ietf-ltans Wed Feb 4 05:28:41 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14DSf5H050421; Wed, 4 Feb 2004 05:28:41 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i14DSfrF050420; Wed, 4 Feb 2004 05:28:41 -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.11/8.12.8) with ESMTP id i14DSX9d050408 for ; Wed, 4 Feb 2004 05:28:38 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i14DSYhe017737; Wed, 4 Feb 2004 14:28:35 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 14:29:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5341@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Cc: "'ralf.brandner@intercomponentware.com'" Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? - keep it Date: Wed, 4 Feb 2004 14:29:00 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB22.D96B5010" 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_001_01C3EB22.D96B5010 Content-Type: text/plain First rough consensus: as taken from the mailing-list I derive the first rough consensus to keep the wording "trusted archive" Best regards and thank you for your comments Tobias ;-) chair LTANS -----Original Message----- From: ralf.brandner@intercomponentware.com [mailto:ralf.brandner@intercomponentware.com] Sent: Friday, January 30, 2004 8:35 To: Tobias.Gondrom@ixos.de Cc: ietf-ltans@imc.org Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ? I agree with Carl and Brian, then also for me is archiving only the "simple" document storage. Trusted archiving is more - conservation of evidence ... Regards, Ralf ======================================== Dr. Ralf Brandner Produktmanager InterComponentWare AG Otto-Hahn-Str. 3 69190 Walldorf Tel: +49 6227 385 135 Fax: +49 6227 385 192 Mobil: +49 173 6667457 Email: ralf.brandner@intercomponentware.com ======================================== "Brandner, Ralf" 28.01.2004 14:33 To: "Ralf Brandner (E-Mail)" cc: Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ? > > ---------- > Von: Brian Hunter[SMTP:BRIAN.HUNTER@SIT.FRAUNHOFER.DE] > Gesendet: Mittwoch, 28. Januar 2004 14:26:54 > An: Carl Wallace > Cc: 'Tobias Gondrom'; ietf-ltans@imc.org > Betreff: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ? > Diese Nachricht wurde automatisch von einer Regel weitergeleitet. > > Carl Wallace wrote: >>For that I would prefer if we could change the names from : >>"Trusted Archiving" to "Archiving" >>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive > > Service" > > The word "trusted" provides a hint that something more than simple storage > of the data is going on (even if the actual trust is in the TSA). Also, an I agree. The differentiation between a simple archive service (only document storage) and an archive service that obtains evidence of document existence is important. > Archive Authority must be trusted if it is providing trust anchor > information. I am not sure I follow this point. What would this trust anchor information be? Regards, Brian ------_=_NextPart_001_01C3EB22.D96B5010 Content-Type: text/html Message
First rough consensus:
 
as taken from the mailing-list I derive the first rough consensus to keep the wording "trusted archive"
 
Best regards and thank you for your comments
 
Tobias ;-)
 
chair LTANS
 
 
-----Original Message-----
From: ralf.brandner@intercomponentware.com [mailto:ralf.brandner@intercomponentware.com]
Sent: Friday, January 30, 2004 8:35
To: Tobias.Gondrom@ixos.de
Cc: ietf-ltans@imc.org
Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ?


I agree with Carl and Brian, then also for me is archiving only the "simple" document storage. Trusted archiving is more - conservation of evidence ...

Regards,
Ralf

========================================
Dr. Ralf Brandner
Produktmanager
InterComponentWare AG
Otto-Hahn-Str. 3
69190 Walldorf
Tel: +49 6227 385 135
Fax: +49 6227 385 192
Mobil: +49 173 6667457
Email: ralf.brandner@intercomponentware.com
========================================



                "Brandner, Ralf" <Ralf.Brandner@med.uni-heidelberg.de>


28.01.2004 14:33
       
       To:        "Ralf Brandner (E-Mail)" <ralf.brandner@intercomponentware.com>
       cc:        
       Subject:        WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ?





>
> ----------
> Von:                  Brian Hunter[SMTP:BRIAN.HUNTER@SIT.FRAUNHOFER.DE]
> Gesendet:                  Mittwoch, 28. Januar 2004 14:26:54
> An:                  Carl Wallace
> Cc:                  'Tobias Gondrom'; ietf-ltans@imc.org
> Betreff:                  Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ?
> Diese Nachricht wurde automatisch von einer Regel weitergeleitet.
>
>
Carl Wallace wrote:
>>For that I would prefer if we could change the names from :
>>"Trusted Archiving" to "Archiving"
>>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive
>
> Service"
>
> The word "trusted" provides a hint that something more than simple storage
> of the data is going on (even if the actual trust is in the TSA).  Also, an

I agree.  The differentiation between a simple archive service (only
document storage) and an archive service that obtains evidence of
document existence is important.

> Archive Authority must be trusted if it is providing trust anchor
> information.

I am not sure I follow this point.  What would this trust anchor
information be?

Regards,
Brian





------_=_NextPart_001_01C3EB22.D96B5010-- From owner-ietf-ltans Fri Feb 13 13:10:25 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DLAPxZ019744; Fri, 13 Feb 2004 13:10:25 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1DLAPJ7019743; Fri, 13 Feb 2004 13:10:25 -0800 (PST) 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.11/8.12.8) with ESMTP id i1DLANqA019736 for ; Fri, 13 Feb 2004 13:10:24 -0800 (PST) (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 QAA03832; Fri, 13 Feb 2004 16:10:43 -0500 (EST) Message-Id: <200402132110.QAA03832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-00.txt Date: Fri, 13 Feb 2004 16:10:43 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner Filename : draft-ietf-ltans-ers-00.txt Pages : 22 Date : 2004-2-12 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODIN