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 k3SLLoBc025370; Fri, 28 Apr 2006 14:21:50 -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 k3SLLoNg025369; Fri, 28 Apr 2006 14:21:50 -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 exprod6og18.obsmtp.com (exprod6og18.obsmtp.com [64.18.1.141]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k3SLLnu0025363 for ; Fri, 28 Apr 2006 14:21:49 -0700 (MST) (envelope-from LMM@acm.org) Received: from source ([192.150.11.134]) by exprod6ob18.obsmtp.com ([64.18.5.12]) with SMTP; Fri, 28 Apr 2006 14:21:49 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k3SLKhBl020078 for ; Fri, 28 Apr 2006 14:20:43 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k3SLLkrs025255 for ; Fri, 28 Apr 2006 14:21:47 -0700 (PDT) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IYG00HTQBC9WD@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Fri, 28 Apr 2006 14:21:46 -0700 (PDT) Received: from MasinterT43p (c-47-39.corp.adobe.com [153.32.47.39]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IYG00G4ABC9M7@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Fri, 28 Apr 2006 14:21:45 -0700 (PDT) Date: Fri, 28 Apr 2006 14:21:37 -0700 From: Larry Masinter Subject: RE: WG Last Call: draft-ietf-ltans-reqs-06.txt In-reply-to: <2666EB2A846BAC4BB2D7F593301A7868256327@MUCXGC2.opentext.net> To: ietf-ltans@imc.org Message-id: <000701c66b09$bbf681d0$272f2099@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcZqokiF2onhi8+MRDCGBKaEIaY5FwATLHkg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Minor editorial comments: Typo: "A long-term archive service provides a evidence that may be used to" "provides a evidence" => "provides evidence" The next to last paragraph of section 6 (Security Considerations): Additional mechanisms, applications or tools may be needed to preserve the value of evidence records associated with original archived data object. Other specifications of LTANS, in particular certification services will address these problems. but "LTANS" isn't defined in this document. I suggest just deleting the "Other specifications..." sentence, since it's not needed. I wonder about Appendix B, because it isn't referenced in the text and doesn't seem directly related to the topic of the document. The simplest edit would be just to remove it. Otherwise, you should explain how it relates to the main document. Larry 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 k3SH71ar014664; Fri, 28 Apr 2006 10:07:01 -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 k3SH71qN014663; Fri, 28 Apr 2006 10:07:01 -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 mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3SH6w3X014657 for ; Fri, 28 Apr 2006 10:06:59 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 12386 invoked from network); 28 Apr 2006 17:10:17 -0000 Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 28 Apr 2006 17:10:17 -0000 Message-ID: <44524BA9.5080903@seccommerce.de> Date: Fri, 28 Apr 2006 19:06:49 +0200 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, Boris Baltzer Subject: Re: Why are the hash values sorted? References: <2666EB2A846BAC4BB2D7F593301A78681E170B@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78681E170B@MUCXGC2.opentext.net> 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 Tobias, > We sort the hash values (binary ascending) to reduce the risk of > collision attacks by resorting the hash values in another combination > and by this getting another hash value for the parent node. I understand these arguments, but they do not convince me. If there was a realistic risk of collision attacks, a better hash algorithm should be used to prohibit such an attack. The draft does not demand a certain hash algorithm and an upgrade would be conformal. I am no cryptographer and maybe missing something, but it is my understanding that we do not have to expect collision attacks against for example SHA-256 within the next years. If your concern is that of a collision attack, you will also have to consider the possibility of inserting arbitrary values into the hash tree in order to perform such an attack. In my perception, inserting arbitrary values into the hash tree provides possibilities for collision attacks similar to those of resorting the hashes. In this respect, sorting the hashes to prevent collisions seems like installing a bigger lock on the door while the window remains open. In short: I think that collision attacks have to be prevented by the hash algorithm, not by the way the tree is sorted. > And as we > only secure the root hash with the time stamp we think that it is > mandatory that the mapping/transformation from a given set of hash > values to the root hash MUST be unambiguous. I suggest to compute the parent hash on the hashes below it in the exact order in which they appear in the ASN.1-sequence. This is an unambiguous rule. > I understand the need for grouping of objects, but the order in the > hash > tree is not the right element for the information of the order of the > documents in an application/document specific context. For many of our customers like IBM and major German authorities it is an important feature to be able to prove the order in which the documents have been signed. They insist that the hash tree is the natural place for this proof. It is important for us to have a solution compatible to the ArchiSig standard and therefore to LTANS-ERS. Therefore I suggest to make the sorting optional and insert a flag into the evidence record which shows whether the values have to be binary sorted before verification or just taken as they are. Kind regards Tilo -- Tilo Kienitz SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 Hamburg http://www.seccommerce.de Germany 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 k3S91QpH091511; Fri, 28 Apr 2006 02:01:26 -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 k3S91QRT091510; Fri, 28 Apr 2006 02:01:26 -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 mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3S91MDp091502 for ; Fri, 28 Apr 2006 02:01:23 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k3S91IM5003111; Fri, 28 Apr 2006 11:01:20 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AA2.48A6DF16" Subject: WG Last Call: draft-ietf-ltans-reqs-06.txt Date: Fri, 28 Apr 2006 11:01:06 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868256327@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ltans-reqs-06.txt Thread-Index: AcZqokiF2onhi8+MRDCGBKaEIaY5Fw== From: "Tobias Gondrom" To: Cc: "Carl Wallace" 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_01C66AA2.48A6DF16 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey folks, As we had very little further comments on this one, Carl and I think = that the discussion can be concluded and that it is also ready for WG = Last Call: WG last call for the "Long-Term Archive Service Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-06.txt=20 (note: this I-D will be submitted as "Informational".) Please provide final comments to the list by May 9th.=20 Thanks,=20 Carl & Tobias Chairs of LTANS __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C66AA2.48A6DF16 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG Last Call: draft-ietf-ltans-reqs-06.txt

Hey = folks,

As we = had very little further comments on this one, Carl and I = think that the discussion can be concluded = and that it is also ready for = WG Last Call:

WG = last call for the “Long-Term Archive Service Requirements”

http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-= 06.txt

(note: this I-D will be submitted as “Informational”.)

Please provide final comments to the list by = May 9th. =

Thanks,

Carl = & Tobias

Chairs of LTANS


__________________________________________
Tobias = Gondrom
Senior = Security Architect
Head of Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone: = +49 (0) 89 4629-1816
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentext.com
Internet: http://www.opentext.com/

This eMail may contain confidential and/or privileged = information. If you are not the intended recipient or have received this = eMail in error, please notify the sender immediately and destroy this = eMail. Any use, disclosure or distribution of the material in this eMail = is strictly forbidden.

Diese = eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht = gestattet.

------_=_NextPart_001_01C66AA2.48A6DF16-- 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 k3RJoDGE058191; Thu, 27 Apr 2006 12:50:13 -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 k3RJoDfF058189; Thu, 27 Apr 2006 12:50:13 -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 willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3RJoDEs058173 for ; Thu, 27 Apr 2006 12:50:13 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3RJo19W021153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FZCUz-0003X9-Nt; Thu, 27 Apr 2006 15:50:01 -0400 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-reqs-06.txt Message-Id: Date: Thu, 27 Apr 2006 15:50:01 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-Term Archive Service Requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-06.txt Pages : 21 Date : 2006-4-27 There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-06.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-reqs-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-reqs-06.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-4-27113028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-27113028.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 k3LHEwMH006996; Fri, 21 Apr 2006 10:14:58 -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 k3LHEwM7006995; Fri, 21 Apr 2006 10:14:58 -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 mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3LHEu5a006988 for ; Fri, 21 Apr 2006 10:14:56 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k3LHErLt004903; Fri, 21 Apr 2006 19:14:54 +0200 (MEST) 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: ERS-06: RE: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt Date: Fri, 21 Apr 2006 19:14:54 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78681E1872@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS-06: RE: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt Thread-Index: AcZlY9aDU0PZMWqZRwmy1XG/HqJ7VwAApmiw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3LHEv5a006990 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: George, Thanks, I forgot to remove the reference to the draft http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-05.txt as it has not already been published as an I-D (as planned in the early stages of ERS) => Reference will have to be removed. Tobias > -----Original Message----- > From: George Jones [mailto:eludom@gmail.com] > Sent: Friday, April 21, 2006 6:51 PM > To: Tobias Gondrom > Subject: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > Need to fill out the "???". Probably will not (should not) make it > past RFC editors with this in. > > [REQ2004] Wallace, C., Brandner, R., and U. Pordesch, "Long-term > Archive Service Requirements", I-D ???, 2005. > > > ---George Jones 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 k3L84UjV085017; Fri, 21 Apr 2006 01:04:30 -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 k3L84UP2085016; Fri, 21 Apr 2006 01:04:30 -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 mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3L84Slj085009 for ; Fri, 21 Apr 2006 01:04:29 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k3L84QL6021596 for ; Fri, 21 Apr 2006 10:04:27 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6651A.351FD4AC" Subject: WG last call on ERS Date: Fri, 21 Apr 2006 10:04:25 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78681E174F@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on ERS Thread-Index: AcZlGjT7hFDWocNiS72VubNcD8NK8g== From: "Tobias Gondrom" 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_01C6651A.351FD4AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, as announced in Dallas, we hereby initiate WG last call for ERS: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt=20 Please provide final comments to the list by May 5th.=20 Thanks,=20 Carl & Tobias Chairs of LTANS ------_=_NextPart_001_01C6651A.351FD4AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG last call on ERS

Folks,

as = announced in Dallas, we = hereby initiate WG last call for ERS:

= http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-0= 6.txt

Please provide final comments to the list = by May 5th. =

Thanks,

Carl = & Tobias

Chairs of LTANS

------_=_NextPart_001_01C6651A.351FD4AC-- 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 k3KJoBjs054395; Thu, 20 Apr 2006 12:50:11 -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 k3KJoBW9054394; Thu, 20 Apr 2006 12:50:11 -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 oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KJo8Iw054387 for ; Thu, 20 Apr 2006 12:50:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3KJo2BX030755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FWfAA-0004zR-H4; Thu, 20 Apr 2006 15:50:02 -0400 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-06.txt Message-Id: Date: Thu, 20 Apr 2006 15:50:02 -0400 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-06.txt Pages : 27 Date : 2006-4-20 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-06.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-06.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-06.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-4-20144156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-20144156.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 k3KHAhw4045183; Thu, 20 Apr 2006 10:10: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 k3KHAhbE045182; Thu, 20 Apr 2006 10:10: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 mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KHAcNA045172 for ; Thu, 20 Apr 2006 10:10:41 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k3KHAbwX010123; Thu, 20 Apr 2006 19:10:37 +0200 (MEST) 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: RE: Why are the hash values sorted? Date: Thu, 20 Apr 2006 19:10:36 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78681E170B@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why are the hash values sorted? Thread-Index: AcZM6QL0oGZD9G7CT7+2TE0QyN0pSAXs3zrw From: "Tobias Gondrom" To: "Tilo Kienitz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3KHAgNA045176 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tilo, and sorry for the late answer. ;-) We sort the hash values (binary ascending) to reduce the risk of collision attacks by resorting the hash values in another combination and by this getting another hash value for the parent node. And as we only secure the root hash with the time stamp we think that it is mandatory that the mapping/transformation from a given set of hash values to the root hash MUST be unambiguous. I understand the need for grouping of objects, but the order in the hash tree is not the right element for the information of the order of the documents in an application/document specific context. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tilo Kienitz > Sent: Tuesday, March 21, 2006 2:02 PM > To: ietf-ltans@imc.org > Subject: Why are the hash values sorted? > > > Hello working group, > > I'm afraid I'm quite late with my question, but what is the > advantage of sorting the hash values? > > Paragraph "3.2. Generation" of draft-ietf-ltans-ers-05 states: > "3. For each data group containing more than one document, its > respective document hashes are binary sorted in ascending > order, concatenated and hashed." > > The order of the documents in the data object group could already > have some meaning in an external application and it would be nice > if the hash tree preserved this existing order. Without the binary > sorting not only the existence of the hashes could be proven after > years but also their order. > > The binary sorting is not needed to get a unique hash value, since > the reducedHashtree uses ASN-sequences. If the hash algorithm > processed the hash values in the same order in which they appear > in the sequences in the reducedHashtree then the root hash would be > uniquely determined without the need to sort anything in between. > > What do you think? > > Kind regards > Tilo Kienitz > > > -- > Tilo Kienitz > SecCommerce Informationssysteme GmbH > Obenhauptstr. 5 > D - 22335 Hamburg http://www.seccommerce.de > Germany 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 k3CEKtcX070310; Wed, 12 Apr 2006 07:20:55 -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 k3CEKtgV070309; Wed, 12 Apr 2006 07:20:55 -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 k3CEKrln070303 for ; Wed, 12 Apr 2006 07:20:54 -0700 (MST) (envelope-from robholliday@isocore.com) Message-Id: <200604121420.k3CEKrln070303@balder-227.proper.com> Received: from [65.213.193.6] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FTgDE-0007sn-J5 for ietf-ltans@imc.org; Wed, 12 Apr 2006 10:20:53 -0400 From: "Robert Holliday" To: Subject: On-line Registration Closing Sunday Date: Wed, 12 Apr 2006 10:20:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C65E1A.C49704F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZePEt4/OUIDWn4R3qO2qTAaKduaA== 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_001C_01C65E1A.C49704F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This week is the last chance for attendees to register online for the International Conference on Network Security. For those interested in registering before time runs out please go to: www.networksecurity2006.com Conference Program Monday, April 17 TECHNICAL SESSIONS AND PANELS 8:45 - 10:30 am Opening Session Chair: Guy Copeland VP and Assistant to the President, CSC . Introduction Guy Copeland . Keynote Speech Andy Purdy Department of Homeland Security . Issues in Wiretapping Technologies Matt Blaze University of Pennsylvania Break (10:30 - 10:45 am) 10:45 am - 12:30 pm Panel: User Authentication Technologies Chair: Radia Perlman Sun Microsystems . PKI: It's not that hard. Why don't we have it? Charlie Kaufman Microsoft . Web Services/Liberty Approach to Single Sign-on Gerald Beuchelt Sun Microsystems . Is the Identity-based Crypto the Best Solution? Terence Spies Voltage Security . PKI: Let's Make it Happen! Bill Burr NIST . SAML Comparison to Kerberos to Support a Centralized Authoritative Source for Authentication Hank Simon Lockheed Martin Lunch (12:30 - 1:45 pm) 1:45 - 3:00 pm Mesh Network Security Chair: Russ Housley Vigil Security, LLC . Status of 802.11 Mesh and Security Donald Eastlake III Motorola . Security Issues in 802.11s William Arbaugh, UMD Jesse Walker, Intel . More on 802.11s Robert Moskowitz ICSA Labs, Cybertrust Break (3:00 - 3:15 pm) 3:15 - 4:30 pm Defending Against Denial of Service Chair: Jim Hughes Sun Microsystems . Surviving Denial of Service Andy Ellis Akamai . MITHRIL: Adaptable Security for Survivability in Collaborative Computing Sites Von Welch, NCSA Jim Basney, NCSA Himanshu Khurana, NCSA . Investigating the Impact of Real-World Factors on Internet Worm Propagation Xiaoyan Hong University of Alabama 4:30 - 5:30 pm Panel: Legislative Aspects of Security . Pat Schambach Nortel . Robert Dix Jr. Citadel Security Software . Michael Aisenberg Verisign . John Morris Center for Democracy & Technology 5:30 - 6:30 pm Reception 6:45 - 7:45 pm Tutorial: Network Incident Response Presenter: Richard Bejtlich Tao Security Tuesday, April 18 TECHNICAL SESSIONS AND PANELS 9:00 - 10:30 am Software Security Chair: Charlie Kaufman Microsoft . Why Software Breaks Andrew Lee Eset . Federal Standards and Guidelines Developed by NIST Stuart Katzke NIST . Impact of NSTISSP-11 on the Current Certification Climate for Products and Technology Keith Beatty SAIC . How can we make products and deployments more secure? Eric Cole Lockheed Martin Break (10:30 - 10:45 am) 10:45 am - 12:30 pm Network Security Protocol Issues Chair: Hilarie Orman Purple Streak, Inc. . Introduction and Comparison of IPv4 Address Resolution Protocol, ICMP Router Discovery and ICMP Redirect; and IPv6 Neighbor Discovery Protocol Security Issues Michael Wasielewski Lockheed-Martin . The ability for the Warfighter to share critical information across and between networks without leakage Adele Friedel Tenix America . Availability and Security Tradeoffs Arun Sood Task Technologies Ltd. . Firewall Traversal: Security and Scalability David McGrew Cisco Systems . Updates on IETF Security Related Working Groups Sam Hartman MIT Russ Housley Vigil Security Lunch (12:30 - 1:45 pm) 1:45 - 3:00 pm Security for Wireless and Internet Mobility Chair: Bijan Jabbari Isocore . Optimizations to Support Secure AP Transitions in 802.11 WLANs Jesse Walker Intel . 3GPP2 Network Firewall Configuration and Control Michael Paddon Qualcomm . Proactive EAP-based handover key management for mobile wireless users Madjid Nakhjiri Motorola Break (3:00 - 3:15 pm) 3:15 - 4:30 pm Panel: Internet Infrastructure Security Chair: Hilarie Orman Purple Streak, Inc. . MPLS VPN Security Harmen van der Linde Cisco Systems . DHS and Internet Infrastructure Security Marcus Sachs SRI . Routing Security Sandra Murphy Sparta . Why Routing Protocol Security isn't Seeing Wide Adoption Russ White Cisco Systems 4:30 - 5:30 pm Web Browser Security Moderator: Darren Moffat Sun Microsystems . The Sad State of Evolution of Interface to User Security with a Focus on the Web Browser Eric Greenberg Netframeworks . XML: Salvation or Struggle Donald Eastlake III Motorola . Web Browser Security Frameworks Perry Metzger Piermont . Issues in Web Browser Security Sam Hartman MIT Wednesday, April 19 TECHNICAL SESSIONS AND PANELS 9:00 - 10:30 am DNS Security Chair: Donald Eastlake III Motorola . Why isn't DNS security deployed, and would we be safer if it was? Charlie Kaufman Microsoft . DNSSEC and FISMA Scott Rose NIST . DNS Security Stuart Schechter Lincoln Laboratory . The Registry Perspective on DNSSEC Matt Larson Verisgn Break (10:30 - 10:45 am) 10:45 am - 12:30 pm Panel: Trusted Platforms Chair: Radia Perlman Sun Microsystems . Trusted Computing: Towards Safe Computing Environments Tom Hardjono SignaCert . A use for TPM Technology in Routing Infrastructure Andy Ellis Akamai . Issues in TPM Technology Ned Smith Intel . An Outsider's Perspective on TPM Russ Housley Vigilsec ------=_NextPart_000_001C_01C65E1A.C49704F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This week is the last chance for attendees to = register online for the International Conference on Network Security.  For = those interested in registering before time runs out please go to:  www.networksecurity2006.com<= /a>

 

Conference Program =

 

Monday, April 17

TECHNICAL SESSIONS AND PANELS 

 

8:45 - 10:30 am

Opening Session

Chair: Guy Copeland

VP and Assistant to the President, = CSC

 

· Introduction

Guy Copeland

 

· Keynote Speech

Andy Purdy

Department of Homeland Security

 

· Issues in Wiretapping Technologies =

Matt Blaze

University of = Pennsylvania

 

Break (10:30 – 10:45 am)

 

10:45 am - 12:30 pm

Panel: User Authentication = Technologies

Chair: Radia Perlman

Sun Microsystems

 

· PKI: It's not that hard. Why don't we have = it?

Charlie Kaufman

Microsoft

 

· Web Services/Liberty Approach to Single = Sign-on

Gerald Beuchelt

Sun Microsystems

 

· Is the Identity-based Crypto the Best = Solution?

Terence Spies

Voltage Security

 

· PKI: Let’s Make it Happen! =

Bill Burr

NIST

 

· SAML Comparison to Kerberos to Support a = Centralized Authoritative Source for Authentication

Hank Simon

Lockheed Martin

 

Lunch (12:30 – 1:45 pm)

 

1:45 - 3:00 pm

Mesh Network Security

Chair: Russ Housley

Vigil Security, LLC

 

· Status of 802.11 Mesh and Security =

Donald Eastlake III

Motorola

 

· Security Issues in 802.11s =

William Arbaugh, UMD

Jesse Walker, Intel

 

· More on 802.11s

Robert Moskowitz

ICSA Labs, Cybertrust

 

Break (3:00 – 3:15 pm)

 

3:15 - 4:30 pm

Defending Against Denial of Service =

Chair: Jim Hughes

Sun Microsystems

 

· Surviving Denial of = Service

Andy Ellis

Akamai

 

· MITHRIL: Adaptable Security for = Survivability in Collaborative Computing Sites

Von Welch, NCSA

Jim Basney, NCSA

Himanshu Khurana, NCSA

 

· Investigating the Impact of Real-World = Factors on Internet Worm Propagation

Xiaoyan Hong

University of = Alabama

 

4:30 - 5:30 pm

Panel: Legislative Aspects of Security =

 

· Pat Schambach

Nortel

 

· Robert Dix Jr.

Citadel Security Software

 

· Michael Aisenberg

Verisign

 

· John Morris

Center for Democracy & = Technology

 

5:30 - 6:30 pm

Reception

 

6:45 - 7:45 pm

Tutorial: Network Incident Response =

Presenter: Richard Bejtlich

Tao Security

 

Tuesday, April 18

TECHNICAL SESSIONS AND PANELS

 

9:00 - 10:30 am

Software Security

Chair: Charlie Kaufman

Microsoft

 

· Why Software Breaks

Andrew Lee

Eset

 

· Federal Standards and = Guidelines

Developed by NIST

Stuart Katzke

NIST

 

· Impact of NSTISSP-11 on the = Current

Certification Climate for Products and =

Technology

Keith Beatty

SAIC

 

· How can we make products = and

deployments more secure?

Eric Cole

Lockheed Martin

 

Break (10:30 – 10:45 am)

 

10:45 am - 12:30 pm

Network Security Protocol Issues

Chair: Hilarie Orman

Purple Streak, Inc.

 

· Introduction and Comparison of IPv4 Address = Resolution Protocol, ICMP Router Discovery and ICMP Redirect; and IPv6 Neighbor = Discovery Protocol Security Issues

Michael Wasielewski

Lockheed-Martin

 

· The ability for the Warfighter to share = critical information across and between networks without leakage

Adele Friedel

Tenix America

 

· Availability and Security Tradeoffs =

Arun Sood

Task Technologies Ltd.

 

· Firewall Traversal: Security and = Scalability

David McGrew

Cisco Systems

 

· Updates on IETF Security Related Working = Groups

Sam Hartman

MIT

Russ Housley

Vigil Security

 

Lunch (12:30 – 1:45 pm)

 

1:45 - 3:00 pm

Security for Wireless and Internet = Mobility

Chair: Bijan Jabbari

Isocore

 

· Optimizations to Support Secure AP = Transitions in 802.11 WLANs

Jesse Walker

Intel

 

· 3GPP2 Network Firewall Configuration and = Control

Michael Paddon

Qualcomm

 

· Proactive EAP-based handover key management = for mobile wireless users

Madjid Nakhjiri

Motorola

 

Break (3:00 – 3:15 pm)

 

3:15 - 4:30 pm

Panel: Internet Infrastructure = Security

Chair: Hilarie Orman

Purple Streak, Inc.

 

· MPLS VPN Security

Harmen van der Linde

Cisco Systems

 

· DHS and Internet Infrastructure = Security

Marcus Sachs

SRI

 

· Routing Security

Sandra Murphy

Sparta

 

· Why Routing Protocol Security isn't Seeing = Wide Adoption

Russ White

Cisco Systems

 

4:30 - 5:30 pm

Web Browser Security

Moderator: Darren Moffat

Sun Microsystems

 

· The Sad State of Evolution of Interface to = User Security with a Focus on the Web Browser

Eric Greenberg

Netframeworks

 

· XML: Salvation or Struggle

Donald Eastlake III

Motorola

 

· Web Browser Security Frameworks =

Perry Metzger

Piermont

 

· Issues in Web Browser = Security

Sam Hartman

MIT

 

Wednesday, April 19

TECHNICAL SESSIONS AND PANELS

 

9:00 - 10:30 am

DNS Security

Chair: Donald Eastlake III

Motorola

 

· Why isn't DNS security deployed, and would = we be safer if it was?

Charlie Kaufman

Microsoft

 

· DNSSEC and FISMA

Scott Rose

NIST

 

· DNS Security

Stuart Schechter

Lincoln Laboratory =

 

· The Registry Perspective on = DNSSEC

Matt Larson

Verisgn

 

Break (10:30 – 10:45 am)

 

10:45 am - 12:30 pm

Panel: Trusted Platforms

Chair: Radia Perlman

Sun Microsystems

 

· Trusted Computing: Towards Safe Computing = Environments

Tom Hardjono

SignaCert

 

· A use for TPM Technology in Routing = Infrastructure

Andy Ellis

Akamai

 

· Issues in TPM Technology

Ned Smith

Intel

 

· An Outsider’s Perspective on = TPM

Russ Housley

Vigilsec

 

 

 

 

 

 

 

------=_NextPart_000_001C_01C65E1A.C49704F0--