From owner-ietf-ltans Thu Apr 1 00:04:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3184jxB027940; Thu, 1 Apr 2004 00:04: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 i3184j3k027938; Thu, 1 Apr 2004 00:04:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3184hsw027912 for ; Thu, 1 Apr 2004 00:04:44 -0800 (PST) (envelope-from Antje.Hollerbach@med.uni-heidelberg.de) Received: from msw.med.uni-heidelberg.de (mail.med.uni-heidelberg.de [129.206.90.21]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i3184fSe023572 for ; Thu, 1 Apr 2004 10:04:41 +0200 (MET DST) Received: from exc02.ads.krz.uni-heidelberg.de (unverified) by msw.med.uni-heidelberg.de (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Thu, 1 Apr 2004 10:04:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:04:40 +0200 Message-ID: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Alternatives for Long Term Archiving Thread-Index: AcQR1vwPWscwRQDjSCWl6xC7VKDuAAF5+qRAAAADG2A= From: "Hollerbach, Antje" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3184isw027932 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the use of different archive facilities is unrealistic for organisations like e.g. hospitals, because the costs are unreasonable, it is very complex and not practicable. Real users, such as our university hospital, which source out their archival system, want to keep their costs as low as possible. Furthermore, redistribution makes little sense for organisations that don't outsource. We need as soon as possible solutions, which can be used for the renewal of signatures and for the proof of the archiving time. Furthermore simple protocols for archiving services would be expedient. The previous documents of LTANS suit this purpose but not the thoughts in your mail below! A. Hollerbach Center for Information Management (ZIM), University Hospital of Heidelberg -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, March 24, 2004 7:37 PM To: ietf-ltans@imc.org Subject: Alternatives for Long Term Archiving One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) is to use a key-less approach to trusted archive. The client who has vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n must be greater than 1, less than or equal to m, and should be selected based on the desired degree of protection against collusion. If this scheme is used, we may not need any cryptographic operations at the TAA. Under this scheme, the LTANS WG would need to still define various protocol for submission, deletion, and retrieval. if the idea is acceptable to the group, it could be the preferred or one of the approaches to perform archiving. As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. One advantage of the approach is that any document split is not sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. To further illustrate one usage of the approach, a client with the need to provide long-term, non-repudiation of a transaction, could obtain current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. When there is a need to retrieve the evidence, n splits could be retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of the TAAs. Santosh Chokhani Orion Security Solutions, Inc. 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (703) 917-0060 Ext. 35 (voice) (703) 917-0260 (Fax) chokhani@orionsec.com Visit our Web site http://www.orionsec.com From owner-ietf-ltans Thu Apr 1 01:15:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i319FX7A052806; Thu, 1 Apr 2004 01:15:33 -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 i319FXOQ052805; Thu, 1 Apr 2004 01:15:33 -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 i319FWqI052767 for ; Thu, 1 Apr 2004 01:15:33 -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 LAA00436; Thu, 1 Apr 2004 11:15:28 +0200 (MET DST) Message-ID: <406BDE1E.3040401@sit.fraunhofer.de> Date: Thu, 01 Apr 2004 11:17:18 +0200 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: Libor.Dostalek@pvt.cz CC: ietf-ltans@imc.org Subject: Re: Our objections to draft ERS References: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor, Thanks for your comments on the draft. Please find my comments below. Libor.Dostalek@pvt.cz wrote: >>From my point of view the complex impression of this draft is very >>good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is requested only > for the root hash of the hash-tree" for a long time. But after some > time, I consider it to be a good idea. If I think it over, the > publishing of the > root hash-tree in newspapers every week is interesting, but the > "classical" time stamp acc. to RFC-3161 can easily temporarily > replace it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term signatures will be > archived (RFC-3126). When archiving long-term signed document to the > TAA, the renew of particular digital signatures acc. to RFC-3126 will be > finished and the whole structure will be stored as data (as Archived > data object)? And after this, it will be renewed as the Archive Time > Stamp Chain? I would like this solution! This is related to your next question. In your example, the whole CMS object, as in RFC 3126, should be given to the TAA for archiving. > > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some examples, which > will make clear the meaning (for example in appendix). As Aleksej and Santosh said, the document and signature, along with certificates, crls, etc, should be archived, in order to provide non-repudiation of the document and signature in the future. > - Evidence record: this structure does not contain the identification > data of the archived document. How could you find such document in the > archive? One reason why no id is included, is that we do not want a connection between the evidence record and the actual provider, since it is not necessary for validating the record. As Aleksej said, this is a management issue, which can be handled by a doc id in the protocol or by meta data, to aid searching, as he earlier proposed. > - Archive Time-stamp, 3.1 Syntax: If I understand well: if the > reducedHashtree item misses, there is the time stamp from the document > instead of from the root-hash tree. If it is true, it should be > described here. You are correct, that is what is meant. I will make the text more explicit in this regards. > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with different > meaning in the RFC-3126. I would recommend to adjust the name slightly. If this name leads to confusion for developers, then we should discuss this. We initially used the term Enhanced Time-Stamp. Let's first wait for some new name suggestions, and we can then decide whether to leave the name or change it. All the suggestions below will be integrated. Brian > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal the ..." > Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not sufficient ..." > Change to "The simple Time-Stamp renewal is not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." change to "A > multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Ć = H (h(i_a)+ ha(i)) > h(i_b)Ć = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Ć", which various readers could view > in a different way. I would recommend to change it for some other ascii > character (e.g. for " ' "). > > > Libor & Marta > > > From owner-ietf-ltans Thu Apr 1 00:45:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i318j3dt042597; Thu, 1 Apr 2004 00:45:03 -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 i318j3Yi042595; Thu, 1 Apr 2004 00:45:03 -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 i318j2gB042542 for ; Thu, 1 Apr 2004 00:45:03 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 11250 invoked from network); 1 Apr 2004 08:44:55 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 1 Apr 2004 08:44:55 -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 10745-10 for ; Thu, 1 Apr 2004 10:44:55 +0200 (CEST) Received: (qmail 11242 invoked from network); 1 Apr 2004 08:44:55 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 1 Apr 2004 08:44:55 -0000 From: "A. Jerman Blazic" To: "'Hollerbach, Antje'" Cc: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:44:54 +0200 Message-ID: <002401c417c5$9aa2c050$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: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.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: Dear Hollerbach, I've been silently waiting for an answer like yours. I must admit, that I unfortunately do not find the discussion going in direction of solving actual problems. From the position of developer, implementation and technical advisor it is hard to cope with current standards and proposes when facing the problem of conserving electronic records. Document bases are already full and usually in hands of single entity, which sees appropriate solution as a technology add-on for preservation of existing and future records. Re-distribution doesn't make much sense, rather single point of trust is what will IMHO evolve in the next years, the same scenario as deployed for digital signatures currently. End users are pressing really hard on us (technology providers) to come up with solution right this moment. And what is needed is to steer the initial LTANS course in the right direction and deliver critical missing pieces in the infrastructure as soon as possible. You may take some of your time and investigate what solutions do exist already on the market in the line with technical requirements, legislation and regulation and how they would solve your problems. The situation is not that bad... Regards A. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Hollerbach, Antje > Sent: Thursday, April 01, 2004 10:05 AM > To: chokhani@orionsec.com > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > > I think that the use of different archive facilities is > unrealistic for organisations like e.g. hospitals, because > the costs are unreasonable, it is very complex and not > practicable. Real users, such as our university hospital, > which source out their archival system, want to keep their > costs as low as possible. Furthermore, redistribution makes > little sense for organisations that don't outsource. We need > as soon as possible solutions, which can be used for the > renewal of signatures and for the proof of the archiving > time. Furthermore simple protocols for archiving services > would be expedient. The previous documents of LTANS suit > this purpose but not the thoughts in your mail below! > > A. Hollerbach > Center for Information Management (ZIM), University Hospital > of Heidelberg > > > > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Wednesday, March 24, 2004 7:37 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > One of the ideas that came out of Seoul meeting (thanks to Larry > Masinter) is to use a key-less approach to trusted archive. > The client who has vested interest in the secure storage of > archived data, can use Shamir's n of m scheme to submit the > archived data to m archive facilities. m must be greater > than 1 and should be selected based on availability needs. n > must be greater than 1, less than or equal to m, and should > be selected based on the desired degree of protection against > collusion. > > If this scheme is used, we may not need any cryptographic > operations at the TAA. > > Under this scheme, the LTANS WG would need to still define > various protocol for submission, deletion, and retrieval. if > the idea is acceptable to the group, it could be the > preferred or one of the approaches to perform archiving. > > As the current LTANS documents in the various stages state or > imply, the trusted archive can continue to be used to submit > any class of data. > > One advantage of the approach is that any document split is > not sensitive even if the original document is sensitive. > However, if the document requires confidentiality, assuming > an adversary could be monitoring the channels to collect all > the splits, the submission and retrieval of the split should > be provided transmission security using techniques such as > SSL or session encryption. This still is lot easier than > needing to provide long-term encryption for stored data. > > To further illustrate one usage of the approach, a client > with the need to provide long-term, non-repudiation of a > transaction, could obtain current time stamp, all the trust > anchor, certificates, revocation information relevant to > signatures and time stamp, and package them using TBD record > format and create m splits. These m split could be sent to m > TAAs using TLS. Each TLS could provide a pointer to its split. > > When there is a need to retrieve the evidence, n splits could > be retrieved from n TAAs that are available and can be > combined to validate the signatures on the transaction as > well as the time stamp. > > The approach also offers some redundancy in case some TAAs > are not available, data is corrupted, or the challenger does > not trust some of the TAAs. > > Santosh Chokhani > Orion Security Solutions, Inc. > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (703) 917-0060 Ext. 35 (voice) > (703) 917-0260 (Fax) > chokhani@orionsec.com > Visit our Web site > http://www.orionsec.com > From owner-ietf-ltans Thu Apr 1 05:32:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31DW2Qe093577; Thu, 1 Apr 2004 05:32: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 i31DW2dd093576; Thu, 1 Apr 2004 05:32: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 i31DW1Pg093570 for ; Thu, 1 Apr 2004 05:32:01 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31DW3At010122 for ; Thu, 1 Apr 2004 08:32:03 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 08:32:03 -0500 Message-ID: <003e01c417ed$b7e2ab30$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: <406AAE4A.8060800@sit.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31DW2Pg093571 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian From owner-ietf-ltans Thu Apr 1 05:36:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31DaDNw093877; Thu, 1 Apr 2004 05:36:13 -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 i31DaDTv093876; Thu, 1 Apr 2004 05:36:13 -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 i31DaDNk093869 for ; Thu, 1 Apr 2004 05:36:13 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31DaEAt010580 for ; Thu, 1 Apr 2004 08:36:15 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 08:36:14 -0500 Message-ID: <003f01c417ee$4df8e8f0$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: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31DaDNk093871 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Antje Hollerbach: See responses in-line in []. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Hollerbach, Antje Sent: Thursday, April 01, 2004 3:05 AM To: chokhani@orionsec.com Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving I think that the use of different archive facilities is unrealistic for organisations like e.g. hospitals, because the costs are unreasonable, it is very complex and not practicable. Real users, such as our university hospital, which source out their archival system, want to keep their costs as low as possible. Furthermore, redistribution makes little sense for organisations that don't outsource. We need as soon as possible solutions, which can be used for the renewal of signatures and for the proof of the archiving time. Furthermore simple protocols for archiving services would be expedient. The previous documents of LTANS suit this purpose but not the thoughts in your mail below! [The n of m scheme is being vetted through the process. Your example shows that there is a need for a single TAA that relies on computer security and possibly refreshing time stamp means. If we were to include n of m scheme in the standards also, it will be in addition to the ERS approach, not instead of]. A. Hollerbach Center for Information Management (ZIM), University Hospital of Heidelberg -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, March 24, 2004 7:37 PM To: ietf-ltans@imc.org Subject: Alternatives for Long Term Archiving One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) is to use a key-less approach to trusted archive. The client who has vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n must be greater than 1, less than or equal to m, and should be selected based on the desired degree of protection against collusion. If this scheme is used, we may not need any cryptographic operations at the TAA. Under this scheme, the LTANS WG would need to still define various protocol for submission, deletion, and retrieval. if the idea is acceptable to the group, it could be the preferred or one of the approaches to perform archiving. As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. One advantage of the approach is that any document split is not sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. To further illustrate one usage of the approach, a client with the need to provide long-term, non-repudiation of a transaction, could obtain current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. When there is a need to retrieve the evidence, n splits could be retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of the TAAs. Santosh Chokhani Orion Security Solutions, Inc. 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (703) 917-0060 Ext. 35 (voice) (703) 917-0260 (Fax) chokhani@orionsec.com Visit our Web site http://www.orionsec.com From owner-ietf-ltans Thu Apr 1 06:28:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31ESwuN098278; Thu, 1 Apr 2004 06:28:58 -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 i31ESwnp098277; Thu, 1 Apr 2004 06:28:58 -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 i31ESuip098257 for ; Thu, 1 Apr 2004 06:28:57 -0800 (PST) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCHOTZENPLOTZ (pc-hotzenplotz [141.12.33.2]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id QAA05438 for ; Thu, 1 Apr 2004 16:28:47 +0200 (MET DST) From: "Ulrich Pordesch" To: Subject: AW: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 16:29:08 +0200 Organization: Fraunhofer, SIT Message-ID: <007401c417f5$b1bf7f00$02210c8d@PCHOTZENPLOTZ> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: Normal In-Reply-To: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31ESvip098272 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh: Getting a proof of existence of data at a certain time in the past using (sequences/ chains of) time-stamps is an essential part of the service and the reason, why we required this as "must requirement" in requirements draft. Getting trust relating to time- of existance by statements of a new kind of trusted authorities (TAAs) is a completly other kind of trust. This solution is not sufficient to conserve value of evidence of signed documents in court, because there is no law (in germany but also anywhere else, as I know), which recognizes trusted archives like regulated/trusted time-stamp authorities. I think we will never get such law, because complex archive systems can not be evaluated to the same degree as simple time-stamping-machines. Statements of TAAs, provided by protocol, may be an additional useful features, if there are users who need it. Ulrich -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Santosh Chokhani Gesendet: Donnerstag, 1. April 2004 15:32 An: ietf-ltans@imc.org Betreff: RE: Alternatives for Long Term Archiving Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian From owner-ietf-ltans Thu Apr 1 07:46:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Fksif004166; Thu, 1 Apr 2004 07:46: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 i31FksTr004165; Thu, 1 Apr 2004 07:46:54 -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 i31Fkr1M004158 for ; Thu, 1 Apr 2004 07:46:54 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31FkuAt029922 for ; Thu, 1 Apr 2004 10:46:56 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:46:56 -0500 Message-ID: <000201c41800$8fdcb7d0$9a00a8c0@hq.orionsec.com> 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.4510 In-reply-to: <007401c417f5$b1bf7f00$02210c8d@PCHOTZENPLOTZ> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31Fks1M004160 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ulrich: To solve the problem, if the person who feels that the evidence may be needed (e.g., the client) can obtain a time stamp, get all appropriate trust anchors, certificates, revocation information attached, split n of m and submit to the archives. Then, when the evidence needs to reconstructed, n TAAs can supply their shares to construct the original with all the signatures and time stamps. Why would that not be simple or meet the German Law? -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Ulrich Pordesch Sent: Thursday, April 01, 2004 9:29 AM To: ietf-ltans@imc.org Subject: AW: Alternatives for Long Term Archiving Santosh: Getting a proof of existence of data at a certain time in the past using (sequences/ chains of) time-stamps is an essential part of the service and the reason, why we required this as "must requirement" in requirements draft. Getting trust relating to time- of existance by statements of a new kind of trusted authorities (TAAs) is a completly other kind of trust. This solution is not sufficient to conserve value of evidence of signed documents in court, because there is no law (in germany but also anywhere else, as I know), which recognizes trusted archives like regulated/trusted time-stamp authorities. I think we will never get such law, because complex archive systems can not be evaluated to the same degree as simple time-stamping-machines. Statements of TAAs, provided by protocol, may be an additional useful features, if there are users who need it. Ulrich -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Santosh Chokhani Gesendet: Donnerstag, 1. April 2004 15:32 An: ietf-ltans@imc.org Betreff: RE: Alternatives for Long Term Archiving Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian From owner-ietf-ltans Thu Apr 1 09:45:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Hjh6w013691; Thu, 1 Apr 2004 09:45: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 i31HjhxB013670; Thu, 1 Apr 2004 09:45: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.11/8.12.8) with ESMTP id i31Hje6a013625 for ; Thu, 1 Apr 2004 09:45:40 -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 i31HjZ6Q011625; Thu, 1 Apr 2004 19:45:36 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 19:45:36 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D548A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 19:47:30 +0200 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 i31Hjf6a013652 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh, It's a bit hard for me to understand all the benefits from the n-of-m-split and why to use it. If you don't mind I try to bring up what I took from the discussion so far and you correct my misunderstanding: 1. n-of-m-split is not instead of ERS data structures - it is in addition ? (what I take from your mail to Antje) 2. n-of-m-split shall provide the security that the data is unchanged based on the idea that it is not possible to tamper all the TAA where the data is stored - or at least not the majority ? 3. n-of-m split has in mind some kind of High availablity and redundancy (like RAID systems ?) using a highly distributed infrastructure - some kind of P2P network ??? Some thought about that from my point of view: >From the business perspective I clearly doubt that any company - and probably not even a private person - would love to risk it's documents on an infrastructure not fully under it's control or that not at least can't be held fully reliable for the storage of the document. Of course within companies and institutions the distribution and redundancy of data is clearly wanted and today already done (e.g. RAID systems etc.) - so the risk to loose a document is something that the solutions already available today can handle quite good. (just talk with some storage vendors - like I had to do during the last months - and you will find that they are doing quite a good job at that.) Probably I missed something important, so please help me a little bit to understand. Tobias Chair of LTANS > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 01, 2004 17:47 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Ulrich: > > To solve the problem, if the person who feels that the > evidence may be needed (e.g., the client) can obtain a time > stamp, get all appropriate trust anchors, certificates, > revocation information attached, split n of m and submit to > the archives. Then, when the evidence needs to > reconstructed, n TAAs can supply their shares to construct > the original with all the signatures and time stamps. > > Why would that not be simple or meet the German Law? > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Ulrich Pordesch > Sent: Thursday, April 01, 2004 9:29 AM > To: ietf-ltans@imc.org > Subject: AW: Alternatives for Long Term Archiving > > > > Santosh: > > Getting a proof of existence of data at a certain time in the > past using (sequences/ chains of) time-stamps is an essential > part of the service and the reason, why we required this as > "must requirement" in requirements draft. Getting trust > relating to time- of existance by statements of a new kind of > trusted authorities (TAAs) is a completly other kind of > trust. This solution is not sufficient to conserve value of > evidence of signed documents in court, because there is no > law (in germany but also anywhere else, as I know), which > recognizes trusted archives like regulated/trusted time-stamp > authorities. I think we will never get such law, because > complex archive systems can not be evaluated to the same > degree as simple time-stamping-machines. Statements of TAAs, > provided by protocol, may be an additional useful features, > if there are users who need it. > > > Ulrich > > > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im > Auftrag von Santosh Chokhani > Gesendet: Donnerstag, 1. April 2004 15:32 > An: ietf-ltans@imc.org > Betreff: RE: Alternatives for Long Term Archiving > > > > Brian: > > I do not think trusted archive requires providing date and > time service. > > If the trusted archive requirement is to attest to the date > of any document, then each TAA may put a date time stamp or > get date-time stamp from an authority and add proper trust > anchors, certificates and revocation information. > > n of m only helps with integrity, availability, and provides > protection against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each > TAA simply > states (and signs) when the document existed and when n TAAs > state the > same date, this date is correct and trustworthy? > > Regards, > Brian > > > > > From owner-ietf-ltans Thu Apr 1 10:03:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31I3T23014941; Thu, 1 Apr 2004 10:03:29 -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 i31I3TRF014940; Thu, 1 Apr 2004 10:03:29 -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 i31I3SAG014922 for ; Thu, 1 Apr 2004 10:03:28 -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 i31I3Pkf017276; Thu, 1 Apr 2004 20:03:25 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ5XZA>; Thu, 1 Apr 2004 20:05:40 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D548C@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" , "'Hollerbach, Antje'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 20:05:20 +0200 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: Dear Jerman, dear Antje, > I've been silently waiting for an answer like yours. I must > admit, that I unfortunately do not find the discussion going > in direction of solving actual problems. I have to agree with you both. > From the position of > developer, implementation and technical advisor it is hard to > cope with current standards and proposes when facing the > problem of conserving electronic records. Document bases are > already full and usually in hands of single entity, which > sees appropriate solution as a technology add-on for > preservation of existing and future records. Here you are fully right. And btw. I know no company which would be willing to share it's documents with others or to rely on others to provide the with mission critical data - and most of the documents, that are signed, are important for some reason. > Re-distribution > doesn't make much sense, rather single point of trust is what > will IMHO evolve in the next years, the same scenario as > deployed for digital signatures currently. End users are > pressing really hard on us (technology providers) to come up > with solution right this moment. And what is needed is to > steer the initial LTANS course in the right direction and > deliver critical missing pieces in the infrastructure as soon > as possible. You are right. What I take from the request from the market at the moment are questions about an available standardized solution for mid of this year - that's in 3 months ! And with all these regulatory compliance stuff and the e-signature and so on this gets a lot of momentum at the moment! So if possible I would also like to speed-up our progress so far that we can deliver a good solution in time - and if necessary would like to add further improving ideas later in a second version - if they really fulfill requirements from the market. Regards Tobias > You may take some of your time and investigate > what solutions do exist already on the market in the line > with technical requirements, legislation and regulation and > how they would solve your problems. The situation is not that bad... > > Regards > > A. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > Hollerbach, Antje > > Sent: Thursday, April 01, 2004 10:05 AM > > To: chokhani@orionsec.com > > Cc: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > I think that the use of different archive facilities is > > unrealistic for organisations like e.g. hospitals, because > > the costs are unreasonable, it is very complex and not > > practicable. Real users, such as our university hospital, > > which source out their archival system, want to keep their > > costs as low as possible. Furthermore, redistribution makes > > little sense for organisations that don't outsource. We need > > as soon as possible solutions, which can be used for the > > renewal of signatures and for the proof of the archiving > > time. Furthermore simple protocols for archiving services > > would be expedient. The previous documents of LTANS suit > > this purpose but not the thoughts in your mail below! > > > > A. Hollerbach > > Center for Information Management (ZIM), University Hospital > > of Heidelberg > > > > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Wednesday, March 24, 2004 7:37 PM > > To: ietf-ltans@imc.org > > Subject: Alternatives for Long Term Archiving > > > > > > One of the ideas that came out of Seoul meeting (thanks to Larry > > Masinter) is to use a key-less approach to trusted archive. > > The client who has vested interest in the secure storage of > > archived data, can use Shamir's n of m scheme to submit the > > archived data to m archive facilities. m must be greater > > than 1 and should be selected based on availability needs. n > > must be greater than 1, less than or equal to m, and should > > be selected based on the desired degree of protection against > > collusion. > > > > If this scheme is used, we may not need any cryptographic > > operations at the TAA. > > > > Under this scheme, the LTANS WG would need to still define > > various protocol for submission, deletion, and retrieval. if > > the idea is acceptable to the group, it could be the > > preferred or one of the approaches to perform archiving. > > > > As the current LTANS documents in the various stages state or > > imply, the trusted archive can continue to be used to submit > > any class of data. > > > > One advantage of the approach is that any document split is > > not sensitive even if the original document is sensitive. > > However, if the document requires confidentiality, assuming > > an adversary could be monitoring the channels to collect all > > the splits, the submission and retrieval of the split should > > be provided transmission security using techniques such as > > SSL or session encryption. This still is lot easier than > > needing to provide long-term encryption for stored data. > > > > To further illustrate one usage of the approach, a client > > with the need to provide long-term, non-repudiation of a > > transaction, could obtain current time stamp, all the trust > > anchor, certificates, revocation information relevant to > > signatures and time stamp, and package them using TBD record > > format and create m splits. These m split could be sent to m > > TAAs using TLS. Each TLS could provide a pointer to its split. > > > > When there is a need to retrieve the evidence, n splits could > > be retrieved from n TAAs that are available and can be > > combined to validate the signatures on the transaction as > > well as the time stamp. > > > > The approach also offers some redundancy in case some TAAs > > are not available, data is corrupted, or the challenger does > > not trust some of the TAAs. > > > > Santosh Chokhani > > Orion Security Solutions, Inc. > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (703) 917-0060 Ext. 35 (voice) > > (703) 917-0260 (Fax) > > chokhani@orionsec.com > > Visit our Web site > > http://www.orionsec.com > > > From owner-ietf-ltans Thu Apr 1 11:26:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31JQ5E3021234; Thu, 1 Apr 2004 11:26: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 i31JQ5PB021233; Thu, 1 Apr 2004 11:26: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 i31JQ4op021227 for ; Thu, 1 Apr 2004 11:26:04 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31JQ8At001521 for ; Thu, 1 Apr 2004 14:26:08 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 14:26:08 -0500 Message-ID: <004801c4181f$2ef557a0$9a00a8c0@hq.orionsec.com> 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.4510 In-reply-to: <077097E85A6BD3119E910800062786A9094D548A@muc-mail5.ixos.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31JQ5op021228 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: You have the summary correct. If a party wants to store a document in its system at a single point, why do we need timestamps at all and further more why do we need to refresh them? I thought their purpose was to provide protection against a rogue TAA. If want single party to be in charge, we can just store the data. No crypto is needed. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Thursday, April 01, 2004 12:48 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Santosh, It's a bit hard for me to understand all the benefits from the n-of-m-split and why to use it. If you don't mind I try to bring up what I took from the discussion so far and you correct my misunderstanding: 1. n-of-m-split is not instead of ERS data structures - it is in addition ? (what I take from your mail to Antje) 2. n-of-m-split shall provide the security that the data is unchanged based on the idea that it is not possible to tamper all the TAA where the data is stored - or at least not the majority ? 3. n-of-m split has in mind some kind of High availablity and redundancy (like RAID systems ?) using a highly distributed infrastructure - some kind of P2P network ??? Some thought about that from my point of view: >From the business perspective I clearly doubt that any company - and probably not even a private person - would love to risk it's documents on an infrastructure not fully under it's control or that not at least can't be held fully reliable for the storage of the document. Of course within companies and institutions the distribution and redundancy of data is clearly wanted and today already done (e.g. RAID systems etc.) - so the risk to loose a document is something that the solutions already available today can handle quite good. (just talk with some storage vendors - like I had to do during the last months - and you will find that they are doing quite a good job at that.) Probably I missed something important, so please help me a little bit to understand. Tobias Chair of LTANS > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 01, 2004 17:47 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Ulrich: > > To solve the problem, if the person who feels that the > evidence may be needed (e.g., the client) can obtain a time > stamp, get all appropriate trust anchors, certificates, > revocation information attached, split n of m and submit to > the archives. Then, when the evidence needs to > reconstructed, n TAAs can supply their shares to construct > the original with all the signatures and time stamps. > > Why would that not be simple or meet the German Law? > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Ulrich Pordesch > Sent: Thursday, April 01, 2004 9:29 AM > To: ietf-ltans@imc.org > Subject: AW: Alternatives for Long Term Archiving > > > > Santosh: > > Getting a proof of existence of data at a certain time in the > past using (sequences/ chains of) time-stamps is an essential > part of the service and the reason, why we required this as > "must requirement" in requirements draft. Getting trust > relating to time- of existance by statements of a new kind of > trusted authorities (TAAs) is a completly other kind of > trust. This solution is not sufficient to conserve value of > evidence of signed documents in court, because there is no > law (in germany but also anywhere else, as I know), which > recognizes trusted archives like regulated/trusted time-stamp > authorities. I think we will never get such law, because > complex archive systems can not be evaluated to the same > degree as simple time-stamping-machines. Statements of TAAs, > provided by protocol, may be an additional useful features, > if there are users who need it. > > > Ulrich > > > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im > Auftrag von Santosh Chokhani > Gesendet: Donnerstag, 1. April 2004 15:32 > An: ietf-ltans@imc.org > Betreff: RE: Alternatives for Long Term Archiving > > > > Brian: > > I do not think trusted archive requires providing date and > time service. > > If the trusted archive requirement is to attest to the date > of any document, then each TAA may put a date time stamp or > get date-time stamp from an authority and add proper trust > anchors, certificates and revocation information. > > n of m only helps with integrity, availability, and provides > protection against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each > TAA simply > states (and signs) when the document existed and when n TAAs > state the > same date, this date is correct and trustworthy? > > Regards, > Brian > > > > > From owner-ietf-ltans Thu Apr 1 16:29:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320TAEs042451; Thu, 1 Apr 2004 16:29: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 i320TA4Y042450; Thu, 1 Apr 2004 16:29:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320T9Rn042439 for ; Thu, 1 Apr 2004 16:29:09 -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-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i320T8SP016530 for ; Thu, 1 Apr 2004 16:29:08 -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 i320T53k005375 for ; Thu, 1 Apr 2004 16:29:05 -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 <0HVI00030PCHOH@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Thu, 01 Apr 2004 16:29:05 -0800 (PST) Date: Thu, 01 Apr 2004 16:28:54 -0800 From: Larry Masinter Subject: (Long) comments on requirements document To: ietf-ltans@imc.org Message-id: <0HVI00031PCHOH@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: AcQYIMBzyKsLVCNSRL6hENsO4L9NBAACfZbwAAehtKA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me try to make some concrete suggestions for updates to draft-ietf-ltans-reqs-00.txt to remove from it the assumption or requirement that a long-term archive MUST use hash algorithms for time stamps or encryption for privacy. My goal is not to require non-hash-based time stamps, but rather, not to exclude it from the requirements document. I think we can be more productive than continuing the discussion in the abstract, since I don't think the abstract discussion is converging, and we're having one of these talking-past-each-other conversations ("I don't think this solution will work", "But the problem is important and we need a solution now") I started to review the document just for places where it unnecessarily made assumptions, but wound up reviewing more generally. I'm sorry for the length. I also will cheerfully admit that I might be completely wrong, have misunderstood or misinterpreted the current document, and so I hope you will take my comments as questions or at least constructive. ============================= CURRENT: A long-term archive service aids in the preservation of data over long periods of time. In particular, it periodically performs activities to preserve the non-repudiation of existence and integrity as well as ensuring the availability of data. Instead of "In particular, it periodically performs...", say "For example, it might periodically perform...". This leaves the door open for long-term archive services that do not need to "periodically" perform activities. ============================== CURRENT: A variety of technical and operational means are required to achieve this goal and technical issues beyond cryptography, such as storage media lifetime, disaster planning, changes in processing or software technology, etc., as well as legal issues must be addressed. I suggest: NEW: A variety of technical and operational means are required to achieve this goal. A solution must address issues such as storage media lifetime, disaster planning, changes in processing and software technology and legal issues, in addition to technical issues of cryptography. This is just wordsmithing. It may be that you can accomplish long-term archiving without 'cryptography' per se (well, secret sharing is described in 'Applied Cryptography' and 'Current Cryptology' but still). ============================== About digital signatures: CURRENT: 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 past the cryptoperiod of the signature private key, is a candidate for preservation using a long-term archive service. I propose: NEW: A long-term archive or notary service may be used to validate the existence of documents, or assertions of agreements, e.g., originally asserted with digital signatures, at times in the future well beyond the validity period of the certificate used originally for signing the document, or even the validity of the algorithms available for digital signatures or encryption. I believe the verification is not of the "digital signature" per se, but an assertion that the parties involved signed the document at the date claimed. So it isn't the "signature" that needs to be verified, it's the agreement. The signature is a way of communicating the agreement. ====================== On requirements: OLD: Operational requirements, such as storage media concerns, individual legal requirements and questions dealing with accounting and billing techniques are not addressed by this document. My concern here is that we might not be able to get away with not addressing other requirements; are they operational or technical? Issues with the long-term interpretability of file formats, with metadata, and with identity of principals. I think that we need to address what assumptions we're making about these things, e.g., that the documents are represented in formats that the originator believes will be interpretable during the lifetime of the signature, that identity of roles (people and organizations) are meaningful over the same lifetime. I think there is a problem with identity in the same time-scale as we're concerned with in long-term archives. AT&T 20 years ago isn't the same organization as AT&T today. ========================================== Originator: Role (person or process) who produces, and possibly signs, a data object that is to be archived. The Originator does not necessarily generate or request generation of an evidence record for the data. Do you want to use the term 'principal' here, since it is standard, rather than 'Role', and give a reference? Again, I think there may be a problem if the lifetime of being able to determine identity isn't as long as the lifetime required for archival. ============================================= 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). I think there is a problem, in that this definition combines the function (asserting that a document existed or had been asserted at a given point in time) and the mechanism for accomplishing that function (e.g., RFC 3161). I'm not sure RFC 3161 gives a good structure for timestamps, for timestamps that have to survive for as long as this document claims is its requirement. Also, "Timestamp Authority (TSA)" isn't define in the glossary, even though it is referenced. So I think that it is necessary to separate out the notion of an "assertion of existence of a document or statement/agreement" from the electronic timestamp mechanism referenced. ================================================== User: Role (person or process), who submit data objects for archiving, request archive packages and verify the evidence of an archived data object using the associated evidence record, optionally including the verification of any signatures within the archived data object itself. I think it's confusing to call this "User", perhaps "Submitter"? There are a lot of users running around. =================================================== 3.1.3 Preservation of evidence for signed or timestamped data Archived data objects may contain digital signatures or time stamps to be able to prove the origin and the time of existence of these objects and signatures. In the course of time the value of evidence of these signatures or timestamps can decrease or can get lost for many reasons: I'm not sure that the requirement is to 'preserve the evidence'. Rather, the requirement is to be able to credibly assert in the future something that is currently asserted. The future assertion might or might not use a similar mechanism as the current assertion. So you might accomplish future assertion of timestamp by somehow "renewing" a timestamp, but you might also accomplish it by having several trusted organizations willing to assert that, according to their records, the document was received at a particular time, with no use of tree-hash-based timestamps. In order to avoid problems in case of disputes in the future it is necessary to preserve a digitally signed document, as well as certificates, revocations lists, OCSP responses and time stamps, even if these elements are not included in the signed document itself. I don't believe this statement. Certainly keeping all of these things won't "avoid problems" in the case of disputes. And keeping these things might not be necessary. By periodically inspecting and acting upon stored evidence, it is possible to generate a cryptographically protected history for a data item that contains no periods of time during which an algorithm was thought to be weak, an authority thought to be compromised, etc. I don't believe this sentence either, or at least, not that it is true without other conditions. After all, there is no way to predict when an algorithm might suddenly be 'thought to be weak'. So it's hard to imagine a practice that would guarantee such a history. Perhaps there is an operational practice which would ensure that it would be very unlikely there would be no such periods, but my impression was that you were going to leave such operational practices "out of scope". ===================================== - The Long-term Archive Service is to store archived data objects over a long, optionally undefined, period of time. I think rather than "optionally undefined" you might mean "arbitrarily long"? Typically in records management, there is a well-defined retention schedule. ================================ - The Long-term Archive Service provides material needed to prove the existence and integrity of data objects for users as well as in court. These means especially are time-stamps, periodically generated during the archiving period of the data objects. Additional verification data, to verify these time-stamps after a long period of time (CRLS, OCSP responses and certificates) need also be provided Again, I don't think that the particular mechanism alluded to here -- of periodically generated time stamps -- should be part of the requirements. It may be part of a proposed solution, but the requirement is to credibly be able to verify the existence of the document at its original communication date. ============================================= 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). This doesn't read right. It is to be designed to not solve these problems? Or it is not necessary to solve all such problems? I think this section is alluding to some problems that you want to rule out of scope. Of course, the problem here is the confounding of the problem statement with one proposed mechanism for solving the problem. I think the point of the section is that the archive service needs to be aware of the assertions that it is being called upon to assert in the future, and that embedded signatures need to be recognized somehow. I don't see any reason why an archive service SHOULDN'T be able to provide assurance about embedded signatures as well as external ones, except that the location of the signature needs to be clear. I don't see why SCVP or DVCS (references?) are referenced here. =========================================== - Archive service assuring long-term Non-Repudiation Long-term Archive Service stores data objects like signed or unsigned documents for identified and authenticated users. It generates time stamps for these data objects and obtains necessary verification data over a given time or until a request of deletion by this authorized user is sent. Again, I'm concerned about long-term identity of what might constitute an "authorized user". This also seems to bake in the notion that one (and only one) user is required to authorize a deletion. With contractual data, for example, you might expect that a third-party archive service might offer to only delete records where the deletion is requested by both parties, not just one. This can't be easily simulated with a single role-based user authorization model. And this 'requirement' seems to bake in the 'periodic replenishment of timestamps' mechanism unnecessarily. ================================================ - Pure long-term non-repudiation Service Long-term Archive Service only guarantees non-repudiation of existence of data. It periodically generates time stamps and obtains additional verification data for a given period of time. It stores data objects (e.g. documents, but also relevant parts of documents containing signatures) locally only for the purpose of non- repudiation. It is not a document-archive for users and therefore does not provide retrieval of documents and no deletion of data objects. Therefore it does not need any access control. I'm not sure that access control is unneeded even for pure non-repudiation services, if it is possible to retrieve the metadata, or to search for documents. I think "it stores data objects " is not proscriptive, but is intended as a possibility. I *think* you're trying to define a long-term notary service with this scenario -- a service that asserts, over the long term, the dated assertion at a particular time. I'm not sure why you aren't using the term, though. ===================================== 3.3 Instances and overall architecture Is this section meant to be an example, or actually proscriptive? Is this just saying how you MIGHT build an archive or notary service, or are you requiring them all to work this way? The text sort of sounds like you intend it to be normative, and I'm not sure why this belongs in a requirements document. Users transfer the data objects that shall be archived at the Trusted Archive Authority (TAA) using their application of choice. I'm confused -- it sounds like you're imagining that there is a user-determined transfer protocol for actually uploading the data, and that the archive protocol then is applied, after the fact, to the previously transferred data. Is this what you meant? ================================ Long-term Archive Service may allow for relays using Long-term Archive Protocol. The use of external archive services may be also possible. But Relaying must be transparent to the client. Here you're allowing the TAA to relay the request to other archive services (1 out of 2) and possibly to multiple services (K out of N). So this architecture might be consistent with K out of N archiving after all, without too many changes. ============================ A TAA may be a server within an enterprise network communicating with local archive servers and other applications or an external service accessible via internet. Is this an issue of firewalls, trust and organizational control, or some other factors? This is the first time the document alludes to the possible organizational relationship between the various parties involved, but I think the relationship is crucial, an important part of the analysis of the validity of long-term archives, and probably needs to be expanded elsewhere. If an organization is charged with archiving its own documents, then it could assert that a contract was valid even if it wasn't. Doesn't the long-term threat model for document forgery require organizational independence of the TAA/TSA that is doing revalidation of signatures? ================================= 4. Long-term Archive Service functional and quality requirements ... - Generate, store and maintain evidence records (i.e. by periodically obtaining timestamps) for data objects submitted for preservation; I think the requirement is to be able to provide, over the lifetime of the record, assurances that were originally obtained through techniques such as timestamps and digital signatures. I don't think there is a requirement for periodically obtaining timestamps. ======================================== - Be able to provide an acknowledgement that a data object existed at a certain time, as an alternative, if user is not able to interpret the evidence record; I think this is a key to a longer discussion about how to provide for long-term interpretability of records, though providing records in standard archivable formats, and providing, at the time of archiving, conversions of the record to multiple formats, etc. ======================================== A long-term archive service must be able to work efficiently even for large amounts of archived data objects. In order to limit expenses, costs and dependency on high performance, time-stamp services, the number of necessary time stamps MUST be minimized and a time stamp should include a large number of signatures and documents; This is pretty strong for a MUST (and RFC 2119 is probably not appropriate here anyway). I don't understand why this is here at all I guess this is assuming some cost model for timestamp services? What is the use case where this matters? =========================== Necessity to access stored archived data object SHOULD be minimized. It SHOULD only be necessary access to the archived data objects only if the archived data objects are requested by users or if applied hash algorithms become insecure. This comment isn't just here, but I just thought of it. There's some assumption here about identifiers for records, or searching for records, or record locators, that isn't discussed in this draft. (I remember some conversation about this at the meeting, though.) How are records identified? Are the record identifiers globally unique? Use the hash of the document for its identifier, for example? Who has access to the record? Interestingly, even if one-way hash algorithms are cracked (someone finds a way of generating another document with different content with the same hash), it's still unlikely that you could _discover_ a valid document hash without knowing anything. So you might provide access control for documents by using document hashes as the key for accessing the document. I don't understand why it is important to minimize the access to stored archived data, as a protocol requirement. This sounds like it's an operational requirement for a well-implemented TAA service, but there are other operational and implementation requirements that aren't mentioned here. ("It should work. It should run on commercially available platforms. It shouldn't have any security holes. It shouldn't erase its disk periodically."). ========================================= The data structure for the evidence record itself should have the following properties: - It MUST be possible to include all timestamps necessary to verify the existence of the archived data objects. .... Again, if there are ways of providing evidence for the existence of an assertion or signature or record at a given point in time, then this requirement would be empty. ============================== - It SHOULD be possible to provide evidence for groups of archived data objects. For example, it should be possible to archive a document file and a signature file together such that they get the same evidence record. - Where groups of data objects are submitted, non-repudiation proof MUST still be available for each archived data object separately. Is this a 'record' requirement or a protocol requirement? Why is this a requirement? The obvious use cases given in the document ("signed contracts or agreements, wills, property deeds, ...") don't have this kind of performance requirement. What are the uses for "CRLs and timestamps over any type of data" that would have this requirement? ======================================= - It SHOULD be possible to create timestamps without the need to access the archived data objects. The access to the archived data SHOULD only be necessary if the security suitability of employed hash algorithm is menaced. Why is this a requirement? Is this a performance requirement? An operational one? Just something you think might be a good idea? How often are timestamps created that this is important? ==================================== - It SHOULD be possible to package all evidence along with the archived data objects in a single data item or to package evidence and archived data objects in separate items. I think there is some assumption about 'evidence records' and their use that might be unclear. Evidence records are used to send assertions TO the archive service at the time the document is archived. And it might -- or might not -- be used to supply evidence when there is a dispute. Is it a requirement that the same data structure be used for both? ======================================== Standardization of a protocol for interactions with a Long-term Archive Service is desirable. The protocol should have the following properties: Again, here you say 'should' in front of a bunch of 'MUST's. I think probably the right thing to do is to get rid of the MUSTs (in some cases, and get rid of the requirement, in others). ============================================== - 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'm concerned about deletion, since a threat to a contract is to have one of the parties delete it. And I'm not sure of the value of deletion, or that it is actually possible, e.g., if the TAA backs up its disks and sends them offsite, is it possible to actually delete its records from its offsite backups? And I'm not sure 'submission of groups' is a MUST requirement. It sounds like a minor optimization. After all, the bulk of the protocol overhead is probably sending the data. ===================================== - The protocol MUST provide a response indicating successful submission or deletion of data. The acknowledgement of successful submission SHOULD permit a submitter to verify that the correct data was received by the service for preservation, e.g. the acknowledgement could include an index, a signature or a timestamp obtained for the archived data object. Shouldn't you always verify the correct data? I think that it's more important to provide for the converse: if there are any errors or difficulties with the request, the failure must be notified. Otherwise, the best you have is the archive service's guess that all went well. ================================ - The protocol MUST response an index to retrieve the archive package. It also should be possible to retrieve archive packages by using hash values of the archived data objects. Earlier you had it possible to get the data independent of the assertion. And "the hash value of the archived data object" is (as I said earlier) one way to get a handle on the document. But it's also problematic -- which hash? which handle? I think this mixes mechanism with requirement. When a package is archived, it gets a handle, and the protocol should allow for the retrieval of the package, assertions about the package, and pieces of the package. ============================================= - The protocol SHOULD support some basic Metadata (Mime-Type, key words, etc.), i.e. the client should be able to provide metadata along with the archived data to facilitate future search operations based on the metadata. Oh, this one is really problematic. First, allowing for search introduces lots of discovery attacks that might not be necessary. Why is this important? If the client wants to archive an index along with some documents, let them archive the index. On the other hand, metadata is crucial. Bits without understanding the interpretation of the bits aren't very useful. The question is whether you just need the content-type, or do you need all of the other content- MIME headers, e.g., content-language? For example, it would be useful to allow the possibility of multiple renderings of the same document in multiple formats, along with an assertion of their equivalence, for long-term document retention (e.g., XHTML, PDF/A, TIFF 6, Unicode text). =============================================== - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an error. - A Long-term Archive Service MUST provide an indication of the long-term archive policy under which the service operates. This is the first mention that I can find of 'archive policy'. What is this, how does a client request one, what are servers allowed not to implement and still be compliant? (There's no point in defining a standard for behavior of non-compliant participants, since they're already non-compliant!). How does a server 'indicate' a policy? ======================================== - The protocol MUST prevent replay attacks. It's odd that this is mentioned without any other attacks being mentioned. And it's not clear what kind of "replay attack" is being asked to be prevented. All? Even ones on unrelated services? ========================================= - The protocol SHOULD permit encryption of data before submission in such a way that there exists non-repudiation evidence for the unencrypted data. So this is assuming that communication between requestor and service isn't over a TLS? I'm not sure why this is a requirement. ===================================== - The protocol SHOULD provide means of associating submitted data objects with previously submitted data objects, i.e. to facilitate retrieval based on aggregation of objects over time. This is the first mention of "associating data". Does this mean that access to the first data object also gives you access to the second? Or just vice versa? How is the association noted? What is this used for? I don't see this in the use cases for contracts, land deeds, etc. ==================================== - The protocol SHOULD provide means for specifying a point in time at which an archived data object need no longer be preserved. It also should be possible to extend the archiving period. Extending the archiving period may also be problematic. Who is authorized to extend the archiving period for an agreement that was previously agreed would expire? ============================================== - The format for the acknowledgements MUST allow the identification of the archiving provider. - The format for the acknowledgements MUST allow (at least from the creating archiving provider) the identification of the participating client. see comments above about identity. Perhaps this is just metadata about the archived data rather than identity? ======================================== - Responses must uniquely reference corresponding requests This seems out of the blue. Any protocol with requests and responses needs some way of linking them, but it might be temporarily rather than through identifiers. ================================ - It should be possible to sign requests and responses. It is recommended that in particular acknowledgements are signed. Why is this a requirement? There is some security requirement for authentication of the participants in the protocol and their authorization to use the protocol and to be identified later, but why is it important to sign the requests and responses rather than, say, using TLS for the communication? ====================== - Deletion must be authenticated. See comments above about deletion. Deletion must be authorized, and authorization policy for Deletion must be observed. ============================== - The archive service MUST be able to provide evidence about the policies that have been used at any time I'm not sure how it is possible to supply evidence. This is very hard, in general, to provide evidence for policies that were used, especially if the policies are baked into the code or into various tables. And some of the policies are operational policies, not technical ones. ==================================== - The protocol SHOULD be as simple to use as possible. A quote attributed to Einstein: "Everything should be as simple as possible, but no simpler". Personally, I think that protocols are simple to use if they aren't new protocols. I wonder if the archival protocol could be implemented by using WebDAV over TLS with certain well-known dynamic properties identified for archival objects. ==================================== Means to enable accountability, access control, confidentiality of communication between applications and TAA need additional precautions (like SSL) that are outside the scope of these requirements. I think not. That is, there is a service requirement for those things, and there has to be some way of accomplishing them. In some cases, you're asking for things like signatures of requests which have only a transactional lifetime (of the request), and might be accomplished other ways. ======================================= 7. Security Considerations This section isn't really about 'security considerations' in the typical sense that IETF requires. What you're supposed to do is outline the threats a long term archive or notary service. You've written some things that also need to be considered, but probably as protocol requirements. ================================================= Where non-standard formats are used or proprietary processing is employed, verification of signatures on or in archived data may require the availability of specific applications or tools. I think this is really a matter of whether or not the long-term archive or notary service relies on these things at all. An archive service cannot assert the validity of a signature (at the time of submission) if it can't interpret the signature. And the believability of the assertion cannot be better than the believability of the signature and its associated software. =================================================== Certificate revocation could retroactively invalidate previously verified signatures. Measures may be implemented to support such claims by an alleged signer, e.g. collection of revocation information after a grace period during which compromise can be reported or preservation of subsequent revocation information. This is some requirement on the archive service at the time of submission, isn't it? ======================================================== Access control mechanisms associated with data stored by a TAA should consider the lifespan of the data object. For example, the credentials of an entity that submitted data to an archive may not be available or valid when the data needs to be retrieved. Well, worse, the identity of the entity might not be clear after 30 years. ======================================================== 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. This is completely out of place. It's one idea for an operational practice which might or might be credible for later asserting validity. And if you have 'write-once media', then deletion isn't possible! ================== Larry -- http://larry.masinter.net From owner-ietf-ltans Thu Apr 1 20:14:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324EBe8059328; Thu, 1 Apr 2004 20:14: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 i324EB4e059327; Thu, 1 Apr 2004 20:14:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324EAqu059321 for ; Thu, 1 Apr 2004 20:14:10 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust202.tnt36.dfw9.da.uu.net ([67.234.81.202] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B9G40-0003dm-00; Thu, 01 Apr 2004 23:13:53 -0500 Message-ID: <406D02C6.655CF8B4@ix.netcom.com> Date: Thu, 01 Apr 2004 22:05:59 -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: Alternatives for Long Term Archiving References: <003e01c417ed$b7e2ab30$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: Santosh and all, I can't invision how a trusted archive be devoid of an accurate time stamp... Santosh Chokhani wrote: > Brian: > > I do not think trusted archive requires providing date and time service. > > If the trusted archive requirement is to attest to the date of any document, > then each TAA may put a date time stamp or get date-time stamp from an > authority and add proper trust anchors, certificates and revocation > information. > > n of m only helps with integrity, availability, and provides protection > against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each TAA simply > states (and signs) when the document existed and when n TAAs state the > same date, this date is correct and trustworthy? > > Regards, > Brian 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 Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-ietf-ltans Fri Apr 2 01:05:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3295nTY036709; Fri, 2 Apr 2004 01:05:49 -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 i3295ni5036708; Fri, 2 Apr 2004 01:05:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from prometheus.terms.cz (prometheus.terms.cz [81.90.160.70]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3295lBx036639 for ; Fri, 2 Apr 2004 01:05:48 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 ([81.90.165.93]) by prometheus.terms.cz (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3294lDe010291 for ; Fri, 2 Apr 2004 11:04:54 +0200 From: To: Subject: RE: Our objections to draft ERS Date: Fri, 2 Apr 2004 11:04:39 +0200 Message-ID: <000601c41891$8be4f8e0$6402a8c0@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C418A2.4F6DC8E0" 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 In-reply-to: <406BDE1E.3040401@sit.fraunhofer.de> 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_0007_01C418A2.4F6DC8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, > In your example, the whole CMS object, as in RFC 3126, should be > given to the TAA for archiving. I have one quite elementary question to verify if I understand well. See the following example: Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid. 2.4.2004 6.5.2007 2020 -+----------------------+--------------------------------------+-- <------------CMS validity-------------> <-----------------ERS validity----------->>> Libor ------=_NextPart_000_0007_01C418A2.4F6DC8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zpráva

Brian,

> In your = example, the=20 whole CMS object, as in RFC 3126, should be
> given to the TAA for = archiving.

I have one quite elementary question to verify if I = understand=20 well. See the following example:

Today 2nd April 2004, I = digitally sign=20 the digital contract and I do not have the TAA at my disposal at = present.=20 My certificate for the digital signature verification will expire 30th = April=20 2004. When signing acc. to RFC-3126, I will add the non-signed attribute = Electronic Signature Timestamp, containing the time stamp acc. to = RFC-3161 with=20 the TSA certificate (expire date 31st Dec. 2008), to the CMS message, = containg=20 the digitally signed contract.

In 2007, I will start the TAA. In = 1st May=20 2007, I will archive my agreement (CMS message) into this TAA. This will = create=20 the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This = ArchiveTimeStamp is issued with the issue date of the following root = hast-tree -=20 let's say 6th May 2007.

In 2020, I will submit this contract = to the=20 court as a proof. I am obliged to prove the non-repudiation. This means, = I will=20 obtain the ERS from the TAA, which can prove, that the whole CMS message = has not=20 been changed from the first issuing of the  ArchiveTimeStamp in 6th = May=20 2007 up to present.

Now, the CMS message will be verified the = same way it=20 would have been done in 6th May 2007. It means, I will verify that the = time=20 stamp in the non-signed attribute had a valid TSA digital signature in = 6th May=20 2007. The time stamp was issued in 2nd April 2004. I will verify if my = personal=20 signature certificate was valid in 2nd April 2004..... Result: digital = contract=20 is valid.

 2.4.2004         =       6.5.2007     = ;            =             &= nbsp; 2020
-+----------------------+--------------------------------------+-- <------------CMS=20 validity------------->
       &n= bsp;           &nb= sp;    <-----------------ERS=20 validity----------->>>

   
Libor

 =20

------=_NextPart_000_0007_01C418A2.4F6DC8E0-- From owner-ietf-ltans Fri Apr 2 04:36:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32CakZg070505; Fri, 2 Apr 2004 04:36: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 i32Cak6K070504; Fri, 2 Apr 2004 04:36: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 i32CajFP070498 for ; Fri, 2 Apr 2004 04:36:45 -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 i32CakAt028939 for ; Fri, 2 Apr 2004 07:36:46 -0500 From: "Santosh Chokhani" To: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Date: Fri, 2 Apr 2004 08:36:46 -0400 Message-Id: <20040402123646.M66414@orionsec.com> In-Reply-To: <406D02C6.655CF8B4@ix.netcom.com> References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (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: The idea is not that a rime stamp is not needed. The client can obtain a time stamp. Each TAA can obtain or assert a time stamp. The assertion by TAA could be in the form of simply time or 3161 compliant time stamp. On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > Santosh and all, > > I can't invision how a trusted archive be devoid of an accurate > time stamp... > > Santosh Chokhani wrote: > > > Brian: > > > > I do not think trusted archive requires providing date and time service. > > > > If the trusted archive requirement is to attest to the date of any document, > > then each TAA may put a date time stamp or get date-time stamp from an > > authority and add proper trust anchors, certificates and revocation > > information. > > > > n of m only helps with integrity, availability, and provides protection > > against perceived collusion threat. > > > > -----Original Message----- > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > Sent: Wednesday, March 31, 2004 6:41 AM > > To: Larry Masinter > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > Subject: Re: Alternatives for Long Term Archiving > > > > Larry or Santosh, > > > > Could someone tell me how the n of m scheme replaces the need of an > > (accredited) time-stamping or time-marking service, when the date of > > document existance must be proved? Is it assumed that each TAA simply > > states (and signs) when the document existed and when n TAAs state the > > same date, this date is correct and trustworthy? > > > > Regards, > > Brian > > 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 > Registered Email addr with the USPS > Contact Number: 214-244-4827 From owner-ietf-ltans Fri Apr 2 16:53:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i330rXcf025562; Fri, 2 Apr 2004 16:53:33 -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 i330rXVO025561; Fri, 2 Apr 2004 16:53:33 -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 i330rXre025555 for ; Fri, 2 Apr 2004 16:53:33 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust53.tnt59.dfw5.da.uu.net ([67.203.43.53] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B9ZPg-0006WA-00; Fri, 02 Apr 2004 19:53:33 -0500 Message-ID: <406E254A.4F3988D2@ix.netcom.com> Date: Fri, 02 Apr 2004 18:45:35 -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: Alternatives for Long Term Archiving References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> <20040402123646.M66414@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: > > The idea is not that a rime stamp is not needed. The client can obtain a > time stamp. This does not jive with your comments below. However that aside, obtaining a time stamp and one provided for at the time the archive is created or the record is or was created and/or also archived, is not the same as a obtaining one... > Each TAA can obtain or assert a time stamp. The assertion by > TAA could be in the form of simply time or 3161 compliant time stamp. Again asserting and/or obtaining a time stamp is not the same as one created at the time the record/records or archive is created... > > > On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > > Santosh and all, > > > > I can't invision how a trusted archive be devoid of an accurate > > time stamp... > > > > Santosh Chokhani wrote: > > > > > Brian: > > > > > > I do not think trusted archive requires providing date and time service. > > > > > > If the trusted archive requirement is to attest to the date of any > document, > > > then each TAA may put a date time stamp or get date-time stamp from an > > > authority and add proper trust anchors, certificates and revocation > > > information. > > > > > > n of m only helps with integrity, availability, and provides protection > > > against perceived collusion threat. > > > > > > -----Original Message----- > > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > > Sent: Wednesday, March 31, 2004 6:41 AM > > > To: Larry Masinter > > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > > Subject: Re: Alternatives for Long Term Archiving > > > > > > Larry or Santosh, > > > > > > Could someone tell me how the n of m scheme replaces the need of an > > > (accredited) time-stamping or time-marking service, when the date of > > > document existance must be proved? Is it assumed that each TAA simply > > > states (and signs) when the document existed and when n TAAs state the > > > same date, this date is correct and trustworthy? > > > > > > Regards, > > > Brian > > > > 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 > > Registered Email addr with the USPS > > 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 Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-ietf-ltans Fri Apr 2 19:54:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i333sDSn036078; Fri, 2 Apr 2004 19:54:13 -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 i333sDhV036077; Fri, 2 Apr 2004 19:54:13 -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 i333sCFg036071 for ; Fri, 2 Apr 2004 19:54:13 -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 i333sJAt011822 for ; Fri, 2 Apr 2004 22:54:19 -0500 From: "Santosh Chokhani" To: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Date: Fri, 2 Apr 2004 23:54:19 -0400 Message-Id: <20040403035419.M84002@orionsec.com> In-Reply-To: <406E254A.4F3988D2@ix.netcom.com> References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> <20040402123646.M66414@orionsec.com> <406E254A.4F3988D2@ix.netcom.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (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: What does not jive? Why can the client and/or the TAAs apply or obtain time stamp. What is the reason for that not being godo enough? On Fri, 02 Apr 2004 18:45:35 -0800, Jeff Williams wrote > Santosh and all, > > Santosh Chokhani wrote: > > > Jeff: > > > > The idea is not that a rime stamp is not needed. The client can obtain a > > time stamp. > > This does not jive with your comments below. However that aside, > obtaining a time stamp and one provided for at the time the archive > is created or the record is or was created and/or also archived, > is not the same as a obtaining one... > > > Each TAA can obtain or assert a time stamp. The assertion by > > TAA could be in the form of simply time or 3161 compliant time stamp. > > Again asserting and/or obtaining a time stamp is not the same as > one created at the time the record/records or archive is created... > > > > > > > On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > > > Santosh and all, > > > > > > I can't invision how a trusted archive be devoid of an accurate > > > time stamp... > > > > > > Santosh Chokhani wrote: > > > > > > > Brian: > > > > > > > > I do not think trusted archive requires providing date and time service. > > > > > > > > If the trusted archive requirement is to attest to the date of any > > document, > > > > then each TAA may put a date time stamp or get date-time stamp from an > > > > authority and add proper trust anchors, certificates and revocation > > > > information. > > > > > > > > n of m only helps with integrity, availability, and provides protection > > > > against perceived collusion threat. > > > > > > > > -----Original Message----- > > > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > > > Sent: Wednesday, March 31, 2004 6:41 AM > > > > To: Larry Masinter > > > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > > > Subject: Re: Alternatives for Long Term Archiving > > > > > > > > Larry or Santosh, > > > > > > > > Could someone tell me how the n of m scheme replaces the need of an > > > > (accredited) time-stamping or time-marking service, when the date of > > > > document existance must be proved? Is it assumed that each TAA simply > > > > states (and signs) when the document existed and when n TAAs state the > > > > same date, this date is correct and trustworthy? > > > > > > > > Regards, > > > > Brian > > > > > > 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 > > > Registered Email addr with the USPS > > > 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 > Registered Email addr with the USPS > Contact Number: 214-244-4827 From owner-ietf-ltans Mon Apr 5 02:02:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35928g4046113; Mon, 5 Apr 2004 02:02:08 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35928L1046112; Mon, 5 Apr 2004 02:02:08 -0700 (PDT) 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 i35926qJ046093 for ; Mon, 5 Apr 2004 02:02:07 -0700 (PDT) (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 i35925gu013775 for ; Mon, 5 Apr 2004 11:02:05 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ7F7K>; Mon, 5 Apr 2004 11:04:18 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D549E@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Subject: FW: why we need sequences of timestamps Date: Mon, 5 Apr 2004 11:04:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41AEC.F0A00740" 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_01C41AEC.F0A00740 Content-Type: text/plain Hello LTANS, somehow a message from Uli got lost. :-( So he asked me to forward it to the community. Tobias Ps.: I will try to find out what went wrong. -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de] Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli ------_=_NextPart_001_01C41AEC.F0A00740 Content-Type: text/html Message
Hello LTANS,
 
somehow a message from Uli got lost. :-(
So he asked me to forward it to the community.
 
Tobias
 
Ps.: I will try to find out what went wrong.
 
 
-----Original Message-----
From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, 2004 13:07
To: ietf-ltans@imc.org
Subject: why we need sequences of timestamps

Santosh

envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report.  In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation.  This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024,

which became insecure in the year 2007.  Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature.

The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge?  Which method should it adopt?  How can LTANS help the hospital?

Case 1
------
The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services.

ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps.  The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority.  The court verifies this change of time-stamps, namely the Evidence Record.  Because the

time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised.  Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so.

n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case.  The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000.  This is hardly credible.  The judge will send an expert to the hospital, who will search through the hospital's archive

and protocols.  This can be very expensive and the chance of success is at best poor.

Case 2
------
The hospital uses an external service provider, a TAA, let's call it Uli-TAA.

ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA.  There is no difference in the court case.  It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged.

n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000.  Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages.  As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used.  Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random

document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it).

ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000.  The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions.  I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the

judge will actually make such a ruling or not.

n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000.  It could be that the judge is convinced.  But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must

prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that.


I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court.  This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs).  There is no foundation for the distribution of documents and the trustworthiness of TAAs.  One

could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner.

Where one could make further considerations is the combination of both methods.  Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal.

Uli

------_=_NextPart_001_01C41AEC.F0A00740-- From owner-ietf-ltans Mon Apr 5 02:19:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i359JvAu053091; Mon, 5 Apr 2004 02:19:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i359JvBo053090; Mon, 5 Apr 2004 02:19:57 -0700 (PDT) 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 i359JtRX053067 for ; Mon, 5 Apr 2004 02:19:56 -0700 (PDT) (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 i359JsGj014431 for ; Mon, 5 Apr 2004 11:19:54 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Apr 2004 11:22:00 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54A0@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: Problem with mailing-list: some emails got lost :-( Date: Mon, 5 Apr 2004 11:21:54 +0200 Importance: high X-Priority: 1 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: Dear all, There seems to be some problem with the mailing-list. Some emails have not been transmitted. I'm tracking the problem. Until then when you send emails to the list please take a look whether it has really been transmitted - as you are also part of the mailing-list you should receive one copy of your own email too. If not, please report the error to me. Regards Tobias Chair LTANS From owner-ietf-ltans Mon Apr 5 03:17:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35AHPis059756; Mon, 5 Apr 2004 03:17:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35AHP7d059755; Mon, 5 Apr 2004 03:17:25 -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.11/8.12.8) with ESMTP id i35AHNee059747 for ; Mon, 5 Apr 2004 03:17:24 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i35AHIN21648; Mon, 5 Apr 2004 12:17:18 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 5 Apr 2004 12:17:18 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i35AHHA13609; Mon, 5 Apr 2004 12:17:17 +0200 (MEST) Date: Mon, 5 Apr 2004 12:17:17 +0200 (MEST) From: Peter Sylvester Message-Id: <200404051017.i35AHHA13609@chandon.edelweb.fr> To: ietf-ltans@imc.org, tobias.gondrom@ixos.de Subject: Re: FW: why we need sequences of timestamps X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The signature has become worthless. It is only of value, if it is provable > that it existed before 2007. What can the hospital do to be able to convince > a judge? Which method should it adopt? How can LTANS help the hospital? > An archive system that answers to a client (the hosptal) that is has taken the responsiblity of the data at some indicated time. When the client store the data, the inspect the answer and check whether the time is close to current. An archive server can link together all attestations and one can require that all indicated dates are conformant to the linking. In this way, a server cannot create an attestation that is earlier than the last created one. An auditing entity or any other client can obtain 'pseudo attestations' from the archive server at regular times or totally randomly and verify that the times are acceptable. We are not in a situation where accurany of milliseconds is required, just days. From owner-ietf-ltans Mon Apr 5 04:45:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35BjLeC067130; Mon, 5 Apr 2004 04:45:21 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35BjLWs067129; Mon, 5 Apr 2004 04:45:21 -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.11/8.12.8) with ESMTP id i35BjK91067122 for ; Mon, 5 Apr 2004 04:45:20 -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 i35BjKAt023817 for ; Mon, 5 Apr 2004 07:45:20 -0400 Message-Id: <200404051145.i35BjKAt023817@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: why we need sequences of timestamps Date: Mon, 5 Apr 2004 07:45:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C41AE1.F279F860" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQa7rjoZ8is4OJQSKaEP7AprKZTgQAD4Jsg In-Reply-To: <077097E85A6BD3119E910800062786A9094D549E@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: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C41AE1.F279F860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Uli, I don't think using 1-of-1 scenarios is a good basis for comparing the two approaches. In any case, why it is necessary to view this as an ERS vs. n-of-m decision? n-of-m could be used in conjunction with ERS to provide data confidentiality. Combining n-of-m with a keyless timestamp scheme could be a nice solution. What about the patient's preservation of evidence? It may be difficult for the patient to manage encryption keys that enable confidentiality of the patient's medical data stored in a commercial archive. I doubt the patient would trust the hospital to maintain all copies of the relevant data. Are there any results of the study you mentioned available online? Carl _____ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, April 05, 2004 5:04 AM To: 'ietf-ltans@imc.org' Subject: FW: why we need sequences of timestamps Hello LTANS, somehow a message from Uli got lost. :-( So he asked me to forward it to the community. Tobias Ps.: I will try to find out what went wrong. -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de] Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli ------=_NextPart_000_0000_01C41AE1.F279F860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Uli,
 
I don't think using 1-of-1 scenarios is a good = basis for=20 comparing the two approaches.  In any case, why it is necessary to = view=20 this as an ERS vs. n-of-m decision?  n-of-m could be used in = conjunction=20 with ERS to provide data confidentiality.  Combining n-of-m = with a=20 keyless timestamp scheme could be a nice solution. =20
 
What about the patient's preservation of = evidence?  It=20 may be difficult for the patient to manage encryption keys that enable=20 confidentiality of the patient's medical data stored in = a commercial=20 archive.  I doubt the patient would trust the hospital to maintain = all=20 copies of the relevant data. 
 
Are there any results of the study you = mentioned available=20 online? 
 
Carl

From: = owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias=20 Gondrom
Sent: Monday, April 05, 2004 5:04 AM
To:=20 'ietf-ltans@imc.org'
Subject: FW: why we need sequences of=20 timestamps

Hello LTANS,
 
somehow a message from Uli got lost.=20 :-(
So=20 he asked me to forward it to the community.
 
Tobias
 
Ps.:=20 I will try to find out what went wrong.
 
 
-----Original Message-----
From: = Ulrich pordesch=20 [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, = 2004=20 13:07
To: ietf-ltans@imc.org
Subject: why we need=20 sequences of timestamps

Santosh

envisage the following court case (we conducted such = cases=20 last fall in an academic study, using real lawyers and judges - and = not only=20 with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. = Afterwards, he=20 wrote and signed an operation report.  In 2020, the patient sues = the=20 hospital for damages in the value of millions, because allegedly there = was an=20 error in the operation.  This alleged error then lead to her = later=20 disability. Let us assume that the doctor's signature used the = algorithm=20 RSA-1024,

which became insecure in the year 2007.  = Furthermore, in=20 2020, signatures created with such a weak key can be easily forged. = Therefore,=20 at the time of the legal suit, anyone could forge the document and=20 signature.

The signature has become worthless. It is only of = value, if it=20 is provable that it existed before 2007. What can the hospital do to = be able=20 to convince a judge?  Which method should it adopt?  How can = LTANS=20 help the hospital?

Case 1
------ =
The hospital does not want to use an external archive service = provider,=20 rather it wants to provide its own in-house archive = services.

ERS: By 2020, its archive system created a chain of, = e.g., 3=20 time-stamps.  The time-stamps were retrieved according to RFC = 3126 and=20 from a legal, accredited time-stamp authority.  The court = verifies this=20 change of time-stamps, namely the Evidence Record.  Because the=20

time-stamps were timely renewed, before the = algorithms became=20 weak (according to the yearly published list of trustworthy = algorithms) and=20 because the used TSA is demonstrably accredited and thus was = inspected, the=20 evidence will be recognised.  Actually, the court must recognise = it,=20 since there are such evidence rules, which virtually force it to do=20 so.

n-of-m: As far as I see it, Shamir's scheme does not = offer any=20 value for this case.  The hospital could, at best, present to the = court a=20 confirmation from its own system, that says the document was added to = its=20 system in 2000.  This is hardly credible.  The judge will = send an=20 expert to the hospital, who will search through the hospital's archive =

and protocols.  This can be very expensive and = the chance=20 of success is at best poor.

Case 2
------ =
The hospital uses an external service provider, a TAA, let's = call it=20 Uli-TAA.

ERS: The provider creates an evidence record, as = above, using=20 time-stamps from an accredited TSA.  There is no difference in = the court=20 case.  It will be recognised, that the archive time-stamps are = correct=20 and were timely generated and thus, the signature existed before 2007 = and=20 cannot have been forged.

n-of-m: The hospital can only present the = confirmation from=20 Uli-TAA, who asserts, that the document was archived in 2000.  = Since this=20 was not a legally recognised method, it is difficult to prove the=20 trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external = providers,=20 Uli-TAA and Santosh-TAA, and splits its messages.  As Antje = already said,=20 she is not overwelmed with enthusiasm for this, since her costs will = double.=20 However, let's assume that two providers are used.  Furthermore, = let's=20 also assume that it is provable that the two pieces belong together, = that is,=20 that random

document pieces cannot combined together (I have not = checked,=20 whether this requirement of the provability of uniqueness exists, but = let's=20 assume it).

ERS: Both TAAS offer their evidence records and it = will be=20 proven that both pieces were archived in 2000.  The fact that the = pieces=20 belong together and thus the original document existed in 2000 is part = of our=20 assumptions.  I must point out that for the case of the = splitting, there=20 is no binding rule for the judge, and we thus do not know, whether the =

judge will actually make such a ruling or = not.

n-of-m: The judge receives a confirmation from = Uli-TAA and=20 Santosh-TAA, that the document existed in their systems in 2000.  = It=20 could be that the judge is convinced.  But perhaps he will say: I = cannot=20 estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must=20

prove that Uli-TAA and Santosh-TAA were completely = trustworthy=20 in the last 20 years. Good luck with that.


I haven't even considered the special cases, where = Uli-TAA is=20 bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no = longer=20 exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides = us with a=20 high volume suitable, secure method that is provable in court.  = This is=20 true since the security of the method only relies on the accreditation = of the=20 algorithms and time-stamp machines (TSAs).  There is no = foundation for=20 the distribution of documents and the trustworthiness of TAAs.  = One=20

could define rules for which policies TAAs must = have, which=20 security measures they must use and how they will be regularly audited = etc.=20 However, I tend to rule out that one can achieve a comparable level of = security through this manner.

Where one could make further considerations is the = combination=20 of both methods.  Additional confirmations from the TAAs, saying = that=20 they had the document or piece, could be in specific cases an = alternative for=20 ERS, in particular, in the case that something went wrong during the=20 time-stamp renewal.

Uli

------=_NextPart_000_0000_01C41AE1.F279F860-- From owner-ietf-ltans Mon Apr 5 05:33:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35CXPTh070737; Mon, 5 Apr 2004 05:33:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35CXPm4070736; Mon, 5 Apr 2004 05:33:25 -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.11/8.12.8) with ESMTP id i35CXP5Q070730 for ; Mon, 5 Apr 2004 05:33:25 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i35CXQAt030150; Mon, 5 Apr 2004 08:33:26 -0400 From: "Santosh Chokhani" To: "'Tobias Gondrom'" , Subject: RE: why we need sequences of timestamps Date: Mon, 5 Apr 2004 08:33:26 -0400 Message-ID: <005101c41b0a$31752440$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C41AE8.AA638440" 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: <077097E85A6BD3119E910800062786A9094D549E@muc-mail5.ixos.de> 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_0052_01C41AE8.AA638440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to what Carl and Peter said, please note that n of m does = not prevent subscribers and the TAAs from obtaining time stamps or TAAs from asserting time. =20 If not n of m, at least two TAAs even in time stamp case are required in order to protect against a single TAA from intentionally corrupting the data. If a single TAA under the control of or as a contractor to an organization being sued had all the data, it can always manipulate prior trust anchors and messages. Thus, an independent source of trust = anchors may be required even in the case of 3161 time stamp refresh. =20 n of m does the same thing without requiring time stamp. =20 =20 -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, April 05, 2004 5:04 AM To: 'ietf-ltans@imc.org' Subject: FW: why we need sequences of timestamps Hello LTANS, =20 somehow a message from Uli got lost. :-( So he asked me to forward it to the community.=20 =20 Tobias =20 Ps.: I will try to find out what went wrong.=20 =20 =20 -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de]=20 Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh=20 envisage the following court case (we conducted such cases last fall in = an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and = signed an operation report. In 2020, the patient sues the hospital for damages = in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024,=20 which became insecure in the year 2007. Furthermore, in 2020, = signatures created with such a weak key can be easily forged. Therefore, at the = time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is = provable that it existed before 2007. What can the hospital do to be able to = convince a judge? Which method should it adopt? How can LTANS help the = hospital? Case 1=20 ------=20 The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 = time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the=20 time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, = the evidence will be recognised. Actually, the court must recognise it, = since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a = confirmation from its own system, that says the document was added to its system in = 2000. This is hardly credible. The judge will send an expert to the hospital, = who will search through the hospital's archive=20 and protocols. This can be very expensive and the chance of success is = at best poor.=20 Case 2=20 ------=20 The hospital uses an external service provider, a TAA, let's call it Uli-TAA.=20 ERS: The provider creates an evidence record, as above, using = time-stamps from an accredited TSA. There is no difference in the court case. It = will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have = been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness = of Uli-TAA during the last 20 years. Case 3=20 ------=20 The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and = splits its messages. As Antje already said, she is not overwelmed with = enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable = that the two pieces belong together, that is, that random=20 document pieces cannot combined together (I have not checked, whether = this requirement of the provability of uniqueness exists, but let's assume = it). ERS: Both TAAS offer their evidence records and it will be proven that = both pieces were archived in 2000. The fact that the pieces belong together = and thus the original document existed in 2000 is part of our assumptions. = I must point out that for the case of the splitting, there is no binding = rule for the judge, and we thus do not know, whether the=20 judge will actually make such a ruling or not.=20 n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, = that the document existed in their systems in 2000. It could be that the = judge is convinced. But perhaps he will say: I cannot estimate = trustworthyness of Ulis and Santoshs TAAs. The hospital must=20 prove that Uli-TAA and Santosh-TAA were completely trustworthy in the = last 20 years. Good luck with that.=20 I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists = and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high = volume suitable, secure method that is provable in court. This is true since = the security of the method only relies on the accreditation of the = algorithms and time-stamp machines (TSAs). There is no foundation for the = distribution of documents and the trustworthiness of TAAs. One=20 could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. = However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had = the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli=20 ------=_NextPart_000_0052_01C41AE8.AA638440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
In=20 addition to what Carl and Peter said, please note that n of m does not = prevent=20 subscribers and the TAAs from obtaining time stamps or TAAs from = asserting=20 time.
 
If not=20 n of m, at least two TAAs even in time stamp case are required = in=20 order to protect against a single TAA from intentionally corrupting the=20 data.  If a single TAA under the control of or as a contractor to = an=20 organization being sued had all the data, it can always manipulate prior = trust=20 anchors and messages.  Thus, an independent source of trust anchors = may be=20 required even in the case of 3161 time stamp = refresh.
 
n of m=20 does the same thing without requiring time stamp.
 
 
-----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, April 05, 2004 = 5:04=20 AM
To: 'ietf-ltans@imc.org'
Subject: FW: why we = need=20 sequences of timestamps

Hello LTANS,
 
somehow a message from Uli got lost.=20 :-(
So=20 he asked me to forward it to the community.
 
Tobias
 
Ps.:=20 I will try to find out what went wrong.
 
 
-----Original Message-----
From: = Ulrich pordesch=20 [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, = 2004=20 13:07
To: ietf-ltans@imc.org
Subject: why we need=20 sequences of timestamps

Santosh

envisage the following court case (we conducted such = cases=20 last fall in an academic study, using real lawyers and judges - and = not only=20 with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. = Afterwards, he=20 wrote and signed an operation report.  In 2020, the patient sues = the=20 hospital for damages in the value of millions, because allegedly there = was an=20 error in the operation.  This alleged error then lead to her = later=20 disability. Let us assume that the doctor's signature used the = algorithm=20 RSA-1024,

which became insecure in the year 2007.  = Furthermore, in=20 2020, signatures created with such a weak key can be easily forged. = Therefore,=20 at the time of the legal suit, anyone could forge the document and=20 signature.

The signature has become worthless. It is only of = value, if it=20 is provable that it existed before 2007. What can the hospital do to = be able=20 to convince a judge?  Which method should it adopt?  How can = LTANS=20 help the hospital?

Case 1
------ =
The hospital does not want to use an external archive service = provider,=20 rather it wants to provide its own in-house archive = services.

ERS: By 2020, its archive system created a chain of, = e.g., 3=20 time-stamps.  The time-stamps were retrieved according to RFC = 3126 and=20 from a legal, accredited time-stamp authority.  The court = verifies this=20 change of time-stamps, namely the Evidence Record.  Because the=20

time-stamps were timely renewed, before the = algorithms became=20 weak (according to the yearly published list of trustworthy = algorithms) and=20 because the used TSA is demonstrably accredited and thus was = inspected, the=20 evidence will be recognised.  Actually, the court must recognise = it,=20 since there are such evidence rules, which virtually force it to do=20 so.

n-of-m: As far as I see it, Shamir's scheme does not = offer any=20 value for this case.  The hospital could, at best, present to the = court a=20 confirmation from its own system, that says the document was added to = its=20 system in 2000.  This is hardly credible.  The judge will = send an=20 expert to the hospital, who will search through the hospital's archive =

and protocols.  This can be very expensive and = the chance=20 of success is at best poor.

Case 2
------ =
The hospital uses an external service provider, a TAA, let's = call it=20 Uli-TAA.

ERS: The provider creates an evidence record, as = above, using=20 time-stamps from an accredited TSA.  There is no difference in = the court=20 case.  It will be recognised, that the archive time-stamps are = correct=20 and were timely generated and thus, the signature existed before 2007 = and=20 cannot have been forged.

n-of-m: The hospital can only present the = confirmation from=20 Uli-TAA, who asserts, that the document was archived in 2000.  = Since this=20 was not a legally recognised method, it is difficult to prove the=20 trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external = providers,=20 Uli-TAA and Santosh-TAA, and splits its messages.  As Antje = already said,=20 she is not overwelmed with enthusiasm for this, since her costs will = double.=20 However, let's assume that two providers are used.  Furthermore, = let's=20 also assume that it is provable that the two pieces belong together, = that is,=20 that random

document pieces cannot combined together (I have not = checked,=20 whether this requirement of the provability of uniqueness exists, but = let's=20 assume it).

ERS: Both TAAS offer their evidence records and it = will be=20 proven that both pieces were archived in 2000.  The fact that the = pieces=20 belong together and thus the original document existed in 2000 is part = of our=20 assumptions.  I must point out that for the case of the = splitting, there=20 is no binding rule for the judge, and we thus do not know, whether the =

judge will actually make such a ruling or = not.

n-of-m: The judge receives a confirmation from = Uli-TAA and=20 Santosh-TAA, that the document existed in their systems in 2000.  = It=20 could be that the judge is convinced.  But perhaps he will say: I = cannot=20 estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must=20

prove that Uli-TAA and Santosh-TAA were completely = trustworthy=20 in the last 20 years. Good luck with that.


I haven't even considered the special cases, where = Uli-TAA is=20 bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no = longer=20 exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides = us with a=20 high volume suitable, secure method that is provable in court.  = This is=20 true since the security of the method only relies on the accreditation = of the=20 algorithms and time-stamp machines (TSAs).  There is no = foundation for=20 the distribution of documents and the trustworthiness of TAAs.  = One=20

could define rules for which policies TAAs must = have, which=20 security measures they must use and how they will be regularly audited = etc.=20 However, I tend to rule out that one can achieve a comparable level of = security through this manner.

Where one could make further considerations is the = combination=20 of both methods.  Additional confirmations from the TAAs, saying = that=20 they had the document or piece, could be in specific cases an = alternative for=20 ERS, in particular, in the case that something went wrong during the=20 time-stamp renewal.

Uli

------=_NextPart_000_0052_01C41AE8.AA638440-- From owner-ietf-ltans Tue Apr 6 00:23:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i367N59b093997; Tue, 6 Apr 2004 00:23:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i367N5kx093996; Tue, 6 Apr 2004 00:23:05 -0700 (PDT) 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 i367N3WR093926 for ; Tue, 6 Apr 2004 00:23:03 -0700 (PDT) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCHOTZENPLOTZ (pc-hotzenplotz [141.12.33.2]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id JAA26602 for ; Tue, 6 Apr 2004 09:22:48 +0200 (MET DST) From: "Ulrich Pordesch" To: Subject: why we need sequences of timestamps (third trial) Date: Tue, 6 Apr 2004 09:23:12 +0200 Organization: Fraunhofer, SIT Message-ID: <000101c41ba8$06a133a0$02210c8d@PCHOTZENPLOTZ> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i367N4WR093989 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The following message got lost twice in cyberspace. Strange to say that some members of the list got it and posted comments. Here is the third trial for all ... Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli From owner-ietf-ltans Tue Apr 6 02:03:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3693Qhn029365; Tue, 6 Apr 2004 02:03:26 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3693Qm3029364; Tue, 6 Apr 2004 02:03:26 -0700 (PDT) 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 i3693KFA029300 for ; Tue, 6 Apr 2004 02:03:21 -0700 (PDT) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (vpnsit9.sit.fraunhofer.de [141.12.110.9]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA08897; Tue, 6 Apr 2004 11:02:53 +0200 (MET DST) Message-ID: <40727255.3050709@sit.fraunhofer.de> Date: Tue, 06 Apr 2004 11:03:17 +0200 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: Santosh Chokhani CC: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps References: <005101c41b0a$31752440$9a00a8c0@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: Santosh Chokhani wrote: > In addition to what Carl and Peter said, please note that n of m does > not prevent subscribers and the TAAs from obtaining time stamps or TAAs > from asserting time. > > If not n of m, at least two TAAs even in time stamp case are required in > order to protect against a single TAA from intentionally corrupting the > data. If a single TAA under the control of or as a contractor to an > organization being sued had all the data, it can always manipulate prior > trust anchors and messages. Thus, an independent source of trust > anchors may be required even in the case of 3161 time stamp refresh. I think a key difference between the two schemes is where the trust lies when a dispute arises in the future. In both schemes, the client has a contract with the TAA to properly archive his data, in the ERS case, this is one TAA, who could intentionally inproperly archive the data so that it is invalid in the future. But the trust of the system is during the dispute. Here, no trust is allocated to the TAA. The client simply has the ERS data structures, containing time-stamps from *trusted* TSAs, who had no access to the documents, nor a financial incentive to function improperly. With n of m, the judge must then trust the TAAs (n of them), that they all functioned correctly, in terms of guidelines as well as the software systems. Uli's point was whether a judge would trust the systems of the TAAs (a TAA system is much more complex than a simple TSA). Currently there are laws in Germany stating that the TSA approach is legally binding. Of course, a hybrid approach could solve both the trust as well as confidentiality issues. But if the time-stamp solution is removed as a mandatory part, we are then unsure of the legal value of the evidential proof. Brian > > n of m does the same thing without requiring time stamp. > > > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: Monday, April 05, 2004 5:04 AM > To: 'ietf-ltans@imc.org' > Subject: FW: why we need sequences of timestamps > > Hello LTANS, > > somehow a message from Uli got lost. :-( > So he asked me to forward it to the community. > > Tobias > > Ps.: I will try to find out what went wrong. > From owner-ietf-ltans Tue Apr 6 02:15:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i369FpoQ033523; Tue, 6 Apr 2004 02:15:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i369FpiN033522; Tue, 6 Apr 2004 02:15:51 -0700 (PDT) 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 i369FnuI033513 for ; Tue, 6 Apr 2004 02:15:50 -0700 (PDT) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (vpnsit9.sit.fraunhofer.de [141.12.110.9]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA10712; Tue, 6 Apr 2004 11:15:40 +0200 (MET DST) Message-ID: <407275AB.10204@sit.fraunhofer.de> Date: Tue, 06 Apr 2004 11:17:31 +0200 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: ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps References: <200404051145.i35BjKAt023817@host13.websitesource.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: Carl Wallace wrote: > Uli, > > I don't think using 1-of-1 scenarios is a good basis for comparing the > two approaches. In any case, why it is necessary to view this as an ERS > vs. n-of-m decision? n-of-m could be used in conjunction with ERS to > provide data confidentiality. Combining n-of-m with a keyless timestamp > scheme could be a nice solution. Adding n of m on the client side could be used to alleviate his key management issues (, provided that the recombination of the n parts is shown to maintain the uniqueness of the document and hence the non-repudiation). > What about the patient's preservation of evidence? It may be difficult > for the patient to manage encryption keys that enable confidentiality of > the patient's medical data stored in a commercial archive. I doubt the > patient would trust the hospital to maintain all copies of the relevant > data. Uli's example was from the point of view of the hospital, who has to archive millions of documents a year, thus it needs an efficient system. The patient would be another type of client, and would not use the hospital's system. Brian > > Are there any results of the study you mentioned available online? > > Carl ... From owner-ietf-ltans Tue Apr 6 06:28:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36DSZUm051222; Tue, 6 Apr 2004 06:28:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36DSZq7051221; Tue, 6 Apr 2004 06:28:35 -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.11/8.12.8) with ESMTP id i36DSYnX051212 for ; Tue, 6 Apr 2004 06:28:34 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i36DSLAt012160 for ; Tue, 6 Apr 2004 09:28:36 -0400 From: "Santosh Chokhani" To: Subject: RE: why we need sequences of timestamps Date: Tue, 6 Apr 2004 09:28:21 -0400 Message-ID: <004f01c41bdb$107fdf60$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40727255.3050709@sit.fraunhofer.de> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: The trust in the ERS model DOES depend on the TAA. While the trust anchor for the outermost timestamp can and should be verified independent of the TAA, all the inner timestamps and data are vulnerable to cryptanalysis and hence TAA manipulation. Thus, the real transaction or document in dispute can always be manipulated. Just like the TSA does not have data or vested interest, the various TAAs should not either and with n of m just like hash, they have meaningless string of bits which they can not manipulate to achieve a specific outcome other than screwing up the integrity. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Brian Hunter Sent: Tuesday, April 06, 2004 5:03 AM To: Santosh Chokhani Cc: 'Tobias Gondrom'; ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps Santosh Chokhani wrote: > In addition to what Carl and Peter said, please note that n of m does > not prevent subscribers and the TAAs from obtaining time stamps or TAAs > from asserting time. > > If not n of m, at least two TAAs even in time stamp case are required > in > order to protect against a single TAA from intentionally corrupting the > data. If a single TAA under the control of or as a contractor to an > organization being sued had all the data, it can always manipulate prior > trust anchors and messages. Thus, an independent source of trust > anchors may be required even in the case of 3161 time stamp refresh. I think a key difference between the two schemes is where the trust lies when a dispute arises in the future. In both schemes, the client has a contract with the TAA to properly archive his data, in the ERS case, this is one TAA, who could intentionally inproperly archive the data so that it is invalid in the future. But the trust of the system is during the dispute. Here, no trust is allocated to the TAA. The client simply has the ERS data structures, containing time-stamps from *trusted* TSAs, who had no access to the documents, nor a financial incentive to function improperly. With n of m, the judge must then trust the TAAs (n of them), that they all functioned correctly, in terms of guidelines as well as the software systems. Uli's point was whether a judge would trust the systems of the TAAs (a TAA system is much more complex than a simple TSA). Currently there are laws in Germany stating that the TSA approach is legally binding. Of course, a hybrid approach could solve both the trust as well as confidentiality issues. But if the time-stamp solution is removed as a mandatory part, we are then unsure of the legal value of the evidential proof. Brian > > n of m does the same thing without requiring time stamp. > > > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: Monday, April 05, 2004 5:04 AM > To: 'ietf-ltans@imc.org' > Subject: FW: why we need sequences of timestamps > > Hello LTANS, > > somehow a message from Uli got lost. :-( > So he asked me to forward it to the community. > > Tobias > > Ps.: I will try to find out what went wrong. > From owner-ietf-ltans Thu Apr 8 05:11:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38CBYPD074902; Thu, 8 Apr 2004 05:11:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38CBYxU074901; Thu, 8 Apr 2004 05:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout01.datevnet.de (mailout01.datevnet.de [193.27.50.78]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38CBWnM074895 for ; Thu, 8 Apr 2004 05:11:33 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 28671 invoked from network); 8 Apr 2004 12:11:31 -0000 Received: from mail01.services.datevnet.de ([10.252.80.78]) (envelope-sender ) by mailout01.datevnet.de (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:31 -0000 Received: (qmail 24410 invoked by uid 0); 8 Apr 2004 12:11:31 -0000 Received: from localhost (HELO mail01.services.datev.de) (sendmail-bs@[127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:31 -0000 Received: (qmail 24402 invoked from network); 8 Apr 2004 12:11:30 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:30 -0000 From: "Michael Tielemann" To: Subject: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 14:13:44 +0200 Message-ID: <03da01c41d62$f04fab10$9c01fb0a@P25823E0> 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.3416 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: Dear all, in my opinion the recently discussed n:m distribution is an academically interesting approach. But I fear that in practice there is no chance to run such a model. Spreading signed data is much expensive in communication, storing, retrieving etc. Sure, there is a benfit in security and evidence, but the overhead is in any industrial context not feasable. Implementing distributed locations is to expensive in the sense of hardware, stuff, building, several DMS (?), backup, disaster recovery, managing responsebility, etc. I guess we need, lets say a local store which serves all neccessary tasks. This allows a more practicable implementation and modelling for any company or application. At our site we have a huge amount of stored documents, splitting this mass up to several locations with all dependencies would be a nightmare. Regards -Michael From owner-ietf-ltans Thu Apr 8 06:06:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38D6MN2079284; Thu, 8 Apr 2004 06:06:22 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38D6MdZ079283; Thu, 8 Apr 2004 06:06:22 -0700 (PDT) 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 i38D6LQk079260 for ; Thu, 8 Apr 2004 06:06:21 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Received: (qmail 31680 invoked from network); 8 Apr 2004 13:06:15 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 8 Apr 2004 13:06:15 -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 31437-05 for ; Thu, 8 Apr 2004 15:06:15 +0200 (CEST) Received: (qmail 31675 invoked from network); 8 Apr 2004 13:06:15 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 8 Apr 2004 13:06:15 -0000 From: "A. Jerman Blazic" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 15:08:16 +0200 Message-ID: <008801c41d6a$8e6eee30$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: <03da01c41d62$f04fab10$9c01fb0a@P25823E0> 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: Dear all, I have been following the discussion for some time and did go through the n/m scenario and I have to add my position (also as a technology provider). As stated a couple of times before n/m solves some critical problems (confidentiality) but mostly in scenarios when trusted archive is presented as an outsourcing service (here I really liked Uli's scenarios). Within an organization n/m approach does not deliver a single benefit, since redundancy and disaster recovery is solved by other approaches/technology and building a "new instance" taking care of redundancy is a wrong direction. Also one should keep in mind that many records do already exist today and transformation using n/m approaches are to demanding and especially form the point of view that DMS systems or docbases are not something that will be implemented with the trusted archive but they DO exist already, archival standards should take care mostly of collecting complementary data for unquestioned record conservation over defined or undefined period of time. The approach being implemented today by technology providers and organizations with docbases is therefore based on deployment of archival interfaces operating directly on existing records by producing conservation relevant data. Three major points needs to be addressed ASAP: archive interaction, archival meta and archival complementary data. Present systems try to build sets of data (mainly trust anchors) on existing or incoming records. Standardizing such (archival) data is a must, since it can not rely on specific technology and this is where the problem really exist at the moment. Data, meta data and complementary data must be transparent of underlying technology and they must be combined with seamless mechanisms for proving integrity on independent platforms or in other words, they must be based on standardized semantic. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael Tielemann > Sent: Thursday, April 08, 2004 2:14 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > > Dear all, > > in my opinion the recently discussed n:m distribution is an > academically interesting approach. But I fear that in > practice there is no chance to run such a model. Spreading > signed data is much expensive in communication, storing, > retrieving etc. Sure, there is a benfit in security and > evidence, but the overhead is in any industrial context not > feasable. Implementing distributed locations is to expensive > in the sense of hardware, stuff, building, several DMS (?), > backup, disaster recovery, managing responsebility, etc. > > I guess we need, lets say a local store which serves all > neccessary tasks. This allows a more practicable > implementation and modelling for any company or application. > > At our site we have a huge amount of stored documents, > splitting this mass up to several locations with all > dependencies would be a nightmare. > > Regards > -Michael > From owner-ietf-ltans Thu Apr 8 06:27:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38DRhKd080911; Thu, 8 Apr 2004 06:27:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38DRhq1080909; Thu, 8 Apr 2004 06:27:43 -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.11/8.12.8) with ESMTP id i38DRgdA080891 for ; Thu, 8 Apr 2004 06:27:43 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38DRhAt013230; Thu, 8 Apr 2004 09:27:43 -0400 From: "Santosh Chokhani" To: "'A. Jerman Blazic'" , Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 09:27:43 -0400 Message-ID: <008301c41d6d$45d0a940$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 In-Reply-To: <008801c41d6a$8e6eee30$1b018ac1@arthur> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38DRhdA080897 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The n of m approach is proposed when you use multiple parties as trust store. If you feel that you need to store your own data and can defend in court time stamps (all of which may be subject to cryptanalysis except the current one), then you do not need multiple third parties. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Thursday, April 08, 2004 9:08 AM To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Dear all, I have been following the discussion for some time and did go through the n/m scenario and I have to add my position (also as a technology provider). As stated a couple of times before n/m solves some critical problems (confidentiality) but mostly in scenarios when trusted archive is presented as an outsourcing service (here I really liked Uli's scenarios). Within an organization n/m approach does not deliver a single benefit, since redundancy and disaster recovery is solved by other approaches/technology and building a "new instance" taking care of redundancy is a wrong direction. Also one should keep in mind that many records do already exist today and transformation using n/m approaches are to demanding and especially form the point of view that DMS systems or docbases are not something that will be implemented with the trusted archive but they DO exist already, archival standards should take care mostly of collecting complementary data for unquestioned record conservation over defined or undefined period of time. The approach being implemented today by technology providers and organizations with docbases is therefore based on deployment of archival interfaces operating directly on existing records by producing conservation relevant data. Three major points needs to be addressed ASAP: archive interaction, archival meta and archival complementary data. Present systems try to build sets of data (mainly trust anchors) on existing or incoming records. Standardizing such (archival) data is a must, since it can not rely on specific technology and this is where the problem really exist at the moment. Data, meta data and complementary data must be transparent of underlying technology and they must be combined with seamless mechanisms for proving integrity on independent platforms or in other words, they must be based on standardized semantic. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael Tielemann > Sent: Thursday, April 08, 2004 2:14 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > > Dear all, > > in my opinion the recently discussed n:m distribution is an > academically interesting approach. But I fear that in > practice there is no chance to run such a model. Spreading > signed data is much expensive in communication, storing, > retrieving etc. Sure, there is a benfit in security and > evidence, but the overhead is in any industrial context not > feasable. Implementing distributed locations is to expensive > in the sense of hardware, stuff, building, several DMS (?), > backup, disaster recovery, managing responsebility, etc. > > I guess we need, lets say a local store which serves all > neccessary tasks. This allows a more practicable > implementation and modelling for any company or application. > > At our site we have a huge amount of stored documents, > splitting this mass up to several locations with all > dependencies would be a nightmare. > > Regards > -Michael > From owner-ietf-ltans Thu Apr 8 06:41:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38DfVvu081711; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38DfVlC081709; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) 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 i38DfUMQ081696 for ; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Received: (qmail 572 invoked from network); 8 Apr 2004 13:41:27 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 8 Apr 2004 13:41:27 -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 32390-09 for ; Thu, 8 Apr 2004 15:41:27 +0200 (CEST) Received: (qmail 567 invoked from network); 8 Apr 2004 13:41:27 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 8 Apr 2004 13:41:27 -0000 From: "A. Jerman Blazic" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 15:43:29 +0200 Message-ID: <008d01c41d6f$7988f290$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: <008301c41d6d$45d0a940$9a00a8c0@hq.orionsec.com> 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: Of course, that is the main point. We should consider demands (at the moment) and focus on them. Multiple parties scenario does not exist currently... At least to my knowledge. But future infrastructures might do that (n/m). > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 3:28 PM > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > The n of m approach is proposed when you use multiple parties > as trust store. > > If you feel that you need to store your own data and can > defend in court time stamps (all of which may be subject to > cryptanalysis except the current one), then you do not need > multiple third parties. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of A. Jerman Blazic > Sent: Thursday, April 08, 2004 9:08 AM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Dear all, > > I have been following the discussion for some time and did go > through the n/m scenario and I have to add my position (also > as a technology provider). > > As stated a couple of times before n/m solves some critical problems > (confidentiality) but mostly in scenarios when trusted > archive is presented as an outsourcing service (here I really > liked Uli's scenarios). Within an organization n/m approach > does not deliver a single benefit, since redundancy and > disaster recovery is solved by other approaches/technology > and building a "new instance" taking care of redundancy is a > wrong direction. Also one should keep in mind that many > records do already exist today and transformation using n/m > approaches are to demanding and especially form the point of > view that DMS systems or docbases are not something that will > be implemented with the trusted archive but they DO exist > already, archival standards should take care mostly of > collecting complementary data for unquestioned record > conservation over defined or undefined period of time. The > approach being implemented today by technology providers and > organizations with docbases is therefore based on deployment > of archival interfaces operating directly on existing records > by producing conservation relevant data. Three major points > needs to be addressed ASAP: archive interaction, archival > meta and archival complementary data. Present systems try to > build sets of data (mainly trust anchors) on existing or > incoming records. Standardizing such (archival) data is a > must, since it can not rely on specific technology and this > is where the problem really exist at the moment. Data, meta > data and complementary data must be transparent of underlying > technology and they must be combined with seamless mechanisms > for proving integrity on independent platforms or in other > words, they must be based on standardized semantic. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > Tielemann > > Sent: Thursday, April 08, 2004 2:14 PM > > To: ietf-ltans@imc.org > > Subject: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > in my opinion the recently discussed n:m distribution is an > > academically interesting approach. But I fear that in > practice there > > is no chance to run such a model. Spreading signed data is much > > expensive in communication, storing, retrieving etc. Sure, > there is a > > benfit in security and evidence, but the overhead is in any > industrial > > context not feasable. Implementing distributed locations is to > > expensive in the sense of hardware, stuff, building, > several DMS (?), > > backup, disaster recovery, managing responsebility, etc. > > > > I guess we need, lets say a local store which serves all neccessary > > tasks. This allows a more practicable implementation and modelling > > for any company or application. > > > > At our site we have a huge amount of stored documents, > splitting this > > mass up to several locations with all dependencies would be a > > nightmare. > > > > Regards > > -Michael > > > From owner-ietf-ltans Thu Apr 8 08:35:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FZM4H090440; Thu, 8 Apr 2004 08:35:22 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38FZMxV090439; Thu, 8 Apr 2004 08:35:22 -0700 (PDT) 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 i38FZGXl090427 for ; Thu, 8 Apr 2004 08:35:21 -0700 (PDT) (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 i38FZDpv027603; Thu, 8 Apr 2004 17:35:13 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ9DCG>; Thu, 8 Apr 2004 17:37:34 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54C7@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Cc: "'Libor.Dostalek@pvt.cz'" Subject: RE: Our objections to draft ERS Date: Thu, 8 Apr 2004 17:37:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41D7F.5E719290" 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_01C41D7F.5E719290 Content-Type: text/plain Libor, to answer in place of Brian: Your described scenario is perfectly right. I would not have been able to explain it better: This is exactly what is meant. best regards Tobias Brian, > In your example, the whole CMS object, as in RFC 3126, should be > given to the TAA for archiving. I have one quite elementary question to verify if I understand well. See the following example: Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid. 2.4.2004 6.5.2007 2020 -+----------------------+--------------------------------------+-- <------------CMS validity-------------> <-----------------ERS validity----------->>> Libor ------_=_NextPart_001_01C41D7F.5E719290 Content-Type: text/html Message
Libor,
 
to answer in place of Brian:
 
Your described scenario is perfectly right.
I would not have been able to explain it better: This is exactly what is meant.
 
best regards
 
    Tobias
 
 

Brian,

> In your example, the whole CMS object, as in RFC 3126, should be
> given to the TAA for archiving.

I have one quite elementary question to verify if I understand well. See the following example:

Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007.

In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the  ArchiveTimeStamp in 6th May 2007 up to present.

Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid.

 2.4.2004               6.5.2007                               2020
-+----------------------+--------------------------------------+--
 <------------CMS validity------------->
                        <-----------------ERS validity----------->>>

   
Libor

 

------_=_NextPart_001_01C41D7F.5E719290-- From owner-ietf-ltans Thu Apr 8 09:40:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Gewuv095127; Thu, 8 Apr 2004 09:40:58 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38GewNv095126; Thu, 8 Apr 2004 09:40:58 -0700 (PDT) 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 i38GeqvD095119 for ; Thu, 8 Apr 2004 09:40:57 -0700 (PDT) (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 i38Geq55008568 for ; Thu, 8 Apr 2004 18:40:54 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ91B2>; Thu, 8 Apr 2004 18:43:14 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 18:42:55 +0200 Importance: high X-Priority: 1 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: Dear all, Personally I fully go with Brian, Aleksej, Uli, Antje and Michael. I can see that n-of-m has some quite interesting aspects but feel the same that it is quite academic concenring current needs and business. I agree that there is one advantage of n-of-m over the current model, that is when it comes to the point that we have no hash algorithms and no PK algorithms at _all_. At the moment we are working quite fine with PK and hash algorithms and the time stamps from PKIX are in practical use - so I would like to rely on them. Second, the distribution is very expensive and AFAIK from my contacts to users and customers will most probably not be accepted. (we are all just humans) As our goal is to develop standards that we think are best for the world _and_ will be _used_. I feel that all of the arguments are exchanged concerning the topic and so I would like to get to an conclusion. >From what I read I feel that there might be rough consensus to reject the proposal of n-of-m for this draft. We can pick it up as a future topic or add-on for LTANS if we are able to demonstrate the need and the business use and have done our homework with the first drafts mid of this year. Am I asking to early or just please give me your statement ? Best regards and happy easter Tobias (Chair of LTANS) > -----Original Message----- > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > Sent: Thursday, April 08, 2004 15:43 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Of course, that is the main point. We should consider demands (at the > moment) and focus on them. Multiple parties scenario does not > exist currently... At least to my knowledge. But future > infrastructures might do that (n/m). > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 3:28 PM > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > The n of m approach is proposed when you use multiple parties > > as trust store. > > > > If you feel that you need to store your own data and can > > defend in court time stamps (all of which may be subject to > > cryptanalysis except the current one), then you do not need > > multiple third parties. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Thursday, April 08, 2004 9:08 AM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > I have been following the discussion for some time and did go > > through the n/m scenario and I have to add my position (also > > as a technology provider). > > > > As stated a couple of times before n/m solves some critical problems > > (confidentiality) but mostly in scenarios when trusted > > archive is presented as an outsourcing service (here I really > > liked Uli's scenarios). Within an organization n/m approach > > does not deliver a single benefit, since redundancy and > > disaster recovery is solved by other approaches/technology > > and building a "new instance" taking care of redundancy is a > > wrong direction. Also one should keep in mind that many > > records do already exist today and transformation using n/m > > approaches are to demanding and especially form the point of > > view that DMS systems or docbases are not something that will > > be implemented with the trusted archive but they DO exist > > already, archival standards should take care mostly of > > collecting complementary data for unquestioned record > > conservation over defined or undefined period of time. The > > approach being implemented today by technology providers and > > organizations with docbases is therefore based on deployment > > of archival interfaces operating directly on existing records > > by producing conservation relevant data. Three major points > > needs to be addressed ASAP: archive interaction, archival > > meta and archival complementary data. Present systems try to > > build sets of data (mainly trust anchors) on existing or > > incoming records. Standardizing such (archival) data is a > > must, since it can not rely on specific technology and this > > is where the problem really exist at the moment. Data, meta > > data and complementary data must be transparent of underlying > > technology and they must be combined with seamless mechanisms > > for proving integrity on independent platforms or in other > > words, they must be based on standardized semantic. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > Tielemann > > > Sent: Thursday, April 08, 2004 2:14 PM > > > To: ietf-ltans@imc.org > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > in my opinion the recently discussed n:m distribution is an > > > academically interesting approach. But I fear that in > > practice there > > > is no chance to run such a model. Spreading signed data is much > > > expensive in communication, storing, retrieving etc. Sure, > > there is a > > > benfit in security and evidence, but the overhead is in any > > industrial > > > context not feasable. Implementing distributed locations is to > > > expensive in the sense of hardware, stuff, building, > > several DMS (?), > > > backup, disaster recovery, managing responsebility, etc. > > > > > > I guess we need, lets say a local store which serves all > neccessary > > > tasks. This allows a more practicable implementation and > modelling > > > for any company or application. > > > > > > At our site we have a huge amount of stored documents, > > splitting this > > > mass up to several locations with all dependencies would be a > > > nightmare. > > > > > > Regards > > > -Michael > > > > > > From owner-ietf-ltans Thu Apr 8 09:43:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38GhVdI095385; Thu, 8 Apr 2004 09:43:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38GhVTD095384; Thu, 8 Apr 2004 09:43:31 -0700 (PDT) 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 i38GhU3s095371 for ; Thu, 8 Apr 2004 09:43:30 -0700 (PDT) (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 i38GhRsu007707 for ; Thu, 8 Apr 2004 18:43:27 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Apr 2004 18:45:38 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54CC@muc-mail5.ixos.de> From: Tobias Gondrom To: Tobias Gondrom Cc: ietf-ltans@imc.org Subject: RE: Problem with mailing-list: some emails got lost :-( - problem solved Date: Thu, 8 Apr 2004 18:45:31 +0200 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: Dear all, Thanks to Pauls fast answer the problem has been solved. It was about the sender was not registered with the mailing-list. Sorry for the interuption Best regards Tobias > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Monday, April 05, 2004 11:22 > To: ietf-ltans@imc.org > Subject: Problem with mailing-list: some emails got lost :-( > Importance: High > > > > Dear all, > > There seems to be some problem with the mailing-list. > Some emails have not been transmitted. > > I'm tracking the problem. Until then when you send emails to > the list please take a look whether it has really been > transmitted - as you are also part of the mailing-list you > should receive one copy of your own email too. > > If not, please report the error to me. > > Regards > > Tobias > > > Chair LTANS > From owner-ietf-ltans Thu Apr 8 10:01:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38H17iC096552; Thu, 8 Apr 2004 10:01:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38H17wF096551; Thu, 8 Apr 2004 10:01:07 -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.11/8.12.8) with ESMTP id i38H16h5096545 for ; Thu, 8 Apr 2004 10:01:06 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38H19At015552; Thu, 8 Apr 2004 13:01:09 -0400 From: "Santosh Chokhani" To: "'Tobias Gondrom'" , Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 13:01:09 -0400 Message-ID: <001b01c41d8b$16df0230$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38H16h5096546 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: You all are ignoring the fact that as you lay out, the TAA is a single source of authority to vouch for the document. You all also seem to say that TAA is within the organization. This could lead to problems in some courts. Please note that the time stamp authority is only good for the outermost time stamp. Due to cryptanalysis etc., inner time stamps may be manipulated by the TAA. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Thursday, April 08, 2004 12:43 PM To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: High Dear all, Personally I fully go with Brian, Aleksej, Uli, Antje and Michael. I can see that n-of-m has some quite interesting aspects but feel the same that it is quite academic concenring current needs and business. I agree that there is one advantage of n-of-m over the current model, that is when it comes to the point that we have no hash algorithms and no PK algorithms at _all_. At the moment we are working quite fine with PK and hash algorithms and the time stamps from PKIX are in practical use - so I would like to rely on them. Second, the distribution is very expensive and AFAIK from my contacts to users and customers will most probably not be accepted. (we are all just humans) As our goal is to develop standards that we think are best for the world _and_ will be _used_. I feel that all of the arguments are exchanged concerning the topic and so I would like to get to an conclusion. >From what I read I feel that there might be rough consensus to reject >the proposal of n-of-m for this draft. We can pick it up as a future topic or add-on for LTANS if we are able to demonstrate the need and the business use and have done our homework with the first drafts mid of this year. Am I asking to early or just please give me your statement ? Best regards and happy easter Tobias (Chair of LTANS) > -----Original Message----- > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > Sent: Thursday, April 08, 2004 15:43 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Of course, that is the main point. We should consider demands (at the > moment) and focus on them. Multiple parties scenario does not > exist currently... At least to my knowledge. But future > infrastructures might do that (n/m). > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 3:28 PM > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > The n of m approach is proposed when you use multiple parties as > > trust store. > > > > If you feel that you need to store your own data and can defend in > > court time stamps (all of which may be subject to cryptanalysis > > except the current one), then you do not need multiple third > > parties. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Thursday, April 08, 2004 9:08 AM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > I have been following the discussion for some time and did go > > through the n/m scenario and I have to add my position (also as a > > technology provider). > > > > As stated a couple of times before n/m solves some critical problems > > (confidentiality) but mostly in scenarios when trusted archive is > > presented as an outsourcing service (here I really liked Uli's > > scenarios). Within an organization n/m approach does not deliver a > > single benefit, since redundancy and disaster recovery is solved by > > other approaches/technology and building a "new instance" taking > > care of redundancy is a wrong direction. Also one should keep in > > mind that many records do already exist today and transformation > > using n/m approaches are to demanding and especially form the point > > of view that DMS systems or docbases are not something that will > > be implemented with the trusted archive but they DO exist > > already, archival standards should take care mostly of > > collecting complementary data for unquestioned record > > conservation over defined or undefined period of time. The > > approach being implemented today by technology providers and > > organizations with docbases is therefore based on deployment > > of archival interfaces operating directly on existing records > > by producing conservation relevant data. Three major points > > needs to be addressed ASAP: archive interaction, archival > > meta and archival complementary data. Present systems try to > > build sets of data (mainly trust anchors) on existing or > > incoming records. Standardizing such (archival) data is a > > must, since it can not rely on specific technology and this > > is where the problem really exist at the moment. Data, meta > > data and complementary data must be transparent of underlying > > technology and they must be combined with seamless mechanisms > > for proving integrity on independent platforms or in other > > words, they must be based on standardized semantic. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > Tielemann > > > Sent: Thursday, April 08, 2004 2:14 PM > > > To: ietf-ltans@imc.org > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > in my opinion the recently discussed n:m distribution is an > > > academically interesting approach. But I fear that in > > practice there > > > is no chance to run such a model. Spreading signed data is much > > > expensive in communication, storing, retrieving etc. Sure, > > there is a > > > benfit in security and evidence, but the overhead is in any > > industrial > > > context not feasable. Implementing distributed locations is to > > > expensive in the sense of hardware, stuff, building, > > several DMS (?), > > > backup, disaster recovery, managing responsebility, etc. > > > > > > I guess we need, lets say a local store which serves all > neccessary > > > tasks. This allows a more practicable implementation and > modelling > > > for any company or application. > > > > > > At our site we have a huge amount of stored documents, > > splitting this > > > mass up to several locations with all dependencies would be a > > > nightmare. > > > > > > Regards > > > -Michael > > > > > > From owner-ietf-ltans Thu Apr 8 10:18:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HIRRS097548; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HIRhU097547; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HIRAL097511 for ; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) (envelope-from LMM@acm.org) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i38HINSP025520; Thu, 8 Apr 2004 10:18:23 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38HIJkq008838; Thu, 8 Apr 2004 10:18:19 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV004P042I77@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 10:18:19 -0700 (PDT) Date: Thu, 08 Apr 2004 10:18:18 -0700 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving - conclusion ? In-reply-to: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> To: "'Tobias Gondrom'" Cc: ietf-ltans@imc.org Message-id: <0HVV004P142J77@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: AcQdiaWlyU612H2sRwqlNDGUBhi6nAAAjd/g Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, I am confused by your call for 'rough consensus'. Personally, I think it is best practice to focus 'rough consensus' on the actual wording in actual internet drafts, rather than on abstract principles. > 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. I have proposed some changes, and raised some questions, about the requirements document. It would be good to follow the charter and see if we can reach consensus on a requirements document. I would prefer one that did not exclude the possibility of mechanisms other than chain-of-evidence for providing for long term non-repudiation services. > 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. I would prefer that the protocol not require timestamp chains, but allow them as an option for providing long-term non-repudiation evidence. Multiple independent party assertions of independent records of receipt and validation, of either full copies (or secret shares, if the archives can be trusted to assert timestamps but not to respect privacy) might be an alternative mechanism. Personally, I think that the "chain of evidence" mechanisms proposed for long-term non-repudiation are themselves "academic research projects", in that they are untested, and seem to rely on some fairly dubious assertions, e.g., that the expiration of the belief in the non-invertability of any particular one-way hash function can be predicted. Larry -- http://larry.masinter.net From owner-ietf-ltans Thu Apr 8 10:21:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HL5Rt097711; Thu, 8 Apr 2004 10:21:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HL5gI097710; Thu, 8 Apr 2004 10:21:05 -0700 (PDT) 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 i38HL4l5097704 for ; Thu, 8 Apr 2004 10:21:04 -0700 (PDT) (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 i38HL5jx003866; Thu, 8 Apr 2004 19:21:06 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ91P3>; Thu, 8 Apr 2004 19:23:28 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54D0@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 19:23:00 +0200 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: Santosh: There seems to be a misunderstanding: You are right TAA is within the organization and can for this not be fully trusted - as a 3rd party time stamp server. Based on the concept of the TAA and ERS we ensure the security based on the time stamps from the trustable third party/source. These timestamps will ensure the integrity like layers around the documents and all more inner layers (with timestamps based on meanwhile weak algorithms). It is _not_ possible for the TAA to manipulate the inner data as the new timestamp (that can be trusted) will ensure the integrity of the document and all up to appliance of the last timestamp already existant timestamps. This includes the possibility of loosing the security of a hash algorithm (as long as there exists at least a new reliable hash algorithm) as the document and all up to then existing timestamps are together rehashed with a new valid hash algorithm. You can _proof_ that the system is secure while renewing/changing hash or PK algorithms over time. For the course of time please consult the email from Libor Dostalek from Friday 4/2/2004 (subject: RE: Our objections to draft ERS) where he described the chain of proof brilliantly. So I can not see any problems with courts. Best regards Tobias > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 19:01 > To: 'Tobias Gondrom'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > Tobias: > > You all are ignoring the fact that as you lay out, the TAA is > a single source of authority to vouch for the document. You > all also seem to say that TAA is within the organization. > > This could lead to problems in some courts. > > Please note that the time stamp authority is only good for > the outermost time stamp. Due to cryptanalysis etc., inner > time stamps may be manipulated by the TAA. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tobias Gondrom > Sent: Thursday, April 08, 2004 12:43 PM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: High > > > > Dear all, > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I can see that n-of-m has some quite interesting > aspects but feel the same that it is quite academic > concenring current needs and business. > > I agree that there is one advantage of n-of-m over the > current model, that is when it comes to the point that we > have no hash algorithms and no PK algorithms at _all_. At the > moment we are working quite fine with PK and hash algorithms > and the time stamps from PKIX are in practical use - so I > would like to rely on them. > > Second, the distribution is very expensive and AFAIK from my > contacts to users and customers will most probably not be > accepted. (we are all just > humans) > > > As our goal is to develop standards that we think are best > for the world _and_ will be _used_. I feel that all of the > arguments are exchanged concerning the topic and so I would > like to get to an conclusion. > > >From what I read I feel that there might be rough consensus to reject > >the > proposal of n-of-m for this draft. We can pick it up as a > future topic or add-on for LTANS if we are able to > demonstrate the need and the business use and have done our > homework with the first drafts mid of this year. > > > Am I asking to early or just please give me your statement ? > > > Best regards and happy easter > > Tobias > > > (Chair of LTANS) > > > > > -----Original Message----- > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > Sent: Thursday, April 08, 2004 15:43 > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Of course, that is the main point. We should consider > demands (at the > > moment) and focus on them. Multiple parties scenario does not exist > > currently... At least to my knowledge. But future infrastructures > > might do that (n/m). > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > Sent: Thursday, April 08, 2004 3:28 PM > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > trust store. > > > > > > If you feel that you need to store your own data and can defend in > > > court time stamps (all of which may be subject to cryptanalysis > > > except the current one), then you do not need multiple third > > > parties. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Thursday, April 08, 2004 9:08 AM > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > I have been following the discussion for some time and did go > > > through the n/m scenario and I have to add my position (also as a > > > technology provider). > > > > > > As stated a couple of times before n/m solves some > critical problems > > > (confidentiality) but mostly in scenarios when trusted archive is > > > presented as an outsourcing service (here I really liked Uli's > > > scenarios). Within an organization n/m approach does not > deliver a > > > single benefit, since redundancy and disaster recovery is > solved by > > > other approaches/technology and building a "new instance" taking > > > care of redundancy is a wrong direction. Also one should keep in > > > mind that many records do already exist today and transformation > > > using n/m approaches are to demanding and especially form > the point > > > of view that DMS systems or docbases are not something that will > > > be implemented with the trusted archive but they DO exist > > > already, archival standards should take care mostly of > > > collecting complementary data for unquestioned record > > > conservation over defined or undefined period of time. The > > > approach being implemented today by technology providers and > > > organizations with docbases is therefore based on deployment > > > of archival interfaces operating directly on existing records > > > by producing conservation relevant data. Three major points > > > needs to be addressed ASAP: archive interaction, archival > > > meta and archival complementary data. Present systems try to > > > build sets of data (mainly trust anchors) on existing or > > > incoming records. Standardizing such (archival) data is a > > > must, since it can not rely on specific technology and this > > > is where the problem really exist at the moment. Data, meta > > > data and complementary data must be transparent of underlying > > > technology and they must be combined with seamless mechanisms > > > for proving integrity on independent platforms or in other > > > words, they must be based on standardized semantic. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > Tielemann > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > academically interesting approach. But I fear that in > > > practice there > > > > is no chance to run such a model. Spreading signed data is much > > > > expensive in communication, storing, retrieving etc. Sure, > > > there is a > > > > benfit in security and evidence, but the overhead is in any > > > industrial > > > > context not feasable. Implementing distributed locations is to > > > > expensive in the sense of hardware, stuff, building, > > > several DMS (?), > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > I guess we need, lets say a local store which serves all > > neccessary > > > > tasks. This allows a more practicable implementation and > > modelling > > > > for any company or application. > > > > > > > > At our site we have a huge amount of stored documents, > > > splitting this > > > > mass up to several locations with all dependencies would be a > > > > nightmare. > > > > > > > > Regards > > > > -Michael > > > > > > > > > > From owner-ietf-ltans Thu Apr 8 10:31:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HVSOZ098232; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HVSub098231; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) 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 i38HVREY098225 for ; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) (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 i38HUx6P026196; Thu, 8 Apr 2004 10:31:04 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38HUt3k012635; Thu, 8 Apr 2004 10:30:56 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV0041P4NJ77@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 10:30:55 -0700 (PDT) Date: Thu, 08 Apr 2004 10:30:55 -0700 From: Larry Masinter Subject: acceptability of replication In-reply-to: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> To: "'Tobias Gondrom'" , ietf-ltans@imc.org Message-id: <0HVV0041Q4NJ77@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: AcQdiaWlyU612H2sRwqlNDGUBhi6nAABKlzQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Second, the distribution is very expensive and AFAIK from my contacts to > users and customers will most probably not be accepted. (we are all just > humans) I wanted to follow up on this point, since several posters have mentioned the cost of replication and difficulty of coordination. However, my understanding is that it is common practice in the industry, for disaster recovery, to maintain multiple copies of important data. And surely anything that you wish to preserve for the long term fits into this scenario. Using secret-sharing, there is no need to access the data once it has been archived, except in the case there is a dispute. However, using chain-of-evidence, the data must be regularly accessed (every several years, at least), in order to update the chain of evidence. Since these are important records undergoing transactional updates, won't they be candidates for off-site replication? So, is it certain that the cost of replication for, say, 2-of-3 with static storage of components is higher than the cost of maintaining a chain-of-evidence active re-signing activity? Larry -- http://larry.masinter.net From owner-ietf-ltans Thu Apr 8 11:12:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38ICjSU000370; Thu, 8 Apr 2004 11:12:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38ICjJq000369; Thu, 8 Apr 2004 11:12:45 -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.11/8.12.8) with ESMTP id i38ICjVg000363 for ; Thu, 8 Apr 2004 11:12:45 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38ICmAt028255 for ; Thu, 8 Apr 2004 14:12:48 -0400 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 14:12:48 -0400 Message-ID: <003401c41d95$1978db60$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D54D0@muc-mail5.ixos.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38ICjVg000364 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: The way time stamp refresh works, the TAA can manipulate the data, trust anchors and time stamps to obtain a time stamp. The ERS approach does not have cryptographic protection against that class of attack. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Thursday, April 08, 2004 1:23 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: Low Santosh: There seems to be a misunderstanding: You are right TAA is within the organization and can for this not be fully trusted - as a 3rd party time stamp server. Based on the concept of the TAA and ERS we ensure the security based on the time stamps from the trustable third party/source. These timestamps will ensure the integrity like layers around the documents and all more inner layers (with timestamps based on meanwhile weak algorithms). It is _not_ possible for the TAA to manipulate the inner data as the new timestamp (that can be trusted) will ensure the integrity of the document and all up to appliance of the last timestamp already existant timestamps. This includes the possibility of loosing the security of a hash algorithm (as long as there exists at least a new reliable hash algorithm) as the document and all up to then existing timestamps are together rehashed with a new valid hash algorithm. You can _proof_ that the system is secure while renewing/changing hash or PK algorithms over time. For the course of time please consult the email from Libor Dostalek from Friday 4/2/2004 (subject: RE: Our objections to draft ERS) where he described the chain of proof brilliantly. So I can not see any problems with courts. Best regards Tobias > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 19:01 > To: 'Tobias Gondrom'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > Tobias: > > You all are ignoring the fact that as you lay out, the TAA is > a single source of authority to vouch for the document. You > all also seem to say that TAA is within the organization. > > This could lead to problems in some courts. > > Please note that the time stamp authority is only good for > the outermost time stamp. Due to cryptanalysis etc., inner > time stamps may be manipulated by the TAA. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tobias Gondrom > Sent: Thursday, April 08, 2004 12:43 PM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: High > > > > Dear all, > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I can see that n-of-m has some quite interesting > aspects but feel the same that it is quite academic > concenring current needs and business. > > I agree that there is one advantage of n-of-m over the > current model, that is when it comes to the point that we > have no hash algorithms and no PK algorithms at _all_. At the > moment we are working quite fine with PK and hash algorithms > and the time stamps from PKIX are in practical use - so I > would like to rely on them. > > Second, the distribution is very expensive and AFAIK from my > contacts to users and customers will most probably not be > accepted. (we are all just > humans) > > > As our goal is to develop standards that we think are best > for the world _and_ will be _used_. I feel that all of the > arguments are exchanged concerning the topic and so I would > like to get to an conclusion. > > >From what I read I feel that there might be rough consensus to reject > >the > proposal of n-of-m for this draft. We can pick it up as a > future topic or add-on for LTANS if we are able to > demonstrate the need and the business use and have done our > homework with the first drafts mid of this year. > > > Am I asking to early or just please give me your statement ? > > > Best regards and happy easter > > Tobias > > > (Chair of LTANS) > > > > > -----Original Message----- > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > Sent: Thursday, April 08, 2004 15:43 > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Of course, that is the main point. We should consider > demands (at the > > moment) and focus on them. Multiple parties scenario does not exist > > currently... At least to my knowledge. But future infrastructures > > might do that (n/m). > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > Sent: Thursday, April 08, 2004 3:28 PM > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > trust store. > > > > > > If you feel that you need to store your own data and can defend in > > > court time stamps (all of which may be subject to cryptanalysis > > > except the current one), then you do not need multiple third > > > parties. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Thursday, April 08, 2004 9:08 AM > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > I have been following the discussion for some time and did go > > > through the n/m scenario and I have to add my position (also as a > > > technology provider). > > > > > > As stated a couple of times before n/m solves some > critical problems > > > (confidentiality) but mostly in scenarios when trusted archive is > > > presented as an outsourcing service (here I really liked Uli's > > > scenarios). Within an organization n/m approach does not > deliver a > > > single benefit, since redundancy and disaster recovery is > solved by > > > other approaches/technology and building a "new instance" taking > > > care of redundancy is a wrong direction. Also one should keep in > > > mind that many records do already exist today and transformation > > > using n/m approaches are to demanding and especially form > the point > > > of view that DMS systems or docbases are not something that will > > > be implemented with the trusted archive but they DO exist already, > > > archival standards should take care mostly of collecting > > > complementary data for unquestioned record conservation over > > > defined or undefined period of time. The approach being > > > implemented today by technology providers and organizations with > > > docbases is therefore based on deployment of archival interfaces > > > operating directly on existing records by producing conservation > > > relevant data. Three major points needs to be addressed ASAP: > > > archive interaction, archival meta and archival complementary > > > data. Present systems try to build sets of data (mainly trust > > > anchors) on existing or incoming records. Standardizing such > > > (archival) data is a must, since it can not rely on specific > > > technology and this is where the problem really exist at the > > > moment. Data, meta data and complementary data must be transparent > > > of underlying technology and they must be combined with seamless > > > mechanisms for proving integrity on independent platforms or in > > > other words, they must be based on standardized semantic. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > Tielemann > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > academically interesting approach. But I fear that in > > > practice there > > > > is no chance to run such a model. Spreading signed data is much > > > > expensive in communication, storing, retrieving etc. Sure, > > > there is a > > > > benfit in security and evidence, but the overhead is in any > > > industrial > > > > context not feasable. Implementing distributed locations is to > > > > expensive in the sense of hardware, stuff, building, > > > several DMS (?), > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > I guess we need, lets say a local store which serves all > > neccessary > > > > tasks. This allows a more practicable implementation and > > modelling > > > > for any company or application. > > > > > > > > At our site we have a huge amount of stored documents, > > > splitting this > > > > mass up to several locations with all dependencies would be a > > > > nightmare. > > > > > > > > Regards > > > > -Michael > > > > > > > > > > From owner-ietf-ltans Thu Apr 8 11:11:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38IBNlO000302; Thu, 8 Apr 2004 11:11:23 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38IBN7b000301; Thu, 8 Apr 2004 11:11:23 -0700 (PDT) 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 i38IBMLn000290 for ; Thu, 8 Apr 2004 11:11:22 -0700 (PDT) (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 i38IAr6P028528; Thu, 8 Apr 2004 11:10:59 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38IAo3k016033; Thu, 8 Apr 2004 11:10:50 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV007NQ6I15Z@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 11:10:49 -0700 (PDT) Date: Thu, 08 Apr 2004 11:10:49 -0700 From: Larry Masinter Subject: RE: Our objections to draft ERS In-reply-to: <000601c41891$8be4f8e0$6402a8c0@pvt.cz> To: Libor.Dostalek@pvt.cz, ietf-ltans@imc.org Message-id: <0HVV007NR6I15Z@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: multipart/alternative; boundary="Boundary_(ID_aATK5K4dGBCGfUN0F13N0w)" Thread-index: AcQYlEl3gZs2tKIzRI2YddTbLU9pCAE/kYiw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_aATK5K4dGBCGfUN0F13N0w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Every time I've tried to explain this, I had to draw a set of diagrams on the board, and invent some notation. I'm not happy with the notation, but I think there must be some better way of explaining the chain-of-evidence. Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. I don't understand how, in 2020, you will verify that the TSA digital signature was valid in May 2007. Won't you need more information than will be trustably available after 13 years? --Boundary_(ID_aATK5K4dGBCGfUN0F13N0w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Zpráva
Every time I've tried to explain this, I had to draw a set of diagrams on the board, and invent some notation. I'm not happy with the notation, but I think there must be some better way of explaining the chain-of-evidence.
 
Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007.

In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the  ArchiveTimeStamp in 6th May 2007 up to present.

Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. 
 
 
I don't understand how, in 2020, you will verify that the TSA digital signature was valid in May 2007. Won't you need more information than will be trustably available after 13 years?
 
--Boundary_(ID_aATK5K4dGBCGfUN0F13N0w)-- From owner-ietf-ltans Wed Apr 21 09:04:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LG4X6Z086665; Wed, 21 Apr 2004 09:04:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LG4X1X086664; Wed, 21 Apr 2004 09:04:33 -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.11/8.12.8) with ESMTP id i3LG4XkX086653 for ; Wed, 21 Apr 2004 09:04:33 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i3LG4ZK5029192 for ; Wed, 21 Apr 2004 12:04:36 -0400 From: "Santosh Chokhani" To: Subject: Data Splitting Date: Wed, 21 Apr 2004 12:04:30 -0400 Message-ID: <001d01c427ba$579e02b0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C42798.D08C62B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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_001E_01C42798.D08C62B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been looking at some of the work done in this area. It seems = that a pure data splitting technique may not be practical. There are couple of problems. For a large amount of data, how would you calculate the prime = and then coefficients. This may be computationally extremely complex or infeasible, i.e. may take the time of the life of the data to split the data. =20 Even a 2 of 2 scheme using exclusive OR will be problem since finding a random stream the size of the data will be next to impossible If you = had smaller seed then, you get into the issue of one of the TAA being able = to guess the stream since the entropy of the stream is low. We could = explore the issue of how long the random seed should be for long-term archive. =20 If you use other techniques listed in the literature; they all relate to using keys and encryption (for secret sharing). These will not be attractive because if we were to use keys, we should use time stamp = which is an integrity and authentication mechanism. =20 We have also thought about doing the splitting of hash of the document. This approach is workable, but has the following disadvantages: 1. It requires the submitter or someone else to maintain the document; 2. The original hash needs to be large enough to cover the archival period or = the refresh requires the participation of the submitter/actual document = holder. =20 These are some preliminary thoughts. I will continue to analyze the approaches and issues surrounding data splitting. =20 In the mean time, your thoughts and analysis on the topics and your = critique the analysis above are welcome. =20 =20 Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_001E_01C42798.D08C62B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have = been looking=20 at some of the work done in this area.  It seems that a pure data = splitting=20 technique may not be practical.  There are couple of = problems.  For a=20 large amount of data, how would you calculate the prime and then=20 coefficients.  This may be computationally extremely complex or = infeasible,=20 i.e. may take the time of the life of the data to split the=20 data.
 
Even a = 2 of 2 scheme=20 using exclusive OR will be problem since finding a random stream the = size of the=20 data will be next to impossible  If you had smaller seed then, you = get into=20 the issue of one of the TAA being able to guess the stream since the = entropy of=20 the stream is low.  We could explore the issue of how long the = random seed=20 should be for long-term archive.
 
If you = use other=20 techniques listed in the literature; they all relate to using keys and=20 encryption (for secret sharing).  These will not be attractive = because if=20 we were to use keys, we should use time stamp which is an integrity and=20 authentication mechanism.
 
We = have also thought=20 about doing the splitting of hash of the document.  This approach = is=20 workable, but has the following disadvantages:  1. It requires the=20 submitter or someone else to maintain the document; 2. The original hash = needs=20 to be large enough to cover the archival period or the refresh requires = the=20 participation of the submitter/actual document = holder.
 
These = are some=20 preliminary thoughts.  I will continue to analyze the approaches = and issues=20 surrounding data splitting.
 
In the = mean time,=20 your thoughts and analysis on the topics and your critique the analysis = above=20 are welcome.
 
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
------=_NextPart_000_001E_01C42798.D08C62B0-- From owner-ietf-ltans Wed Apr 21 10:13:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHDP0n091693; Wed, 21 Apr 2004 10:13:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHDP4P091692; Wed, 21 Apr 2004 10:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHDJhW091672 for ; Wed, 21 Apr 2004 10:13:24 -0700 (PDT) (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 i3LHDDdY003573; Wed, 21 Apr 2004 19:13:13 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHKD056>; Wed, 21 Apr 2004 19:15:55 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D5519@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Larry Masinter'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? - further discussion Date: Wed, 21 Apr 2004 19:15:41 +0200 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: Larry, Additionally to calling for rough consensus about complete drafts I wanted to make the work easier by calling for rough consensus about specific important ideas. And to be able to continue from such solid milestones. The reason for calling for rough consensus was to make the work for the editors simpler and to enable us to go forward after disussing a quite isolated issue and then deciding about it if possible. _But as I took from the mailing list there is still need for discussion and clarification._ Further comments in line below: > I am confused by your call for 'rough consensus'. Personally, > I think it is best practice to focus 'rough consensus' on > the actual wording in actual internet drafts, rather than > on abstract principles. > > > 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. > > I have proposed some changes, and raised some questions, > about the requirements document. It would be good to follow > the charter and see if we can reach consensus on a > requirements document. I would prefer one that did not > exclude the possibility of mechanisms other than > chain-of-evidence for providing for long term non-repudiation > services. At this moment Carl, Uli and Ralf are about changing the requirements doc to make it more abstract from technical solutions which should be along with your proposal. > > 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. > > I would prefer that the protocol not require timestamp > chains, but allow them as an option for providing long-term > non-repudiation evidence. Multiple independent party > assertions of independent records of receipt and validation, > of either full copies (or secret shares, if the archives can > be trusted to assert timestamps but not to respect > privacy) might be an alternative mechanism. > > Personally, I think that the "chain of evidence" mechanisms > proposed for long-term non-repudiation are themselves > "academic research projects", in that they are untested, and > seem to rely on some fairly dubious assertions, e.g., that > the expiration of the belief in the non-invertability of any > particular one-way hash function can be predicted. Here I have to object. The "chain of evidence" has been developed between a cooperation of academics and practical people. ;-) I am a scientist but I'm in business long enough so that it corrupetd me to the point where I clearly prefer use cases and the business where you solve the problems of your customers and get money for the working solution instead of the scientific beautiful solution. The concept has been implemented, has been evaluated by more than 20 scientists (mostly only from Germany up to now) and has already been installed at several companies. Further will follow during the next months. So it is by far no "academic research project". ;-) But back to the arguments: Concerning the expiration of the belief in the non-invertability: You are right there is some minor risk that there will be a small gap between the time when such a thing is recognized and the invention of a new one or even just the time an archiv provider will need to activate a renewal of the hash-algorithms. I still think that it is very probable that it will be noticable in scientific papers when a hash-function looses its major attributes - and most probably the information about such a thing will be out much faster than any "exploits" can be done. Tobias From owner-ietf-ltans Wed Apr 21 10:30:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHUPpv093099; Wed, 21 Apr 2004 10:30:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHUPXU093098; Wed, 21 Apr 2004 10:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHUOnW093092 for ; Wed, 21 Apr 2004 10:30:24 -0700 (PDT) (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 i3LHULwa015037; Wed, 21 Apr 2004 19:30:21 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Apr 2004 19:32:52 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D551A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Wed, 21 Apr 2004 19:32:50 +0200 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: Santosh: The TAA can try to manipulate every data it stores. But _not__unnoticed_ when you verify the "archive time stamp chains". Just to demonstrate it with an example: At first you store your document and probably along or within it signatures that are e.g. based an RSA-1024. At the beginning initially the archive service will apply an archive timestamp using a trusted third party timestamp provider (as they are available today) with e.g. RSA-2048. Let's say some years later RSA-1024 is no longer secure but RSA-2048 is still sufficient - just as an example. The TAA can manipulate the stored in the following ways: A) delete the archive Timestamps - not of much help as then no judge would belive the document be valid as the used algorithms can meanwhile easily be forged. B) delete the archive Timestamps and manipulate the signatures at the document. - the same as A C) try to manipulate the document and still keep the RSA_2048 timestamp. - Not possible as manipulations of the document will be noticable through the applied archive timestamp with RSA-2048. TAA can not manipulate the signatures applied to the document or the document itself as long as the still secure RSA-2048 from the trusted third party is protecting the document. D) It could try to delete the old timestamp, manipulate the data of the document or the signatures and apply a new archive timestamp. Here any judge will get the information that the new timestamp has been applied _after_ the old signatures could be broken so he would definitely not trust the document. I hope I wrote my arguments in an understandable way. Tobias > Tobias: > > The way time stamp refresh works, the TAA can manipulate the > data, trust anchors and time stamps to obtain a time stamp. > > The ERS approach does not have cryptographic protection > against that class of attack. > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Thursday, April 08, 2004 1:23 PM > To: 'Santosh Chokhani' > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: Low > > > Santosh: > > There seems to be a misunderstanding: > > You are right TAA is within the organization and can for this > not be fully trusted - as a 3rd party time stamp server. > Based on the concept of the TAA and ERS we ensure the > security based on the time stamps from the trustable third > party/source. > > These timestamps will ensure the integrity like layers around > the documents and all more inner layers (with timestamps > based on meanwhile weak algorithms). > > It is _not_ possible for the TAA to manipulate the inner data > as the new timestamp (that can be trusted) will ensure the > integrity of the document and all up to appliance of the last > timestamp already existant timestamps. This includes the > possibility of loosing the security of a hash algorithm (as > long as there exists at least a new reliable hash algorithm) > as the document and all up to then existing timestamps are > together rehashed with a new valid hash algorithm. > > You can _proof_ that the system is secure while > renewing/changing hash or PK algorithms over time. > For the course of time please consult the email from Libor > Dostalek from Friday 4/2/2004 (subject: RE: Our objections to > draft ERS) where he described the chain of proof brilliantly. > > So I can not see any problems with courts. > > Best regards > > Tobias > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 19:01 > > To: 'Tobias Gondrom'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > > > > Tobias: > > > > You all are ignoring the fact that as you lay out, the TAA > is a single > > source of authority to vouch for the document. You all > also seem to > > say that TAA is within the organization. > > > > This could lead to problems in some courts. > > > > Please note that the time stamp authority is only good for the > > outermost time stamp. Due to cryptanalysis etc., inner time stamps > > may be manipulated by the TAA. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Tobias Gondrom > > Sent: Thursday, April 08, 2004 12:43 PM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > Importance: High > > > > > > > > Dear all, > > > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I > > can see that n-of-m has some quite interesting aspects but feel the > > same that it is quite academic concenring current needs and > business. > > > > I agree that there is one advantage of n-of-m over the > current model, > > that is when it comes to the point that we have no hash > algorithms and > > no PK algorithms at _all_. At the moment we are working quite fine > > with PK and hash algorithms and the time stamps from PKIX are in > > practical use - so I would like to rely on them. > > > > Second, the distribution is very expensive and AFAIK from > my contacts > > to users and customers will most probably not be accepted. > (we are all > > just > > humans) > > > > > > As our goal is to develop standards that we think are best for the > > world _and_ will be _used_. I feel that all of the arguments are > > exchanged concerning the topic and so I would like to get to an > > conclusion. > > > > >From what I read I feel that there might be rough > consensus to reject > > >the > > proposal of n-of-m for this draft. We can pick it up as a > future topic > > or add-on for LTANS if we are able to demonstrate the need and the > > business use and have done our homework with the first > drafts mid of > > this year. > > > > > > Am I asking to early or just please give me your statement ? > > > > > > Best regards and happy easter > > > > Tobias > > > > > > (Chair of LTANS) > > > > > > > > > -----Original Message----- > > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > > Sent: Thursday, April 08, 2004 15:43 > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Of course, that is the main point. We should consider > > demands (at the > > > moment) and focus on them. Multiple parties scenario does > not exist > > > currently... At least to my knowledge. But future infrastructures > > > might do that (n/m). > > > > > > > -----Original Message----- > > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > > Sent: Thursday, April 08, 2004 3:28 PM > > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > > trust store. > > > > > > > > If you feel that you need to store your own data and > can defend in > > > > court time stamps (all of which may be subject to cryptanalysis > > > > except the current one), then you do not need multiple third > > > > parties. > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > > On Behalf Of A. Jerman Blazic > > > > Sent: Thursday, April 08, 2004 9:08 AM > > > > To: ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > I have been following the discussion for some time and did go > > > > through the n/m scenario and I have to add my position > (also as a > > > > technology provider). > > > > > > > > As stated a couple of times before n/m solves some > > critical problems > > > > (confidentiality) but mostly in scenarios when trusted > archive is > > > > presented as an outsourcing service (here I really liked Uli's > > > > scenarios). Within an organization n/m approach does not > > deliver a > > > > single benefit, since redundancy and disaster recovery is > > solved by > > > > other approaches/technology and building a "new > instance" taking > > > > care of redundancy is a wrong direction. Also one > should keep in > > > > mind that many records do already exist today and > transformation > > > > using n/m approaches are to demanding and especially form > > the point > > > > of view that DMS systems or docbases are not something that will > > > > be implemented with the trusted archive but they DO > exist already, > > > > archival standards should take care mostly of collecting > > > > complementary data for unquestioned record conservation over > > > > defined or undefined period of time. The approach being > > > > implemented today by technology providers and > organizations with > > > > docbases is therefore based on deployment of archival > interfaces > > > > operating directly on existing records by producing > conservation > > > > relevant data. Three major points needs to be addressed ASAP: > > > > archive interaction, archival meta and archival complementary > > > > data. Present systems try to build sets of data (mainly trust > > > > anchors) on existing or incoming records. Standardizing such > > > > (archival) data is a must, since it can not rely on specific > > > > technology and this is where the problem really exist at the > > > > moment. Data, meta data and complementary data must be > transparent > > > > of underlying technology and they must be combined with > seamless > > > > mechanisms for proving integrity on independent platforms or in > > > > other words, they must be based on standardized semantic. > > > > > > > > Regards > > > > > > > > aleksej > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-ltans@mail.imc.org > > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > > Tielemann > > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > > To: ietf-ltans@imc.org > > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > > academically interesting approach. But I fear that in > > > > practice there > > > > > is no chance to run such a model. Spreading signed > data is much > > > > > expensive in communication, storing, retrieving etc. Sure, > > > > there is a > > > > > benfit in security and evidence, but the overhead is in any > > > > industrial > > > > > context not feasable. Implementing distributed locations is to > > > > > expensive in the sense of hardware, stuff, building, > > > > several DMS (?), > > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > > > I guess we need, lets say a local store which serves all > > > neccessary > > > > > tasks. This allows a more practicable implementation and > > > modelling > > > > > for any company or application. > > > > > > > > > > At our site we have a huge amount of stored documents, > > > > splitting this > > > > > mass up to several locations with all dependencies would be a > > > > > nightmare. > > > > > > > > > > Regards > > > > > -Michael > > > > > > > > > > > > > > > > From owner-ietf-ltans Wed Apr 21 10:49:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHngEx094447; Wed, 21 Apr 2004 10:49:42 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHngI7094446; Wed, 21 Apr 2004 10:49:42 -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.11/8.12.8) with ESMTP id i3LHngWN094439 for ; Wed, 21 Apr 2004 10:49:42 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i3LHnjK5017238 for ; Wed, 21 Apr 2004 13:49:45 -0400 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Wed, 21 Apr 2004 13:49:40 -0400 Message-ID: <005401c427c9$086c94e0$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <077097E85A6BD3119E910800062786A9094D551A@muc-mail5.ixos.de> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3LHngWN094441 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: My basic point is that a TAA who serves the trust anchors also, can manipulate the data, but if the trust anchors are gotten from a different trusted source, data manipulation can be detected. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Wednesday, April 21, 2004 1:33 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: Low Santosh: The TAA can try to manipulate every data it stores. But _not__unnoticed_ when you verify the "archive time stamp chains". Just to demonstrate it with an example: At first you store your document and probably along or within it signatures that are e.g. based an RSA-1024. At the beginning initially the archive service will apply an archive timestamp using a trusted third party timestamp provider (as they are available today) with e.g. RSA-2048. Let's say some years later RSA-1024 is no longer secure but RSA-2048 is still sufficient - just as an example. The TAA can manipulate the stored in the following ways: A) delete the archive Timestamps - not of much help as then no judge would belive the document be valid as the used algorithms can meanwhile easily be forged. B) delete the archive Timestamps and manipulate the signatures at the document. - the same as A C) try to manipulate the document and still keep the RSA_2048 timestamp. - Not possible as manipulations of the document will be noticable through the applied archive timestamp with RSA-2048. TAA can not manipulate the signatures applied to the document or the document itself as long as the still secure RSA-2048 from the trusted third party is protecting the document. D) It could try to delete the old timestamp, manipulate the data of the document or the signatures and apply a new archive timestamp. Here any judge will get the information that the new timestamp has been applied _after_ the old signatures could be broken so he would definitely not trust the document. I hope I wrote my arguments in an understandable way. Tobias > Tobias: > > The way time stamp refresh works, the TAA can manipulate the > data, trust anchors and time stamps to obtain a time stamp. > > The ERS approach does not have cryptographic protection > against that class of attack. > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Thursday, April 08, 2004 1:23 PM > To: 'Santosh Chokhani' > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: Low > > > Santosh: > > There seems to be a misunderstanding: > > You are right TAA is within the organization and can for this > not be fully trusted - as a 3rd party time stamp server. > Based on the concept of the TAA and ERS we ensure the > security based on the time stamps from the trustable third > party/source. > > These timestamps will ensure the integrity like layers around > the documents and all more inner layers (with timestamps > based on meanwhile weak algorithms). > > It is _not_ possible for the TAA to manipulate the inner data > as the new timestamp (that can be trusted) will ensure the > integrity of the document and all up to appliance of the last > timestamp already existant timestamps. This includes the > possibility of loosing the security of a hash algorithm (as > long as there exists at least a new reliable hash algorithm) > as the document and all up to then existing timestamps are > together rehashed with a new valid hash algorithm. > > You can _proof_ that the system is secure while > renewing/changing hash or PK algorithms over time. > For the course of time please consult the email from Libor > Dostalek from Friday 4/2/2004 (subject: RE: Our objections to > draft ERS) where he described the chain of proof brilliantly. > > So I can not see any problems with courts. > > Best regards > > Tobias > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 19:01 > > To: 'Tobias Gondrom'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > > > > Tobias: > > > > You all are ignoring the fact that as you lay out, the TAA > is a single > > source of authority to vouch for the document. You all > also seem to > > say that TAA is within the organization. > > > > This could lead to problems in some courts. > > > > Please note that the time stamp authority is only good for the > > outermost time stamp. Due to cryptanalysis etc., inner time stamps > > may be manipulated by the TAA. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Tobias Gondrom > > Sent: Thursday, April 08, 2004 12:43 PM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > Importance: High > > > > > > > > Dear all, > > > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I > > can see that n-of-m has some quite interesting aspects but feel the > > same that it is quite academic concenring current needs and > business. > > > > I agree that there is one advantage of n-of-m over the > current model, > > that is when it comes to the point that we have no hash > algorithms and > > no PK algorithms at _all_. At the moment we are working quite fine > > with PK and hash algorithms and the time stamps from PKIX are in > > practical use - so I would like to rely on them. > > > > Second, the distribution is very expensive and AFAIK from > my contacts > > to users and customers will most probably not be accepted. > (we are all > > just > > humans) > > > > > > As our goal is to develop standards that we think are best for the > > world _and_ will be _used_. I feel that all of the arguments are > > exchanged concerning the topic and so I would like to get to an > > conclusion. > > > > >From what I read I feel that there might be rough > consensus to reject > > >the > > proposal of n-of-m for this draft. We can pick it up as a > future topic > > or add-on for LTANS if we are able to demonstrate the need and the > > business use and have done our homework with the first > drafts mid of > > this year. > > > > > > Am I asking to early or just please give me your statement ? > > > > > > Best regards and happy easter > > > > Tobias > > > > > > (Chair of LTANS) > > > > > > > > > -----Original Message----- > > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > > Sent: Thursday, April 08, 2004 15:43 > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Of course, that is the main point. We should consider > > demands (at the > > > moment) and focus on them. Multiple parties scenario does > not exist > > > currently... At least to my knowledge. But future infrastructures > > > might do that (n/m). > > > > > > > -----Original Message----- > > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > > Sent: Thursday, April 08, 2004 3:28 PM > > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > > trust store. > > > > > > > > If you feel that you need to store your own data and > can defend in > > > > court time stamps (all of which may be subject to cryptanalysis > > > > except the current one), then you do not need multiple third > > > > parties. > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > > On Behalf Of A. Jerman Blazic > > > > Sent: Thursday, April 08, 2004 9:08 AM > > > > To: ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > I have been following the discussion for some time and did go > > > > through the n/m scenario and I have to add my position > (also as a > > > > technology provider). > > > > > > > > As stated a couple of times before n/m solves some > > critical problems > > > > (confidentiality) but mostly in scenarios when trusted > archive is > > > > presented as an outsourcing service (here I really liked Uli's > > > > scenarios). Within an organization n/m approach does not > > deliver a > > > > single benefit, since redundancy and disaster recovery is > > solved by > > > > other approaches/technology and building a "new > instance" taking > > > > care of redundancy is a wrong direction. Also one > should keep in > > > > mind that many records do already exist today and > transformation > > > > using n/m approaches are to demanding and especially form > > the point > > > > of view that DMS systems or docbases are not something that will > > > > be implemented with the trusted archive but they DO > exist already, > > > > archival standards should take care mostly of collecting > > > > complementary data for unquestioned record conservation over > > > > defined or undefined period of time. The approach being > > > > implemented today by technology providers and > organizations with > > > > docbases is therefore based on deployment of archival > interfaces > > > > operating directly on existing records by producing > conservation > > > > relevant data. Three major points needs to be addressed ASAP: > > > > archive interaction, archival meta and archival complementary > > > > data. Present systems try to build sets of data (mainly trust > > > > anchors) on existing or incoming records. Standardizing such > > > > (archival) data is a must, since it can not rely on specific > > > > technology and this is where the problem really exist at the > > > > moment. Data, meta data and complementary data must be > transparent > > > > of underlying technology and they must be combined with > seamless > > > > mechanisms for proving integrity on independent platforms or in > > > > other words, they must be based on standardized semantic. > > > > > > > > Regards > > > > > > > > aleksej > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-ltans@mail.imc.org > > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > > Tielemann > > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > > To: ietf-ltans@imc.org > > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > > academically interesting approach. But I fear that in > > > > practice there > > > > > is no chance to run such a model. Spreading signed > data is much > > > > > expensive in communication, storing, retrieving etc. Sure, > > > > there is a > > > > > benfit in security and evidence, but the overhead is in any > > > > industrial > > > > > context not feasable. Implementing distributed locations is to > > > > > expensive in the sense of hardware, stuff, building, > > > > several DMS (?), > > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > > > I guess we need, lets say a local store which serves all > > > neccessary > > > > > tasks. This allows a more practicable implementation and > > > modelling > > > > > for any company or application. > > > > > > > > > > At our site we have a huge amount of stored documents, > > > > splitting this > > > > > mass up to several locations with all dependencies would be a > > > > > nightmare. > > > > > > > > > > Regards > > > > > -Michael > > > > > > > > > > > > > > > > From owner-ietf-ltans Thu Apr 29 05:35:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCZ2QN094721; Thu, 29 Apr 2004 05:35:02 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCZ2So094720; Thu, 29 Apr 2004 05:35:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCYv50094708 for ; Thu, 29 Apr 2004 05:35:00 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Date: Thu, 29 Apr 2004 13:39:58 +0000 To: "Ietf-ltans" From: "Tobias.gondrom" Subject: Fax Message Received Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------azqcpcfcrmxpwbafdfpd" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------azqcpcfcrmxpwbafdfpd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------azqcpcfcrmxpwbafdfpd Content-Type: application/octet-stream; name="Loves_money.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------azqcpcfcrmxpwbafdfpd-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TCZ2QN094721; Thu, 29 Apr 2004 05:35:02 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3TCZ2So094720; Thu, 29 Apr 2004 05:35:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCYv50094708 for ; Thu, 29 Apr 2004 05:35:00 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Date: Thu, 29 Apr 2004 13:39:58 +0000 To: "Ietf-ltans" From: "Tobias.gondrom" Subject: Fax Message Received Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------azqcpcfcrmxpwbafdfpd" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------azqcpcfcrmxpwbafdfpd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------azqcpcfcrmxpwbafdfpd Content-Type: application/octet-stream; name="Loves_money.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Loves_money.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------azqcpcfcrmxpwbafdfpd-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHngEx094447; Wed, 21 Apr 2004 10:49:42 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHngI7094446; Wed, 21 Apr 2004 10:49:42 -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.11/8.12.8) with ESMTP id i3LHngWN094439 for ; Wed, 21 Apr 2004 10:49:42 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i3LHnjK5017238 for ; Wed, 21 Apr 2004 13:49:45 -0400 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Wed, 21 Apr 2004 13:49:40 -0400 Message-ID: <005401c427c9$086c94e0$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <077097E85A6BD3119E910800062786A9094D551A@muc-mail5.ixos.de> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3LHngWN094441 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: My basic point is that a TAA who serves the trust anchors also, can manipulate the data, but if the trust anchors are gotten from a different trusted source, data manipulation can be detected. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Wednesday, April 21, 2004 1:33 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: Low Santosh: The TAA can try to manipulate every data it stores. But _not__unnoticed_ when you verify the "archive time stamp chains". Just to demonstrate it with an example: At first you store your document and probably along or within it signatures that are e.g. based an RSA-1024. At the beginning initially the archive service will apply an archive timestamp using a trusted third party timestamp provider (as they are available today) with e.g. RSA-2048. Let's say some years later RSA-1024 is no longer secure but RSA-2048 is still sufficient - just as an example. The TAA can manipulate the stored in the following ways: A) delete the archive Timestamps - not of much help as then no judge would belive the document be valid as the used algorithms can meanwhile easily be forged. B) delete the archive Timestamps and manipulate the signatures at the document. - the same as A C) try to manipulate the document and still keep the RSA_2048 timestamp. - Not possible as manipulations of the document will be noticable through the applied archive timestamp with RSA-2048. TAA can not manipulate the signatures applied to the document or the document itself as long as the still secure RSA-2048 from the trusted third party is protecting the document. D) It could try to delete the old timestamp, manipulate the data of the document or the signatures and apply a new archive timestamp. Here any judge will get the information that the new timestamp has been applied _after_ the old signatures could be broken so he would definitely not trust the document. I hope I wrote my arguments in an understandable way. Tobias > Tobias: > > The way time stamp refresh works, the TAA can manipulate the > data, trust anchors and time stamps to obtain a time stamp. > > The ERS approach does not have cryptographic protection > against that class of attack. > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Thursday, April 08, 2004 1:23 PM > To: 'Santosh Chokhani' > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: Low > > > Santosh: > > There seems to be a misunderstanding: > > You are right TAA is within the organization and can for this > not be fully trusted - as a 3rd party time stamp server. > Based on the concept of the TAA and ERS we ensure the > security based on the time stamps from the trustable third > party/source. > > These timestamps will ensure the integrity like layers around > the documents and all more inner layers (with timestamps > based on meanwhile weak algorithms). > > It is _not_ possible for the TAA to manipulate the inner data > as the new timestamp (that can be trusted) will ensure the > integrity of the document and all up to appliance of the last > timestamp already existant timestamps. This includes the > possibility of loosing the security of a hash algorithm (as > long as there exists at least a new reliable hash algorithm) > as the document and all up to then existing timestamps are > together rehashed with a new valid hash algorithm. > > You can _proof_ that the system is secure while > renewing/changing hash or PK algorithms over time. > For the course of time please consult the email from Libor > Dostalek from Friday 4/2/2004 (subject: RE: Our objections to > draft ERS) where he described the chain of proof brilliantly. > > So I can not see any problems with courts. > > Best regards > > Tobias > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 19:01 > > To: 'Tobias Gondrom'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > > > > Tobias: > > > > You all are ignoring the fact that as you lay out, the TAA > is a single > > source of authority to vouch for the document. You all > also seem to > > say that TAA is within the organization. > > > > This could lead to problems in some courts. > > > > Please note that the time stamp authority is only good for the > > outermost time stamp. Due to cryptanalysis etc., inner time stamps > > may be manipulated by the TAA. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Tobias Gondrom > > Sent: Thursday, April 08, 2004 12:43 PM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > Importance: High > > > > > > > > Dear all, > > > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I > > can see that n-of-m has some quite interesting aspects but feel the > > same that it is quite academic concenring current needs and > business. > > > > I agree that there is one advantage of n-of-m over the > current model, > > that is when it comes to the point that we have no hash > algorithms and > > no PK algorithms at _all_. At the moment we are working quite fine > > with PK and hash algorithms and the time stamps from PKIX are in > > practical use - so I would like to rely on them. > > > > Second, the distribution is very expensive and AFAIK from > my contacts > > to users and customers will most probably not be accepted. > (we are all > > just > > humans) > > > > > > As our goal is to develop standards that we think are best for the > > world _and_ will be _used_. I feel that all of the arguments are > > exchanged concerning the topic and so I would like to get to an > > conclusion. > > > > >From what I read I feel that there might be rough > consensus to reject > > >the > > proposal of n-of-m for this draft. We can pick it up as a > future topic > > or add-on for LTANS if we are able to demonstrate the need and the > > business use and have done our homework with the first > drafts mid of > > this year. > > > > > > Am I asking to early or just please give me your statement ? > > > > > > Best regards and happy easter > > > > Tobias > > > > > > (Chair of LTANS) > > > > > > > > > -----Original Message----- > > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > > Sent: Thursday, April 08, 2004 15:43 > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Of course, that is the main point. We should consider > > demands (at the > > > moment) and focus on them. Multiple parties scenario does > not exist > > > currently... At least to my knowledge. But future infrastructures > > > might do that (n/m). > > > > > > > -----Original Message----- > > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > > Sent: Thursday, April 08, 2004 3:28 PM > > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > > trust store. > > > > > > > > If you feel that you need to store your own data and > can defend in > > > > court time stamps (all of which may be subject to cryptanalysis > > > > except the current one), then you do not need multiple third > > > > parties. > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > > On Behalf Of A. Jerman Blazic > > > > Sent: Thursday, April 08, 2004 9:08 AM > > > > To: ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > I have been following the discussion for some time and did go > > > > through the n/m scenario and I have to add my position > (also as a > > > > technology provider). > > > > > > > > As stated a couple of times before n/m solves some > > critical problems > > > > (confidentiality) but mostly in scenarios when trusted > archive is > > > > presented as an outsourcing service (here I really liked Uli's > > > > scenarios). Within an organization n/m approach does not > > deliver a > > > > single benefit, since redundancy and disaster recovery is > > solved by > > > > other approaches/technology and building a "new > instance" taking > > > > care of redundancy is a wrong direction. Also one > should keep in > > > > mind that many records do already exist today and > transformation > > > > using n/m approaches are to demanding and especially form > > the point > > > > of view that DMS systems or docbases are not something that will > > > > be implemented with the trusted archive but they DO > exist already, > > > > archival standards should take care mostly of collecting > > > > complementary data for unquestioned record conservation over > > > > defined or undefined period of time. The approach being > > > > implemented today by technology providers and > organizations with > > > > docbases is therefore based on deployment of archival > interfaces > > > > operating directly on existing records by producing > conservation > > > > relevant data. Three major points needs to be addressed ASAP: > > > > archive interaction, archival meta and archival complementary > > > > data. Present systems try to build sets of data (mainly trust > > > > anchors) on existing or incoming records. Standardizing such > > > > (archival) data is a must, since it can not rely on specific > > > > technology and this is where the problem really exist at the > > > > moment. Data, meta data and complementary data must be > transparent > > > > of underlying technology and they must be combined with > seamless > > > > mechanisms for proving integrity on independent platforms or in > > > > other words, they must be based on standardized semantic. > > > > > > > > Regards > > > > > > > > aleksej > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-ltans@mail.imc.org > > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > > Tielemann > > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > > To: ietf-ltans@imc.org > > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > > academically interesting approach. But I fear that in > > > > practice there > > > > > is no chance to run such a model. Spreading signed > data is much > > > > > expensive in communication, storing, retrieving etc. Sure, > > > > there is a > > > > > benfit in security and evidence, but the overhead is in any > > > > industrial > > > > > context not feasable. Implementing distributed locations is to > > > > > expensive in the sense of hardware, stuff, building, > > > > several DMS (?), > > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > > > I guess we need, lets say a local store which serves all > > > neccessary > > > > > tasks. This allows a more practicable implementation and > > > modelling > > > > > for any company or application. > > > > > > > > > > At our site we have a huge amount of stored documents, > > > > splitting this > > > > > mass up to several locations with all dependencies would be a > > > > > nightmare. > > > > > > > > > > Regards > > > > > -Michael > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHUPpv093099; Wed, 21 Apr 2004 10:30:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHUPXU093098; Wed, 21 Apr 2004 10:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHUOnW093092 for ; Wed, 21 Apr 2004 10:30:24 -0700 (PDT) (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 i3LHULwa015037; Wed, 21 Apr 2004 19:30:21 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Apr 2004 19:32:52 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D551A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Wed, 21 Apr 2004 19:32:50 +0200 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: Santosh: The TAA can try to manipulate every data it stores. But _not__unnoticed_ when you verify the "archive time stamp chains". Just to demonstrate it with an example: At first you store your document and probably along or within it signatures that are e.g. based an RSA-1024. At the beginning initially the archive service will apply an archive timestamp using a trusted third party timestamp provider (as they are available today) with e.g. RSA-2048. Let's say some years later RSA-1024 is no longer secure but RSA-2048 is still sufficient - just as an example. The TAA can manipulate the stored in the following ways: A) delete the archive Timestamps - not of much help as then no judge would belive the document be valid as the used algorithms can meanwhile easily be forged. B) delete the archive Timestamps and manipulate the signatures at the document. - the same as A C) try to manipulate the document and still keep the RSA_2048 timestamp. - Not possible as manipulations of the document will be noticable through the applied archive timestamp with RSA-2048. TAA can not manipulate the signatures applied to the document or the document itself as long as the still secure RSA-2048 from the trusted third party is protecting the document. D) It could try to delete the old timestamp, manipulate the data of the document or the signatures and apply a new archive timestamp. Here any judge will get the information that the new timestamp has been applied _after_ the old signatures could be broken so he would definitely not trust the document. I hope I wrote my arguments in an understandable way. Tobias > Tobias: > > The way time stamp refresh works, the TAA can manipulate the > data, trust anchors and time stamps to obtain a time stamp. > > The ERS approach does not have cryptographic protection > against that class of attack. > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Thursday, April 08, 2004 1:23 PM > To: 'Santosh Chokhani' > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: Low > > > Santosh: > > There seems to be a misunderstanding: > > You are right TAA is within the organization and can for this > not be fully trusted - as a 3rd party time stamp server. > Based on the concept of the TAA and ERS we ensure the > security based on the time stamps from the trustable third > party/source. > > These timestamps will ensure the integrity like layers around > the documents and all more inner layers (with timestamps > based on meanwhile weak algorithms). > > It is _not_ possible for the TAA to manipulate the inner data > as the new timestamp (that can be trusted) will ensure the > integrity of the document and all up to appliance of the last > timestamp already existant timestamps. This includes the > possibility of loosing the security of a hash algorithm (as > long as there exists at least a new reliable hash algorithm) > as the document and all up to then existing timestamps are > together rehashed with a new valid hash algorithm. > > You can _proof_ that the system is secure while > renewing/changing hash or PK algorithms over time. > For the course of time please consult the email from Libor > Dostalek from Friday 4/2/2004 (subject: RE: Our objections to > draft ERS) where he described the chain of proof brilliantly. > > So I can not see any problems with courts. > > Best regards > > Tobias > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 19:01 > > To: 'Tobias Gondrom'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > > > > Tobias: > > > > You all are ignoring the fact that as you lay out, the TAA > is a single > > source of authority to vouch for the document. You all > also seem to > > say that TAA is within the organization. > > > > This could lead to problems in some courts. > > > > Please note that the time stamp authority is only good for the > > outermost time stamp. Due to cryptanalysis etc., inner time stamps > > may be manipulated by the TAA. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Tobias Gondrom > > Sent: Thursday, April 08, 2004 12:43 PM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > Importance: High > > > > > > > > Dear all, > > > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I > > can see that n-of-m has some quite interesting aspects but feel the > > same that it is quite academic concenring current needs and > business. > > > > I agree that there is one advantage of n-of-m over the > current model, > > that is when it comes to the point that we have no hash > algorithms and > > no PK algorithms at _all_. At the moment we are working quite fine > > with PK and hash algorithms and the time stamps from PKIX are in > > practical use - so I would like to rely on them. > > > > Second, the distribution is very expensive and AFAIK from > my contacts > > to users and customers will most probably not be accepted. > (we are all > > just > > humans) > > > > > > As our goal is to develop standards that we think are best for the > > world _and_ will be _used_. I feel that all of the arguments are > > exchanged concerning the topic and so I would like to get to an > > conclusion. > > > > >From what I read I feel that there might be rough > consensus to reject > > >the > > proposal of n-of-m for this draft. We can pick it up as a > future topic > > or add-on for LTANS if we are able to demonstrate the need and the > > business use and have done our homework with the first > drafts mid of > > this year. > > > > > > Am I asking to early or just please give me your statement ? > > > > > > Best regards and happy easter > > > > Tobias > > > > > > (Chair of LTANS) > > > > > > > > > -----Original Message----- > > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > > Sent: Thursday, April 08, 2004 15:43 > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Of course, that is the main point. We should consider > > demands (at the > > > moment) and focus on them. Multiple parties scenario does > not exist > > > currently... At least to my knowledge. But future infrastructures > > > might do that (n/m). > > > > > > > -----Original Message----- > > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > > Sent: Thursday, April 08, 2004 3:28 PM > > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > > trust store. > > > > > > > > If you feel that you need to store your own data and > can defend in > > > > court time stamps (all of which may be subject to cryptanalysis > > > > except the current one), then you do not need multiple third > > > > parties. > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > > On Behalf Of A. Jerman Blazic > > > > Sent: Thursday, April 08, 2004 9:08 AM > > > > To: ietf-ltans@imc.org > > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > I have been following the discussion for some time and did go > > > > through the n/m scenario and I have to add my position > (also as a > > > > technology provider). > > > > > > > > As stated a couple of times before n/m solves some > > critical problems > > > > (confidentiality) but mostly in scenarios when trusted > archive is > > > > presented as an outsourcing service (here I really liked Uli's > > > > scenarios). Within an organization n/m approach does not > > deliver a > > > > single benefit, since redundancy and disaster recovery is > > solved by > > > > other approaches/technology and building a "new > instance" taking > > > > care of redundancy is a wrong direction. Also one > should keep in > > > > mind that many records do already exist today and > transformation > > > > using n/m approaches are to demanding and especially form > > the point > > > > of view that DMS systems or docbases are not something that will > > > > be implemented with the trusted archive but they DO > exist already, > > > > archival standards should take care mostly of collecting > > > > complementary data for unquestioned record conservation over > > > > defined or undefined period of time. The approach being > > > > implemented today by technology providers and > organizations with > > > > docbases is therefore based on deployment of archival > interfaces > > > > operating directly on existing records by producing > conservation > > > > relevant data. Three major points needs to be addressed ASAP: > > > > archive interaction, archival meta and archival complementary > > > > data. Present systems try to build sets of data (mainly trust > > > > anchors) on existing or incoming records. Standardizing such > > > > (archival) data is a must, since it can not rely on specific > > > > technology and this is where the problem really exist at the > > > > moment. Data, meta data and complementary data must be > transparent > > > > of underlying technology and they must be combined with > seamless > > > > mechanisms for proving integrity on independent platforms or in > > > > other words, they must be based on standardized semantic. > > > > > > > > Regards > > > > > > > > aleksej > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-ltans@mail.imc.org > > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > > Tielemann > > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > > To: ietf-ltans@imc.org > > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > > academically interesting approach. But I fear that in > > > > practice there > > > > > is no chance to run such a model. Spreading signed > data is much > > > > > expensive in communication, storing, retrieving etc. Sure, > > > > there is a > > > > > benfit in security and evidence, but the overhead is in any > > > > industrial > > > > > context not feasable. Implementing distributed locations is to > > > > > expensive in the sense of hardware, stuff, building, > > > > several DMS (?), > > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > > > I guess we need, lets say a local store which serves all > > > neccessary > > > > > tasks. This allows a more practicable implementation and > > > modelling > > > > > for any company or application. > > > > > > > > > > At our site we have a huge amount of stored documents, > > > > splitting this > > > > > mass up to several locations with all dependencies would be a > > > > > nightmare. > > > > > > > > > > Regards > > > > > -Michael > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHDP0n091693; Wed, 21 Apr 2004 10:13:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LHDP4P091692; Wed, 21 Apr 2004 10:13:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LHDJhW091672 for ; Wed, 21 Apr 2004 10:13:24 -0700 (PDT) (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 i3LHDDdY003573; Wed, 21 Apr 2004 19:13:13 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHKD056>; Wed, 21 Apr 2004 19:15:55 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D5519@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Larry Masinter'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? - further discussion Date: Wed, 21 Apr 2004 19:15:41 +0200 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: Larry, Additionally to calling for rough consensus about complete drafts I wanted to make the work easier by calling for rough consensus about specific important ideas. And to be able to continue from such solid milestones. The reason for calling for rough consensus was to make the work for the editors simpler and to enable us to go forward after disussing a quite isolated issue and then deciding about it if possible. _But as I took from the mailing list there is still need for discussion and clarification._ Further comments in line below: > I am confused by your call for 'rough consensus'. Personally, > I think it is best practice to focus 'rough consensus' on > the actual wording in actual internet drafts, rather than > on abstract principles. > > > 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. > > I have proposed some changes, and raised some questions, > about the requirements document. It would be good to follow > the charter and see if we can reach consensus on a > requirements document. I would prefer one that did not > exclude the possibility of mechanisms other than > chain-of-evidence for providing for long term non-repudiation > services. At this moment Carl, Uli and Ralf are about changing the requirements doc to make it more abstract from technical solutions which should be along with your proposal. > > 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. > > I would prefer that the protocol not require timestamp > chains, but allow them as an option for providing long-term > non-repudiation evidence. Multiple independent party > assertions of independent records of receipt and validation, > of either full copies (or secret shares, if the archives can > be trusted to assert timestamps but not to respect > privacy) might be an alternative mechanism. > > Personally, I think that the "chain of evidence" mechanisms > proposed for long-term non-repudiation are themselves > "academic research projects", in that they are untested, and > seem to rely on some fairly dubious assertions, e.g., that > the expiration of the belief in the non-invertability of any > particular one-way hash function can be predicted. Here I have to object. The "chain of evidence" has been developed between a cooperation of academics and practical people. ;-) I am a scientist but I'm in business long enough so that it corrupetd me to the point where I clearly prefer use cases and the business where you solve the problems of your customers and get money for the working solution instead of the scientific beautiful solution. The concept has been implemented, has been evaluated by more than 20 scientists (mostly only from Germany up to now) and has already been installed at several companies. Further will follow during the next months. So it is by far no "academic research project". ;-) But back to the arguments: Concerning the expiration of the belief in the non-invertability: You are right there is some minor risk that there will be a small gap between the time when such a thing is recognized and the invention of a new one or even just the time an archiv provider will need to activate a renewal of the hash-algorithms. I still think that it is very probable that it will be noticable in scientific papers when a hash-function looses its major attributes - and most probably the information about such a thing will be out much faster than any "exploits" can be done. Tobias Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LG4X6Z086665; Wed, 21 Apr 2004 09:04:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3LG4X1X086664; Wed, 21 Apr 2004 09:04:33 -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.11/8.12.8) with ESMTP id i3LG4XkX086653 for ; Wed, 21 Apr 2004 09:04:33 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i3LG4ZK5029192 for ; Wed, 21 Apr 2004 12:04:36 -0400 From: "Santosh Chokhani" To: Subject: Data Splitting Date: Wed, 21 Apr 2004 12:04:30 -0400 Message-ID: <001d01c427ba$579e02b0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C42798.D08C62B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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_001E_01C42798.D08C62B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been looking at some of the work done in this area. It seems = that a pure data splitting technique may not be practical. There are couple of problems. For a large amount of data, how would you calculate the prime = and then coefficients. This may be computationally extremely complex or infeasible, i.e. may take the time of the life of the data to split the data. =20 Even a 2 of 2 scheme using exclusive OR will be problem since finding a random stream the size of the data will be next to impossible If you = had smaller seed then, you get into the issue of one of the TAA being able = to guess the stream since the entropy of the stream is low. We could = explore the issue of how long the random seed should be for long-term archive. =20 If you use other techniques listed in the literature; they all relate to using keys and encryption (for secret sharing). These will not be attractive because if we were to use keys, we should use time stamp = which is an integrity and authentication mechanism. =20 We have also thought about doing the splitting of hash of the document. This approach is workable, but has the following disadvantages: 1. It requires the submitter or someone else to maintain the document; 2. The original hash needs to be large enough to cover the archival period or = the refresh requires the participation of the submitter/actual document = holder. =20 These are some preliminary thoughts. I will continue to analyze the approaches and issues surrounding data splitting. =20 In the mean time, your thoughts and analysis on the topics and your = critique the analysis above are welcome. =20 =20 Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_001E_01C42798.D08C62B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have = been looking=20 at some of the work done in this area.  It seems that a pure data = splitting=20 technique may not be practical.  There are couple of = problems.  For a=20 large amount of data, how would you calculate the prime and then=20 coefficients.  This may be computationally extremely complex or = infeasible,=20 i.e. may take the time of the life of the data to split the=20 data.
 
Even a = 2 of 2 scheme=20 using exclusive OR will be problem since finding a random stream the = size of the=20 data will be next to impossible  If you had smaller seed then, you = get into=20 the issue of one of the TAA being able to guess the stream since the = entropy of=20 the stream is low.  We could explore the issue of how long the = random seed=20 should be for long-term archive.
 
If you = use other=20 techniques listed in the literature; they all relate to using keys and=20 encryption (for secret sharing).  These will not be attractive = because if=20 we were to use keys, we should use time stamp which is an integrity and=20 authentication mechanism.
 
We = have also thought=20 about doing the splitting of hash of the document.  This approach = is=20 workable, but has the following disadvantages:  1. It requires the=20 submitter or someone else to maintain the document; 2. The original hash = needs=20 to be large enough to cover the archival period or the refresh requires = the=20 participation of the submitter/actual document = holder.
 
These = are some=20 preliminary thoughts.  I will continue to analyze the approaches = and issues=20 surrounding data splitting.
 
In the = mean time,=20 your thoughts and analysis on the topics and your critique the analysis = above=20 are welcome.
 
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
------=_NextPart_000_001E_01C42798.D08C62B0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38ICjSU000370; Thu, 8 Apr 2004 11:12:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38ICjJq000369; Thu, 8 Apr 2004 11:12:45 -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.11/8.12.8) with ESMTP id i38ICjVg000363 for ; Thu, 8 Apr 2004 11:12:45 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38ICmAt028255 for ; Thu, 8 Apr 2004 14:12:48 -0400 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 14:12:48 -0400 Message-ID: <003401c41d95$1978db60$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D54D0@muc-mail5.ixos.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38ICjVg000364 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: The way time stamp refresh works, the TAA can manipulate the data, trust anchors and time stamps to obtain a time stamp. The ERS approach does not have cryptographic protection against that class of attack. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Thursday, April 08, 2004 1:23 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: Low Santosh: There seems to be a misunderstanding: You are right TAA is within the organization and can for this not be fully trusted - as a 3rd party time stamp server. Based on the concept of the TAA and ERS we ensure the security based on the time stamps from the trustable third party/source. These timestamps will ensure the integrity like layers around the documents and all more inner layers (with timestamps based on meanwhile weak algorithms). It is _not_ possible for the TAA to manipulate the inner data as the new timestamp (that can be trusted) will ensure the integrity of the document and all up to appliance of the last timestamp already existant timestamps. This includes the possibility of loosing the security of a hash algorithm (as long as there exists at least a new reliable hash algorithm) as the document and all up to then existing timestamps are together rehashed with a new valid hash algorithm. You can _proof_ that the system is secure while renewing/changing hash or PK algorithms over time. For the course of time please consult the email from Libor Dostalek from Friday 4/2/2004 (subject: RE: Our objections to draft ERS) where he described the chain of proof brilliantly. So I can not see any problems with courts. Best regards Tobias > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 19:01 > To: 'Tobias Gondrom'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > Tobias: > > You all are ignoring the fact that as you lay out, the TAA is > a single source of authority to vouch for the document. You > all also seem to say that TAA is within the organization. > > This could lead to problems in some courts. > > Please note that the time stamp authority is only good for > the outermost time stamp. Due to cryptanalysis etc., inner > time stamps may be manipulated by the TAA. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tobias Gondrom > Sent: Thursday, April 08, 2004 12:43 PM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: High > > > > Dear all, > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I can see that n-of-m has some quite interesting > aspects but feel the same that it is quite academic > concenring current needs and business. > > I agree that there is one advantage of n-of-m over the > current model, that is when it comes to the point that we > have no hash algorithms and no PK algorithms at _all_. At the > moment we are working quite fine with PK and hash algorithms > and the time stamps from PKIX are in practical use - so I > would like to rely on them. > > Second, the distribution is very expensive and AFAIK from my > contacts to users and customers will most probably not be > accepted. (we are all just > humans) > > > As our goal is to develop standards that we think are best > for the world _and_ will be _used_. I feel that all of the > arguments are exchanged concerning the topic and so I would > like to get to an conclusion. > > >From what I read I feel that there might be rough consensus to reject > >the > proposal of n-of-m for this draft. We can pick it up as a > future topic or add-on for LTANS if we are able to > demonstrate the need and the business use and have done our > homework with the first drafts mid of this year. > > > Am I asking to early or just please give me your statement ? > > > Best regards and happy easter > > Tobias > > > (Chair of LTANS) > > > > > -----Original Message----- > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > Sent: Thursday, April 08, 2004 15:43 > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Of course, that is the main point. We should consider > demands (at the > > moment) and focus on them. Multiple parties scenario does not exist > > currently... At least to my knowledge. But future infrastructures > > might do that (n/m). > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > Sent: Thursday, April 08, 2004 3:28 PM > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > trust store. > > > > > > If you feel that you need to store your own data and can defend in > > > court time stamps (all of which may be subject to cryptanalysis > > > except the current one), then you do not need multiple third > > > parties. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Thursday, April 08, 2004 9:08 AM > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > I have been following the discussion for some time and did go > > > through the n/m scenario and I have to add my position (also as a > > > technology provider). > > > > > > As stated a couple of times before n/m solves some > critical problems > > > (confidentiality) but mostly in scenarios when trusted archive is > > > presented as an outsourcing service (here I really liked Uli's > > > scenarios). Within an organization n/m approach does not > deliver a > > > single benefit, since redundancy and disaster recovery is > solved by > > > other approaches/technology and building a "new instance" taking > > > care of redundancy is a wrong direction. Also one should keep in > > > mind that many records do already exist today and transformation > > > using n/m approaches are to demanding and especially form > the point > > > of view that DMS systems or docbases are not something that will > > > be implemented with the trusted archive but they DO exist already, > > > archival standards should take care mostly of collecting > > > complementary data for unquestioned record conservation over > > > defined or undefined period of time. The approach being > > > implemented today by technology providers and organizations with > > > docbases is therefore based on deployment of archival interfaces > > > operating directly on existing records by producing conservation > > > relevant data. Three major points needs to be addressed ASAP: > > > archive interaction, archival meta and archival complementary > > > data. Present systems try to build sets of data (mainly trust > > > anchors) on existing or incoming records. Standardizing such > > > (archival) data is a must, since it can not rely on specific > > > technology and this is where the problem really exist at the > > > moment. Data, meta data and complementary data must be transparent > > > of underlying technology and they must be combined with seamless > > > mechanisms for proving integrity on independent platforms or in > > > other words, they must be based on standardized semantic. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > Tielemann > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > academically interesting approach. But I fear that in > > > practice there > > > > is no chance to run such a model. Spreading signed data is much > > > > expensive in communication, storing, retrieving etc. Sure, > > > there is a > > > > benfit in security and evidence, but the overhead is in any > > > industrial > > > > context not feasable. Implementing distributed locations is to > > > > expensive in the sense of hardware, stuff, building, > > > several DMS (?), > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > I guess we need, lets say a local store which serves all > > neccessary > > > > tasks. This allows a more practicable implementation and > > modelling > > > > for any company or application. > > > > > > > > At our site we have a huge amount of stored documents, > > > splitting this > > > > mass up to several locations with all dependencies would be a > > > > nightmare. > > > > > > > > Regards > > > > -Michael > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38IBNlO000302; Thu, 8 Apr 2004 11:11:23 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38IBN7b000301; Thu, 8 Apr 2004 11:11:23 -0700 (PDT) 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 i38IBMLn000290 for ; Thu, 8 Apr 2004 11:11:22 -0700 (PDT) (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 i38IAr6P028528; Thu, 8 Apr 2004 11:10:59 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38IAo3k016033; Thu, 8 Apr 2004 11:10:50 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV007NQ6I15Z@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 11:10:49 -0700 (PDT) Date: Thu, 08 Apr 2004 11:10:49 -0700 From: Larry Masinter Subject: RE: Our objections to draft ERS In-reply-to: <000601c41891$8be4f8e0$6402a8c0@pvt.cz> To: Libor.Dostalek@pvt.cz, ietf-ltans@imc.org Message-id: <0HVV007NR6I15Z@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: multipart/alternative; boundary="Boundary_(ID_aATK5K4dGBCGfUN0F13N0w)" Thread-index: AcQYlEl3gZs2tKIzRI2YddTbLU9pCAE/kYiw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_aATK5K4dGBCGfUN0F13N0w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Every time I've tried to explain this, I had to draw a set of diagrams on the board, and invent some notation. I'm not happy with the notation, but I think there must be some better way of explaining the chain-of-evidence. Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. I don't understand how, in 2020, you will verify that the TSA digital signature was valid in May 2007. Won't you need more information than will be trustably available after 13 years? --Boundary_(ID_aATK5K4dGBCGfUN0F13N0w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Zpráva
Every time I've tried to explain this, I had to draw a set of diagrams on the board, and invent some notation. I'm not happy with the notation, but I think there must be some better way of explaining the chain-of-evidence.
 
Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007.

In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the  ArchiveTimeStamp in 6th May 2007 up to present.

Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. 
 
 
I don't understand how, in 2020, you will verify that the TSA digital signature was valid in May 2007. Won't you need more information than will be trustably available after 13 years?
 
--Boundary_(ID_aATK5K4dGBCGfUN0F13N0w)-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HVSOZ098232; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HVSub098231; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) 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 i38HVREY098225 for ; Thu, 8 Apr 2004 10:31:28 -0700 (PDT) (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 i38HUx6P026196; Thu, 8 Apr 2004 10:31:04 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38HUt3k012635; Thu, 8 Apr 2004 10:30:56 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV0041P4NJ77@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 10:30:55 -0700 (PDT) Date: Thu, 08 Apr 2004 10:30:55 -0700 From: Larry Masinter Subject: acceptability of replication In-reply-to: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> To: "'Tobias Gondrom'" , ietf-ltans@imc.org Message-id: <0HVV0041Q4NJ77@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: AcQdiaWlyU612H2sRwqlNDGUBhi6nAABKlzQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Second, the distribution is very expensive and AFAIK from my contacts to > users and customers will most probably not be accepted. (we are all just > humans) I wanted to follow up on this point, since several posters have mentioned the cost of replication and difficulty of coordination. However, my understanding is that it is common practice in the industry, for disaster recovery, to maintain multiple copies of important data. And surely anything that you wish to preserve for the long term fits into this scenario. Using secret-sharing, there is no need to access the data once it has been archived, except in the case there is a dispute. However, using chain-of-evidence, the data must be regularly accessed (every several years, at least), in order to update the chain of evidence. Since these are important records undergoing transactional updates, won't they be candidates for off-site replication? So, is it certain that the cost of replication for, say, 2-of-3 with static storage of components is higher than the cost of maintaining a chain-of-evidence active re-signing activity? Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HL5Rt097711; Thu, 8 Apr 2004 10:21:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HL5gI097710; Thu, 8 Apr 2004 10:21:05 -0700 (PDT) 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 i38HL4l5097704 for ; Thu, 8 Apr 2004 10:21:04 -0700 (PDT) (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 i38HL5jx003866; Thu, 8 Apr 2004 19:21:06 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ91P3>; Thu, 8 Apr 2004 19:23:28 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54D0@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 19:23:00 +0200 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: Santosh: There seems to be a misunderstanding: You are right TAA is within the organization and can for this not be fully trusted - as a 3rd party time stamp server. Based on the concept of the TAA and ERS we ensure the security based on the time stamps from the trustable third party/source. These timestamps will ensure the integrity like layers around the documents and all more inner layers (with timestamps based on meanwhile weak algorithms). It is _not_ possible for the TAA to manipulate the inner data as the new timestamp (that can be trusted) will ensure the integrity of the document and all up to appliance of the last timestamp already existant timestamps. This includes the possibility of loosing the security of a hash algorithm (as long as there exists at least a new reliable hash algorithm) as the document and all up to then existing timestamps are together rehashed with a new valid hash algorithm. You can _proof_ that the system is secure while renewing/changing hash or PK algorithms over time. For the course of time please consult the email from Libor Dostalek from Friday 4/2/2004 (subject: RE: Our objections to draft ERS) where he described the chain of proof brilliantly. So I can not see any problems with courts. Best regards Tobias > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 19:01 > To: 'Tobias Gondrom'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > > > Tobias: > > You all are ignoring the fact that as you lay out, the TAA is > a single source of authority to vouch for the document. You > all also seem to say that TAA is within the organization. > > This could lead to problems in some courts. > > Please note that the time stamp authority is only good for > the outermost time stamp. Due to cryptanalysis etc., inner > time stamps may be manipulated by the TAA. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tobias Gondrom > Sent: Thursday, April 08, 2004 12:43 PM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving - conclusion ? > Importance: High > > > > Dear all, > > Personally I fully go with Brian, Aleksej, Uli, Antje and > Michael. I can see that n-of-m has some quite interesting > aspects but feel the same that it is quite academic > concenring current needs and business. > > I agree that there is one advantage of n-of-m over the > current model, that is when it comes to the point that we > have no hash algorithms and no PK algorithms at _all_. At the > moment we are working quite fine with PK and hash algorithms > and the time stamps from PKIX are in practical use - so I > would like to rely on them. > > Second, the distribution is very expensive and AFAIK from my > contacts to users and customers will most probably not be > accepted. (we are all just > humans) > > > As our goal is to develop standards that we think are best > for the world _and_ will be _used_. I feel that all of the > arguments are exchanged concerning the topic and so I would > like to get to an conclusion. > > >From what I read I feel that there might be rough consensus to reject > >the > proposal of n-of-m for this draft. We can pick it up as a > future topic or add-on for LTANS if we are able to > demonstrate the need and the business use and have done our > homework with the first drafts mid of this year. > > > Am I asking to early or just please give me your statement ? > > > Best regards and happy easter > > Tobias > > > (Chair of LTANS) > > > > > -----Original Message----- > > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > > Sent: Thursday, April 08, 2004 15:43 > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Of course, that is the main point. We should consider > demands (at the > > moment) and focus on them. Multiple parties scenario does not exist > > currently... At least to my knowledge. But future infrastructures > > might do that (n/m). > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > > Sent: Thursday, April 08, 2004 3:28 PM > > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > The n of m approach is proposed when you use multiple parties as > > > trust store. > > > > > > If you feel that you need to store your own data and can defend in > > > court time stamps (all of which may be subject to cryptanalysis > > > except the current one), then you do not need multiple third > > > parties. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Thursday, April 08, 2004 9:08 AM > > > To: ietf-ltans@imc.org > > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > I have been following the discussion for some time and did go > > > through the n/m scenario and I have to add my position (also as a > > > technology provider). > > > > > > As stated a couple of times before n/m solves some > critical problems > > > (confidentiality) but mostly in scenarios when trusted archive is > > > presented as an outsourcing service (here I really liked Uli's > > > scenarios). Within an organization n/m approach does not > deliver a > > > single benefit, since redundancy and disaster recovery is > solved by > > > other approaches/technology and building a "new instance" taking > > > care of redundancy is a wrong direction. Also one should keep in > > > mind that many records do already exist today and transformation > > > using n/m approaches are to demanding and especially form > the point > > > of view that DMS systems or docbases are not something that will > > > be implemented with the trusted archive but they DO exist > > > already, archival standards should take care mostly of > > > collecting complementary data for unquestioned record > > > conservation over defined or undefined period of time. The > > > approach being implemented today by technology providers and > > > organizations with docbases is therefore based on deployment > > > of archival interfaces operating directly on existing records > > > by producing conservation relevant data. Three major points > > > needs to be addressed ASAP: archive interaction, archival > > > meta and archival complementary data. Present systems try to > > > build sets of data (mainly trust anchors) on existing or > > > incoming records. Standardizing such (archival) data is a > > > must, since it can not rely on specific technology and this > > > is where the problem really exist at the moment. Data, meta > > > data and complementary data must be transparent of underlying > > > technology and they must be combined with seamless mechanisms > > > for proving integrity on independent platforms or in other > > > words, they must be based on standardized semantic. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > > Tielemann > > > > Sent: Thursday, April 08, 2004 2:14 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > > > > > Dear all, > > > > > > > > in my opinion the recently discussed n:m distribution is an > > > > academically interesting approach. But I fear that in > > > practice there > > > > is no chance to run such a model. Spreading signed data is much > > > > expensive in communication, storing, retrieving etc. Sure, > > > there is a > > > > benfit in security and evidence, but the overhead is in any > > > industrial > > > > context not feasable. Implementing distributed locations is to > > > > expensive in the sense of hardware, stuff, building, > > > several DMS (?), > > > > backup, disaster recovery, managing responsebility, etc. > > > > > > > > I guess we need, lets say a local store which serves all > > neccessary > > > > tasks. This allows a more practicable implementation and > > modelling > > > > for any company or application. > > > > > > > > At our site we have a huge amount of stored documents, > > > splitting this > > > > mass up to several locations with all dependencies would be a > > > > nightmare. > > > > > > > > Regards > > > > -Michael > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HIRRS097548; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38HIRhU097547; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38HIRAL097511 for ; Thu, 8 Apr 2004 10:18:27 -0700 (PDT) (envelope-from LMM@acm.org) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i38HINSP025520; Thu, 8 Apr 2004 10:18:23 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i38HIJkq008838; Thu, 8 Apr 2004 10:18:19 -0700 (PDT) Received: from MasinterT40 ([130.248.176.28]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVV004P042I77@mailsj-v1.corp.adobe.com>; Thu, 08 Apr 2004 10:18:19 -0700 (PDT) Date: Thu, 08 Apr 2004 10:18:18 -0700 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving - conclusion ? In-reply-to: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> To: "'Tobias Gondrom'" Cc: ietf-ltans@imc.org Message-id: <0HVV004P142J77@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: AcQdiaWlyU612H2sRwqlNDGUBhi6nAAAjd/g Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, I am confused by your call for 'rough consensus'. Personally, I think it is best practice to focus 'rough consensus' on the actual wording in actual internet drafts, rather than on abstract principles. > 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. I have proposed some changes, and raised some questions, about the requirements document. It would be good to follow the charter and see if we can reach consensus on a requirements document. I would prefer one that did not exclude the possibility of mechanisms other than chain-of-evidence for providing for long term non-repudiation services. > 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. I would prefer that the protocol not require timestamp chains, but allow them as an option for providing long-term non-repudiation evidence. Multiple independent party assertions of independent records of receipt and validation, of either full copies (or secret shares, if the archives can be trusted to assert timestamps but not to respect privacy) might be an alternative mechanism. Personally, I think that the "chain of evidence" mechanisms proposed for long-term non-repudiation are themselves "academic research projects", in that they are untested, and seem to rely on some fairly dubious assertions, e.g., that the expiration of the belief in the non-invertability of any particular one-way hash function can be predicted. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38H17iC096552; Thu, 8 Apr 2004 10:01:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38H17wF096551; Thu, 8 Apr 2004 10:01:07 -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.11/8.12.8) with ESMTP id i38H16h5096545 for ; Thu, 8 Apr 2004 10:01:06 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38H19At015552; Thu, 8 Apr 2004 13:01:09 -0400 From: "Santosh Chokhani" To: "'Tobias Gondrom'" , Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 13:01:09 -0400 Message-ID: <001b01c41d8b$16df0230$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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38H16h5096546 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: You all are ignoring the fact that as you lay out, the TAA is a single source of authority to vouch for the document. You all also seem to say that TAA is within the organization. This could lead to problems in some courts. Please note that the time stamp authority is only good for the outermost time stamp. Due to cryptanalysis etc., inner time stamps may be manipulated by the TAA. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Thursday, April 08, 2004 12:43 PM To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Importance: High Dear all, Personally I fully go with Brian, Aleksej, Uli, Antje and Michael. I can see that n-of-m has some quite interesting aspects but feel the same that it is quite academic concenring current needs and business. I agree that there is one advantage of n-of-m over the current model, that is when it comes to the point that we have no hash algorithms and no PK algorithms at _all_. At the moment we are working quite fine with PK and hash algorithms and the time stamps from PKIX are in practical use - so I would like to rely on them. Second, the distribution is very expensive and AFAIK from my contacts to users and customers will most probably not be accepted. (we are all just humans) As our goal is to develop standards that we think are best for the world _and_ will be _used_. I feel that all of the arguments are exchanged concerning the topic and so I would like to get to an conclusion. >From what I read I feel that there might be rough consensus to reject >the proposal of n-of-m for this draft. We can pick it up as a future topic or add-on for LTANS if we are able to demonstrate the need and the business use and have done our homework with the first drafts mid of this year. Am I asking to early or just please give me your statement ? Best regards and happy easter Tobias (Chair of LTANS) > -----Original Message----- > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > Sent: Thursday, April 08, 2004 15:43 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Of course, that is the main point. We should consider demands (at the > moment) and focus on them. Multiple parties scenario does not > exist currently... At least to my knowledge. But future > infrastructures might do that (n/m). > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 3:28 PM > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > The n of m approach is proposed when you use multiple parties as > > trust store. > > > > If you feel that you need to store your own data and can defend in > > court time stamps (all of which may be subject to cryptanalysis > > except the current one), then you do not need multiple third > > parties. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Thursday, April 08, 2004 9:08 AM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > I have been following the discussion for some time and did go > > through the n/m scenario and I have to add my position (also as a > > technology provider). > > > > As stated a couple of times before n/m solves some critical problems > > (confidentiality) but mostly in scenarios when trusted archive is > > presented as an outsourcing service (here I really liked Uli's > > scenarios). Within an organization n/m approach does not deliver a > > single benefit, since redundancy and disaster recovery is solved by > > other approaches/technology and building a "new instance" taking > > care of redundancy is a wrong direction. Also one should keep in > > mind that many records do already exist today and transformation > > using n/m approaches are to demanding and especially form the point > > of view that DMS systems or docbases are not something that will > > be implemented with the trusted archive but they DO exist > > already, archival standards should take care mostly of > > collecting complementary data for unquestioned record > > conservation over defined or undefined period of time. The > > approach being implemented today by technology providers and > > organizations with docbases is therefore based on deployment > > of archival interfaces operating directly on existing records > > by producing conservation relevant data. Three major points > > needs to be addressed ASAP: archive interaction, archival > > meta and archival complementary data. Present systems try to > > build sets of data (mainly trust anchors) on existing or > > incoming records. Standardizing such (archival) data is a > > must, since it can not rely on specific technology and this > > is where the problem really exist at the moment. Data, meta > > data and complementary data must be transparent of underlying > > technology and they must be combined with seamless mechanisms > > for proving integrity on independent platforms or in other > > words, they must be based on standardized semantic. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > Tielemann > > > Sent: Thursday, April 08, 2004 2:14 PM > > > To: ietf-ltans@imc.org > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > in my opinion the recently discussed n:m distribution is an > > > academically interesting approach. But I fear that in > > practice there > > > is no chance to run such a model. Spreading signed data is much > > > expensive in communication, storing, retrieving etc. Sure, > > there is a > > > benfit in security and evidence, but the overhead is in any > > industrial > > > context not feasable. Implementing distributed locations is to > > > expensive in the sense of hardware, stuff, building, > > several DMS (?), > > > backup, disaster recovery, managing responsebility, etc. > > > > > > I guess we need, lets say a local store which serves all > neccessary > > > tasks. This allows a more practicable implementation and > modelling > > > for any company or application. > > > > > > At our site we have a huge amount of stored documents, > > splitting this > > > mass up to several locations with all dependencies would be a > > > nightmare. > > > > > > Regards > > > -Michael > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38GhVdI095385; Thu, 8 Apr 2004 09:43:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38GhVTD095384; Thu, 8 Apr 2004 09:43:31 -0700 (PDT) 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 i38GhU3s095371 for ; Thu, 8 Apr 2004 09:43:30 -0700 (PDT) (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 i38GhRsu007707 for ; Thu, 8 Apr 2004 18:43:27 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Apr 2004 18:45:38 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54CC@muc-mail5.ixos.de> From: Tobias Gondrom To: Tobias Gondrom Cc: ietf-ltans@imc.org Subject: RE: Problem with mailing-list: some emails got lost :-( - problem solved Date: Thu, 8 Apr 2004 18:45:31 +0200 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: Dear all, Thanks to Pauls fast answer the problem has been solved. It was about the sender was not registered with the mailing-list. Sorry for the interuption Best regards Tobias > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] > Sent: Monday, April 05, 2004 11:22 > To: ietf-ltans@imc.org > Subject: Problem with mailing-list: some emails got lost :-( > Importance: High > > > > Dear all, > > There seems to be some problem with the mailing-list. > Some emails have not been transmitted. > > I'm tracking the problem. Until then when you send emails to > the list please take a look whether it has really been > transmitted - as you are also part of the mailing-list you > should receive one copy of your own email too. > > If not, please report the error to me. > > Regards > > Tobias > > > Chair LTANS > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Gewuv095127; Thu, 8 Apr 2004 09:40:58 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38GewNv095126; Thu, 8 Apr 2004 09:40:58 -0700 (PDT) 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 i38GeqvD095119 for ; Thu, 8 Apr 2004 09:40:57 -0700 (PDT) (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 i38Geq55008568 for ; Thu, 8 Apr 2004 18:40:54 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ91B2>; Thu, 8 Apr 2004 18:43:14 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54CB@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving - conclusion ? Date: Thu, 8 Apr 2004 18:42:55 +0200 Importance: high X-Priority: 1 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: Dear all, Personally I fully go with Brian, Aleksej, Uli, Antje and Michael. I can see that n-of-m has some quite interesting aspects but feel the same that it is quite academic concenring current needs and business. I agree that there is one advantage of n-of-m over the current model, that is when it comes to the point that we have no hash algorithms and no PK algorithms at _all_. At the moment we are working quite fine with PK and hash algorithms and the time stamps from PKIX are in practical use - so I would like to rely on them. Second, the distribution is very expensive and AFAIK from my contacts to users and customers will most probably not be accepted. (we are all just humans) As our goal is to develop standards that we think are best for the world _and_ will be _used_. I feel that all of the arguments are exchanged concerning the topic and so I would like to get to an conclusion. >From what I read I feel that there might be rough consensus to reject the proposal of n-of-m for this draft. We can pick it up as a future topic or add-on for LTANS if we are able to demonstrate the need and the business use and have done our homework with the first drafts mid of this year. Am I asking to early or just please give me your statement ? Best regards and happy easter Tobias (Chair of LTANS) > -----Original Message----- > From: A. Jerman Blazic [mailto:aljosa@e5.ijs.si] > Sent: Thursday, April 08, 2004 15:43 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Of course, that is the main point. We should consider demands (at the > moment) and focus on them. Multiple parties scenario does not > exist currently... At least to my knowledge. But future > infrastructures might do that (n/m). > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Thursday, April 08, 2004 3:28 PM > > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > The n of m approach is proposed when you use multiple parties > > as trust store. > > > > If you feel that you need to store your own data and can > > defend in court time stamps (all of which may be subject to > > cryptanalysis except the current one), then you do not need > > multiple third parties. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Thursday, April 08, 2004 9:08 AM > > To: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > I have been following the discussion for some time and did go > > through the n/m scenario and I have to add my position (also > > as a technology provider). > > > > As stated a couple of times before n/m solves some critical problems > > (confidentiality) but mostly in scenarios when trusted > > archive is presented as an outsourcing service (here I really > > liked Uli's scenarios). Within an organization n/m approach > > does not deliver a single benefit, since redundancy and > > disaster recovery is solved by other approaches/technology > > and building a "new instance" taking care of redundancy is a > > wrong direction. Also one should keep in mind that many > > records do already exist today and transformation using n/m > > approaches are to demanding and especially form the point of > > view that DMS systems or docbases are not something that will > > be implemented with the trusted archive but they DO exist > > already, archival standards should take care mostly of > > collecting complementary data for unquestioned record > > conservation over defined or undefined period of time. The > > approach being implemented today by technology providers and > > organizations with docbases is therefore based on deployment > > of archival interfaces operating directly on existing records > > by producing conservation relevant data. Three major points > > needs to be addressed ASAP: archive interaction, archival > > meta and archival complementary data. Present systems try to > > build sets of data (mainly trust anchors) on existing or > > incoming records. Standardizing such (archival) data is a > > must, since it can not rely on specific technology and this > > is where the problem really exist at the moment. Data, meta > > data and complementary data must be transparent of underlying > > technology and they must be combined with seamless mechanisms > > for proving integrity on independent platforms or in other > > words, they must be based on standardized semantic. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > > Tielemann > > > Sent: Thursday, April 08, 2004 2:14 PM > > > To: ietf-ltans@imc.org > > > Subject: Alternatives for Long Term Archiving > > > > > > > > > > > > Dear all, > > > > > > in my opinion the recently discussed n:m distribution is an > > > academically interesting approach. But I fear that in > > practice there > > > is no chance to run such a model. Spreading signed data is much > > > expensive in communication, storing, retrieving etc. Sure, > > there is a > > > benfit in security and evidence, but the overhead is in any > > industrial > > > context not feasable. Implementing distributed locations is to > > > expensive in the sense of hardware, stuff, building, > > several DMS (?), > > > backup, disaster recovery, managing responsebility, etc. > > > > > > I guess we need, lets say a local store which serves all > neccessary > > > tasks. This allows a more practicable implementation and > modelling > > > for any company or application. > > > > > > At our site we have a huge amount of stored documents, > > splitting this > > > mass up to several locations with all dependencies would be a > > > nightmare. > > > > > > Regards > > > -Michael > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38FZM4H090440; Thu, 8 Apr 2004 08:35:22 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38FZMxV090439; Thu, 8 Apr 2004 08:35:22 -0700 (PDT) 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 i38FZGXl090427 for ; Thu, 8 Apr 2004 08:35:21 -0700 (PDT) (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 i38FZDpv027603; Thu, 8 Apr 2004 17:35:13 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ9DCG>; Thu, 8 Apr 2004 17:37:34 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54C7@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Cc: "'Libor.Dostalek@pvt.cz'" Subject: RE: Our objections to draft ERS Date: Thu, 8 Apr 2004 17:37:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41D7F.5E719290" 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_01C41D7F.5E719290 Content-Type: text/plain Libor, to answer in place of Brian: Your described scenario is perfectly right. I would not have been able to explain it better: This is exactly what is meant. best regards Tobias Brian, > In your example, the whole CMS object, as in RFC 3126, should be > given to the TAA for archiving. I have one quite elementary question to verify if I understand well. See the following example: Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid. 2.4.2004 6.5.2007 2020 -+----------------------+--------------------------------------+-- <------------CMS validity-------------> <-----------------ERS validity----------->>> Libor ------_=_NextPart_001_01C41D7F.5E719290 Content-Type: text/html Message
Libor,
 
to answer in place of Brian:
 
Your described scenario is perfectly right.
I would not have been able to explain it better: This is exactly what is meant.
 
best regards
 
    Tobias
 
 

Brian,

> In your example, the whole CMS object, as in RFC 3126, should be
> given to the TAA for archiving.

I have one quite elementary question to verify if I understand well. See the following example:

Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007.

In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the  ArchiveTimeStamp in 6th May 2007 up to present.

Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid.

 2.4.2004               6.5.2007                               2020
-+----------------------+--------------------------------------+--
 <------------CMS validity------------->
                        <-----------------ERS validity----------->>>

   
Libor

 

------_=_NextPart_001_01C41D7F.5E719290-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38DfVvu081711; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38DfVlC081709; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) 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 i38DfUMQ081696 for ; Thu, 8 Apr 2004 06:41:31 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Received: (qmail 572 invoked from network); 8 Apr 2004 13:41:27 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 8 Apr 2004 13:41:27 -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 32390-09 for ; Thu, 8 Apr 2004 15:41:27 +0200 (CEST) Received: (qmail 567 invoked from network); 8 Apr 2004 13:41:27 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 8 Apr 2004 13:41:27 -0000 From: "A. Jerman Blazic" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 15:43:29 +0200 Message-ID: <008d01c41d6f$7988f290$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: <008301c41d6d$45d0a940$9a00a8c0@hq.orionsec.com> 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: Of course, that is the main point. We should consider demands (at the moment) and focus on them. Multiple parties scenario does not exist currently... At least to my knowledge. But future infrastructures might do that (n/m). > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 08, 2004 3:28 PM > To: 'A. Jerman Blazic'; ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > The n of m approach is proposed when you use multiple parties > as trust store. > > If you feel that you need to store your own data and can > defend in court time stamps (all of which may be subject to > cryptanalysis except the current one), then you do not need > multiple third parties. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of A. Jerman Blazic > Sent: Thursday, April 08, 2004 9:08 AM > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Dear all, > > I have been following the discussion for some time and did go > through the n/m scenario and I have to add my position (also > as a technology provider). > > As stated a couple of times before n/m solves some critical problems > (confidentiality) but mostly in scenarios when trusted > archive is presented as an outsourcing service (here I really > liked Uli's scenarios). Within an organization n/m approach > does not deliver a single benefit, since redundancy and > disaster recovery is solved by other approaches/technology > and building a "new instance" taking care of redundancy is a > wrong direction. Also one should keep in mind that many > records do already exist today and transformation using n/m > approaches are to demanding and especially form the point of > view that DMS systems or docbases are not something that will > be implemented with the trusted archive but they DO exist > already, archival standards should take care mostly of > collecting complementary data for unquestioned record > conservation over defined or undefined period of time. The > approach being implemented today by technology providers and > organizations with docbases is therefore based on deployment > of archival interfaces operating directly on existing records > by producing conservation relevant data. Three major points > needs to be addressed ASAP: archive interaction, archival > meta and archival complementary data. Present systems try to > build sets of data (mainly trust anchors) on existing or > incoming records. Standardizing such (archival) data is a > must, since it can not rely on specific technology and this > is where the problem really exist at the moment. Data, meta > data and complementary data must be transparent of underlying > technology and they must be combined with seamless mechanisms > for proving integrity on independent platforms or in other > words, they must be based on standardized semantic. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael > Tielemann > > Sent: Thursday, April 08, 2004 2:14 PM > > To: ietf-ltans@imc.org > > Subject: Alternatives for Long Term Archiving > > > > > > > > Dear all, > > > > in my opinion the recently discussed n:m distribution is an > > academically interesting approach. But I fear that in > practice there > > is no chance to run such a model. Spreading signed data is much > > expensive in communication, storing, retrieving etc. Sure, > there is a > > benfit in security and evidence, but the overhead is in any > industrial > > context not feasable. Implementing distributed locations is to > > expensive in the sense of hardware, stuff, building, > several DMS (?), > > backup, disaster recovery, managing responsebility, etc. > > > > I guess we need, lets say a local store which serves all neccessary > > tasks. This allows a more practicable implementation and modelling > > for any company or application. > > > > At our site we have a huge amount of stored documents, > splitting this > > mass up to several locations with all dependencies would be a > > nightmare. > > > > Regards > > -Michael > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38DRhKd080911; Thu, 8 Apr 2004 06:27:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38DRhq1080909; Thu, 8 Apr 2004 06:27:43 -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.11/8.12.8) with ESMTP id i38DRgdA080891 for ; Thu, 8 Apr 2004 06:27:43 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i38DRhAt013230; Thu, 8 Apr 2004 09:27:43 -0400 From: "Santosh Chokhani" To: "'A. Jerman Blazic'" , Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 09:27:43 -0400 Message-ID: <008301c41d6d$45d0a940$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 In-Reply-To: <008801c41d6a$8e6eee30$1b018ac1@arthur> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i38DRhdA080897 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The n of m approach is proposed when you use multiple parties as trust store. If you feel that you need to store your own data and can defend in court time stamps (all of which may be subject to cryptanalysis except the current one), then you do not need multiple third parties. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Thursday, April 08, 2004 9:08 AM To: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Dear all, I have been following the discussion for some time and did go through the n/m scenario and I have to add my position (also as a technology provider). As stated a couple of times before n/m solves some critical problems (confidentiality) but mostly in scenarios when trusted archive is presented as an outsourcing service (here I really liked Uli's scenarios). Within an organization n/m approach does not deliver a single benefit, since redundancy and disaster recovery is solved by other approaches/technology and building a "new instance" taking care of redundancy is a wrong direction. Also one should keep in mind that many records do already exist today and transformation using n/m approaches are to demanding and especially form the point of view that DMS systems or docbases are not something that will be implemented with the trusted archive but they DO exist already, archival standards should take care mostly of collecting complementary data for unquestioned record conservation over defined or undefined period of time. The approach being implemented today by technology providers and organizations with docbases is therefore based on deployment of archival interfaces operating directly on existing records by producing conservation relevant data. Three major points needs to be addressed ASAP: archive interaction, archival meta and archival complementary data. Present systems try to build sets of data (mainly trust anchors) on existing or incoming records. Standardizing such (archival) data is a must, since it can not rely on specific technology and this is where the problem really exist at the moment. Data, meta data and complementary data must be transparent of underlying technology and they must be combined with seamless mechanisms for proving integrity on independent platforms or in other words, they must be based on standardized semantic. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael Tielemann > Sent: Thursday, April 08, 2004 2:14 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > > Dear all, > > in my opinion the recently discussed n:m distribution is an > academically interesting approach. But I fear that in > practice there is no chance to run such a model. Spreading > signed data is much expensive in communication, storing, > retrieving etc. Sure, there is a benfit in security and > evidence, but the overhead is in any industrial context not > feasable. Implementing distributed locations is to expensive > in the sense of hardware, stuff, building, several DMS (?), > backup, disaster recovery, managing responsebility, etc. > > I guess we need, lets say a local store which serves all > neccessary tasks. This allows a more practicable > implementation and modelling for any company or application. > > At our site we have a huge amount of stored documents, > splitting this mass up to several locations with all > dependencies would be a nightmare. > > Regards > -Michael > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38D6MN2079284; Thu, 8 Apr 2004 06:06:22 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38D6MdZ079283; Thu, 8 Apr 2004 06:06:22 -0700 (PDT) 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 i38D6LQk079260 for ; Thu, 8 Apr 2004 06:06:21 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Received: (qmail 31680 invoked from network); 8 Apr 2004 13:06:15 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 8 Apr 2004 13:06:15 -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 31437-05 for ; Thu, 8 Apr 2004 15:06:15 +0200 (CEST) Received: (qmail 31675 invoked from network); 8 Apr 2004 13:06:15 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 8 Apr 2004 13:06:15 -0000 From: "A. Jerman Blazic" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 15:08:16 +0200 Message-ID: <008801c41d6a$8e6eee30$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: <03da01c41d62$f04fab10$9c01fb0a@P25823E0> 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: Dear all, I have been following the discussion for some time and did go through the n/m scenario and I have to add my position (also as a technology provider). As stated a couple of times before n/m solves some critical problems (confidentiality) but mostly in scenarios when trusted archive is presented as an outsourcing service (here I really liked Uli's scenarios). Within an organization n/m approach does not deliver a single benefit, since redundancy and disaster recovery is solved by other approaches/technology and building a "new instance" taking care of redundancy is a wrong direction. Also one should keep in mind that many records do already exist today and transformation using n/m approaches are to demanding and especially form the point of view that DMS systems or docbases are not something that will be implemented with the trusted archive but they DO exist already, archival standards should take care mostly of collecting complementary data for unquestioned record conservation over defined or undefined period of time. The approach being implemented today by technology providers and organizations with docbases is therefore based on deployment of archival interfaces operating directly on existing records by producing conservation relevant data. Three major points needs to be addressed ASAP: archive interaction, archival meta and archival complementary data. Present systems try to build sets of data (mainly trust anchors) on existing or incoming records. Standardizing such (archival) data is a must, since it can not rely on specific technology and this is where the problem really exist at the moment. Data, meta data and complementary data must be transparent of underlying technology and they must be combined with seamless mechanisms for proving integrity on independent platforms or in other words, they must be based on standardized semantic. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Michael Tielemann > Sent: Thursday, April 08, 2004 2:14 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > > Dear all, > > in my opinion the recently discussed n:m distribution is an > academically interesting approach. But I fear that in > practice there is no chance to run such a model. Spreading > signed data is much expensive in communication, storing, > retrieving etc. Sure, there is a benfit in security and > evidence, but the overhead is in any industrial context not > feasable. Implementing distributed locations is to expensive > in the sense of hardware, stuff, building, several DMS (?), > backup, disaster recovery, managing responsebility, etc. > > I guess we need, lets say a local store which serves all > neccessary tasks. This allows a more practicable > implementation and modelling for any company or application. > > At our site we have a huge amount of stored documents, > splitting this mass up to several locations with all > dependencies would be a nightmare. > > Regards > -Michael > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38CBYPD074902; Thu, 8 Apr 2004 05:11:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i38CBYxU074901; Thu, 8 Apr 2004 05:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout01.datevnet.de (mailout01.datevnet.de [193.27.50.78]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38CBWnM074895 for ; Thu, 8 Apr 2004 05:11:33 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 28671 invoked from network); 8 Apr 2004 12:11:31 -0000 Received: from mail01.services.datevnet.de ([10.252.80.78]) (envelope-sender ) by mailout01.datevnet.de (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:31 -0000 Received: (qmail 24410 invoked by uid 0); 8 Apr 2004 12:11:31 -0000 Received: from localhost (HELO mail01.services.datev.de) (sendmail-bs@[127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:31 -0000 Received: (qmail 24402 invoked from network); 8 Apr 2004 12:11:30 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 8 Apr 2004 12:11:30 -0000 From: "Michael Tielemann" To: Subject: Alternatives for Long Term Archiving Date: Thu, 8 Apr 2004 14:13:44 +0200 Message-ID: <03da01c41d62$f04fab10$9c01fb0a@P25823E0> 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.3416 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: Dear all, in my opinion the recently discussed n:m distribution is an academically interesting approach. But I fear that in practice there is no chance to run such a model. Spreading signed data is much expensive in communication, storing, retrieving etc. Sure, there is a benfit in security and evidence, but the overhead is in any industrial context not feasable. Implementing distributed locations is to expensive in the sense of hardware, stuff, building, several DMS (?), backup, disaster recovery, managing responsebility, etc. I guess we need, lets say a local store which serves all neccessary tasks. This allows a more practicable implementation and modelling for any company or application. At our site we have a huge amount of stored documents, splitting this mass up to several locations with all dependencies would be a nightmare. Regards -Michael Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36DSZUm051222; Tue, 6 Apr 2004 06:28:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36DSZq7051221; Tue, 6 Apr 2004 06:28:35 -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.11/8.12.8) with ESMTP id i36DSYnX051212 for ; Tue, 6 Apr 2004 06:28:34 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i36DSLAt012160 for ; Tue, 6 Apr 2004 09:28:36 -0400 From: "Santosh Chokhani" To: Subject: RE: why we need sequences of timestamps Date: Tue, 6 Apr 2004 09:28:21 -0400 Message-ID: <004f01c41bdb$107fdf60$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40727255.3050709@sit.fraunhofer.de> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: The trust in the ERS model DOES depend on the TAA. While the trust anchor for the outermost timestamp can and should be verified independent of the TAA, all the inner timestamps and data are vulnerable to cryptanalysis and hence TAA manipulation. Thus, the real transaction or document in dispute can always be manipulated. Just like the TSA does not have data or vested interest, the various TAAs should not either and with n of m just like hash, they have meaningless string of bits which they can not manipulate to achieve a specific outcome other than screwing up the integrity. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Brian Hunter Sent: Tuesday, April 06, 2004 5:03 AM To: Santosh Chokhani Cc: 'Tobias Gondrom'; ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps Santosh Chokhani wrote: > In addition to what Carl and Peter said, please note that n of m does > not prevent subscribers and the TAAs from obtaining time stamps or TAAs > from asserting time. > > If not n of m, at least two TAAs even in time stamp case are required > in > order to protect against a single TAA from intentionally corrupting the > data. If a single TAA under the control of or as a contractor to an > organization being sued had all the data, it can always manipulate prior > trust anchors and messages. Thus, an independent source of trust > anchors may be required even in the case of 3161 time stamp refresh. I think a key difference between the two schemes is where the trust lies when a dispute arises in the future. In both schemes, the client has a contract with the TAA to properly archive his data, in the ERS case, this is one TAA, who could intentionally inproperly archive the data so that it is invalid in the future. But the trust of the system is during the dispute. Here, no trust is allocated to the TAA. The client simply has the ERS data structures, containing time-stamps from *trusted* TSAs, who had no access to the documents, nor a financial incentive to function improperly. With n of m, the judge must then trust the TAAs (n of them), that they all functioned correctly, in terms of guidelines as well as the software systems. Uli's point was whether a judge would trust the systems of the TAAs (a TAA system is much more complex than a simple TSA). Currently there are laws in Germany stating that the TSA approach is legally binding. Of course, a hybrid approach could solve both the trust as well as confidentiality issues. But if the time-stamp solution is removed as a mandatory part, we are then unsure of the legal value of the evidential proof. Brian > > n of m does the same thing without requiring time stamp. > > > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: Monday, April 05, 2004 5:04 AM > To: 'ietf-ltans@imc.org' > Subject: FW: why we need sequences of timestamps > > Hello LTANS, > > somehow a message from Uli got lost. :-( > So he asked me to forward it to the community. > > Tobias > > Ps.: I will try to find out what went wrong. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i369FpoQ033523; Tue, 6 Apr 2004 02:15:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i369FpiN033522; Tue, 6 Apr 2004 02:15:51 -0700 (PDT) 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 i369FnuI033513 for ; Tue, 6 Apr 2004 02:15:50 -0700 (PDT) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (vpnsit9.sit.fraunhofer.de [141.12.110.9]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA10712; Tue, 6 Apr 2004 11:15:40 +0200 (MET DST) Message-ID: <407275AB.10204@sit.fraunhofer.de> Date: Tue, 06 Apr 2004 11:17:31 +0200 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: ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps References: <200404051145.i35BjKAt023817@host13.websitesource.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: Carl Wallace wrote: > Uli, > > I don't think using 1-of-1 scenarios is a good basis for comparing the > two approaches. In any case, why it is necessary to view this as an ERS > vs. n-of-m decision? n-of-m could be used in conjunction with ERS to > provide data confidentiality. Combining n-of-m with a keyless timestamp > scheme could be a nice solution. Adding n of m on the client side could be used to alleviate his key management issues (, provided that the recombination of the n parts is shown to maintain the uniqueness of the document and hence the non-repudiation). > What about the patient's preservation of evidence? It may be difficult > for the patient to manage encryption keys that enable confidentiality of > the patient's medical data stored in a commercial archive. I doubt the > patient would trust the hospital to maintain all copies of the relevant > data. Uli's example was from the point of view of the hospital, who has to archive millions of documents a year, thus it needs an efficient system. The patient would be another type of client, and would not use the hospital's system. Brian > > Are there any results of the study you mentioned available online? > > Carl ... Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3693Qhn029365; Tue, 6 Apr 2004 02:03:26 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i3693Qm3029364; Tue, 6 Apr 2004 02:03:26 -0700 (PDT) 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 i3693KFA029300 for ; Tue, 6 Apr 2004 02:03:21 -0700 (PDT) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (vpnsit9.sit.fraunhofer.de [141.12.110.9]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA08897; Tue, 6 Apr 2004 11:02:53 +0200 (MET DST) Message-ID: <40727255.3050709@sit.fraunhofer.de> Date: Tue, 06 Apr 2004 11:03:17 +0200 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: Santosh Chokhani CC: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: why we need sequences of timestamps References: <005101c41b0a$31752440$9a00a8c0@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: Santosh Chokhani wrote: > In addition to what Carl and Peter said, please note that n of m does > not prevent subscribers and the TAAs from obtaining time stamps or TAAs > from asserting time. > > If not n of m, at least two TAAs even in time stamp case are required in > order to protect against a single TAA from intentionally corrupting the > data. If a single TAA under the control of or as a contractor to an > organization being sued had all the data, it can always manipulate prior > trust anchors and messages. Thus, an independent source of trust > anchors may be required even in the case of 3161 time stamp refresh. I think a key difference between the two schemes is where the trust lies when a dispute arises in the future. In both schemes, the client has a contract with the TAA to properly archive his data, in the ERS case, this is one TAA, who could intentionally inproperly archive the data so that it is invalid in the future. But the trust of the system is during the dispute. Here, no trust is allocated to the TAA. The client simply has the ERS data structures, containing time-stamps from *trusted* TSAs, who had no access to the documents, nor a financial incentive to function improperly. With n of m, the judge must then trust the TAAs (n of them), that they all functioned correctly, in terms of guidelines as well as the software systems. Uli's point was whether a judge would trust the systems of the TAAs (a TAA system is much more complex than a simple TSA). Currently there are laws in Germany stating that the TSA approach is legally binding. Of course, a hybrid approach could solve both the trust as well as confidentiality issues. But if the time-stamp solution is removed as a mandatory part, we are then unsure of the legal value of the evidential proof. Brian > > n of m does the same thing without requiring time stamp. > > > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: Monday, April 05, 2004 5:04 AM > To: 'ietf-ltans@imc.org' > Subject: FW: why we need sequences of timestamps > > Hello LTANS, > > somehow a message from Uli got lost. :-( > So he asked me to forward it to the community. > > Tobias > > Ps.: I will try to find out what went wrong. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i367N59b093997; Tue, 6 Apr 2004 00:23:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i367N5kx093996; Tue, 6 Apr 2004 00:23:05 -0700 (PDT) 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 i367N3WR093926 for ; Tue, 6 Apr 2004 00:23:03 -0700 (PDT) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCHOTZENPLOTZ (pc-hotzenplotz [141.12.33.2]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id JAA26602 for ; Tue, 6 Apr 2004 09:22:48 +0200 (MET DST) From: "Ulrich Pordesch" To: Subject: why we need sequences of timestamps (third trial) Date: Tue, 6 Apr 2004 09:23:12 +0200 Organization: Fraunhofer, SIT Message-ID: <000101c41ba8$06a133a0$02210c8d@PCHOTZENPLOTZ> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i367N4WR093989 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The following message got lost twice in cyberspace. Strange to say that some members of the list got it and posted comments. Here is the third trial for all ... Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35CXPTh070737; Mon, 5 Apr 2004 05:33:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35CXPm4070736; Mon, 5 Apr 2004 05:33:25 -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.11/8.12.8) with ESMTP id i35CXP5Q070730 for ; Mon, 5 Apr 2004 05:33:25 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i35CXQAt030150; Mon, 5 Apr 2004 08:33:26 -0400 From: "Santosh Chokhani" To: "'Tobias Gondrom'" , Subject: RE: why we need sequences of timestamps Date: Mon, 5 Apr 2004 08:33:26 -0400 Message-ID: <005101c41b0a$31752440$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C41AE8.AA638440" 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: <077097E85A6BD3119E910800062786A9094D549E@muc-mail5.ixos.de> 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_0052_01C41AE8.AA638440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to what Carl and Peter said, please note that n of m does = not prevent subscribers and the TAAs from obtaining time stamps or TAAs from asserting time. =20 If not n of m, at least two TAAs even in time stamp case are required in order to protect against a single TAA from intentionally corrupting the data. If a single TAA under the control of or as a contractor to an organization being sued had all the data, it can always manipulate prior trust anchors and messages. Thus, an independent source of trust = anchors may be required even in the case of 3161 time stamp refresh. =20 n of m does the same thing without requiring time stamp. =20 =20 -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, April 05, 2004 5:04 AM To: 'ietf-ltans@imc.org' Subject: FW: why we need sequences of timestamps Hello LTANS, =20 somehow a message from Uli got lost. :-( So he asked me to forward it to the community.=20 =20 Tobias =20 Ps.: I will try to find out what went wrong.=20 =20 =20 -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de]=20 Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh=20 envisage the following court case (we conducted such cases last fall in = an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and = signed an operation report. In 2020, the patient sues the hospital for damages = in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024,=20 which became insecure in the year 2007. Furthermore, in 2020, = signatures created with such a weak key can be easily forged. Therefore, at the = time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is = provable that it existed before 2007. What can the hospital do to be able to = convince a judge? Which method should it adopt? How can LTANS help the = hospital? Case 1=20 ------=20 The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 = time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the=20 time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, = the evidence will be recognised. Actually, the court must recognise it, = since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a = confirmation from its own system, that says the document was added to its system in = 2000. This is hardly credible. The judge will send an expert to the hospital, = who will search through the hospital's archive=20 and protocols. This can be very expensive and the chance of success is = at best poor.=20 Case 2=20 ------=20 The hospital uses an external service provider, a TAA, let's call it Uli-TAA.=20 ERS: The provider creates an evidence record, as above, using = time-stamps from an accredited TSA. There is no difference in the court case. It = will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have = been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness = of Uli-TAA during the last 20 years. Case 3=20 ------=20 The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and = splits its messages. As Antje already said, she is not overwelmed with = enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable = that the two pieces belong together, that is, that random=20 document pieces cannot combined together (I have not checked, whether = this requirement of the provability of uniqueness exists, but let's assume = it). ERS: Both TAAS offer their evidence records and it will be proven that = both pieces were archived in 2000. The fact that the pieces belong together = and thus the original document existed in 2000 is part of our assumptions. = I must point out that for the case of the splitting, there is no binding = rule for the judge, and we thus do not know, whether the=20 judge will actually make such a ruling or not.=20 n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, = that the document existed in their systems in 2000. It could be that the = judge is convinced. But perhaps he will say: I cannot estimate = trustworthyness of Ulis and Santoshs TAAs. The hospital must=20 prove that Uli-TAA and Santosh-TAA were completely trustworthy in the = last 20 years. Good luck with that.=20 I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists = and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high = volume suitable, secure method that is provable in court. This is true since = the security of the method only relies on the accreditation of the = algorithms and time-stamp machines (TSAs). There is no foundation for the = distribution of documents and the trustworthiness of TAAs. One=20 could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. = However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had = the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli=20 ------=_NextPart_000_0052_01C41AE8.AA638440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
In=20 addition to what Carl and Peter said, please note that n of m does not = prevent=20 subscribers and the TAAs from obtaining time stamps or TAAs from = asserting=20 time.
 
If not=20 n of m, at least two TAAs even in time stamp case are required = in=20 order to protect against a single TAA from intentionally corrupting the=20 data.  If a single TAA under the control of or as a contractor to = an=20 organization being sued had all the data, it can always manipulate prior = trust=20 anchors and messages.  Thus, an independent source of trust anchors = may be=20 required even in the case of 3161 time stamp = refresh.
 
n of m=20 does the same thing without requiring time stamp.
 
 
-----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, April 05, 2004 = 5:04=20 AM
To: 'ietf-ltans@imc.org'
Subject: FW: why we = need=20 sequences of timestamps

Hello LTANS,
 
somehow a message from Uli got lost.=20 :-(
So=20 he asked me to forward it to the community.
 
Tobias
 
Ps.:=20 I will try to find out what went wrong.
 
 
-----Original Message-----
From: = Ulrich pordesch=20 [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, = 2004=20 13:07
To: ietf-ltans@imc.org
Subject: why we need=20 sequences of timestamps

Santosh

envisage the following court case (we conducted such = cases=20 last fall in an academic study, using real lawyers and judges - and = not only=20 with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. = Afterwards, he=20 wrote and signed an operation report.  In 2020, the patient sues = the=20 hospital for damages in the value of millions, because allegedly there = was an=20 error in the operation.  This alleged error then lead to her = later=20 disability. Let us assume that the doctor's signature used the = algorithm=20 RSA-1024,

which became insecure in the year 2007.  = Furthermore, in=20 2020, signatures created with such a weak key can be easily forged. = Therefore,=20 at the time of the legal suit, anyone could forge the document and=20 signature.

The signature has become worthless. It is only of = value, if it=20 is provable that it existed before 2007. What can the hospital do to = be able=20 to convince a judge?  Which method should it adopt?  How can = LTANS=20 help the hospital?

Case 1
------ =
The hospital does not want to use an external archive service = provider,=20 rather it wants to provide its own in-house archive = services.

ERS: By 2020, its archive system created a chain of, = e.g., 3=20 time-stamps.  The time-stamps were retrieved according to RFC = 3126 and=20 from a legal, accredited time-stamp authority.  The court = verifies this=20 change of time-stamps, namely the Evidence Record.  Because the=20

time-stamps were timely renewed, before the = algorithms became=20 weak (according to the yearly published list of trustworthy = algorithms) and=20 because the used TSA is demonstrably accredited and thus was = inspected, the=20 evidence will be recognised.  Actually, the court must recognise = it,=20 since there are such evidence rules, which virtually force it to do=20 so.

n-of-m: As far as I see it, Shamir's scheme does not = offer any=20 value for this case.  The hospital could, at best, present to the = court a=20 confirmation from its own system, that says the document was added to = its=20 system in 2000.  This is hardly credible.  The judge will = send an=20 expert to the hospital, who will search through the hospital's archive =

and protocols.  This can be very expensive and = the chance=20 of success is at best poor.

Case 2
------ =
The hospital uses an external service provider, a TAA, let's = call it=20 Uli-TAA.

ERS: The provider creates an evidence record, as = above, using=20 time-stamps from an accredited TSA.  There is no difference in = the court=20 case.  It will be recognised, that the archive time-stamps are = correct=20 and were timely generated and thus, the signature existed before 2007 = and=20 cannot have been forged.

n-of-m: The hospital can only present the = confirmation from=20 Uli-TAA, who asserts, that the document was archived in 2000.  = Since this=20 was not a legally recognised method, it is difficult to prove the=20 trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external = providers,=20 Uli-TAA and Santosh-TAA, and splits its messages.  As Antje = already said,=20 she is not overwelmed with enthusiasm for this, since her costs will = double.=20 However, let's assume that two providers are used.  Furthermore, = let's=20 also assume that it is provable that the two pieces belong together, = that is,=20 that random

document pieces cannot combined together (I have not = checked,=20 whether this requirement of the provability of uniqueness exists, but = let's=20 assume it).

ERS: Both TAAS offer their evidence records and it = will be=20 proven that both pieces were archived in 2000.  The fact that the = pieces=20 belong together and thus the original document existed in 2000 is part = of our=20 assumptions.  I must point out that for the case of the = splitting, there=20 is no binding rule for the judge, and we thus do not know, whether the =

judge will actually make such a ruling or = not.

n-of-m: The judge receives a confirmation from = Uli-TAA and=20 Santosh-TAA, that the document existed in their systems in 2000.  = It=20 could be that the judge is convinced.  But perhaps he will say: I = cannot=20 estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must=20

prove that Uli-TAA and Santosh-TAA were completely = trustworthy=20 in the last 20 years. Good luck with that.


I haven't even considered the special cases, where = Uli-TAA is=20 bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no = longer=20 exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides = us with a=20 high volume suitable, secure method that is provable in court.  = This is=20 true since the security of the method only relies on the accreditation = of the=20 algorithms and time-stamp machines (TSAs).  There is no = foundation for=20 the distribution of documents and the trustworthiness of TAAs.  = One=20

could define rules for which policies TAAs must = have, which=20 security measures they must use and how they will be regularly audited = etc.=20 However, I tend to rule out that one can achieve a comparable level of = security through this manner.

Where one could make further considerations is the = combination=20 of both methods.  Additional confirmations from the TAAs, saying = that=20 they had the document or piece, could be in specific cases an = alternative for=20 ERS, in particular, in the case that something went wrong during the=20 time-stamp renewal.

Uli

------=_NextPart_000_0052_01C41AE8.AA638440-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35BjLeC067130; Mon, 5 Apr 2004 04:45:21 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35BjLWs067129; Mon, 5 Apr 2004 04:45:21 -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.11/8.12.8) with ESMTP id i35BjK91067122 for ; Mon, 5 Apr 2004 04:45:20 -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 i35BjKAt023817 for ; Mon, 5 Apr 2004 07:45:20 -0400 Message-Id: <200404051145.i35BjKAt023817@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: why we need sequences of timestamps Date: Mon, 5 Apr 2004 07:45:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C41AE1.F279F860" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQa7rjoZ8is4OJQSKaEP7AprKZTgQAD4Jsg In-Reply-To: <077097E85A6BD3119E910800062786A9094D549E@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: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C41AE1.F279F860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Uli, I don't think using 1-of-1 scenarios is a good basis for comparing the two approaches. In any case, why it is necessary to view this as an ERS vs. n-of-m decision? n-of-m could be used in conjunction with ERS to provide data confidentiality. Combining n-of-m with a keyless timestamp scheme could be a nice solution. What about the patient's preservation of evidence? It may be difficult for the patient to manage encryption keys that enable confidentiality of the patient's medical data stored in a commercial archive. I doubt the patient would trust the hospital to maintain all copies of the relevant data. Are there any results of the study you mentioned available online? Carl _____ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, April 05, 2004 5:04 AM To: 'ietf-ltans@imc.org' Subject: FW: why we need sequences of timestamps Hello LTANS, somehow a message from Uli got lost. :-( So he asked me to forward it to the community. Tobias Ps.: I will try to find out what went wrong. -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de] Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli ------=_NextPart_000_0000_01C41AE1.F279F860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Uli,
 
I don't think using 1-of-1 scenarios is a good = basis for=20 comparing the two approaches.  In any case, why it is necessary to = view=20 this as an ERS vs. n-of-m decision?  n-of-m could be used in = conjunction=20 with ERS to provide data confidentiality.  Combining n-of-m = with a=20 keyless timestamp scheme could be a nice solution. =20
 
What about the patient's preservation of = evidence?  It=20 may be difficult for the patient to manage encryption keys that enable=20 confidentiality of the patient's medical data stored in = a commercial=20 archive.  I doubt the patient would trust the hospital to maintain = all=20 copies of the relevant data. 
 
Are there any results of the study you = mentioned available=20 online? 
 
Carl

From: = owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias=20 Gondrom
Sent: Monday, April 05, 2004 5:04 AM
To:=20 'ietf-ltans@imc.org'
Subject: FW: why we need sequences of=20 timestamps

Hello LTANS,
 
somehow a message from Uli got lost.=20 :-(
So=20 he asked me to forward it to the community.
 
Tobias
 
Ps.:=20 I will try to find out what went wrong.
 
 
-----Original Message-----
From: = Ulrich pordesch=20 [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, = 2004=20 13:07
To: ietf-ltans@imc.org
Subject: why we need=20 sequences of timestamps

Santosh

envisage the following court case (we conducted such = cases=20 last fall in an academic study, using real lawyers and judges - and = not only=20 with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. = Afterwards, he=20 wrote and signed an operation report.  In 2020, the patient sues = the=20 hospital for damages in the value of millions, because allegedly there = was an=20 error in the operation.  This alleged error then lead to her = later=20 disability. Let us assume that the doctor's signature used the = algorithm=20 RSA-1024,

which became insecure in the year 2007.  = Furthermore, in=20 2020, signatures created with such a weak key can be easily forged. = Therefore,=20 at the time of the legal suit, anyone could forge the document and=20 signature.

The signature has become worthless. It is only of = value, if it=20 is provable that it existed before 2007. What can the hospital do to = be able=20 to convince a judge?  Which method should it adopt?  How can = LTANS=20 help the hospital?

Case 1
------ =
The hospital does not want to use an external archive service = provider,=20 rather it wants to provide its own in-house archive = services.

ERS: By 2020, its archive system created a chain of, = e.g., 3=20 time-stamps.  The time-stamps were retrieved according to RFC = 3126 and=20 from a legal, accredited time-stamp authority.  The court = verifies this=20 change of time-stamps, namely the Evidence Record.  Because the=20

time-stamps were timely renewed, before the = algorithms became=20 weak (according to the yearly published list of trustworthy = algorithms) and=20 because the used TSA is demonstrably accredited and thus was = inspected, the=20 evidence will be recognised.  Actually, the court must recognise = it,=20 since there are such evidence rules, which virtually force it to do=20 so.

n-of-m: As far as I see it, Shamir's scheme does not = offer any=20 value for this case.  The hospital could, at best, present to the = court a=20 confirmation from its own system, that says the document was added to = its=20 system in 2000.  This is hardly credible.  The judge will = send an=20 expert to the hospital, who will search through the hospital's archive =

and protocols.  This can be very expensive and = the chance=20 of success is at best poor.

Case 2
------ =
The hospital uses an external service provider, a TAA, let's = call it=20 Uli-TAA.

ERS: The provider creates an evidence record, as = above, using=20 time-stamps from an accredited TSA.  There is no difference in = the court=20 case.  It will be recognised, that the archive time-stamps are = correct=20 and were timely generated and thus, the signature existed before 2007 = and=20 cannot have been forged.

n-of-m: The hospital can only present the = confirmation from=20 Uli-TAA, who asserts, that the document was archived in 2000.  = Since this=20 was not a legally recognised method, it is difficult to prove the=20 trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external = providers,=20 Uli-TAA and Santosh-TAA, and splits its messages.  As Antje = already said,=20 she is not overwelmed with enthusiasm for this, since her costs will = double.=20 However, let's assume that two providers are used.  Furthermore, = let's=20 also assume that it is provable that the two pieces belong together, = that is,=20 that random

document pieces cannot combined together (I have not = checked,=20 whether this requirement of the provability of uniqueness exists, but = let's=20 assume it).

ERS: Both TAAS offer their evidence records and it = will be=20 proven that both pieces were archived in 2000.  The fact that the = pieces=20 belong together and thus the original document existed in 2000 is part = of our=20 assumptions.  I must point out that for the case of the = splitting, there=20 is no binding rule for the judge, and we thus do not know, whether the =

judge will actually make such a ruling or = not.

n-of-m: The judge receives a confirmation from = Uli-TAA and=20 Santosh-TAA, that the document existed in their systems in 2000.  = It=20 could be that the judge is convinced.  But perhaps he will say: I = cannot=20 estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must=20

prove that Uli-TAA and Santosh-TAA were completely = trustworthy=20 in the last 20 years. Good luck with that.


I haven't even considered the special cases, where = Uli-TAA is=20 bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no = longer=20 exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides = us with a=20 high volume suitable, secure method that is provable in court.  = This is=20 true since the security of the method only relies on the accreditation = of the=20 algorithms and time-stamp machines (TSAs).  There is no = foundation for=20 the distribution of documents and the trustworthiness of TAAs.  = One=20

could define rules for which policies TAAs must = have, which=20 security measures they must use and how they will be regularly audited = etc.=20 However, I tend to rule out that one can achieve a comparable level of = security through this manner.

Where one could make further considerations is the = combination=20 of both methods.  Additional confirmations from the TAAs, saying = that=20 they had the document or piece, could be in specific cases an = alternative for=20 ERS, in particular, in the case that something went wrong during the=20 time-stamp renewal.

Uli

------=_NextPart_000_0000_01C41AE1.F279F860-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35AHPis059756; Mon, 5 Apr 2004 03:17:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35AHP7d059755; Mon, 5 Apr 2004 03:17:25 -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.11/8.12.8) with ESMTP id i35AHNee059747 for ; Mon, 5 Apr 2004 03:17:24 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i35AHIN21648; Mon, 5 Apr 2004 12:17:18 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 5 Apr 2004 12:17:18 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i35AHHA13609; Mon, 5 Apr 2004 12:17:17 +0200 (MEST) Date: Mon, 5 Apr 2004 12:17:17 +0200 (MEST) From: Peter Sylvester Message-Id: <200404051017.i35AHHA13609@chandon.edelweb.fr> To: ietf-ltans@imc.org, tobias.gondrom@ixos.de Subject: Re: FW: why we need sequences of timestamps X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The signature has become worthless. It is only of value, if it is provable > that it existed before 2007. What can the hospital do to be able to convince > a judge? Which method should it adopt? How can LTANS help the hospital? > An archive system that answers to a client (the hosptal) that is has taken the responsiblity of the data at some indicated time. When the client store the data, the inspect the answer and check whether the time is close to current. An archive server can link together all attestations and one can require that all indicated dates are conformant to the linking. In this way, a server cannot create an attestation that is earlier than the last created one. An auditing entity or any other client can obtain 'pseudo attestations' from the archive server at regular times or totally randomly and verify that the times are acceptable. We are not in a situation where accurany of milliseconds is required, just days. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i359JvAu053091; Mon, 5 Apr 2004 02:19:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i359JvBo053090; Mon, 5 Apr 2004 02:19:57 -0700 (PDT) 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 i359JtRX053067 for ; Mon, 5 Apr 2004 02:19:56 -0700 (PDT) (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 i359JsGj014431 for ; Mon, 5 Apr 2004 11:19:54 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Apr 2004 11:22:00 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D54A0@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: Problem with mailing-list: some emails got lost :-( Date: Mon, 5 Apr 2004 11:21:54 +0200 Importance: high X-Priority: 1 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: Dear all, There seems to be some problem with the mailing-list. Some emails have not been transmitted. I'm tracking the problem. Until then when you send emails to the list please take a look whether it has really been transmitted - as you are also part of the mailing-list you should receive one copy of your own email too. If not, please report the error to me. Regards Tobias Chair LTANS Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35928g4046113; Mon, 5 Apr 2004 02:02:08 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i35928L1046112; Mon, 5 Apr 2004 02:02:08 -0700 (PDT) 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 i35926qJ046093 for ; Mon, 5 Apr 2004 02:02:07 -0700 (PDT) (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 i35925gu013775 for ; Mon, 5 Apr 2004 11:02:05 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ7F7K>; Mon, 5 Apr 2004 11:04:18 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D549E@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Subject: FW: why we need sequences of timestamps Date: Mon, 5 Apr 2004 11:04:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41AEC.F0A00740" 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_01C41AEC.F0A00740 Content-Type: text/plain Hello LTANS, somehow a message from Uli got lost. :-( So he asked me to forward it to the community. Tobias Ps.: I will try to find out what went wrong. -----Original Message----- From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de] Sent: Sunday, April 04, 2004 13:07 To: ietf-ltans@imc.org Subject: why we need sequences of timestamps Santosh envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others): Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report. In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation. This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024, which became insecure in the year 2007. Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature. The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge? Which method should it adopt? How can LTANS help the hospital? Case 1 ------ The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services. ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps. The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority. The court verifies this change of time-stamps, namely the Evidence Record. Because the time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised. Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so. n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case. The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000. This is hardly credible. The judge will send an expert to the hospital, who will search through the hospital's archive and protocols. This can be very expensive and the chance of success is at best poor. Case 2 ------ The hospital uses an external service provider, a TAA, let's call it Uli-TAA. ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA. There is no difference in the court case. It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged. n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000. Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years. Case 3 ------ The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages. As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used. Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it). ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000. The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions. I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the judge will actually make such a ruling or not. n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000. It could be that the judge is convinced. But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that. I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations. Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court. This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs). There is no foundation for the distribution of documents and the trustworthiness of TAAs. One could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner. Where one could make further considerations is the combination of both methods. Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal. Uli ------_=_NextPart_001_01C41AEC.F0A00740 Content-Type: text/html Message
Hello LTANS,
 
somehow a message from Uli got lost. :-(
So he asked me to forward it to the community.
 
Tobias
 
Ps.: I will try to find out what went wrong.
 
 
-----Original Message-----
From: Ulrich pordesch [mailto:pordesch@sit.fraunhofer.de]
Sent: Sunday, April 04, 2004 13:07
To: ietf-ltans@imc.org
Subject: why we need sequences of timestamps

Santosh

envisage the following court case (we conducted such cases last fall in an academic study, using real lawyers and judges - and not only with an ERS-similar method, but also others):

Doctor A operated on patient B in year 2000. Afterwards, he wrote and signed an operation report.  In 2020, the patient sues the hospital for damages in the value of millions, because allegedly there was an error in the operation.  This alleged error then lead to her later disability. Let us assume that the doctor's signature used the algorithm RSA-1024,

which became insecure in the year 2007.  Furthermore, in 2020, signatures created with such a weak key can be easily forged. Therefore, at the time of the legal suit, anyone could forge the document and signature.

The signature has become worthless. It is only of value, if it is provable that it existed before 2007. What can the hospital do to be able to convince a judge?  Which method should it adopt?  How can LTANS help the hospital?

Case 1
------
The hospital does not want to use an external archive service provider, rather it wants to provide its own in-house archive services.

ERS: By 2020, its archive system created a chain of, e.g., 3 time-stamps.  The time-stamps were retrieved according to RFC 3126 and from a legal, accredited time-stamp authority.  The court verifies this change of time-stamps, namely the Evidence Record.  Because the

time-stamps were timely renewed, before the algorithms became weak (according to the yearly published list of trustworthy algorithms) and because the used TSA is demonstrably accredited and thus was inspected, the evidence will be recognised.  Actually, the court must recognise it, since there are such evidence rules, which virtually force it to do so.

n-of-m: As far as I see it, Shamir's scheme does not offer any value for this case.  The hospital could, at best, present to the court a confirmation from its own system, that says the document was added to its system in 2000.  This is hardly credible.  The judge will send an expert to the hospital, who will search through the hospital's archive

and protocols.  This can be very expensive and the chance of success is at best poor.

Case 2
------
The hospital uses an external service provider, a TAA, let's call it Uli-TAA.

ERS: The provider creates an evidence record, as above, using time-stamps from an accredited TSA.  There is no difference in the court case.  It will be recognised, that the archive time-stamps are correct and were timely generated and thus, the signature existed before 2007 and cannot have been forged.

n-of-m: The hospital can only present the confirmation from Uli-TAA, who asserts, that the document was archived in 2000.  Since this was not a legally recognised method, it is difficult to prove the trustworthiness of Uli-TAA during the last 20 years.


Case 3
------
The hospital uses 2 external providers, Uli-TAA and Santosh-TAA, and splits its messages.  As Antje already said, she is not overwelmed with enthusiasm for this, since her costs will double. However, let's assume that two providers are used.  Furthermore, let's also assume that it is provable that the two pieces belong together, that is, that random

document pieces cannot combined together (I have not checked, whether this requirement of the provability of uniqueness exists, but let's assume it).

ERS: Both TAAS offer their evidence records and it will be proven that both pieces were archived in 2000.  The fact that the pieces belong together and thus the original document existed in 2000 is part of our assumptions.  I must point out that for the case of the splitting, there is no binding rule for the judge, and we thus do not know, whether the

judge will actually make such a ruling or not.

n-of-m: The judge receives a confirmation from Uli-TAA and Santosh-TAA, that the document existed in their systems in 2000.  It could be that the judge is convinced.  But perhaps he will say: I cannot estimate trustworthyness of Ulis and Santoshs TAAs. The hospital must

prove that Uli-TAA and Santosh-TAA were completely trustworthy in the last 20 years. Good luck with that.


I haven't even considered the special cases, where Uli-TAA is bought by Alexij-TAA (or Santosh-TAA), and thus after 20 years no longer exists and cannot be asked for confirmations.

Short summary: Archive time stamp sequences provides us with a high volume suitable, secure method that is provable in court.  This is true since the security of the method only relies on the accreditation of the algorithms and time-stamp machines (TSAs).  There is no foundation for the distribution of documents and the trustworthiness of TAAs.  One

could define rules for which policies TAAs must have, which security measures they must use and how they will be regularly audited etc. However, I tend to rule out that one can achieve a comparable level of security through this manner.

Where one could make further considerations is the combination of both methods.  Additional confirmations from the TAAs, saying that they had the document or piece, could be in specific cases an alternative for ERS, in particular, in the case that something went wrong during the time-stamp renewal.

Uli

------_=_NextPart_001_01C41AEC.F0A00740-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i333sDSn036078; Fri, 2 Apr 2004 19:54:13 -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 i333sDhV036077; Fri, 2 Apr 2004 19:54:13 -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 i333sCFg036071 for ; Fri, 2 Apr 2004 19:54:13 -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 i333sJAt011822 for ; Fri, 2 Apr 2004 22:54:19 -0500 From: "Santosh Chokhani" To: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Date: Fri, 2 Apr 2004 23:54:19 -0400 Message-Id: <20040403035419.M84002@orionsec.com> In-Reply-To: <406E254A.4F3988D2@ix.netcom.com> References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> <20040402123646.M66414@orionsec.com> <406E254A.4F3988D2@ix.netcom.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (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: What does not jive? Why can the client and/or the TAAs apply or obtain time stamp. What is the reason for that not being godo enough? On Fri, 02 Apr 2004 18:45:35 -0800, Jeff Williams wrote > Santosh and all, > > Santosh Chokhani wrote: > > > Jeff: > > > > The idea is not that a rime stamp is not needed. The client can obtain a > > time stamp. > > This does not jive with your comments below. However that aside, > obtaining a time stamp and one provided for at the time the archive > is created or the record is or was created and/or also archived, > is not the same as a obtaining one... > > > Each TAA can obtain or assert a time stamp. The assertion by > > TAA could be in the form of simply time or 3161 compliant time stamp. > > Again asserting and/or obtaining a time stamp is not the same as > one created at the time the record/records or archive is created... > > > > > > > On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > > > Santosh and all, > > > > > > I can't invision how a trusted archive be devoid of an accurate > > > time stamp... > > > > > > Santosh Chokhani wrote: > > > > > > > Brian: > > > > > > > > I do not think trusted archive requires providing date and time service. > > > > > > > > If the trusted archive requirement is to attest to the date of any > > document, > > > > then each TAA may put a date time stamp or get date-time stamp from an > > > > authority and add proper trust anchors, certificates and revocation > > > > information. > > > > > > > > n of m only helps with integrity, availability, and provides protection > > > > against perceived collusion threat. > > > > > > > > -----Original Message----- > > > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > > > Sent: Wednesday, March 31, 2004 6:41 AM > > > > To: Larry Masinter > > > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > > > Subject: Re: Alternatives for Long Term Archiving > > > > > > > > Larry or Santosh, > > > > > > > > Could someone tell me how the n of m scheme replaces the need of an > > > > (accredited) time-stamping or time-marking service, when the date of > > > > document existance must be proved? Is it assumed that each TAA simply > > > > states (and signs) when the document existed and when n TAAs state the > > > > same date, this date is correct and trustworthy? > > > > > > > > Regards, > > > > Brian > > > > > > 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 > > > Registered Email addr with the USPS > > > 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 > Registered Email addr with the USPS > Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i330rXcf025562; Fri, 2 Apr 2004 16:53:33 -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 i330rXVO025561; Fri, 2 Apr 2004 16:53:33 -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 i330rXre025555 for ; Fri, 2 Apr 2004 16:53:33 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust53.tnt59.dfw5.da.uu.net ([67.203.43.53] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B9ZPg-0006WA-00; Fri, 02 Apr 2004 19:53:33 -0500 Message-ID: <406E254A.4F3988D2@ix.netcom.com> Date: Fri, 02 Apr 2004 18:45:35 -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: Alternatives for Long Term Archiving References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> <20040402123646.M66414@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: > > The idea is not that a rime stamp is not needed. The client can obtain a > time stamp. This does not jive with your comments below. However that aside, obtaining a time stamp and one provided for at the time the archive is created or the record is or was created and/or also archived, is not the same as a obtaining one... > Each TAA can obtain or assert a time stamp. The assertion by > TAA could be in the form of simply time or 3161 compliant time stamp. Again asserting and/or obtaining a time stamp is not the same as one created at the time the record/records or archive is created... > > > On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > > Santosh and all, > > > > I can't invision how a trusted archive be devoid of an accurate > > time stamp... > > > > Santosh Chokhani wrote: > > > > > Brian: > > > > > > I do not think trusted archive requires providing date and time service. > > > > > > If the trusted archive requirement is to attest to the date of any > document, > > > then each TAA may put a date time stamp or get date-time stamp from an > > > authority and add proper trust anchors, certificates and revocation > > > information. > > > > > > n of m only helps with integrity, availability, and provides protection > > > against perceived collusion threat. > > > > > > -----Original Message----- > > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > > Sent: Wednesday, March 31, 2004 6:41 AM > > > To: Larry Masinter > > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > > Subject: Re: Alternatives for Long Term Archiving > > > > > > Larry or Santosh, > > > > > > Could someone tell me how the n of m scheme replaces the need of an > > > (accredited) time-stamping or time-marking service, when the date of > > > document existance must be proved? Is it assumed that each TAA simply > > > states (and signs) when the document existed and when n TAAs state the > > > same date, this date is correct and trustworthy? > > > > > > Regards, > > > Brian > > > > 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 > > Registered Email addr with the USPS > > 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 Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32CakZg070505; Fri, 2 Apr 2004 04:36: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 i32Cak6K070504; Fri, 2 Apr 2004 04:36: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 i32CajFP070498 for ; Fri, 2 Apr 2004 04:36:45 -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 i32CakAt028939 for ; Fri, 2 Apr 2004 07:36:46 -0500 From: "Santosh Chokhani" To: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Date: Fri, 2 Apr 2004 08:36:46 -0400 Message-Id: <20040402123646.M66414@orionsec.com> In-Reply-To: <406D02C6.655CF8B4@ix.netcom.com> References: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> <406D02C6.655CF8B4@ix.netcom.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 69.143.113.169 (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: The idea is not that a rime stamp is not needed. The client can obtain a time stamp. Each TAA can obtain or assert a time stamp. The assertion by TAA could be in the form of simply time or 3161 compliant time stamp. On Thu, 01 Apr 2004 22:05:59 -0800, Jeff Williams wrote > Santosh and all, > > I can't invision how a trusted archive be devoid of an accurate > time stamp... > > Santosh Chokhani wrote: > > > Brian: > > > > I do not think trusted archive requires providing date and time service. > > > > If the trusted archive requirement is to attest to the date of any document, > > then each TAA may put a date time stamp or get date-time stamp from an > > authority and add proper trust anchors, certificates and revocation > > information. > > > > n of m only helps with integrity, availability, and provides protection > > against perceived collusion threat. > > > > -----Original Message----- > > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > > Sent: Wednesday, March 31, 2004 6:41 AM > > To: Larry Masinter > > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > > Subject: Re: Alternatives for Long Term Archiving > > > > Larry or Santosh, > > > > Could someone tell me how the n of m scheme replaces the need of an > > (accredited) time-stamping or time-marking service, when the date of > > document existance must be proved? Is it assumed that each TAA simply > > states (and signs) when the document existed and when n TAAs state the > > same date, this date is correct and trustworthy? > > > > Regards, > > Brian > > 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 > Registered Email addr with the USPS > Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3295nTY036709; Fri, 2 Apr 2004 01:05:49 -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 i3295ni5036708; Fri, 2 Apr 2004 01:05:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from prometheus.terms.cz (prometheus.terms.cz [81.90.160.70]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3295lBx036639 for ; Fri, 2 Apr 2004 01:05:48 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 ([81.90.165.93]) by prometheus.terms.cz (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3294lDe010291 for ; Fri, 2 Apr 2004 11:04:54 +0200 From: To: Subject: RE: Our objections to draft ERS Date: Fri, 2 Apr 2004 11:04:39 +0200 Message-ID: <000601c41891$8be4f8e0$6402a8c0@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C418A2.4F6DC8E0" 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 In-reply-to: <406BDE1E.3040401@sit.fraunhofer.de> 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_0007_01C418A2.4F6DC8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, > In your example, the whole CMS object, as in RFC 3126, should be > given to the TAA for archiving. I have one quite elementary question to verify if I understand well. See the following example: Today 2nd April 2004, I digitally sign the digital contract and I do not have the TAA at my disposal at present. My certificate for the digital signature verification will expire 30th April 2004. When signing acc. to RFC-3126, I will add the non-signed attribute Electronic Signature Timestamp, containing the time stamp acc. to RFC-3161 with the TSA certificate (expire date 31st Dec. 2008), to the CMS message, containg the digitally signed contract. In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement (CMS message) into this TAA. This will create the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued with the issue date of the following root hast-tree - let's say 6th May 2007. In 2020, I will submit this contract to the court as a proof. I am obliged to prove the non-repudiation. This means, I will obtain the ERS from the TAA, which can prove, that the whole CMS message has not been changed from the first issuing of the ArchiveTimeStamp in 6th May 2007 up to present. Now, the CMS message will be verified the same way it would have been done in 6th May 2007. It means, I will verify that the time stamp in the non-signed attribute had a valid TSA digital signature in 6th May 2007. The time stamp was issued in 2nd April 2004. I will verify if my personal signature certificate was valid in 2nd April 2004..... Result: digital contract is valid. 2.4.2004 6.5.2007 2020 -+----------------------+--------------------------------------+-- <------------CMS validity-------------> <-----------------ERS validity----------->>> Libor ------=_NextPart_000_0007_01C418A2.4F6DC8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zpráva

Brian,

> In your = example, the=20 whole CMS object, as in RFC 3126, should be
> given to the TAA for = archiving.

I have one quite elementary question to verify if I = understand=20 well. See the following example:

Today 2nd April 2004, I = digitally sign=20 the digital contract and I do not have the TAA at my disposal at = present.=20 My certificate for the digital signature verification will expire 30th = April=20 2004. When signing acc. to RFC-3126, I will add the non-signed attribute = Electronic Signature Timestamp, containing the time stamp acc. to = RFC-3161 with=20 the TSA certificate (expire date 31st Dec. 2008), to the CMS message, = containg=20 the digitally signed contract.

In 2007, I will start the TAA. In = 1st May=20 2007, I will archive my agreement (CMS message) into this TAA. This will = create=20 the ERS with the first ArchiveTimeStamp, issued after 1st May 2007. This = ArchiveTimeStamp is issued with the issue date of the following root = hast-tree -=20 let's say 6th May 2007.

In 2020, I will submit this contract = to the=20 court as a proof. I am obliged to prove the non-repudiation. This means, = I will=20 obtain the ERS from the TAA, which can prove, that the whole CMS message = has not=20 been changed from the first issuing of the  ArchiveTimeStamp in 6th = May=20 2007 up to present.

Now, the CMS message will be verified the = same way it=20 would have been done in 6th May 2007. It means, I will verify that the = time=20 stamp in the non-signed attribute had a valid TSA digital signature in = 6th May=20 2007. The time stamp was issued in 2nd April 2004. I will verify if my = personal=20 signature certificate was valid in 2nd April 2004..... Result: digital = contract=20 is valid.

 2.4.2004         =       6.5.2007     = ;            =             &= nbsp; 2020
-+----------------------+--------------------------------------+-- <------------CMS=20 validity------------->
       &n= bsp;           &nb= sp;    <-----------------ERS=20 validity----------->>>

   
Libor

 =20

------=_NextPart_000_0007_01C418A2.4F6DC8E0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324EBe8059328; Thu, 1 Apr 2004 20:14: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 i324EB4e059327; Thu, 1 Apr 2004 20:14:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324EAqu059321 for ; Thu, 1 Apr 2004 20:14:10 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust202.tnt36.dfw9.da.uu.net ([67.234.81.202] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B9G40-0003dm-00; Thu, 01 Apr 2004 23:13:53 -0500 Message-ID: <406D02C6.655CF8B4@ix.netcom.com> Date: Thu, 01 Apr 2004 22:05:59 -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: Alternatives for Long Term Archiving References: <003e01c417ed$b7e2ab30$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: Santosh and all, I can't invision how a trusted archive be devoid of an accurate time stamp... Santosh Chokhani wrote: > Brian: > > I do not think trusted archive requires providing date and time service. > > If the trusted archive requirement is to attest to the date of any document, > then each TAA may put a date time stamp or get date-time stamp from an > authority and add proper trust anchors, certificates and revocation > information. > > n of m only helps with integrity, availability, and provides protection > against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each TAA simply > states (and signs) when the document existed and when n TAAs state the > same date, this date is correct and trustworthy? > > Regards, > Brian 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 Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320TAEs042451; Thu, 1 Apr 2004 16:29: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 i320TA4Y042450; Thu, 1 Apr 2004 16:29:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320T9Rn042439 for ; Thu, 1 Apr 2004 16:29:09 -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-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i320T8SP016530 for ; Thu, 1 Apr 2004 16:29:08 -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 i320T53k005375 for ; Thu, 1 Apr 2004 16:29:05 -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 <0HVI00030PCHOH@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Thu, 01 Apr 2004 16:29:05 -0800 (PST) Date: Thu, 01 Apr 2004 16:28:54 -0800 From: Larry Masinter Subject: (Long) comments on requirements document To: ietf-ltans@imc.org Message-id: <0HVI00031PCHOH@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: AcQYIMBzyKsLVCNSRL6hENsO4L9NBAACfZbwAAehtKA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me try to make some concrete suggestions for updates to draft-ietf-ltans-reqs-00.txt to remove from it the assumption or requirement that a long-term archive MUST use hash algorithms for time stamps or encryption for privacy. My goal is not to require non-hash-based time stamps, but rather, not to exclude it from the requirements document. I think we can be more productive than continuing the discussion in the abstract, since I don't think the abstract discussion is converging, and we're having one of these talking-past-each-other conversations ("I don't think this solution will work", "But the problem is important and we need a solution now") I started to review the document just for places where it unnecessarily made assumptions, but wound up reviewing more generally. I'm sorry for the length. I also will cheerfully admit that I might be completely wrong, have misunderstood or misinterpreted the current document, and so I hope you will take my comments as questions or at least constructive. ============================= CURRENT: A long-term archive service aids in the preservation of data over long periods of time. In particular, it periodically performs activities to preserve the non-repudiation of existence and integrity as well as ensuring the availability of data. Instead of "In particular, it periodically performs...", say "For example, it might periodically perform...". This leaves the door open for long-term archive services that do not need to "periodically" perform activities. ============================== CURRENT: A variety of technical and operational means are required to achieve this goal and technical issues beyond cryptography, such as storage media lifetime, disaster planning, changes in processing or software technology, etc., as well as legal issues must be addressed. I suggest: NEW: A variety of technical and operational means are required to achieve this goal. A solution must address issues such as storage media lifetime, disaster planning, changes in processing and software technology and legal issues, in addition to technical issues of cryptography. This is just wordsmithing. It may be that you can accomplish long-term archiving without 'cryptography' per se (well, secret sharing is described in 'Applied Cryptography' and 'Current Cryptology' but still). ============================== About digital signatures: CURRENT: 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 past the cryptoperiod of the signature private key, is a candidate for preservation using a long-term archive service. I propose: NEW: A long-term archive or notary service may be used to validate the existence of documents, or assertions of agreements, e.g., originally asserted with digital signatures, at times in the future well beyond the validity period of the certificate used originally for signing the document, or even the validity of the algorithms available for digital signatures or encryption. I believe the verification is not of the "digital signature" per se, but an assertion that the parties involved signed the document at the date claimed. So it isn't the "signature" that needs to be verified, it's the agreement. The signature is a way of communicating the agreement. ====================== On requirements: OLD: Operational requirements, such as storage media concerns, individual legal requirements and questions dealing with accounting and billing techniques are not addressed by this document. My concern here is that we might not be able to get away with not addressing other requirements; are they operational or technical? Issues with the long-term interpretability of file formats, with metadata, and with identity of principals. I think that we need to address what assumptions we're making about these things, e.g., that the documents are represented in formats that the originator believes will be interpretable during the lifetime of the signature, that identity of roles (people and organizations) are meaningful over the same lifetime. I think there is a problem with identity in the same time-scale as we're concerned with in long-term archives. AT&T 20 years ago isn't the same organization as AT&T today. ========================================== Originator: Role (person or process) who produces, and possibly signs, a data object that is to be archived. The Originator does not necessarily generate or request generation of an evidence record for the data. Do you want to use the term 'principal' here, since it is standard, rather than 'Role', and give a reference? Again, I think there may be a problem if the lifetime of being able to determine identity isn't as long as the lifetime required for archival. ============================================= 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). I think there is a problem, in that this definition combines the function (asserting that a document existed or had been asserted at a given point in time) and the mechanism for accomplishing that function (e.g., RFC 3161). I'm not sure RFC 3161 gives a good structure for timestamps, for timestamps that have to survive for as long as this document claims is its requirement. Also, "Timestamp Authority (TSA)" isn't define in the glossary, even though it is referenced. So I think that it is necessary to separate out the notion of an "assertion of existence of a document or statement/agreement" from the electronic timestamp mechanism referenced. ================================================== User: Role (person or process), who submit data objects for archiving, request archive packages and verify the evidence of an archived data object using the associated evidence record, optionally including the verification of any signatures within the archived data object itself. I think it's confusing to call this "User", perhaps "Submitter"? There are a lot of users running around. =================================================== 3.1.3 Preservation of evidence for signed or timestamped data Archived data objects may contain digital signatures or time stamps to be able to prove the origin and the time of existence of these objects and signatures. In the course of time the value of evidence of these signatures or timestamps can decrease or can get lost for many reasons: I'm not sure that the requirement is to 'preserve the evidence'. Rather, the requirement is to be able to credibly assert in the future something that is currently asserted. The future assertion might or might not use a similar mechanism as the current assertion. So you might accomplish future assertion of timestamp by somehow "renewing" a timestamp, but you might also accomplish it by having several trusted organizations willing to assert that, according to their records, the document was received at a particular time, with no use of tree-hash-based timestamps. In order to avoid problems in case of disputes in the future it is necessary to preserve a digitally signed document, as well as certificates, revocations lists, OCSP responses and time stamps, even if these elements are not included in the signed document itself. I don't believe this statement. Certainly keeping all of these things won't "avoid problems" in the case of disputes. And keeping these things might not be necessary. By periodically inspecting and acting upon stored evidence, it is possible to generate a cryptographically protected history for a data item that contains no periods of time during which an algorithm was thought to be weak, an authority thought to be compromised, etc. I don't believe this sentence either, or at least, not that it is true without other conditions. After all, there is no way to predict when an algorithm might suddenly be 'thought to be weak'. So it's hard to imagine a practice that would guarantee such a history. Perhaps there is an operational practice which would ensure that it would be very unlikely there would be no such periods, but my impression was that you were going to leave such operational practices "out of scope". ===================================== - The Long-term Archive Service is to store archived data objects over a long, optionally undefined, period of time. I think rather than "optionally undefined" you might mean "arbitrarily long"? Typically in records management, there is a well-defined retention schedule. ================================ - The Long-term Archive Service provides material needed to prove the existence and integrity of data objects for users as well as in court. These means especially are time-stamps, periodically generated during the archiving period of the data objects. Additional verification data, to verify these time-stamps after a long period of time (CRLS, OCSP responses and certificates) need also be provided Again, I don't think that the particular mechanism alluded to here -- of periodically generated time stamps -- should be part of the requirements. It may be part of a proposed solution, but the requirement is to credibly be able to verify the existence of the document at its original communication date. ============================================= 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). This doesn't read right. It is to be designed to not solve these problems? Or it is not necessary to solve all such problems? I think this section is alluding to some problems that you want to rule out of scope. Of course, the problem here is the confounding of the problem statement with one proposed mechanism for solving the problem. I think the point of the section is that the archive service needs to be aware of the assertions that it is being called upon to assert in the future, and that embedded signatures need to be recognized somehow. I don't see any reason why an archive service SHOULDN'T be able to provide assurance about embedded signatures as well as external ones, except that the location of the signature needs to be clear. I don't see why SCVP or DVCS (references?) are referenced here. =========================================== - Archive service assuring long-term Non-Repudiation Long-term Archive Service stores data objects like signed or unsigned documents for identified and authenticated users. It generates time stamps for these data objects and obtains necessary verification data over a given time or until a request of deletion by this authorized user is sent. Again, I'm concerned about long-term identity of what might constitute an "authorized user". This also seems to bake in the notion that one (and only one) user is required to authorize a deletion. With contractual data, for example, you might expect that a third-party archive service might offer to only delete records where the deletion is requested by both parties, not just one. This can't be easily simulated with a single role-based user authorization model. And this 'requirement' seems to bake in the 'periodic replenishment of timestamps' mechanism unnecessarily. ================================================ - Pure long-term non-repudiation Service Long-term Archive Service only guarantees non-repudiation of existence of data. It periodically generates time stamps and obtains additional verification data for a given period of time. It stores data objects (e.g. documents, but also relevant parts of documents containing signatures) locally only for the purpose of non- repudiation. It is not a document-archive for users and therefore does not provide retrieval of documents and no deletion of data objects. Therefore it does not need any access control. I'm not sure that access control is unneeded even for pure non-repudiation services, if it is possible to retrieve the metadata, or to search for documents. I think "it stores data objects " is not proscriptive, but is intended as a possibility. I *think* you're trying to define a long-term notary service with this scenario -- a service that asserts, over the long term, the dated assertion at a particular time. I'm not sure why you aren't using the term, though. ===================================== 3.3 Instances and overall architecture Is this section meant to be an example, or actually proscriptive? Is this just saying how you MIGHT build an archive or notary service, or are you requiring them all to work this way? The text sort of sounds like you intend it to be normative, and I'm not sure why this belongs in a requirements document. Users transfer the data objects that shall be archived at the Trusted Archive Authority (TAA) using their application of choice. I'm confused -- it sounds like you're imagining that there is a user-determined transfer protocol for actually uploading the data, and that the archive protocol then is applied, after the fact, to the previously transferred data. Is this what you meant? ================================ Long-term Archive Service may allow for relays using Long-term Archive Protocol. The use of external archive services may be also possible. But Relaying must be transparent to the client. Here you're allowing the TAA to relay the request to other archive services (1 out of 2) and possibly to multiple services (K out of N). So this architecture might be consistent with K out of N archiving after all, without too many changes. ============================ A TAA may be a server within an enterprise network communicating with local archive servers and other applications or an external service accessible via internet. Is this an issue of firewalls, trust and organizational control, or some other factors? This is the first time the document alludes to the possible organizational relationship between the various parties involved, but I think the relationship is crucial, an important part of the analysis of the validity of long-term archives, and probably needs to be expanded elsewhere. If an organization is charged with archiving its own documents, then it could assert that a contract was valid even if it wasn't. Doesn't the long-term threat model for document forgery require organizational independence of the TAA/TSA that is doing revalidation of signatures? ================================= 4. Long-term Archive Service functional and quality requirements ... - Generate, store and maintain evidence records (i.e. by periodically obtaining timestamps) for data objects submitted for preservation; I think the requirement is to be able to provide, over the lifetime of the record, assurances that were originally obtained through techniques such as timestamps and digital signatures. I don't think there is a requirement for periodically obtaining timestamps. ======================================== - Be able to provide an acknowledgement that a data object existed at a certain time, as an alternative, if user is not able to interpret the evidence record; I think this is a key to a longer discussion about how to provide for long-term interpretability of records, though providing records in standard archivable formats, and providing, at the time of archiving, conversions of the record to multiple formats, etc. ======================================== A long-term archive service must be able to work efficiently even for large amounts of archived data objects. In order to limit expenses, costs and dependency on high performance, time-stamp services, the number of necessary time stamps MUST be minimized and a time stamp should include a large number of signatures and documents; This is pretty strong for a MUST (and RFC 2119 is probably not appropriate here anyway). I don't understand why this is here at all I guess this is assuming some cost model for timestamp services? What is the use case where this matters? =========================== Necessity to access stored archived data object SHOULD be minimized. It SHOULD only be necessary access to the archived data objects only if the archived data objects are requested by users or if applied hash algorithms become insecure. This comment isn't just here, but I just thought of it. There's some assumption here about identifiers for records, or searching for records, or record locators, that isn't discussed in this draft. (I remember some conversation about this at the meeting, though.) How are records identified? Are the record identifiers globally unique? Use the hash of the document for its identifier, for example? Who has access to the record? Interestingly, even if one-way hash algorithms are cracked (someone finds a way of generating another document with different content with the same hash), it's still unlikely that you could _discover_ a valid document hash without knowing anything. So you might provide access control for documents by using document hashes as the key for accessing the document. I don't understand why it is important to minimize the access to stored archived data, as a protocol requirement. This sounds like it's an operational requirement for a well-implemented TAA service, but there are other operational and implementation requirements that aren't mentioned here. ("It should work. It should run on commercially available platforms. It shouldn't have any security holes. It shouldn't erase its disk periodically."). ========================================= The data structure for the evidence record itself should have the following properties: - It MUST be possible to include all timestamps necessary to verify the existence of the archived data objects. .... Again, if there are ways of providing evidence for the existence of an assertion or signature or record at a given point in time, then this requirement would be empty. ============================== - It SHOULD be possible to provide evidence for groups of archived data objects. For example, it should be possible to archive a document file and a signature file together such that they get the same evidence record. - Where groups of data objects are submitted, non-repudiation proof MUST still be available for each archived data object separately. Is this a 'record' requirement or a protocol requirement? Why is this a requirement? The obvious use cases given in the document ("signed contracts or agreements, wills, property deeds, ...") don't have this kind of performance requirement. What are the uses for "CRLs and timestamps over any type of data" that would have this requirement? ======================================= - It SHOULD be possible to create timestamps without the need to access the archived data objects. The access to the archived data SHOULD only be necessary if the security suitability of employed hash algorithm is menaced. Why is this a requirement? Is this a performance requirement? An operational one? Just something you think might be a good idea? How often are timestamps created that this is important? ==================================== - It SHOULD be possible to package all evidence along with the archived data objects in a single data item or to package evidence and archived data objects in separate items. I think there is some assumption about 'evidence records' and their use that might be unclear. Evidence records are used to send assertions TO the archive service at the time the document is archived. And it might -- or might not -- be used to supply evidence when there is a dispute. Is it a requirement that the same data structure be used for both? ======================================== Standardization of a protocol for interactions with a Long-term Archive Service is desirable. The protocol should have the following properties: Again, here you say 'should' in front of a bunch of 'MUST's. I think probably the right thing to do is to get rid of the MUSTs (in some cases, and get rid of the requirement, in others). ============================================== - 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'm concerned about deletion, since a threat to a contract is to have one of the parties delete it. And I'm not sure of the value of deletion, or that it is actually possible, e.g., if the TAA backs up its disks and sends them offsite, is it possible to actually delete its records from its offsite backups? And I'm not sure 'submission of groups' is a MUST requirement. It sounds like a minor optimization. After all, the bulk of the protocol overhead is probably sending the data. ===================================== - The protocol MUST provide a response indicating successful submission or deletion of data. The acknowledgement of successful submission SHOULD permit a submitter to verify that the correct data was received by the service for preservation, e.g. the acknowledgement could include an index, a signature or a timestamp obtained for the archived data object. Shouldn't you always verify the correct data? I think that it's more important to provide for the converse: if there are any errors or difficulties with the request, the failure must be notified. Otherwise, the best you have is the archive service's guess that all went well. ================================ - The protocol MUST response an index to retrieve the archive package. It also should be possible to retrieve archive packages by using hash values of the archived data objects. Earlier you had it possible to get the data independent of the assertion. And "the hash value of the archived data object" is (as I said earlier) one way to get a handle on the document. But it's also problematic -- which hash? which handle? I think this mixes mechanism with requirement. When a package is archived, it gets a handle, and the protocol should allow for the retrieval of the package, assertions about the package, and pieces of the package. ============================================= - The protocol SHOULD support some basic Metadata (Mime-Type, key words, etc.), i.e. the client should be able to provide metadata along with the archived data to facilitate future search operations based on the metadata. Oh, this one is really problematic. First, allowing for search introduces lots of discovery attacks that might not be necessary. Why is this important? If the client wants to archive an index along with some documents, let them archive the index. On the other hand, metadata is crucial. Bits without understanding the interpretation of the bits aren't very useful. The question is whether you just need the content-type, or do you need all of the other content- MIME headers, e.g., content-language? For example, it would be useful to allow the possibility of multiple renderings of the same document in multiple formats, along with an assertion of their equivalence, for long-term document retention (e.g., XHTML, PDF/A, TIFF 6, Unicode text). =============================================== - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an error. - A Long-term Archive Service MUST provide an indication of the long-term archive policy under which the service operates. This is the first mention that I can find of 'archive policy'. What is this, how does a client request one, what are servers allowed not to implement and still be compliant? (There's no point in defining a standard for behavior of non-compliant participants, since they're already non-compliant!). How does a server 'indicate' a policy? ======================================== - The protocol MUST prevent replay attacks. It's odd that this is mentioned without any other attacks being mentioned. And it's not clear what kind of "replay attack" is being asked to be prevented. All? Even ones on unrelated services? ========================================= - The protocol SHOULD permit encryption of data before submission in such a way that there exists non-repudiation evidence for the unencrypted data. So this is assuming that communication between requestor and service isn't over a TLS? I'm not sure why this is a requirement. ===================================== - The protocol SHOULD provide means of associating submitted data objects with previously submitted data objects, i.e. to facilitate retrieval based on aggregation of objects over time. This is the first mention of "associating data". Does this mean that access to the first data object also gives you access to the second? Or just vice versa? How is the association noted? What is this used for? I don't see this in the use cases for contracts, land deeds, etc. ==================================== - The protocol SHOULD provide means for specifying a point in time at which an archived data object need no longer be preserved. It also should be possible to extend the archiving period. Extending the archiving period may also be problematic. Who is authorized to extend the archiving period for an agreement that was previously agreed would expire? ============================================== - The format for the acknowledgements MUST allow the identification of the archiving provider. - The format for the acknowledgements MUST allow (at least from the creating archiving provider) the identification of the participating client. see comments above about identity. Perhaps this is just metadata about the archived data rather than identity? ======================================== - Responses must uniquely reference corresponding requests This seems out of the blue. Any protocol with requests and responses needs some way of linking them, but it might be temporarily rather than through identifiers. ================================ - It should be possible to sign requests and responses. It is recommended that in particular acknowledgements are signed. Why is this a requirement? There is some security requirement for authentication of the participants in the protocol and their authorization to use the protocol and to be identified later, but why is it important to sign the requests and responses rather than, say, using TLS for the communication? ====================== - Deletion must be authenticated. See comments above about deletion. Deletion must be authorized, and authorization policy for Deletion must be observed. ============================== - The archive service MUST be able to provide evidence about the policies that have been used at any time I'm not sure how it is possible to supply evidence. This is very hard, in general, to provide evidence for policies that were used, especially if the policies are baked into the code or into various tables. And some of the policies are operational policies, not technical ones. ==================================== - The protocol SHOULD be as simple to use as possible. A quote attributed to Einstein: "Everything should be as simple as possible, but no simpler". Personally, I think that protocols are simple to use if they aren't new protocols. I wonder if the archival protocol could be implemented by using WebDAV over TLS with certain well-known dynamic properties identified for archival objects. ==================================== Means to enable accountability, access control, confidentiality of communication between applications and TAA need additional precautions (like SSL) that are outside the scope of these requirements. I think not. That is, there is a service requirement for those things, and there has to be some way of accomplishing them. In some cases, you're asking for things like signatures of requests which have only a transactional lifetime (of the request), and might be accomplished other ways. ======================================= 7. Security Considerations This section isn't really about 'security considerations' in the typical sense that IETF requires. What you're supposed to do is outline the threats a long term archive or notary service. You've written some things that also need to be considered, but probably as protocol requirements. ================================================= Where non-standard formats are used or proprietary processing is employed, verification of signatures on or in archived data may require the availability of specific applications or tools. I think this is really a matter of whether or not the long-term archive or notary service relies on these things at all. An archive service cannot assert the validity of a signature (at the time of submission) if it can't interpret the signature. And the believability of the assertion cannot be better than the believability of the signature and its associated software. =================================================== Certificate revocation could retroactively invalidate previously verified signatures. Measures may be implemented to support such claims by an alleged signer, e.g. collection of revocation information after a grace period during which compromise can be reported or preservation of subsequent revocation information. This is some requirement on the archive service at the time of submission, isn't it? ======================================================== Access control mechanisms associated with data stored by a TAA should consider the lifespan of the data object. For example, the credentials of an entity that submitted data to an archive may not be available or valid when the data needs to be retrieved. Well, worse, the identity of the entity might not be clear after 30 years. ======================================================== 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. This is completely out of place. It's one idea for an operational practice which might or might be credible for later asserting validity. And if you have 'write-once media', then deletion isn't possible! ================== Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31JQ5E3021234; Thu, 1 Apr 2004 11:26: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 i31JQ5PB021233; Thu, 1 Apr 2004 11:26: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 i31JQ4op021227 for ; Thu, 1 Apr 2004 11:26:04 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31JQ8At001521 for ; Thu, 1 Apr 2004 14:26:08 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 14:26:08 -0500 Message-ID: <004801c4181f$2ef557a0$9a00a8c0@hq.orionsec.com> 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.4510 In-reply-to: <077097E85A6BD3119E910800062786A9094D548A@muc-mail5.ixos.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31JQ5op021228 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias: You have the summary correct. If a party wants to store a document in its system at a single point, why do we need timestamps at all and further more why do we need to refresh them? I thought their purpose was to provide protection against a rogue TAA. If want single party to be in charge, we can just store the data. No crypto is needed. -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@ixos.de] Sent: Thursday, April 01, 2004 12:48 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Santosh, It's a bit hard for me to understand all the benefits from the n-of-m-split and why to use it. If you don't mind I try to bring up what I took from the discussion so far and you correct my misunderstanding: 1. n-of-m-split is not instead of ERS data structures - it is in addition ? (what I take from your mail to Antje) 2. n-of-m-split shall provide the security that the data is unchanged based on the idea that it is not possible to tamper all the TAA where the data is stored - or at least not the majority ? 3. n-of-m split has in mind some kind of High availablity and redundancy (like RAID systems ?) using a highly distributed infrastructure - some kind of P2P network ??? Some thought about that from my point of view: >From the business perspective I clearly doubt that any company - and probably not even a private person - would love to risk it's documents on an infrastructure not fully under it's control or that not at least can't be held fully reliable for the storage of the document. Of course within companies and institutions the distribution and redundancy of data is clearly wanted and today already done (e.g. RAID systems etc.) - so the risk to loose a document is something that the solutions already available today can handle quite good. (just talk with some storage vendors - like I had to do during the last months - and you will find that they are doing quite a good job at that.) Probably I missed something important, so please help me a little bit to understand. Tobias Chair of LTANS > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 01, 2004 17:47 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Ulrich: > > To solve the problem, if the person who feels that the > evidence may be needed (e.g., the client) can obtain a time > stamp, get all appropriate trust anchors, certificates, > revocation information attached, split n of m and submit to > the archives. Then, when the evidence needs to > reconstructed, n TAAs can supply their shares to construct > the original with all the signatures and time stamps. > > Why would that not be simple or meet the German Law? > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Ulrich Pordesch > Sent: Thursday, April 01, 2004 9:29 AM > To: ietf-ltans@imc.org > Subject: AW: Alternatives for Long Term Archiving > > > > Santosh: > > Getting a proof of existence of data at a certain time in the > past using (sequences/ chains of) time-stamps is an essential > part of the service and the reason, why we required this as > "must requirement" in requirements draft. Getting trust > relating to time- of existance by statements of a new kind of > trusted authorities (TAAs) is a completly other kind of > trust. This solution is not sufficient to conserve value of > evidence of signed documents in court, because there is no > law (in germany but also anywhere else, as I know), which > recognizes trusted archives like regulated/trusted time-stamp > authorities. I think we will never get such law, because > complex archive systems can not be evaluated to the same > degree as simple time-stamping-machines. Statements of TAAs, > provided by protocol, may be an additional useful features, > if there are users who need it. > > > Ulrich > > > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im > Auftrag von Santosh Chokhani > Gesendet: Donnerstag, 1. April 2004 15:32 > An: ietf-ltans@imc.org > Betreff: RE: Alternatives for Long Term Archiving > > > > Brian: > > I do not think trusted archive requires providing date and > time service. > > If the trusted archive requirement is to attest to the date > of any document, then each TAA may put a date time stamp or > get date-time stamp from an authority and add proper trust > anchors, certificates and revocation information. > > n of m only helps with integrity, availability, and provides > protection against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each > TAA simply > states (and signs) when the document existed and when n TAAs > state the > same date, this date is correct and trustworthy? > > Regards, > Brian > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31I3T23014941; Thu, 1 Apr 2004 10:03:29 -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 i31I3TRF014940; Thu, 1 Apr 2004 10:03:29 -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 i31I3SAG014922 for ; Thu, 1 Apr 2004 10:03:28 -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 i31I3Pkf017276; Thu, 1 Apr 2004 20:03:25 +0200 (MEST) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <2AHJ5XZA>; Thu, 1 Apr 2004 20:05:40 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D548C@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" , "'Hollerbach, Antje'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 20:05:20 +0200 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: Dear Jerman, dear Antje, > I've been silently waiting for an answer like yours. I must > admit, that I unfortunately do not find the discussion going > in direction of solving actual problems. I have to agree with you both. > From the position of > developer, implementation and technical advisor it is hard to > cope with current standards and proposes when facing the > problem of conserving electronic records. Document bases are > already full and usually in hands of single entity, which > sees appropriate solution as a technology add-on for > preservation of existing and future records. Here you are fully right. And btw. I know no company which would be willing to share it's documents with others or to rely on others to provide the with mission critical data - and most of the documents, that are signed, are important for some reason. > Re-distribution > doesn't make much sense, rather single point of trust is what > will IMHO evolve in the next years, the same scenario as > deployed for digital signatures currently. End users are > pressing really hard on us (technology providers) to come up > with solution right this moment. And what is needed is to > steer the initial LTANS course in the right direction and > deliver critical missing pieces in the infrastructure as soon > as possible. You are right. What I take from the request from the market at the moment are questions about an available standardized solution for mid of this year - that's in 3 months ! And with all these regulatory compliance stuff and the e-signature and so on this gets a lot of momentum at the moment! So if possible I would also like to speed-up our progress so far that we can deliver a good solution in time - and if necessary would like to add further improving ideas later in a second version - if they really fulfill requirements from the market. Regards Tobias > You may take some of your time and investigate > what solutions do exist already on the market in the line > with technical requirements, legislation and regulation and > how they would solve your problems. The situation is not that bad... > > Regards > > A. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > Hollerbach, Antje > > Sent: Thursday, April 01, 2004 10:05 AM > > To: chokhani@orionsec.com > > Cc: ietf-ltans@imc.org > > Subject: RE: Alternatives for Long Term Archiving > > > > > > > > > > I think that the use of different archive facilities is > > unrealistic for organisations like e.g. hospitals, because > > the costs are unreasonable, it is very complex and not > > practicable. Real users, such as our university hospital, > > which source out their archival system, want to keep their > > costs as low as possible. Furthermore, redistribution makes > > little sense for organisations that don't outsource. We need > > as soon as possible solutions, which can be used for the > > renewal of signatures and for the proof of the archiving > > time. Furthermore simple protocols for archiving services > > would be expedient. The previous documents of LTANS suit > > this purpose but not the thoughts in your mail below! > > > > A. Hollerbach > > Center for Information Management (ZIM), University Hospital > > of Heidelberg > > > > > > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: Wednesday, March 24, 2004 7:37 PM > > To: ietf-ltans@imc.org > > Subject: Alternatives for Long Term Archiving > > > > > > One of the ideas that came out of Seoul meeting (thanks to Larry > > Masinter) is to use a key-less approach to trusted archive. > > The client who has vested interest in the secure storage of > > archived data, can use Shamir's n of m scheme to submit the > > archived data to m archive facilities. m must be greater > > than 1 and should be selected based on availability needs. n > > must be greater than 1, less than or equal to m, and should > > be selected based on the desired degree of protection against > > collusion. > > > > If this scheme is used, we may not need any cryptographic > > operations at the TAA. > > > > Under this scheme, the LTANS WG would need to still define > > various protocol for submission, deletion, and retrieval. if > > the idea is acceptable to the group, it could be the > > preferred or one of the approaches to perform archiving. > > > > As the current LTANS documents in the various stages state or > > imply, the trusted archive can continue to be used to submit > > any class of data. > > > > One advantage of the approach is that any document split is > > not sensitive even if the original document is sensitive. > > However, if the document requires confidentiality, assuming > > an adversary could be monitoring the channels to collect all > > the splits, the submission and retrieval of the split should > > be provided transmission security using techniques such as > > SSL or session encryption. This still is lot easier than > > needing to provide long-term encryption for stored data. > > > > To further illustrate one usage of the approach, a client > > with the need to provide long-term, non-repudiation of a > > transaction, could obtain current time stamp, all the trust > > anchor, certificates, revocation information relevant to > > signatures and time stamp, and package them using TBD record > > format and create m splits. These m split could be sent to m > > TAAs using TLS. Each TLS could provide a pointer to its split. > > > > When there is a need to retrieve the evidence, n splits could > > be retrieved from n TAAs that are available and can be > > combined to validate the signatures on the transaction as > > well as the time stamp. > > > > The approach also offers some redundancy in case some TAAs > > are not available, data is corrupted, or the challenger does > > not trust some of the TAAs. > > > > Santosh Chokhani > > Orion Security Solutions, Inc. > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (703) 917-0060 Ext. 35 (voice) > > (703) 917-0260 (Fax) > > chokhani@orionsec.com > > Visit our Web site > > http://www.orionsec.com > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Hjh6w013691; Thu, 1 Apr 2004 09:45: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 i31HjhxB013670; Thu, 1 Apr 2004 09:45: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.11/8.12.8) with ESMTP id i31Hje6a013625 for ; Thu, 1 Apr 2004 09:45:40 -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 i31HjZ6Q011625; Thu, 1 Apr 2004 19:45:36 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 19:45:36 +0200 Message-ID: <077097E85A6BD3119E910800062786A9094D548A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 19:47:30 +0200 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 i31Hjf6a013652 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh, It's a bit hard for me to understand all the benefits from the n-of-m-split and why to use it. If you don't mind I try to bring up what I took from the discussion so far and you correct my misunderstanding: 1. n-of-m-split is not instead of ERS data structures - it is in addition ? (what I take from your mail to Antje) 2. n-of-m-split shall provide the security that the data is unchanged based on the idea that it is not possible to tamper all the TAA where the data is stored - or at least not the majority ? 3. n-of-m split has in mind some kind of High availablity and redundancy (like RAID systems ?) using a highly distributed infrastructure - some kind of P2P network ??? Some thought about that from my point of view: >From the business perspective I clearly doubt that any company - and probably not even a private person - would love to risk it's documents on an infrastructure not fully under it's control or that not at least can't be held fully reliable for the storage of the document. Of course within companies and institutions the distribution and redundancy of data is clearly wanted and today already done (e.g. RAID systems etc.) - so the risk to loose a document is something that the solutions already available today can handle quite good. (just talk with some storage vendors - like I had to do during the last months - and you will find that they are doing quite a good job at that.) Probably I missed something important, so please help me a little bit to understand. Tobias Chair of LTANS > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Thursday, April 01, 2004 17:47 > To: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > Ulrich: > > To solve the problem, if the person who feels that the > evidence may be needed (e.g., the client) can obtain a time > stamp, get all appropriate trust anchors, certificates, > revocation information attached, split n of m and submit to > the archives. Then, when the evidence needs to > reconstructed, n TAAs can supply their shares to construct > the original with all the signatures and time stamps. > > Why would that not be simple or meet the German Law? > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Ulrich Pordesch > Sent: Thursday, April 01, 2004 9:29 AM > To: ietf-ltans@imc.org > Subject: AW: Alternatives for Long Term Archiving > > > > Santosh: > > Getting a proof of existence of data at a certain time in the > past using (sequences/ chains of) time-stamps is an essential > part of the service and the reason, why we required this as > "must requirement" in requirements draft. Getting trust > relating to time- of existance by statements of a new kind of > trusted authorities (TAAs) is a completly other kind of > trust. This solution is not sufficient to conserve value of > evidence of signed documents in court, because there is no > law (in germany but also anywhere else, as I know), which > recognizes trusted archives like regulated/trusted time-stamp > authorities. I think we will never get such law, because > complex archive systems can not be evaluated to the same > degree as simple time-stamping-machines. Statements of TAAs, > provided by protocol, may be an additional useful features, > if there are users who need it. > > > Ulrich > > > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im > Auftrag von Santosh Chokhani > Gesendet: Donnerstag, 1. April 2004 15:32 > An: ietf-ltans@imc.org > Betreff: RE: Alternatives for Long Term Archiving > > > > Brian: > > I do not think trusted archive requires providing date and > time service. > > If the trusted archive requirement is to attest to the date > of any document, then each TAA may put a date time stamp or > get date-time stamp from an authority and add proper trust > anchors, certificates and revocation information. > > n of m only helps with integrity, availability, and provides > protection against perceived collusion threat. > > -----Original Message----- > From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] > Sent: Wednesday, March 31, 2004 6:41 AM > To: Larry Masinter > Cc: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: Re: Alternatives for Long Term Archiving > > > Larry or Santosh, > > Could someone tell me how the n of m scheme replaces the need of an > (accredited) time-stamping or time-marking service, when the date of > document existance must be proved? Is it assumed that each > TAA simply > states (and signs) when the document existed and when n TAAs > state the > same date, this date is correct and trustworthy? > > Regards, > Brian > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Fksif004166; Thu, 1 Apr 2004 07:46: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 i31FksTr004165; Thu, 1 Apr 2004 07:46:54 -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 i31Fkr1M004158 for ; Thu, 1 Apr 2004 07:46:54 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31FkuAt029922 for ; Thu, 1 Apr 2004 10:46:56 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:46:56 -0500 Message-ID: <000201c41800$8fdcb7d0$9a00a8c0@hq.orionsec.com> 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.4510 In-reply-to: <007401c417f5$b1bf7f00$02210c8d@PCHOTZENPLOTZ> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31Fks1M004160 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ulrich: To solve the problem, if the person who feels that the evidence may be needed (e.g., the client) can obtain a time stamp, get all appropriate trust anchors, certificates, revocation information attached, split n of m and submit to the archives. Then, when the evidence needs to reconstructed, n TAAs can supply their shares to construct the original with all the signatures and time stamps. Why would that not be simple or meet the German Law? -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Ulrich Pordesch Sent: Thursday, April 01, 2004 9:29 AM To: ietf-ltans@imc.org Subject: AW: Alternatives for Long Term Archiving Santosh: Getting a proof of existence of data at a certain time in the past using (sequences/ chains of) time-stamps is an essential part of the service and the reason, why we required this as "must requirement" in requirements draft. Getting trust relating to time- of existance by statements of a new kind of trusted authorities (TAAs) is a completly other kind of trust. This solution is not sufficient to conserve value of evidence of signed documents in court, because there is no law (in germany but also anywhere else, as I know), which recognizes trusted archives like regulated/trusted time-stamp authorities. I think we will never get such law, because complex archive systems can not be evaluated to the same degree as simple time-stamping-machines. Statements of TAAs, provided by protocol, may be an additional useful features, if there are users who need it. Ulrich -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Santosh Chokhani Gesendet: Donnerstag, 1. April 2004 15:32 An: ietf-ltans@imc.org Betreff: RE: Alternatives for Long Term Archiving Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31ESwuN098278; Thu, 1 Apr 2004 06:28:58 -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 i31ESwnp098277; Thu, 1 Apr 2004 06:28:58 -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 i31ESuip098257 for ; Thu, 1 Apr 2004 06:28:57 -0800 (PST) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCHOTZENPLOTZ (pc-hotzenplotz [141.12.33.2]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id QAA05438 for ; Thu, 1 Apr 2004 16:28:47 +0200 (MET DST) From: "Ulrich Pordesch" To: Subject: AW: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 16:29:08 +0200 Organization: Fraunhofer, SIT Message-ID: <007401c417f5$b1bf7f00$02210c8d@PCHOTZENPLOTZ> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: Normal In-Reply-To: <003e01c417ed$b7e2ab30$9a00a8c0@hq.orionsec.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31ESvip098272 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh: Getting a proof of existence of data at a certain time in the past using (sequences/ chains of) time-stamps is an essential part of the service and the reason, why we required this as "must requirement" in requirements draft. Getting trust relating to time- of existance by statements of a new kind of trusted authorities (TAAs) is a completly other kind of trust. This solution is not sufficient to conserve value of evidence of signed documents in court, because there is no law (in germany but also anywhere else, as I know), which recognizes trusted archives like regulated/trusted time-stamp authorities. I think we will never get such law, because complex archive systems can not be evaluated to the same degree as simple time-stamping-machines. Statements of TAAs, provided by protocol, may be an additional useful features, if there are users who need it. Ulrich -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Santosh Chokhani Gesendet: Donnerstag, 1. April 2004 15:32 An: ietf-ltans@imc.org Betreff: RE: Alternatives for Long Term Archiving Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31DaDNw093877; Thu, 1 Apr 2004 05:36:13 -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 i31DaDTv093876; Thu, 1 Apr 2004 05:36:13 -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 i31DaDNk093869 for ; Thu, 1 Apr 2004 05:36:13 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31DaEAt010580 for ; Thu, 1 Apr 2004 08:36:15 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 08:36:14 -0500 Message-ID: <003f01c417ee$4df8e8f0$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: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31DaDNk093871 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Antje Hollerbach: See responses in-line in []. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Hollerbach, Antje Sent: Thursday, April 01, 2004 3:05 AM To: chokhani@orionsec.com Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving I think that the use of different archive facilities is unrealistic for organisations like e.g. hospitals, because the costs are unreasonable, it is very complex and not practicable. Real users, such as our university hospital, which source out their archival system, want to keep their costs as low as possible. Furthermore, redistribution makes little sense for organisations that don't outsource. We need as soon as possible solutions, which can be used for the renewal of signatures and for the proof of the archiving time. Furthermore simple protocols for archiving services would be expedient. The previous documents of LTANS suit this purpose but not the thoughts in your mail below! [The n of m scheme is being vetted through the process. Your example shows that there is a need for a single TAA that relies on computer security and possibly refreshing time stamp means. If we were to include n of m scheme in the standards also, it will be in addition to the ERS approach, not instead of]. A. Hollerbach Center for Information Management (ZIM), University Hospital of Heidelberg -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, March 24, 2004 7:37 PM To: ietf-ltans@imc.org Subject: Alternatives for Long Term Archiving One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) is to use a key-less approach to trusted archive. The client who has vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n must be greater than 1, less than or equal to m, and should be selected based on the desired degree of protection against collusion. If this scheme is used, we may not need any cryptographic operations at the TAA. Under this scheme, the LTANS WG would need to still define various protocol for submission, deletion, and retrieval. if the idea is acceptable to the group, it could be the preferred or one of the approaches to perform archiving. As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. One advantage of the approach is that any document split is not sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. To further illustrate one usage of the approach, a client with the need to provide long-term, non-repudiation of a transaction, could obtain current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. When there is a need to retrieve the evidence, n splits could be retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of the TAAs. Santosh Chokhani Orion Security Solutions, Inc. 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (703) 917-0060 Ext. 35 (voice) (703) 917-0260 (Fax) chokhani@orionsec.com Visit our Web site http://www.orionsec.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31DW2Qe093577; Thu, 1 Apr 2004 05:32: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 i31DW2dd093576; Thu, 1 Apr 2004 05:32: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 i31DW1Pg093570 for ; Thu, 1 Apr 2004 05:32:01 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i31DW3At010122 for ; Thu, 1 Apr 2004 08:32:03 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 08:32:03 -0500 Message-ID: <003e01c417ed$b7e2ab30$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: <406AAE4A.8060800@sit.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i31DW2Pg093571 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: I do not think trusted archive requires providing date and time service. If the trusted archive requirement is to attest to the date of any document, then each TAA may put a date time stamp or get date-time stamp from an authority and add proper trust anchors, certificates and revocation information. n of m only helps with integrity, availability, and provides protection against perceived collusion threat. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Wednesday, March 31, 2004 6:41 AM To: Larry Masinter Cc: ietf-ltans@imc.org; chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i319FX7A052806; Thu, 1 Apr 2004 01:15:33 -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 i319FXOQ052805; Thu, 1 Apr 2004 01:15:33 -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 i319FWqI052767 for ; Thu, 1 Apr 2004 01:15:33 -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 LAA00436; Thu, 1 Apr 2004 11:15:28 +0200 (MET DST) Message-ID: <406BDE1E.3040401@sit.fraunhofer.de> Date: Thu, 01 Apr 2004 11:17:18 +0200 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: Libor.Dostalek@pvt.cz CC: ietf-ltans@imc.org Subject: Re: Our objections to draft ERS References: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor, Thanks for your comments on the draft. Please find my comments below. Libor.Dostalek@pvt.cz wrote: >>From my point of view the complex impression of this draft is very >>good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is requested only > for the root hash of the hash-tree" for a long time. But after some > time, I consider it to be a good idea. If I think it over, the > publishing of the > root hash-tree in newspapers every week is interesting, but the > "classical" time stamp acc. to RFC-3161 can easily temporarily > replace it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term signatures will be > archived (RFC-3126). When archiving long-term signed document to the > TAA, the renew of particular digital signatures acc. to RFC-3126 will be > finished and the whole structure will be stored as data (as Archived > data object)? And after this, it will be renewed as the Archive Time > Stamp Chain? I would like this solution! This is related to your next question. In your example, the whole CMS object, as in RFC 3126, should be given to the TAA for archiving. > > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some examples, which > will make clear the meaning (for example in appendix). As Aleksej and Santosh said, the document and signature, along with certificates, crls, etc, should be archived, in order to provide non-repudiation of the document and signature in the future. > - Evidence record: this structure does not contain the identification > data of the archived document. How could you find such document in the > archive? One reason why no id is included, is that we do not want a connection between the evidence record and the actual provider, since it is not necessary for validating the record. As Aleksej said, this is a management issue, which can be handled by a doc id in the protocol or by meta data, to aid searching, as he earlier proposed. > - Archive Time-stamp, 3.1 Syntax: If I understand well: if the > reducedHashtree item misses, there is the time stamp from the document > instead of from the root-hash tree. If it is true, it should be > described here. You are correct, that is what is meant. I will make the text more explicit in this regards. > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with different > meaning in the RFC-3126. I would recommend to adjust the name slightly. If this name leads to confusion for developers, then we should discuss this. We initially used the term Enhanced Time-Stamp. Let's first wait for some new name suggestions, and we can then decide whether to leave the name or change it. All the suggestions below will be integrated. Brian > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal the ..." > Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not sufficient ..." > Change to "The simple Time-Stamp renewal is not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." change to "A > multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Ć = H (h(i_a)+ ha(i)) > h(i_b)Ć = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Ć", which various readers could view > in a different way. I would recommend to change it for some other ascii > character (e.g. for " ' "). > > > Libor & Marta > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i318j3dt042597; Thu, 1 Apr 2004 00:45:03 -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 i318j3Yi042595; Thu, 1 Apr 2004 00:45:03 -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 i318j2gB042542 for ; Thu, 1 Apr 2004 00:45:03 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 11250 invoked from network); 1 Apr 2004 08:44:55 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 1 Apr 2004 08:44:55 -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 10745-10 for ; Thu, 1 Apr 2004 10:44:55 +0200 (CEST) Received: (qmail 11242 invoked from network); 1 Apr 2004 08:44:55 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 1 Apr 2004 08:44:55 -0000 From: "A. Jerman Blazic" To: "'Hollerbach, Antje'" Cc: Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:44:54 +0200 Message-ID: <002401c417c5$9aa2c050$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: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.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: Dear Hollerbach, I've been silently waiting for an answer like yours. I must admit, that I unfortunately do not find the discussion going in direction of solving actual problems. From the position of developer, implementation and technical advisor it is hard to cope with current standards and proposes when facing the problem of conserving electronic records. Document bases are already full and usually in hands of single entity, which sees appropriate solution as a technology add-on for preservation of existing and future records. Re-distribution doesn't make much sense, rather single point of trust is what will IMHO evolve in the next years, the same scenario as deployed for digital signatures currently. End users are pressing really hard on us (technology providers) to come up with solution right this moment. And what is needed is to steer the initial LTANS course in the right direction and deliver critical missing pieces in the infrastructure as soon as possible. You may take some of your time and investigate what solutions do exist already on the market in the line with technical requirements, legislation and regulation and how they would solve your problems. The situation is not that bad... Regards A. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Hollerbach, Antje > Sent: Thursday, April 01, 2004 10:05 AM > To: chokhani@orionsec.com > Cc: ietf-ltans@imc.org > Subject: RE: Alternatives for Long Term Archiving > > > > > I think that the use of different archive facilities is > unrealistic for organisations like e.g. hospitals, because > the costs are unreasonable, it is very complex and not > practicable. Real users, such as our university hospital, > which source out their archival system, want to keep their > costs as low as possible. Furthermore, redistribution makes > little sense for organisations that don't outsource. We need > as soon as possible solutions, which can be used for the > renewal of signatures and for the proof of the archiving > time. Furthermore simple protocols for archiving services > would be expedient. The previous documents of LTANS suit > this purpose but not the thoughts in your mail below! > > A. Hollerbach > Center for Information Management (ZIM), University Hospital > of Heidelberg > > > > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: Wednesday, March 24, 2004 7:37 PM > To: ietf-ltans@imc.org > Subject: Alternatives for Long Term Archiving > > > One of the ideas that came out of Seoul meeting (thanks to Larry > Masinter) is to use a key-less approach to trusted archive. > The client who has vested interest in the secure storage of > archived data, can use Shamir's n of m scheme to submit the > archived data to m archive facilities. m must be greater > than 1 and should be selected based on availability needs. n > must be greater than 1, less than or equal to m, and should > be selected based on the desired degree of protection against > collusion. > > If this scheme is used, we may not need any cryptographic > operations at the TAA. > > Under this scheme, the LTANS WG would need to still define > various protocol for submission, deletion, and retrieval. if > the idea is acceptable to the group, it could be the > preferred or one of the approaches to perform archiving. > > As the current LTANS documents in the various stages state or > imply, the trusted archive can continue to be used to submit > any class of data. > > One advantage of the approach is that any document split is > not sensitive even if the original document is sensitive. > However, if the document requires confidentiality, assuming > an adversary could be monitoring the channels to collect all > the splits, the submission and retrieval of the split should > be provided transmission security using techniques such as > SSL or session encryption. This still is lot easier than > needing to provide long-term encryption for stored data. > > To further illustrate one usage of the approach, a client > with the need to provide long-term, non-repudiation of a > transaction, could obtain current time stamp, all the trust > anchor, certificates, revocation information relevant to > signatures and time stamp, and package them using TBD record > format and create m splits. These m split could be sent to m > TAAs using TLS. Each TLS could provide a pointer to its split. > > When there is a need to retrieve the evidence, n splits could > be retrieved from n TAAs that are available and can be > combined to validate the signatures on the transaction as > well as the time stamp. > > The approach also offers some redundancy in case some TAAs > are not available, data is corrupted, or the challenger does > not trust some of the TAAs. > > Santosh Chokhani > Orion Security Solutions, Inc. > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (703) 917-0060 Ext. 35 (voice) > (703) 917-0260 (Fax) > chokhani@orionsec.com > Visit our Web site > http://www.orionsec.com > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3184jxB027940; Thu, 1 Apr 2004 00:04: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 i3184j3k027938; Thu, 1 Apr 2004 00:04:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3184hsw027912 for ; Thu, 1 Apr 2004 00:04:44 -0800 (PST) (envelope-from Antje.Hollerbach@med.uni-heidelberg.de) Received: from msw.med.uni-heidelberg.de (mail.med.uni-heidelberg.de [129.206.90.21]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i3184fSe023572 for ; Thu, 1 Apr 2004 10:04:41 +0200 (MET DST) Received: from exc02.ads.krz.uni-heidelberg.de (unverified) by msw.med.uni-heidelberg.de (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Thu, 1 Apr 2004 10:04:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Alternatives for Long Term Archiving Date: Thu, 1 Apr 2004 10:04:40 +0200 Message-ID: <123BA0F81288BA44BB8011E378F8182F5A7A1C@mailhost.krz.uni-heidelberg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Alternatives for Long Term Archiving Thread-Index: AcQR1vwPWscwRQDjSCWl6xC7VKDuAAF5+qRAAAADG2A= From: "Hollerbach, Antje" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3184isw027932 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the use of different archive facilities is unrealistic for organisations like e.g. hospitals, because the costs are unreasonable, it is very complex and not practicable. Real users, such as our university hospital, which source out their archival system, want to keep their costs as low as possible. Furthermore, redistribution makes little sense for organisations that don't outsource. We need as soon as possible solutions, which can be used for the renewal of signatures and for the proof of the archiving time. Furthermore simple protocols for archiving services would be expedient. The previous documents of LTANS suit this purpose but not the thoughts in your mail below! A. Hollerbach Center for Information Management (ZIM), University Hospital of Heidelberg -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, March 24, 2004 7:37 PM To: ietf-ltans@imc.org Subject: Alternatives for Long Term Archiving One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) is to use a key-less approach to trusted archive. The client who has vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n must be greater than 1, less than or equal to m, and should be selected based on the desired degree of protection against collusion. If this scheme is used, we may not need any cryptographic operations at the TAA. Under this scheme, the LTANS WG would need to still define various protocol for submission, deletion, and retrieval. if the idea is acceptable to the group, it could be the preferred or one of the approaches to perform archiving. As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. One advantage of the approach is that any document split is not sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. To further illustrate one usage of the approach, a client with the need to provide long-term, non-repudiation of a transaction, could obtain current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. When there is a need to retrieve the evidence, n splits could be retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of the TAAs. Santosh Chokhani Orion Security Solutions, Inc. 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (703) 917-0060 Ext. 35 (voice) (703) 917-0260 (Fax) chokhani@orionsec.com Visit our Web site http://www.orionsec.com