From owner-ietf-ltans Wed Dec 17 13:11:35 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBZib096360 for ; Wed, 17 Dec 2003 13:11:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHLBZIt096359 for ietf-ltans-bks; Wed, 17 Dec 2003 13:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBYib096354 for ; Wed, 17 Dec 2003 13:11:34 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hBHLBV2L027493; Wed, 17 Dec 2003 16:11:31 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , Subject: RE: draft minutes Date: Wed, 17 Dec 2003 16:11:26 -0500 Message-ID: <000801c3c4e2$5877b900$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200311201448.hAKEmOn08990@chandon.edelweb.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBHLBZib096355 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Peter, Sorry the response is so delayed - some comments are inline below. > Agenda 1) : > > Stated that the group is concerned with signed data as opposed to > > unsigned, general purpose archive. > > What exactly is meant by 'signed data'. I think the purpose is to > > 'archive and/or notarize authentifiable representations of > information'. > > If signed data means that the data to be archived need to > have some characteristics that can be considered as an > equivalent of all aspects of what is called 'signature' for a > paper document, > then ok. I think the comment was simply distinguishing between archiving in the sense this group is considering and a backup solution. > The difference between archive and notoarize may be floating. > If the archive provider cares a little bit of the semnatics > of the document, for example when seome future conversion may > be planned, then this can be considered as the first step of > a notarisation operation; A real notarisation (depending on > which culture you think about) can just end here (public > notary) or continue to validate and assert the conformance to > some legal procedure (EU continent). > > Agenda 3) : > > Having siad the previous, I don't think that one should even > try to address > the long term validaty of digital signature chains by using > any cryptographic > approach that includes secrets. Digital signatures are for > strong authentication (IMHO) and not a sufficintly stable > means for long term. > It seems important to me that the underlying service model > assumes that there is at least one additional redundant > mechanism that can be used to prove the "existance" of some > data at:before a certain > time, e.g. physical protection with strong ordering of the > storage media. At what point would you deem verification of digital signatures not worthy of consideration? One of the comments in the minutes offered 7, 30 and 100 years as benchmarks. Would any of those qualify? Given that the accrual of signatures is due to timestamp refresh (in the specs that served as input to this group anyway), it may be sufficient to define archive structures that are timestamp format agnostic to accommodate non-signature-based timestamp solutions. There seems to be some general agreement regarding refreshed timestamps as a tool useful for archiving. The applicability of the linking hash approach to IETF work is not clear to me due to patent issues. > > "Complicated problem of establishing validity of a chain of > signatures > > over 100 years." > > Can someone give a paper equvalent example? The "Long Term Archive Architecture" gave a comic counterexample. In any case, whether or not a chain of digital signatures would ever be verified to prove the validity of a signature that is hundreds of years old or to make claims regarding the content of the associated data isn't necessarily relevant. It's just an extreme extension of the mechanisms that have been presented so far. From owner-ietf-ltans Thu Dec 18 14:18:27 2003 Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMIPib039986 for ; Thu, 18 Dec 2003 14:18:26 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Fri, 19 Dec 2003 01:24:08 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Fri, 19 Dec 2003 01:24:08 一人暮らしは寂しいね。彼氏もいないし… From owner-ietf-ltans Fri Dec 19 07:53:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJFrpib056087 for ; Fri, 19 Dec 2003 07:53:51 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBJFrp1m056086 for ietf-ltans-bks; Fri, 19 Dec 2003 07:53:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJFrnib056081 for ; Fri, 19 Dec 2003 07:53:50 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA09394; Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hBJFrmY15369; Fri, 19 Dec 2003 16:53:48 +0100 (MET) Date: Fri, 19 Dec 2003 16:53:48 +0100 (MET) From: Peter Sylvester Message-Id: <200312191553.hBJFrmY15369@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, cwallace@orionsec.com Subject: Re: draft minutes Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Did you intend to respond offlist? If not, feel free to forward my response > to the list. Comments below... A bug in my mail reader's reply function, it didn't detect the list. Thanks, Sun. > > > I think the comment was simply distinguishing between archiving in the > sense > > > this group is considering and a backup solution. > > > > The distinction seems not not to explain to me, technically the > > difference may be very small. > > Yes, the difference may be very small. I was only giving my interpretation > of what Russ said during the introduction. I never considered unsigned data > as beyond out concern. ok. > > > "not worthy of consideration" is not exactly what I had in mind. "Not > being > > able anymore by definition". the cryptographic validation of a signature > > aginst a certificate as the ONLY means to validate it can only be done > > rather shortly after the signature. > > I took your point to be that we should define a solution that does not use > any cryptographic mechanism that relies on secrets and agree completely. I > don't agree (at least not yet) that secret based, e.g. signature, mechanisms > can not be part of the solution. Ok. > > Just an example: > > SMIME contains a linking of hashes, i.e. > sign(hash(hash(data),attributes)), > > and if you consider that the data can be a hash+time, then there is > > even an additional indirection. > > I don't think that so far, any of the hash linking patent holders has > > tried to challenge this, or at least they lost as far as I remember. > > OK. .. > > > I know only one (other?) person convinced, and trying to convince that > > refreshed time stamps are *THE* tool. The difference is whether it > > is one of possible security measures, or whether this is consider > > as a 100% secure measure and no others are necessary since no redunancy > > problem exist. > > I've not heard anyone assert that refreshed timestamps are *THE* tool, in > the sense that they are sufficient alone to provide the solution. I have > heard folks who favor procedural controls over such mechanisms entirely. In > any case, there are multiple references, in IETF alone, asserting refreshed > timestamps as *A* tool. A slippery road. I tend to be careful to say anything abut the validity of 30 or 100 years, except that microfilm and paper have known qualities. > > It doesn't seem very important to make a decision about whether > > this or that mechanism is the right one, it would even be a disaster > > since it seems desirable to able to change/add new technologies, > > in order to avoid surprises like with "all you need is to > > make magnetic tapes" or else. > > It is important that we make decisions regarding mechanisms (and > procedures/processes/etc?) if we intend to produce standards in this area. I used bad wording. The decision cn be about a currently selection of techniques and a framework allowing enhancements that won't make previous techniques obsolete and may allow even migration. > > > 100 years later or, what counts > > is the statement of the archiver/notariser telling whether a document > > is valid. In general, you don't challenge the notary if it follows a > > correct procedure etc.; it is in our interest to define architectures > > and principles that have security characteristics similar to existing > > paper techniques. > > It is also in our interest to define evidence to support claims by > archivers/notaries. Yes. I think that we are sufficiently in phase now. I wonder whether the people who are mentioned in the minutes could repeat or explain their comments (if they are subscribed to the list). My capacity of listening distant conversations or telepathy are somewhat limited. :-) regards From owner-ietf-ltans Sat Dec 20 07:35:52 2003 Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBKFZoib094348 for ; Sat, 20 Dec 2003 07:35:51 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Sun, 21 Dec 2003 00:35:41 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Sun, 21 Dec 2003 00:35:41 一人暮らしは寂しいね。彼氏もいないし… From owner-ietf-ltans Wed Dec 24 15:34:30 2003 Received: from 203.141.35.113 (OFSfb-01p3-43.ppp11.odn.ad.jp [211.131.156.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBONYNib028185 for ; Wed, 24 Dec 2003 15:34:30 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Thu, 25 Dec 2003 08:34:22 Subject: =?ISO-2022-JP?B?GyRCMj8kLDklJC0kSiROISkbKEI=?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: <5hf52mdyvmncgrz.251220030834@203.141.35.113> Date: Thu, 25 Dec 2003 08:34:22 いいよ☆なんでも作ってあげるよ　今度会うときまでに決めておいてね(^_^)v From owner-ietf-ltans Tue Dec 30 04:34:07 2003 Received: from 203.141.35.113 (142.232.109.219.ap.yournet.ne.jp [219.109.232.142]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUCY5ib058730 for ; Tue, 30 Dec 2003 04:34:06 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Tue, 30 Dec 2003 21:03:49 Subject: =?ISO-2022-JP?B?GyRCJEQkXiRzJEokJCRoJCkbKEI=?=(T_T)/~~~ From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Tue, 30 Dec 2003 21:03:49 かなり暇してるのぉ。メィルちょ。 Received: from 203.141.35.113 (142.232.109.219.ap.yournet.ne.jp [219.109.232.142]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUCY5ib058730 for ; Tue, 30 Dec 2003 04:34:06 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Tue, 30 Dec 2003 21:03:49 Subject: =?ISO-2022-JP?B?GyRCJEQkXiRzJEokJCRoJCkbKEI=?=(T_T)/~~~ From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Tue, 30 Dec 2003 21:03:49 かなり暇してるのぉ。メィルちょ。 Received: from 203.141.35.113 (OFSfb-01p3-43.ppp11.odn.ad.jp [211.131.156.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBONYNib028185 for ; Wed, 24 Dec 2003 15:34:30 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Thu, 25 Dec 2003 08:34:22 Subject: =?ISO-2022-JP?B?GyRCMj8kLDklJC0kSiROISkbKEI=?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: <5hf52mdyvmncgrz.251220030834@203.141.35.113> Date: Thu, 25 Dec 2003 08:34:22 いいよ☆なんでも作ってあげるよ　今度会うときまでに決めておいてね(^_^)v Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBKFZoib094348 for ; Sat, 20 Dec 2003 07:35:51 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Sun, 21 Dec 2003 00:35:41 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Sun, 21 Dec 2003 00:35:41 一人暮らしは寂しいね。彼氏もいないし… Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJFrpib056087 for ; Fri, 19 Dec 2003 07:53:51 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBJFrp1m056086 for ietf-ltans-bks; Fri, 19 Dec 2003 07:53:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJFrnib056081 for ; Fri, 19 Dec 2003 07:53:50 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA09394; Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Fri, 19 Dec 2003 16:53:49 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hBJFrmY15369; Fri, 19 Dec 2003 16:53:48 +0100 (MET) Date: Fri, 19 Dec 2003 16:53:48 +0100 (MET) From: Peter Sylvester Message-Id: <200312191553.hBJFrmY15369@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, cwallace@orionsec.com Subject: Re: draft minutes Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Did you intend to respond offlist? If not, feel free to forward my response > to the list. Comments below... A bug in my mail reader's reply function, it didn't detect the list. Thanks, Sun. > > > I think the comment was simply distinguishing between archiving in the > sense > > > this group is considering and a backup solution. > > > > The distinction seems not not to explain to me, technically the > > difference may be very small. > > Yes, the difference may be very small. I was only giving my interpretation > of what Russ said during the introduction. I never considered unsigned data > as beyond out concern. ok. > > > "not worthy of consideration" is not exactly what I had in mind. "Not > being > > able anymore by definition". the cryptographic validation of a signature > > aginst a certificate as the ONLY means to validate it can only be done > > rather shortly after the signature. > > I took your point to be that we should define a solution that does not use > any cryptographic mechanism that relies on secrets and agree completely. I > don't agree (at least not yet) that secret based, e.g. signature, mechanisms > can not be part of the solution. Ok. > > Just an example: > > SMIME contains a linking of hashes, i.e. > sign(hash(hash(data),attributes)), > > and if you consider that the data can be a hash+time, then there is > > even an additional indirection. > > I don't think that so far, any of the hash linking patent holders has > > tried to challenge this, or at least they lost as far as I remember. > > OK. .. > > > I know only one (other?) person convinced, and trying to convince that > > refreshed time stamps are *THE* tool. The difference is whether it > > is one of possible security measures, or whether this is consider > > as a 100% secure measure and no others are necessary since no redunancy > > problem exist. > > I've not heard anyone assert that refreshed timestamps are *THE* tool, in > the sense that they are sufficient alone to provide the solution. I have > heard folks who favor procedural controls over such mechanisms entirely. In > any case, there are multiple references, in IETF alone, asserting refreshed > timestamps as *A* tool. A slippery road. I tend to be careful to say anything abut the validity of 30 or 100 years, except that microfilm and paper have known qualities. > > It doesn't seem very important to make a decision about whether > > this or that mechanism is the right one, it would even be a disaster > > since it seems desirable to able to change/add new technologies, > > in order to avoid surprises like with "all you need is to > > make magnetic tapes" or else. > > It is important that we make decisions regarding mechanisms (and > procedures/processes/etc?) if we intend to produce standards in this area. I used bad wording. The decision cn be about a currently selection of techniques and a framework allowing enhancements that won't make previous techniques obsolete and may allow even migration. > > > 100 years later or, what counts > > is the statement of the archiver/notariser telling whether a document > > is valid. In general, you don't challenge the notary if it follows a > > correct procedure etc.; it is in our interest to define architectures > > and principles that have security characteristics similar to existing > > paper techniques. > > It is also in our interest to define evidence to support claims by > archivers/notaries. Yes. I think that we are sufficiently in phase now. I wonder whether the people who are mentioned in the minutes could repeat or explain their comments (if they are subscribed to the list). My capacity of listening distant conversations or telepathy are somewhat limited. :-) regards Received: from 203.141.35.113 (39.47.44.61.ap.yournet.ne.jp [61.44.47.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMIPib039986 for ; Thu, 18 Dec 2003 14:18:26 -0800 (PST) (envelope-from petits_nya_milky_nya@yahoo.co.jp) Received: from [127.0.0.1] by MS18 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.0)); Fri, 19 Dec 2003 01:24:08 Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?= From: petits_nya_milky_nya@yahoo.co.jp To: ietf-ltans-bks@above.proper.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Mail Distributer Reply-To: petits_nya_milky_nya@yahoo.co.jp Message-ID: Date: Fri, 19 Dec 2003 01:24:08 一人暮らしは寂しいね。彼氏もいないし… Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBZib096360 for ; Wed, 17 Dec 2003 13:11:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHLBZIt096359 for ietf-ltans-bks; Wed, 17 Dec 2003 13:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHLBYib096354 for ; Wed, 17 Dec 2003 13:11:34 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hBHLBV2L027493; Wed, 17 Dec 2003 16:11:31 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , Subject: RE: draft minutes Date: Wed, 17 Dec 2003 16:11:26 -0500 Message-ID: <000801c3c4e2$5877b900$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200311201448.hAKEmOn08990@chandon.edelweb.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBHLBZib096355 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Peter, Sorry the response is so delayed - some comments are inline below. > Agenda 1) : > > Stated that the group is concerned with signed data as opposed to > > unsigned, general purpose archive. > > What exactly is meant by 'signed data'. I think the purpose is to > > 'archive and/or notarize authentifiable representations of > information'. > > If signed data means that the data to be archived need to > have some characteristics that can be considered as an > equivalent of all aspects of what is called 'signature' for a > paper document, > then ok. I think the comment was simply distinguishing between archiving in the sense this group is considering and a backup solution. > The difference between archive and notoarize may be floating. > If the archive provider cares a little bit of the semnatics > of the document, for example when seome future conversion may > be planned, then this can be considered as the first step of > a notarisation operation; A real notarisation (depending on > which culture you think about) can just end here (public > notary) or continue to validate and assert the conformance to > some legal procedure (EU continent). > > Agenda 3) : > > Having siad the previous, I don't think that one should even > try to address > the long term validaty of digital signature chains by using > any cryptographic > approach that includes secrets. Digital signatures are for > strong authentication (IMHO) and not a sufficintly stable > means for long term. > It seems important to me that the underlying service model > assumes that there is at least one additional redundant > mechanism that can be used to prove the "existance" of some > data at:before a certain > time, e.g. physical protection with strong ordering of the > storage media. At what point would you deem verification of digital signatures not worthy of consideration? One of the comments in the minutes offered 7, 30 and 100 years as benchmarks. Would any of those qualify? Given that the accrual of signatures is due to timestamp refresh (in the specs that served as input to this group anyway), it may be sufficient to define archive structures that are timestamp format agnostic to accommodate non-signature-based timestamp solutions. There seems to be some general agreement regarding refreshed timestamps as a tool useful for archiving. The applicability of the linking hash approach to IETF work is not clear to me due to patent issues. > > "Complicated problem of establishing validity of a chain of > signatures > > over 100 years." > > Can someone give a paper equvalent example? The "Long Term Archive Architecture" gave a comic counterexample. In any case, whether or not a chain of digital signatures would ever be verified to prove the validity of a signature that is hundreds of years old or to make claims regarding the content of the associated data isn't necessarily relevant. It's just an extreme extension of the mechanisms that have been presented so far.