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 jBLGDUWD075840; Wed, 21 Dec 2005 08:13:30 -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 jBLGDUer075839; Wed, 21 Dec 2005 08:13:30 -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 jBLGDSlj075832 for ; Wed, 21 Dec 2005 08:13:29 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200512211613.jBLGDSlj075832@above.proper.com> Received: (qmail 23468 invoked from network); 21 Dec 2005 16:13:27 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 21 Dec 2005 16:13:27 -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 22974-10 for ; Wed, 21 Dec 2005 17:13:25 +0100 (CET) Received: (qmail 23447 invoked from network); 21 Dec 2005 16:13:24 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 21 Dec 2005 16:13:24 -0000 From: "A. Jerman Blazic" To: "'Tobias Gondrom'" , Subject: RE: LTANS: Examples of ERS data - cross checking of implementations Date: Wed, 21 Dec 2005 17:19:13 +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: AcYCZcb25/++4L9eRnGlzJJErswHKgD5BguA In-Reply-To: <3C1BE8610E44734499EF92FB35F5B07001648A2B@MUCXGC1.opentext.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 jBLGDUlj075834 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias SETCCE has done the implementation of LTAP as well as (its own XML interpretation of) ERS. Interoperability testing is however desirable, but I wonder whether ERS will be limited to ASN.1 syntax only. The LTAP includes both. Best regards Aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: 16. december 2005 18:26 > To: ietf-ltans@imc.org > Subject: LTANS: Examples of ERS data - cross checking of > implementations > Importance: Low > > Hello, > > > > I learned that two companies (IXOS and Fraunhofer) currently > make cross tests of their implementations of the ERS Draft. > Attached you find an example of an ERS produced, along with > the file which it is protecting. If you are implementing ERS > at the moment, too, you are invited to contact them via this > mailing-list (or I will happily relay the contact for you), > maybe we find a third or forth one who implemented ERS and > wants to share and cross check her implementation. > > > > Best regards, > > > > Tobias > > > > > > > > __________________________________________ > 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ält vertrauliche und/oder rechtlich > geschützte Informationen. Wenn Sie nicht der richtige > Adressat sind oder diese eMail irrtümlich erhalten haben, > informieren Sie bitte sofort den Absender und vernichten Sie > diese eMail. Jegliche Art der Verwendung, Vervielfältigung > oder Weitergabe ist nicht gestattet. > > > > 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 jBH0Ir9J002030; Fri, 16 Dec 2005 16:18:53 -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 jBH0Ir7N002029; Fri, 16 Dec 2005 16:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gate12-norfolk.nmci.navy.mil (gate12-norfolk.nmci.navy.mil [138.162.5.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBH0Ir6J002017 for ; Fri, 16 Dec 2005 16:18:53 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from naeanrfkms04.nmci.navy.mil by gate12-norfolk.nmci.navy.mil via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Sat, 17 Dec 2005 00:18:53 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 16 Dec 2005 08:33:16 +0000 Received: (private information removed) Received: from mail pickup service by NAWESDNIEB05.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Fri, 16 Dec 2005 16:17:54 -0800 Received: from nawesdnieg04.nadsuswe.nads.navy.mil ([10.0.10.59]) by nawesdnieb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Dec 2005 13:13:09 -0800 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by nawesdnieg04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Dec 2005 13:13:08 -0800 Received: from Nawesdnims02.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.59]) with ESMTP; Fri, 16 Dec 2005 21:13:09 +0000 Received: from nawesdnifw03c.nmci.navy.mil (nawesdnifw03c.nmci.navy.mil [10.0.0.163]) by nawesdnims02.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id jBGKrdK01857 for ; Fri, 16 Dec 2005 20:53:39 GMT Received: from [138.163.0.136] by nawesdnifw03c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Fri, 16 Dec 2005 21:13:08 +0000 Received: from mx2.spawar.navy.mil (128.49.251.7) by navysdniio01.nmci.navy.mil with ESMTP; 16 Dec 2005 13:13:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx2.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id jBGLApjA020590 for ; Fri, 16 Dec 2005 13:10:52 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMWo-00031f-0t; Fri, 16 Dec 2005 15:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMWh-0002zq-1Q for i-d-announce@megatron.ietf.org; Fri, 16 Dec 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12488 for ; Fri, 16 Dec 2005 15:49:02 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMYM-0006VN-QM for i-d-announce@ietf.org; Fri, 16 Dec 2005 15:51:47 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EnMWf-0006DB-Se; Fri, 16 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ietf-ltans@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.592, required 3.3, BAYES_00 -2.60, MIME_BOUND_NEXTPART 0.00, NO_REAL_NAME 0.01) Subject: I-D ACTION:draft-ietf-ltans-notareqs-03.txt X-OriginalArrivalTime: 16 Dec 2005 21:13:08.0905 (UTC) FILETIME=[83A32190:01C60285] 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 : Requirements for Data Validation and Certification Services Author(s) : T. Gondrom, et al. Filename : draft-ietf-ltans-notareqs-03.txt Pages : 12 Date : 2005-12-16 This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. The data being validated may correspond to assertions about real-world facts or events. This document establishes the need for components to be used in addition to or in conjunction with long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-03.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-notareqs-03.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-notareqs-03.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: <2005-12-16144345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-notareqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-notareqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-16144345.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 jBGMIi1E091386; Fri, 16 Dec 2005 14:18:44 -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 jBGMIilZ091385; Fri, 16 Dec 2005 14:18:44 -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 jBGMIi2I091365 for ; Fri, 16 Dec 2005 14:18:44 -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: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Fri, 16 Dec 2005 14:18:37 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C879494D78@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Thread-Index: AcYCVLLdLHjCx1LqRH2L4Q6wpE8I9wAOFi3A From: "Carl Wallace" To: "Young H. Etheridge" Cc: "Tobias Gondrom" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBGMIi2I091380 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Yes but the structures and/or processes defined here should > support such. > > > > > On closer examination of all four (4) TimeStamp methods produced in > X9.95 it seems that most of the necessary TimeStamp artifacts are > encodable options, particularly, in the CMS ASN.1 encoding. In > particular, the applicable cert validation paths and CRLs for > digitally > signed TimeStamps are optional encodings. There are CMS software > development APIs, e.g., BouncyCastle's Java-based crypto API, > that allow > a developer to simply exercise these options. This seems to provide > additional credence to my request to give X9.95 an equal footing with > RFC-3161 in the LTANS ERS I-D. Of course, CMS supports cert bags and CRL bags. These certainly could be used. Are they? How are they incorporated into the generation and validation operations? For example, when the timestamp is refreshed the validation material would already need to be incorporated into the timestamp. These details should be in the document. Are there issues related to supporting users in multiple PKI communities who may validate the timestamp signature, and thus impact what should be included in the timestamp's cert and CRL bags? Where are the trust anchors obtained to verify the old timestamps? In Paris, much seemed to be made about policies. Do those need to be in this document? These seem like issues that should be addressed to me. 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 jBGKo3GE082330; Fri, 16 Dec 2005 12:50:03 -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 jBGKo3uD082327; Fri, 16 Dec 2005 12:50:03 -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 jBGKo267082317 for ; Fri, 16 Dec 2005 12:50:02 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EnMWf-0006DB-Se; Fri, 16 Dec 2005 15: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-notareqs-03.txt Message-Id: Date: Fri, 16 Dec 2005 15: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 : Requirements for Data Validation and Certification Services Author(s) : T. Gondrom, et al. Filename : draft-ietf-ltans-notareqs-03.txt Pages : 12 Date : 2005-12-16 This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. The data being validated may correspond to assertions about real-world facts or events. This document establishes the need for components to be used in addition to or in conjunction with long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-03.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-notareqs-03.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-notareqs-03.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: <2005-12-16144345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-notareqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-notareqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-16144345.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 jBGHPnEL055199; Fri, 16 Dec 2005 09:25:49 -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 jBGHPnna055198; Fri, 16 Dec 2005 09:25:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGHPlkR055180 for ; Fri, 16 Dec 2005 09:25:48 -0800 (PST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id jBGHPk8E013723 for ; Fri, 16 Dec 2005 18:25:46 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C60265.BFF33ACD" Subject: LTANS: Examples of ERS data - cross checking of implementations Date: Fri, 16 Dec 2005 18:25:57 +0100 Message-ID: <3C1BE8610E44734499EF92FB35F5B07001648A2B@MUCXGC1.opentext.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: LTANS: Examples of ERS data - cross checking of implementations Thread-Index: AcYCZcb25/++4L9eRnGlzJJErswHKg== X-Priority: 5 Importance: low 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_01C60265.BFF33ACD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C60265.BFF33ACD" ------_=_NextPart_002_01C60265.BFF33ACD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I learned that two companies (IXOS and Fraunhofer) currently make cross = tests of their implementations of the ERS Draft. Attached you find an = example of an ERS produced, along with the file which it is protecting. = If you are implementing ERS at the moment, too, you are invited to = contact them via this mailing-list (or I will happily relay the contact = for you), maybe we find a third or forth one who implemented ERS and = wants to share and cross check her implementation. =20 Best regards, =20 Tobias =20 =20 =20 __________________________________________ 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. =20 ------_=_NextPart_002_01C60265.BFF33ACD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I learned that two companies (IXOS and Fraunhofer) = currently make cross tests of their implementations of the ERS Draft. Attached you = find an example of an ERS produced, along with the file which it is = protecting. If you are implementing ERS at the moment, too, you are invited to contact = them via this mailing-list (or I will happily relay the contact for you), = maybe we find a third or forth one who implemented ERS and wants to share and = cross check her implementation.

 

Best regards,

 

Tobias

 

 

 

__________________________________________
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@opentex= t.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_002_01C60265.BFF33ACD-- ------_=_NextPart_001_01C60265.BFF33ACD Content-Type: image/jpeg; name="flight-doc.jpg" Content-Transfer-Encoding: base64 Content-Description: flight-doc.jpg Content-Disposition: attachment; filename="flight-doc.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAsICAoIBwsKCQoNDAsNERwSEQ8PESIZGhQcKSQrKigk JyctMkA3LTA9MCcnOEw5PUNFSElIKzZPVU5GVEBHSEX/2wBDAQwNDREPESESEiFFLicuRUVFRUVF RUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUX/wAARCADnAUADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDsaKKK 7DEKKKKACiis3VWluZrHSraR45tRm8syIcFI1G6Qg9jgYHualuyuNK5an1GytSVuLy3iYdRJKAR+ BNUn8U6HGSG1W1JHXD5/lXUR6TpOmQII7O2t0BWNSVUZJIAGT1JJAGeSTjvWmsSIMKqqPQACsvav sVynjq6noWmanOLK6hNnckyEopzC46qePunqPQ5HcVcHiPSDjF8nPT5W/wAK9PubiG0QPO+xDJGg O0nLOwRRwO5IHtnnire0elJVGth8qPJv+Eg0sglbxT6ERsRn8BWPLq9jJOJNxWO5jzKhRiVkHB7d CPT0969mu54bWEPcOVRpEjB2nlnYIo4HckD0554q3gUOo2HKjzPwb4v06x0MWGp3u17RzHC5RyZI uqngds4/AV0X/Cc+Gx97U1X6xSD+YrftrmK6QvbvvQSOhO0jDIxRhyOxBHvjjirW0HqM1nzMGkzl x448Mk4Grwfk3+FPHjLw6wyuqwHnGACT+WM10u0egqlFKgvbi2NxJLMqrMUKgeWjkhQCAARlG6kn 14xRzMOVGKPG3hzvqkS+mVYZ/MUh8b+Gh11i3B9DnP5YrqcCm7BnOOfpRzMOVHMf8Jx4Zzj+2Lf8 j/hTv+E38Nnpq0J+gY/0rpto9Kq2txFfWsF3bOZIJ0EkbYIypGQeRkZBHHFPmYcqMMeNfDpzt1SM 47BHJ/lSf8Jr4eH3tRA+sUg/mK6fFLgUuZhyo5Y+N/DYPOrRfXa2P5U7/hNfDe3P9rW+Poc/lit+ KaO4ijkhdZIpFDK6EEMCMggjqCOhFTbR/kCjmYcqOZHjXw2TgatBn3DD+lcLrfie21bWbi4F3H9n gP2e1jJ4bkbpPYE4/ACvV1uoTeSWqufPjRJHQA8KxYKc4xyUb349xVny0/uj8qak0OyPJbfV9Jt4 RENRgJXJY5PzHqSPxqYa7pR/5iFv+LYr1QopGCB6dKPLT+6Pyq/aPsLlR5He6xpk8K28d9bF5SAG MmBGRzvJHIxjI9TgVtWWr6BY2gii1W1IBJd3mG52PVj6k13v2dfOL7jgjG3Axn1zjOfxpxt4mOWj Vj6sAaPaeQuU4j/hJNExn+1rP/v8tJ/wkeiZx/alr/32K7gW8IOViQH1Cin+WmMbR+VP2r7D5UcK PEWikf8AIVs/+/w/xp8eu6TLIEj1O0Lk4CiZck/nXafZoM58mPPrtFQ3OnWV5E0d1aQTRvwyyRgh vrkUe1fYOVGCCCAQQQeQR0NJWJ4tsh4Nsk1fRMxWwlVLiwJJiYE9VB+4eMccHPT12LaeO7toriFg 0cqB1I7gjIrWMlIhqw+ikkkSKNpJXVI1GWZiAFHqSelZK3l7rR2aN+4tOj6hKnB9olP3j/tHj0zT bEWb/VoLB44Ar3F5L/qbWEZkf39APc4FMtdMvL9hca5IqpwVsYT+7GOQXbq5B7cD2NX9M0i00lXN uGaaU5muJTuklPqx7/ToKu0ku4X7GC2pzafN5OsQeQpOFvI8mBvTJPKH2PHua06tMqyIUdQyMCCC Mhh6EHrWQukz6YMaS4a3Bz9jnY4Xnny3OSvsDkfSnZoC7RVe1vY7pmj2vFOn34JRh1HrjuD2IyDV imAVT01Rc+P4weVs9OZx/stJIB/JTVyq2g/N481Ejounwg/Uu5H6VnU2KjuW/ENhqmtvcWmnzLax wRHa8yttlnYEqQQQQY8KQ3zDL5A3RjECfb7mW51RP7TiLX9p9ntZdyiOF1gEuY+h4aQHOQpUkYOS ela6iS8S0ZyJ5EeRF2nlVKgnOMcF1/P2NNt7+C7t7W4gZpIbtVaFxG2CCpYE8fKMDqcckDqQK5zQ 43UIr+7tJbK4N5LbaPc28UkkDO0lyfNjcOSh3lkhIJOMF3JABQGrKed5o+1f2v8A2H5kvkbPtP2j O2Hbu2/vsbvtH3uPu9tldXbW0NrGY4F2IZHkI3E5Z3LsefUkn2zxxVugDgXi1GdbVdZTUJNS+02L RiFZTAFBhMpby/3WQ4mPzcgAEcba2NGa+m1BrO4klaHR8wGXzMm5dgChY5BJWIruyMM8hIA2A101 Zkj2ui2MkqxN5bSnCIcmSWWToMnALSPjkgDPJAHABzJtNXs7F59Ma8+3T3t+qxsf3aIftDxnYRtA MgjIdhk7gM7SBT7eK8uNHnjjXU4hJd2oKeZc5RDMgkCyShZT8mSxAVQCAOQ5PUW96k8zQlHjuEjS WSGQfNGr7gASMgnKMOCenoQS+a4hhlt0lfa9xIY4hg/MwVnI46cKx59PXFAHLRw6hbeIoraVtQlh haJbe48yVzLEI1DBxgQ5LeYWdyXIyFXJQixqUWoDxHdywwy/YGtbdbmWEsJtoefKxYHJ+YFsEMFP ygsVI17zWrOxvfssgunnVBIywWk02FYkAkopAyVPX0NS2eoxXwzEJR+8mj+ZDjMUhjbJGQMkcAkE jJxwcAHMywa3FatcWMt8+oTXd7EiSsSiRgXBhG1vlA3rEQxGcEDO0gUH+0llM2ifbWs4ni8uO/8A tBLyus0ZyJPnMYL27N/CArEfMDXUXN7HbTWUcgffdSmJNoGAwjd+eemEI4zyR9RI11Et6lqz4mkR 5EXaeVUqCc9OC6/n7GgDG8LQ6l9i36sZxMkUNsFlYncUjG9yCTljI0gLdGCIRkYJwrSy1TT9F0iK 3OoYl0+M3qktuQK8AKqAPkYRNMAEAc4z8zAGuvu9Tt9PEYuDKXkJ2xwwvM7AYydqAnAyATjAJAzk jM8Nys5UIJRmNZBviZOGzgcgc8HI6jjIGRkA4u+TXms7k6IbwwyrPbWa3LSq6ho4m3sXIcENHOqs 5yGdAPlOR02mx3F1Y3Ul2Z0N5LIyoXZDHF9yPaMhkJRVYjIIZmPB4GxVG5vY7aayjkD77qUxJtAw GEbvzz0whHGeSPqADi7e2v7LQLKBU1JLhNKhFikZmIW7IYuJccAA+UMS/IACBgBhW14hlhGuabFd SaiLdre4YpYNPuLhoQCRDyQAWGTwM+pFbtzcw2sYknbYhkSMHaTlncIo49SQPbPPFK1pE16l0yZm jR40bceFYqSMdOSi/l7mgDk8avDPHLfxXQ86xso7+W3Qs+QLguE8sEk7ygOwEgOSMcMGQS6nZQQx 28l4ZL+aWyi+0l2aDLvLDMBJ94CEsWBJJKIhwQ2Owml8mJpSHKopYhELsQOeAAST7AEntVK0uLHU 7wXMImF1bI0eJ4pInVHIJ+RwDgmMYbGMqQDwRQBdhi8mJYgXKooUF3LsQOOSSST7kknvVmiigAoo ooAKKKKACiiigDkfiWit4B1TOOBGRn18xa5jwvq0UHhXTIdr3N40ZCW0C5kIDEAnsBx1JArrviEg k8CauMdIgfyYH+lc/wDD6GOLwbZOIkSSUuXYAAt85AJPfgVpSvcmWxci0ebUJVuNdKMqnKWEZ3Qq fVzxvP1GB2HetsAAAAAADAA6AelFFdCVjO4UUUUxBRRRQBXvLGC+jVZlOVOY5FOHjPqCOQf09Qaz Jbi60gH+0f39mMAXqDBQf9NFHT6jj1ArboqWhplRWDqGQhlYZBByCPUGoPDwH/Ccaue/2K3/AJvT JNHezYy6M6QZOWtHz5D+uAP9WT6jj1BrP0bUlTx+I7iJ7aS8sfKaF8ZEiMT16EEE4I4OD71nPYqO 5saxpGp6he3NzazS2zoUtYCjjPlsrCSUHIxhpQxXqTbLzkqVng0u8gm06EQ5trHUpZEYMABA0Mu3 C54CtIIwB2QEAA4HTCisDQ4ptJvJtC1OBtMddUn0+WGe7aZP9MmK4BADHK5zgvtKAgAAEgGpeGxE 01vp2mB45LYx2DoUA0+cvIzSjcQUBLocxgkbMYGFB7WigDjrnSJ5rvU5IdKwJXjZ5ZvK824QSqZI lYMS0bopAWQqBkD7pxG2Xw4l5prrLpEEaf2hBNbWkqRk20IaESgAEqoOyRiFJBDc8kiuzooA5O80 C3jv9Umi0rdDPY29sn2NYkc7XcMoDEDAXyshvlIUAggYrW0qyWHTbNJrC2tZIcssMMYCxMcglQMh SQxyATjcRuYcnWooAwW0g3Hiea+m89I1t7dYmjuXRWdZJWYMqsNwG5OGBHJA71nxaVqkbs9sEguB FqYilcjCSTXCvCSOcggZ6HGMEZ4rrqrzQxzRSQyxrJFIpV0dQQwIwQQeCCOMUAcRBpf9oa95C6Xc W+n280L3MM0iHc5iuQ7OUdg7MHhDAkswI3Ag5OppehPBrdjdTWUS/ZUvYkkIUmNGnBgVe4Aj3gAc KCRxnFdDZ2lvY2y29pBFbwpnbHEgVVySTgDgZJJ/GrVAGDrUTzTR7tKvLtVB2TWN0IZUJPzKSXQ7 ThTgEgkcgbQTm3Wjapdxst4BNNJBpsc00Mnl73iuGeYqQQVwDkEAHnjkYHYUUAcMfD1/E8Zht32J LLI0YmGGSO8ikgjUE4AESOEXhVLEHbuJMk1jq95LcXNravY3EmoPPCbh4z5f+gmFXYKWBHmY4GTj kjFdrRQBwc3hwXkk5Hh/yIZpLMslyYXYtFOTJI5DtuLRyEZJJO1weo3aNnpVxFrkUxsvLmS7nmuN Q3J/pEDCTy4sg7zt3xcMAo8vgnC56uigDB8K6Omh6DaWwtlt52hje5VSMGURqrHgkZ+UZI4J55JJ q3ploYovtNwXN7cKrTvIACCOQgAJAVckAAkck5JJY6dFABRRRQAUUUUAFFFFABRRRQBx/wATLv7H 4E1DH3ptkQ/Fhn9AapeClKeDNLBGMxE/mxNUPi/qMZ0uy0eEGS7upxIEHJ2jIH5sQB9DXRaVZDTd Js7MZ/0eFYzn1A5/XNa0lq2RPYtUUUV0GYUUUUAFFZV1qtzorAa5aiOBmCreWpLx5PTcD8yfqPet KCeG5gSa2mSaFxlZI2BBHsRSUk9gH0UUUwCqOqaXDqluiSM0U8LB7e5j4eFx0IP8x0NXqKTV9GBy s/jbxF4edodY0MXyIPlvLXKiQD+IjBAPcjjBPSkt/jDaSgeZot8MjI8sh8/TpXWgkZwetY0+kS2k jXGiusDscvavxDKfbH+rPuBg9wetYul2LUymPi1ZYydF1UDp/ql/xp//AAta0P3dC1cg9P3I/wAa t2mqJczNbSpJbXiDLW82A2PUEHDD3GR9KuZPqfzo9kn1HzGFJ8WYQxEWgak2Ou5QD+maE+LMTEj+ wNS4HZQf0rdyfU/nRk+p/On7Jdw5jFHxXtwPn0HVQB1PlDgfnTf+FwaQRk6bqWcA48tOAeh+90Nb m4+p/OualtE0jUXjjjC214d8bAfdkxyhPpgZH4gdBUunbqCkSt8YtMHTStQyTxlVGf19KUfF7TvI 806XqIHXIRSuPXOf8/rVLULe7uGQW4R0IHDtjy2ByGHrnkEe9XvByC/0LUrC5Ae0MrqkZH3UfJK4 9jk/jS9nruHMMHxj0+Uf6PpN/JgjONvH5E1Inxcs2z/xJNTJBxhUB/rXOfD+GXw/411XRJ3+YxkA jgOVIII+qkmvUckdzRGF1e43KzOSk+LmnxMVl0fU0IHIaNQR+Zqr/wALeRmKxaDdsT0/eDn3wB/+ uu3PPXn60AkdDVey8yec40/For9/w5fKe2T+fak/4XBAAC2hXy9s5GM+nSuz3H1P51w/jO4lufEG l6dA53rHJMcnhSeA31ADfmPWpdO3Ualcnj+LsDjP9hX5XJGVwelIPi7bMgddDviCcBsjBOcYz9eP rUGnwS21tiYhXPVUclUA4ABPtyTxkkmptH05Lm8OqMjJDnNvHk7XPOZSOgJyQOOnPUjD9n5hzEq/ FfJx/wAI3qf4DP8ASkb4spG21/DupKP9oAH8sVvZPqfzoyfU/nVeyXcOY53/AIXBCW2jQL4j6jP5 Yp3/AAtwZ/5F3UMev+RXQZPqfzqC81CGxjD3MpXcdqKASzn0UDkn2FHsl3DmMVvi/Ep+bQL9fqR/ hTV+Mdo+dui3jAHBwynB9K01tb/VebtpLGzPSBGxNKP9ph9wewOfUjpWtb28NpCIbaJIYl6JGMAf 59alUr9Q5zlR8Yoz93QLw/Rx/hTh8X4Od2g3wPoCDx+Vdbk+p/OjJ9T+dV7HzFznKj4tI65Tw9qJ HqACP5VDP8UdSkiZNN8MXhnI+UyqzAH3AGT+YrsQzDox/Ogsx6sfzo9j5hznC6D4b1K/8RP4i8Sg CfO+GDP3GPTjJwFHQEk5+nPb0VHcXEdpazXEx2xQoZHPoAM/0rRJRVkS22ySiuXtdU1S6mgDxKLx iYorbJCeYQHkkkI52RqwXHds98Y2rXUree6e0WRpJYwR5hj2pKRgMUPQ4JGQDxkUozTdkNpovMyo jO7BVUZJJwAPUntWR/wkFtcyvb6RFLqlyuMrb/cXPrIflH5k+1ONvFqfi+Cyvgr2kNm1wsD8rNIX C5I6EKOxzy2aueGxHBFf2qgebb3sqyHGC2TuUn/gBUDtgYHSs5Td7IGrK5Jrii9NrpUZPm3UySEq eY442Dlj6DIAHuwrPjto7bxhqAsFWO1a2RrlF4XzyxwQOgO3rjrkVJYXrWejXnie+gf7RdqDBbsP mSPOIox7kkE+7e1PtI10nS5Jr+VBL81zdzAYDOeWP0GMAegApQV5X7DtZWJLu9FqYo1jee4nJEUE ZG5yOp54AA5JPA+pAqm+vw2Zxq1rdabzgPPHujP0kTIH4kVZ8N2sswk1u+jKXN6B5UbdYIOqr7E/ ePufat2Vo0hkaYqI1Uly3QDHOc9sVTm73RDaTsZ0ciTRiSJ1kjYZDIQQfoRS1yc1guk6Ne+I9LMl kZpxJb2QUiOWM7UUGM9CxywIwRuH0rob2/jsPKXy3mnnfZDBHgu5AycZIAAHJJIAFVGaaZTTRbor mLnxRI5ZrJY44I2Ad7ggFsHBGScLyCAeSSDgEDNdFaTi6tIZxsxIoP7tw4/AjqKmFaMpOMRuDSTZ DqGmWuqQiO6jJKHdHIhKvGexUjkGstri/wBGJGp5urEdL6NfmQf9NUH8xx6gVv0oOOlatE3KUUsc 0ayROrxsMhlOQR6gilrLvdMFtqUCaNMbS6umLSQhQ0JQfekKHgHJABBGSfqROdF1knP/AAkAHsLF MfqSai77DLtQ3lpFfWklvNnY46jqpByCPcHBH0qJdD1MEbtfmI74tIx/Q1MNFuu+t3Z+kMI/9lp/ IDl7i/mtTJZvt/tCPIZiMIF7TE9AuOcdc5Hat3wfZm30+ecRvHBcyB4VkJ3MoGC5B6bjk49D71I/ hW1uLqOe+u7u82ADy5WURsAcgMFAyM84PFb9JJ31BvQ47xHZLp/i7Q9fUYQzC0uCB2YEKxP4kfgK 7Hoa4bxLrkupJd6VaxRpCknlvNJ8xZlIOVHQYIHJz0PFYrXeo3LF5tWvyTyVE5QAnnGFwKS0bsG6 PU6K8cstUuJ7m8T+1dRURziOMi7fuDx19QfzrWtdd1m0eRY9Ukk8vHy3iLIGB75GCO469qpO4cp6 bXF+J7V7XXE1GQBIZoo4Y7nGRDICxAb0DbsZ9j04rZ8Pa2+swzJcQpBc25AdUbKsCOGGeQOCMHoR WvNBFcwyQzxrJFICro4yGB7EUnqhLQ421t5dYmMMsRjtoji45yJCOkYPcHqT1xgdScdIFIAAGAOA AKrR+EtGiULFbyogJIRbmQAZOTwGxTv+EU0k53QzEEYIN1KQR/31Qk0F0WNpHY01mCqWYgBRkknA H1NVz4Q0NvvWJb6zSH+bVWuPBejG2cWVlHbzgho3JJAYHIyCSCMjBHoTRqGg5bu41E7dJRDEDhry UHyxzghBwXI9eB7mrtlpUFlIZyXuLthhrmYguR6DHCj2AA+tSafeC+s0m2eW6kxyR/8APNwcMv4H p6jB71ZppdQCiiirEFFIHUuUDKXAyVBGQPpVO7luW1G00+zMcUl0sjG4ddwjCYyAuRknIxk4GCee lS2krsaV9C4zLGhd2CqOpJwB+Jqna63pl9eNaWl/BPcKCSkbZ4HXB6HGe1Z/h7w/barpcN/rvm6l dyMxK3TZSIhiMCMfKMY5461s63p/maRmwjWO5syJrYRqBhl52gDsRlSPQ1nz3E2k7EOpXf2GwkuM hVQrvkYEiNSQCxAxkAEnGe1c14o0doRcR6he3d80kcL2xchY1JmCyAKoAJCsuM54Jrp4ZINU01JG Tdb3UIJRv7rDkH8DiuQvtQudS0WyVVe5fSr6K3RowAk7qwGTIT0ZSOBnnk9qmq2ldGtNJsv+I4I4 tPuL0wNKkQd54o3KGdCxcoTnhcnJxyQoFaWowS23h6w1Dy7VZrBkmItUIjWI8SBRk8bCT+GaytI1 r+1jJZ3kADNCHEiAiOZCORg8gjkEHPQ81q+HJVksLvw5f5aS0jMaE9ZbcghSPUgZU+4965qM3dp7 m+IppJSht1DWZP7PnsNZjPy2MuJyOc274Dn3AO1vwq8f9B8ZsoIFvqtsJAc8GaPg49yhB/4DVDSI 11Dw0LK8BbYsljODwSUJjJ/EAH8ahiluLnwXBcyAy6roE+HUdWMZKsD/AL0ZJ/EGuia1T7nMldNG lfv/AGp4hWLcDbaVh2Az81ww4B9dqHP1YelUr+M6zrtrowXNrEBd3voVB/dp+LDJHoPerthFLZac ZL9wZzunuXUYG45Jx7AcD2ApPCUBbS5NTlUifVJDckHqqHiNfoFA/EmrtaNhSe7OhrA1H/id6xHo oObOAC4vj2YZ+SI+mSMn2GO9a93dRWNnNdXDbYYEMjn0AGT/ACrkJo7qHw7b20haHVfEd0TO6tzG hBLAemI1C8dzms32RMFd3Y+XVrS9vZNY1G8jj0m1crYKzALKygh5gOrHJIGO2SOtZ0dhda9qcmqX 5mgsnQRwWWcFo+uZCORk8lR14B6YqK+0u31PxfHbRRp/Z+mwx+YgT5VcElYx25ypP0ANbWrWr3mn yJFkzqC0PzlRvwQMn05rnq1WnyLTud9Gimudq/ZGdr81tpkFtIkMDSRusYtWACyxsQpQ8YA6EE9C OKv+HIzbG4s4btry1t1QGckEGc5MgQ91GV65wSRmuJt1dDpthJNNFJNqiJdCRwZ1IceVkHPy7ckE ZGa6gvqWnarrtzps0d/EJgTE6BPNcRjcQy4GRwDxgkHODVUWqe7JrJzlouhuz6rDbSSq0dxIsJAl kiiMixkjIBxk5xgnjgEZxmrMV3bz2xuYriJ7cAkyqwKgAZJyPQVX0e+tbPwbDqEExuw6eY0mMNNM xwQR2Jc4x24HauZksSLi5t7Vkie5VoriTbticxkvNI3sXIjB9Aa6VNnIle5z994n8RxaxfXFjbXE MVyAIibTfiIHCsCfXdk9stXo/h651C60K2m1WFob5gRIrJtOQSASO2QAfxrkFN7rdvbvJqY8+4Dw qojAA8skkZXGASB2yAARXX6BeS32kRvc7xdRExTh8ZEgODyOo6EHuCKmnNSk1c0nTcUm0alFFMil S4iWWJw8bDIYdCK6DEfSFgilj0UZNMaaMTLCzgSMCwTPJAwCcenI/OkuDi2lOcfIf5GgDx+3uHlj ty53G4k8wk9cks5P5D9aZNqH2awnugwMkrEwoDyR0Bx6cZqurwRaZA5uVjPkjOeqggAkepwCOO59 qow3i39+xWNEhVQib3IEagkAnGSevYHGayUlomy3dJtK5FoTu1zcW+dskyblJ/vqcg/zrf3i5kSR SQlzAVwequpzj6jJ/Kmadb28lzcnUJJYhaAFGtgXcEck4IBwACDn1FSvF9kvpoJWMjRt5oWMElsj IdRgEgg84GAQfWs1VhzuCbuvuKUZuKk1a50nhKTb4lU5I8+0cEe4IIz+Zrvq868PSgeJ9OK4IkWQ A+xQn+grvWvbVJvKa4jWTONpYZzxx+orZNIizZYrJ17Who1kjrGJbmZvLgiOcOepyQOABkk+1a3b Iqhqmlw6rZiGUtG6HfHMmN0bdMjPHTIIPBBIqZ83K7bjha65tupxset6zPCUk1NI5m/eMYo0Owk8 KMg5Xtzycdea3vDuu3N9cT2OoiEXMUayLJGCBKpJBOCT0OM/UcVxfiLTLnQL6CCCW0YvCXMgtQpA BIOBk8kde3Pau+0bw9aaSwuA5numj2GUjACk5wqjgDp7nHWuGiqyqPmlddjsrui6a5Y2fRjXX+z/ ABICARBqaHPPCzRjjA/2kB/FKlOtaal5NaPewpPCMyI7bdvTueM8jjOeaZ4nKQaR9uYgGwmjuRzj O08j6kEj8a8umuTeXovWW3udrFgJY8iQZOAW4JIDEZyOgI6CuudVU/mY4fDzrtqO6Vz1i7v47ewN 1HtnVioj2yAByxCjnoBkjmqUNjqWsXt9b32omyjtZAhgsAVcgqGBMhGSOSOAM4Nc82pWsHh68s/s p+yT2kd3ZQM5BCOQCu7k5WTJB9CK46TX9SXUpL4Xphu3bLtFcEZPPBU8Ecng8cmiU9jJQ3PWLnwp Y2tg8mjWscGpQjzIZ8ku7jnDseSD0IJ6Gq9zfLNpFnrdorP9lIuQgOCVwRIv1ALfiBTvBvi3/hIL dre7VUv4kDNtPyyoeA49OeCOxI9aWwjFlrWr6Y4HlM4u4Uxx5cgwwHtvDfn704tNW6MhXTs90aOn SiHWNQsPMVo3xe25HQxuTuxjrhwT/wACFbVcLbSDSLW0mDtt0S8NhO7clraTBQn2BaP/AL5Nd1SX Ymas79zghbmfUNQ0dX/4ldpOS4B5lMgEnlk9lBJyO+QOxzHPYQ3mthbcyRRwYkuRG+EMm3EYx03A HOccACrl/p+oaPrbGwe3ktNVnLkXJYeTLtycEZyCFJA45GM1X0W4jtNAGo6hcRKbgm4mmPAJJwP0 AAHtXJV5023t0PSw3I4Jdepb0/R7XTE/cgvIVCGWTBYqOg4AAAx0AHr1o1HT/tvlTQytbX1uS1vc r1QnqD6qehHcVgXvjUqSNNs90Y6zXJKA+4Uc/nisWbxPrLTCN79bd2x+6FqASD0xuyT9a51dO99T WVSlZx3R13hrVmutc1S2uEEF0wWaSAHgSABZCvqCNjD61raYRY+Mr20cfudVthcAHoZE+RwPqpU/ hXmon1bT9aN+1zPDftHjdcW4AdMY4BAyOg4reTxis95pM19b/Z7yzulIZMmOZHBjcAnkHBzg8cda 7oVYzha+p5zVpabFBvPZWVr+/KsCCDdOQQeCDkmpY73VIIxHBrF9GigBB5gIAHQcimUjt5cbPjO0 E4+gzXZyoi4+2vtd1ae4hbWpXs4GUOZIY2DyAg4xgZAwM+vStJ/7Zk1FL2TWi08cZiVjax4UEgnA 6AkgZPXiqvh6IxaHbFjlpgZmPuxJ/qK1OppKCtdg29kYUM2p2mpzWlpqjsgJuLqRoEJMjngZx1wM +wwBXVaTqR1GKZJlWO5t22Sqp4ORkMO+CPyII7Vy+nfvJL+4JB8+6faR6LhR/I0R6sND8RiSRN9v cW4ExHJQBjhgO4GeR6dK58RQi4cyWp1YetJTUW9Dc8Voq6QtwqwiWK4hYPKuQBvA57455HpVibWI 9MY299Y3NvOoyscEJkWQZ6oVGME+uD6ip9Uso9b0S4tVcFLmL93IDkZ6qfpnBrz6zMSC3a7nu7Ms TDdTRyyF4iueDycAn1BAz0rkpRjOLT3R0VpShJNbM3lv7jRobe1a2k+2zXEt/FZnOYnkJEYZR1wA zYHcjoASM9kdLS5XUhqhigiFvNtZFjCZJA+U8nJyRknJ5zW9oWifZdUl1IaiNShkiEcUzsXfrzk5 I4Axxj6V0EixKBJIFxFlskdOOTU1Kjb5URDDcyvJ6nnv2yx061ltSgvLMHzgjhoZopMHD5ABK8AE gZGe9dDoXiqz0XT5bHURILmGUkRxqzuysA+5icdCSMnBIA4rC1e5udSsk1SWUFEcTJbyKDGIycAH jJODk885I9Kz9S8OXem/66eBiXGCZMsxPfBBJ7Dpn046bRUqTSe7Rkkppq90j1yG/trrT/ttvMZL cqW3xjcQB14GTkemKwbS5ubHTLu9jeHyWCSGQREpKSM+agBAAYYyDjDA9cgHk/D99Do1rNLcRyzq wBWWC8MezGQcAAAknHX0pTqVxpmhx2siXUd5MHud25ZFjfgs5XOQAPQcZJAzW7nNpNrUyUI3avod j4WcXwnv4rp5Vc+W4B3o7DqQxAbqTxgAZ4B61vXP/HpN/uH+Rrz7wr9vlmiTSLwxtPKY7iJoPMWN FziTPTIOBwcEEccV0ur2+pWEllG+sSztO7+ZGtvGi+WqEsTgE9gOD1NXCorWJnCzPKYQ19pK6eSy oGSbOMhRtxgA9CTkkjrgfj1XhhtKg0L7LZQRzaw4Ikjki3NuyRkkjAQDng4x7muQtJmguoIlTIkh Xn0IGc/Tmte01W+0SzVNPl3TSyfvI5IwEIBGCDnOSM5zxgjHIpVKPNSTgtb6ip1uSq1Nq1tDe1LR TbaLdCWMwiKNsNHcFo5Sc7fkPIO4ocgDv2OK5qXVL0WkhlleZJ1jXcSFKgEkJwOVOTxx0HPYz3uu ajrEk0d8qRxKFMcUb4VGyDuJ53HGRgnHOewrOkZ2vrOzjI8l2GT1JwckfoPzp0qC5HKotegVa15q NN6dTpvDkrN4p0sO24iSQA4wD8kg/pmr19p95ceKblYtpgmvVjYlsYygY8ew5rn5xFBpUN4k0xkk kItY4RlpSSVYsewOSABzzn2qeS7uNLlSNXlt5luIp4LYAeYHJKtnAAA2nGDgEjjiolUTaS7mkabS bfY9cAAGAMAdBUbtsjZ+PlBPJwOPftXKyeOfLh87+yZfLM3kD9+uQ2ccjGAPxPWoo9V/4Su/ktZo fJs7MK8kBkyZnOSucY+UAZx3JGelaTqKEW2Zwg5yUUZWt37au1lq82kStafZWVQJhltxA3KR1AJA IIHU4yBW9oWrarceE7uR7VH1CwDQJGrbjI6KByOxJ5x3zx1rE1+6tNI1EmGzEkjR58pCVRpScgtg gYADk/X8aLXT/FNtdXV1cW2p2txcsDIbNIWjIAwOMk5AyM8k8c1z0pOUnLa50VYKMVG92iS71FFs 7a5aC9vJGkAkurjMIUgEkAMQMgA4AGBjqT1wNQ0+Ca0m1a2GIBIFaIwtGY4yMqSD1I45Gcgk+wt3 mp61JZyW2sXd/GsgKOs9kAMZIyCY+OOcg8ZrPaObWL2BIb2S/u9u2NCEKxqO54woHrjJzTlTVr30 Ko1pQldLXsacmhajrnhjSZjIjRxyfZLdGBAMZJw7N1IBAAA4wBUtjoWg2+rw2s5e7jaPCTSIywSz Z5RMAA4AzyTnPetzS9FlsNJFle6jNPApLeUuI40ycnGOcA88n8BU9lpsIggMd1PPaKRNBDJjYpwA DwASQMYJJIxWMqsOVpb9zRUZufM0km72Mqeaz8PXtrd2UMKSW9wsbW8AAkdZAQV2dATgEZOPlzU7 +Jpb7X1vLfR5Y5LaAwzRy3CAsrkFcYz0Kn8zWbdIJPFN5uUAWoBTK45kAJOe/T9TUdqSPE0qj7rW Yz+DnH8zXXQg1BNvc5a7TqNJbE+s6zemHU2OjhbO9tVhuPMnVihBOJBtGTgEfkK04fHOpJbRK2n2 0rhADJ9oIDHHXGzv1/GkKhgVYAhhgg9wa5nTxsso4/8AnkTHz7EgfoK2cEn6mO61NzV/EtxrmltZ XelohLpIskN1ypBByAUxnAI545rIsLS/8Q6zaw6tuaztiNwjYAAENjIA4JI5I6dBjNPp1rf3elNc PaLbFpipEsxIMZGAR05UgdODknmuPF0puk1S1k9F5eZpSkk7N2R19v4X0mB45VtFM0cm9JSSWByS BnPIAOMe3rV+SxtpXZ5IVZ2ZXLHk5UgjB7AEA4HHX1Ncxp/ibU7jT52/st7lvMdY54pUWM8kAckE Y6d+lWl1XX5NPgVdJ23UezzWeaPY474IJIz9OPevkp4PHOXvPZ23PQjy20Rq3uiafqN5DdXluJZY vu7ySMYIwQeMc5xjqBXB+INDksNZeCzsV+y3mWhiEgAG0DdwemTyB/8Aqq/deJfEEEN1FJHaxSNK VhlBZgDniMMBtJ7Akj35qa2uU1Kdr2aXzbxQUZSCvkA4yoQnI6DOeT64r1MuwWIjUtVl7va/5GFd x5dtSAaKq/8AL7dH/eKn+lKdJXdt+2yknqpCEkfTFP1K5kjTyVJiEmcyjqqAEuR+GAPc1ppoSWOl Q6pceSdXvV4tLqLzRISPkjUcFSoIyQfUnjp9LKSj0OJJsq2dqtlZw2yEssShQT1IFSs2xS390E/l UYXTUe2tLqGaGaTAFzPMZIGYkgDAYEISCA2B27dak6m3kvxDBJax20Ukc8DzmVVmAyDGTztIPfHb jrRGom7JDcbalXRVI0a1Zs7nTzDn1JJP86ytVPmazIu9h5duigqeeSSf6Vtaeu3TrUDPEKfyFc87 b7+8diNzzMQM87VO0fhx+tOq7QSLoK87mzoHiBtI8uyvH3aeTtWRusBJzye6kn8PpVzxCEXX4Y7S 3PmyRGed4QSZByoBGcehz1OAK5llDAhgCrDBBHBFXtGvUso7yS8keSW3gAhZ+cwgnCj3BOD9RXFC C9opJ2OurJqDW/6Fmz1iXQbuSN7iCC3mmSR4blcsCSAxG05AwM8gjNa2q602o2t/Fpc0P2SKEiS4 X5y5KklV7DAxknPXgcVyUasMvLhppCWkYDkknP5c4FRMDBMHtvkllDRsq8B1KknI74HOapwg58zR F5wp2TOlFsLv+ztORQVmaMuvYRJgt+HAH410EmnQ/wBqSkSzL9uHmOAFIBjK4wSCR2474+ucHSjP NqBaz3b4rODO3bu8tpMvtLcA4HGe4FSyz38dzZxlp21GIvJJHcyKVxkgEbRwpXK9sk5xxU1+ac7R ewqPLGHvK93uJqWkC11SAS3DyWd1LuG4At5wJfBPocEg9eCPSqOrknULvJGf7PKrnoCXI/nitLUd SfWZrK3isbq38i4WeaSdAAoUHgHJBJJ7dqzPECf6SWHGbYdPQTKT/OtqTmqTclqjKqo+09zZnb+A Lyz/ALGuYI2MEsMxeW3dv9SCAAQehB2ls9MkjtXNnWNQ1PVorqS+iM8bmye1hjBj2nLSENuIICgH Ix0GfSuavTHJdP5V15E23yZYckGdSQQpA5YHHQV2PhjQjbJqOpTwi2nMUlssIAygAyS2O5OOB0Ax WEG5tdBzSjdvU88dxb/2fLEjvmIrIAMkHap4H0xVma7zEwjjdyB02kAe5yO1RyM1vbW04QuoCAqD gnMY5H5frQuqQE4ZJVbGSChP8q9OjJKLTlY82vBykmo3sMiaQ48y2MhUgrIAAc+pBxz+hpYBKdYg Z4xGI0kkAzkk4OSccdcVJ/acYUlLeeTBx9zAB9CT9D+VRWtxJdXUzvD5apbuB82TzjvU1HTto7su iqnNrGyNmK6tdM1WG6lTakBeQbVJ3yGM4yB06g59uayhcSG4WSUEXYnSaQk5MmWAJyOo5P0q7qhj USh3WNmhPlEkAO5IVgSf9gnHp17VlNIZGhE5WOaOVFwSQxBPOQegxz1I4rz6i/eXR2XfKl0OvtLS O/0+dJGdR9tkcFCAchjjqD6Uw6Gbm+K6deXUd2V2y3CSbRGowcHaBk8jAz79BVnQxnT2YHIe4mII 7gyHmsu6165tLy9XSWjHnbVaQgE5XIO3tjnqfTAreu7U79WXhqTqVLJN+hf1SKws9S03TI5nnmUS i4MhLuxZAAXb1wMAdh7Yr0TwlfnUPD8HmSeZPbZtpmPUunGT9Rg/jXhrTSWVxHdSSSSusokdiclu eTz35xn3r0PS5dR0qymuY7qGCyvIY7i4nbkwtjkouMHK7Rk9xnB6VzxnFU1fe504nDzhUtbpqem4 5rzrTrhbnX9dluSFv1ujGY2IykKgCPHsRk56ZNdV4ZW8XRI2v5pJmkd5IzKQXEZYlASOpxj88dqk 1Hw7pOrTCa/0+CeVRjeyfMR6Ejkj2NEo8ysc9Ofs5Xtc4vVtSS6tpI4JgljHIkd5eZ+RQSAY1I4L EdccAdeSBWjY6raajJJHbM4aMBiskTR5BJAIyBkZBGR6Vb8QS28Fuvh2ytY2kmi8zylPlx28Ybhz jn7w4A6nOSBXP6jfDw5aIiyG91WdQBJMecDufRQSSAOpJ7kmsJwirRW51U6s3eb0RTuG3eJNXGDl TCP/ACHVa3B/4SZz2+xj/wBDqjorzzajqMtzM0sshjYyNgZ4PQDgDjAHpWhbnd4icY+7Zj9XP+Fe pSVqSTPOqO8211Ndeoz61y9vcRRxbJpkSUM29XYAglieQa6iqFykup38elWshiMiGS4mUZaOPOMD 3JyB6cmnUaiuZ9AgnJ2W7My3aTUJjDpkRupB95g2I0+rdPwGT7VtJ4SZwst3qBaVASFWICNSQQTg nJIBODkY61vWVjb6daR2tnEIoYxgAd/c+pPc1Uv2GpXR0lGPllQ92ykjCHogI6Fj+gPqK8yeInN2 WiPRhhoQV3qzkLzS9OuXjmtNR06REcB455vJjcjjIAJyCOCTknHBxXX6Elrb6elta3FvLtJcrBLv VcknA5JAHQVmaNdnR7DSIE0K5kewMi3u23GTuyAUJxv5weD0qprOjaVbFdcuJptMuHnaYxx4Ltkk hAAcA4wDjjrmiSTSVxU2021GxZ1eP+0Li5tIoZMqrRCRbsJECVBPmRk9ADnIBBz1zUGqTW98kTaU vmXdsAh1IOI4kA4wXPDgnqBn6iqlrInifWTNcxoLdgWa2jGOB90ysOWJPbp+VJrt3NatLCExDC4M cSqDEFwMAgdDyTW1Oi1Zt2saKm5txfUt38cQvLd7ks0UpEJjGcsAS5HHrtA/GtrUJIrMXEt7eR3N yYQTLEzeYHJIk2noEAB+UHsMjPXnriO3+1SDVrq8tcSiSzvIX/dx4AwCAOCMHk8EHqKkWa4nmNvr V1C72+HEoIAukJJR8k4AB5wAORk54reT5p8ux5yi1Hm3RZMkYt57y9RIxMAWjK5EaAYjjx3wMDHc 59aoTw/aBeXEAaICGSKWN8gghTwV6ZyQc5z1FXBcpKV1GWJnsLZwYFxg3U54XaD2BJ5PU89BVEXS x2UtvKHnnumcXE8QBjErgnGc84AxgZwBziqU03ZbLqDg0k3uxLQSRQ2UkKuwlSPeMkjG3kkdscEH vgjvXMq5S3trokkAnzO/DHk/gcGup0sj+w7Qjp9nX+Vc5aKG0+AMAQ0YBHqMUVtEvMugrtk/0OR6 iorq3S4hZGBzg4I6g/57VBFOLaQW1wSAOIpD0YdgT6jpV2sDrTTViG3iMKFCxZcgqD1XjkZ9M9Kv aTaG91CdycJawlQR3dwR+g/nVR3IKpGhkmkOI4x1Y/4eprq9I08abZJCxDSsTJM46Fz1P07D6VpS jd36IwrySXKjI0xZ5L+NYbye0EmnxMTAQC2CRgkg+vat62tYrUN5e9nc5eSRizue2SeT/SsCznit NQsWct81rLCAFJLESDAAHU9a0ZLu8lcxwgQOAD5YUSSDJ6schVHsSTW0Uk27anK22rX0NWsTXoHl mtNokMcgkikERAYggHAJGB9360WGrxLNPFe6naybCMOGC4POQOmQMDnHcjtRrOrWkVgLiG5hlaGQ OFSQEkcjoD71TkmhJNMwrWGO7khezVReRAOkkTEeW3BDu+OoIGAOAQeDya7rQPEGmrocj3+uQPcX YMkqTOoaNyMMOAOCRkcd65DRLqG9mjtfL2WajLluPPbBJJJ7ZB479/SuwVYyoKBCpHBAGDWMIW1T uy5O+lrHn8F1byQQJOJY9pj+VkILgAgkeo5FXLdYtXms7KFH2xyvNIwHMZOAAcZwMKMk9yfSuwub O2vUVLuCOdVOQHUEA+3pT4LeG2iEVvEkSDosagD9Kvkva/Qm7V7HBmSPT2vbG4Rl2zLJCzgJvIJH IOMgg4yM9AatXf2S3sYb5H2Q3EciAkc54449wa7KWCGcATRJKB0EiggfnSiGIRiMRJ5a9E2jA+g6 UKNr2FzPY84jnF7qbul4ih/kHmAlcHkA88A5wfce9WIDLHqVtaMm2aKTaIpovMVQeCQfTGSBnFT+ K75JtQWzitQpg4aQjaXB6qPY/TqOPU1E1h4oIhdRhLq3Ia3kJz5kRyCCe+Acgn09euCguZtuzK1s dXYXNppmmWsNzcwwsyFgGIXqSeB2HNcRbzrGyq5JOOoBOOT/ADHNaMQN9frBbSCR5XSBCDwQAFB+ nBP0zWjqc1oNQjsVGNNsFMKMpODKcFnJHOM5Bx7msqk/aPkasketh4PDpVIO7erS6GJMpmQnGVJV QCDyCRk4/IV2egam9oP7Mv03WLyvDaTMcjAJAjf68gE9elc7c2v2KaOYsfsyyI8iuQXjGQc5H31O OCOfWtt2tv8AhG7iWbEkLGSRSp6kuSpB9c4wauFC8GpbmeLxSqVIzg+mtz0rwqyf8I5YxLISYkML KeqlCVK++CMZ74z3rbxXzyY3mlNzeO0t253PICQQT1xjGPwrqbD4j6lpdm1pdQrfyqmYZ5H2kAnA 8zjnBI5GCQDnnmkttTgdrm/4/ntbBrK+gmC63E22GMDPmxE/MrjPCd89j06151eB9Vu2utQkMs7g DKkqEA6AAHgD35qSe4nu7qW6vJmnuZTmSRuC3oAOgA6ACq9xIYoGKn5z8qfU8CiyvfqO7ta+hZ8O TObxgx3GSA5b12OQD+INbtkobXL2QdUgij+mSxP9KxNFjEWrRopyEtWB9/mHP581uaWd19qh9JI1 H4Rj/Guun8C9TGW7NSqEF8mia3eXd5HKba6ijRZY0LiMrnIYDkA5znFX6FOCDVVIKceVhCbhJSQ6 PXpNXBi0KF3ViQb2ZCsSDoSAeXI9OB6mtKwsYtNtzFEXkZiXklkOXkY9ST6/yGBVLwzN5miiI48y 3mkhcdwQ5Iz9QQfxrZrxJ6NxXQ9mnqlJ9SteXcVjaS3Vw+2KIZJ7n0A9STgAeprhNStr/Vbl7rUY LhGUjy4VUlII+CTkcE4PJ65GO1W9b1cX+tRwW9yiQ2MoxuGVklzgsTjG1RkfXPtWrqetnT3kVbZp BGmWYMAASOOOpHTNdlClZcz3Bttp206FXQ9LkVYJ2lAhiJMaCPBYcgEnPQ9enNWb3RWuJZZkuCWZ g6xuAEB4zkjkjHbtUOlayZLlre8uY3LhTEwXGSc5HHHpjvzTtU1kwPcW6Zj8oLvlBG5QcHIBByMH GfX6V1DfPzFfeL6+TZIWgjBJAAKvgjv3Gccf7BrR0COCSK7sp4onNrcFoo3UEJGwBXAI4HXp6GqN 9c3TQoINHgiuolCLc2s2yIqCSQYSOnJOAScnOap2+phdRgkjukgu7gMEIUPCUKho42IIO8nIwSCC c9ODnXXPC2zueXQmoS7o19bt4zcJNeQXWolQfstjbIQo4AJcjr1xk9uADzWbbSpcXCpeERXKIRBa mEwpCpBB8sEDJxwT1+gp1or6nD9qvLi6e4LESRtI0axsOqhARj8cnnrVj+zoWmgdpbgiJ96RvMWU HBGcEnHBPQilRoShZvUurWU7paGVohz4etQT0jIP4EisOz/48bf/AK5it3RU8vRhHyPLaWPn2Yis Gz/48oP9wfyrWrsgw+7JXRJEKOodT1BGRVUWAjUrFcTxrzhQ/A/MVcoyAeSPoTWB0NJ7m/oFraJp sN1BFtlnjBkkYlnJ7gk84yOla9YHhq9txZGxaaNZoJHVYy2CVJyCAevWt8gjrXXBppWPOkmm0zk3 jNlcaoYnvEuvOJjeMDy8NgqCSOBknPPvWvLbRxWhbU2SO2B/49o87ST2J6uSfzPY9ai1OOMSX0bv sFxbeYT6bQQSPpkGq4uo1sodW1KXLlAY0xwhI6KO7Huf5CnawFSbRdMkSS8vLdbOBQQkSHaQPVjz lj2A6dOTXOCzQRElA5EJPC4xwcZOMZHr3xXSx2V5r00k73UcCwOFSEx7wpIBznIBOCOfyqSTwvet Okwv4pGQj5HiKqwHODg9M1y1Yym0oqyNqbhFNyd2Zs9uCLO0t4QboRwhIzwAxDEkgdgDkn3rtNNs l07TYbOJiwiXAZucnqTj6npVHS9Je0ubm9vHSW8nIBZAQEUDAAzz9fwrV6VtTjZXZk3cIPOEY+0F DJ3MecfrT6QNxzS5HrWggooyPUVBFdx3BYRhwVJB3IRyPqPcUAcf4tgNlq8d2ARBcriQknG8AgE4 9sflWPqAI/s4gHBs48HIHrng9a77V9OTVtNktZGClsFHIztIPB/p+NZMPhqZ5LNNRnguLa1UqEWI gkEYAJz7CuecG3oa06ii030M/wANLLYabqOqRK+IAI4jjIR2GC5x2UHP4n1qC/s5NJYnLy2jdJCM lSeob6nofeuj0m7Sy0W6tIoIHjj8+doCN29ElIdcHvtxjPqKxrXWtOW/k01ZDNp748mSYEEAjPlt n0PAPsKxpxU24z+TOtV5UpKrTfqivpd80d/b29u0MyMHVUkG4RgjJIxyBx0962lSNvBn78AL9nMm FGMHJYEfjjFZaWw0/V5YQqCK3tJJYXCgPg4GCepxggZ7Gujis/PGkaSuD58sSsD02IA7/hhcfjXR BOEWm72OWrUVWbmla/RHP6hp1/okqRarbmEuAY5xzHJkdj2PseaqSwJKrBxncuMjqB14P15ru9S+ IcNy81qNCS/sdxAaaZQJQO4UgjHcZPSuLC2Wq6kU8PRSWMDwmQQ3Th1MgIBCYOQOeuT06Vik27IV yGISCMCVw7DjcBjP4etQITc3Jk/5YwkhCOjN0J+g6D8aedP1mecWrxQ27OQMmTBI74Oefwyamlik 08rBcwm3IACk8ofTDdPwODVOLSu0K6Leiru1Wdz/AAQKB+LE/wBBWvpAzc6o3Y3AH5IorN0EFrq+ PoYx+hP9a1NDbzLKWb/nrcSsD6jcQP0FdMF7qIe7NKiiitCDPaW50XUJNQtYWubecAXNuv3jgYDr 6kDgjvVq78Rw6lp/2fQpjLeXBKbcbWhGMsxBxjA4B6ZIp088VrC007iONBkse1Z80UsjMRG8FxqK iGMgfvEhALOxA6E5wB2JGa5KtCDlzdTsoVZpcvQx9L0sTGYpMLOxhUpcTo4JkIPRCegzxnv061pa h4atn0p7rTLq4Zlj3ANMXWYDnHPfjjHQ9qyrm7SO4R7K2QAMNkag4UYA2Hgc559q6DQzd/al2ySt AuRKjgBVPXC++T2zx+FFkd8qbS5m9TN8OQGQWoUtJC5LuuMYI5BzjpwPz+tXPENjNdTSSS25MaBQ kw6IvGTgck5zxjpVvQ7uSCaXSnjBW3lkVZA3YHIBGOOCBn2q3JrVvBdyQzrJGqEgSkZUkDOBjnP4 c1aHGcm+a2pWurlbRF+UyzSHbFCnLSN6AfzPYc1n/ZVYDTp5gQs/n3bxkgSXJGQikYICAAkjnp71 eEC6PKywTG+1yZMNPIMLAh74HCjjgDknrxVa1054pVkdwTGT5YPJ5OXcnu7fkAeKmLdVp20Wx5Uk qSavq9zQijSJdqAgE5JJJJJ6kk8k+5p9FFdRgY2njEl/D2S7kAHscH+tc/axSOFtreJ5pYvkKxjO 0g45PQfjWwtvJc69qdr5xjQhJguDhwVAOcEHHA6HvVsRyQObSS4itLaOPzCbdPLyM4wSScfUc+9Z SjzJX6GsJuDbXUzRpcMLBNRuS0rDItLQEs34jnH5D3qzJY2UMQlubS0sLZSAN8avK/scggH2GT9K ik1aG1jMOjW6KpOTPIDhvcA8sfc8fWstt0kpmmd5punmSHJA9h0H4Vm5RjokaKE5u7ZQs7ZFLQTx AiUGRAw5U5wQPQgYNadtqV3pOJElee0U5khkO4gdypPPHXBqtdRh4CdgcxneAejY6g/UZH407UbS N7yG30lMG9gD+WrBQB1zyQBlQc89qhNpOSdrFzSTUGr32Y/XPEtlqFni0SYTYKfOoAKsMEZBPPAP 4Vkz/bNYR7yX5baBdqjB2qOgA9T61FcWUtncGC7U+cACU3AnBAI5BIwQc1twYi8GwRk83DlR+JJ/ pU+0c9SZ0lBLzLGi65DZxXKOAZHcMoZgo4UA5Y9+Bx1ORXR6VqS6paNOsbRhXMZBOckdSD3Fckmn DVtUis7YbYrcAz3AXDEc4H1OePQY9DXawQx28KQwIEjjACqOgFbQba8jCVkT0U0N61DE9yZD5sSK hOBhySPfp3rQRYooooAKMk96KKACq19ctZWE9ykRlMSFtgOCcf5zVmmEggggEHqD3oA4K/1qO6iL LaxW91KDmSByGII6EjlgRjINUP7HD6BHfopdxvEmD0AJAP6VrXNiNJ1WW2A229wpaF8EkKTyox6H H5CrOlRed4XubRSSVEkeR3OMg/rXK731NFsZELalLZ20jxNKm0xeahDMYj1BHU4I6/hXS3msxgPc Ww1CCdIJI1YW4xhgM5yDjoORg9ax7G7aKITRrguFaWAnG4sQA6E9icAg+/4zXOpLJbMrR7VJG/5w fkyAxGOvBNY+2mny2TTNvZQte5nZ8+GG1jYY8sGVlOcDGMZ9Sf0zVsxIUVCoAXG3BwV9wRyD9KHj t4dTvYrdEjAkAEajAwAACB6Hk596dWzVnYyWqLdvqs0MfkaghvrX+8QPMT39/rwa2ICl1ajyXTUL FyFKyYLL7Enrj0OCPU1zlLE0lvOJraQxTdNwGQw9COhH6+hrSNRrRkuPY0Wj/scTXWn28xtceZJH Jgggd1bJI4HAII+lX/D2DoNsw6PuYfQsT/Ws+OW/vdDcTPbRWrQsD5aEuVAIOMnAJA9619GiEGh2 KAEYhU8+pGf61ut12sQ9i9R1oqlqs72ukXk0Rw8cLFT6HGAatuyuSc9d6i2pa0RA7mK0cCFUGdzg 8uR0IHYH/GtibV0bxCl3FNmFIo4ipXJYOSxwOoPT8qzrDw/PbwAxWs24hdhZwATgEg4PQkmk1yzf TfEDXkyvHZSkbJYRgIdoGD6dOvQiuVvqz1oQhBJN+p0A02HVHmukvJhFI24KF2lJBgZOeeMdCKje 4Ol24jspo7pjulleQg7iMDAA4HT8MVc0+3+06CIBKCZEYGSMgnBJwSQSCcEZrlr+2upCIlaBSshj 3ISpYDg8dhx0pm0LSdm9DT0/N3rOsXmnyAtiMqBj5i0YyCenBB7dayr6K8FyGVpYV8weYZmBIfpn qc//AFqueHr+Gwubz7Y4XzCqLIDkHywAen1/Q11EdnaNO13HEjSSjl+oYH2PHNJbChJwu2vQoW9v FaxlIlwGOWJJJYnqSTyT7mpqxz4n0rAImkP0hf8AwpI/E2lvIEMkkYJxukjIA+p7fjXQpRWiZ4/s 5vWzNmimghgCpBBGQQcginVRBiX9jBPrkbXMIkEluQpJIKlWycEEHo36VzGpCez1iaGK0kuY1wyZ Zn2ggY65xyDXX6sDGbK5yAIbgB/o4Kn9SKrz3J03UPOWGSWS5i8tY07upyAT2GCck9MVnKKafqXG TTujmzHqrbPMt1tRKcIJOXc+gXrn3OAO5Fa1l4eAhLX9xPJOxyQkpAUenHU1fsbJ45Hu7xxLeyjD MOkY/uKOwH60l9qBgJhtwGnIGSRlYwc4J9+OB3+lJU4xV5FOpOTtczdQh0vS41Vi7TycIklwwH1P PA/nXPz3b298vkyPuRNmYiVxkcgYzwBgYqScEt/pFwJzdAuWABdcEjDehAAPpg8V0PhyYQ6cLe1h BmikPnB3x1HDj1Bx09j+OLtUdlojZN00pbv8jkZLie4nDOJWkb5QWySTwAMn6AV0GoubRbWytwjP axqAhGS0jcAAevf863tWtLu8gt2szEk0MwkAlOV6Ec8H1qppmi3Sag9/qcqPMSWSOPO0HAGee+Bg elSqVnZbEzrOe5o6Vp66ZYrACGlYl5ZO7uep/pWgGB61HRXQlZWMHqS0oJFRhj35pcigVh+aMikz mimFxcijNRybzGwhKiTHylwSAffFNiEqqRMyMc8FQQMUgJic0lIWAppYmgLGX4h086hpzGEH7Tbn zISOpIHI/EfrisjwtdRSpPCileA+DyD6/wBK6ocHNcxcx3Oiagz2tlJdWshMiiIEmPPVe/GQCPqa znHqi4voY10Ftrg2E8T+VBcApMFPyxk5wSOf8+1aEup2V1FDHcy3N1FbgrGskRIAwB2AzwB1rT0y 4vLzVRcNp01pH5ZWRpDw46gYwOQSefQmtzOOlY+xU7N6WLVVrS1zirOa3lQQalGHtVcpDNgrJBzw CeoGMfTvWo3h1dpEWo3agjgMQcenOM1heJbspqt3BbyKyybTJt5wcYI/QZrR0XVJ7WJobtSbNCAk 3JMQJOA3tx17cVvBxvyy+8hp7oItGnZvs8V88d8oJZLgBkmX1QgZA9R1H61TuLbxBZJI8tmjRxgk yLggAd+DXW3FvHdRgMSCpDRyIcFD2IPY/wA6p3F1NPEmm3JAuZJEO9RhZYwckgdjxgj3HY1UqSQl JjLpTaeF5E6MlrtP1Iwf1Nb0KeXBGmMbUAx9BisbVj5kVtbn/l4uo4yPUZyR+QrYuJkghkmkOEjU scegGa0enyJ6DZ7qK32hyS7fdjRSzN9AATVW8N5dWc0H9jX5jlQoWKqCAQRnBOfer9nOdOgdBGLj WJ08yWJTxHnorN/CAD9SckA5po8X21s5h1a0ubG4HVTGZFPoQy9R+FcU8RN35FodsMNG3vPUz7Hx EbazgtL20mS/gjAkif5CwAADDPXI7fWrlvr0M9wYruNYoJUDRlskkE4wwxgZz9KTUNO07xrZJcWd 8QY+AQMhTnoynBB9wQfrWNdaY2iRrHLp5eWc+TBLDdM6M5BwTGxyMAE85ApU6vNo9Gb6RWquu5iT aJdwR/2pb3QtILlHnRYw67VBOF+UdcAeg5rfn8OCKxhufLE0piDXIuZ2OWwDn0ODnjFS3t7NqVoN Mj0WJfs5jBDXClljBBIGRnkADI461oT6zttpV1KwMSMCAQwkjPHQkDI+pGPerpqdm5IzhOmpWTuc xZQT2l26yskYCcR78blz0B7fX36V1Opan/Z1rai3kiiLAfLJztAXIBGcjPAzVSx1HTI7YQ3NtEnl MHBjUyxkHo+cHHTv6VW1nTJ2lEcUkksFyzSDEe4hicgZz0OepxwK0O26lJX0RyNJgYIIyD1BpaQk DqcZ4oO5pdTo/C1+QZNOlYnYN8Oefl7jPscEexrpq85t7w6ddwXgBIjf5gDyQRgj+VbyeOdMYgND cr77QcfrWkJpKzZ89iqPJVaS0Zu6lbG70y5gU4ZoztPoRyP1AqhBOl7PazKePs5lx6FsD+hqNfGG jEAm4kU+hhOf0rnV1owyXcelRtMzfLC5U4jjyT0PcFiOeOB1pupFa30OdRb0SNnXdeTSlMEOHu2H A6iMHuff0FYNxLLDLKFkZ/3QcsMkSAMck+54OfoOlN8N2X9o6lM92BJ5ZDvvAJbJPrU13dTWCz6c oBWQSEgjOQBjGe3Azx3ArCc3N36FqNjWtkSPTrgyANZ3IeKdkUFoTuJWQdyMEZH0NZcM8+kakJuG YDLCMkrPGf4lPQjuPQjFPttVaztnhUmLJCyo5AmTjGVBwDkAA+hBOOagufst1AY7H7STJIAiyODu c9MAAgepPHH1qLWd0aRnZOL2O7ilWWJJIzlHAIPqDyKcDmqthAbOxgtnfeYkClvUirVdCdjnCigG iqTAKKbMsjwssTiOQ4wxGdvPp3pY1KoAzliB1I60ALS5xSUUAOyfU02iigAooooAKKKM0XAUmszW 9TGlaZJOCPNb5Ywe5Pf8Ov4Uur3cllbI0bBBJII2mIyIgc8kfXA/GsWRkuJoDqd8i3Vm5IjnjAjZ uOcjGRwD6+1ZznYqKuNs9EOn+Hb7U77m7mhIjD9UDcZPucj6fnWcPNLxwSEld0cZVumAu9s/XOPp mrep6tNrDpDI6qY5AdkLb4wB0Of4iSeB2xjGTTJ547h44Yy4uYyxkAHynPyjB7kbsZ9u9c0U1q92 bTabSjsg0LWpbBjZ6ipSHd8rnA8ok9CPT+X0rc1MiK+0u6zlFmMZI6YcYB+mQKyvFsCW9h5iHb5r hCgGASMnP6Vg2WsyxWEtnKxaLh4iefLcEEfgcYP1rphVsrMxcdbo7oqZ9fs4yMpbxvMR6E4UfzNS 69IF0poQ+2S4YRof7pzkk+wAJP0qjperae0lzf3F5DGbghUR3AKooxyOvJJP5VS1vWIrm6hksZ0k hgjJZ1PAd8gde+AfzqpSVm77lU4c00mdRdW8eneH5DaykjiSSYsd0+SMkt1yfXt06VzHmXrXrJvI hBEjAOHKgHI5POcjp71q+E72znea1WaMkouId5IOM5OCOT0zjjFbuopDbWbXC2sLNDygKDC8jJ49 Ov4VCtbQ9SEoxdlqY9v4VSRWujcXNles5Jkt3CEjtkDjPfjFF6l9pktpcalqBvrSNypLQhWhJBAc kckYyD6ZzTZfEczB40kgSWM5DAZEoPIA54461e1tpLqwtzbAyRs28ywjeVAHBHrnJH50uVXvbUiV G+j0uE1tDepG+TkDMc0bYIHqCOo9uhqA3FxYjF6pmgxj7RGnK/76joPcZHsK5zTbq90o/KVkt5AJ FtmIBYE/wY6Hvjoc11VneQ30ZaEkMhw8bDDxn0I6g1umn5M86rSlSdnt3KT6VbXKefp8n2YyjO+D BjkHuvQ/UYPvVyPWZ7JAuq2bIijAntQZIwB3I6r+o96ik07Y7TWEn2aZjlgBmOQ/7S/1GD9aI9QE bCO/jNrJkAMTmNz/ALLf0ODScU/IIVZR0T0OEQNNMsECGWZukaDJP+H41cutDvbYxq80DTyf6uBC Wb35xgD1J44rZ0+3gsYWh0WIMTxJfyjIP+6P4vwwPc1owWsduWZSzyv9+WQ5d/TJ9PQDgVKp3Wpv VxtSb00Rzx8M3ZhDC6iE6kEIEJUkHOCSc9faq9uGmhDkpvBKsrxDKkHBHBrrndI42kkYKijJYnAA 9TXNacbK61Wc6i7W1tO7SRt5nlH7yjJJGOgJx3rlxdOKirbhh6k5TbnqindCWCMNti8vIDFIgCo9 cHIxmo4UM0wjDloQpMoyMH0z+vFa+qR2FndwppNxJehkYuPPDgYIAOcDBPPFZtvCZTMsiiOESnMY xycDg47D071w3tHU7LXat9xb0Ah9bvmTmMxJg4x7cfrU8Nrb32uXsdzHu8ohkOSMZHI47HNS6JEP tt/KBgYjjBxxkAk4/MVHHMLTUdQuCAzOQsYJwCRkcnsAFJPsK7IfAjz6nxv1LGs3cccZiwu7GZGI GVBzgAnucH6AE+lQaFp5LtqVwDvcEQAjGFPVsdiew7DFUrO2bWNSaN2dreE7p2IwZGPYjsTgZHYA DtztSXl1czyQ6bFCUibZJPKTtU9wAOSR+Xat4LqzNvoXPtUP2gwb/wB4MZGDxnpz71OpI6VnWeox ySzW8roZoSxkkjUhMDGSSeh6jGexrNvr0XYgnFxNaiIqDEFySzcgAggZwOQeADWt9CbHSqwb606u f1HVJHsLaWzcQtOWJ3OAVUZ5BPAGcc9weOtXIdbs5CqRyPMeFLRwsUB+uMCi6A1M0uaZuHQ8UoIP Q07sQtFFFFwCiiii4C5pM00kDqaC47c0XYDqazY4HJqtJNcecypbgxqMhzIBnjoB7H19akjYtGGZ ChIyVJBI9sjihIAljS4heKVQ8bghlI4INci9oLW9eyuyCTgxTscbhnA3EckHhT6cHua7Cs7WNOOo 2REWBcRZMRJ65GCp9iOPyqJxutBp2DTrWySEy2tqkMhJDDHKsOoJPPBrmNPtkj11xwVYRjg/7S5B HY5B4NamlaiwO+XOcATbuCQOA591PDe2DU2oHHiGzC4wwXOO/JP9KwNBniiE3Q0+3H/LSbB+mOf0 JrKSxtLaSSFrRLgxNjzC5UkHnBHTIyPatrXFlNzpzxbN6ytgOcAnaTg+mcHms6XzHvt1vsR5ztkg lJBRgOTkdQQB9a5asnzWvpY3pJWu1rcW2i0qUshsisinDJsZyPQ5GRg1d0Wzsnmu50tkXZJ5SBkI wAAScHuSfyotUhs0IknjMjnLsSBk9MYz0HakstQt7TUpYWniMV2Q6OGBAcAAg+mRgg+tLBzTra3t 57FV0+TQtXukRPma2iQSZy0YO0OexBHKsOxH45FEWru9sIdVnkNskgC3ewZjbB+SZfXnqODwc1p1 SvbEysZ4AhmK7ZI3+5Ov91v6Hsa9icL6o46dVwd0FnopbUBKqOMyE+eMFGQ5wQRxyCOK6i1tks7Z IEJIXPJ6kk5P6muGthf2dtNJoM0j26/67TpSd8LdTt7j2x196taD4sgM5s7vdBvkIAmc5i4HGT2z nrjGawem56CrqotXZmzcX0OmXs0dtaQFFAll2HDk88jtxjviq7PY6zefM/2LUEAEVxDICWBycdMH vwc9eKqanoIgto3hcywMxBkjjLOoOTkkH5gTwTipdE0m6i8k+WPKSQsJJCRkZ/uEZB9D+NM3lCEo a6k8l1d6VhdWjDQ9BeQAlPbeOqn35FXVaOeIFSksbDIIwQw/kau31p9ttjD5rR5IIKgHkdiD1HtX F2Vrf2t9draTJbmEgSwuMxvIck4A6DBHI9auMne2551aiormT+RugAAAAAAYAHYUjMEUsegBP0Ao orfochy9zqUmqXIUQym1UF40Ur+829WbJH4CojfkHBt5c/Vf8aKK8qrBTn7x30JuMdCGfV0RvL8p 1kJwu4DGTxk4JqJjLEzSQuRKQzMG5D44OR0zk8f4UUVkoRjsU6kmndnWWcI0jSP3rFiimSVupY9T XLXHmxp5cZ33U8rRg54Bz8wweOuTnvx6UUV0ROZ7nXadYpp9nHbw87T8zdC7HqTWWNCmjuIhbX0i QFyXWLKMVPXJzgnlRnGe/aiiuiyMi3/YkAmdld0tWVBJbgDDY+7k9SOckdz1ptxo0Fwq7pmUea9w SVB3MeBkEEYAGAMUUVVkBNDpSW1611LLJKxTyG83BAOQeAOAOOgGKns4DaRNHv3O7tIzAYyWOf0G B+FFFCSAsUUUUwE3H1NG4+poooANx9TRk+poooAWiiigAooooAKKKKAOe1W1NrewXlvgLcyAYPTe eASPRhwR9D2qr58Qv7KU7tm3dFnlgu7BBPqMkZ7gCiiuee5otjY1ldth9pHLWzrKB6jof0JrHvnW WdJfIWWKBdxLHBZSMcf4H9KKK4a3xpnTR+Fl+KC0kjWRIYtrAEExjOCMjtT5bS2aMpJBHtYYICAf yoorypzkpWTO1RVhlndy6bcQ2V2xlilLCCUnLDHVW9fY1s4wcUUV9Ng6kqlNczPIqxSnoVbqyWWZ Jo5DbXYH7uZBk49COhHsapzW1prkz2Wq24g1FFJ82HneBwSD6ex/CiiuiaWpmikmj67oJeXSL/zY VO0oTj8Cp4/EGqt54wup/Jh1K1RmjycxuULZxg8ZAIwfzoornelrGlKrNPRk1t4yNs8Ujm5lkVSH WR/lZe3AOPTnGevXNbunF5bMXUwUS3RM77fVuQPwGB+FFFaUdW7mlebaVz//2Q== ------_=_NextPart_001_01C60265.BFF33ACD Content-Type: application/octet-stream; name="flight-ats.der" Content-Transfer-Encoding: base64 Content-Description: flight-ats.der Content-Disposition: attachment; filename="flight-ats.der" MIIb7gIBATAaMA0GCWCGSAFlAwQCAwUAMAkGBSskAwIBBQAwghvLMIIQnjCCCMwwCQYFKyQDAgEF AKCB/zCB/DBCBBRRsXi0oJWS1CW3CXK6RI6wIh052QQUW9AkfJ+GtLH611APYfzZ5iJlGtIEFGC7 xXBpSfxNGRdxuad0NBajQPfuMCwEFLg3+9YbHIJkT9GWiSz5+x7haiRzBBRG2PwwO+1s+kM+jwkU aswvLDKlHDAsBBTPGN2iG41x18Q+EbYDs8DDCZhr2AQUa6Cgu2z0PLdmWxh2q6nbT5AyVrEwLAQU xBSgCo5XnknOxbqrBqu1d6bv/qMEFDQT4zep2/2CCjIVUO8L+CJwtehFMCwEFPeabKh6fHQc9Arr qqiRgFX4WBDqBBQAAAAAAAAAAAAAAAAAAAAAAAAAADCCB7sGCSqGSIb3DQEHAqCCB6wwggeoAgEB MQswCQYFKyQDAgEFADBXBgsqhkiG9w0BCRABBKBIBEYwRAIBAQYHKwYBBQcHAjAhMAkGBSskAwIB BQAEFPf4AVdPwjIDRWBSDV+QN6U+9wShAgIaghgPMjAwNTEyMTUxMjUwMDRaoIIF+DCCAfcwggFg oAMCAQICAggAMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4 dDEQMA4GA1UEAxMHRGVtbyBDQTAeFw0wNTA1MzAxMzU4MTlaFw0xNTA1MjgxMzU4MTlaMDQxCzAJ BgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDESMBAGA1UEAxMJRGVtbyBUU1MxMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC/d7rKidbDAaDCuf/fot+SNc7r/dUwxdHv8AcoiMICH9qRlu0V 7Nv9gW8bTi8SjN6Jaag8/+1r954IH+rsgxe/ppy4CK7hLoGirDOFIHfLMjmX8suztnF1W4N/9Vsa DX5g5K7r9apH1lru8vLuEab2sRQPzG9TvyRe/py8y1EvfQIDAQABoxowGDAJBgNVHRMEAjAAMAsG A1UdDwQEAwIHgDANBgkqhkiG9w0BAQUFAAOBgQA2FsMJT85uYGNqar4k88KxWLeycXaMBtfMGQ+K 89F2P7cvGnqoH682+CvgYHRHp0f6ORNNg8jiiq+dBKmtRLo6Ssij7pyJf7/5L+LRa6ln/TyV/SMO 1EBhCmblfhd8hH8pC63kYgDZkAfGH/OKDtRLh4ZVq/yC1iP30YMYhRBtajCCAfowggFjoAMCAQIC AgQAMA0GCSqGSIb3DQEBBQUAMDQxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDESMBAG A1UEAxMJRGVtbyBSb290MB4XDTA1MDUzMDEzNDk0MloXDTE1MDUyOTEzNDk0MlowMjELMAkGA1UE BhMCREUxETAPBgNVBAoTCE9wZW5UZXh0MRAwDgYDVQQDEwdEZW1vIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDjwk+HzRJgBUvCzgYkdVwsAH6hfla32DF34XoqmcECMPHKwF9yRf/0m57T QHjUUHRp4gZCd6PQ5rbxgXNYfS8BQT2Mvn+ZjO5kx4FeE71oLhe8hEKGBEYP0hyml+WvhbG4BTdK D05Xay2nNz290PsWtJfPB3UKbtveBRJe3Kox4QIDAQABox0wGzAMBgNVHRMEBTADAQH/MAsGA1Ud DwQEAwIChDANBgkqhkiG9w0BAQUFAAOBgQC+pAEXdtLoZHDolH/r3BO0Yw9ES64faa+/yNKwTS7h uI5lzzwxoglyoeZfLXQbtOR0apJPTtBCVTykNGX2pjMxA1heDWgjnFMugmrxyHEw4+vtoLbCi586 Qt8X5Zu23vclOlHKWmho1aHyjepBvd0AsZS9CJIcDaBRwKvdRLg+ezCCAfswggFkoAMCAQICAQAw DQYJKoZIhvcNAQEFBQAwNDELMAkGA1UEBhMCREUxETAPBgNVBAoTCE9wZW5UZXh0MRIwEAYDVQQD EwlEZW1vIFJvb3QwHhcNMDUwNTMwMTM0MjIwWhcNMTUwNTMwMTM0MjIwWjA0MQswCQYDVQQGEwJE RTERMA8GA1UEChMIT3BlblRleHQxEjAQBgNVBAMTCURlbW8gUm9vdDCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxNfaI2o8yvbsycD6MT2RDiWAbVFsep+kJXelJtYVx/d+RBtGJ5aWR91ggxlc CEpGlGuz6Wb9+VRd5hkMIBJnKmDl2jh+rvcDWSnMvk7JzzBOdnH4hN0qxjVz8z0zn4AWsupIAJGE 1NnSqBor0F4TFxaUAxvC6Nq3uDFrdH69HDUCAwEAAaMdMBswDAYDVR0TBAUwAwEB/zALBgNVHQ8E BAMCAgQwDQYJKoZIhvcNAQEFBQADgYEAWwIPcIZT45xPTepP0Bnkl+iGB4tXAqkbG0wEORyZGZL4 DW3zLVKZlPjmuR0RmOgfU0txtNN/xVA1ncT2P2eIyQY7eKkVLLyg3Sre2IMv9N8WoM9QligalKu2 zbX07ttVl3XkZotAxFcIsxcRvr7XCK/YCm8Ab/R9HeCmxBoN4C8xggE/MIIBOwIBATA4MDIxCzAJ BgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDEQMA4GA1UEAxMHRGVtbyBDQQICCAAwCQYFKyQD AgEFAKBfMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABBDAcBgkqhkiG9w0BCQUxDxcNMDUxMjE1 MTI1MDA0WjAjBgkqhkiG9w0BCQQxFgQUX2vbitQQkThAxiN1hpp95kBF/l4wDQYJKoZIhvcNAQEB BQAEgYCVgy2hMvZAhyzlT6L6iB1p4WZ3YHVTZ+IL35BZrMXZ/gm/yQJrXwjdE+pA+Myl/sGIaf6S bRNRVKzP1Ypd13fkZem8BoP5gW2uWyjMh8gNv3OPBfo7RdKOpb7oDP5gGdpFE+dNYMlfu1K5Mzd/ hGoB4fyqE/H/MTC/T8RPFLb6DDCCB8owCQYFKyQDAgEFADCCB7sGCSqGSIb3DQEHAqCCB6wwggeo AgEBMQswCQYFKyQDAgEFADBXBgsqhkiG9w0BCRABBKBIBEYwRAIBAQYHKwYBBQcHAjAhMAkGBSsk AwIBBQAEFJwtiLrmVW+Dfqir8HDL/MoOt4GfAgIahBgPMjAwNTEyMTUxMjUxMjhaoIIF+DCCAfcw ggFgoAMCAQICAggAMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVu VGV4dDEQMA4GA1UEAxMHRGVtbyBDQTAeFw0wNTA1MzAxMzU4MTlaFw0xNTA1MjgxMzU4MTlaMDQx CzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDESMBAGA1UEAxMJRGVtbyBUU1MxMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/d7rKidbDAaDCuf/fot+SNc7r/dUwxdHv8AcoiMICH9qR lu0V7Nv9gW8bTi8SjN6Jaag8/+1r954IH+rsgxe/ppy4CK7hLoGirDOFIHfLMjmX8suztnF1W4N/ 9VsaDX5g5K7r9apH1lru8vLuEab2sRQPzG9TvyRe/py8y1EvfQIDAQABoxowGDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIHgDANBgkqhkiG9w0BAQUFAAOBgQA2FsMJT85uYGNqar4k88KxWLeycXaMBtfM GQ+K89F2P7cvGnqoH682+CvgYHRHp0f6ORNNg8jiiq+dBKmtRLo6Ssij7pyJf7/5L+LRa6ln/TyV /SMO1EBhCmblfhd8hH8pC63kYgDZkAfGH/OKDtRLh4ZVq/yC1iP30YMYhRBtajCCAfowggFjoAMC AQICAgQAMA0GCSqGSIb3DQEBBQUAMDQxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDES MBAGA1UEAxMJRGVtbyBSb290MB4XDTA1MDUzMDEzNDk0MloXDTE1MDUyOTEzNDk0MlowMjELMAkG A1UEBhMCREUxETAPBgNVBAoTCE9wZW5UZXh0MRAwDgYDVQQDEwdEZW1vIENBMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDjwk+HzRJgBUvCzgYkdVwsAH6hfla32DF34XoqmcECMPHKwF9yRf/0 m57TQHjUUHRp4gZCd6PQ5rbxgXNYfS8BQT2Mvn+ZjO5kx4FeE71oLhe8hEKGBEYP0hyml+WvhbG4 BTdKD05Xay2nNz290PsWtJfPB3UKbtveBRJe3Kox4QIDAQABox0wGzAMBgNVHRMEBTADAQH/MAsG A1UdDwQEAwIChDANBgkqhkiG9w0BAQUFAAOBgQC+pAEXdtLoZHDolH/r3BO0Yw9ES64faa+/yNKw TS7huI5lzzwxoglyoeZfLXQbtOR0apJPTtBCVTykNGX2pjMxA1heDWgjnFMugmrxyHEw4+vtoLbC i586Qt8X5Zu23vclOlHKWmho1aHyjepBvd0AsZS9CJIcDaBRwKvdRLg+ezCCAfswggFkoAMCAQIC AQAwDQYJKoZIhvcNAQEFBQAwNDELMAkGA1UEBhMCREUxETAPBgNVBAoTCE9wZW5UZXh0MRIwEAYD VQQDEwlEZW1vIFJvb3QwHhcNMDUwNTMwMTM0MjIwWhcNMTUwNTMwMTM0MjIwWjA0MQswCQYDVQQG EwJERTERMA8GA1UEChMIT3BlblRleHQxEjAQBgNVBAMTCURlbW8gUm9vdDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAxNfaI2o8yvbsycD6MT2RDiWAbVFsep+kJXelJtYVx/d+RBtGJ5aWR91g gxlcCEpGlGuz6Wb9+VRd5hkMIBJnKmDl2jh+rvcDWSnMvk7JzzBOdnH4hN0qxjVz8z0zn4AWsupI AJGE1NnSqBor0F4TFxaUAxvC6Nq3uDFrdH69HDUCAwEAAaMdMBswDAYDVR0TBAUwAwEB/zALBgNV HQ8EBAMCAgQwDQYJKoZIhvcNAQEFBQADgYEAWwIPcIZT45xPTepP0Bnkl+iGB4tXAqkbG0wEORyZ GZL4DW3zLVKZlPjmuR0RmOgfU0txtNN/xVA1ncT2P2eIyQY7eKkVLLyg3Sre2IMv9N8WoM9Qliga lKu2zbX07ttVl3XkZotAxFcIsxcRvr7XCK/YCm8Ab/R9HeCmxBoN4C8xggE/MIIBOwIBATA4MDIx CzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDEQMA4GA1UEAxMHRGVtbyBDQQICCAAwCQYF KyQDAgEFAKBfMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABBDAcBgkqhkiG9w0BCQUxDxcNMDUx MjE1MTI1MTI4WjAjBgkqhkiG9w0BCQQxFgQUbTOxuDxqZsQLc4nfyfU30B5n1tEwDQYJKoZIhvcN AQEBBQAEgYCDZi7Ghp6qalyPyxaPsMDwJzTERdo7+a3/1IxIR9LQtxIO/jansqDGAGPdmHc+TaV+ UHSJ4pcfU9s3fx5UmqC33pG9Pn6XIMKO13pvAzFb2HRoWBHZF3W2KAAt8JD+79PykCmdtJYjW8WM D4/acFttDN0mFhIvI9G9D5ow0cH+XDCCCyUwggshMA0GCWCGSAFlAwQCAwUAoIIC6TCCAuUwgcYE QDW7R0t/EX+qDoaAlKtU6x+nNZDD3/QUDFqvZUCqB8XpBvpJXS93Pu0pd9r+MRELmuqEfsho3EFc GtQ7dXCcXjMEQDZAzXNUJx454G8kXt8xaplbkokoaRah3X0MMwCfZ6h+1SuOH90Zu0RniqvMcDgB Puxns7mguxXE37QfzYI4PW0EQDhc3Rtk65NIOUR2ByMN0RH/flA9Jf6BM/nmz8QRr8PPMaSZqLtT HlgOAuZTjMACHWFyk11Kon5fap13fZ2KZNwwgYQEQPcEDcHDf2y/9T2klbgVUUOYUjtolU6G6YH9 uiaUV34wuUSrT7eB0/nWgmFEZfFUb7Yrpx/CQ8ByLNoe0pHIKooEQCEAmZAr7tgnJl6QwiBznafm YkpAR5sptvVzH93cw+CcnRxGt+YK7Q2QxGMcpdq2YBdeSYqoSH8rfFRUyJPaQqQwgYQEQAxCoiSG T6+/PIABS93dslpF31Zu5bk6UQ4UBG8EXGLbrIKB4H2YE6i91sO3xDo44MwoZzNzWzqTrHU6cNha stEEQFfplxESOW2drO8/u9Qi8oVr+LUmkArjnNgMOm4TckFsi76XFRDJsxY0IBVr+xV8wRWU7AT3 W4Hqs9cPo3w+8r8wgYQEQN3y1Dknkp1aRNKi+rKOgNeVft3rsk2JE49mC7QMBui11z4NoCTISGc/ IhPipS564gFeOXI1MdWpBnbeZxST398EQIz8st8EbjTBgzSV9eKMWFq8yCo/L4mp+CIDYplOsVSL Em2lw9bU6XzKS1S6pNvcCQS1NrwqXTabzwYufKOIVyAwgYQEQGFqGQozdgTfsQku4LWtExEXv7VI f4wa/pSFsMK1HmwrKirNPsqhud3cfi1DE6Ho258/bPagW0TwT+sXTSeftaYEQKFqPjVYmRglwiry qGL6eUiJQyZHh1TivQ20evdQxi3xr6KS2N248IIxXoB9iQDGK0gwDrv+ARfq15P9EMpp4EEwgggh BgkqhkiG9w0BBwKggggSMIIIDgIBATEPMA0GCWCGSAFlAwQCAwUAMIGHBgsqhkiG9w0BCRABBKB4 BHYwdAIBAQYHKwYBBQcHAjBRMA0GCWCGSAFlAwQCAwUABEAOGXY6B0MWXB9TAiYwAr36vYvvT8Vy xAYiqO3xsgsxfLVTp34y8lRC9d8XOSlLAnajt7L5mVC9BTC0KdDQqumVAgIahhgPMjAwNTEyMTUx MzAxMTRaoIIF+DCCAfcwggFgoAMCAQICAggAMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkRF MREwDwYDVQQKEwhPcGVuVGV4dDEQMA4GA1UEAxMHRGVtbyBDQTAeFw0wNTA1MzAxMzU4MTlaFw0x NTA1MjgxMzU4MTlaMDQxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDESMBAGA1UEAxMJ RGVtbyBUU1MxMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/d7rKidbDAaDCuf/fot+SNc7r /dUwxdHv8AcoiMICH9qRlu0V7Nv9gW8bTi8SjN6Jaag8/+1r954IH+rsgxe/ppy4CK7hLoGirDOF IHfLMjmX8suztnF1W4N/9VsaDX5g5K7r9apH1lru8vLuEab2sRQPzG9TvyRe/py8y1EvfQIDAQAB oxowGDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIHgDANBgkqhkiG9w0BAQUFAAOBgQA2FsMJT85uYGNq ar4k88KxWLeycXaMBtfMGQ+K89F2P7cvGnqoH682+CvgYHRHp0f6ORNNg8jiiq+dBKmtRLo6Ssij 7pyJf7/5L+LRa6ln/TyV/SMO1EBhCmblfhd8hH8pC63kYgDZkAfGH/OKDtRLh4ZVq/yC1iP30YMY hRBtajCCAfowggFjoAMCAQICAgQAMA0GCSqGSIb3DQEBBQUAMDQxCzAJBgNVBAYTAkRFMREwDwYD VQQKEwhPcGVuVGV4dDESMBAGA1UEAxMJRGVtbyBSb290MB4XDTA1MDUzMDEzNDk0MloXDTE1MDUy OTEzNDk0MlowMjELMAkGA1UEBhMCREUxETAPBgNVBAoTCE9wZW5UZXh0MRAwDgYDVQQDEwdEZW1v IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjwk+HzRJgBUvCzgYkdVwsAH6hfla32DF3 4XoqmcECMPHKwF9yRf/0m57TQHjUUHRp4gZCd6PQ5rbxgXNYfS8BQT2Mvn+ZjO5kx4FeE71oLhe8 hEKGBEYP0hyml+WvhbG4BTdKD05Xay2nNz290PsWtJfPB3UKbtveBRJe3Kox4QIDAQABox0wGzAM BgNVHRMEBTADAQH/MAsGA1UdDwQEAwIChDANBgkqhkiG9w0BAQUFAAOBgQC+pAEXdtLoZHDolH/r 3BO0Yw9ES64faa+/yNKwTS7huI5lzzwxoglyoeZfLXQbtOR0apJPTtBCVTykNGX2pjMxA1heDWgj nFMugmrxyHEw4+vtoLbCi586Qt8X5Zu23vclOlHKWmho1aHyjepBvd0AsZS9CJIcDaBRwKvdRLg+ ezCCAfswggFkoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwNDELMAkGA1UEBhMCREUxETAPBgNVBAoT CE9wZW5UZXh0MRIwEAYDVQQDEwlEZW1vIFJvb3QwHhcNMDUwNTMwMTM0MjIwWhcNMTUwNTMwMTM0 MjIwWjA0MQswCQYDVQQGEwJERTERMA8GA1UEChMIT3BlblRleHQxEjAQBgNVBAMTCURlbW8gUm9v dDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxNfaI2o8yvbsycD6MT2RDiWAbVFsep+kJXel JtYVx/d+RBtGJ5aWR91ggxlcCEpGlGuz6Wb9+VRd5hkMIBJnKmDl2jh+rvcDWSnMvk7JzzBOdnH4 hN0qxjVz8z0zn4AWsupIAJGE1NnSqBor0F4TFxaUAxvC6Nq3uDFrdH69HDUCAwEAAaMdMBswDAYD VR0TBAUwAwEB/zALBgNVHQ8EBAMCAgQwDQYJKoZIhvcNAQEFBQADgYEAWwIPcIZT45xPTepP0Bnk l+iGB4tXAqkbG0wEORyZGZL4DW3zLVKZlPjmuR0RmOgfU0txtNN/xVA1ncT2P2eIyQY7eKkVLLyg 3Sre2IMv9N8WoM9QligalKu2zbX07ttVl3XkZotAxFcIsxcRvr7XCK/YCm8Ab/R9HeCmxBoN4C8x ggFwMIIBbAIBATA4MDIxCzAJBgNVBAYTAkRFMREwDwYDVQQKEwhPcGVuVGV4dDEQMA4GA1UEAxMH RGVtbyBDQQICCAAwDQYJYIZIAWUDBAIDBQCggYswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJEAEE MBwGCSqGSIb3DQEJBTEPFw0wNTEyMTUxMzAxMTRaME8GCSqGSIb3DQEJBDFCBEBlIDv0yQdVU2YN PbgB9eCZG96IgBxQHmVjjzyUfUJKZATFH0IostLfzSQFH4BUEIFrGfpP2b/ylJwnzg2jxCdiMA0G CSqGSIb3DQEBAQUABIGAab5Bs6o+YC2aH61xCwhPRjRn9ykD9sQWUA/wiLUwnbxCmHTffG7r9ZJF noLEStBsdXjykY4rPgTJNiE6BPbrGrM2XjKM2eGEmcaLEJpmlW9dkCvRaZBfBpIKrhfj0weX9kLu xeD2+Im3XjqsQxUMMY+C8EVVuAoADpj6EBtU3j4= ------_=_NextPart_001_01C60265.BFF33ACD-- 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 jBGHIlwm052609; Fri, 16 Dec 2005 09:18: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 jBGHIlND052608; Fri, 16 Dec 2005 09:18:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGHIjjc052570 for ; Fri, 16 Dec 2005 09:18:45 -0800 (PST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id jBGHIfGT013588; Fri, 16 Dec 2005 18:18:41 +0100 (MET) 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: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Fri, 16 Dec 2005 18:18:52 +0100 Message-ID: <3C1BE8610E44734499EF92FB35F5B07001648A2A@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Thread-Index: AcYBux34x/XVE90RQqGOOHgFjVCwugAAVTjgAClqjnA= From: "Tobias Gondrom" To: "Carl Wallace" , "Young H. Etheridge" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBGHIkjc052601 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Three comments: A) At first I think we will not be able to provide the _perfect_ solution capturing all problems with ERS - there might always be problems with long-term validation. (and from my experience to go for perfect lead to go for "no-go" ;-) ) But Carl is right one has to think of the availability of the verification data in the medium to far future: any technical authority can only guarantee the availability of additional verification data for a limited time (the TSA might be shut down, might face an accident, or other). At the moment facing the problem of necessary verification data I see two approaches (complementing each other): 1. it is possible to add all necessary verification data into the timestamps we use in ERS. We already do this in both implementations I know first hand. (At the time you receive the timestamp from a TSA, you also verify it and for the verification get all necessary data (i.e. all certificates up to the root, and optionally an OCSP or CRL. With certified TSAs you most probably will not need a OCSP as the press would usually cover any compromising of the private key of a TSA - but of course this may differ from country to country.) 2. the availability of long term validation data can be provided along with the ERS by the SCVP/ERS approach. #1 is solving most of the problems of long term verification and #2 could flexibly bridge gaps. B) more general: I believe the following paradigm to be a good approach: All for the verification necessary information should be allocated as close as possible to the objects to be verified (in case of RFC3161 TS this is _within_ the TS structure, in case of CMS this is _within_ the CMS structure). This is already possible with the currently available specifications. If this is not possible due to time constraints, or limited availability of verification data (maybe some of the verification data are only getting available after several days after archiving, the approach via SCVP should be used to handle this data, but it should not lead to _additional_ general fields ("buckets") in ERS to hold any possibly necessary data. C) How do others think about the proposed text from Young for the ERS draft? Best regards, Tobias > -----Original Message----- > From: Carl Wallace [mailto:cwallace@orionsec.com] > Sent: Thursday, December 15, 2005 10:25 PM > To: 'Young H. Etheridge' > Cc: Tobias Gondrom; ietf-ltans@imc.org > Subject: RE: LTANS: ERS - question for consensus about the mentioning of > other TS Services (other than RFC3161) in the I-D > > > > To some extent isn't this being partially addressed > > by providing for TimeStamp renewal? > > I don't think so. What's the value of renewed timestamps without the > means > to verify them? > > > This seems to place the > > burden on those who have a vested interest in the Evidence > > Record as well as the viability of the Evidence Record to > > perform good practices on Evidence Record Management. > > Yes but the structures and/or processes defined here should support such. 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 jBGF8MAT036245; Fri, 16 Dec 2005 07:08: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 jBGF8MTK036244; Fri, 16 Dec 2005 07:08:22 -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 jBGF8Kus036236 for ; Fri, 16 Dec 2005 07:08:21 -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 9C95315849; Fri, 16 Dec 2005 10:08:15 -0500 (EST) Message-ID: <43A2D8C8.2060609@yhetheridge.org> Date: Fri, 16 Dec 2005 10:10:00 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace Cc: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <200512152125.jBFLPOaY030482@host15.websitesource.com> In-Reply-To: <200512152125.jBFLPOaY030482@host15.websitesource.com> 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: Carl Wallace wrote: > > >> To some extent isn't this being partially addressed >> by providing for TimeStamp renewal? >> > > I don't think so. What's the value of renewed timestamps without the means > to verify them? > > >> This seems to place the >> burden on those who have a vested interest in the Evidence >> Record as well as the viability of the Evidence Record to >> perform good practices on Evidence Record Management. >> > > Yes but the structures and/or processes defined here should support such. > > On closer examination of all four (4) TimeStamp methods produced in X9.95 it seems that most of the necessary TimeStamp artifacts are encodable options, particularly, in the CMS ASN.1 encoding. In particular, the applicable cert validation paths and CRLs for digitally signed TimeStamps are optional encodings. There are CMS software development APIs, e.g., BouncyCastle's Java-based crypto API, that allow a developer to simply exercise these options. This seems to provide additional credence to my request to give X9.95 an equal footing with RFC-3161 in the LTANS ERS I-D. 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 jBFLbYsJ021888; Thu, 15 Dec 2005 13:37:34 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBFLbYfB021887; Thu, 15 Dec 2005 13:37:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBFLbY8K021880 for ; Thu, 15 Dec 2005 13:37:34 -0800 (PST) (envelope-from arshad.noor@strongauth.com) Received: from [10.0.4.10] ([69.232.142.170]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPSA id <0IRK001ZN56N9K@igw.noorhome.net> for ietf-ltans@imc.org; Thu, 15 Dec 2005 13:03:59 -0800 (PST) Date: Thu, 15 Dec 2005 13:39:59 -0800 From: Arshad Noor Subject: Sorry for the earlier e-mail to the wrong alias To: ietf-ltans@imc.org Message-id: <43A1E2AF.60300@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 jBFLPTXq020219; Thu, 15 Dec 2005 13:25:29 -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 jBFLPTIE020218; Thu, 15 Dec 2005 13:25:29 -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 jBFLPTtV020210 for ; Thu, 15 Dec 2005 13:25:29 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (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 jBFLPOaY030482; Thu, 15 Dec 2005 16:25:27 -0500 Message-Id: <200512152125.jBFLPOaY030482@host15.websitesource.com> From: "Carl Wallace" To: "'Young H. Etheridge'" Cc: "'Tobias Gondrom'" , Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Thu, 15 Dec 2005 16:25:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYBux34x/XVE90RQqGOOHgFjVCwugAAVTjg In-Reply-To: <43A1DABA.5090808@yhetheridge.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > To some extent isn't this being partially addressed > by providing for TimeStamp renewal? I don't think so. What's the value of renewed timestamps without the means to verify them? > This seems to place the > burden on those who have a vested interest in the Evidence > Record as well as the viability of the Evidence Record to > perform good practices on Evidence Record Management. Yes but the structures and/or processes defined here should support such. 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 jBFL4Niw016931; Thu, 15 Dec 2005 13:04: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 jBFL4Nbi016929; Thu, 15 Dec 2005 13:04:23 -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 jBFL4MqO016921 for ; Thu, 15 Dec 2005 13:04:22 -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 D64F7158E4; Thu, 15 Dec 2005 16:04:19 -0500 (EST) Message-ID: <43A1DABA.5090808@yhetheridge.org> Date: Thu, 15 Dec 2005 16:06:02 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace Cc: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <200512151951.jBFJpVaY022471@host15.websitesource.com> In-Reply-To: <200512151951.jBFJpVaY022471@host15.websitesource.com> 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: Carl Wallace wrote:. . . . >> Are these not problems for CMS consumers now? Or, am I >> missing some other point? >> > > These are problems for CMS consumers now but the problem is magnified by > time in our case. CMS consumers performing signature verification and path > validation now can obtain information for directories, OCSP responders, etc. > When performing these operations on historical artifacts, the information is > not readily available. There's been very little discussion regarding how > the verification of EvidenceRecords will be carried out, including how the > artifacts necessary to verify the interior timestamps will be obtained. > These concerns could result in changes to the ERS syntax. How do existing > implementations of ERS handle this? There seems to be a significant gap at > the moment and last call seems premature without a plan in place to support > validating the structures. > > As noted earlier, separating the preservation of verification artifacts from > the archived data seems to be the right way to proceed. This seems worthy > of standardization to me. I've been planning to submit an I-D similar to > the ERS/SCVP draft that describes alternative directory attributes to hold > historical certificates (and possibly ERS-protected certificates) and CRL > techniques to support long-term archive. > > I agree that your concerns are well-taken. But to this point when such concerns arise the predominant attitude that I've noticed is the typical Ostrich reaction to frightening info - head in the sand or run. What are your potential Evidence Record consumers saying? Mine are shrugging and saying "yeah, that's a problem alright, but I'll be retired before that problem arises! " Handling, e.g., maintaining readers/editors, for historical e-archives has similar issues aside from time-honored integrity. Theoretically this is being somewhat pursued in the OpenDocument format to the point that there will be but two formats for the future, Microsoft's and all other's. Perhaps your I-D is the best means of addressing the concern while assuming the problem is not strictly a syntax concern? Evidence Record without Evidence Record artifacts and archived data seems to be vacuous. Just as good backup procedures necessarily promote testing the efficacy of the backup media, it seems that Evidence Record management should promote assurances of the availability and subsequent viability of the Evidence Record. To some extent isn't this being partially addressed by providing for TimeStamp renewal? This seems to place the burden on those who have a vested interest in the Evidence Record as well as the viability of the Evidence Record to perform good practices on Evidence Record Management. 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 jBFJpXU4005230; Thu, 15 Dec 2005 11:51: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 jBFJpX2q005229; Thu, 15 Dec 2005 11:51:33 -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 jBFJpWbO005223 for ; Thu, 15 Dec 2005 11:51:33 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (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 jBFJpVaY022471; Thu, 15 Dec 2005 14:51:31 -0500 Message-Id: <200512151951.jBFJpVaY022471@host15.websitesource.com> From: "Carl Wallace" To: "'Young H. Etheridge'" Cc: "'Tobias Gondrom'" , Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Thu, 15 Dec 2005 14:51:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYBqrRwy0qxJjWdQkC4t3rJp8fmpQABAwRg In-Reply-To: <43A1BF32.3070202@yhetheridge.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > No. The material needed to perform the validation must > come from somewhere. > > That somewhere has not been defined. > > > > > Are you suggesting that the EncapulatedContentInfo with > Optional Content needs a URL/URI to the > DigestedData/SignedData/MACData/... and/or possibly a URL/URI > to at least one potential Verification subscriber service? No. A verification service is not required. > Are these not problems for CMS consumers now? Or, am I > missing some other point? These are problems for CMS consumers now but the problem is magnified by time in our case. CMS consumers performing signature verification and path validation now can obtain information for directories, OCSP responders, etc. When performing these operations on historical artifacts, the information is not readily available. There's been very little discussion regarding how the verification of EvidenceRecords will be carried out, including how the artifacts necessary to verify the interior timestamps will be obtained. These concerns could result in changes to the ERS syntax. How do existing implementations of ERS handle this? There seems to be a significant gap at the moment and last call seems premature without a plan in place to support validating the structures. As noted earlier, separating the preservation of verification artifacts from the archived data seems to be the right way to proceed. This seems worthy of standardization to me. I've been planning to submit an I-D similar to the ERS/SCVP draft that describes alternative directory attributes to hold historical certificates (and possibly ERS-protected certificates) and CRL techniques to support long-term archive. 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 jBFJ6sIJ001207; Thu, 15 Dec 2005 11:06:54 -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 jBFJ6s2A001206; Thu, 15 Dec 2005 11:06:54 -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 jBFJ6rSf001200 for ; Thu, 15 Dec 2005 11:06:53 -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 47EA2158EF; Thu, 15 Dec 2005 14:06:51 -0500 (EST) Message-ID: <43A1BF32.3070202@yhetheridge.org> Date: Thu, 15 Dec 2005 14:08:34 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace Cc: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <200512151815.jBFIF8aY030134@host15.websitesource.com> In-Reply-To: <200512151815.jBFIF8aY030134@host15.websitesource.com> 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: Carl Wallace wrote: > > >> Do you have ASN.1 code envisioned for this mechanism? >> > > Not at the moment but I can provide some. > > >> Does the X9.95 TimeStampToken Verification protocol for each >> of the TSTs not address your concerns? >> > > No. The material needed to perform the validation must come from somewhere. > That somewhere has not been defined. > > Are you suggesting that the EncapulatedContentInfo with Optional Content needs a URL/URI to the DigestedData/SignedData/MACData/... and/or possibly a URL/URI to at least one potential Verification subscriber service? Are these not problems for CMS consumers now? Or, am I missing some other point? 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 jBFIFAxv097251; Thu, 15 Dec 2005 10:15: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 jBFIFA47097250; Thu, 15 Dec 2005 10:15:10 -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 jBFIF9eg097239 for ; Thu, 15 Dec 2005 10:15:09 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (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 jBFIF8aY030134; Thu, 15 Dec 2005 13:15:08 -0500 Message-Id: <200512151815.jBFIF8aY030134@host15.websitesource.com> From: "Carl Wallace" To: "'Young H. Etheridge'" Cc: "'Tobias Gondrom'" , Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Thu, 15 Dec 2005 13:15:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYBnmeHjoADrRZYT3W4Q21P3UApZgABPl7Q In-Reply-To: <43A1AA8B.9090101@yhetheridge.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Do you have ASN.1 code envisioned for this mechanism? Not at the moment but I can provide some. > Does the X9.95 TimeStampToken Verification protocol for each > of the TSTs not address your concerns? No. The material needed to perform the validation must come from somewhere. That somewhere has not been defined. 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 jBFHcoSq091728; Thu, 15 Dec 2005 09:38:50 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBFHcoLl091727; Thu, 15 Dec 2005 09:38:50 -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 jBFHcna2091720 for ; Thu, 15 Dec 2005 09:38:49 -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 08BCC158EC; Thu, 15 Dec 2005 12:38:45 -0500 (EST) Message-ID: <43A1AA8B.9090101@yhetheridge.org> Date: Thu, 15 Dec 2005 12:40:27 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace Cc: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <200512151131.jBFBVdaY030364@host15.websitesource.com> In-Reply-To: <200512151131.jBFBVdaY030364@host15.websitesource.com> 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: Carl Wallace wrote: . . . > > I think we need to define a mechanism so each application does not need to > invent a mechanism. There's a general purpose "bucket" out the outermost > layer of the EvidenceRecord but this does not seem ideal for collecting > materials used to validate interior timestamps. For CMS-based timestamps, > we could use the certs bag or unsigned attributes. Once we identify where > to store the material, we need to identify how to preserve that material > (since in many/most cases these items will also be signed). This is where > the ERS/SCVP draft fits in. Instead of preserving validation materials with > each archived data object, the materials can be preserved one time separate > from the object and retrieved at validation time. > > Do you have ASN.1 code envisioned for this mechanism? Does the X9.95 TimeStampToken Verification protocol for each of the TSTs not address your concerns? . . . 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 jBFBVgrq044297; Thu, 15 Dec 2005 03:31: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 jBFBVggJ044296; Thu, 15 Dec 2005 03:31:42 -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 jBFBVfN7044289 for ; Thu, 15 Dec 2005 03:31:41 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (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 jBFBVdaY030364; Thu, 15 Dec 2005 06:31:39 -0500 Message-Id: <200512151131.jBFBVdaY030364@host15.websitesource.com> From: "Carl Wallace" To: "'Young H. Etheridge'" Cc: "'Tobias Gondrom'" , Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Thu, 15 Dec 2005 06:31:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43A091C0.8010204@yhetheridge.org> Thread-Index: AcYA+Fx5DnwZTHc9R023yxsKBPmTtgAcdUeg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > This does re-raise the question of how/where to convey information > > necessary to verify interior timestamps in an EvidenceRecord. > If I understand your question correctly then a digitally > signed TimeStamp does not necessarily resolve the need > either, does it? No, the same problem exists for signature-based timestamps but the addition of timestamp format may place additional requirements for a generic solution. > It seems that ERS is presently application > specific or an API could offer a driver to try all available > TSA - not exactly efficient and rather prone to error. What > do you suggest as a resolution? I think we need to define a mechanism so each application does not need to invent a mechanism. There's a general purpose "bucket" out the outermost layer of the EvidenceRecord but this does not seem ideal for collecting materials used to validate interior timestamps. For CMS-based timestamps, we could use the certs bag or unsigned attributes. Once we identify where to store the material, we need to identify how to preserve that material (since in many/most cases these items will also be signed). This is where the ERS/SCVP draft fits in. Instead of preserving validation materials with each archived data object, the materials can be preserved one time separate from the object and retrieved at validation time. > > It also raises the > > possibility of different timestamps over a single EvidenceRecord. > > > Agreed. An opportunity for EvidenceRecord resilience. > > > > > 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 jBELem7v000404; Wed, 14 Dec 2005 13:40: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 jBELemIR000403; Wed, 14 Dec 2005 13:40:48 -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 jBELelTO000397 for ; Wed, 14 Dec 2005 13:40:47 -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 D284A15893; Wed, 14 Dec 2005 16:40:42 -0500 (EST) Message-ID: <43A091C0.8010204@yhetheridge.org> Date: Wed, 14 Dec 2005 16:42:24 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace Cc: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <200512142119.jBELJPaY005456@host15.websitesource.com> In-Reply-To: <200512142119.jBELJPaY005456@host15.websitesource.com> 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: Carl Wallace wrote: >>> Young suggested to also mention and name also some other timestamp >>> techniques, especially ISO ([I180141], [I180142], [I180143], and >>> [ANSX995] - References see below). >>> >>> >> My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 >> on a similar cryptographic level with RFC-3161, not emphasize >> any one over the other. My game is cryptographic resilience. >> Offer cryptographic choices for ERS TimeStamps as a step >> toward future proofing TimeStamps. >> > > This does re-raise the question of how/where to convey information necessary > to verify interior timestamps in an EvidenceRecord. If I understand your question correctly then a digitally signed TimeStamp does not necessarily resolve the need either, does it? It seems that ERS is presently application specific or an API could offer a driver to try all available TSA - not exactly efficient and rather prone to error. What do you suggest as a resolution? > It also raises the > possibility of different timestamps over a single EvidenceRecord. > Agreed. An opportunity for EvidenceRecord resilience. > > 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 jBELJTsO096505; Wed, 14 Dec 2005 13:19:29 -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 jBELJTsC096504; Wed, 14 Dec 2005 13:19:29 -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 jBELJSlk096498 for ; Wed, 14 Dec 2005 13:19:29 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (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 jBELJPaY005456; Wed, 14 Dec 2005 16:19:25 -0500 Message-Id: <200512142119.jBELJPaY005456@host15.websitesource.com> From: "Carl Wallace" To: "'Young H. Etheridge'" , "'Tobias Gondrom'" Cc: Subject: RE: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Wed, 14 Dec 2005 16:19:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43A088CE.4050903@yhetheridge.org> Thread-Index: AcYA80dOwLugLPBGQEK0N06goPZdeQAAFKIg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Young suggested to also mention and name also some other timestamp > > techniques, especially ISO ([I180141], [I180142], [I180143], and > > [ANSX995] - References see below). > > > My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 > on a similar cryptographic level with RFC-3161, not emphasize > any one over the other. My game is cryptographic resilience. > Offer cryptographic choices for ERS TimeStamps as a step > toward future proofing TimeStamps. This does re-raise the question of how/where to convey information necessary to verify interior timestamps in an EvidenceRecord. It also raises the possibility of different timestamps over a single EvidenceRecord. 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 jBEL2ZiS093922; Wed, 14 Dec 2005 13:02:35 -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 jBEL2Z2D093921; Wed, 14 Dec 2005 13:02:35 -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 jBEL2YMl093915 for ; Wed, 14 Dec 2005 13:02:34 -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 AB0A41588D; Wed, 14 Dec 2005 16:02:33 -0500 (EST) Message-ID: <43A088CE.4050903@yhetheridge.org> Date: Wed, 14 Dec 2005 16:04:14 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom Cc: ietf-ltans@imc.org Subject: Re: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D References: <3C1BE8610E44734499EF92FB35F5B0700164867E@MUCXGC1.opentext.net> In-Reply-To: <3C1BE8610E44734499EF92FB35F5B0700164867E@MUCXGC1.opentext.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please see response interspersed below: Tobias Gondrom wrote: > > Hello, > > at the moment the role of other TS mechanisms (besides RFC3161) is not > fully agreed. > > In all past versions we specified that for ERS a TimeStamp should be > used and mentioned RFC3161 as one example, not naming any other ones > specifically. > > Young suggested to also mention and name also some other timestamp > techniques, especially ISO ([I180141], [I180142], [I180143], and > [ANSX995] – References see below). > My goal was to place ANSI X9.95, ISO 18014-1, and ISO 18014-3 on a similar cryptographic level with RFC-3161, not emphasize any one over the other. My game is cryptographic resilience. Offer cryptographic choices for ERS TimeStamps as a step toward future proofing TimeStamps. > > Which I did in a first and soft step in ERS-04, besides I asked Carl > to raise this topic at the last IETF meeting. > > Young asked me to prepare a slightly stronger wording about the use of > the timestamps other than RFC3161. > > So I ask for mailing-list opinion to find out about consensus how to > change the draft. > > Currently I see three options (but am open for additional ones coming > from the community): > > a) we stay with the 04-draft > (http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt) > My reason for suggesting the ANSI and ISO standards is that they offer implementers a number of choices for verifiable TimeStamp from an appropriate TSA, not all of which require PKI solutions. The -04 draft does mention the added standards, but still seems to unnecessarily require a PKI digital signature even if one of the ANSI or ISO standards is implemented. The ISO standards provide cryptological efficacy for a number of TimeStamp choices, including that offered in RFC3161. The ANSI standard rather definitively suggests cryptographic resilience for TimeStamp. > > b) we change the draft as proposed by Young slightly, more emphasizing > the use of ISO timestamps and in my opinion de-emphasizing the use of > others not mentioned in the draft > As already stated I intended that my proposal offer TimeStamp choices of similar cryptographic stature as specified by standards bodies in good standing by most enterprises, especially the financial community. Certainly my intent is to not emphasize one TimeStamp over another. It seems to me that the implementer and subsequent buyer who desires to be standards compliant should be able to choose that which best fits their business requirements. > > c) go back to the wording in ERS-03 by removing the names and > references to the ISO timestamp concepts. > This choice seems to squarely place ERS as a PKI-only solution. Many businesses depend on the standards bodies to aid them in specifying correct cryptographic choices. I believe that it not desirable or necessary for all business digital information evidence records to require PKI-based TimeStamps. > > The specific parts in question are: > > In Section 1.3. Terminology -- change -- > > "Time-Stamp: A signed confirmation generated by a Time Stamping > > Authority (TSA) that a data item existed at a certain time. > > [RFC3161] specifies a good structure for time-stamps and a > > protocol for communicating with a Time-stamp Authority (TSA). > > Further good structures and protocols for communicating with a > > Time-stamp Authority (TSA) may also, but not exclusively, be > > [I180141], [I180142], [I180143], and [ANSX995]." > > -- to -- > > "Time-Stamp: A signed confirmation generated by a Time Stamping > > Authority (TSA) that a data item existed at a certain time. > > [RFC3161] specifies an acceptable structure for time-stamps and a > > protocol for communicating with a Time-stamp Authority (TSA). > > Further acceptable structures and protocols for communicating with a > > Time-stamp Authority (TSA) may be those specified in > > [I180141], [I180143], or [ANSX995]." > > In Section 3.1 Syntax -- change -- > > "timeStamp should contain the time-stamp as defined in section 1.3 > > "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]). > > 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." > > -- to -- > > "timeStamp should contain the time-stamp as defined in section 1.3 > > "Terminology". (e.g. as defined with timeStampToken in [RFC 3161], > > [ANSX995], [I180141], or [I180143])." > > *Open for votes, opinion, discussion!* > > Best regards, Tobias > Thanks, yhe. > > References: > > [ANSX995] American National Standard for Financial Services, > > "Trusted Timestamp Management and Security", ANSX X9.95- > > 2005, June 2005. > > [I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: > > Framework", ISO ISO-18014-1, February 2002. > > [I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: > > Mechanisms producing independent tokens", ISO ISO-18014-2, > > December 2002. > > [I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: > > Mechanisms producing linked tokens", ISO ISO-18014-3, > > February 2004. > > *__________________________________________* > *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ält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > eMail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, > Vervielfältigung oder Weitergabe ist nicht gestattet. > 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 jBEHr4Xk067320; Wed, 14 Dec 2005 09:53:04 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEHr4JJ067319; Wed, 14 Dec 2005 09:53:04 -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 jBEHr2aZ067313 for ; Wed, 14 Dec 2005 09:53:03 -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 jBEHr1Lt026189; Wed, 14 Dec 2005 18:53:01 +0100 (MET) 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: Change Request: draft-ietf-ltans-ers-04.txt Date: Wed, 14 Dec 2005 18:53:08 +0100 Message-ID: <3C1BE8610E44734499EF92FB35F5B07001648687@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Change Request: draft-ietf-ltans-ers-04.txt Thread-Index: AcYA1Fs33yrVA+qnT1WoABLYPiPPFgAAUw1g From: "Tobias Gondrom" To: "Young H. Etheridge" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBEHr3aZ067314 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Young, thank you, for raising this issue. (I sent the same request out just before I received yours; but assume it will hit the list a few minutes later) Actually I have no strong opinion on the wording, than that I think ERS should stay open to other time-stamping technologies (not only limiting itself to any set) as had this been through all our drafts. I would prefer to stick with the current text as I think that this already gives other standards especially the ones named by you the right emphasize and space. I could also live with the texts you propose except for one small change: Use "e.g." instead of "i.e." in the second section: > "timeStamp must contain the verifiable time-stamp as defined in > section "1.3. Terminology", i.e., as defined with TimeStampToken in > [RFC 3161], [ANSX995], [I180141], or [I180143]." (e.g. = "as an example", i.e. = "That is" might falsely suggest that we tend to limit the draft to those four references.) At the moment I don't feel that I have sufficient knowledge of the ISO standards you mentioned that I would feel perfectly fine with stating that they "specify an acceptable time-stamp structure". I know this for sure for RFC3161, but am not sure about the ISO standards. Other opinions please? Regards, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Young H. Etheridge > Sent: Wednesday, December 14, 2005 6:27 PM > To: ietf-ltans@imc.org > Subject: Change Request: draft-ietf-ltans-ers-04.txt > > > Regarding the recent posting of "draft-ietf-ltans-ers-04", it seems > reasonable to me that the ERS validation spec should refer to an > abstract timestamp validation algorithm with details provided by the > specification associated with the type of timestamp employed by an > implementer. To that end, I suggest the following simple changes to the > draft: > > In section "1.3. Terminology" -- change -- > > -- from -- > > "Time-Stamp: A signed confirmation generated by a Time Stamping > Authority (TSA) that a data item existed at a certain time. > [RFC3161] specifies a good structure for time-stamps and a > protocol for communicating with a Time-stamp Authority (TSA). > Further good structures and protocols for communicating with a > Time-stamp Authority (TSA) may also, but not exclusively, be > [I180141], [I180142], [I180143], and [ANSX995]." > > -- to -- > > "Time-Stamp: A verifiable confirmation generated by a Time Stamping > Authority (TSA) that a data item existed at a certain time. > [RFC3161], > [ANSX995], [I180141], or [I180143] specify an acceptable time-stamp > structure along with a protocol for communicating with a TSA." > > and > > In Section "3.1. Syntax" -- change -- > > -- from -- > > "timeStamp should contain the time-stamp as defined in section 1.3 > "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]). > 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." > > -- to -- > > "timeStamp must contain the verifiable time-stamp as defined in > section "1.3. Terminology", i.e., as defined with TimeStampToken in > [RFC 3161], [ANSX995], [I180141], or [I180143]." 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 jBEHfIhm065058; Wed, 14 Dec 2005 09:41: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 jBEHfITB065057; Wed, 14 Dec 2005 09:41:18 -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 jBEHfGMl065048 for ; Wed, 14 Dec 2005 09:41:16 -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 jBEHfCLt026109 for ; Wed, 14 Dec 2005 18:41:14 +0100 (MET) 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_01C600D5.920E583D" Subject: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Date: Wed, 14 Dec 2005 18:41:17 +0100 Message-ID: <3C1BE8610E44734499EF92FB35F5B0700164867E@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: ERS - question for consensus about the mentioning of other TS Services (other than RFC3161) in the I-D Thread-Index: AcYA1ZZSlpX15j8qQlODEeKMopodKA== 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_01C600D5.920E583D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 at the moment the role of other TS mechanisms (besides RFC3161) is not = fully agreed.=20 =20 In all past versions we specified that for ERS a TimeStamp should be = used and mentioned RFC3161 as one example, not naming any other ones = specifically.=20 =20 Young suggested to also mention and name also some other timestamp = techniques, especially ISO ([I180141], [I180142], [I180143], and = [ANSX995] - References see below). =20 Which I did in a first and soft step in ERS-04, besides I asked Carl to = raise this topic at the last IETF meeting.=20 =20 Young asked me to prepare a slightly stronger wording about the use of = the timestamps other than RFC3161. So I ask for mailing-list opinion to find out about consensus how to = change the draft. Currently I see three options (but am open for additional ones coming = from the community): a) we stay with the 04-draft = (http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt) b) we change the draft as proposed by Young slightly, more = emphasizing the use of ISO timestamps and in my opinion de-emphasizing = the use of others not mentioned in the draft c) go back to the wording in ERS-03 by removing the names and = references to the ISO timestamp concepts. =20 =20 =20 The specific parts in question are: =20 In Section 1.3. Terminology -- change -- =20 "Time-Stamp: A signed confirmation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies a good structure for time-stamps and a protocol for communicating with a Time-stamp Authority (TSA). Further good structures and protocols for communicating with a Time-stamp Authority (TSA) may also, but not exclusively, be [I180141], [I180142], [I180143], and [ANSX995]." =20 -- to -- =20 "Time-Stamp: A signed confirmation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies an acceptable structure for time-stamps and a protocol for communicating with a Time-stamp Authority (TSA). Further acceptable structures and protocols for communicating with = a Time-stamp Authority (TSA) may be those specified in [I180141], [I180143], or [ANSX995]." =20 =20 In Section 3.1 Syntax -- change -- =20 "timeStamp should contain the time-stamp as defined in section 1.3 "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]). 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." =20 -- to -- =20 "timeStamp should contain the time-stamp as defined in section 1.3 "Terminology". (e.g. as defined with timeStampToken in [RFC 3161], [ANSX995], [I180141], or [I180143])." =20 =20 Open for votes, opinion, discussion! =20 Best regards, Tobias =20 =20 =20 =20 References:=20 [ANSX995] American National Standard for Financial Services, "Trusted Timestamp Management and Security", ANSX X9.95- 2005, June 2005. =20 [I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: Framework", ISO ISO-18014-1, February 2002. =20 [I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: Mechanisms producing independent tokens", ISO ISO-18014-2, December 2002. =20 [I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: Mechanisms producing linked tokens", ISO ISO-18014-3, February 2004. =20 =20 =20 =20 __________________________________________ 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. =20 ------_=_NextPart_001_01C600D5.920E583D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

at the moment the role of other TS mechanisms = (besides RFC3161) is not fully agreed.

 

In all past versions we specified that for ERS a = TimeStamp should be used and mentioned RFC3161 as one example, not naming any = other ones specifically.

 

Young suggested to also mention and name also some = other timestamp techniques, especially ISO ([I180141], [I180142], [I180143], and = [ANSX995] – References see below).

 

Which I did in a first and soft step in ERS-04, = besides I asked Carl to raise this topic at the last IETF meeting. =

 

Young asked me to prepare a slightly stronger wording = about the use of the timestamps other than = RFC3161.

So I ask for mailing-list opinion to find out about consensus how to change the draft.

Currently I see three options (but am open for = additional ones coming from the community):

a)       = we stay with the 04-draft = (http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-04.txt)

b)       = we change the draft as proposed by Young slightly, more emphasizing the use of ISO timestamps and in my opinion de-emphasizing the use of others not = mentioned in the draft

c)       = go back to the wording in ERS-03 by removing the names and references to the ISO = timestamp concepts.

 

 

 

The specific parts in question = are:

 

In Section 1.3.=A0 = Terminology -- change --

 

"Time-Stamp: A = signed confirmation generated by a Time Stamping

=A0=A0=A0=A0=A0 = Authority (TSA) that a data item existed at a certain time.

=A0=A0=A0=A0=A0 = [RFC3161] specifies a good structure for time-stamps and a

=A0=A0=A0=A0=A0 = protocol for communicating with a Time-stamp Authority = (TSA).

=A0=A0=A0=A0=A0 = Further good structures and protocols for communicating with = a

=A0=A0=A0=A0=A0 = Time-stamp Authority (TSA) may also, but not exclusively, be

=A0=A0=A0=A0=A0 = [I180141], [I180142], [I180143], and [ANSX995]."

 

-- to = --

 

"Time-Stamp: A = signed confirmation generated by a Time Stamping

=A0=A0=A0=A0=A0 = Authority (TSA) that a data item existed at a certain time.

=A0=A0=A0=A0=A0 = [RFC3161] specifies an acceptable structure for time-stamps and a

=A0=A0=A0=A0=A0 = protocol for communicating with a Time-stamp Authority = (TSA).

=A0=A0=A0=A0=A0 = Further acceptable structures and protocols for communicating with = a

=A0=A0=A0=A0=A0 = Time-stamp Authority (TSA) may be those specified in

=A0=A0=A0=A0=A0 = [I180141], [I180143], or [ANSX995]."

 

 

In Section 3.1 = Syntax -- change --

 

"timeStamp = should contain the time-stamp as defined in section = 1.3

=A0=A0 = "Terminology". (e.g. as defined with timeStampToken in [RFC = 3161]).

=A0=A0 Other types = of time-stamp might be used, if they contain time data,

=A0=A0 time-stamped = data and a signature from the TSA of these data."

 

-- to = --

 

"timeStamp = should contain the time-stamp as defined in section = 1.3

=A0=A0 = "Terminology". (e.g. as defined with timeStampToken in [RFC = 3161],

=A0 [ANSX995], = [I180141], or [I180143])."

 

 

Open for votes, opinion, = discussion!

 

Best regards, Tobias

 

 

 

 

References:

=A0=A0 [ANSX995]=A0 American National Standard for = Financial Services,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Trusted = Timestamp Management and Security", ANSX X9.95-

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2005, June = 2005.

 

=A0=A0 [I180141]=A0 ISO/IEC JTC 1/SC 27, "Time = stamping services - Part 1:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Framework", ISO ISO-18014-1, February 2002.

 

=A0=A0 [I180142]=A0 ISO/IEC JTC 1/SC 27, "Time = stamping services - Part 2:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mechanisms = producing independent tokens", ISO ISO-18014-2,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 December = 2002.

 

=A0=A0 [I180143]=A0 ISO/IEC JTC 1/SC 27, "Time = stamping services - Part 3:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mechanisms = producing linked tokens", ISO ISO-18014-3,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 February = 2004.

 

 

 

 

__________________________________________
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@opentex= t.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_01C600D5.920E583D-- 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 jBEHP15N062752; Wed, 14 Dec 2005 09:25: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 jBEHP1gu062751; Wed, 14 Dec 2005 09:25:01 -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 jBEHP01h062745 for ; Wed, 14 Dec 2005 09:25:00 -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 1F93915894 for ; Wed, 14 Dec 2005 12:24:56 -0500 (EST) Message-ID: <43A055CD.2060507@yhetheridge.org> Date: Wed, 14 Dec 2005 12:26:37 -0500 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Change Request: draft-ietf-ltans-ers-04.txt 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: Regarding the recent posting of "draft-ietf-ltans-ers-04", it seems reasonable to me that the ERS validation spec should refer to an abstract timestamp validation algorithm with details provided by the specification associated with the type of timestamp employed by an implementer. To that end, I suggest the following simple changes to the draft: In section "1.3. Terminology" -- change -- -- from -- "Time-Stamp: A signed confirmation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies a good structure for time-stamps and a protocol for communicating with a Time-stamp Authority (TSA). Further good structures and protocols for communicating with a Time-stamp Authority (TSA) may also, but not exclusively, be [I180141], [I180142], [I180143], and [ANSX995]." -- to -- "Time-Stamp: A verifiable confirmation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161], [ANSX995], [I180141], or [I180143] specify an acceptable time-stamp structure along with a protocol for communicating with a TSA." and In Section "3.1. Syntax" -- change -- -- from -- "timeStamp should contain the time-stamp as defined in section 1.3 "Terminology". (e.g. as defined with timeStampToken in [RFC 3161]). 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." -- to -- "timeStamp must contain the verifiable time-stamp as defined in section "1.3. Terminology", i.e., as defined with TimeStampToken in [RFC 3161], [ANSX995], [I180141], or [I180143]." 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 jB9HrVSu056799; Fri, 9 Dec 2005 09:53: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 jB9HrVjr056798; Fri, 9 Dec 2005 09:53:31 -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 jB9HrUVx056785; Fri, 9 Dec 2005 09:53:31 -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 jB9HrUC7017857; Fri, 9 Dec 2005 12:53:30 -0500 From: "Santosh Chokhani" To: Cc: Subject: RE: Certificate Validity Problem Date: Fri, 9 Dec 2005 12:53:24 -0500 Message-ID: <00cc01c5fce9$76d7c980$ac00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcX86J3NCoy8rQjcTTe6bG+FSIf9kwAAE3Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <7.0.0.10.2.20051209110230.06577be8@vigilsec.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The work being done in the IETF LTANS will also help. Also, there is an I-D that is relevant to this effort. The following is the I-D URL. http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-00.txt -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Friday, December 09, 2005 11:04 AM To: Stephen Kent; Ersin Gulacti Cc: ietf-pkix@imc.org Subject: Re: Certificate Validity Problem The protocol accommodates the query, but the server need to keep the historical data to respond property. As I see it, this historical data retention is optional. Russ At 11:59 AM 12/8/2005, Stephen Kent wrote: >>Hello, >> >>We are operating a Certificate Authority (which uses our own CA software) >>and we have a process to set certificate status to on-hold. Owners of >>certificates can put their certificates on-hold and they can return them >>to the valid status. >> >>When somebody tries to verify the validity of signature he can only check >>the most recent status of the certificate. He can use the most fresh CRL >>or execute an OCSP query. Both of these techniques lack an important >>functionality, you cannot query the status of a certificate at a certain >>time in the past. Maybe at the time of signing the certificate used was >>on-hold. >> >>Is there a method or another technique to solve this problem? >> >>Thanks. > >SCVP should be able to accommodate queries about the status of a >cert at a previous point in time. > >Steve > 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 jB8Ko2JW043702; Thu, 8 Dec 2005 12:50:02 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8Ko2u8043693; Thu, 8 Dec 2005 12:50:02 -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 jB8Ko13V043681 for ; Thu, 8 Dec 2005 12:50:02 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EkSiH-0007wE-Bg; Thu, 08 Dec 2005 15: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-04.txt Message-Id: Date: Thu, 08 Dec 2005 15: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-04.txt Pages : 25 Date : 2005-12-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-04.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-04.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-04.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: <2005-12-8115306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-8115306.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 jB6BwcI4012700; Tue, 6 Dec 2005 03:58:38 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB6Bwc6b012699; Tue, 6 Dec 2005 03:58:38 -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 jB6BwanR012689 for ; Tue, 6 Dec 2005 03:58:36 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (124.sub-70-194-165.myvzw.com [70.194.165.124]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jB6BwQGf029853; Tue, 6 Dec 2005 06:58:27 -0500 Message-Id: <200512061158.jB6BwQGf029853@host15.websitesource.com> From: "Carl Wallace" To: "'Tobias Gondrom'" , "'Hannes Weber'" Cc: Subject: RE: ERS and certificates Date: Tue, 6 Dec 2005 06:58:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B0700159E69C@MUCXGC1.opentext.net> Thread-Index: AcX5rJpFFfZIbX1hT5a9Y7GeEM2DOQAKMEHQACGGReA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > And before answering: in nearly all commercial applications > it can be expected that they are able to (and DO) retrieve > the verification data (certificate path and OCSP/CRL) at the > time of entry into the system and can add this information as > recommended by ISIS-MTT to the signed documents. Similarly, this could be done before applying a refreshed timestamp. What's the process for discovering the validation information used to verify a timestamp chain? > In case this is not the case, one has to find a solution as > you thought of. > And your idea of simply extending the model of the > EvidenceRecord by simply adding the additional verification > data as an additional file represented by a hash value in the > normal hashtrees is the right approach. 1) Should we define a standard means of associating validation information with an EvidenceRecord to cover these cases instead of leaving it up to folks to roll their own? 2) Is there anything else that should be associated with an EvidenceRecord besides validation information? I thought the consensus during the Paris meeting was the crypto policy needed to be covered. Perhaps ERS needs some extensible fields a la attributes or extensions. 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 jB6823sN084432; Tue, 6 Dec 2005 00:02:03 -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 jB6823SV084431; Tue, 6 Dec 2005 00:02:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB6822sx084424 for ; Tue, 6 Dec 2005 00:02:02 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 7A08D6D3FD; Tue, 6 Dec 2005 00:01:57 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Tobias Gondrom'" , Cc: "'Young H. Etheridge'" , "'Carl Wallace'" Subject: RE: ltans: ers-04 Date: Tue, 6 Dec 2005 00:06:01 -0800 Message-ID: <001e01c5fa3b$e686b710$1700a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C5F9F8.D8668450" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B0700159E697@MUCXGC1.opentext.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX51TOc5uzr4A7DQ+eOAnLuQkPXmgAYxqXw 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_001F_01C5F9F8.D8668450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 _____ =20 From: Tobias Gondrom [mailto:tgondrom@opentext.com]=20 Sent: Monday, December 05, 2005 11:51 AM To: ietf-ltans@imc.org Cc: Jim Schaad; Young H. Etheridge; Carl Wallace Subject: ltans: ers-04 Jim, Young, Carl, =20 Thanks for your thorough review.=20 I adopted your remarks and made the corrections you recommended. Document will soon also be sent via IETF to the mailing-list =96 until = then so far via attachment.=20 Before the long Q&A below: I really adopted nearly all comments and corrections you proposed, these are mainly answers to questions from Jim = and a few requests for further clarification of some of comments from Jim. @Young: I widened the scope of the potentially used timestamps as you requested (though not using such a quite strong wording as you proposed = in your comments sent to me). Please provide me feedback whether this is sufficient in your eyes. =20 @all: take a final look! =96 we SHOULD go to WG last call next week. =20 =20 Thanks for your help =20 Tobias =20 =20 =20 =20 I only refer to questions where I did not change the text: >From Jim: Q: Section 2.1: digestAlgorithms - is this just the OIDs of the = algorithm identifiers or does this include all of the parameters as well? A: We refer here to =93AlgorithmIdentifier FROM AI ;=94 =20 Q: Section 2.1: field encryption in EvidenceRecord is not described in = order and in the same format. A: Yes, but I don=92t understand the problem. Encryption is optional and covers the option to encrypt content before submitting it to an archive. = We define EncryptionMethod for this. =20 =20 I don't object to the fact that there is a fuller descripiton = else where, but feel the text should say something like: =20 encryption contains the data necessary to allow for .... and is more completely discussed in section 5.1 =20 Q: Section 2.1: field encrytion - is this suppose to contain infomration about re-encryption or about decryption of the fields? There is some differences between these. Suggest a hint about where keys are found is included = as well in this location. A: EncryptionMethod is defined in Section 5.1 =20 The discription of EncryptionMethod refered to having enough data = to re-encrypt the message if necessary. Where is the informatino to = decrypt the message kept? Is the document suppose to be a ContentInfo object?=20 =20 Q: Section 3.1: Are you restricted to a single set of parameters? If = you are doing multiple hash operations might one which to allow for = different sets of parameters for each of the hash operations? A: Within one hash-tree: Yes. As you can see within an = ArchiveTimeStampChain one can of course have multiple ArchiveTimeStapms with different hash = algs for the hash-trees. Do you see need for more than one hash alg within one hash-tree? =20 The question deals not with multiple hash algorithms but a single = hash algorithm which has parameters. I.e. a keyed hash fucntion. In this = case there might be multiple sets of parameters that are used with the single hash function.=20 =20 Q: Section 3.2: From my reading of the text, Figure 3 should be (h1), = (h2a, h2b, h2c), (h3) as this is the order items are in the tree above.=20 A: No. The hash-tree in figure 1 does not reflect with its order the = binary order of the elements on the same level of the tree. See also above = Figure 2 =93Assuming that the sorted binary ordering of the hashes in Figure 1 = is: h2abc < h1 then the reduced hash-tree for data group 1 (d1) is:=93 =20 =20 OK.=20 =20 Q: Section 3.2: There not text or reference for how grouping is done. = (step 4 - place in groups and sort) A: sorting is in binary ascending order, the granularity of the tree is = not necessary to define. E.g. the number of leaves on every level is open = for the implementation =96 any number can be verified with the described algorithms.=20 =20 My issue is not with sorting, but with grouping. The information dealing with grouping is not kept in the tree, does it need to be? When does one know that grouping is necessary --- is this out of scope of the document?=20 =20 Q: Section 3.3: Why search in the first list rather than the entire = list of reducedHashtree? It seems to me that it could be anyplace in the list = and still be valid. A: as only corresponding neighboring leaves are in the reducedhashtree = and the lowest level is the first list, it must be in the first group of = values. See also section 3.2 below figure 1 listed items 1-3=20 =20 The answer has to to do with how a new hash algorithm is applied.=20 =20 Q: Section 3.3: In step 3 it says that the value must be a member of the next higher list --- WHAT LIST????? The reduction removes these from the list of hash values. It must be taken on faith that it is correct until = you reach the root. A: Yes. Computing the complete hashtree will need to compute until the highest node to verify that the hashtree is consistent. On the other = hand we expect less false trees and can save memory by not storing values that = are easily computable (redundantly). The fact that an item belongs to a = reduced hash-tree on the other hand can easily be verified as this hash value is = in the first list.=20 =20 Then make the text simplier and just say that the hash tree is re-computed to get the root value and don't talk about intermediate = values.=20 =20 Q: Section 3.3: How does one re-construct the grouping that was created = in the production step? Very non-obious You don=92t need to do much reconstruction. Verify the lists you got is = all you need to do. For this the simple rules (order binary ascendant and concatenate, compute hash of next level) are fully sufficient. =20 As with the above, if you just say use the existing reduced tree = and re-compute the root value of the tree then the question of how to = re-group because unimportant.=20 =20 Q: Section 4.1: What does it mean for a ArchiveTimeStampSequence to be ordered by time of timestamp? If I run two parallel = ArchiveTimeStampChains with different hash functions and sign both at the approx the same time = -- which comes first? Ordered by the first entry or the last entry on the chain? There is no reason to assume that all of the entries in the second chain occur after all of the entiries in the first chain. A: Oh yes it is. Every ArchiveTimeStampChain is securing the existence = of the one before (it refers to the timestamp of the one before) as well as every ArchiveTimeStampChain must be temporal after the first one (it = also refers to the one before =96 for that it could not be created without = there one before closed. =20 Which means that you need to include text someplace which says I cannot run to conccurent ArrivheTimeStampChains at the same time with different hash values.=20 =20 Q: Section 4.2: It states that the hash algorithms must be the same -- = how about the hash algorithm parameters? A: You are probably right and it should state a SHOULD (but a really = strong SHOULD ;-) ) =96 will discuss this with a person who implemented it =96 = maybe someone else can verify this too? =20 Q: Section 4.2, 4.3: I have serveral issues with the algorithm that you = are using to replace a hash functions. They are: =20 Q: 1) I believe that atsc(i) should be a constant for all documents. A document should never be deleted and then re-added, nor is a document = added during the process of renewing a timestamp. Thus either the document = has been deleted (in which case it is not re-hashed) or it is in every ArchiveTimeStampSequence. Ergo - atsc(i) is constant for all values of = i. A: no atsc(i) is not constant for all documents within a tree as the = atsc(i) consists on the lowest atomic level of reducedhashtrees which do NOT = contain all hashvalues of all documents but only the hash values of all = neighbours to the document in question. (comment: this has the advantage of = limiting the size of the EvidenceRecord to the amount of data really needed =96 = not unnecessarily inflating the data =96 think e.g. of 10^9 objects in a = hashtree and adding new hashtrees=85.)=20 =20 I am definately going to implement this incorrectly. What you are discribing and what I read in the document have absolutely no relation = with each other.=20 =20 Q: 2) Verification requires that an implemenation of all previous hash algorithms be kept is that what one wants to do? (I.e. do you want to = be able to have a "fast" proof using just the current data). A: you MUST keep the old hash values because they are the algs to prove = the consistent over the first periods of time =96 using only the new hash = algs can never provide proof over time where they have not been used. =20 I understand that I need to be able to do a full walk of the tree, = the question of being able to start with a fast walk and then go back and do = the complete proof is what I was asking.=20 =20 Q: 3) What happens if only one item is left in a document group (i.e the rest have been deleted)? Is it treated as a document group of one or as = a single document? A: The hash values of these documents still remain in the group they can never be removed as by this the integrity of the group could never be proved. On the other hand thanks to the characteristics of hash algs = there is no way to get information about a deleted document from its former = e.g. 160bit hash value (one way, etc.) =20 How do I compute H((d(i)) in the event that the document has been deleted, but d(i) is part of a group with d(j) =20 Q: Section 5.1: The proper term is detached content rather than = external content. Suggest "encryptionCover is a CMS content type of = EnvelopedData where the encryptedContent field is absent" A: could you please explain this a bit more? I don=92t understand your suggestion completely.=20 =20 I believe that this is a simpler way of saying the same thing that your current text is attempting to say, but using CMS language. =20 Q: Section 5.1: Putting the private key into a BIT STRING is = problematic. I would suggest either an OCTET STRING or an ANY DEFINED BY with the OID = as well. A: What problem do you see with BIT STRING ?=20 =20 Well -- the first think you are wasting space for the unused bit = field -- going to an OCTET STRING would eliminate that problem. Secondly I = don't know if there is a justification for adding the wrapping field at all. Lastly having the OID present would make life easier in terms of trying = to figure out what the internal data structure really is.=20 =20 Q: Section 5.1: I don't understand the set of parameters that you have defined for re-encryption of the structure. I would thing that the only thing that you need is the ContentEncryptionKey in the clear - The rest = of the parameters are kept in the encryptionCover field. You don't need to = the public key or the KeyEncryptionKey fields unless you are intending to re-build the EncryptionCover field. A: first you might want them for convenience and better organization of = the verification, second you need e.g. the ssed to be counter potential = attacks trying to bring in a second encrypted document with different content = and different seed but same hash value of the encrypted document. I know = this is potential paranoia, but discussions pointed our potential attack vectors here.=20 =20 If this is really what you are trying to protect against it would = be better to have a hash of the original document and rely on not being = able to (1) invert the hash and (2) not having the document to do a comparision = for equivalance of the document to see if it is the one that was archived. Unless the encryptiojn parameters are included in the timestamp value = (which does not appear to be true from the text) then you are not protecting againist having a different document show up that has the same hash = value but different content encryption key.=20 =20 Q: Section 5.1: If you are using the EncryptedData field you need to = make some additional statements that are not required in CMS. A. where in the document do you refer to the EncryptedData field? =20 1) The ContentInfo field to be submitted MUST be DER encoded. 2) The encrypted content MUST be connonicalized PRIOR to being = encrypted. (i.e. ASN.1 is DER encoded, MIME uses S/MIME rules and so forth) 3) The EncryptedData RecipientInfos MUST ALL be kept intact unless the EncryptedData field was not archived.=20 =20 Sorry -- I meant EnvelopedData not EncryptedData. =20 =20 Section 6: Use the correct module for CMS --=20 CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } Q: thanks for the correction =96 done. =20 =20 Q: Section 6: Add a reference comment to each of the IMPORT-ed modules = -- >From [RFCXXXX] so that they can be easily found A: done. =20 =20 Comment: Useful to have the list name in the document so I know where = to send mail to. A: you=92re right would be useful. On the other hand the WG is named and = the mailing-list can be derived from that easily via www.ietf.org and further it is not common, and therefore not done. =20 -- pity one of the problems with going to the XML document = version. I used to include the mailing list name in the status section of all of = the documents that I wrote. =20 =20 =20 =20 =20 =20 =20 __________________________________________ 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. =20 ------=_NextPart_000_001F_01C5F9F8.D8668450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

From: Tobias Gondrom=20 [mailto:tgondrom@opentext.com]
Sent: Monday, December 05, = 2005=20 11:51 AM
To: ietf-ltans@imc.org
Cc: Jim Schaad; = Young H.=20 Etheridge; Carl Wallace
Subject: ltans: = ers-04

Jim, Young,=20 Carl,

 

Thanks for your thorough = review.=20

I adopted your remarks = and made=20 the corrections you recommended.

Document will soon also = be sent=20 via IETF to the mailing-list =96 until then so far via attachment.=20

Before the long Q&A = below: I=20 really adopted nearly all comments and corrections you proposed, these = are=20 mainly answers to questions from Jim and a few requests for further=20 clarification of some of comments from = Jim.

@Young: I widened the = scope of the=20 potentially used timestamps as you requested (though not using such a = quite=20 strong wording as you proposed in your comments sent to me). Please = provide me=20 feedback whether this is sufficient in your = eyes.

 

@all: take a final look! = =96 we=20 SHOULD go to WG last call next week.

 

 

Thanks for your=20 help

 

           = =20 Tobias

 

 

 

 

I only refer to = questions where I=20 did not change the text:

From=20 Jim:

Q: Section 2.1:=20 digestAlgorithms - is this just the OIDs of the algorithm identifiers = or does=20 this include all of the parameters as = well?

A: We refer here to=20 =93AlgorithmIdentifier FROM=20 AI ;=94

 

Q: Section 2.1: = field=20 encryption in EvidenceRecord is not described in order and in the same = format.

A: Yes, but I don=92t = understand the=20 problem. Encryption is optional and covers the option to encrypt = content=20 before submitting it to an archive. We define EncryptionMethod for this.  

 

<JLS>  I don't=20 object to the fact that there is a fuller descripiton else where, but = feel the=20 text should say something like:

 

encryption contains = the data=20 necessary to allow for .... and is more completely discussed in = section=20 5.1

 

Q: Section 2.1: = field=20 encrytion - is this suppose to contain infomration about re-encryption = or=20 about decryption of the fields?  There is some=20 differences

between = these.  =20 Suggest a hint about where keys are found is included=20 as

well in this=20 location.

A:=20 EncryptionMethod  is defined in = Section=20 5.1

 

<JLS> The = discription of=20 EncryptionMethod refered to having enough data to re-encrypt the = message if=20 necessary.  Where is the informatino to decrypt the message = kept? =20 Is the document suppose to be a ContentInfo=20 object? 

 

Q: Section = 3.1:  Are=20 you restricted to a single set of parameters?  If you are doing = multiple=20 hash operations  might one which to allow for different sets of=20 parameters for each of the hash = operations?

A: Within one = hash-tree:=20 Yes. As you can see within an ArchiveTimeStampChain one can of course = have=20 multiple ArchiveTimeStapms with different hash algs for the=20 hash-trees.

Do you see need = for more=20 than one hash alg within one hash-tree?

 

<JLS>=20 The question deals not with multiple hash algorithms but a single = hash=20 algorithm which has parameters.  I.e. a keyed hash = fucntion.  In=20 this case there might be multiple sets of parameters that are = used with=20 the single hash function. 

 

Q: Section 3.2: = >From my=20 reading of the text, Figure 3 should be (h1), (h2a, h2b, h2c), (h3) as = this is=20 the order items are in the tree above.

A: No. The = hash-tree in=20 figure 1 does not reflect with its order the binary order of the = elements on=20 the same level of the tree. See also above Figure 2 =93Assuming that = the sorted=20 binary ordering of the hashes in Figure 1 is: h2abc < h1 then the = reduced=20 hash-tree for data group 1 (d1) is:=93  

 

<JLS>=20 OK. 

 

Q: Section = 3.2: =20 There not text or reference for how grouping is done. (step=20 4

- place in = groups and=20 sort)

A: sorting is in = binary=20 ascending order, the granularity of the tree is not necessary to = define. E.g.=20 the number of leaves on every level is open for the implementation =96 = any=20 number can be verified with the described algorithms. 

 

<JLS> My issue = is not with=20 sorting, but with grouping.  The information dealing with = grouping is not=20 kept in the tree, does it need to be?  When does one know that = grouping=20 is necessary --- is this out of scope of the=20 document? 

 

Q: Section = 3.3:  Why=20 search in the first list rather than the entire list of = reducedHashtree? =20 It seems to me that it could be anyplace in the list and still be=20 valid.

A: as only = corresponding=20 neighboring leaves are in the reducedhashtree and the lowest level is = the=20 first list, it must be in the first group of=20 values.

See also section = 3.2 below=20 figure 1 listed items 1-3 

 

<JLS> The = answer has=20 to to do with how a new hash algorithm is=20 applied. 

 

Q: Section 3.3: = In step 3=20 it says that the value must be a member of the next higher list --- = WHAT=20 LIST????? The reduction removes these from the list of hash = values.  It=20 must be taken on faith that it is correct until you reach the=20 root.

A: Yes. = Computing the=20 complete hashtree will need to compute until the highest node to = verify that=20 the hashtree is consistent. On the other hand we expect less false = trees and=20 can save memory by not storing values that are easily computable=20 (redundantly). The fact that an item belongs to a reduced hash-tree on = the=20 other hand can easily be verified as this hash value is in the first=20 list. 

 

<JLS> Then make=20 the text simplier and just say that the hash tree is re-computed = to get=20 the root value and don't talk about intermediate=20 values. 

 

Q: Section 3.3: = How does=20 one re-construct the grouping that was created in the production = step? =20 Very non-obious

You don=92t need = to do much=20 reconstruction. Verify the lists you got is all you need to do. For = this the=20 simple rules (order binary ascendant and concatenate, compute hash of = next=20 level) are fully sufficient.

 

<JLS> As with=20 the above, if you just say use the existing reduced tree = and re-compute=20 the root value of the tree then the question of how to re-group=20 because unimportant. 

 

Q: Section = 4.1:  What=20 does it mean for a ArchiveTimeStampSequence to be ordered by time of=20 timestamp?  If I run two parallel ArchiveTimeStampChains with = different=20 hash functions and sign both at the approx the same time -- which = comes=20 first?  Ordered by the first entry or the last entry on the=20 chain?

There is no = reason to=20 assume that all of the entries in the second chain occur after all of = the=20 entiries in the first chain.

A: Oh yes it is. = Every=20 ArchiveTimeStampChain is securing the existence of the one before (it = refers=20 to the timestamp of the one before) as well as every = ArchiveTimeStampChain=20 must be temporal after the first one (it also refers to the one before = =96 for=20 that it could not be created without there one before=20 closed.

 

<JLS> Which=20 means that you need to include text someplace which says I cannot run = to=20 conccurent ArrivheTimeStampChains at the same time with different = hash=20 values. 

 

Q: Section = 4.2:  It=20 states that the hash algorithms must be the same -- how about the hash = algorithm parameters?

A: You are = probably right=20 and it should state a SHOULD (but a really strong SHOULD ;-) ) =96 = will discuss=20 this with a person who implemented it =96 maybe someone else can = verify this=20 too?

 

Q: Section 4.2, = 4.3: I=20 have serveral issues with the algorithm that you are using to replace = a hash=20 functions.  They are:

 

Q: 1) I believe = that=20 atsc(i) should be a constant for all documents.  A document = should never=20 be deleted and then re-added, nor is a document added during the = process of=20 renewing a timestamp.  Thus either the document has been deleted = (in=20 which case it is not re-hashed) or it is in every=20 ArchiveTimeStampSequence.  Ergo - atsc(i) is constant for all = values of=20 i.

