Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1MF2sPl045842; Wed, 22 Feb 2006 08:02:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k1MF2sSg045841; Wed, 22 Feb 2006 08:02:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1MF2rR8045835 for ; Wed, 22 Feb 2006 08:02:53 -0700 (MST) (envelope-from robholliday@isocore.com) Message-Id: <200602221502.k1MF2rR8045835@balder-227.proper.com> Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FBvVz-0007lj-7c for ietf-ltans@imc.org; Wed, 22 Feb 2006 10:02:51 -0500 From: "Robert Holliday" To: Subject: International Conference on Network Security 2006 Date: Wed, 22 Feb 2006 10:02:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C63797.24DC13F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcY3wQ1oZSvucIsCSeOHG2kehror5g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: 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_0008_01C63797.24DC13F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_0008_01C63797.24DC13F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

=

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://www.isocore.com/netwo= rksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/netwo= rksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.isocore.com/netwo= rksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /span>

 

 

 

------=_NextPart_000_0008_01C63797.24DC13F0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1MChhJU028143; Wed, 22 Feb 2006 05:43:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k1MChhJI028142; Wed, 22 Feb 2006 05:43:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1MChgDh028123 for ; Wed, 22 Feb 2006 05:43:43 -0700 (MST) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from [141.12.87.229] (sitp394.sit.fraunhofer.de [141.12.69.140]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k1MChOAr007558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2006 13:43:25 +0100 Message-ID: <43FC5CAE.3070405@sit.fraunhofer.de> Date: Wed, 22 Feb 2006 13:44:30 +0100 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Call for papers, Workshop "Long-term Security" at ETRICS 2006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Call for Papers for the Workshop "Long-term Security" Co-located with the International Conference on Emerging Trends in Information and Communication Security (ETRICS'06) June 6-9, 2006, Freiburg, Germany http://www.etrics.org/workshops Concerns about the long-term security of digital data and communication are growing for many applications, such as archiving, notarial acts, secure transmission of genome data, and many workflows in the banking and financial industries, e-health, and e-government. Security goals, such as availability, authenticity, integrity, and confidentiality of documents and communication contents are in danger when viewed from a long-term perspective. In contrast to paper documents, the probative force of electronically signed documents can decrease over time due to advances in cryptographic research, the increasing computational power to break keys and the possible realization of the quantum computer. These advances might also allow long-term and/or future attacks on encrypted communication over public networks, thus threatening the confidentiality of the contents. Additionally, legal regulations often demand time spans for document preservation which are well beyond the expected lifetime of common data formats. The transformation into current formats imposes new challenges, especially for signed documents. This workshop aims at the discussion of recent advances in organizational and technical means providing long-term security. Theoretical work, prototypes and experimental studies are equally welcome. Topics of interest include but are not limited to: * Security goals, requirements and legal aspects under a long-term perspective * Organizational and technical means of long-term security * Long-term cryptographic mechanisms * Operations such as conversions to ensure the long-term-availability of data Important Dates: * April 15, 2006: Abstract submission (send 2 pages to kreutzer@dzi.tu-darmstadt.de) * April 28, 2006: Final paper submission * May 1, 2006: Notification of acceptance for the workshop Workshop Chairs: * Dr. Andreas. U. Schmidt, Fraunhofer SIT, Germany * Michael Kreutzer, Darmstadt Centre for IT Security, Germany Program Committee: * Harald Baier, FH Bingen, Germany * Martin Döring, Cryptography and Computer Algebra, TU Darmstadt, Germany * Maximillian Dornseif, Dependable Distributed Systems, University of Mannheim, Germany * Manuel Hartl, Flexsecure GmbH, Eberstadt, Germany * Martin Kähmer, Univ. of Freiburg, Germany * Ulrich Pinsdorf, Fraunhofer IGD, Germany * Kai Rannenberg, Univ. of Frankfurt, Germany * Jörg Rocker, Security Management, Postbank Systems AG, Germany * Axel Sikora, Univ. of Applied Sciences Lörrach, Germany * Daniel Wilke, Project group constitution-compatible technology development, Univ. Kassel, Germany * Petra Wohlmacher, Federal Network Agency, Mainz, Germany Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1GGxgE8074913; Thu, 16 Feb 2006 08:59:42 -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 k1GGxg81074912; Thu, 16 Feb 2006 08:59:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1GGxgHS074905 for ; Thu, 16 Feb 2006 08:59:42 -0800 (PST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6331B.4B4EDCF5" Subject: Comments draft-ietf-ltans-ers-05 Date: Thu, 16 Feb 2006 09:06:14 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C8790147D52F@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments draft-ietf-ltans-ers-05 thread-index: AcYzGl22DMTwlZp3SHm//Bj2ISrSIw== From: "Santosh Chokhani" To: 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_001_01C6331B.4B4EDCF5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. We should state in the security considerations section that the long term security of encryption scheme has not been analyzed in terms of how it can be used to create collisions. Actually, a better understanding of Section 5 is required to make a final determination in this area. =20 2. It should also point out that the encryption scheme is not renewable. =20 3. Section 4.1, Is there a hash tree aside from or other than the reduced hash tree? =20 4. Section 4.2 contradicts Section 3 by saying that "initial time stamp is obtained for each object". I thought the time stamp is obtained for a reduced hash tree. =20 5. Section 4.3, all three verification steps seem to be missing generation of root hash and using that to verify the time stamp. =20 6. Section 5.1 ASN.1 seems to be incomplete. =20 7. Section 5 is confusing enough that an example in Appendix will help =20 8. Section 5.1 is unclear on what is in the archive record in terms of private and secret keys. a) The section says that RSA key transfer is used, but then describes the symmetric encryption also. b) The ASN.1 seems to imply that the private key or the symmetric key is also archived. That does not seem to provide any confidentiality to the archived data. In that case, why not archive the plaintext data. Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------_=_NextPart_001_01C6331B.4B4EDCF5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.       We should state in the security = considerations section that the long term security of encryption scheme has not been analyzed = in terms of how it can be used to create collisions.  Actually, a better understanding of Section 5 is required to make a final determination in = this area.

 

2.        It should also point out that the = encryption scheme is not renewable.

 

3.       Section 4.1, Is there a hash tree aside from = or other than the reduced hash tree?

 

4.       Section 4.2 contradicts Section 3 by saying = that “initial time stamp is obtained for each object”.  I = thought the time stamp is obtained for a reduced hash = tree.

 

5.       Section 4.3, all three verification steps = seem to be missing generation of root hash and using that to verify the time = stamp.

 

6.       Section 5.1 ASN.1 seems to be = incomplete.

 

7.       Section 5 is confusing enough that an example = in Appendix will help

 

8.       Section 5.1 is unclear on what is in the = archive record in terms of private and secret keys.

a)    The section says that RSA key transfer is = used, but then describes the symmetric encryption = also.

b)    The ASN.1 seems to imply that the private key = or the symmetric key is also archived.  That does not seem to provide any = confidentiality to the archived data.  In that case, why not archive the plaintext = data.

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

 

