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

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

 

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

 

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

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

…    

 

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

 

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

 

------

 

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

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

 

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

 

 

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


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

Regards,
Ralf

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



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


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





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

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

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

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

Regards,
Brian





------_=_NextPart_001_01C3EB22.D96B5010-- From owner-ietf-ltans Fri Feb 13 13:10:25 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DLAPxZ019744; Fri, 13 Feb 2004 13:10:25 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1DLAPJ7019743; Fri, 13 Feb 2004 13:10:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DLANqA019736 for ; Fri, 13 Feb 2004 13:10:24 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03832; Fri, 13 Feb 2004 16:10:43 -0500 (EST) Message-Id: <200402132110.QAA03832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-00.txt Date: Fri, 13 Feb 2004 16:10:43 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner Filename : draft-ietf-ltans-ers-00.txt Pages : 22 Date : 2004-2-12 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163252.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DLAPxZ019744; Fri, 13 Feb 2004 13:10:25 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1DLAPJ7019743; Fri, 13 Feb 2004 13:10:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DLANqA019736 for ; Fri, 13 Feb 2004 13:10:24 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03832; Fri, 13 Feb 2004 16:10:43 -0500 (EST) Message-Id: <200402132110.QAA03832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-00.txt Date: Fri, 13 Feb 2004 16:10:43 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner Filename : draft-ietf-ltans-ers-00.txt Pages : 22 Date : 2004-2-12 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163252.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14DSf5H050421; Wed, 4 Feb 2004 05:28:41 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i14DSfrF050420; Wed, 4 Feb 2004 05:28:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14DSX9d050408 for ; Wed, 4 Feb 2004 05:28:38 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i14DSYhe017737; Wed, 4 Feb 2004 14:28:35 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 14:29:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5341@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Cc: "'ralf.brandner@intercomponentware.com'" Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? - keep it Date: Wed, 4 Feb 2004 14:29:00 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB22.D96B5010" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EB22.D96B5010 Content-Type: text/plain First rough consensus: as taken from the mailing-list I derive the first rough consensus to keep the wording "trusted archive" Best regards and thank you for your comments Tobias ;-) chair LTANS -----Original Message----- From: ralf.brandner@intercomponentware.com [mailto:ralf.brandner@intercomponentware.com] Sent: Friday, January 30, 2004 8:35 To: Tobias.Gondrom@ixos.de Cc: ietf-ltans@imc.org Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ? I agree with Carl and Brian, then also for me is archiving only the "simple" document storage. Trusted archiving is more - conservation of evidence ... Regards, Ralf ======================================== Dr. Ralf Brandner Produktmanager InterComponentWare AG Otto-Hahn-Str. 3 69190 Walldorf Tel: +49 6227 385 135 Fax: +49 6227 385 192 Mobil: +49 173 6667457 Email: ralf.brandner@intercomponentware.com ======================================== "Brandner, Ralf" 28.01.2004 14:33 To: "Ralf Brandner (E-Mail)" cc: Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ? > > ---------- > Von: Brian Hunter[SMTP:BRIAN.HUNTER@SIT.FRAUNHOFER.DE] > Gesendet: Mittwoch, 28. Januar 2004 14:26:54 > An: Carl Wallace > Cc: 'Tobias Gondrom'; ietf-ltans@imc.org > Betreff: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ? > Diese Nachricht wurde automatisch von einer Regel weitergeleitet. > > Carl Wallace wrote: >>For that I would prefer if we could change the names from : >>"Trusted Archiving" to "Archiving" >>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive > > Service" > > The word "trusted" provides a hint that something more than simple storage > of the data is going on (even if the actual trust is in the TSA). Also, an I agree. The differentiation between a simple archive service (only document storage) and an archive service that obtains evidence of document existence is important. > Archive Authority must be trusted if it is providing trust anchor > information. I am not sure I follow this point. What would this trust anchor information be? Regards, Brian ------_=_NextPart_001_01C3EB22.D96B5010 Content-Type: text/html Message
First rough consensus:
 
as taken from the mailing-list I derive the first rough consensus to keep the wording "trusted archive"
 
Best regards and thank you for your comments
 
Tobias ;-)
 
chair LTANS
 
 
-----Original Message-----
From: ralf.brandner@intercomponentware.com [mailto:ralf.brandner@intercomponentware.com]
Sent: Friday, January 30, 2004 8:35
To: Tobias.Gondrom@ixos.de
Cc: ietf-ltans@imc.org
Subject: WG: Initial requirements for long-term archive I-D - wording: Trusted archiving ?


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

Regards,
Ralf

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



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


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





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

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

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

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

Regards,
Brian





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

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

 

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

 

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

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

…    

 

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

 

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

 

------

 

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

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

 

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

 

 

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