A: no atsc(i) is = not=20 constant for all documents within a tree as the atsc(i) consists on = the lowest=20 atomic level of reducedhashtrees which do NOT contain all hashvalues = of all=20 documents but only the hash values of all neighbours to the document = in=20 question. (comment: this has the advantage of limiting the size of the = EvidenceRecord to the amount of data really needed =96 not = unnecessarily=20 inflating the data =96 think e.g. of 10^9 objects in a hashtree and = adding new=20 hashtrees=85.) 

 

<JLS> I am = definately going=20 to implement this incorrectly.  What you are discribing and what = I read=20 in the document have absolutely no relation with each=20 other. 

 

Q: 2) = Verification=20 requires that an implemenation of all previous hash algorithms be kept = is that=20 what one wants to do?  (I.e. do you want to be able to have a = "fast"=20 proof using just the current data).

A: you MUST keep = the old=20 hash values because they are the algs to prove the consistent over the = first=20 periods of time =96 using only the new hash algs can never provide = proof over=20 time where they have not been used.

 

<JLS> I=20 understand that I need to be able to do a full walk of the tree, the=20 question of being able to start with a fast walk and then go back = and do=20 the complete proof is what I was=20 asking. 

 

Q: 3) What = happens if only=20 one item is left in a document group (i.e the rest have been = deleted)? =20 Is it treated as a document group of one or as a single=20 document?