------_=_NextPart_001_01C6331B.4B4EDCF5-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1GFGRXx063371; Thu, 16 Feb 2006 07:16:27 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k1GFGRMg063369; Thu, 16 Feb 2006 07:16:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1GFGQxc063356 for ; Thu, 16 Feb 2006 07:16:26 -0800 (PST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Jabber Date: Thu, 16 Feb 2006 07:22:58 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C8790147D37A@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jabber thread-index: AcYzC/D2yYubyuvTTtClFvvP894kXQ== From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k1GFGQxc063358 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, The LTANS WG will be meeting next month in Dallas. The draft IETF agenda with the meeting date should be posted tomorrow. I'll post a draft meeting agenda by the end of the month. In order to support remote participation and speed WG progress, we really need a Jabber scribe for this meeting. Please let me know if you can fulfill this role, or know someone who could. Thanks. Carl Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1FCPuS0043692; Wed, 15 Feb 2006 04:25: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 k1FCPuUT043691; Wed, 15 Feb 2006 04:25:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1FCPtJ4043684 for ; Wed, 15 Feb 2006 04:25:55 -0800 (PST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: 65th IETF LTANS agenda slots Date: Wed, 15 Feb 2006 04:32:13 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C879014218FA@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 65th IETF LTANS agenda slots Thread-Index: AcYyKcMRr6kkbQMoQ02MlK8AUhwJTw== From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k1FCPtJ4043686 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, If anyone would like time on the agenda during the LTANS meeting in Dallas, please send a note to me and Tobias. We'll post a draft agenda later this month. Carl Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DF7XEC042701; Mon, 13 Feb 2006 07:07:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k1DF7Xjm042700; Mon, 13 Feb 2006 07:07:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from advantage-security.com ([201.148.139.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DF7Wi5042694 for ; Mon, 13 Feb 2006 07:07:32 -0800 (PST) (envelope-from gwerner@advantage-security.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: comments on draft-ietf-ltans-pki-notareqs-03.txt Date: Mon, 13 Feb 2006 09:07:21 -0600 Message-ID: <1815FE0A4A30A44BA2F9E367E1B00AB130A46D@corporativo.production.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-ltans-pki-notareqs-03.txt Thread-Index: AcYwc2pKqRmA8TawT6qt12ZrqPFhkAAOwv9w From: "Greg Werner" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k1DF7Wi5042695 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes I believe it would be worthwhile, BBVA Mexico for instance has stated that they would rather spend more to achieve more *trust* regarding their archived datum. They could, for example, set up an nCipher appliance to provide the time stamps on a massive scale. This would be cheaper for them and probably provide them with faster responses since the TSA would be hosted on the local network. However this is not a legal and therefore *trusted* solution for them. How is a total system consisting of more trusted components more difficult to asses for security? Thanks. Greg -----Mensaje original----- De: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@sit.fraunhofer.de] Enviado el: lunes, 13 de febrero de 2006 2:00 Para: ietf-ltans@imc.org Asunto: Re: comments on draft-ietf-ltans-pki-notareqs-03.txt The rationale was that *trust* comes always at a cost, e.g., external timestamping services are expensive not due to technical reasons but rather since their certified trustworthiness and accuracy comes at a cost to the clientele. That discriminates the use of trusted service providers in a general way from outsourcing. Moreover, a total system consisting of more trusted components is more difficult to assess for security, which entails further cost. Performance and scalability might indeed not be such a problem. Is an explanation along the mentioned lines desirable? AUS Greg Werner wrote: >Regarding: > >6. Operational Considerations > > Data validation and certification services may have strong > performance and scalability requirements. A certification service > must be able to work efficiently even for large amounts of data > objects and requests. > > In order to limit expenses and to achieve high performance, the > involvement of other trusted third parties should be minimized. > >I´m not sure I understand the second paragraph. Could someone please explain, it sounds as if the recommendation is to "limit expenses" however some companies may which to pay more for certain services to circumvent some possible risks (whatever those may be). > >It sounds like the recommendation is out of scope because this is a cost/benefit and ROI analysis that each company should do. > >Greg > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DCuSdF031977; Mon, 13 Feb 2006 04:56:28 -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 k1DCuSHe031976; Mon, 13 Feb 2006 04:56:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DCuQtB031966 for ; Mon, 13 Feb 2006 04:56:27 -0800 (PST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.87.208] (sitp230.sit.fraunhofer.de [141.12.68.230]) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k1DCuLA0011832; Mon, 13 Feb 2006 13:56:21 +0100 Message-ID: <43F081DE.2010702@sit.fraunhofer.de> Date: Mon, 13 Feb 2006 13:55:58 +0100 From: Thomas Kunz User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Frei CC: Tilo Kienitz , ietf-ltans@imc.org Subject: Re: LTANS: Examples of ERS data - cross checking of implementations References: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> <43F058D0.5030209@seccommerce.de> <43F063BF.6060207@sit.fraunhofer.de> <1139834127.9584.40.camel@localhost.localdomain> In-Reply-To: <1139834127.9584.40.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Adrian Frei wrote: > Thomas Kunz wrote: > >>Tilo Kienitz wrote: >> >>>Hello, >>> >>>Frei Adrian (frr) wrote: >>> >>> >>>>Hmm, I think you misunderstood the generation of the reduced hash tree >>>>(I-D 3.2). The five lists in IXOS' hash tree are not five data object >>>>groups; they are five levels of the hash tree. The tree looks like >>> >>> > this: >>> >>> >>>> ROOT >>>> | \ \ >>>> YYYY f79a 0000 >>>> | \ \ /|\ >>>> YYYY c414 3413 >>>> | \ \ /|\ /|\ >>>> YYYY cf18 6ba0 >>>> / | \ /|\ /|\ >>>> YYYY (c4a8) b837 46d8 >>>> / | \ / | \ / | \ >>>>51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX >>>>data obj grp 1 data obj grp 2 data obj grp 3 >>> >>> >>>Thank you for the explanation. If it is really meant to encode this >>>tree in the way the Ixos-example dit it, then how would it be possible >>>to encode the tree if I wanted to include the complete "data obj grp 2" >>>too? In the simple case that I only want to proove that a certain, >>>single data object exists in the tree, only a single data object group >>>has to be included in the reduced hash tree and the Ixos-encoding works >>>fine. But let "data obj grp 1" contain the hash over the signature of >>>a document and "data obj grp 2" the hash over the OCSP response for the >>>certificate of the person who signed the document. Then I would like >>>to have both hashes in the same reduced hash tree. Of course I could >>>create two independent evidence records where each contains the reduced >>>hash tree for one of the hashes. But it would be good to have every- >>>thing relating to one document (sig hash and OCSP response hash) in the >>>same evidence record. >>> >> >>You have always different evidence records for every data object group >>in the hash tree. If you would like to have the hash over the signature >>and the hash over the ocsp response in the same reduced hash tree, you >>should build a data object group containing these two hashes. In the >>example above, "data obj grp 1" consists of three (data object) hashes, >>but a data object group can be of arbitrary size, independent of having >>a binary tree, a ternary tree or whatever tree. > > > Ok, sorry, actually the three leafs in the IXOS tree are all single > object groups with only a single object, which means the text in my > diagram is wrong. However, it could have been otherwise. > The text in your diagram is not necessarily wrong. As I pointed out in another thread in this mailing list, if you have a ternary tree and the first list of hash values in the reduced hashtree contains three hashes, you can't unambiguously detemine if you have a object group containing only one data object hash (and the other two hashes a simply siblings) or a data object group containing three data object hashes (the same e.g. in the case of a binary tree and two hash values in the first list). Of course, since IXOS provided only one document together with the evidence record, we can assume that the group consists only of one document hash. Regards, Thomas Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DCZbHU031103; Mon, 13 Feb 2006 04:35: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 k1DCZbJW031102; Mon, 13 Feb 2006 04:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2.zhwin.ch (mx2.zhwin.ch [160.85.104.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DCZaP9031095 for ; Mon, 13 Feb 2006 04:35:36 -0800 (PST) (envelope-from frr@zhwin.ch) Received: from orwell.zhwin.ch ([160.85.104.31]) by mx2.zhwin.ch with esmtp (Exim 4.54) id 1F8cvS-00031m-IJ; Mon, 13 Feb 2006 13:35:30 +0100 Received: from dove.zhwin.ch (Not Verified[160.85.196.13]) by orwell.zhwin.ch with NetIQ MailMarshal 6.0 Service Pack 1a (v6,0,3,33) id ; Mon, 13 Feb 2006 13:34:51 +0100 Received: from langouste.zhwin.ch ([160.85.196.12]) by dove.zhwin.ch with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 13:35:30 +0100 Received: from 160.85.182.240 ([160.85.182.240]) by langouste.zhwin.ch ([160.85.196.12]) via Exchange Front-End Server mail.zhwin.ch ([160.85.196.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Feb 2006 12:35:29 +0000 Received: from DSKT6049 by mail.zhwin.ch; 13 Feb 2006 13:35:27 +0100 Subject: Re: LTANS: Examples of ERS data - cross checking of implementations From: Adrian Frei To: Thomas Kunz Cc: Tilo Kienitz , ietf-ltans@imc.org In-Reply-To: <43F063BF.6060207@sit.fraunhofer.de> References: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> <43F058D0.5030209@seccommerce.de> <43F063BF.6060207@sit.fraunhofer.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 13 Feb 2006 13:35:27 +0100 Message-Id: <1139834127.9584.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-OriginalArrivalTime: 13 Feb 2006 12:35:30.0330 (UTC) FILETIME=[F9A7EFA0:01C63099] Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas Kunz wrote: > Tilo Kienitz wrote: > > > > Hello, > > > > Frei Adrian (frr) wrote: > > > >> Hmm, I think you misunderstood the generation of the reduced hash tree > >> (I-D 3.2). The five lists in IXOS' hash tree are not five data object > >> groups; they are five levels of the hash tree. The tree looks like > > > > > this: > > > >> > >> ROOT > >> | \ \ > >> YYYY f79a 0000 > >> | \ \ /|\ > >> YYYY c414 3413 > >> | \ \ /|\ /|\ > >> YYYY cf18 6ba0 > >> / | \ /|\ /|\ > >> YYYY (c4a8) b837 46d8 > >> / | \ / | \ / | \ > >> 51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX > >> data obj grp 1 data obj grp 2 data obj grp 3 > > > > > > Thank you for the explanation. If it is really meant to encode this > > tree in the way the Ixos-example dit it, then how would it be possible > > to encode the tree if I wanted to include the complete "data obj grp 2" > > too? In the simple case that I only want to proove that a certain, > > single data object exists in the tree, only a single data object group > > has to be included in the reduced hash tree and the Ixos-encoding works > > fine. But let "data obj grp 1" contain the hash over the signature of > > a document and "data obj grp 2" the hash over the OCSP response for the > > certificate of the person who signed the document. Then I would like > > to have both hashes in the same reduced hash tree. Of course I could > > create two independent evidence records where each contains the reduced > > hash tree for one of the hashes. But it would be good to have every- > > thing relating to one document (sig hash and OCSP response hash) in the > > same evidence record. > > > You have always different evidence records for every data object group > in the hash tree. If you would like to have the hash over the signature > and the hash over the ocsp response in the same reduced hash tree, you > should build a data object group containing these two hashes. In the > example above, "data obj grp 1" consists of three (data object) hashes, > but a data object group can be of arbitrary size, independent of having > a binary tree, a ternary tree or whatever tree. Ok, sorry, actually the three leafs in the IXOS tree are all single object groups with only a single object, which means the text in my diagram is wrong. However, it could have been otherwise. Tilo Kienitz wrote: >>> Why is the last hash value 00...00? A hash which just happens to be >>> all zeros by coincidence? Or does it have a special meaning? > >> That's exactly because of 3.2.4. Since IXOS' tree contained something >> between 81 and 162 documents they had to include an additional (dummy) >> hash value (0000) to the last level of the tree to get a "complete" >> ternary hash tree. > > Why is it necessary to have a complete ternary hash tree? The hash > computation would work well without the dummy. > Hmm, I think you are right, but possibly it was just the easiest way to generate a complete ternary hash tree and then reduce it. My implementation does also generate complete and full balanced binary trees just to make things easier. Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DAlvoA021253; Mon, 13 Feb 2006 02:47:57 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k1DAlvSd021252; Mon, 13 Feb 2006 02:47:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DAluL7021215 for ; Mon, 13 Feb 2006 02:47:56 -0800 (PST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.87.208] (sitp230.sit.fraunhofer.de [141.12.68.230]) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k1DAlnF1012751; Mon, 13 Feb 2006 11:47:49 +0100 Message-ID: <43F063BF.6060207@sit.fraunhofer.de> Date: Mon, 13 Feb 2006 11:47:27 +0100 From: Thomas Kunz User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tilo Kienitz CC: "Frei Adrian (frr)" , ietf-ltans@imc.org Subject: Re: LTANS: Examples of ERS data - cross checking of implementations References: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> <43F058D0.5030209@seccommerce.de> In-Reply-To: <43F058D0.5030209@seccommerce.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Tilo Kienitz wrote: > > Hello, > > Frei Adrian (frr) wrote: > >> Hmm, I think you misunderstood the generation of the reduced hash tree >> (I-D 3.2). The five lists in IXOS' hash tree are not five data object >> groups; they are five levels of the hash tree. The tree looks like > > > this: > >> >> ROOT >> | \ \ >> YYYY f79a 0000 >> | \ \ /|\ >> YYYY c414 3413 >> | \ \ /|\ /|\ >> YYYY cf18 6ba0 >> / | \ /|\ /|\ >> YYYY (c4a8) b837 46d8 >> / | \ / | \ / | \ >> 51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX >> data obj grp 1 data obj grp 2 data obj grp 3 > > > Thank you for the explanation. If it is really meant to encode this > tree in the way the Ixos-example dit it, then how would it be possible > to encode the tree if I wanted to include the complete "data obj grp 2" > too? In the simple case that I only want to proove that a certain, > single data object exists in the tree, only a single data object group > has to be included in the reduced hash tree and the Ixos-encoding works > fine. But let "data obj grp 1" contain the hash over the signature of > a document and "data obj grp 2" the hash over the OCSP response for the > certificate of the person who signed the document. Then I would like > to have both hashes in the same reduced hash tree. Of course I could > create two independent evidence records where each contains the reduced > hash tree for one of the hashes. But it would be good to have every- > thing relating to one document (sig hash and OCSP response hash) in the > same evidence record. > You have always different evidence records for every data object group in the hash tree. If you would like to have the hash over the signature and the hash over the ocsp response in the same reduced hash tree, you should build a data object group containing these two hashes. In the example above, "data obj grp 1" consists of three (data object) hashes, but a data object group can be of arbitrary size, independent of having a binary tree, a ternary tree or whatever tree. > >>> Why is the last hash value 00...00? A hash which just happens to be >>> all zeros by coincidence? Or does it have a special meaning? > > > > >> That's exactly because of 3.2.4. Since IXOS' tree contained something >> between 81 and 162 documents they had to include an additional (dummy) >> hash value (0000) to the last level of the tree to get a "complete" >> ternary hash tree. > > > Why is it necessary to have a complete ternary hash tree? The hash > computation would work well without the dummy. > > Regards > Tilo > > Regards, Thomas Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DA1ANk015702; Mon, 13 Feb 2006 02:01: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 k1DA1AZS015701; Mon, 13 Feb 2006 02:01:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1DA17Gq015694 for ; Mon, 13 Feb 2006 02:01:08 -0800 (PST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 19897 invoked from network); 13 Feb 2006 10:03:12 -0000 Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 13 Feb 2006 10:03:12 -0000 Message-ID: <43F058D0.5030209@seccommerce.de> Date: Mon, 13 Feb 2006 11:00:48 +0100 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frei Adrian (frr)" , ietf-ltans@imc.org Subject: Re: LTANS: Examples of ERS data - cross checking of implementations References: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> In-Reply-To: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Frei Adrian (frr) wrote: > Hmm, I think you misunderstood the generation of the reduced hash tree > (I-D 3.2). The five lists in IXOS' hash tree are not five data object > groups; they are five levels of the hash tree. The tree looks like > this: > > ROOT > | \ \ > YYYY f79a 0000 > | \ \ /|\ > YYYY c414 3413 > | \ \ /|\ /|\ > YYYY cf18 6ba0 > / | \ /|\ /|\ > YYYY (c4a8) b837 46d8 > / | \ / | \ / | \ > 51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX > data obj grp 1 data obj grp 2 data obj grp 3 Thank you for the explanation. If it is really meant to encode this tree in the way the Ixos-example dit it, then how would it be possible to encode the tree if I wanted to include the complete "data obj grp 2" too? In the simple case that I only want to proove that a certain, single data object exists in the tree, only a single data object group has to be included in the reduced hash tree and the Ixos-encoding works fine. But let "data obj grp 1" contain the hash over the signature of a document and "data obj grp 2" the hash over the OCSP response for the certificate of the person who signed the document. Then I would like to have both hashes in the same reduced hash tree. Of course I could create two independent evidence records where each contains the reduced hash tree for one of the hashes. But it would be good to have every- thing relating to one document (sig hash and OCSP response hash) in the same evidence record. >> Why is the last hash value 00...00? A hash which just happens to be >> all zeros by coincidence? Or does it have a special meaning? > > That's exactly because of 3.2.4. Since IXOS' tree contained something > between 81 and 162 documents they had to include an additional (dummy) > hash value (0000) to the last level of the tree to get a "complete" > ternary hash tree. Why is it necessary to have a complete ternary hash tree? The hash computation would work well without the dummy. Regards Tilo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1D7xXFZ004483; Sun, 12 Feb 2006 23:59:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k1D7xX5D004482; Sun, 12 Feb 2006 23:59:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1D7xWLL004475 for ; Sun, 12 Feb 2006 23:59:33 -0800 (PST) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from [141.12.87.229] (sitp225.sit.fraunhofer.de [141.12.68.225]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k1D7xOrr029143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 08:59:25 +0100 Message-ID: <43F03C99.5050907@sit.fraunhofer.de> Date: Mon, 13 Feb 2006 09:00:25 +0100 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: comments on draft-ietf-ltans-pki-notareqs-03.txt References: <1815FE0A4A30A44BA2F9E367E1B00AB130A450@corporativo.production.local> In-Reply-To: <1815FE0A4A30A44BA2F9E367E1B00AB130A450@corporativo.production.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The rationale was that *trust* comes always at a cost, e.g., external timestamping services are expensive not due to technical reasons but rather since their certified trustworthiness and accuracy comes at a cost to the clientele. That discriminates the use of trusted service providers in a general way from outsourcing. Moreover, a total system consisting of more trusted components is more difficult to assess for security, which entails further cost. Performance and scalability might indeed not be such a problem. Is an explanation along the mentioned lines desirable? AUS Greg Werner wrote: >Regarding: > >6. Operational Considerations > > Data validation and certification services may have strong > performance and scalability requirements. A certification service > must be able to work efficiently even for large amounts of data > objects and requests. > > In order to limit expenses and to achieve high performance, the > involvement of other trusted third parties should be minimized. > >I´m not sure I understand the second paragraph. Could someone please explain, it sounds as if the recommendation is to "limit expenses" however some companies may which to pay more for certain services to circumvent some possible risks (whatever those may be). > >It sounds like the recommendation is out of scope because this is a cost/benefit and ROI analysis that each company should do. > >Greg > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1D7FIqW001715; Sun, 12 Feb 2006 23:15:18 -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 k1D7FIM1001714; Sun, 12 Feb 2006 23:15:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2.zhwin.ch (mx2.zhwin.ch [160.85.104.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1D7FGRw001706 for ; Sun, 12 Feb 2006 23:15:17 -0800 (PST) (envelope-from frr@zhwin.ch) Received: from orwell.zhwin.ch ([160.85.104.31]) by mx2.zhwin.ch with esmtp (Exim 4.54) id 1F8XvS-0001rv-Gx; Mon, 13 Feb 2006 08:15:10 +0100 Received: from dove.zhwin.ch (Not Verified[160.85.196.13]) by orwell.zhwin.ch with NetIQ MailMarshal 6.0 Service Pack 1a (v6,0,3,33) id ; Mon, 13 Feb 2006 08:14:31 +0100 Received: from langouste.zhwin.ch ([160.85.196.12]) by dove.zhwin.ch with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 08:15:10 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: AW: LTANS: Examples of ERS data - cross checking of implementations Date: Mon, 13 Feb 2006 08:15:09 +0100 Message-ID: <55FEC03AF31CBE458B6B455F5214CAC74342CA@langouste.zhwin.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: Examples of ERS data - cross checking of implementations Thread-Index: AcYvTE78TBsA5QFPQNKeONfM2oYCuwBHIdsg From: "Frei Adrian \(frr\)" To: "Tilo Kienitz" , X-OriginalArrivalTime: 13 Feb 2006 07:15:10.0339 (UTC) FILETIME=[39A60D30:01C6306D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k1D7FIRw001709 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Tilo Kienitz wrote: > Thomas Kunz wrote: > > The procedure how to concatenate and hash the values in the reduced > > hashtree is decribed in section 3.3 of the I-D. > > You concatenate the three values (51B1..., 5BD0..., 60BB...) in the > > first list in ascending order an hash them with ripemd160. This hash > > becomes member of the second list (B537..., 46D8...). Now you > > concatenate these three hash values (the two in the list and the > > calculated one) and hash them, etc. Continue this procedure until the > > root hash is calculated. This root hash must correspond to the hashed > > message in the timestamp. > > I was able to compute the root hash and verify the first timestamp this > way. But I think the root hash has to be computed differently. The > example contains the following hashes. I have noted all DER encoding > bytes and named the data object groups A, B, C, D and E. > > 30 81 fc > 30 42 (data object group A) > 04 14 51b178b4a09592d425b70972ba448eb0221d39d9 > 04 14 5bd0247c9f86b4b1fad7500f61fcd9e622651ad2 > 04 14 60bbc5706949fc4d191771b9a7743416a340f7ee > 30 2c (data object group B) > 04 14 b837fbd61b1c82644fd196892cf9fb1ee16a2473 > 04 14 46d8fc303bed6cfa433e8f09146acc2f2c32a51c > 30 2c (data object group C) > 04 14 cf18dda21b8d71d7c43e11b603b3c0c309986bd8 > 04 14 6ba0a0bb6cf43cb7665b1876aba9db4f903256b1 > 30 2c (data object group D) > 04 14 c414a00a8e579e49cec5baab06abb577a6effea3 > 04 14 3413e337a9dbfd820a321550ef0bf82270b5e845 > 30 2c (data object group E) > 04 14 f79a6ca87a7c741cf40aebaaa8918055f85810ea > 04 14 0000000000000000000000000000000000000000 > > I agree on the first step which is to compute the hash over (51B1..., > 5BD0..., 60BB...). It's C4A84457CAF1F7CD675754ECE406C429DE0B059F. But > why should it be inserted into data object group B? I think the next > step should be to generate the hashes over over data object groups B, C, > D and E without inserting anything. The resulting five hashes (one for > each data object group) build the next higher list of hash values. I > think this is meant by "This hash value h' must become member of the > next higher list of hash values." Otherwise h' would become member of > another list of hash values on the same level instead of the next higher > level. Data object groups A, B, C, D and E are on the same level. > Then the hash over the binary sorted five computed hashes is > 06E1045012391C2DCE1F673E6917EE2239EB5EA7. Finally this hash alone is > hashed again, because there is another ASN1-sequence (DER tag and > length: 30 81 fc) above it. > The result is the root hash 0F42B6C261ACCF42AD55E005211ED1B168F373B9. > Please correct me if I did not understand the example correctly. Hmm, I think you misunderstood the generation of the reduced hash tree (I-D 3.2). The five lists in IXOS' hash tree are not five data object groups; they are five levels of the hash tree. The tree looks like this: ROOT | \ \ YYYY f79a 0000 | \ \ /|\ YYYY c414 3413 | \ \ /|\ /|\ YYYY cf18 6ba0 / | \ /|\ /|\ YYYY (c4a8) b837 46d8 / | \ / | \ / | \ 51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX data obj grp 1 data obj grp 2 data obj grp 3 > Why is the last hash value 00...00? A hash which just happens to be all > zeros by coincidence? Or does it have a special meaning? That's exactly because of 3.2.4. Since IXOS' tree contained something between 81 and 162 documents they had to include an additional (dummy) hash value (0000) to the last level of the tree to get a "complete" ternary hash tree. Regards, Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1BKPQtW065401; Sat, 11 Feb 2006 12:25:26 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k1BKPQ1P065400; Sat, 11 Feb 2006 12:25:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1BKPOAa065386 for ; Sat, 11 Feb 2006 12:25:24 -0800 (PST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 3181 invoked from network); 11 Feb 2006 20:27:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.1.10) by 0 with RC4-MD5 encrypted SMTP; 11 Feb 2006 20:27:28 -0000 Message-ID: <43EE4839.9050701@seccommerce.de> Date: Sat, 11 Feb 2006 21:25:29 +0100 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: LTANS: Examples of ERS data - cross checking of implementations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, first of all I would like to thank IXOS for posting an example of an ERS and I would like to add something to the discussion of Adrian Frei and Thomas Kunz. Thomas Kunz wrote: > The procedure how to concatenate and hash the values in the reduced > hashtree is decribed in section 3.3 of the I-D. > You concatenate the three values (51B1..., 5BD0..., 60BB...) in the > first list in ascending order an hash them with ripemd160. This hash > becomes member of the second list (B537..., 46D8...). Now you > concatenate these three hash values (the two in the list and the > calculated one) and hash them, etc. Continue this procedure until the > root hash is calculated. This root hash must correspond to the hashed > message in the timestamp. I was able to compute the root hash and verify the first timestamp this way. But I think the root hash has to be computed differently. The example contains the following hashes. I have noted all DER encoding bytes and named the data object groups A, B, C, D and E. 30 81 fc 30 42 (data object group A) 04 14 51b178b4a09592d425b70972ba448eb0221d39d9 04 14 5bd0247c9f86b4b1fad7500f61fcd9e622651ad2 04 14 60bbc5706949fc4d191771b9a7743416a340f7ee 30 2c (data object group B) 04 14 b837fbd61b1c82644fd196892cf9fb1ee16a2473 04 14 46d8fc303bed6cfa433e8f09146acc2f2c32a51c 30 2c (data object group C) 04 14 cf18dda21b8d71d7c43e11b603b3c0c309986bd8 04 14 6ba0a0bb6cf43cb7665b1876aba9db4f903256b1 30 2c (data object group D) 04 14 c414a00a8e579e49cec5baab06abb577a6effea3 04 14 3413e337a9dbfd820a321550ef0bf82270b5e845 30 2c (data object group E) 04 14 f79a6ca87a7c741cf40aebaaa8918055f85810ea 04 14 0000000000000000000000000000000000000000 I agree on the first step which is to compute the hash over (51B1..., 5BD0..., 60BB...). It's C4A84457CAF1F7CD675754ECE406C429DE0B059F. But why should it be inserted into data object group B? I think the next step should be to generate the hashes over over data object groups B, C, D and E without inserting anything. The resulting five hashes (one for each data object group) build the next higher list of hash values. I think this is meant by "This hash value h' must become member of the next higher list of hash values." Otherwise h' would become member of another list of hash values on the same level instead of the next higher level. Data object groups A, B, C, D and E are on the same level. Then the hash over the binary sorted five computed hashes is 06E1045012391C2DCE1F673E6917EE2239EB5EA7. Finally this hash alone is hashed again, because there is another ASN1-sequence (DER tag and length: 30 81 fc) above it. The result is the root hash 0F42B6C261ACCF42AD55E005211ED1B168F373B9. Please correct me if I did not understand the example correctly. Why is the last hash value 00...00? A hash which just happens to be all zeros by coincidence? Or does it have a special meaning? Another question maybe for the authors of the draft. What is meant by 3.2.4 "If additional hash values are needed, e.g. so that all nodes have the same number of children, any data may be hashed using H and used.)" Why could it be important that all nodes have the same number of children? Kind regards Tilo Kienitz -- SecCommerce GmbH Hamburg Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1ANkdg9085161; Fri, 10 Feb 2006 15:46: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 k1ANkd1n085160; Fri, 10 Feb 2006 15:46:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from advantage-security.com ([201.148.139.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1ANkcZk085154 for ; Fri, 10 Feb 2006 15:46:38 -0800 (PST) (envelope-from gwerner@advantage-security.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: comments on draft-ietf-ltans-pki-notareqs-03.txt Date: Fri, 10 Feb 2006 17:46:31 -0600 Message-ID: <1815FE0A4A30A44BA2F9E367E1B00AB130A450@corporativo.production.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-ltans-pki-notareqs-03.txt Thread-Index: AcYtUsOrmebO7tOLTbKwELOR1y4rVgAGsmEgAEuCGjA= From: "Greg Werner" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k1ANkdZk085155 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding: 6. Operational Considerations Data validation and certification services may have strong performance and scalability requirements. A certification service must be able to work efficiently even for large amounts of data objects and requests. In order to limit expenses and to achieve high performance, the involvement of other trusted third parties should be minimized. I´m not sure I understand the second paragraph. Could someone please explain, it sounds as if the recommendation is to "limit expenses" however some companies may which to pay more for certain services to circumvent some possible risks (whatever those may be). It sounds like the recommendation is out of scope because this is a cost/benefit and ROI analysis that each company should do. Greg Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k19EP6X3039500; Thu, 9 Feb 2006 06:25:06 -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 k19EP64q039497; Thu, 9 Feb 2006 06:25:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k19EP4h4039446 for ; Thu, 9 Feb 2006 06:25:04 -0800 (PST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.11] (moors.yandk.org [192.168.1.11]) by burrens.yandk.org (Postfix) with ESMTP id 8296813CF6 for ; Thu, 9 Feb 2006 09:25:03 -0500 (EST) Message-ID: <43EB5196.3050303@yhetheridge.org> Date: Thu, 09 Feb 2006 09:28:38 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20060111) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: comments on draft-ietf-ltans-ers-05.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I believe there are still some inconsistencies in the implied definition of timestamp in various points of the draft. For example, the implied definition seems to be well-stated in the last paragraph of Section 3.2 on p. 11. The last note, "[ANSX995], [I180142] and [I180143] specify irrefutably verifiable time-stamps which do not depend on certificates, CRLS, or OCSP-Responses", seems to be quite adequately stated. However, the definition of Time-Stamp in Section 1.3 on p. 5 states it as "A signed confirmation generated by a Time Stamping Authority (TSA)". I believe a more consistent statement would say it as "A cryptographically secure confirmation generated by a Time Stamping Authority (TSA)". The inconsistency persists in the last paragraph of Section 3.1 on p. 9. The statement, "Other types of time-stamp might be used, if they contain time data, time-stamped data and a signature from the TSA of these data" should for consistency's sake read as "Other types of time-stamp might be used, if they contain time data, time-stamped data and a cryptographically secure confirmation from the TSA of these data". Thank you, yhe Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k19BsVHC018349; Thu, 9 Feb 2006 03:54: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 k19BsVpK018348; Thu, 9 Feb 2006 03:54:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k19BsUto018329 for ; Thu, 9 Feb 2006 03:54:30 -0800 (PST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt Date: Thu, 9 Feb 2006 04:00:51 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C879012A18A6@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-ltans-pki-retention-00.txt thread-index: AcYtUsOrmebO7tOLTbKwELOR1y4rVgAGsmEg From: "Carl Wallace" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k19BsUto018343 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > - ERS is not the only service using certificates; we are here > talking about certificate management, which includes all kind > of certficates within an organisation > - these are mainly policy oriented issues, e.g. the choice of > a specific certificate also includes a set of very complex > rules (CPS, Signature laws, inhouse rules et.al.) which > define the basics such as keeping the necessary verification > or revocation data The choice of which certificate to use for a particular operation is made before the events being addressed by LTANS. The ERS/SCVP and retention drafts aim to preserve certificates so these decisions can be independent of the preservation of signed data. > - how to keep this information is policy dependent and must > be managed by the organisation: --> risk management Agreed. > So the first thing will be to define the adequate > certificate/PKI/ policy for your needs and then decide abou > the necessary cert. > management structure. Legally spoken: it is my responsibility > to store the necessary verification data, how I will do that, > should remain in my responsibility. Having said this, I do > not think this should be part of the LTANS standard. Do you think LTANS specs can play a role here, i.e., ERS? If not, what specs apply? The retention spec defines an optional binding between certs and evidence records that enables you to fulfill your responsibility of preserving the necessary verification data. It's not clear to me that certs must be preserved as part of a signed data object especially since not doing this has significant benefit, e.g., storage savings and decoupling trust anchors from signed data. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k198SEoH091294; Thu, 9 Feb 2006 00:28:14 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k198SE1w091293; Thu, 9 Feb 2006 00:28:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ms8.webland.ch (ms8.webland.ch [194.209.78.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k198SCr2091276 for ; Thu, 9 Feb 2006 00:28:13 -0800 (PST) (envelope-from bruno@wildhaber.com) Received: from [192.168.1.41] ([83.77.221.93]) by ms8.webland.ch (Webland.MailServer.v.8.3.5) with ASMTP id NKL61905; Thu, 9 Feb 2006 09:28:05 +0100 In-Reply-To: <82D5657AE1F54347A734BDD33637C87901252CC1@EXVS01.ex.dslextreme.net> References: <82D5657AE1F54347A734BDD33637C87901252CC1@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CE877BA-017B-4181-8D86-DBF814BFA05E@wildhaber.com> Cc: "Tobias Gondrom" , Content-Transfer-Encoding: 7bit From: Bruno Wildhaber Subject: Re: comments on draft-ietf-ltans-pki-retention-00.txt Date: Thu, 9 Feb 2006 09:28:02 +0100 To: Carl Wallace X-Mailer: Apple Mail (2.746.2) X-WLGenuine-Reason: [FILTER]=Local or Smtp Auth Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi everybody firstly thanks to all who contributed their time to the very valuable ERS standardization work! Here are some thoughts abot the need for defining rules for retention of PKI artifacts - ERS is not the only service using certificates; we are here talking about certificate management, which includes all kind of certficates within an organisation - these are mainly policy oriented issues, e.g. the choice of a specific certificate also includes a set of very complex rules (CPS, Signature laws, inhouse rules et.al.) which define the basics such as keeping the necessary verification or revocation data - how to keep this information is policy dependent and must be managed by the organisation: --> risk management So the first thing will be to define the adequate certificate/PKI/ policy for your needs and then decide abou the necessary cert. management structure. Legally spoken: it is my responsibility to store the necessary verification data, how I will do that, should remain in my responsibility. Having said this, I do not think this should be part of the LTANS standard. Bruno Am 08.02.2006 um 00:24 schrieb Carl Wallace: > > A few responses inline... > > >>> From what I experienced today, the place where signed documents >> (documents and their signatures) are stored, usually also >> need to be able to at least store the list of certificates >> and OCSP-response or CRL. >> (as long as a user can not rely on an infrastructure besides >> the local archiving system for providing this data, he >> usually wants to store everything in one place so that he >> later has all the data available). > > The local archiving system could still maintain the data, just not > over > and over again for each data item. The PKI artifacts could be stored > separately and preserved once by the system maintaining the data. > >> Having this said I can see three approaches to store the >> necessary data with the signed documents: >> 1. to store the certificates (up to the root) and the >> OCSP-response or CRL inside the signed document or signature >> using RFC3126 > > This assumes the one doing the storing shares common trust anchors > with > all relying parties. If the data is generally available for > consumption > by many folks, such as in environments with bridged PKIs, this > assumption may not hold. > >> 2. to store the necessary verification data >> (certificates and OCSP-responses and/or CRL) in the same >> storage system (and also applying Evidence Records to ensure >> the integrity of them. > > This is possible using the mechanisms in the retention draft. > >> 3. To store with the document only a reference to the >> verification data (certificates and OCSP-responses and/or >> CRL), on another system that applies the Evidence Record >> technique. This could be provided by e.g. a trust center or >> better a redundant net of trust centers, each of them also >> providing evidence for the historical date of the others. >> (that way if one gets lost there are still some left....) > > This is also possible using the mechanisms in the retention draft. > >> Until such services are available I would recommend users to >> store all necessary verification data directly in the signed >> document: this costs more storage space but it makes sure >> that the complete verification data is directly linked to the >> signed document. > > In addition to storage space costs, it limits the verification > possibilities beyond what is possible when verifying the data at > generation time. > >> Tobias >> >> >> Wildhaber Consulting Dr. Bruno Wildhaber, CISA/CISM Seestrasse 100 8610 Uster Schweiz Tel. +41 44 826 21 21 Fax. +41 44 826 21 22 bruno@wildhaber.com www.wildhaber.com Daten recht im Griff? 1. Nationale Records Management Konferenz: Der Compliance Event 2006 http://www.aufbewahrung.ch/deutsch/pages/rm_conference.htm The IT Governance Network www.itgovernance.com Kompetenzzentrum Records Management www.aufbewahrung.ch Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k18No6gZ021244; Wed, 8 Feb 2006 15:50:06 -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 k18No6Cv021243; Wed, 8 Feb 2006 15:50:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k18No5cY021229 for ; Wed, 8 Feb 2006 15:50:06 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F6z4T-0007OL-HW; Wed, 08 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-05.txt Message-Id: Date: Wed, 08 Feb 2006 18:50:01 -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, et al. Filename : draft-ietf-ltans-ers-05.txt Pages : 26 Date : 2006-2-8 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-05.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-05.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: <2006-2-8173246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-8173246.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17NIIxU021053; Tue, 7 Feb 2006 15:18:18 -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 k17NIIEQ021052; Tue, 7 Feb 2006 15:18:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17NIHqW021007 for ; Tue, 7 Feb 2006 15:18:17 -0800 (PST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comments on draft-ietf-ltans-pki-retention-00.txt Date: Tue, 7 Feb 2006 15:24:29 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87901252CC1@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-ltans-pki-retention-00.txt thread-index: AcYccYvMQAdzyJPhRC2i3EDgL+1gkgPqMNBwAAho0BA= From: "Carl Wallace" To: "Tobias Gondrom" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k17NIHqW021025 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A few responses inline... > >From what I experienced today, the place where signed documents > (documents and their signatures) are stored, usually also > need to be able to at least store the list of certificates > and OCSP-response or CRL. > (as long as a user can not rely on an infrastructure besides > the local archiving system for providing this data, he > usually wants to store everything in one place so that he > later has all the data available). The local archiving system could still maintain the data, just not over and over again for each data item. The PKI artifacts could be stored separately and preserved once by the system maintaining the data. > Having this said I can see three approaches to store the > necessary data with the signed documents: > 1. to store the certificates (up to the root) and the > OCSP-response or CRL inside the signed document or signature > using RFC3126 This assumes the one doing the storing shares common trust anchors with all relying parties. If the data is generally available for consumption by many folks, such as in environments with bridged PKIs, this assumption may not hold. > 2. to store the necessary verification data > (certificates and OCSP-responses and/or CRL) in the same > storage system (and also applying Evidence Records to ensure > the integrity of them. This is possible using the mechanisms in the retention draft. > 3. To store with the document only a reference to the > verification data (certificates and OCSP-responses and/or > CRL), on another system that applies the Evidence Record > technique. This could be provided by e.g. a trust center or > better a redundant net of trust centers, each of them also > providing evidence for the historical date of the others. > (that way if one gets lost there are still some left....) This is also possible using the mechanisms in the retention draft. > Until such services are available I would recommend users to > store all necessary verification data directly in the signed > document: this costs more storage space but it makes sure > that the complete verification data is directly linked to the > signed document. In addition to storage space costs, it limits the verification possibilities beyond what is possible when verifying the data at generation time. > Tobias > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17JOeLi088390; Tue, 7 Feb 2006 11:24: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 k17JOenb088389; Tue, 7 Feb 2006 11:24:40 -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 (mucmx02.ixos.de [149.235.128.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17JOcCC088382 for ; Tue, 7 Feb 2006 11:24:39 -0800 (PST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k17JOaLt028615 for ; Tue, 7 Feb 2006 20:24:37 +0100 (MET) Content-class: urn:content-classes:message Subject: comments on draft-ietf-ltans-pki-retention-00.txt Date: Tue, 7 Feb 2006 20:24:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <3C1BE8610E44734499EF92FB35F5B07001938A93@MUCXGC1.opentext.net> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-ltans-pki-retention-00.txt Thread-Index: AcYccYvMQAdzyJPhRC2i3EDgL+1gkgPqMNBw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k17JOdCC088384 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, thanks for posting the pki-retention draft. >From what I understood I like the data structure that would enable (trusted?) third parties to provide such data as a service for the trust centers in the future. >From what I experienced today, the place where signed documents (documents and their signatures) are stored, usually also need to be able to at least store the list of certificates and OCSP-response or CRL. (as long as a user can not rely on an infrastructure besides the local archiving system for providing this data, he usually wants to store everything in one place so that he later has all the data available). Having this said I can see three approaches to store the necessary data with the signed documents: 1. to store the certificates (up to the root) and the OCSP-response or CRL inside the signed document or signature using RFC3126 2. to store the necessary verification data (certificates and OCSP-responses and/or CRL) in the same storage system (and also applying Evidence Records to ensure the integrity of them. 3. To store with the document only a reference to the verification data (certificates and OCSP-responses and/or CRL), on another system that applies the Evidence Record technique. This could be provided by e.g. a trust center or better a redundant net of trust centers, each of them also providing evidence for the historical date of the others. (that way if one gets lost there are still some left....) Until such services are available I would recommend users to store all necessary verification data directly in the signed document: this costs more storage space but it makes sure that the complete verification data is directly linked to the signed document. Tobias Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17E56HS048648; Tue, 7 Feb 2006 06:05:06 -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 k17E56wr048647; Tue, 7 Feb 2006 06:05:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17E55sY048638 for ; Tue, 7 Feb 2006 06:05:05 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id k17E53t9003451 for ; Tue, 7 Feb 2006 09:05:03 -0500 From: "santosh chokhani" To: Subject: RE: LTANS-ERS: Verification and data groups Date: Tue, 7 Feb 2006 09:04:58 -0500 Message-ID: <001101c62bef$7dd49620$a900a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOgAA1PRMAAFcvhQAAIJqBwAACWpqAAAhWPIA== In-Reply-To: <200602071301.k17D1LsN038464@above.proper.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That will be fine. I am not as conversant in it, but will try to slog through it. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Tuesday, February 07, 2006 8:09 AM To: ietf-ltans@imc.org Subject: RE: LTANS-ERS: Verification and data groups Basic idea was presented, I think at paris meeting by Peter (Sylvester). We are working with XML currently (it is a version 0.9 albeit in production already...). Will that do? > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: 7. februar 2006 13:55 > To: A. Jerman Blazic; ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > Aleksej, > > Can you point me to or send me the ASN.1 for your proposal? > > Thanks. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Tuesday, February 07, 2006 4:34 AM > To: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > Santosh > > Preserving of archive data is indeed performed as maintenance > of archive objects. Such objects are composed (or collected) > as they enter the archive and they in general consist of: > > - archive data itself > - metadata or any associated data (may come in flavor of > digital signatures, managerial data, etc...) > - preservation/conservation data > > The last element of the logical structure is what we try to > achieve with the ERS (but not only ERS!). Now, if > preservation is actually handling with archive objects the > preservation data must be an individual part of the object. > It really does not matter how the evidence information is > generated or collected, by grouping or not, the matter is > only that the evidence information as a part of the > preservation data and must always be decoupled for any common > evidence structure as the hash trees are. The ERS > specification as it is, lacks or redirects the focus on hash > trees and their generation. It solves the problem of > "degrouping" but statements such as retimestamping of the > whole hash tree are IMO wrong. There is no need to > retimestamp the whole hash structure but perform the same > type of operation on existing archive objects regardless of > the fact that they are in the group or not (you may always > build a new group form the elements of two or more groups). > Grouping is just another mechanism which may be used or not. > The focus is really on the archive objects as they carry > evidence information individually. > > Another problem of the current ERS specification are digest > algorithms. > If I > remember correctly the specification proposes the use of the > same algorithm through the hash structure, which is improper > approach. It is true that the chain is as strong as its > weakest element, but as we already have TAS requirement such > as transfer of archive data and its evidence from one archive > to another, sustaining the requirement of consistent hash > structure is just impossible. > > What I propose is a better definition of the archival process > and the data structures to be defined by the LTANS. I tried > to summarize such ideas in the LTAP specification but am > afraid this is not the right document. > > Aleksej > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: 6. februar 2006 23:39 > > To: A. Jerman Blazic; ietf-ltans@imc.org > > Subject: RE: LTANS-ERS: Verification and data groups > > > > Aleksej, > > > > If you proposing to replace the data groups and hash trees with the > > archive objects as simplification, I am in full agreement. > > > > I am not sure this complexity is that useful or needed. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > > Sent: Monday, February 06, 2006 11:15 AM > > To: ietf-ltans@imc.org > > Subject: RE: LTANS-ERS: Verification and data groups > > > > > > > Of course it is up to the client to decide which data > > object should be > > > pooled into a group and which not. But a verification > > component should > > > be able to unambiguously decide if a document group is > complete or > > > not. > > > With the structure I sketched, verification of a single > > data object is > > > still possible, but additionally it can be verified if > the group is > > > complete. > > > > Hmm, I could hardly agree with this, as the ERS is meant > for providing > > evidence information of an object and not group of objects. The > > logical (or any other reason for) grouping is done by the > supportive > > infrastructure, e.g. data management (or DMS if you want). IMO the > > grouping is proposed purely as the answer to scalability > issues that > > may arise when handling significant amount of data. Basically the > > evidence creation process should perform necessary actions to group > > data objects in a way that a single evidence is enough. > Instantly the > > objects archived must be degrouped and no particular information is > > needed to identify the group members. This is out of the scope and > > that is exactly what the ERS does. > > > > Aleksej > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17D1Mqg038475; Tue, 7 Feb 2006 05:01: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 k17D1MJN038474; Tue, 7 Feb 2006 05:01:22 -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.9) with SMTP id k17D1LsN038464 for ; Tue, 7 Feb 2006 05:01:21 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200602071301.k17D1LsN038464@above.proper.com> Received: (qmail 1900 invoked from network); 7 Feb 2006 13:01:18 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 7 Feb 2006 13:01:18 -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 01867-01 for ; Tue, 7 Feb 2006 14:01:17 +0100 (CET) Received: (qmail 1896 invoked from network); 7 Feb 2006 13:01:16 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 7 Feb 2006 13:01:16 -0000 From: "A. Jerman Blazic" To: Subject: RE: LTANS-ERS: Verification and data groups Date: Tue, 7 Feb 2006 14:08:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <82D5657AE1F54347A734BDD33637C8790120A3AD@EXVS01.ex.dslextreme.net> thread-index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOgAA1PRMAAFcvhQAAIJqBwAACWpqA= X-Virus-Scanned: amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Basic idea was presented, I think at paris meeting by Peter (Sylvester). We are working with XML currently (it is a version 0.9 albeit in production already...). Will that do? > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: 7. februar 2006 13:55 > To: A. Jerman Blazic; ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > Aleksej, > > Can you point me to or send me the ASN.1 for your proposal? > > Thanks. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Tuesday, February 07, 2006 4:34 AM > To: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > Santosh > > Preserving of archive data is indeed performed as maintenance > of archive objects. Such objects are composed (or collected) > as they enter the archive and they in general consist of: > > - archive data itself > - metadata or any associated data (may come in flavor of > digital signatures, managerial data, etc...) > - preservation/conservation data > > The last element of the logical structure is what we try to > achieve with the ERS (but not only ERS!). Now, if > preservation is actually handling with archive objects the > preservation data must be an individual part of the object. > It really does not matter how the evidence information is > generated or collected, by grouping or not, the matter is > only that the evidence information as a part of the > preservation data and must always be decoupled for any common > evidence structure as the hash trees are. The ERS > specification as it is, lacks or redirects the focus on hash > trees and their generation. It solves the problem of > "degrouping" but statements such as retimestamping of the > whole hash tree are IMO wrong. There is no need to > retimestamp the whole hash structure but perform the same > type of operation on existing archive objects regardless of > the fact that they are in the group or not (you may always > build a new group form the elements of two or more groups). > Grouping is just another mechanism which may be used or not. > The focus is really on the archive objects as they carry > evidence information individually. > > Another problem of the current ERS specification are digest > algorithms. > If I > remember correctly the specification proposes the use of the > same algorithm through the hash structure, which is improper > approach. It is true that the chain is as strong as its > weakest element, but as we already have TAS requirement such > as transfer of archive data and its evidence from one archive > to another, sustaining the requirement of consistent hash > structure is just impossible. > > What I propose is a better definition of the archival process > and the data structures to be defined by the LTANS. I tried > to summarize such ideas in the LTAP specification but am > afraid this is not the right document. > > Aleksej > > > -----Original Message----- > > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > > Sent: 6. februar 2006 23:39 > > To: A. Jerman Blazic; ietf-ltans@imc.org > > Subject: RE: LTANS-ERS: Verification and data groups > > > > Aleksej, > > > > If you proposing to replace the data groups and hash trees with the > > archive objects as simplification, I am in full agreement. > > > > I am not sure this complexity is that useful or needed. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > > Sent: Monday, February 06, 2006 11:15 AM > > To: ietf-ltans@imc.org > > Subject: RE: LTANS-ERS: Verification and data groups > > > > > > > Of course it is up to the client to decide which data > > object should be > > > pooled into a group and which not. But a verification > > component should > > > be able to unambiguously decide if a document group is > complete or > > > not. > > > With the structure I sketched, verification of a single > > data object is > > > still possible, but additionally it can be verified if > the group is > > > complete. > > > > Hmm, I could hardly agree with this, as the ERS is meant > for providing > > evidence information of an object and not group of objects. The > > logical (or any other reason for) grouping is done by the > supportive > > infrastructure, e.g. data management (or DMS if you want). IMO the > > grouping is proposed purely as the answer to scalability > issues that > > may arise when handling significant amount of data. Basically the > > evidence creation process should perform necessary actions to group > > data objects in a way that a single evidence is enough. > Instantly the > > objects archived must be degrouped and no particular information is > > needed to identify the group members. This is out of the scope and > > that is exactly what the ERS does. > > > > Aleksej > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17CmhM8037173; Tue, 7 Feb 2006 04:48:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k17Cmh15037172; Tue, 7 Feb 2006 04:48:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17CmgcD037165 for ; Tue, 7 Feb 2006 04:48:42 -0800 (PST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LTANS-ERS: Verification and data groups Date: Tue, 7 Feb 2006 04:54:53 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C8790120A3AD@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS-ERS: Verification and data groups thread-index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOgAA1PRMAAFcvhQAAIJqBw From: "Santosh Chokhani" To: "A. Jerman Blazic" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k17CmhcD037167 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej, Can you point me to or send me the ASN.1 for your proposal? Thanks. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Tuesday, February 07, 2006 4:34 AM To: ietf-ltans@imc.org Subject: RE: LTANS-ERS: Verification and data groups Santosh Preserving of archive data is indeed performed as maintenance of archive objects. Such objects are composed (or collected) as they enter the archive and they in general consist of: - archive data itself - metadata or any associated data (may come in flavor of digital signatures, managerial data, etc...) - preservation/conservation data The last element of the logical structure is what we try to achieve with the ERS (but not only ERS!). Now, if preservation is actually handling with archive objects the preservation data must be an individual part of the object. It really does not matter how the evidence information is generated or collected, by grouping or not, the matter is only that the evidence information as a part of the preservation data and must always be decoupled for any common evidence structure as the hash trees are. The ERS specification as it is, lacks or redirects the focus on hash trees and their generation. It solves the problem of "degrouping" but statements such as retimestamping of the whole hash tree are IMO wrong. There is no need to retimestamp the whole hash structure but perform the same type of operation on existing archive objects regardless of the fact that they are in the group or not (you may always build a new group form the elements of two or more groups). Grouping is just another mechanism which may be used or not. The focus is really on the archive objects as they carry evidence information individually. Another problem of the current ERS specification are digest algorithms. If I remember correctly the specification proposes the use of the same algorithm through the hash structure, which is improper approach. It is true that the chain is as strong as its weakest element, but as we already have TAS requirement such as transfer of archive data and its evidence from one archive to another, sustaining the requirement of consistent hash structure is just impossible. What I propose is a better definition of the archival process and the data structures to be defined by the LTANS. I tried to summarize such ideas in the LTAP specification but am afraid this is not the right document. Aleksej > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: 6. februar 2006 23:39 > To: A. Jerman Blazic; ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > Aleksej, > > If you proposing to replace the data groups and hash trees > with the archive objects as simplification, I am in full agreement. > > I am not sure this complexity is that useful or needed. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Monday, February 06, 2006 11:15 AM > To: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > > Of course it is up to the client to decide which data > object should be > > pooled into a group and which not. But a verification > component should > > be able to unambiguously decide if a document group is complete or > > not. > > With the structure I sketched, verification of a single > data object is > > still possible, but additionally it can be verified if the group is > > complete. > > Hmm, I could hardly agree with this, as the ERS is meant for > providing evidence information of an object and not group of > objects. The logical (or any other reason for) grouping is > done by the supportive infrastructure, e.g. data management > (or DMS if you want). IMO the grouping is proposed purely as > the answer to scalability issues that may arise when handling > significant amount of data. Basically the evidence creation > process should perform necessary actions to group data > objects in a way that a single evidence is enough. Instantly > the objects archived must be degrouped and no particular > information is needed to identify the group members. This is > out of the scope and that is exactly what the ERS does. > > Aleksej > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k179Ql3P006852; Tue, 7 Feb 2006 01:26: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 k179Qlse006851; Tue, 7 Feb 2006 01:26:47 -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.9) with SMTP id k179QjUE006839 for ; Tue, 7 Feb 2006 01:26:46 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200602070926.k179QjUE006839@above.proper.com> Received: (qmail 22729 invoked from network); 7 Feb 2006 09:26:43 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 7 Feb 2006 09:26:43 -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 22497-08 for ; Tue, 7 Feb 2006 10:26:42 +0100 (CET) Received: (qmail 22721 invoked from network); 7 Feb 2006 09:26:42 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 7 Feb 2006 09:26:42 -0000 From: "A. Jerman Blazic" To: Subject: RE: LTANS-ERS: Verification and data groups Date: Tue, 7 Feb 2006 10:33:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOgAA1PRMAAFcvhQA== In-Reply-To: <82D5657AE1F54347A734BDD33637C87901209EC1@EXVS01.ex.dslextreme.net> X-Virus-Scanned: amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh Preserving of archive data is indeed performed as maintenance of archive objects. Such objects are composed (or collected) as they enter the archive and they in general consist of: - archive data itself - metadata or any associated data (may come in flavor of digital signatures, managerial data, etc...) - preservation/conservation data The last element of the logical structure is what we try to achieve with the ERS (but not only ERS!). Now, if preservation is actually handling with archive objects the preservation data must be an individual part of the object. It really does not matter how the evidence information is generated or collected, by grouping or not, the matter is only that the evidence information as a part of the preservation data and must always be decoupled for any common evidence structure as the hash trees are. The ERS specification as it is, lacks or redirects the focus on hash trees and their generation. It solves the problem of "degrouping" but statements such as retimestamping of the whole hash tree are IMO wrong. There is no need to retimestamp the whole hash structure but perform the same type of operation on existing archive objects regardless of the fact that they are in the group or not (you may always build a new group form the elements of two or more groups). Grouping is just another mechanism which may be used or not. The focus is really on the archive objects as they carry evidence information individually. Another problem of the current ERS specification are digest algorithms. If I remember correctly the specification proposes the use of the same algorithm through the hash structure, which is improper approach. It is true that the chain is as strong as its weakest element, but as we already have TAS requirement such as transfer of archive data and its evidence from one archive to another, sustaining the requirement of consistent hash structure is just impossible. What I propose is a better definition of the archival process and the data structures to be defined by the LTANS. I tried to summarize such ideas in the LTAP specification but am afraid this is not the right document. Aleksej > -----Original Message----- > From: Santosh Chokhani [mailto:chokhani@orionsec.com] > Sent: 6. februar 2006 23:39 > To: A. Jerman Blazic; ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > Aleksej, > > If you proposing to replace the data groups and hash trees > with the archive objects as simplification, I am in full agreement. > > I am not sure this complexity is that useful or needed. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Monday, February 06, 2006 11:15 AM > To: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > > Of course it is up to the client to decide which data > object should be > > pooled into a group and which not. But a verification > component should > > be able to unambiguously decide if a document group is complete or > > not. > > With the structure I sketched, verification of a single > data object is > > still possible, but additionally it can be verified if the group is > > complete. > > Hmm, I could hardly agree with this, as the ERS is meant for > providing evidence information of an object and not group of > objects. The logical (or any other reason for) grouping is > done by the supportive infrastructure, e.g. data management > (or DMS if you want). IMO the grouping is proposed purely as > the answer to scalability issues that may arise when handling > significant amount of data. Basically the evidence creation > process should perform necessary actions to group data > objects in a way that a single evidence is enough. Instantly > the objects archived must be degrouped and no particular > information is needed to identify the group members. This is > out of the scope and that is exactly what the ERS does. > > Aleksej > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k16MWRxc017652; Mon, 6 Feb 2006 14:32:27 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k16MWR0C017651; Mon, 6 Feb 2006 14:32:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k16MWRee017637 for ; Mon, 6 Feb 2006 14:32:27 -0800 (PST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LTANS-ERS: Verification and data groups Date: Mon, 6 Feb 2006 14:38:33 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87901209EC1@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS-ERS: Verification and data groups thread-index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOgAA1PRMA= From: "Santosh Chokhani" To: "A. Jerman Blazic" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k16MWRee017646 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej, If you proposing to replace the data groups and hash trees with the archive objects as simplification, I am in full agreement. I am not sure this complexity is that useful or needed. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Monday, February 06, 2006 11:15 AM To: ietf-ltans@imc.org Subject: RE: LTANS-ERS: Verification and data groups > Of course it is up to the client to decide which data object > should be pooled into a group and which not. But a > verification component should be able to unambiguously decide > if a document group is complete or not. > With the structure I sketched, verification of a single data > object is still possible, but additionally it can be verified > if the group is complete. Hmm, I could hardly agree with this, as the ERS is meant for providing evidence information of an object and not group of objects. The logical (or any other reason for) grouping is done by the supportive infrastructure, e.g. data management (or DMS if you want). IMO the grouping is proposed purely as the answer to scalability issues that may arise when handling significant amount of data. Basically the evidence creation process should perform necessary actions to group data objects in a way that a single evidence is enough. Instantly the objects archived must be degrouped and no particular information is needed to identify the group members. This is out of the scope and that is exactly what the ERS does. Aleksej Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k16G8NOU050765; Mon, 6 Feb 2006 08:08: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 k16G8Nsv050764; Mon, 6 Feb 2006 08:08:23 -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.9) with SMTP id k16G8JTX050757 for ; Mon, 6 Feb 2006 08:08:21 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200602061608.k16G8JTX050757@above.proper.com> Received: (qmail 12468 invoked from network); 6 Feb 2006 16:08:17 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 6 Feb 2006 16:08:17 -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 11922-08 for ; Mon, 6 Feb 2006 17:08:16 +0100 (CET) Received: (qmail 12464 invoked from network); 6 Feb 2006 16:08:16 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 6 Feb 2006 16:08:16 -0000 From: "A. Jerman Blazic" To: Subject: RE: LTANS-ERS: Verification and data groups Date: Mon, 6 Feb 2006 17:15:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYrAfHmgNdObpscQ8+SlDwgqpJPlQANcGOg In-Reply-To: <43E71938.30105@sit.fraunhofer.de> X-Virus-Scanned: amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Of course it is up to the client to decide which data object > should be pooled into a group and which not. But a > verification component should be able to unambiguously decide > if a document group is complete or not. > With the structure I sketched, verification of a single data > object is still possible, but additionally it can be verified > if the group is complete. Hmm, I could hardly agree with this, as the ERS is meant for providing evidence information of an object and not group of objects. The logical (or any other reason for) grouping is done by the supportive infrastructure, e.g. data management (or DMS if you want). IMO the grouping is proposed purely as the answer to scalability issues that may arise when handling significant amount of data. Basically the evidence creation process should perform necessary actions to group data objects in a way that a single evidence is enough. Instantly the objects archived must be degrouped and no particular information is needed to identify the group members. This is out of the scope and that is exactly what the ERS does. Aleksej Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k169dmdP096386; Mon, 6 Feb 2006 01:39:48 -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 k169dmtg096385; Mon, 6 Feb 2006 01:39:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k169dktO096378 for ; Mon, 6 Feb 2006 01:39:47 -0800 (PST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.87.208] (sitp144.sit.fraunhofer.de [141.12.68.144]) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k169dSH3005768 for ; Mon, 6 Feb 2006 10:39:39 +0100 Message-ID: <43E71938.30105@sit.fraunhofer.de> Date: Mon, 06 Feb 2006 10:39:04 +0100 From: Thomas Kunz User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: LTANS-ERS: Verification and data groups References: <1815FE0A4A30A44BA2F9E367E1B00AB130A169@corporativo.production.local> In-Reply-To: <1815FE0A4A30A44BA2F9E367E1B00AB130A169@corporativo.production.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Of course it is up to the client to decide which data object should be pooled into a group and which not. But a verification component should be able to unambiguously decide if a document group is complete or not. With the structure I sketched, verification of a single data object is still possible, but additionally it can be verified if the group is complete. Regards, Thomas Greg Werner wrote: > In Mexico several banks, such as BBVA and HSBC, for example, have expressed interest in using a system that allows them to batch several documents into one group and segregate other documents, such as sensitive contracts, as single objects. As Jerman states below their reason to count on a system to verify single objects will depend on their specific needs, in this case it would be to mitigate legal risks. > > Regards, > > Greg Werner CISSP > Advantage Security > Tel. +52 55 5081 4366 > > -----Mensaje original----- > De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] En nombre de A. Jerman Blazic > Enviado el: viernes, 03 de febrero de 2006 7:26 > Para: 'Carl Wallace'; 'Thomas Kunz'; 'Susanne Okunick' > CC: ietf-ltans@imc.org > Asunto: RE: LTANS-ERS: Verification and data groups > > > That is correct. It is up to the client to decide which data should be > grouped or not and this is included in the LTAP specification. Please bare > in mind that grouping can happen for whatever reason: logically, > semantically or any particular reason defined by a client (e.g. data > accompanied with the meta data). However, verification of a single object > MUST be possible at any time. Otherwise a service might hit scalability and > confidentiality problems (imagine a case focused on specific document to be > presented to the court and a case when such document is a group member...). > > >>-----Original Message----- >>From: owner-ietf-ltans@mail.imc.org >>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace >>Sent: 3. februar 2006 13:00 >>To: Thomas Kunz; Susanne Okunick >>Cc: ietf-ltans@imc.org >>Subject: RE: LTANS-ERS: Verification and data groups >> >> >>If I recall correctly, this was to have been a feature of >>LTAP, i.e., at submission time a client could request that >>the data being submitted not be lumped into a larger >>grouping. This is a different than what you've suggested but >>achieves a similar end. If LTAP is foregone in favor of a >>binding to an existing protocol, like WebDAV, or >>directly-managed ERS structures, like in the ERS/SCVP draft >>where the SCVP server performs all of the maintenance, then >>the sort of structure you propose makes more sense to meet >>the grouping requirement. I'm not sure it's a good idea to >>verify an evidence record without verifying each document in >>the group. >> >> >>>-----Original Message----- >>>From: owner-ietf-ltans@mail.imc.org >>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>>Sent: Friday, February 03, 2006 3:15 AM >>>To: Susanne Okunick >>>Cc: ietf-ltans@imc.org >>>Subject: Re: LTANS-ERS: Verification and data groups >>> >>> >>>Hello, >>> >>>I agree with Susanne. A solution could be to change the ASN.1 >>>structure of the ArchiveTimestamp. The hash values of the data >>>object(s) could be stored in a separate sequence of octet >> >>strings and >> >>>the first list of the reduced hashtree only holds the hash >> >>values of >> >>>the siblings of the data object node. So the size of the >> >>data object >> >>>group can unambiguously determined. >>>Perhaps the authors of the draft can give an opinion to >> >>that problem? >> >>>Best regards, >>>Thomas >>> >>> >>>Susanne Okunick wrote: >>> >>>>Hello, >>>> >>>>At the verification of evidence records I get into difficulty. I >>>>think, sometimes the verification for data groups is not >>> >>>practicable! >>> >>>>For data groups consisting of more than one documents the >> >>following >> >>>>points have to be checked (compare example in the draft; >>> >>>page 10,11): >>> >>>>a) check whether the hash value of each data object is within the >>>>first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( >>> >>>h2b,h2c,h2a) >>> >>>>b) check whether the document group is complete. That >>> >>>means: All data >>> >>>>objects have to be available at the time of verification >>> >>>(d2a,d2b,d2c). >>> >>>>If a data group consits of five documents, I will need all five >>>>documents for the entire successfull verification. >>>> >>>>The first sequence of every reduced binary hashtree >> >>consists of *at >> >>>>least* two hash values. >>>>This is for 1) one data object or 2) a data group consisting of >>>>exactly two data objects! >>>>My question: How to identify the right case? >>>> >>>>Assuming the following simple reduced binary hashtree: >>>>[[h1a,h1b][h2][h3]] >>>> >>>>For verification you have to calculate the root of hash (h123): >>>>h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary >>>>sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary >>> >>>sorted and >>> >>>>concatenated (h1a, h1b) ) | h2 h1a | h1b >>>> >>>>Now there are two possibilities: >>>>1) h1a and h1b don't build a data group => for whole >>> >>>verification you >>> >>>>need the data object "d1a" to show that the data object's >>> >>>hash value >>> >>>>is "h1a" >>>>2) h1a and h1b are data objects of one data group => for >>> >>>verification >>> >>>>both data objects d1a and d1b must be available and you >>> >>>have to show >>> >>>>that both hash values are correctly computed >>>> >>>>Thus you never know (in case of having two hash values in >> >>the first >> >>>>sequence of reduced binary hashtree), whether one or two >> >>documents >> >>>>needed for verification. >>>> >>>>Best regards, >>>>Susanne >>>> >>>>P. S. In case of ternary hashtrees there is the same >>> >>>problem: Do you >>> >>>>need one or three documents for correct verification? >>>> >>> >>> >>>-- >>>------------------------------------------------------------ >>>Dipl. Inf. Thomas Kunz >>>Fraunhofer-Institut für Sichere Informationstechnologie SIT >>>Rheinstrasse 75 >>>D-64295 Darmstadt (Germany) >>>Tel: +49-6151-869-60204 >>>------------------------------------------------------------ >>>e-mail: thomas.kunz@sit.fraunhofer.de >>> >>>http://www.sit.fraunhofer.de >>>------------------------------------------------------------ >>> >>> >> > > > -- ------------------------------------------------------------ Dipl. Inf. Thomas Kunz Fraunhofer-Institut für Sichere Informationstechnologie SIT Rheinstrasse 75 D-64295 Darmstadt (Germany) Tel: +49-6151-869-60204 ------------------------------------------------------------ e-mail: thomas.kunz@sit.fraunhofer.de http://www.sit.fraunhofer.de ------------------------------------------------------------ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k13GXDoF059341; Fri, 3 Feb 2006 08:33:13 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k13GXDPo059340; Fri, 3 Feb 2006 08:33:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from advantage-security.com ([201.148.139.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k13GXCuJ059323 for ; Fri, 3 Feb 2006 08:33:12 -0800 (PST) (envelope-from gwerner@advantage-security.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: LTANS-ERS: Verification and data groups Date: Fri, 3 Feb 2006 10:33:04 -0600 Message-ID: <1815FE0A4A30A44BA2F9E367E1B00AB130A169@corporativo.production.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS-ERS: Verification and data groups Thread-Index: AcYonFucdo/mcmeTSjy8QBCYHtroUgAGuNXAAANfHBAABmmYAA== From: "Greg Werner" To: "A. Jerman Blazic" , "Carl Wallace" , "Thomas Kunz" , "Susanne Okunick" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k13GXCuJ059335 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Mexico several banks, such as BBVA and HSBC, for example, have expressed interest in using a system that allows them to batch several documents into one group and segregate other documents, such as sensitive contracts, as single objects. As Jerman states below their reason to count on a system to verify single objects will depend on their specific needs, in this case it would be to mitigate legal risks. Regards, Greg Werner CISSP Advantage Security Tel. +52 55 5081 4366 -----Mensaje original----- De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] En nombre de A. Jerman Blazic Enviado el: viernes, 03 de febrero de 2006 7:26 Para: 'Carl Wallace'; 'Thomas Kunz'; 'Susanne Okunick' CC: ietf-ltans@imc.org Asunto: RE: LTANS-ERS: Verification and data groups That is correct. It is up to the client to decide which data should be grouped or not and this is included in the LTAP specification. Please bare in mind that grouping can happen for whatever reason: logically, semantically or any particular reason defined by a client (e.g. data accompanied with the meta data). However, verification of a single object MUST be possible at any time. Otherwise a service might hit scalability and confidentiality problems (imagine a case focused on specific document to be presented to the court and a case when such document is a group member...). > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: 3. februar 2006 13:00 > To: Thomas Kunz; Susanne Okunick > Cc: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > If I recall correctly, this was to have been a feature of > LTAP, i.e., at submission time a client could request that > the data being submitted not be lumped into a larger > grouping. This is a different than what you've suggested but > achieves a similar end. If LTAP is foregone in favor of a > binding to an existing protocol, like WebDAV, or > directly-managed ERS structures, like in the ERS/SCVP draft > where the SCVP server performs all of the maintenance, then > the sort of structure you propose makes more sense to meet > the grouping requirement. I'm not sure it's a good idea to > verify an evidence record without verifying each document in > the group. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > > Sent: Friday, February 03, 2006 3:15 AM > > To: Susanne Okunick > > Cc: ietf-ltans@imc.org > > Subject: Re: LTANS-ERS: Verification and data groups > > > > > > Hello, > > > > I agree with Susanne. A solution could be to change the ASN.1 > > structure of the ArchiveTimestamp. The hash values of the data > > object(s) could be stored in a separate sequence of octet > strings and > > the first list of the reduced hashtree only holds the hash > values of > > the siblings of the data object node. So the size of the > data object > > group can unambiguously determined. > > Perhaps the authors of the draft can give an opinion to > that problem? > > > > Best regards, > > Thomas > > > > > > Susanne Okunick wrote: > > > > > > Hello, > > > > > > At the verification of evidence records I get into difficulty. I > > > think, sometimes the verification for data groups is not > > practicable! > > > > > > For data groups consisting of more than one documents the > following > > > points have to be checked (compare example in the draft; > > page 10,11): > > > a) check whether the hash value of each data object is within the > > > first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( > > h2b,h2c,h2a) > > > b) check whether the document group is complete. That > > means: All data > > > objects have to be available at the time of verification > > (d2a,d2b,d2c). > > > If a data group consits of five documents, I will need all five > > > documents for the entire successfull verification. > > > > > > The first sequence of every reduced binary hashtree > consists of *at > > > least* two hash values. > > > This is for 1) one data object or 2) a data group consisting of > > > exactly two data objects! > > > My question: How to identify the right case? > > > > > > Assuming the following simple reduced binary hashtree: > > > [[h1a,h1b][h2][h3]] > > > > > > For verification you have to calculate the root of hash (h123): > > > h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary > > > sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary > > sorted and > > > concatenated (h1a, h1b) ) | h2 h1a | h1b > > > > > > Now there are two possibilities: > > > 1) h1a and h1b don't build a data group => for whole > > verification you > > > need the data object "d1a" to show that the data object's > > hash value > > > is "h1a" > > > 2) h1a and h1b are data objects of one data group => for > > verification > > > both data objects d1a and d1b must be available and you > > have to show > > > that both hash values are correctly computed > > > > > > Thus you never know (in case of having two hash values in > the first > > > sequence of reduced binary hashtree), whether one or two > documents > > > needed for verification. > > > > > > Best regards, > > > Susanne > > > > > > P. S. In case of ternary hashtrees there is the same > > problem: Do you > > > need one or three documents for correct verification? > > > > > > > > > -- > > ------------------------------------------------------------ > > Dipl. Inf. Thomas Kunz > > Fraunhofer-Institut für Sichere Informationstechnologie SIT > > Rheinstrasse 75 > > D-64295 Darmstadt (Germany) > > Tel: +49-6151-869-60204 > > ------------------------------------------------------------ > > e-mail: thomas.kunz@sit.fraunhofer.de > > > > http://www.sit.fraunhofer.de > > ------------------------------------------------------------ > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k13DJ1gE032046; Fri, 3 Feb 2006 05:19: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 k13DJ1jc032045; Fri, 3 Feb 2006 05:19:01 -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.9) with SMTP id k13DIx3a032033 for ; Fri, 3 Feb 2006 05:19:00 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200602031319.k13DIx3a032033@above.proper.com> Received: (qmail 24874 invoked from network); 3 Feb 2006 13:18:58 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 3 Feb 2006 13:18:58 -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 23044-10 for ; Fri, 3 Feb 2006 14:18:54 +0100 (CET) Received: (qmail 24851 invoked from network); 3 Feb 2006 13:18:54 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 3 Feb 2006 13:18:54 -0000 From: "A. Jerman Blazic" To: "'Carl Wallace'" , "'Thomas Kunz'" , "'Susanne Okunick'" Cc: Subject: RE: LTANS-ERS: Verification and data groups Date: Fri, 3 Feb 2006 14:26:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYonFucdo/mcmeTSjy8QBCYHtroUgAGuNXAAANfHBA= In-Reply-To: <82D5657AE1F54347A734BDD33637C87901138C1D@EXVS01.ex.dslextreme.net> X-Virus-Scanned: amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k13DJ13a032040 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That is correct. It is up to the client to decide which data should be grouped or not and this is included in the LTAP specification. Please bare in mind that grouping can happen for whatever reason: logically, semantically or any particular reason defined by a client (e.g. data accompanied with the meta data). However, verification of a single object MUST be possible at any time. Otherwise a service might hit scalability and confidentiality problems (imagine a case focused on specific document to be presented to the court and a case when such document is a group member...). > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: 3. februar 2006 13:00 > To: Thomas Kunz; Susanne Okunick > Cc: ietf-ltans@imc.org > Subject: RE: LTANS-ERS: Verification and data groups > > > If I recall correctly, this was to have been a feature of > LTAP, i.e., at submission time a client could request that > the data being submitted not be lumped into a larger > grouping. This is a different than what you've suggested but > achieves a similar end. If LTAP is foregone in favor of a > binding to an existing protocol, like WebDAV, or > directly-managed ERS structures, like in the ERS/SCVP draft > where the SCVP server performs all of the maintenance, then > the sort of structure you propose makes more sense to meet > the grouping requirement. I'm not sure it's a good idea to > verify an evidence record without verifying each document in > the group. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > > Sent: Friday, February 03, 2006 3:15 AM > > To: Susanne Okunick > > Cc: ietf-ltans@imc.org > > Subject: Re: LTANS-ERS: Verification and data groups > > > > > > Hello, > > > > I agree with Susanne. A solution could be to change the ASN.1 > > structure of the ArchiveTimestamp. The hash values of the data > > object(s) could be stored in a separate sequence of octet > strings and > > the first list of the reduced hashtree only holds the hash > values of > > the siblings of the data object node. So the size of the > data object > > group can unambiguously determined. > > Perhaps the authors of the draft can give an opinion to > that problem? > > > > Best regards, > > Thomas > > > > > > Susanne Okunick wrote: > > > > > > Hello, > > > > > > At the verification of evidence records I get into difficulty. I > > > think, sometimes the verification for data groups is not > > practicable! > > > > > > For data groups consisting of more than one documents the > following > > > points have to be checked (compare example in the draft; > > page 10,11): > > > a) check whether the hash value of each data object is within the > > > first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( > > h2b,h2c,h2a) > > > b) check whether the document group is complete. That > > means: All data > > > objects have to be available at the time of verification > > (d2a,d2b,d2c). > > > If a data group consits of five documents, I will need all five > > > documents for the entire successfull verification. > > > > > > The first sequence of every reduced binary hashtree > consists of *at > > > least* two hash values. > > > This is for 1) one data object or 2) a data group consisting of > > > exactly two data objects! > > > My question: How to identify the right case? > > > > > > Assuming the following simple reduced binary hashtree: > > > [[h1a,h1b][h2][h3]] > > > > > > For verification you have to calculate the root of hash (h123): > > > h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary > > > sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary > > sorted and > > > concatenated (h1a, h1b) ) | h2 h1a | h1b > > > > > > Now there are two possibilities: > > > 1) h1a and h1b don't build a data group => for whole > > verification you > > > need the data object "d1a" to show that the data object's > > hash value > > > is "h1a" > > > 2) h1a and h1b are data objects of one data group => for > > verification > > > both data objects d1a and d1b must be available and you > > have to show > > > that both hash values are correctly computed > > > > > > Thus you never know (in case of having two hash values in > the first > > > sequence of reduced binary hashtree), whether one or two > documents > > > needed for verification. > > > > > > Best regards, > > > Susanne > > > > > > P. S. In case of ternary hashtrees there is the same > > problem: Do you > > > need one or three documents for correct verification? > > > > > > > > > -- > > ------------------------------------------------------------ > > Dipl. Inf. Thomas Kunz > > Fraunhofer-Institut für Sichere Informationstechnologie SIT > > Rheinstrasse 75 > > D-64295 Darmstadt (Germany) > > Tel: +49-6151-869-60204 > > ------------------------------------------------------------ > > e-mail: thomas.kunz@sit.fraunhofer.de > > > > http://www.sit.fraunhofer.de > > ------------------------------------------------------------ > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k13BrxXS020029; Fri, 3 Feb 2006 03:53:59 -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 k13Brxdo020028; Fri, 3 Feb 2006 03:53:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k13BrxgC020013 for ; Fri, 3 Feb 2006 03:53:59 -0800 (PST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LTANS-ERS: Verification and data groups Date: Fri, 3 Feb 2006 03:59:32 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87901138C1D@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS-ERS: Verification and data groups thread-index: AcYonFucdo/mcmeTSjy8QBCYHtroUgAGuNXA From: "Carl Wallace" To: "Thomas Kunz" , "Susanne Okunick" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k13BrxgC020023 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If I recall correctly, this was to have been a feature of LTAP, i.e., at submission time a client could request that the data being submitted not be lumped into a larger grouping. This is a different than what you've suggested but achieves a similar end. If LTAP is foregone in favor of a binding to an existing protocol, like WebDAV, or directly-managed ERS structures, like in the ERS/SCVP draft where the SCVP server performs all of the maintenance, then the sort of structure you propose makes more sense to meet the grouping requirement. I'm not sure it's a good idea to verify an evidence record without verifying each document in the group. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > Sent: Friday, February 03, 2006 3:15 AM > To: Susanne Okunick > Cc: ietf-ltans@imc.org > Subject: Re: LTANS-ERS: Verification and data groups > > > Hello, > > I agree with Susanne. A solution could be to change the ASN.1 > structure of the ArchiveTimestamp. The hash values of the > data object(s) could be stored in a separate sequence of > octet strings and the first list of the reduced hashtree only > holds the hash values of the siblings of the data object > node. So the size of the data object group can unambiguously > determined. > Perhaps the authors of the draft can give an opinion to that problem? > > Best regards, > Thomas > > > Susanne Okunick wrote: > > > > Hello, > > > > At the verification of evidence records I get into difficulty. I > > think, sometimes the verification for data groups is not > practicable! > > > > For data groups consisting of more than one documents the following > > points have to be checked (compare example in the draft; > page 10,11): > > a) check whether the hash value of each data object is within the > > first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( > h2b,h2c,h2a) > > b) check whether the document group is complete. That > means: All data > > objects have to be available at the time of verification > (d2a,d2b,d2c). > > If a data group consits of five documents, I will need all five > > documents for the entire successfull verification. > > > > The first sequence of every reduced binary hashtree consists of *at > > least* two hash values. > > This is for 1) one data object or 2) a data group consisting of > > exactly two data objects! > > My question: How to identify the right case? > > > > Assuming the following simple reduced binary hashtree: > > [[h1a,h1b][h2][h3]] > > > > For verification you have to calculate the root of hash (h123): > > h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary > > sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary > sorted and > > concatenated (h1a, h1b) ) | h2 h1a | h1b > > > > Now there are two possibilities: > > 1) h1a and h1b don't build a data group => for whole > verification you > > need the data object "d1a" to show that the data object's > hash value > > is "h1a" > > 2) h1a and h1b are data objects of one data group => for > verification > > both data objects d1a and d1b must be available and you > have to show > > that both hash values are correctly computed > > > > Thus you never know (in case of having two hash values in the first > > sequence of reduced binary hashtree), whether one or two documents > > needed for verification. > > > > Best regards, > > Susanne > > > > P. S. In case of ternary hashtrees there is the same > problem: Do you > > need one or three documents for correct verification? > > > > > -- > ------------------------------------------------------------ > Dipl. Inf. Thomas Kunz > Fraunhofer-Institut für Sichere Informationstechnologie SIT > Rheinstrasse 75 > D-64295 Darmstadt (Germany) > Tel: +49-6151-869-60204 > ------------------------------------------------------------ > e-mail: thomas.kunz@sit.fraunhofer.de > > http://www.sit.fraunhofer.de > ------------------------------------------------------------ > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k138FMCr085648; Fri, 3 Feb 2006 00:15: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 k138FMbP085647; Fri, 3 Feb 2006 00:15:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k138FKuJ085615 for ; Fri, 3 Feb 2006 00:15:21 -0800 (PST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.87.208] (sitp21.sit.fraunhofer.de [141.12.68.21]) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k138FDaV001157; Fri, 3 Feb 2006 09:15:13 +0100 Message-ID: <43E310F8.4070505@sit.fraunhofer.de> Date: Fri, 03 Feb 2006 09:14:48 +0100 From: Thomas Kunz User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Susanne Okunick CC: ietf-ltans@imc.org Subject: Re: LTANS-ERS: Verification and data groups References: <43D78E7E.20809@sit.fraunhofer.de> In-Reply-To: <43D78E7E.20809@sit.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I agree with Susanne. A solution could be to change the ASN.1 structure of the ArchiveTimestamp. The hash values of the data object(s) could be stored in a separate sequence of octet strings and the first list of the reduced hashtree only holds the hash values of the siblings of the data object node. So the size of the data object group can unambiguously determined. Perhaps the authors of the draft can give an opinion to that problem? Best regards, Thomas Susanne Okunick wrote: > > Hello, > > At the verification of evidence records I get into difficulty. I think, > sometimes the verification for data groups is not practicable! > > For data groups consisting of more than one documents the following > points have to be checked (compare example in the draft; page 10,11): > a) check whether the hash value of each data object is within the first > sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( h2b,h2c,h2a) > b) check whether the document group is complete. That means: All data > objects have to be available at the time of verification (d2a,d2b,d2c). > If a data group consits of five documents, I will need all five > documents for the entire successfull verification. > > The first sequence of every reduced binary hashtree consists of *at > least* two hash values. > This is for 1) one data object or 2) a data group consisting of exactly > two data objects! > My question: How to identify the right case? > > Assuming the following simple reduced binary hashtree: > [[h1a,h1b][h2][h3]] > > For verification you have to calculate the root of hash (h123): > h123=H( binary sorted and concatenated (h12, h3) ) > h12=H( binary sorted and concatenated (h1ab, h2) ) | h3 > h1ab = H( binary sorted and concatenated (h1a, h1b) ) | h2 > h1a | h1b > > Now there are two possibilities: > 1) h1a and h1b don't build a data group => for whole verification you > need the data object "d1a" to show that the data object's hash value is > "h1a" > 2) h1a and h1b are data objects of one data group => for verification > both data objects d1a and d1b must be available and you have to show > that both hash values are correctly computed > > Thus you never know (in case of having two hash values in the first > sequence of reduced binary hashtree), whether one or two documents > needed for verification. > > Best regards, > Susanne > > P. S. In case of ternary hashtrees there is the same problem: Do you > need one or three documents for correct verification? > -- ------------------------------------------------------------ Dipl. Inf. Thomas Kunz Fraunhofer-Institut für Sichere Informationstechnologie SIT Rheinstrasse 75 D-64295 Darmstadt (Germany) Tel: +49-6151-869-60204 ------------------------------------------------------------ e-mail: thomas.kunz@sit.fraunhofer.de http://www.sit.fraunhofer.de ------------------------------------------------------------