From owner-ietf-ltans Sat Nov 1 04:28:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSYkT008555 for ; Sat, 1 Nov 2003 04:28:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1CSYO5008554 for ietf-ltans-bks; Sat, 1 Nov 2003 04:28:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSWkT008548 for ; Sat, 1 Nov 2003 04:28:33 -0800 (PST) (envelope-from Hannes.Tschofenig@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVF29118 for ; Sat, 1 Nov 2003 13:28:32 +0100 (MET) Received: from joe (lnxekv1-07.esn.sbs.de [149.246.36.7]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVs27566 for ; Sat, 1 Nov 2003 13:28:31 +0100 (MET) From: "Hannes Tschofenig" To: Subject: Date: Sat, 1 Nov 2003 13:27:43 +0100 Message-ID: <000001c3a073$8d72f3b0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: subscribe From owner-ietf-ltans Mon Nov 3 08:39:10 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3GdAkT040365 for ; Mon, 3 Nov 2003 08:39:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3GdApE040364 for ietf-ltans-bks; Mon, 3 Nov 2003 08:39:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3Gd8kT040357 for ; Mon, 3 Nov 2003 08:39:08 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA15265; Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Gd0U02088; Mon, 3 Nov 2003 17:39:00 +0100 (MET) Date: Mon, 3 Nov 2003 17:39:00 +0100 (MET) From: Peter Sylvester Message-Id: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> To: ulrich.pordesch@sit.fraunhofer.de, cwallace@orionsec.com, ralf_brandner@med.uni-heideberg.de Subject: draft-ietf-ltans-reqs-00.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here some comments: For the German collegues, I use a rather "French style" of writing The difference is essentially: Pb: a German and a French person talk about the first initial draft and the goal is that it is a starting point and one needs to continue. - The French would say: "This draft is a completely unacceptable way to solve the problem." ==> The German would stop working (believing that everything is bad). - The German would say: "This is already a good starting point." ==> The French would stop working 'believing that everything is ok). :-) So now, a bit of brain storming: > It is anticipated that a timestamp containing a digital signature > will be obtained for data submitted to a long-term archive service. > Thus, for all types of data, i.e. signed and unsigned, one or more > digital signatures will exist that require preservation by the long- > term archive service. I do not think that this phrase is good in the introduction, in particular the wording of 'time stamp containing a digital signature'. Why do 'signatures require preservation'? The data itself need it. > This document aims to identify the technical requirements for a long- > term archive service charged with preservation of digitally signed > data in an X.509 certificate-based PKI. I disagree with this definition, i.e. with the second part staring with 'charged with ...' > Operational requirements, such as storage media concerns, individual > legal requirements and questions dealing with accountability are not > addressed by this document. I disagree that questions concerning accountability are not addressed. At least clients should be probperly identifiable. There may be just wording problem 'accountability" vs "accounting and billing techniques". At least a requeirement must be: "The transaction data and protocols must allow to carry either directly or indirectly information that allow to associate each transaction to some accounting and billing meachnism, examples are identifiers for individual clients and/or large customers. Some raw requirements (oops, I saw that some of them are already in), soory I didn't read all while I was writing. - An archive service provider MUST NOT be able to insert data in a non chronological way, i.e., if some data are archived and time stamped, no data with a older time stamp can be inserted. - An archive service MUST NOt be able to delete data from the archive with detecting, or in other words, the service must be able to prove that nothing has been deleted. - An archive service MUST allow to transfer completely or partially, archived data to another services provider without loss of the global integrity property defined above. - An archive service MUST allow to delete completely or partially, archived data to another services provider without loss of the global integrity property defined above. (This can for example be accomplished by transfering data to a fictious "archiver"). Deleting may becontrolled by a policy, but needs exceptions. I think the previous can be deduced from several of the existing text, in particular, about evidence for groups etc. - The archive service MUST be able to provide evidence about the policies that have been used at any time. - The format for the evidence/acknowledgements MUST allow to identify the archiving provider. - The format for the evidence/acknowledgements MUST allow (at least the creating the archiving provider) to identify the participating client. - A client or other relying parties MUST be able to prove that a particular acknowledgement (attestation) belongs to a request may by the client. I an simple case, a gloabl identifier of the client is used, for example. - It MUST be possible to include metadata concerning the data, for example a mime type, a short description in clear in the acknowlegments (attestations). - A broker style service provider should be able to relay requests to back end service providers. - A provider should be able to provide the service in a staged way, i.e. provide initial acknowledgements for by final ones. This is important in order to avoid a simgle point of failure. - A client may obtain final acknoledgements either by an asynch method, e.g. mail, or by a polling technique (maybe combined with a notification), cf. SAML - An acknowledgement/attestion is a verifyable statement from the archive provider confirming the acceptance and (maybe partial) fulfillment of the requested action. Short term verifiability needs to be ensured for the requesting client but also for other relying parties (e.g. signature shared secret authentication, ...) Long term authenticity can be ensured by a particular service. Comment about: - The protocol MUST define interactions with a Long-term Archive Service including, at a minimum: submission of data or groups of data for preservation, retrieval of archive packages and deletion of archived data and associated evidence records. I think the protocol should allow the validation of a acknowledge. Or, this would be a "confirm existence" vs "retrieval" of archive packages. - The protocol must allow that a "confirm existance" may return a reference of another archive provider. Chapter 3: - The model should allow for relays. - If I understand it right, the TSA is used as a security mechanism by the TAA. I think one should not restrict this and open this to other mechanisms, e.g. an service provider can use another backend archive, can archive just all its transaction logs (or acknowledgements), - The text makes a lot of assumption about timestamps, in particular that a time stamp has a signature. I think one should weaken this. time stamping using hash linking is a technique that allows independance of secrets, and also, as a side effect, links all time stamps together, thus, is a good mesure to protect against undetected loss of archived data, or against false inclusions etc. to resumee: Good start :-) Regards Peter From owner-ietf-ltans Mon Nov 3 09:56:42 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HugkT043858 for ; Mon, 3 Nov 2003 09:56:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3HugK6043857 for ietf-ltans-bks; Mon, 3 Nov 2003 09:56:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HuekT043850 for ; Mon, 3 Nov 2003 09:56:41 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA15871 for ; Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Hudg02285 for ietf-ltans@imc.org; Mon, 3 Nov 2003 18:56:39 +0100 (MET) Date: Mon, 3 Nov 2003 18:56:39 +0100 (MET) From: Peter Sylvester Message-Id: <200311031756.hA3Hudg02285@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: long term Archive Architecture X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I have received a docuiment from two colleagues Libor and Marta in the Czech republic. So far, awaiting some comment from the chairmen, I have put the document in the ltans web server into the "related documents" section. --- forwarded message : From: "Marta.Vohnoutova@pvt.cz" Date: Mon, 3 Nov 2003 18:13:15 +0100 Dear Peter, I am very glad that I can send you the Long-term archiving - draft proposal which we (Libor Dostalek and Marta Vohnoutova) have made. You can see that we worked hard to help our ietf-ltans-arch group to progress. We put there our experiences with the "special world" of real archivists who will unavoidably talk to the long-term archiving project. This is a draft proposal and we expect and we would be very glad if other authors thing over our material. But we think it could be a very good starting point. Please bo so kind - read the attached material throroughly, put it on your web site and announce to the conference participants that new draft proposal exists. Looking forward to any comments Best regards Cordially Libor and Marta P.S. Because of necessary pictures we transformed the file into the PDF form (because of the rastr - the best view is if the scale is 100%. From owner-ietf-ltans Wed Nov 5 06:13:44 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDikT081544 for ; Wed, 5 Nov 2003 06:13:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5EDiDL081543 for ietf-ltans-bks; Wed, 5 Nov 2003 06:13:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDgkT081534 for ; Wed, 5 Nov 2003 06:13:43 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-138-88-47-253.res.east.verizon.net [138.88.47.253]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA5EDZKJ018447; Wed, 5 Nov 2003 09:13:35 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , , Cc: Subject: RE: draft-ietf-ltans-reqs-00.txt Date: Wed, 5 Nov 2003 09:13:36 -0500 Message-ID: <000301c3a3a7$01496900$6501a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5EDhkT081535 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the comments and additional requirements. A few comments are inline below... > I do not think that this phrase is good in the introduction, > in particular the wording of 'time stamp containing a digital > signature'. Why do 'signatures require preservation'? The > data itself need it. I agree the wording is a little awkward and in general the draft may be overly prescriptive w.r.t. to timestamps as a mechanism, though this is based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there will always be one or more digital signatures present is based on assumptions that data submitted to an archive will be timestamped and that timestamps include a signature. Signatures require preservation due to the decreasing value of the objects used to verify the signature, etc., etc. > I disagree with this definition, i.e. with the second part > staring with 'charged with ...' OK. We can strike the reference to the environment and leave that to the mechanism specs. > - An archive service provider MUST NOT be able to insert data in a > non chronological way, i.e., if some data are archived and > time stamped, > no data with a older time stamp can be inserted. I not sure I agree with this. If I have a document with timestamp 1 and you have a document with timestamp 2, I shouldn't be prevented from archiving my document because you submitted your doc first. If you mean that the archive itself must never apply a timestamp older than a previously applied timestamp, then I agree. > - An archive service MUST NOt be able to delete data from the > archive with > detecting, or in other words, the service must be able to prove that > nothing has been deleted. > > - An archive service MUST allow to transfer completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. > > - An archive service MUST allow to delete completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. (This can for example > be accomplished by transfering data to a fictious "archiver"). > Deleting may becontrolled by a policy, but needs exceptions. Perhaps we need a section addressing operational requirements. > - A provider should be able to provide the service in a staged way, > i.e. provide initial acknowledgements for by final ones. This is > important in order to avoid a simgle point of failure. This may also be important if there is to be support for a grace period to accommodate compromise declaration after submission. > - If I understand it right, the TSA is used as a security > mechanism by the TAA. I think one should not restrict this > and open this to other mechanisms, e.g. an service > provider can use another backend archive, can archive just > all its transaction logs (or acknowledgements), In this case the TAA is acting as a client to another TAA. There's nothing in the draft to restrict this type of interaction. > - The text makes a lot of assumption about > timestamps, in particular that a time stamp has a signature. I think > one should weaken this. time stamping using hash linking is > a technique > that allows independance of secrets, and also, as a side effect, > links all time stamps together, thus, is a good mesure to protect > against undetected loss of archived data, or against false > inclusions etc. Are there any timestamp formats that should be considered that don't feature digital signatures? RFC3161 and ATS both feature signatures. From owner-ietf-ltans Wed Nov 5 07:40:25 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeOkT085262 for ; Wed, 5 Nov 2003 07:40:24 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FeO8X085261 for ietf-ltans-bks; Wed, 5 Nov 2003 07:40:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeMkT085252 for ; Wed, 5 Nov 2003 07:40:23 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA29551 for ; Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA5FeHj06929 for ietf-ltans@imc.org; Wed, 5 Nov 2003 16:40:17 +0100 (MET) Date: Wed, 5 Nov 2003 16:40:17 +0100 (MET) From: Peter Sylvester Message-Id: <200311051540.hA5FeHj06929@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: draft-ietf-ltans-reqs-00.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > I do not think that this phrase is good in the introduction, > > in particular the wording of 'time stamp containing a digital > > signature'. Why do 'signatures require preservation'? The > > data itself need it. > > I agree the wording is a little awkward and in general the draft may be > overly prescriptive w.r.t. to timestamps as a mechanism, though this is > based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there > will always be one or more digital signatures present is based on > assumptions that data submitted to an archive will be timestamped and that > timestamps include a signature. Signatures require preservation due to the > decreasing value of the objects used to verify the signature, etc., etc. I think we are able to find a wording which is sufficiently neutral. > > > I disagree with this definition, i.e. with the second part > > staring with 'charged with ...' > > OK. We can strike the reference to the environment and leave that to the > mechanism specs. Ok. > > > > > - An archive service provider MUST NOT be able to insert data in a > > non chronological way, i.e., if some data are archived and > > time stamped, > > no data with a older time stamp can be inserted. > > I not sure I agree with this. If I have a document with timestamp 1 and you > have a document with timestamp 2, I shouldn't be prevented from archiving my > document because you submitted your doc first. If you mean that the archive > itself must never apply a timestamp older than a previously applied > timestamp, then I agree. the usage of the overloaded word time stamp (as you mention, the client data may already have one in some way, and the server may add another) is perhaps a problem. Indeed I mean basically the second thing. In fact, I am not sure whether strict linear order is required in the global sense, if you have trees of hashes. indeed, a client may have obtained some time stamp or "file seal" much earlier in order to have a proof of the existance, and this is not related to the time of archiving. > > > - An archive service MUST NOt be able to delete data from the > > archive with > > detecting, or in other words, the service must be able to prove that > > nothing has been deleted. > > > > - An archive service MUST allow to transfer completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. > > > > - An archive service MUST allow to delete completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. (This can for example > > be accomplished by transfering data to a fictious "archiver"). > > Deleting may becontrolled by a policy, but needs exceptions. > > Perhaps we need a section addressing operational requirements. I think input from some real archiving providers may be helpful. > > > > - A provider should be able to provide the service in a staged way, > > i.e. provide initial acknowledgements for by final ones. This is > > important in order to avoid a simgle point of failure. > > This may also be important if there is to be support for a grace period to > accommodate compromise declaration after submission. Yes. > > > > > - If I understand it right, the TSA is used as a security > > mechanism by the TAA. I think one should not restrict this > > and open this to other mechanisms, e.g. an service > > provider can use another backend archive, can archive just > > all its transaction logs (or acknowledgements), > > In this case the TAA is acting as a client to another TAA. There's nothing > in the draft to restrict this type of interaction. Right > > - The text makes a lot of assumption about > > timestamps, in particular that a time stamp has a signature. I think > > one should weaken this. time stamping using hash linking is > > a technique > > that allows independance of secrets, and also, as a side effect, > > links all time stamps together, thus, is a good mesure to protect > > against undetected loss of archived data, or against false > > inclusions etc. > > Are there any timestamp formats that should be considered that don't feature > digital signatures? RFC3161 and ATS both feature signatures. Yes. At least in a second step: A client only needs a strong authentication method to validate a server when the time stamp is obtained. This is in general done by a signature. If you use hash linking, and if you publish in regular intervals the last hash, a client can ask for an extended time stamp which includes a hash chain up to the published one. This extended time stamp no longer depends on the security of keys, only on the hash function. See: http://ltans.edelweb.fr/Cybernetica-OpenEvidence-TimeStamping.pdf or at the http://www.cyber.ee Peter ----- End Included Message ----- From owner-ietf-ltans Thu Nov 20 06:48:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmYkT034255 for ; Thu, 20 Nov 2003 06:48:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKEmYfo034254 for ietf-ltans-bks; Thu, 20 Nov 2003 06:48:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmTkT034244 for ; Thu, 20 Nov 2003 06:48:32 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA05195 for ; Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hAKEmOn08990 for ietf-ltans@imc.org; Thu, 20 Nov 2003 15:48:24 +0100 (MET) Date: Thu, 20 Nov 2003 15:48:24 +0100 (MET) From: Peter Sylvester Message-Id: <200311201448.hAKEmOn08990@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: draft minutes X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The draft minutes of the IETF58 meeting are avialable in the web server. Since I was not able to participate, here some comments concerning several items mentioned in the minutes. It is really nice to see comments and questions in a raw form, this gives a better impression of the discusson, and allows to better ask for clarifications than with a 'summary by the chairman' approach. Thus: Agenda 1) : > Stated that the group is concerned with signed data as opposed to unsigned, general purpose archive. What exactly is meant by 'signed data'. I think the purpose is to 'archive and/or notarize authentifiable representations of information'. If signed data means that the data to be archived need to have some characteristics that can be considered as an equivalent of all aspects of what is called 'signature' for a paper document, then ok. The difference between archive and notoarize may be floating. If the archive provider cares a little bit of the semnatics of the document, for example when seome future conversion may be planned, then this can be considered as the first step of a notarisation operation; A real notarisation (depending on which culture you think about) can just end here (public notary) or continue to validate and assert the conformance to some legal procedure (EU continent). Agenda 3) : Having siad the previous, I don't think that one should even try to address the long term validaty of digital signature chains by using any cryptographic approach that includes secrets. Digital signatures are for strong authentication (IMHO) and not a sufficintly stable means for long term. It seems important to me that the underlying service model assumes that there is at least one additional redundant mechanism that can be used to prove the "existance" of some data at:before a certain time, e.g. physical protection with strong ordering of the storage media. > "Complicated problem of establishing validity of a chain of signatures over 100 years." Can someone give a paper equvalent example? 5) The requireemnts doc is a first attempt. "deleting data from archive without detection" : The requirement is not that one must not be able to delete without detecting, but rather that the archiver may be interested to prove at any time the global integrity of the data he has, or that if some data are not there, then they had never been there. This can be done in different ways, in a simple way by never deleting anything. > Hillary: You can't force archiving service to really archive, i.e. the bits can always be lost. Deletion requires authentication. I am not sure what is meant here. > Ulrich: Format conversion was considered - signature format, document format, etc. Considered it as a separate service distinct from archive services and notary services. It is not necessary to bundle such service as part of an archive. > Larry: General question raised, in favor or against, including some support for formats (i.e. format conversion history). > Tobias: Is this work useful? 1 person yes. No people no. Everyone else no answer. For whatever type of document, the inclusion of metadata describing the actual format (like a mime type, or oid, or schema, ...) should not be excluded as part of the input. Some of these metadata may provide sufficient redundancy information concerning the 'information structure' allowing a conversion in the future. Such a conversion can occur either on request of some client, or by some global service action, in this case the service provider can convert the data, and keep a history of the actions. The service provider is able to return the archived information in a representation which is 'state of the art' plus, optionally traces about the orginal formats and the conversions that had been done (like copied from hand written paper to machine written paper and signed by some authority). regards Peter Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmYkT034255 for ; Thu, 20 Nov 2003 06:48:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKEmYfo034254 for ietf-ltans-bks; Thu, 20 Nov 2003 06:48:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKEmTkT034244 for ; Thu, 20 Nov 2003 06:48:32 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA05195 for ; Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 20 Nov 2003 15:48:25 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hAKEmOn08990 for ietf-ltans@imc.org; Thu, 20 Nov 2003 15:48:24 +0100 (MET) Date: Thu, 20 Nov 2003 15:48:24 +0100 (MET) From: Peter Sylvester Message-Id: <200311201448.hAKEmOn08990@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: draft minutes X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The draft minutes of the IETF58 meeting are avialable in the web server. Since I was not able to participate, here some comments concerning several items mentioned in the minutes. It is really nice to see comments and questions in a raw form, this gives a better impression of the discusson, and allows to better ask for clarifications than with a 'summary by the chairman' approach. Thus: Agenda 1) : > Stated that the group is concerned with signed data as opposed to unsigned, general purpose archive. What exactly is meant by 'signed data'. I think the purpose is to 'archive and/or notarize authentifiable representations of information'. If signed data means that the data to be archived need to have some characteristics that can be considered as an equivalent of all aspects of what is called 'signature' for a paper document, then ok. The difference between archive and notoarize may be floating. If the archive provider cares a little bit of the semnatics of the document, for example when seome future conversion may be planned, then this can be considered as the first step of a notarisation operation; A real notarisation (depending on which culture you think about) can just end here (public notary) or continue to validate and assert the conformance to some legal procedure (EU continent). Agenda 3) : Having siad the previous, I don't think that one should even try to address the long term validaty of digital signature chains by using any cryptographic approach that includes secrets. Digital signatures are for strong authentication (IMHO) and not a sufficintly stable means for long term. It seems important to me that the underlying service model assumes that there is at least one additional redundant mechanism that can be used to prove the "existance" of some data at:before a certain time, e.g. physical protection with strong ordering of the storage media. > "Complicated problem of establishing validity of a chain of signatures over 100 years." Can someone give a paper equvalent example? 5) The requireemnts doc is a first attempt. "deleting data from archive without detection" : The requirement is not that one must not be able to delete without detecting, but rather that the archiver may be interested to prove at any time the global integrity of the data he has, or that if some data are not there, then they had never been there. This can be done in different ways, in a simple way by never deleting anything. > Hillary: You can't force archiving service to really archive, i.e. the bits can always be lost. Deletion requires authentication. I am not sure what is meant here. > Ulrich: Format conversion was considered - signature format, document format, etc. Considered it as a separate service distinct from archive services and notary services. It is not necessary to bundle such service as part of an archive. > Larry: General question raised, in favor or against, including some support for formats (i.e. format conversion history). > Tobias: Is this work useful? 1 person yes. No people no. Everyone else no answer. For whatever type of document, the inclusion of metadata describing the actual format (like a mime type, or oid, or schema, ...) should not be excluded as part of the input. Some of these metadata may provide sufficient redundancy information concerning the 'information structure' allowing a conversion in the future. Such a conversion can occur either on request of some client, or by some global service action, in this case the service provider can convert the data, and keep a history of the actions. The service provider is able to return the archived information in a representation which is 'state of the art' plus, optionally traces about the orginal formats and the conversions that had been done (like copied from hand written paper to machine written paper and signed by some authority). regards Peter Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeOkT085262 for ; Wed, 5 Nov 2003 07:40:24 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FeO8X085261 for ietf-ltans-bks; Wed, 5 Nov 2003 07:40:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FeMkT085252 for ; Wed, 5 Nov 2003 07:40:23 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA29551 for ; Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 5 Nov 2003 16:40:18 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA5FeHj06929 for ietf-ltans@imc.org; Wed, 5 Nov 2003 16:40:17 +0100 (MET) Date: Wed, 5 Nov 2003 16:40:17 +0100 (MET) From: Peter Sylvester Message-Id: <200311051540.hA5FeHj06929@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: draft-ietf-ltans-reqs-00.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > I do not think that this phrase is good in the introduction, > > in particular the wording of 'time stamp containing a digital > > signature'. Why do 'signatures require preservation'? The > > data itself need it. > > I agree the wording is a little awkward and in general the draft may be > overly prescriptive w.r.t. to timestamps as a mechanism, though this is > based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there > will always be one or more digital signatures present is based on > assumptions that data submitted to an archive will be timestamped and that > timestamps include a signature. Signatures require preservation due to the > decreasing value of the objects used to verify the signature, etc., etc. I think we are able to find a wording which is sufficiently neutral. > > > I disagree with this definition, i.e. with the second part > > staring with 'charged with ...' > > OK. We can strike the reference to the environment and leave that to the > mechanism specs. Ok. > > > > > - An archive service provider MUST NOT be able to insert data in a > > non chronological way, i.e., if some data are archived and > > time stamped, > > no data with a older time stamp can be inserted. > > I not sure I agree with this. If I have a document with timestamp 1 and you > have a document with timestamp 2, I shouldn't be prevented from archiving my > document because you submitted your doc first. If you mean that the archive > itself must never apply a timestamp older than a previously applied > timestamp, then I agree. the usage of the overloaded word time stamp (as you mention, the client data may already have one in some way, and the server may add another) is perhaps a problem. Indeed I mean basically the second thing. In fact, I am not sure whether strict linear order is required in the global sense, if you have trees of hashes. indeed, a client may have obtained some time stamp or "file seal" much earlier in order to have a proof of the existance, and this is not related to the time of archiving. > > > - An archive service MUST NOt be able to delete data from the > > archive with > > detecting, or in other words, the service must be able to prove that > > nothing has been deleted. > > > > - An archive service MUST allow to transfer completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. > > > > - An archive service MUST allow to delete completely or partially, > > archived data to another services provider without loss of the > > global integrity property defined above. (This can for example > > be accomplished by transfering data to a fictious "archiver"). > > Deleting may becontrolled by a policy, but needs exceptions. > > Perhaps we need a section addressing operational requirements. I think input from some real archiving providers may be helpful. > > > > - A provider should be able to provide the service in a staged way, > > i.e. provide initial acknowledgements for by final ones. This is > > important in order to avoid a simgle point of failure. > > This may also be important if there is to be support for a grace period to > accommodate compromise declaration after submission. Yes. > > > > > - If I understand it right, the TSA is used as a security > > mechanism by the TAA. I think one should not restrict this > > and open this to other mechanisms, e.g. an service > > provider can use another backend archive, can archive just > > all its transaction logs (or acknowledgements), > > In this case the TAA is acting as a client to another TAA. There's nothing > in the draft to restrict this type of interaction. Right > > - The text makes a lot of assumption about > > timestamps, in particular that a time stamp has a signature. I think > > one should weaken this. time stamping using hash linking is > > a technique > > that allows independance of secrets, and also, as a side effect, > > links all time stamps together, thus, is a good mesure to protect > > against undetected loss of archived data, or against false > > inclusions etc. > > Are there any timestamp formats that should be considered that don't feature > digital signatures? RFC3161 and ATS both feature signatures. Yes. At least in a second step: A client only needs a strong authentication method to validate a server when the time stamp is obtained. This is in general done by a signature. If you use hash linking, and if you publish in regular intervals the last hash, a client can ask for an extended time stamp which includes a hash chain up to the published one. This extended time stamp no longer depends on the security of keys, only on the hash function. See: http://ltans.edelweb.fr/Cybernetica-OpenEvidence-TimeStamping.pdf or at the http://www.cyber.ee Peter ----- End Included Message ----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDikT081544 for ; Wed, 5 Nov 2003 06:13:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5EDiDL081543 for ietf-ltans-bks; Wed, 5 Nov 2003 06:13:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5EDgkT081534 for ; Wed, 5 Nov 2003 06:13:43 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-138-88-47-253.res.east.verizon.net [138.88.47.253]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hA5EDZKJ018447; Wed, 5 Nov 2003 09:13:35 -0500 From: "Carl Wallace" To: "'Peter Sylvester'" , , Cc: Subject: RE: draft-ietf-ltans-reqs-00.txt Date: Wed, 5 Nov 2003 09:13:36 -0500 Message-ID: <000301c3a3a7$01496900$6501a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5EDhkT081535 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the comments and additional requirements. A few comments are inline below... > I do not think that this phrase is good in the introduction, > in particular the wording of 'time stamp containing a digital > signature'. Why do 'signatures require preservation'? The > data itself need it. I agree the wording is a little awkward and in general the draft may be overly prescriptive w.r.t. to timestamps as a mechanism, though this is based on previous work - RFC3126, DVCS, ATS, TAP. The notion that there will always be one or more digital signatures present is based on assumptions that data submitted to an archive will be timestamped and that timestamps include a signature. Signatures require preservation due to the decreasing value of the objects used to verify the signature, etc., etc. > I disagree with this definition, i.e. with the second part > staring with 'charged with ...' OK. We can strike the reference to the environment and leave that to the mechanism specs. > - An archive service provider MUST NOT be able to insert data in a > non chronological way, i.e., if some data are archived and > time stamped, > no data with a older time stamp can be inserted. I not sure I agree with this. If I have a document with timestamp 1 and you have a document with timestamp 2, I shouldn't be prevented from archiving my document because you submitted your doc first. If you mean that the archive itself must never apply a timestamp older than a previously applied timestamp, then I agree. > - An archive service MUST NOt be able to delete data from the > archive with > detecting, or in other words, the service must be able to prove that > nothing has been deleted. > > - An archive service MUST allow to transfer completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. > > - An archive service MUST allow to delete completely or partially, > archived data to another services provider without loss of the > global integrity property defined above. (This can for example > be accomplished by transfering data to a fictious "archiver"). > Deleting may becontrolled by a policy, but needs exceptions. Perhaps we need a section addressing operational requirements. > - A provider should be able to provide the service in a staged way, > i.e. provide initial acknowledgements for by final ones. This is > important in order to avoid a simgle point of failure. This may also be important if there is to be support for a grace period to accommodate compromise declaration after submission. > - If I understand it right, the TSA is used as a security > mechanism by the TAA. I think one should not restrict this > and open this to other mechanisms, e.g. an service > provider can use another backend archive, can archive just > all its transaction logs (or acknowledgements), In this case the TAA is acting as a client to another TAA. There's nothing in the draft to restrict this type of interaction. > - The text makes a lot of assumption about > timestamps, in particular that a time stamp has a signature. I think > one should weaken this. time stamping using hash linking is > a technique > that allows independance of secrets, and also, as a side effect, > links all time stamps together, thus, is a good mesure to protect > against undetected loss of archived data, or against false > inclusions etc. Are there any timestamp formats that should be considered that don't feature digital signatures? RFC3161 and ATS both feature signatures. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HugkT043858 for ; Mon, 3 Nov 2003 09:56:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3HugK6043857 for ietf-ltans-bks; Mon, 3 Nov 2003 09:56:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3HuekT043850 for ; Mon, 3 Nov 2003 09:56:41 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA15871 for ; Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 18:56:40 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Hudg02285 for ietf-ltans@imc.org; Mon, 3 Nov 2003 18:56:39 +0100 (MET) Date: Mon, 3 Nov 2003 18:56:39 +0100 (MET) From: Peter Sylvester Message-Id: <200311031756.hA3Hudg02285@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: long term Archive Architecture X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I have received a docuiment from two colleagues Libor and Marta in the Czech republic. So far, awaiting some comment from the chairmen, I have put the document in the ltans web server into the "related documents" section. --- forwarded message : From: "Marta.Vohnoutova@pvt.cz" Date: Mon, 3 Nov 2003 18:13:15 +0100 Dear Peter, I am very glad that I can send you the Long-term archiving - draft proposal which we (Libor Dostalek and Marta Vohnoutova) have made. You can see that we worked hard to help our ietf-ltans-arch group to progress. We put there our experiences with the "special world" of real archivists who will unavoidably talk to the long-term archiving project. This is a draft proposal and we expect and we would be very glad if other authors thing over our material. But we think it could be a very good starting point. Please bo so kind - read the attached material throroughly, put it on your web site and announce to the conference participants that new draft proposal exists. Looking forward to any comments Best regards Cordially Libor and Marta P.S. Because of necessary pictures we transformed the file into the PDF form (because of the rastr - the best view is if the scale is 100%. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3GdAkT040365 for ; Mon, 3 Nov 2003 08:39:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3GdApE040364 for ietf-ltans-bks; Mon, 3 Nov 2003 08:39:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3Gd8kT040357 for ; Mon, 3 Nov 2003 08:39:08 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA15265; Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 3 Nov 2003 17:39:03 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hA3Gd0U02088; Mon, 3 Nov 2003 17:39:00 +0100 (MET) Date: Mon, 3 Nov 2003 17:39:00 +0100 (MET) From: Peter Sylvester Message-Id: <200311031639.hA3Gd0U02088@chandon.edelweb.fr> To: ulrich.pordesch@sit.fraunhofer.de, cwallace@orionsec.com, ralf_brandner@med.uni-heideberg.de Subject: draft-ietf-ltans-reqs-00.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here some comments: For the German collegues, I use a rather "French style" of writing The difference is essentially: Pb: a German and a French person talk about the first initial draft and the goal is that it is a starting point and one needs to continue. - The French would say: "This draft is a completely unacceptable way to solve the problem." ==> The German would stop working (believing that everything is bad). - The German would say: "This is already a good starting point." ==> The French would stop working 'believing that everything is ok). :-) So now, a bit of brain storming: > It is anticipated that a timestamp containing a digital signature > will be obtained for data submitted to a long-term archive service. > Thus, for all types of data, i.e. signed and unsigned, one or more > digital signatures will exist that require preservation by the long- > term archive service. I do not think that this phrase is good in the introduction, in particular the wording of 'time stamp containing a digital signature'. Why do 'signatures require preservation'? The data itself need it. > This document aims to identify the technical requirements for a long- > term archive service charged with preservation of digitally signed > data in an X.509 certificate-based PKI. I disagree with this definition, i.e. with the second part staring with 'charged with ...' > Operational requirements, such as storage media concerns, individual > legal requirements and questions dealing with accountability are not > addressed by this document. I disagree that questions concerning accountability are not addressed. At least clients should be probperly identifiable. There may be just wording problem 'accountability" vs "accounting and billing techniques". At least a requeirement must be: "The transaction data and protocols must allow to carry either directly or indirectly information that allow to associate each transaction to some accounting and billing meachnism, examples are identifiers for individual clients and/or large customers. Some raw requirements (oops, I saw that some of them are already in), soory I didn't read all while I was writing. - An archive service provider MUST NOT be able to insert data in a non chronological way, i.e., if some data are archived and time stamped, no data with a older time stamp can be inserted. - An archive service MUST NOt be able to delete data from the archive with detecting, or in other words, the service must be able to prove that nothing has been deleted. - An archive service MUST allow to transfer completely or partially, archived data to another services provider without loss of the global integrity property defined above. - An archive service MUST allow to delete completely or partially, archived data to another services provider without loss of the global integrity property defined above. (This can for example be accomplished by transfering data to a fictious "archiver"). Deleting may becontrolled by a policy, but needs exceptions. I think the previous can be deduced from several of the existing text, in particular, about evidence for groups etc. - The archive service MUST be able to provide evidence about the policies that have been used at any time. - The format for the evidence/acknowledgements MUST allow to identify the archiving provider. - The format for the evidence/acknowledgements MUST allow (at least the creating the archiving provider) to identify the participating client. - A client or other relying parties MUST be able to prove that a particular acknowledgement (attestation) belongs to a request may by the client. I an simple case, a gloabl identifier of the client is used, for example. - It MUST be possible to include metadata concerning the data, for example a mime type, a short description in clear in the acknowlegments (attestations). - A broker style service provider should be able to relay requests to back end service providers. - A provider should be able to provide the service in a staged way, i.e. provide initial acknowledgements for by final ones. This is important in order to avoid a simgle point of failure. - A client may obtain final acknoledgements either by an asynch method, e.g. mail, or by a polling technique (maybe combined with a notification), cf. SAML - An acknowledgement/attestion is a verifyable statement from the archive provider confirming the acceptance and (maybe partial) fulfillment of the requested action. Short term verifiability needs to be ensured for the requesting client but also for other relying parties (e.g. signature shared secret authentication, ...) Long term authenticity can be ensured by a particular service. Comment about: - The protocol MUST define interactions with a Long-term Archive Service including, at a minimum: submission of data or groups of data for preservation, retrieval of archive packages and deletion of archived data and associated evidence records. I think the protocol should allow the validation of a acknowledge. Or, this would be a "confirm existence" vs "retrieval" of archive packages. - The protocol must allow that a "confirm existance" may return a reference of another archive provider. Chapter 3: - The model should allow for relays. - If I understand it right, the TSA is used as a security mechanism by the TAA. I think one should not restrict this and open this to other mechanisms, e.g. an service provider can use another backend archive, can archive just all its transaction logs (or acknowledgements), - The text makes a lot of assumption about timestamps, in particular that a time stamp has a signature. I think one should weaken this. time stamping using hash linking is a technique that allows independance of secrets, and also, as a side effect, links all time stamps together, thus, is a good mesure to protect against undetected loss of archived data, or against false inclusions etc. to resumee: Good start :-) Regards Peter Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSYkT008555 for ; Sat, 1 Nov 2003 04:28:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA1CSYO5008554 for ietf-ltans-bks; Sat, 1 Nov 2003 04:28:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1CSWkT008548 for ; Sat, 1 Nov 2003 04:28:33 -0800 (PST) (envelope-from Hannes.Tschofenig@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVF29118 for ; Sat, 1 Nov 2003 13:28:32 +0100 (MET) Received: from joe (lnxekv1-07.esn.sbs.de [149.246.36.7]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA1CSVs27566 for ; Sat, 1 Nov 2003 13:28:31 +0100 (MET) From: "Hannes Tschofenig" To: Subject: Date: Sat, 1 Nov 2003 13:27:43 +0100 Message-ID: <000001c3a073$8d72f3b0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: subscribe