A: The hash = values of=20 these documents still remain in the group they can never be removed as = by this=20 the integrity of the group could never be proved. On the other hand = thanks to=20 the characteristics of hash algs there is no way to get information = about a=20 deleted document from its former e.g. 160bit hash value (one way,=20 etc.)

 

<JLS>  How do I compute H((d(i)) = in the=20 event that the document has been deleted, but d(i) is part of a group = with=20 d(j)

 

Q: Section = 5.1:  The=20 proper term is detached content rather than external content.  = Suggest=20 "encryptionCover is a CMS content type of EnvelopedData where the=20 encryptedContent field is absent"

A: could you = please=20 explain this a bit more? I don=92t understand your suggestion = completely. 

 

<JLS> I = believe that=20 this is a simpler way of saying the same thing that  your current = text is=20 attempting to say, but using CMS=20 language.

 

Q: Section 5.1: = Putting=20 the private key into a BIT STRING is problematic.  I would = suggest either=20 an OCTET STRING or an ANY DEFINED BY with the OID as=20 well.

A: What problem = do you see=20 with BIT STRING ? 

 

<JLS> Well = -- the=20 first think you are wasting space for the unused bit field = -- going=20 to an OCTET STRING would eliminate that problem.  Secondly I = don't know=20 if there is a justification for adding the wrapping field at = all.  Lastly=20 having the OID present would make life easier in terms of trying to = figure out=20 what the internal data structure really=20 is. 

 

Q: Section = 5.1:  I=20 don't understand the set of parameters that you have defined for = re-encryption=20 of the structure.  I would thing that the only thing that you = need is the=20 ContentEncryptionKey in the clear - The rest of the parameters are = kept in the=20 encryptionCover field.  You don't need to the public key or the=20 KeyEncryptionKey fields unless you are intending to re-build the=20 EncryptionCover field.

A: first you = might want=20 them for convenience and better organization of the verification, = second you=20 need e.g. the ssed to be counter potential attacks trying to bring in = a second=20 encrypted document with different content and different seed but same = hash=20 value of the encrypted document. I know this is potential paranoia, = but=20 discussions pointed our potential attack vectors here. 

 

<JLS> If = this is=20 really what you are trying to protect against it would be better to = have a=20 hash of the original document and rely on not being able to (1) = invert=20 the hash and (2) not having the document to do a comparision for=20 equivalance of the document to see if it is the one that was = archived. =20 Unless the encryptiojn parameters are included in the timestamp=20 value (which does not appear to be true from the text) then you = are not=20 protecting againist having a different document show up that has the = same hash=20 value but different content encryption=20 key. 

 

Q: Section = 5.1:  If=20 you are using the EncryptedData field you need to make some additional = statements that are not required in CMS.

A. where in the = document=20 do you refer to the EncryptedData field?

 

1) The = ContentInfo field=20 to be submitted MUST be DER encoded.

