Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VMo4g1098866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 15:50:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4VMo4xP098865; Thu, 31 May 2007 15:50:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VMo3A1098851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 May 2007 15:50:04 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 27F6C26EC2; Thu, 31 May 2007 22:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HttT0-0003Fu-9n; Thu, 31 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-14.txt Message-Id: Date: Thu, 31 May 2007 18:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-14.txt Pages : 33 Date : 2007-5-31 In many scenarios, users must be able prove the existence and integrity of data, including 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, a structure designed to support long-term non- repudiation of existence of data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-14.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-14.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-14.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: <2007-5-31162529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-31162529.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VIrkOJ045287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 11:53:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4VIrkds045286; Thu, 31 May 2007 11:53:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VIrg38045269 for ; Thu, 31 May 2007 11:53:43 -0700 (MST) (envelope-from jpbedell@mises.com) Received: by nz-out-0506.google.com with SMTP id z31so254065nzd for ; Thu, 31 May 2007 11:53:38 -0700 (PDT) Received: by 10.114.149.2 with SMTP id w2mr965930wad.1180637617569; Thu, 31 May 2007 11:53:37 -0700 (PDT) Received: by 10.114.127.6 with HTTP; Thu, 31 May 2007 11:53:37 -0700 (PDT) Message-ID: <24ee1de20705311153o396419c3ta3a4c82d7b43ebe3@mail.gmail.com> Date: Thu, 31 May 2007 11:53:37 -0700 From: "J. Patrick Bedell" To: "Tobias Gondrom" , ietf-ltans@imc.org Subject: Re: first steps toward LTAP implementation available at https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868010A9E89@MUCXGC2.opentext.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24ee1de20705291449v15475622iec0ff55f9d7cee36@mail.gmail.com> <2666EB2A846BAC4BB2D7F593301A7868010A9E89@MUCXGC2.opentext.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I hope that it will be easier to understand the needs for the LTANS/LTAP specs with open source implementations, so feel free to provide criticisms of (and patches for!) the code. I'm trying to develop financial instruments to better quantify the economic value of information, so that the creation of information valuable to others can be efficiently valued as an economic good. With regard to the notes in ltans-impl-notes.txt, I was listening to the talks about enterprise risk management at http://www.ermsymposium.com/handouts.php and wanted to write some notes to myself about how long-term archival systems can help enterprises manage risks through economic information analysis. Thanks for the feedback! Patrick jpbedell@mises.com On 5/31/07, Tobias Gondrom wrote: > Hello Patrick, > > wow, that was fast. > Just a small comment: LTAP is still in progress and we will probably > need another 6 weeks to get it finalized. > > I'll try to take a look at the src on the weekend (focussing on the ERS > stuff). Maybe Peter and Carl as the authors of the LTAP draft could also > take a look at it? > > Tobias > > > Ps.: sorry for asking a dumb question, but I am a bit confused about the > "marketing and business" comments from date 2007-05-24 - 2007-05-29 in > the ltans-imp-notes.txt. What do you mean with them? > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of J. Patrick Bedell > > Sent: Tuesday, May 29, 2007 11:50 PM > > To: ietf-ltans@imc.org > > Subject: first steps toward LTAP implementation available at > > https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans > > > > > > Hello, > > I'm writing to let the list know that the code that I've been > > writing to implement LTAP in Apache OFBiz is downloadable from the > > sf.net SVN, and to invite anyone who is interested to contribute code > > or ideas. The code can be obtained with > > "svn co https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans ltans" > . > > Thanks in advance for your feedback! > > > > J. Patrick Bedell > > jpbedell@mises.com > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VHK4VN029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 10:20:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4VHK4IK029596; Thu, 31 May 2007 10:20:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4VHK2Hr029583 for ; Thu, 31 May 2007 10:20:03 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l4VHJxlk012713; Thu, 31 May 2007 19:20:00 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: first steps toward LTAP implementation available at https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans Date: Thu, 31 May 2007 19:19:59 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868010A9E89@MUCXGC2.opentext.net> In-Reply-To: <24ee1de20705291449v15475622iec0ff55f9d7cee36@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: first steps toward LTAP implementation available at https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans Thread-Index: AceiPVAGvXa8BXbmQuSSg88Bp3zgngBaHfdg X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "J. Patrick Bedell" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l4VHK3Hr029591 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Patrick, wow, that was fast. Just a small comment: LTAP is still in progress and we will probably need another 6 weeks to get it finalized. I'll try to take a look at the src on the weekend (focussing on the ERS stuff). Maybe Peter and Carl as the authors of the LTAP draft could also take a look at it? Tobias Ps.: sorry for asking a dumb question, but I am a bit confused about the "marketing and business" comments from date 2007-05-24 - 2007-05-29 in the ltans-imp-notes.txt. What do you mean with them? > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of J. Patrick Bedell > Sent: Tuesday, May 29, 2007 11:50 PM > To: ietf-ltans@imc.org > Subject: first steps toward LTAP implementation available at > https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans > > > Hello, > I'm writing to let the list know that the code that I've been > writing to implement LTAP in Apache OFBiz is downloadable from the > sf.net SVN, and to invite anyone who is interested to contribute code > or ideas. The code can be obtained with > "svn co https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans ltans" . > Thanks in advance for your feedback! > > J. Patrick Bedell > jpbedell@mises.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4TLnebK063356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2007 14:49:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4TLneeG063354; Tue, 29 May 2007 14:49:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4TLncCe063347 for ; Tue, 29 May 2007 14:49:40 -0700 (MST) (envelope-from jpbedell@mises.com) Received: by wa-out-1112.google.com with SMTP id k22so840630waf for ; Tue, 29 May 2007 14:49:38 -0700 (PDT) Received: by 10.114.174.2 with SMTP id w2mr3605319wae.1180475378555; Tue, 29 May 2007 14:49:38 -0700 (PDT) Received: by 10.114.127.6 with HTTP; Tue, 29 May 2007 14:49:38 -0700 (PDT) Message-ID: <24ee1de20705291449v15475622iec0ff55f9d7cee36@mail.gmail.com> Date: Tue, 29 May 2007 14:49:38 -0700 From: "J. Patrick Bedell" To: ietf-ltans@imc.org Subject: first steps toward LTAP implementation available at https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'm writing to let the list know that the code that I've been writing to implement LTAP in Apache OFBiz is downloadable from the sf.net SVN, and to invite anyone who is interested to contribute code or ideas. The code can be obtained with "svn co https://svn.sourceforge.net/svnroot/infoeng/trunk/ltans ltans" . Thanks in advance for your feedback! J. Patrick Bedell jpbedell@mises.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4R7KFB8013368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 May 2007 00:20:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4R7KF2k013366; Sun, 27 May 2007 00:20:15 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4R7KEkg013339 for ; Sun, 27 May 2007 00:20:15 -0700 (MST) (envelope-from jpbedell@mises.com) Received: by wa-out-1112.google.com with SMTP id k22so434471waf for ; Sun, 27 May 2007 00:20:14 -0700 (PDT) Received: by 10.114.73.1 with SMTP id v1mr2325086waa.1180250413994; Sun, 27 May 2007 00:20:13 -0700 (PDT) Received: by 10.114.127.6 with HTTP; Sun, 27 May 2007 00:20:13 -0700 (PDT) Message-ID: <24ee1de20705270020u228c4206q27ffcbf588057ea9@mail.gmail.com> Date: Sun, 27 May 2007 00:20:13 -0700 From: "J. Patrick Bedell" To: ietf-ltans@imc.org Subject: asn.1 module for archive fiduciary media - request for feedback MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_178604_6585336.1180250413954" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_178604_6585336.1180250413954 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm implementing an open-source module for Apache OFBiz to issue "archive fiduciary media" based on digital resources (associated with public keys) in a long-term archival system. I've attached the first version of an ASN.1 module for AFM to this email. I'd welcome your comments! Thanks! J. Patrick Bedell jpbedell@mises.com ------=_Part_178604_6585336.1180250413954 Content-Type: application/octet-stream; name=afm-0.0.1.asn Content-Transfer-Encoding: base64 X-Attachment-Id: f_f276i66s Content-Disposition: attachment; filename="afm-0.0.1.asn" ICAgCiAgIC0tICAgIEFGTSB7aXNvKDEpIGlkZW50aWZpZWQtb3JnYW5pemF0aW9uKDMpIGRvZCg2 KQogICAtLSAgICAgICAgIGludGVybmV0KDEpIHNlY3VyaXR5KDUpIG1lY2hhbmlzbXMoNSkKICAg LS0gICAgICAgICBsdGFucygxMSkgaWQtbW9kKDApIGlkLW1vZC1hZm0oMikgaWQtbW9kLWFmbS12 MSgxKSB9CiAgIERFRklOSVRJT05TIElNUExJQ0lUIFRBR1MgOjo9CiAgIEJFR0lOCiAgIAogICAt LSBFWFBPUlRTIEFMTCAtLQogICBJTVBPUlRTCiAgICAgIEFsZ29yaXRobUlkZW50aWZpZXIsIEdl bmVyYWxOYW1lcwogICAgICBGUk9NIEF1dGhlbnRpY2F0aW9uRnJhbWV3b3JrCiAgICAgICAge2pv aW50LWlzby1pdHUtdCBkcyg1KSBtb2R1bGUoMSkKICAgICAgICAgICAgICBhdXRoZW50aWNhdGlv bkZyYW1ld29yayg3KSA0fQoKICAgICAgUG9saWN5SW5mb3JtYXRpb24KICAgICAgRlJPTSBDZXJ0 aWZpY2F0ZUV4dGVuc2lvbnMKICAgICAgICB7am9pbnQtaXNvLWl0dS10IGRzKDUpIG1vZHVsZSgx KQogICAgICAgICAgICAgIGNlcnRpZmljYXRlRXh0ZW5zaW9ucygyNikgNH0KCSAgICAgIAogICAg ICBSZXF1ZXN0IAogICAgICBGUk9NIExUQVAgCiAgICAgICAge2lzbygxKSBpZGVudGlmaWVkLW9y Z2FuaXphdGlvbigzKSBkb2QoNikKICAgICAgICAgaW50ZXJuZXQoMSkgc2VjdXJpdHkoNSkgbWVj aGFuaXNtcyg1KQogICAgICAgICBsdGFucygxMSkgbW9kdWxlKDEpIGx0YXAoMykgMH0KICAgICAg OwogICAgCiAgICBMVEFQUmVxdWVzdEluZm9ybWF0aW9uIDo6PSBTRVFVRU5DRSB7IAogICAgICAg IHZlcnNpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZlcnNpb24sICAt LSBjdXJyZW50IHZlcnNpb24gaXMgMAoJbHRhcFJlcXVlc3QgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUmVxdWVzdCwgLS0gZHJhZnQtaWV0Zi1sdGFucy1sdGFwLTA0LnR4dAogICAg ICAgIGx0YXBPYmplY3ROYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5hbWUgT1BU SU9OQUwsCglsdGFwT2JqZWN0UHVibGljS2V5SW5mbyAgICAgCSAgICAgICAgICAgICBTdWJqZWN0 UHVibGljS2V5SW5mbyBPUFRJT05BTCwKICAgICAgICBleHRlbnNpb25zICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFswXSBFeHRlbnNpb25zIE9QVElPTkFMLAoJbHRhcFNpZ25hdHVyZUFs Z29yaXRobSAgICAgICAgICAgICAgICAgICAgICAgQWxnb3JpdGhtSWRlbnRpZmllciBPUFRJT05B TCwKCWx0YXBTaWduYXR1cmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJJVCBTVFJJ TkcgT1BUSU9OQUwKICAgIH0KICAgIAogICAgQXJjaGl2ZUZpZHVjaWFyeU1lZGlhUmVxdWVzdCA6 Oj0gU0VRVUVOQ0UgeyAKICAgICAgIHZlcnNpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAg VmVyc2lvbiwKICAgICAgIHN1YmplY3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSwK ICAgICAgIHN1YmplY3RQdWJsaWNLZXlJbmZvICAgICAgICAgICAgICAgU3ViamVjdFB1YmxpY0tl eUluZm8sCiAgICAgICBsdGFwUmVxdWVzdEluZm9ybWF0aW9uICAgICAgICAgICAgIExUQVBSZXF1 ZXN0SW5mb3JtYXRpb24sCiAgICAgICBzaWduYXR1cmVBbGdvcml0aG0gICAgICAgICAgICAgICAg IEFsZ29yaXRobUlkZW50aWZpZXIsCiAgICAgICBzaWduYXR1cmVWYWx1ZSAgICAgICAgICAgICAg ICAgICAgIEJJVCBTVFJJTkcKICAgIH0KICAgIAogICAgLS0gRW52ZWxvcGVkIGluZm9ybWF0aW9u IHBvcnRpb24KICAgIEFyY2hpdmVGaWR1Y2lhcnlNZWRpYVJlcXVlc3RFbnZlbG9wZSA6Oj0gU0VR VUVOQ0UgewogICAgICB2ZXJzaW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWZXJzaW9u LAogICAgICByZWNpcGllbnRJbmZvIHsKICAgICAgICAgIHZlcnNpb24gICAgICAgICAgICAgICAg ICAgICAgICAgVmVyc2lvbiwKICAgICAgICAgIGlzc3VlckFuZFNlcmlhbE51bWJlciB7CiAgICAg ICAgICAgICAgaXNzdWVyICAgICAgICAgICAgICAgICAgICAgIE5hbWUsCiAgICAgICAgICAgICAg c2VyaWFsTnVtYmVyICAgICAgICAgICAgICAgIENlcnRpZmljYXRlU2VyaWFsTnVtYmVyCiAgICAg ICAgICB9CiAgICAgICAgICBrZXlFbmNyeXB0aW9uQWxnb3JpdGhtICAgICAgICAgIEFsZ29yaXRo bUlkZW50aWZpZXIsCiAgICAgICAgICBlbmNyeXB0ZWRLZXkgICAgICAgICAgICAgICAgICAgIEJJ VCBTVFJJTkcgCiAgICAgIH0KICAgICAgZW5jcnlwdGVkQ29udGVudEluZm8gewogICAgICAgICAg Y29udGVudFR5cGUgICAgICAgICAgICAgICAgICAgICBBbGdvcml0aG1JZGVudGlmaWVyLCAgCiAg ICAgICAgICBjb250ZW50RW5jcnlwdGlvbkFsZ29yaXRobSAgICAgIE9CSkVDVCBJREVOVElGSUVS LCAKICAgICAgICAgIGVuY3J5cHRlZENvbnRlbnQgICAgICAgICAgICAgICAgQklUIFNUUklORyAK ICAgICAgfQogICAgfQogICAgCiAgICBBcmNoaXZlRmlkdWNpYXJ5TWVkaWFSZXF1ZXN0U2lnbmVk RW52ZWxvcGUgOjo9IFNFUVVFTkNFIHsKICAgICAgdmVyc2lvbiBWZXJzaW9uLAogICAgICBkaWdl c3RBbGdvcml0aG0gT0JKRUNUIElERU5USUZJRVIsIAogICAgICBjb250ZW50SW5mbyB7CiAgICAg ICAgICBjb250ZW50VHlwZSB7cGtjcy03IDF9LAogICAgICAgICAgY29udGVudCAgQXJjaGl2ZUZp ZHVjaWFyeU1lZGlhUmVxdWVzdEVudmVsb3BlCiAgICAgIH0KICAgICAgY2VydGlmaWNhdGUgeyAg IAogICAgICAgICAgdmVyc2lvbiAgICAgICAgICAgICAgICAgICAgICAgIFZlcnNpb24sCiAgICAg ICAgICBzZXJpYWxOdW1iZXIgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVTZXJpYWxOdW1i ZXIsCiAgICAgICAgICBzaWduYXR1cmUgICAgICAgICAgICAgICAgICAgICAgT0JKRUNUIElERU5U SUZJRVIsIAoJICBpc3N1ZXIgICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSwgCiAgICAgICAg ICB2YWxpZGl0eSB7CiAgICAgICAgICAgICAgbm90QmVmb3JlICAgICAgICAgICAgICAgICAgR2Vu ZXJhbGl6ZWRUaW1lLAogICAgICAgICAgICAgIG5vdEFmdGVyICAgICAgICAgICAgICAgICAgIEdl bmVyYWxpemVkVGltZSAKICAgICAgICAgIH0KICAgICAgICAgIHN1YmplY3QgICAgICAgICAgICAg ICAgICAgICAgICBOYW1lLCAKICAgICAgICAgIHN1YmplY3RQdWJsaWNLZXlJbmZvIHsKICAgICAg ICAgICAgICBhbGdvcml0aG0gICAgICAgICAgICAgICAgICB7cGtjcy0xIDF9LAogICAgICAgICAg ICAgIHN1YmplY3RQdWJsaWNLZXkgICAgICAgICAgIE9DVEVUIFNUUklORwogICAgICAgICAgfQog ICAgICAgICAgc2lnbmF0dXJlQWxnb3JpdGhtICAgICAgICAgICAgIE9CSkVDVCBJREVOVElGSUVS LAoJICBzaWduYXR1cmUgICAgICAgICAgICAgICAgICAgICAgQklUIFNUUklORyAtLSAgInRoZSBz aWduYXR1cmUgZ2VuZXJhdGVkIGJ5IHVzaW5nIHRoZSByZXF1ZXN0ZXIncwoJICAgICAtLSBwcml2 YXRlIGtleSBjb3JyZXNwb25kaW5nIHRvIHRoZSBwdWJsaWMga2V5IGluCgkgICAgIC0tIHRoZSBh Zm1SZXEuc3ViamVjdFB1YmxpY0tleUluZm8uIgogICAgICB9CiAgICAgIHNpZ25lckluZm8gIHsK ICAgICAgICAgIHZlcnNpb24gVmVyc2lvbiwKICAgICAgICAgIGlzc3VlckFuZFNlcmlhbE51bWJl ciB7CiAgICAgICAgICAgICAgaXNzdWVyIE5hbWUsIC0tICJ0aGUgcmVxdWVzdGVyJ3Mgc3ViamVj dCBuYW1lIgogICAgICAgICAgICAgIHNlcmlhbE51bWJlciBDZXJ0aWZpY2F0ZVNlcmlhbE51bWJl ciAtLSAidGhlIHRyYW5zYWN0aW9uIGlkIGFzc29jaWF0ZWQKCSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSB3aXRoIHRoZSBlbnJvbGxtZW50IgogICAgICAgICAg fQogICAgICAgICAgZGlnZXN0QWxnb3JpdGhtIE9CSkVDVCBJREVOVElGSUVSLCAtLSB7aXNvKDAp IG1lbWJlci1ib2R5KDIpIFVTKDg0MCkgcnNhZHNpKDExMzU0OSkgZGlnZXN0QWxnb3JpdGhtKDIp IDV9CiAgICAgICAgICBhdXRoZW50aWNhdGVBdHRyaWJ1dGVzIHsKICAgICAgICAgICAgICBjb250 ZW50VHlwZSAge3twa2NzLTkgM30ge3BrY3MtNyAxfX0sCiAgICAgICAgICAgICAgbWVzc2FnZURp Z2VzdCB7e3BrY3MtOSA0fSBPQ1RFVCBTVFJJTkd9LAogICAgICAgICAgICAgIHRyYW5zYWN0aW9u LWlkIHt7aWQtYXR0cmlidXRlcyB0cmFuc0lkKDcpfSBQcmludGFibGVTdHJpbmd9LAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIHRoaXMgdHJhbnNhY3Rpb24gaWQgd2lsbCBiZSB1c2Vk CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gdG9nZXRoZXIgd2l0aCB0aGUgc3ViamVj dCBuYW1lIGFzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gdGhlIGlkZW50aWZpZXIg b2YgdGhlIHJlcXVlc3RlcidzIGtleQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIHBh aXIgZHVyaW5nIGVucm9sbG1lbnQKICAgICAgICAgICAgICBtZXNzYWdlVHlwZSB7e2lkLWF0dHJp YnV0ZXMgbWVzc2FnZVR5cGUoMil9IE9DVEVUIFNUUklOR30sIC0tICJBRk1SZXF1ZXN0IgogICAg ICAgICAgICAgIHNlbmRlck5vbmNlIHt7aWQtYXR0cmlidXRlcyBzZW5kZXJOb25jZSg1KX0gT0NU RVQgU1RSSU5HfSAtLSAiYSByYW5kb20gbnVtYmVyIGVuY29kZWQgYXMgYSBzdHJpbmciCiAgICAg ICAgICB9CiAgICAgICAgICBkaWdlc3RFbmNyeXB0aW9uQWxnb3JpdGhtIE9CSkVDVCBJREVOVElG SUVSLCAtLSB7cGtjcy0xIDF9IHJzYSBlbmNyeXB0aW9uCiAgICAgICAgICBlbmNyeXB0ZWREaWdl c3QgT0NURVQgU1RSSU5HIC0tICJlbmNyeXB0ZWQgZGlnZXN0IG9mIHRoZSBhdXRoZW50aWNhdGVk IGF0dHJpYnV0ZXMgdXNpbmcgcmVxdWVzdGVyJ3MgcHJpdmF0ZSBrZXkiCiAgICAgICB9CiAgICB9 CgogICAgQXJjaGl2ZUZpZHVjaWFyeU1lZGlhUmVxdWVzdFNpZ25lZEVudmVsb3BlZENvbnRlbnRJ bmZvIDo6PSBTRVFVRU5DRSB7IAogICAgICAgY29udGVudFR5cGUge3BrY3MtNyAyfSwKICAgICAg IGNvbnRlbnQgQXJjaGl2ZUZpZHVjaWFyeU1lZGlhUmVxdWVzdFNpZ25lZEVudmVsb3BlCiAgICB9 CiAgICAKICAgIEFyY2hpdmVGaWR1Y2lhcnlNZWRpYVVuaXRUZW1wbGF0ZSAgOjo9ICBTRVFVRU5D RSAgewogICAgICAgIHZlcnNpb24gICAgICAgICBbMF0gIEVYUExJQ0lUIFZlcnNpb24gREVGQVVM VCB2MSwKICAgICAgICBzZXJpYWxOdW1iZXIgICAgICAgICBDZXJ0aWZpY2F0ZVNlcmlhbE51bWJl ciwKICAgICAgICBzaWduYXR1cmUgICAgICAgICAgICBBbGdvcml0aG1JZGVudGlmaWVyLAogICAg ICAgIGlzc3VlciAgICAgICAgICAgICAgIE5hbWUsCiAgICAgICAgdmFsaWRpdHkgICAgICAgICAg ICAgVmFsaWRpdHksCiAgICAgICAgc3ViamVjdCAgICAgICAgICAgICAgTmFtZSwKICAgICAgICBz dWJqZWN0UHVibGljS2V5SW5mbyBTdWJqZWN0UHVibGljS2V5SW5mbywKICAgICAgICBpc3N1ZXJV bmlxdWVJRCAgWzFdICBJTVBMSUNJVCBVbmlxdWVJZGVudGlmaWVyIE9QVElPTkFMLAoJc3ViamVj dFVuaXF1ZUlEIFsyXSAgSU1QTElDSVQgVW5pcXVlSWRlbnRpZmllciBPUFRJT05BTCwKICAgICAg ICBleHRlbnNpb25zICAgICAgWzNdICBFWFBMSUNJVCBFeHRlbnNpb25zIE9QVElPTkFMICAgCiAg ICB9CgogICAgQXJjaGl2ZUZpZHVjaWFyeU1lZGlhVW5pdCA6Oj0gIFNFUVVFTkNFICB7CiAgICAg ICAgYWZtVW5pdFRlbXBsYXRlICAgICAgICAgICAgICAgIEFyY2hpdmVGaWR1Y2lhcnlNZWRpYVVu aXRUZW1wbGF0ZSwKICAgICAgICBzaWduYXR1cmVBbGdvcml0aG0gICAgICAgICAgICAgQWxnb3Jp dGhtSWRlbnRpZmllciwKICAgICAgICBzaWduYXR1cmVWYWx1ZSAgICAgICAgICAgICAgICAgQklU IFNUUklORywKCWlzc3VlclRyZWVTaWduYXR1cmVBbGdvcml0aG0gICBBbGdvcml0aG1JZGVudGlm aWVyLAoJaXNzdWVyVHJlZVNpZ25hdHVyZSAgICAgICAgICAgIEJJVCBTVFJJTkcKICAgIH0KICAg CiAgICBBcmNoaXZlRmlkdWNpYXJ5TWVkaWFTZXQgOjo9IFNFUVVFTkNFIHsgCiAgICAgICAgYWZt VW5pdHMgICAgICAgICAgICAgICAgICAgICAgIFNFUVVFTkNFIE9GIEFyY2hpdmVGaWR1Y2lhcnlN ZWRpYVVuaXQsIC0tIAogICAgICAgIHNlcmllc0NlcnRpZmljYXRlICAgICAgICAgICAgICBTRVQg T0YgQ2VydGlmaWNhdGUsIC0tIGNlcnRpZmljYXRlIAoJc2lnbmF0dXJlQWxnb3JpdGhtICAgICAg ICAgICAgIEFsZ29yaXRobUlkZW50aWZpZXIsIC0tIAoJc2lnbmF0dXJlICAgICAgICAgICAgICAg ICAgICAgIEJJVCBTVFJJTkcgLS0gCiAgICB9CiAgICAKICAgIEFyY2hpdmVGaWR1Y2lhcnlNZWRp YVJlc3BvbnNlIDo6PSBDSE9JQ0UgeyAKICAgICAgICBvcGVyYXRpb25SZXNwb25zZSAgICAgQXJj aGl2ZUZpZHVjaWFyeU1lZGlhT3BlcmF0aW9uUmVzcG9uc2UsCgllcnJvck5vdGljZSAgICAgICBb MF0gU3RhdHVzTm90aWNlIAogICAgfQogICAgCiAgICBBcmNoaXZlRmlkdWNpYXJ5TWVkaWFPcGVy YXRpb25SZXNwb25zZSA6Oj0gU0VRVUVOQ0UgeyAKICAgICAtLSBzaWduZWQgZGF0YSBvbmx5IGZv ciAKICAgICAgIGx0YXBSZXNwb25zZSAgICAgICAgICAgICAgICAgICAgUmVzcG9uc2UsCiAgICAg ICBhZm1TdGF0dXNOb3RpY2UgICAgICAgICAgICAgICAgIFN0YXR1c05vdGljZSwKICAgICAgIGFm bVJlc3BvbnNlU2V0ICAgICAgICAgICAgICAgICAgU0VUIE9GIEFyY2hpdmVGaWR1Y2lhcnlNZWRp YVNldCwKICAgICAgIGFmbVJlc3BvbnNlQ2VydGlmaWNhdGUgICAgICAgICAgU0VUIE9GIENlcnRp ZmljYXRlLCAtLSBjZXJ0aWZpY2F0ZSBkZXNjcmliaW5nIHJlc3VsdHMgb2Ygb3BlcmF0aW9uLCBp ZiBzdWNjZXNzZnVsIAogICAgICAgcmVzcG9uc2VTaWduYXR1cmVBbGdvcml0aG0gICAgICBBbGdv cml0aG1JZGVudGlmaWVyLAogICAgICAgcmVzcG9uc2VTaWduYXR1cmUgICAgICAgICAgICAgICBP Q1RFVCBTVFJJTkcKICAgIH0KICAgIAogIAo= ------=_Part_178604_6585336.1180250413954-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4AAYMWt040235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2007 03:34:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4AAYMuG040233; Thu, 10 May 2007 03:34:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4AAY06D040152 for ; Thu, 10 May 2007 03:34:21 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l4AAXvo0014403; Thu, 10 May 2007 12:33:58 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: open source implementation of LTANS? Date: Thu, 10 May 2007 12:33:56 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868F2A3AB@MUCXGC2.opentext.net> In-Reply-To: <24ee1de20705091924m681a20feyefac834cf948ff5b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open source implementation of LTANS? Thread-Index: AceSq98JvU9gZjJCTDuyBBcAOWcJBAAQQLmw From: "Tobias Gondrom" To: "J. Patrick Bedell" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l4AAYL6D040228 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Patrick, AFAIK there exist only several commercial (closed source) implementations of LTANS ERS. So an open source implementation would be great and very welcome. If you like to run compatibility tests with existing implementations, feel free to send emails to this list. There are at least an implementation from Fraunhofer and one from Open text who would be willing to help and do some cross testing. If I can help with any additional explanations of ERS or LTANS parts to support your project of the open source implementation please don't hesitate and send an email to this list or me directly or just give me a call. Tobias Ps.: I also read your draft-jpbedell-information-currency-trading-00 and found it an interesting idea. Though I am not sure the established trading centers will be willing to use it. __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of J. Patrick Bedell > Sent: Thursday, May 10, 2007 4:24 AM > To: ietf-ltans@imc.org > Subject: open source implementation of LTANS? > > > Hi, > Thanks for your work on the LTANS specifications! I'm working to > implement LTANS as an OFBIZ component, to be released at > http://sourceforge.net/projects/infoeng , hopefully before too much > longer. ;) FWIW, I've been releasing software to create what I've > called "information currency" from submitted information, with the > latest release of an open source server > http://prdownloads.sf.net/infoeng/icws-0.2.3.tar.gz , implementing the > draft specification at > http://infoeng.sf.net/information-currency-rfc.txt . > Has there been an open-source implementation of the LTANS draft > specifications at this time? > > J. Patrick Bedell > jpbedell@mises.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4A2OXZc006434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 19:24:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4A2OX6F006433; Wed, 9 May 2007 19:24:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4A2OWK2006427 for ; Wed, 9 May 2007 19:24:33 -0700 (MST) (envelope-from jpbedell@mises.com) Received: by wr-out-0506.google.com with SMTP id 50so414581wri for ; Wed, 09 May 2007 19:24:30 -0700 (PDT) Received: by 10.114.124.1 with SMTP id w1mr312726wac.1178763869188; Wed, 09 May 2007 19:24:29 -0700 (PDT) Received: by 10.114.127.6 with HTTP; Wed, 9 May 2007 19:24:29 -0700 (PDT) Message-ID: <24ee1de20705091924m681a20feyefac834cf948ff5b@mail.gmail.com> Date: Wed, 9 May 2007 19:24:29 -0700 From: "J. Patrick Bedell" To: ietf-ltans@imc.org Subject: open source implementation of LTANS? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Thanks for your work on the LTANS specifications! I'm working to implement LTANS as an OFBIZ component, to be released at http://sourceforge.net/projects/infoeng , hopefully before too much longer. ;) FWIW, I've been releasing software to create what I've called "information currency" from submitted information, with the latest release of an open source server http://prdownloads.sf.net/infoeng/icws-0.2.3.tar.gz , implementing the draft specification at http://infoeng.sf.net/information-currency-rfc.txt . Has there been an open-source implementation of the LTANS draft specifications at this time? J. Patrick Bedell jpbedell@mises.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l49JoNL7085421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 12:50:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l49JoNdR085420; Wed, 9 May 2007 12:50:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l49Jo2Nd085307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 9 May 2007 12:50:23 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5C06A175FE; Wed, 9 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlsAk-0002HX-40; Wed, 09 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-13.txt Message-Id: Date: Wed, 09 May 2007 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-13.txt Pages : 34 Date : 2007-5-9 In many scenarios, users must be able prove the existence and integrity of data, including 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, a structure designed to support long-term non- repudiation of existence of data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-13.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-13.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-13.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: <2007-5-9131952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-9131952.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l44Gsk0D078929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2007 09:54:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l44GsktW078928; Fri, 4 May 2007 09:54:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l44GsORW078863 for ; Fri, 4 May 2007 09:54:45 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l44GsJlk023453; Fri, 4 May 2007 18:54:20 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: LTANS: clean-up of ltans oid structure - final revision of OID Registry Date: Fri, 4 May 2007 18:54:18 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0124_01C78E7D.9E703B40" Message-ID: <2666EB2A846BAC4BB2D7F593301A7868F29D10@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868E389D0@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: clean-up of ltans oid structure - final revision of OID Registry Thread-Index: AceLMgHiP1bGNZ8gRneeQr1eBR8HzgBmgm4AAGc/0dA= From: "Tobias Gondrom" To: Cc: "Carl Wallace" , "Peter Sylvester" 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_0124_01C78E7D.9E703B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, based on the discussion here on the list and some tough discussions, = Peter and I came to a good compromise better aligned with how the other WG OID registries handle their OIDs (e.g. PKIX and SMIME)=20 This lead to the following solution with a rather flat structure (very similar to the ones of the other working groups). Please read it and provide feedback until May-08.=20 After that date we should post the OIDs to our LTANS-OID-registry.=20 Comment: The following design ideas have been followed with the list = below: 1. other WGs have one arc for all modules (not two, one for the current = and one for 88-modules) - and the modules arc is directly under the root and = not below other semantic sub-groups (like it would have been with ers and = ltap in my initial proposal)=20 2. common semantics of the OID tree is to split into modules, algorithms = and other types of identifiers. (so the methods is an arc parallel to the modules) 3. the syntax of the alias names on the left side (e.g. id-mod-ltap) = also follows the common way of the other WGs.=20 (The only thing we do in extend to common usages, is to add versions = below the module arc (which is for the sake of later extensibility or = modification (when we may add further versions to the arc) a good thing).) Best regards, Tobias -- LTANS Object Identifier Registry ltans OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3)=20 dod(6) internet(1) security(5) mechanisms(5) ltans(11) } -- LTANS Arcs id-mod OBJECT IDENTIFIER ::=3D { ltans 0 } -- modules id-meth OBJECT IDENTIFIER ::=3D { ltans 1 } -- methods -- LTANS Modules id-mod-ers88 OBJECT IDENTIFIER ::=3D { id-mod 1 } - Modules in 1988 = Syntax id-mod-ers OBJECT IDENTIFIER ::=3D { id-mod 2 } =20 id-mod-ltap88 OBJECT IDENTIFIER ::=3D { id-mod 3 } - Modules in 1988 = Syntax =20 id-mod-ltap OBJECT IDENTIFIER ::=3D { id-mod 4 } =20 -- ERS Module 88 Version id-mod-ers88-v1 OBJECT IDENTIFIER ::=3D { id-mod-ers88 1 } - Version = number for RFC -- ERS Module Version id-mod-ers-v1 OBJECT IDENTIFIER ::=3D { id-mod-ers 1 } - Version = number for RFC -- LTAP Module 88 Version id-mod-ltap88-v1 OBJECT IDENTIFIER ::=3D { id-mod-ltap88 1 } - Version = number for RFC -- LTAP Module Version id-mod-ltap-v1 OBJECT IDENTIFIER ::=3D { id-mod-ltap 1 } - Version = number for RFC=20 -- LTANS Methods id-meth-er-internal OBJECT IDENTIFIER ::=3D { id-meth 1 } id-meth-er-external OBJECT IDENTIFIER ::=3D { id-meth 2 } __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John Shackleton This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, = displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for = which it was sent by OTC. All other rights and licenses to this email are = fully reserved to OTC. If you are not an Authorized Recipient, you are = required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. = The transmission of this email by OTC is not to be construed as a waiver by = OTC and/or the individual sending this email on behalf of OTC of any of = their respective rights or privileges at law or otherwise, howsoever arising. ------=_NextPart_000_0124_01C78E7D.9E703B40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA1MDQxNjU0MThaMCMGCSqGSIb3DQEJBDEWBBQbALmJ5/7hjxV8ZFbBpaUc7BTq QDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAL/7xnvtunnlMu2PJOKdV4JxDyYFnQ0xz9zdt0wXh9FtXJ6E0CXBQudOzNU7 RXqKJolxwjL9sGOJfakU/M9jotE/0PZ28leFJwrDfNjPO07ZTd3YRNzDscDDPmjzwzSi1HEBrRY0 Tzq1yjUO3fbQY1vQGWyvM1vMFsZNzpBrdmOD6+NI6SAmzEA/fRhumeobtZksqyHhXSeciCi851X+ fhk0tNIxAcpK4SO9lSTYxi/rHFpgnL8g5h5hhfMzzz7Nx4clDn2WyHrt314iXA8jeAg8gyoYiuaT QDRO32IxUDGtD2TiKAUHOdbJc/E4BEKQq8tOXKt75Cwd3U6E0LxADrhYIU74/uYfj1SQbg/t1uFp AwJW0NodysZ907MrzQZVp8dp17QwNjHDwkvVCT1BGPHX9KNDqPdLnQrDle6WsbcryswafPt16B9e ADo3REKOskT5ENeDMCt/Rnt9Ks5Zs7/koU2VEhlAioHfFZercEIHBmv4e2YzQ1ZnsO5WM0MM9yi8 7GDpksN6Q4IyGwuIH9ePDQm/qbOVG6dhldcRt2Y+UCVNB0iyVUvpY/vevRI+WZGQiWMAswWq0S0M 8WV8bWnJ6t5PxUDBhSkMzYQZBpgrPEObxp3qD+BKFytks7DB2poyLNIymjV9W0bPn9gVY1vk2ncD trm5mFswSm9LWbEiAAAAAAAA ------=_NextPart_000_0124_01C78E7D.9E703B40-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l42FmlPB019559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2007 08:48:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l42Fmk4A019558; Wed, 2 May 2007 08:48:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l42FmO9H019503 for ; Wed, 2 May 2007 08:48:45 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l42FmGI5022525; Wed, 2 May 2007 17:48:17 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LTANS: clean-up of ltans oid structure - next revision of OID Registry Date: Wed, 2 May 2007 17:48:16 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0027_01C78CE2.0FBEF9A0" Message-ID: <2666EB2A846BAC4BB2D7F593301A7868E389D0@MUCXGC2.opentext.net> In-Reply-To: <4635F972.9040108@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: clean-up of ltans oid structure - next revision of OID Registry Thread-Index: AceLMgHiP1bGNZ8gRneeQr1eBR8HzgBmgm4A From: "Tobias Gondrom" To: "Peter Sylvester" Cc: "Carl Wallace" , Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C78CE2.0FBEF9A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, a few comments inline. - Tobias > Hi, > > I think we are getting closer. But some comments anyway. > > > First, only the id-* need to be defined with global names. They are in > fact defined in each > of the asn.1 modules for ers or ltap, etc. The other ids are not global > definitions. They > are not intended to be importable from anywhere. I am not sure I understand your comment correctly (as ers and ltans are father nodes of the other global OIDs we should also list them correctly. Please refer as examples to how other WGs registered their OIDs (e.g. PKIX and SMIME) http://www.imc.org/ietf-pkix/pkix-oid.asn and you should also take a look at: http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.5.5.7&action=displa y http://www.imc.org/ietf-smime/sm-oid.asn and of course also the global registry: http://asn1.elibel.tm.fr/oid/index.htm > ltans, ers and ltap are special: They are used locally in the ers or > ltap module to > define the parents of some id-* > unless we follow the logic of the ITU to have a useful definitions module > where we can even import oid of moduls, there is no reason to them > a name, they are just object identifier values. > > Second, mste values should have names at the last component, i.e. all > except the module > identifiers whether the last is just the version number. > > I still don't think that pushing down the module arc below ers or ltap > is a good idea, since > other working groups don't do that. IMO it does too much of delegation > to a topic > writer like ers or ltap. Well, the actual logic means: "Dear ltans > contributor, if > you want to contribute some work, tell us how many asn1 modules you want, > and we give you an arc root where you are supposed to add one > mod(2) > mod88(1) > and you can use the rest of the arc as you wish. You are right, that the other examples (PKIX and SMIME seem to have put all modules in a flat hierachie below the first level OID "id-mod". But without versions and most of them also did not cope with different ASN.1 versions in their modules. We had some design choices: from my point of view mostly we have the choice of a flat and very compact (though maybe unorganized) tree or to improve this by adding the version and further hierarchies. So this is why I came up with the proposed solution. What I definitely want to prevent is to have two top-level arcs mod and mod88 (which by the way hasn't been done by any other WG either). > > I prefer at least for tyhe modules: > > 'Write one or two modules', chose a NAME for the module, we (ltans) > give > you an identifier for that. " ... > > BtW, in any case I'd prefer module(0) instead of mod(2) Is your preference because of the length module vs. mod or is it because of the number 0 vs. 2? > > Tobias Gondrom wrote: > > Hello Peter, hello all, > > > > sorry, that this answer took me so long, but I have been occupied the > last week with some other things. :-( > > > > > > I agree, we are on the same page. > > As mentioned before, the intention is to list the OIDs we will register > at the LTANS OID registry at http://www.imc.org/ietf-ltans/ltans-oid.asn > > > I don't see what is supposed to be registered and how. The only OID, in > fact, it value > is the > > { iso(1) identified-organization(3) dod(6) internet(1) security(5) > mechanisms(5) ltans(11) } > > > I don't think that we need an actual global definition id-ltans or ltans > for it. > If the name is a hint that instruct module writers to include a local > definition of > that kind, then, why not, so in the ers modules one would have the > definitions > > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > > -- LTANS Arcs > ers OBJECT IDENTIFIER ::= { ltans ers(1) } - Evidence Record Syntax > > in order to be able to says > > id-ers-em OBJECT IDENTIFIER ::= { ers em(3) } > > instead of > > id-ers-em OBJECT IDENTIFIER ::= { ltans ers(1) em(3) } > > or > > id-ers-em OBJECT IDENTIFIER ::= { so(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) > ers(1) em(3) } > > Note the NAMES ers and em on the right side! > > > > > > 1. As no one else had any additional comments concerning the naming > convention (module vs. module97) I will follow your proposal. > > > > 2. As I learned also from our discussion my naming convention was in > some cases a bit confusing (and ambiguous), so I looked again at the other > OID lists and revised the draft for LTANS-OIDs slightly to be unambiguous > by using the name of the father node as the prefix for the name of the > child-node (as done by PKIX and SMIME). Other OID lists follow the > guidance to always use the short code of the level above as the prefix for > the identifiers one level below, without the WG father node, e.g. at PKIX > id-swb-pkc-cert-path being a child of id-swb. > > > > Please note: I only revised the names, the structures stayed exactly the > same. And I hope that the new names and convention are acceptable. > > > > If not, please reply until May-07 to the list. > > > > One small additional comment concerning the prefix "id": > > I only used it for some of the identifiers, if there is a WG consensus > to use the id-prefix for all identifiers, I will of course follow this > guidance, but I would vote for the names as listed below: > > > The NAMES on the left side are global since the registry is not part of > an asn.1 modul, > so you cannot just import the values. This "asn" file just uses some > asn.1 syntax but this > seems inappropriate to me. > > > > > -- LTANS Object Identifier Registry > > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > > > > > -- LTANS Arcs > > ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > > > > { ltans ers(1) } > > > ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol > > > > { ltans ltap(2) } > > Thus one I already meantioned above. > > -- ERS Modules > > ers-mod88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax > > > > { ers mod88(1) } > > > ers-mod OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax > > > > { ers mod(2) } > > I'd prefer 0 as in other specs. and cann it module(0) > > > id-ers-em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method in ERS > { ers em(3) } > > > } > > > > -- Version for ERS Module 88 > > ers-mod88-ver OBJECT IDENTIFIER ::= { ers-mod88 1 } - Version number for > RFC > > > > -- Version for ERS Module > > ers-mod-ver OBJECT IDENTIFIER ::= { ers-mod 1 } - Version number for > RFC > > > > > > -- ERS Encryption Methods > > id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em 1} > > id-ers-em-er-external OBJECT IDENTIFIER ::= {id-ers-em 2} > > > > > > id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em er-internal(1)} > > etc > > > -- LTAP Modules > > ltap-mod88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax > > ltap-mod OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax > > > > { ltap mod88(1) } > { ltap mod(2) } > > > > -- for LTAP Module 88 > > ltap-mod88-ver OBJECT IDENTIFIER ::= { ltap-mod88 1 } - Version number > for RFC > > > > -- for LTAP Module > > ltap-mod-ver OBJECT IDENTIFIER ::= { ltap-mod 1 } - Version number for > RFC > > > > > > The names on the right side are necssary since we want to write > > ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) ltans(11) ers(1) mod(2) 1 } > or as I prefer > > > ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) ltans(11) module(0) ers(1) 1 } > > > > > Best regards, Tobias > > > > > > > Have fun. ------=_NextPart_000_0027_01C78CE2.0FBEF9A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA1MDIxNTQ4MTVaMCMGCSqGSIb3DQEJBDEWBBRqWU8icQF07nxaK9jICR4bYsJ8 ZzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAJATpjgOil3vA/c+lTbKpQqDSP4yjF6mjjBYFjiL3BZDUXmL+XhJO9ESbp/T FaRmJyc89E3pujPf6NWd6foPCdZMhCS/a6//sU0p2srEVy0LxEttn2MOUdFXTnl+ijSxLRq1d4DV vRwF0mfRhzRGglKB0SF768w7yptmUPivmAInungz62gYqmc4rnbr0hNMjdJ/mBvyuFOiQoIFZEda 0iiFbjUgRXkOVISlJ8/E3ME6cd0JFBw16o6JDVTW6bmJqnqm/cCJolaZbknl90b/GuW6QQO76l4j 7IoHOq0OIXYTdeSne0/NkBOGChrUuWWMOlHI7Yl2ODEsWupbe6usMvV7ugFZ/+rDM32SrWj//aLY qY5rkLulz8vSUBiD8islH73eDiurglkdTXgslZYs+AC+8zv/CifYMfsEivlNqyB08p3T9hQrZ6lH GsPeM+wUG16EFKNgZSN0CWfykipWz0p9SW6fRyozXHBV7Yy5OnlbwV3NeDIA3qkd88XY4DkgnQoi mB8K1kAT3TgyEZ8rtClUcNPq7trG15XvUu+HvQtQySZ/2VopNNQZtIh4f8VSOPQ+9fVNx9c0Dqtw Z9w1i73i2My19ITyEXjycXH1Au/BbagpBENU1i1DyCpBg6TMJbgJYHZN7BhDFkD65VtOGrQaM8sW 1Uxpq5JFoM8Loe6pAAAAAAAA ------=_NextPart_000_0027_01C78CE2.0FBEF9A0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l41GhZjc014941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2007 09:43:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l41GhZk9014940; Tue, 1 May 2007 09:43:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l41GhBR9014847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2007 09:43:34 -0700 (MST) (envelope-from ulrich.pordesch@sit.fraunhofer.de) Received: from pcpordeschlab (sitp2_57.sit.fraunhofer.de [141.12.69.57]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with SMTP id l41Gh6P5014940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 May 2007 18:43:08 +0200 From: "Ulrich Pordesch" To: "'Tobias Gondrom'" , References: <2666EB2A846BAC4BB2D7F593301A7868E387A3@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868E387A3@MUCXGC2.opentext.net> Subject: AW: I-D ACTION:draft-ietf-ltans-ers-12.txt Date: Tue, 1 May 2007 18:43:02 +0200 Message-ID: <005201c78c0f$cd0e6820$672b3860$@pordesch@sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acd7V4VY7hQjz9uMQY2BfvBIGr2M5QPx6A9wADwJY2A= Content-Language: de Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l41GhYR8014933 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I fully agree with your assessment, Tobias. There is no need to modify the draft based on these new comments from Denis. Ulrich -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Tobias Gondrom Gesendet: Montag, 30. April 2007 14:41 An: Denis Pinkas Cc: ietf-ltans@imc.org Betreff: RE: I-D ACTION:draft-ietf-ltans-ers-12.txt Hello Denis, thank you for your review and please excuse that it took me so long to answer. 0. As ERS is in IETF LC (started 2007-02-21), I will treat and document your comments also as IETF LC comments. But now concerning your comments: 1. This is as designed. When an initial EvidenceRecord is created there is only one ArchiveTimeStamp in it. Further ArchiveTimeStamps (in the ArchiveTimeStampChain are added when Timestamp-renewald are necessary (this means there is always just one further ArchiveTimestamp added to the chain). and similar to that of with new ArchiveTimestamps created by hashtree-renewal. So the use case (to create at one point in time multiple ArchiveTimestamps within the same ArchiveTimestampchain) you described actually never applies. 2. In fact it is very easy to find out which documents are stored/covered by and ArchiveTimeStamp: the hash values of the documents (which can be computed easily) are stored in the first ArchiveTimeStamp. So it is trivial to relate documents to the EvidenceRecord. 3. CryptoInfos and EncryptionInfo follow two very different goals: CryptoInfos to provide information (like all used algorithms) at the higher level of the EveidenceRecord to make processing easier (or to make it easy to decide for an implementation whether it shall proceed with the evaluation or abort if it may not be able to compute one of thee listed algorithms.) encryptionInfo has the intend to ensure a bi-directional mapping between used encryption methods (like e.g. splitting the bits between several archive systems) and the documents. (Note in some cases such an encryption algorithm might use additional parameters and only be surjective but not be bijective. The encryptionInfo field is allow the user to provide all necessary information to make the operation fully bijective. (By this the proof that the decrypted information mathematically unambiguously matches the encrypted and by the EvidenceRecord protected content.) 4. a) An unlimited number of levels in the hashtree is definitely possible with the current structure. (It is not limited to 3 levels.) b) every node is unambiguous. c) at first the structure of the EvidenceRecord is obviously intended to be extended every time algorithms get weak and a timestamp-renewal or hashtree-renewal occurs. So it is not intended to include an EvidenceRecord within another for this need (the equivalent of your idea is that ArchiveTimestamps protect the preceeding ArchiveTimestamps, which is the case). At any given time an existing EvidenceRecord can be extended (also by another party) and if it is necessary (although I can see no clear use case for that) it can of course also be stored and protected itself as a data object protected by an EvidenceRecord. d) we have added several hooks for extensibility with the Attributes in the ArchiveTimeStamp structure. (btw. inspired by your last review) e) it is not intended to stack time-stamp tokens with CRLs by a one-to-one relationship. Additional verification data for the timestamps should be stored in the timestamp structures themselves or in the cryptoInfos. Summarizing: The comments above are due to misunderstanding but do not demonstrate a defect in the draft or data structure. I can see no need to make any changes to the draft, except for the wording: there had been a few wording comments from the AD review and those will be addressed in a new version. The new draft is scheduled to be submitted in one week and will (if no further objections occur) then be processed further in the IETF LC. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Tuesday, April 10, 2007 11:44 AM > To: ietf-ltans@imc.org > Subject: Re: I-D ACTION:draft-ietf-ltans-ers-12.txt > > > Comments on draft-ietf-ltans-ers-12 > > Major comments 1 to 4 > > The current syntax is defined as: > > EvidenceRecord ::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > cryptoInfos [0] CryptoInfos OPTIONAL, > encryptionInfo [1] EncryptionInfo OPTIONAL, > archiveTimeStampSequence ArchiveTimeStampSequence > } > > ArchiveTimeStampSequence ::= SEQUENCE OF > ArchiveTimeStampChain > > ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, > attributes [1] Attributes OPTIONAL, > reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} > > Attributes ::= SET SIZE (1..MAX) OF Attribute > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > There are several problems with this syntax: > > 1) Within ArchiveTimeStamp, the timeStamp element is mandatory. > When an ArchiveTimeStampChain is being built, several time stamp tokens > will be needed whereas only one time stamp token at the top of the > hierarchy > is really needed. It should be possible to have a timeStamp element > present > in the EvidenceRecord structure. > > 2) When the Evidence Record is stored separate from the archived data, > the syntax does not allow to interoperate, since there is no way to know > how to build or reconstruct the right sequence of PartialHashtrees. > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > One way to solve this issue would be to add the name of each element used > to construct the hash tree, so that that name can be used to locate and > fetch > the corresponding file. > > 3) cryptoInfos and encryptionInfo are currently defined as follows: > > CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute > > EncryptionInfo ::= SEQUENCE { > encryptionInfoType OBJECT IDENTIFIER, > encryptionInfoValue ANY DEFINED BY encryptionInfoType > } > > cryptoInfos and encryptionInfo do not allow any kind of interoperability. > It would more appropriate to define generic extensions, like for > certificates and CRLs: > > extensions Extensions OPTIONAL, > > 4) The current syntax does not allow : > > - an unlimited number of levels in the tree (only three levels are > possible); > - to identify a node; > - to incorporate into an Evidence Record, previously computed Evidence > Records; > - to add new extensions; > - to stack time-stamp tokens and CRLs. > > The following syntax would solve the issue: > > EvidenceRecord::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > reducedHashtree ReducedHashtree OPTIONAL, > otherEvidenceRecords SEQUENCE OF EvidenceRecord OPTIONAL, > extensions Extensions OPTIONAL, > timeStamps SEQUENCE OF TimeStamp > } > > ReducedHashTree ::= SEQUENCE { > hashTreeElements SEQUENCE OF HashTreeElement, > reducedHashTree SEQUENCE OF ReducedHashTree OPTIONAL > } > > HashTreeElement ::= SEQUENCE { > node BOOLEAN DEFAULT FALSE, > digestAlgorithm AlgorithmIdentifier, > elementHash OCTET STRING, > elementName GeneralName OPTIONAL, > } > > TimeStamp ::= SEQUENCE { > tst ContentInfo, > crl CertificateList OPTIONAL > } > > Sections 3.2 and 3.3 would need to be rewritten. > > Minor comment > > The word non-repudiation is misused in several places. For example, on > page 6: > > " each Archive Timestamp preserves non-repudiation of the previous Archive > Timestamp" . > There is no need to use the word non-repudiation here, since the following > sentence is sufficient: > " each new time-stamp maintains the validity of the previous time-stamp". > > Denis > > ================================================================ > > > 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-12.txt > > Pages : 34 > > Date : 2007-3-8 > > > > In many scenarios, users must be able prove the existence and > > integrity of data, including 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, a structure designed to support long-term non- > > repudiation of existence of data. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.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-12.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-12.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. > > > > Content-Type: text/plain > > Content-ID: < 2007-3-8122718.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-ltans-ers-12.txt > > > > Regards, > > Denis Pinkas