2) The encrypted = content=20 MUST be connonicalized PRIOR to being = encrypted.

(i.e. ASN.1 is = DER=20 encoded, MIME uses S/MIME rules and so = forth)

3) The = EncryptedData=20 RecipientInfos MUST ALL be kept intact unless the EncryptedData field = was not=20 archived. 

 

<JLS> Sorry -- = I=20 meant EnvelopedData not=20 EncryptedData.

 <= /FONT>

 

Section 6:  = Use the=20 correct module for CMS --

  =20 CryptographicMessageSyntax2004

     {=20 iso(1) member-body(2) us(840) = rsadsi(113549)

      =20 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)=20 }

Q: thanks for = the=20 correction =96 done.

 

 

Q: Section = 6:  Add a=20 reference comment to each of the IMPORT-ed modules -- From [RFCXXXX] = so that=20 they can be easily found

A:=20 done.

 

 

Comment:  = Useful to=20 have the list name in the document so I know where to send mail=20 to.

A: you=92re right would = be useful.=20 On the other hand the WG is named and the mailing-list can be derived = from=20 that easily via www.ietf.org and = further it=20 is not common, and therefore not done.

 

 <JLS> -- pity = one of the=20 problems with going to the XML document version.  I used to = include the=20 mailing list name in the status section of all of the documents that I = wrote.

 

 

 

 

 

 

 

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

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

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

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

 

------=_NextPart_000_001F_01C5F9F8.D8668450-- 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 jB5LS7I6008639; Mon, 5 Dec 2005 13:28:07 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB5LS7Ra008638; Mon, 5 Dec 2005 13:28:07 -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 jB5LS6mT008629 for ; Mon, 5 Dec 2005 13:28:06 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-71-246-225-58.washdc.fios.verizon.net [71.246.225.58]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jB5LS3gn014857; Mon, 5 Dec 2005 16:28:03 -0500 Message-Id: <200512052128.jB5LS3gn014857@host15.websitesource.com> From: "Carl Wallace" To: "'Tobias Gondrom'" , "'Hannes Weber'" Cc: Subject: RE: ERS and certificates Date: Mon, 5 Dec 2005 16:28:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcX5rJpFFfZIbX1hT5a9Y7GeEM2DOQAKMEHQAANOX7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B0700159E69C@MUCXGC1.opentext.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Have a look at the SCVP/ERS draft. It uses ERS but separates the preservation of the certification path entirely and thus avoids maintaining an ERS for the certification path repeatedly. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom > Sent: Monday, December 05, 2005 3:28 PM > To: Hannes Weber > Cc: ietf-ltans@imc.org > Subject: RE: ERS and certificates > Importance: Low > > > Hi Hannes, > > nice to read. I heard of about 3 diploma thesis about this > issue in the last 18 months. (one was from IBM, one from FHG, > the third I've forgotten, maybe Siemens) Your findings are > true. It is necessary to include any verification data > (especially the complete certificate path) before the time of > the first hashing and timestamping. If it would be added > lated it would of course change the hash value. > Concerning the certificate path for the timestamps in the > ArchiveTimeStamp itself, it should of course be trivial to > get them at the time of request. > The others should be obtained when the data enters the system > and runs through a first verification before archiving (good > process design would recommend to verify data before archiving). > > And before answering: in nearly all commercial applications > it can be expected that they are able to (and DO) retrieve > the verification data (certificate path and OCSP/CRL) at the > time of entry into the system and can add this information as > recommended by ISIS-MTT to the signed documents. > > In case this is not the case, one has to find a solution as > you thought of. > And your idea of simply extending the model of the > EvidenceRecord by simply adding the additional verification > data as an additional file represented by a hash value in the > normal hashtrees is the right approach. > > But as you can in this case not know when the information > might become available to the system (it might even be AFTER > several timestamp and hashtree renewals) the logic connection > between the elements (original file, verification data) must > be kept by the leading application (in your case the DMS) and > not within the ERS! > > Of course all hash values of all elements can (and SHOULD) > end up in one > hashtree: So if e.g. you add a document with signatures at > let's say Dec > 1 2005 and build a first hashtree (with timestamp) without > the certificate path. You might add the file containing the > certificate path information one day later (Dec 2, 2005) (or > five years later) in a second hashtree. At the time of the > next occurring renewal (no matter how many occurred in > between and no matter be it a timestamp or hashtree > renewal) you simply take care that both hashtrees have their > highest node be represented by a hash in the same new > hashtree. Of course you could also just add the hash value of > the verification data right besides the hash value of the > ArchiveTimeStamp(Chain) of the original document. > > In the end for verification you have a bit more work of > course than you would have had if you included the > verification data before archiving: > You have to verify the integrity of both EvidenceRecords (the > one for the original file and the second for the file with > the additional verification data you e.g. received a day > later). Note: as both EvidenceRecords might have come > together at some point in time as leaves in a new hashtree > you probably can simplify verification procedure due to duplication. > After this first step (or in parallel) you verify the > signatures in the document with the verification data and > only if ALL checks succeed you can assume that the document > and its signatures are correct. > > I strongly recommend to use the EvidenceRecord solely to > proof the non-repudiation of the single objects (ignoring any > potential further relationship between them) and leaving the > link between them to the leading application. (Small personal > comment: I discussed this also with my team and all other > things will most probably get you in trouble with your > implementation. ;-) ) > > Best regards, and if you like please feel free to call if you > have further questions - am always happy to help (and same > time zone could make things easier ;-) ). > > Tobias > > __________________________________________ > Tobias Gondrom > 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/ > > > > > > > Hi, > > i am a student at the university of Bremen (Germany) and recently > wrote my > > diploma thesis about > > digital signatures in long-term archives. The aim of my work was to > > develop a library capable of performing the long-term > non-repudiation > > for digital signed documents > in > > the context of document management systems. > > > > My solution relies on ERS, but in order to be able to > ensure long-term > > non-repudiation for any kind of signatures - that are conform to > > ISIS-MTT - I extended ERS. This > was > > necessary because ERS is > > not capable of prooving the evidence for digital signatures that do > not > > include the complete > > certificate path. > > At the time the evidence record is generated it is not possible to > > extend the renewed signature with the missing certificates of the > > certificate path (the certificates field of a CMS-object in > a signed > > field) which are necessary for the non-repudiation proof. > > So I integrated the certificates of the certificate path > and the OCSP > > responses into the evidence record by exploiting the data > object group > > feature. The renewal of a signed documents must be extended as > > follows: > > Timestamp Renewal/Inital Renewal: Before a digital signature > (CMS-Object, > > ERS-Object,...) is renewed > > a proof of its validity is performed and the data (called > > RevocationInfoArchival [RIA] and consits of certificates and OCSP > > responses) is stored within the evidence > record. > > For each certificate and > > each ocsp the hash value is computed. These hash values are sorted, > > concated and hashed again. > > This hash value (the hash value for one RIA) is treated as > an ordinary > > signed document within a data object group. > > Hashtree Renewal: First create the RIA for the latest > signature. Then > > compute the hashvalue for each RIA of the evidece record. Sort, > > concate and hash these hashvalues and integrate this > together with the > > hashvalue of the evidence record into the hashtree using the data > > object group procedure. > > Validation: Within the validiation of an evidence record the stored > RIAs > > have to be used for all but > > the latest signature. To ensure their validity it is checked whether > the > > hashvalue appears in the > > first hashlist of the "next" archive time stamp (meeting > the usual ERS > > terms as timeliness, correct hash algortihm, and so on). > > > > I would be glad to hear your opinion about this soultion. > > > > Best Regards > > Hannes Weber > > 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 jB5KS7EX099923; Mon, 5 Dec 2005 12:28:07 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB5KS70s099922; Mon, 5 Dec 2005 12:28:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5KS4I4099904 for ; Mon, 5 Dec 2005 12:28:05 -0800 (PST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id jB5KS27Y007408; Mon, 5 Dec 2005 21:28:03 +0100 (MET) 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: ERS and certificates Date: Mon, 5 Dec 2005 21:28:15 +0100 Message-ID: <3C1BE8610E44734499EF92FB35F5B0700159E69C@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS and certificates Thread-Index: AcX5rJpFFfZIbX1hT5a9Y7GeEM2DOQAKMEHQ X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Hannes Weber" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jB5KS6I4099906 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Hannes, nice to read. I heard of about 3 diploma thesis about this issue in the last 18 months. (one was from IBM, one from FHG, the third I've forgotten, maybe Siemens) Your findings are true. It is necessary to include any verification data (especially the complete certificate path) before the time of the first hashing and timestamping. If it would be added lated it would of course change the hash value. Concerning the certificate path for the timestamps in the ArchiveTimeStamp itself, it should of course be trivial to get them at the time of request. The others should be obtained when the data enters the system and runs through a first verification before archiving (good process design would recommend to verify data before archiving). And before answering: in nearly all commercial applications it can be expected that they are able to (and DO) retrieve the verification data (certificate path and OCSP/CRL) at the time of entry into the system and can add this information as recommended by ISIS-MTT to the signed documents. In case this is not the case, one has to find a solution as you thought of. And your idea of simply extending the model of the EvidenceRecord by simply adding the additional verification data as an additional file represented by a hash value in the normal hashtrees is the right approach. But as you can in this case not know when the information might become available to the system (it might even be AFTER several timestamp and hashtree renewals) the logic connection between the elements (original file, verification data) must be kept by the leading application (in your case the DMS) and not within the ERS! Of course all hash values of all elements can (and SHOULD) end up in one hashtree: So if e.g. you add a document with signatures at let's say Dec 1 2005 and build a first hashtree (with timestamp) without the certificate path. You might add the file containing the certificate path information one day later (Dec 2, 2005) (or five years later) in a second hashtree. At the time of the next occurring renewal (no matter how many occurred in between and no matter be it a timestamp or hashtree renewal) you simply take care that both hashtrees have their highest node be represented by a hash in the same new hashtree. Of course you could also just add the hash value of the verification data right besides the hash value of the ArchiveTimeStamp(Chain) of the original document. In the end for verification you have a bit more work of course than you would have had if you included the verification data before archiving: You have to verify the integrity of both EvidenceRecords (the one for the original file and the second for the file with the additional verification data you e.g. received a day later). Note: as both EvidenceRecords might have come together at some point in time as leaves in a new hashtree you probably can simplify verification procedure due to duplication. After this first step (or in parallel) you verify the signatures in the document with the verification data and only if ALL checks succeed you can assume that the document and its signatures are correct. I strongly recommend to use the EvidenceRecord solely to proof the non-repudiation of the single objects (ignoring any potential further relationship between them) and leaving the link between them to the leading application. (Small personal comment: I discussed this also with my team and all other things will most probably get you in trouble with your implementation. ;-) ) Best regards, and if you like please feel free to call if you have further questions - am always happy to help (and same time zone could make things easier ;-) ). Tobias __________________________________________ Tobias Gondrom 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/ > Hi, > i am a student at the university of Bremen (Germany) and recently wrote my > diploma thesis about > digital signatures in long-term archives. The aim of my work was to > develop > a library capable of > performing the long-term non-repudiation for digital signed documents in > the context of document management systems. > > My solution relies on ERS, but in order to be able to ensure long-term > non-repudiation for any kind > of signatures - that are conform to ISIS-MTT - I extended ERS. This was > necessary because ERS is > not capable of prooving the evidence for digital signatures that do not > include the complete > certificate path. > At the time the evidence record is generated it is not > possible to extend > the renewed signature with the missing certificates of the certificate > path > (the certificates > field of a CMS-object in a signed field) which are necessary for the > non-repudiation proof. > So I integrated the certificates of the certificate path and the OCSP > responses into the evidence > record by exploiting the data object group feature. The renewal of a > signed > documents must be > extended as follows: > Timestamp Renewal/Inital Renewal: Before a digital signature (CMS-Object, > ERS-Object,...) is renewed > a proof of its validity is performed and the data (called > RevocationInfoArchival [RIA] and consits > of certificates and OCSP responses) is stored within the evidence record. > For each certificate and > each ocsp the hash value is computed. These hash values are sorted, > concated and hashed again. > This hash value (the hash value for one RIA) is treated as an ordinary > signed document within a > data object group. > Hashtree Renewal: First create the RIA for the latest signature. Then > compute the hashvalue for each > RIA of the evidece record. Sort, concate and hash these hashvalues and > integrate this together with > the hashvalue of the evidence record into the hashtree using the data > object group procedure. > Validation: Within the validiation of an evidence record the stored RIAs > have to be used for all but > the latest signature. To ensure their validity it is checked whether the > hashvalue appears in the > first hashlist of the "next" archive time stamp (meeting the usual ERS > terms as timeliness, correct > hash algortihm, and so on). > > I would be glad to hear your opinion about this soultion. > > Best Regards > Hannes Weber 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 jB5ErQYp045010; Mon, 5 Dec 2005 06:53: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 jB5ErQg3045009; Mon, 5 Dec 2005 06:53:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB5ErOQS044995 for ; Mon, 5 Dec 2005 06:53:25 -0800 (PST) (envelope-from Hannes.Weber@gmx.de) Received: (qmail invoked by alias); 05 Dec 2005 14:33:12 -0000 Received: from dslb-082-083-235-163.pools.arcor-ip.net (EHLO laptop.gmx.de) [82.83.235.163] by mail.gmx.net (mp030) with SMTP; 05 Dec 2005 15:33:12 +0100 X-Authenticated: #3519241 Message-Id: <5.1.0.14.2.20051205153250.028d59b8@pop.gmx.net> X-Sender: 3519241@pop.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Dec 2005 15:32:57 +0100 To: ietf-ltans@imc.org From: Hannes Weber Subject: ERS and certificates Cc: hannes.Weber@gmx.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Y-GMX-Trusted: 0 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, i am a student at the university of Bremen (Germany) and recently wrote my diploma thesis about digital signatures in long-term archives. The aim of my work was to develop a library capable of performing the long-term non-repudiation for digital signed documents in the context of document management systems. My solution relies on ERS, but in order to be able to ensure long-term non-repudiation for any kind of signatures - that are conform to ISIS-MTT - I extended ERS. This was necessary because ERS is not capable of prooving the evidence for digital signatures that do not include the complete certificate path. At the time the evidence record is generated it is not possible to extend the renewed signature with the missing certificates of the certificate path (the certificates field of a CMS-object in a signed field) which are necessary for the non-repudiation proof. So I integrated the certificates of the certificate path and the OCSP responses into the evidence record by exploiting the data object group feature. The renewal of a signed documents must be extended as follows: Timestamp Renewal/Inital Renewal: Before a digital signature (CMS-Object, ERS-Object,...) is renewed a proof of its validity is performed and the data (called RevocationInfoArchival [RIA] and consits of certificates and OCSP responses) is stored within the evidence record. For each certificate and each ocsp the hash value is computed. These hash values are sorted, concated and hashed again. This hash value (the hash value for one RIA) is treated as an ordinary signed document within a data object group. Hashtree Renewal: First create the RIA for the latest signature. Then compute the hashvalue for each RIA of the evidece record. Sort, concate and hash these hashvalues and integrate this together with the hashvalue of the evidence record into the hashtree using the data object group procedure. Validation: Within the validiation of an evidence record the stored RIAs have to be used for all but the latest signature. To ensure their validity it is checked whether the hashvalue appears in the first hashlist of the "next" archive time stamp (meeting the usual ERS terms as timeliness, correct hash algortihm, and so on). I would be glad to hear your opinion about this soultion. Best Regards Hannes Weber 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 jB518TlU045782; Sun, 4 Dec 2005 17:08:29 -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 jB518Ti8045781; Sun, 4 Dec 2005 17:08:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB518Rg8045772 for ; Sun, 4 Dec 2005 17:08:27 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 89E416CED0; Sun, 4 Dec 2005 17:08:26 -0800 (PST) Reply-To: From: "Jim Schaad" To: , , Cc: Subject: Comments on the draft ltrans-ers-03 Date: Sun, 4 Dec 2005 17:12:46 -0800 Message-ID: <00f601c5f939$00d94be0$1700a8c0@augustcellars.local> 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: AcX5OQARGtR6tjg3TQurYRtCO4bUTg== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gentlemen, Here is a first level review. I have not gone into the document in any depth nor have I actually tried to compile the ASN.1 module. I am not on this mailing list so if you have any questions for me then you need to respond directly to me. Jim Schaad Soaring Hawk Consulting. Section 1.1 "example are" --> "example is" Section 1.3: "An evidence record include" --> "includes" Section 3.2 - consistancy on "hash-tree" "hash tree" "hashtree" Appendix A - "In this case the hash value of the CMS Object as well as the hash value of the content have --> "has" Section 2.1: digestAlgorithms - is this just the OIDs of the algorithm identifiers or does this include all of the parameters as well? Section 2.1: field encryption in EvidenceRecord is not described in order and in the same format. Section 2.1: field encrytion - is this suppose to contain infomration about re-encryption or about decryption of the fields? There is some differences between these. Suggest a hint about where keys are found is included as well in this location. Section 3.1: Are you restricted to a single set of parameters? If you are doing multiple hash operations might one which to allow for different sets of parameters for each of the hash operations? Section 3.2: From my reading of the text, Figure 3 should be (h1), (h2a, h2b, h2c), (h3) as this is the order items are in the tree above. Section 3.2: There not text or reference for how grouping is done. (step 4 - place in groups and sort) Section 3.3: Why search in the first list rather than the entire list of reducedHashtree? It seems to me that it could be anyplace in the list and still be valid. Section 3.3: In step 3 it says that the value must be a member of the next higher list --- WHAT LIST????? The reduction removes these from the list of hash values. It must be taken on faith that it is correct until you reach the root. Section 3.3: How does one re-construct the grouping that was created in the production step? Very non-obious Section 4.1: What does it mean for a ArchiveTimeStampSequence to be ordered by time of timestamp? If I run two parallel ArchiveTimeStampChains with different hash functions and sign both at the approx the same time -- which comes first? Ordered by the first entry or the last entry on the chain? There is no reason to assume that all of the entries in the second chain occur after all of the entiries in the first chain. Section 4.2: It states that the hash algorithms must be the same -- how about the hash algorithm parameters? Section 4.2, 4.3: I have serveral issues with the algorithm that you are using to replace a hash functions. They are: 1) I believe that atsc(i) should be a constant for all documents. A document should never be deleted and then re-added, nor is a document added during the process of renewing a timestamp. Thus either the document has been deleted (in which case it is not re-hashed) or it is in every ArchiveTimeStampSequence. Ergo - atsc(i) is constant for all values of i. 2) Verification requires that an implemenation of all previous hash algorithms be kept is that what one wants to do? (I.e. do you want to be able to have a "fast" proof using just the current data). 3) What happens if only one item is left in a document group (i.e the rest have been deleted)? Is it treated as a document group of one or as a single document? Section 5.1: The proper term is detached content rather than external content. Suggest "encryptionCover is a CMS content type of EnvelopedData where the encryptedContent field is absent" Section 5.1: Putting the private key into a BIT STRING is problematic. I would suggest either an OCTET STRING or an ANY DEFINED BY with the OID as well. Section 5.1: I don't understand the set of parameters that you have defined for re-encryption of the structure. I would thing that the only thing that you need is the ContentEncryptionKey in the clear - The rest of the parameters are kept in the encryptionCover field. You don't need to the public key or the KeyEncryptionKey fields unless you are intending to re-build the EncryptionCover field. Section 5.1: If you are using the EncryptedData field you need to make some additional statements that are not required in CMS. 1) The ContentInfo field to be submitted MUST be DER encoded. 2) The encrypted content MUST be connonicalized PRIOR to being encrypted. (i.e. ASN.1 is DER encoded, MIME uses S/MIME rules and so forth) 3) The EncryptedData RecipientInfos MUST ALL be kept intact unless the EncryptedData field was not archived. Section 6: Use the correct module for CMS -- CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } Section 6: Add a reference comment to each of the IMPORT-ed modules -- From [RFCXXXX] so that they can be easily found Section 6: ASN Errors id-EncryptionCMS_encryptedmessage ::= {id-ATS-1} -- id-ATS-1 not defined EncryptionKeyRandom::= SEQUENCE { encryptionKey OCTET STRING, randomValue BIT STRING}} -- illegal token } Comment: Useful to have the list name in the document so I know where to send mail to. ---- need guidence on what happens if a key is revoked -- need to have a second signature added before hand?