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 l0TKo4se007333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 13: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 l0TKo4nJ007332; Mon, 29 Jan 2007 13: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 ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TKo3vp007326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Jan 2007 13:50:04 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C7A6832993; Mon, 29 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HBdRy-0001XY-L7; Mon, 29 Jan 2007 15:50:02 -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-validate-01.txt Message-Id: Date: Mon, 29 Jan 2007 15:50:02 -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 : Verification Data Author(s) : T. Gondrom Filename : draft-ietf-ltans-validate-01.txt Pages : 11 Date : 2007-1-29 Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-01.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-validate-01.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-validate-01.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-1-29114215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-validate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-validate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-29114215.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 l0LDDedC022563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jan 2007 06:13: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 l0LDDe97022562; Sun, 21 Jan 2007 06:13: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 mail.seccommerce.de (mail.seccommerce.de [87.139.75.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0LDDaGu022553 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sun, 21 Jan 2007 06:13:39 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 10526 invoked from network); 21 Jan 2007 13:19:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.1.10) by 0 with RC4-MD5 encrypted SMTP; 21 Jan 2007 13:19:29 -0000 Message-ID: <45B36705.70603@seccommerce.de> Date: Sun, 21 Jan 2007 14:13:41 +0100 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: Clarification of ISO-IEC 18014 documents References: <886F5D4C78AFB14D87261206BFB9612E1C41D8AE@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1C41D8AE@scygmxs1.cygnacom.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: A note from my implementator's point of view: We implemented ERS in our product called SecPKI-server. Several customer's have been using it for some time now. ERS fulfils the requirement that we have: To aggregate a large number of document's hashes into a hash-tree so that they are all protected by a single archive time stamp on the root of the tree. I've described it a bit too simple, ERS is more, I know. I don't know whether the mentioned ISO document treats the same subject. Even if it did, that wouldn't be a reason to change our working implementation. Regards Tilo Carl Wallace wrote: > > -----Original Message----- > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > Sent: Wednesday, January 17, 2007 8:47 PM > > Subject: Re: Clarification of ISO-IEC 18014 documents > > > > Yes, the spec is rather opaque in that regard. Fortunately, > > 18014-1-revised will do so. > > > > It seems to me that aggregation would need to be built into > > extRenewal or other EXTENSIONS in a standard way. > > So the ISO spec would need to be enhanced and ported into the IETF. ERS > achieves these ends now and is already there. > > > I agree the opportunity for change has been waiting about for > > well over a year. How many applications are ready for this > > draft to be a standard? > > Several implementations have been cited on the list and at the WG > meetings over the last year or so. There is also an XML version out > there (Aleksej?). 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 l0IEuJQ1070292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 07:56:19 -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 l0IEuJG4070291; Thu, 18 Jan 2007 07:56:19 -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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IEuImR070284 for ; Thu, 18 Jan 2007 07:56:19 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l0IDuF510477; Thu, 18 Jan 2007 14:56:16 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 18 Jan 2007 14:56:16 +0100 (MET) Message-ID: <45AF7C04.1040706@edelweb.fr> Date: Thu, 18 Jan 2007 14:54:12 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Denis Pinkas CC: "ietf-ltans@imc.org" Subject: LTAP comments References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103030803010003060607" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms010103030803010003060607 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have changed the subject and removed the smime list a target in order to create a thread based on the comments from Denis concerning LTAP. Denis Pinkas wrote: > Peter, > > You said: > > >> The details how a delete request is authenticated is outside of scope of >> LTAP as well as management of ownerships etc. >> > > Many aspects seem to be outside the scope of the document, whereas they should not.. > This remark is not extremely helpful. If you tell what you think is missing in that document please tell. > >> A trace record means: "At this place there had been some data which can >> be described by (list of some metadata), >> they had been deleted (metadata about that fact)." It is not the backend >> LTA that creates all these metedata, >> the frontend that authenticates the request prepares some of them. The >> LTA does not make complicated decisions. >> > > A trace record from the LTA would be insufficient in case of a dispute. > I realize that the term 'trace record' is not really appropriate. LTAP treats with objects, so when an object is deleted, it can be in fact be replaced by a particular object that only has metadata indicating that the original object had been deleted. On of the possible metadata is a new location. > An LTA is providing a service for someone. An LTA has to be made responsible > of its actions, and therfor must give back some proof for each deposit or for an addition > to a former deposit. > Each operation has a result statement. This is given from the LTAP server to its immediate client. The LTAP specification does not, and probably should not specify what mechanism is used between a client and a server ensure authenticity of the requests and responses, and to allow third parties to verify this. What the LTAP protocol does allow is to carry identities of participating parties in the requests/response and also as metadata for the objects. Well, having said that, the number of possible mechanisms is not really huge. > In case the owner of the data decides to shorten the original archival time period > (BTW mentioned nowhere in ERS or in LTAP), then the LTA must be able to present > some proof of that will, otherwise the owner of the data could pretend that the archive > was deleted by the LTA before the end of the original archival period. > LTAP does not say who is allowed to delete. This depends on policies and configuration which are a layer around/above LTAP. It be that an owner is never allowed to delete, only someone else, for example. If someone has archived data, and the response can be attributed to some lta because of a signature (or because some other LTA which archives all the results of another LTA, e.g. a journal confirms the fact), what can happens: - the LTA still has the data and one can access them, - the LTA has deleted the data and has a placeholder that indicates something - the LTA has nothing. The protocol does not prohibit the last situation, when it occurs, this can be either a result of a voluntary action of some 'authority' or a catastrophic failure (like in Paris with ownership records of buildings) or a bad implementation or configuration. How to attribute faulty behaviour, or even recover from this situation, is another question. Peter --------------ms010103030803010003060607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE4MTM1NDEyWjAjBgkqhkiG9w0B CQQxFgQU7+0gsw7+VQGbd0zDtlspv+jihZ0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAJqDpTsQy+r1ap/qD h5aeAfuq6EKm+3pWrHbZyFTSDTcV5rYMOlPl/V91hEiz1G7L9wpbAgQJrJK5jvQYC5jnyDyX JAE0TLNyjeBSRRjiLKUFqaKuRCo4kQR+BGD4HsjyAShjLPZ7JQXwhlolEwbPYu9wviAeSlE9 nvwz77vz/7gAAAAAAAA= --------------ms010103030803010003060607-- 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 l0IEH5BA066862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 07:17:05 -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 l0IEH5WB066861; Thu, 18 Jan 2007 07:17:05 -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 burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IEH3Rw066854 for ; Thu, 18 Jan 2007 07:17:04 -0700 (MST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.22] (ullapool.yandk.org [192.168.1.22]) by burrens.yandk.org (Postfix) with ESMTP id D0A2516521; Thu, 18 Jan 2007 09:17:02 -0500 (EST) Message-ID: <45AF815E.9050100@yhetheridge.org> Date: Thu, 18 Jan 2007 09:17:02 -0500 From: Young H Etheridge User-Agent: Thunderbird 2.0b1 (X11/20061206) MIME-Version: 1.0 To: Tobias Gondrom Cc: Carl Wallace , ietf-ltans@imc.org Subject: Re: Clarification of ISO-IEC 18014 documents References: <2666EB2A846BAC4BB2D7F593301A78689B3EE8@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78689B3EE8@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: And I don't disagree with Carl, either. I was merely going on record to clarify a misconception on the capability of 18014 for the mailing list. I have no other agenda. Tobias Gondrom wrote: > > I agree with Carl. > > > > Young, if you like, feel free to invite me to the ISO discussions and > I will be happy to present ERS there. > > And second I am not sure I understood your initial email correctly: Do > you propose to add some new text to ERS, or was this just a > clarification for the mailing list? > > (if the first is the case, as I would not want to miss any requests > for change to the ERS, please send the proposed text and section again.) > > > > Tobias > > > > > > > > > > * From: * owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] *On Behalf Of *Carl Wallace > *Sent:* Thursday, January 18, 2007 1:26 PM > *To:* Young H Etheridge > *Cc:* ietf-ltans@imc.org > *Subject:* RE: Clarification of ISO-IEC 18014 documents > > > > > -----Original Message----- > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > Sent: Wednesday, January 17, 2007 8:47 PM > > Subject: Re: Clarification of ISO-IEC 18014 documents > > > > Yes, the spec is rather opaque in that regard. Fortunately, > > 18014-1-revised will do so. > > > > It seems to me that aggregation would need to be built into > > extRenewal or other EXTENSIONS in a standard way. > > So the ISO spec would need to be enhanced and ported into the IETF. > ERS achieves these ends now and is already there. > > > I agree the opportunity for change has been waiting about for > > well over a year. How many applications are ready for this > > draft to be a standard? > > Several implementations have been cited on the list and at the WG > meetings over the last year or so. There is also an XML version out > there (Aleksej?). > 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 l0ID49LK061162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 06:04:09 -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 l0ID49u2061161; Thu, 18 Jan 2007 06:04:09 -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 l0ID453F061154 for ; Thu, 18 Jan 2007 06:04:08 -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 l0ID3x3H024822; Thu, 18 Jan 2007 14:04:00 +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_01C73B01.1E810FDC" Subject: RE: Clarification of ISO-IEC 18014 documents Date: Thu, 18 Jan 2007 14:03:59 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B3EE8@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of ISO-IEC 18014 documents Thread-Index: Acc6/3vIJdPnQtbjSWO3ux7r6b80OQAAMWjw From: "Tobias Gondrom" To: "Carl Wallace" , "Young H Etheridge" Cc: 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_01C73B01.1E810FDC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Carl.=20 =20 Young, if you like, feel free to invite me to the ISO discussions and I will be happy to present ERS there.=20 And second I am not sure I understood your initial email correctly: Do you propose to add some new text to ERS, or was this just a clarification for the mailing list? (if the first is the case, as I would not want to miss any requests for change to the ERS, please send the proposed text and section again.) =20 Tobias =20 =20 =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, January 18, 2007 1:26 PM To: Young H Etheridge Cc: ietf-ltans@imc.org Subject: RE: Clarification of ISO-IEC 18014 documents =20 > -----Original Message-----=20 > From: Young H Etheridge [mailto:yhe@yhetheridge.org]=20 > Sent: Wednesday, January 17, 2007 8:47 PM=20 > Subject: Re: Clarification of ISO-IEC 18014 documents=20 >=20 > Yes, the spec is rather opaque in that regard. Fortunately,=20 > 18014-1-revised will do so.=20 >=20 > It seems to me that aggregation would need to be built into=20 > extRenewal or other EXTENSIONS in a standard way.=20 So the ISO spec would need to be enhanced and ported into the IETF. ERS achieves these ends now and is already there.=20 =20 > I agree the opportunity for change has been waiting about for=20 > well over a year. How many applications are ready for this=20 > draft to be a standard?=20 Several implementations have been cited on the list and at the WG meetings over the last year or so. There is also an XML version out there (Aleksej?). =20 ------_=_NextPart_001_01C73B01.1E810FDC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Clarification of ISO-IEC 18014 documents

I agree with Carl. =

 

Young, if you = like, feel free to invite me to the ISO discussions and I will be happy to present = ERS there.

And second I am = not sure I understood your initial email correctly: Do you propose to add some = new text to ERS, or was this just a clarification for the mailing = list?

(if the first is = the case, as I would not want to miss any requests for change to the ERS, please = send the proposed text and section again.)

 =

Tobias

 

 =

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Carl Wallace
Sent: Thursday, January = 18, 2007 1:26 PM
To: Young H Etheridge
Cc: = ietf-ltans@imc.org
Subject: RE: = Clarification of ISO-IEC 18014 documents

 

> -----Original Message-----
> From: Young H = Etheridge [mailto:yhe@yhetheridge.org] =
> Sent: Wednesday, = January 17, 2007 8:47 PM
> Subject: Re: = Clarification of ISO-IEC 18014 documents
>
> Yes, the spec is = rather opaque in that regard.  Fortunately,
> 18014-1-revised = will do so.
>
> It seems to me that aggregation would need to be built into
> extRenewal or other = EXTENSIONS in a standard way.

So the ISO spec would need to be enhanced and ported into the IETF.  ERS = achieves these ends now and is already there.
  =
> I agree the = opportunity for change has been waiting about for
> well over a = year.  How many applications are ready for this
> draft to be a = standard?

Several implementations have been cited on the list and at the WG meetings over = the last year or so.  There is also an XML version out there = (Aleksej?). 

------_=_NextPart_001_01C73B01.1E810FDC-- 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 l0ICvUWU060556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 05:57:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0ICvUwo060555; Thu, 18 Jan 2007 05:57:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0ICvSqb060549 for ; Thu, 18 Jan 2007 05:57:28 -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 l0ICvMlk024155; Thu, 18 Jan 2007 13:57:23 +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: Clarification of ISO-IEC 18014 documents Date: Thu, 18 Jan 2007 13:57:21 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B3EE2@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of ISO-IEC 18014 documents Thread-Index: Acc6pGNf6iChZe6kS3KzPe8bWavt3gAWmRkg From: "Tobias Gondrom" To: "Young H Etheridge" , "Carl Wallace" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0ICvTqb060550 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, from what I know of the ISO 19014 I see no reason to deviate from the current course. It is one thing to provide a solution for a single timestamp ro document but another to concur with the aggregation and support of large numbers of documents as provided by ERS. (In fact this was one of the most important attributes in the first place, cause if you only consider one document or one signature you could do this by hand simply by applying a new timestamp on container (e.g. zip) of a document and its RFC3161 TS and you are done. The main problem was to aggregate large numbers of documents with high performance. And I can not see that this is covered by ISO 18014. Second I will not rely or speculate on a solution that is currently "work in progress" at ISO to consider whether ERS should be stopped in this final stage. I would rather turn the arguments around and say ISO should consider taking a closer look at IETF ERS draft which is ready now and in case they plan to dublicate its functionality, reconsider whether this would be very wise. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Young H Etheridge > Sent: Thursday, January 18, 2007 2:47 AM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: Re: Clarification of ISO-IEC 18014 documents > > > Yes, the spec is rather opaque in that regard. Fortunately, > 18014-1-revised will do so. > > It seems to me that aggregation would need to be built into extRenewal > or other EXTENSIONS in a standard way. > > I agree the opportunity for change has been waiting about for well over > a year. How many applications are ready for this draft to be a standard? > > Carl Wallace wrote: > > > > I see. So it does address the coverage of original and current hashes > > (if only the spec had included language about verification of > > extRenewal I might have caught that). How about support for > > aggregation? > > > > Aside from the technical bits, there's also the question of whether an > > 11th hour request like this is justifiable. > > > > > -----Original Message----- > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > Sent: Wednesday, January 17, 2007 5:33 PM > > > To: Carl Wallace > > > Cc: ietf-ltans@imc.org > > > Subject: Re: Clarification of ISO-IEC 18014 documents > > > > > > As I understand the process: > > > > > > A TSA that supports renewal requests, in response: > > > - generates a new TSTInfo, > > > - copies the hash value from the request into the TSTInfo, > > > - copies the extRenewal extension from the request into an > > > extRenewal > > > extension of the TSTInfo with this extRenewal containing > > > the desired > > > original TS, > > > - sets the current time and fills in the other fields of > > > TSTInfo, and > > > - proceeds to generate the renewal timestamp token for this TSTInfo. > > > > > > Unless I misunderstand the process this renewal timestamp > > > token covers both the submitted hash value and the previous > > > timestamp token regardless of the method is used by the TSA > > > for generating the ContentInfo. > > > > > > This process is echoed in the revised 18014-1text. > > > > > > Carl Wallace wrote: > > > > > > > > In response to Denis' post, I reviewed the mechanisms in > > > 18014-3. How > > > > do those align with the text from -1? > > > > > > > > > -----Original Message----- > > > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > > > Sent: Wednesday, January 17, 2007 4:19 PM > > > > > To: CWallace@cygnacom.com > > > > > Cc: ietf-ltans@imc.org > > > > > Subject: Clarification of ISO-IEC 18014 documents > > > > > > > > > > Carl, > > > > > > > > > > A clarification of the ISO 18014 documents may be useful. > > > > > > > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend > > > TS renewal > > > > > in the terms as expressed in WG communications of late. I quote: > > > > > "A time-stamp re-issue may also be necessary when the > > > hash--function > > > > > used to form the hash value from the original data is called into > > > > > question. In this case, both the old time-stamp token and the > > > > > original data must be included in the newly calculated hash value > > > > > submitted for time-stamp reissue." > > > > > > > > > > A revision of 18014-1 is in-progress. The term reissue is being > > > > > replaced with renewal along with descriptive information > > > that makes > > > > > the point clear that a renewal contains a hash of the data along > > > > > with the hash of the original TS that is being renewed. The new > > > > > description is quite clear in regard to creation and > > > verification of > > > > > renewal. > > > > > > > > > > Furthermore, ANSI X9.95 is consistent on renewal with > > > those found in > > > > > 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > > > > > > > > > I hope this helps. > > > > > > > > > > yhe > > > > > > > > > > > > > > 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 l0ICgR0r059672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 05:42:27 -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 l0ICgRf6059671; Thu, 18 Jan 2007 05:42:27 -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 l0ICgPMV059664 for ; Thu, 18 Jan 2007 05:42:26 -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 l0ICgDHt024075; Thu, 18 Jan 2007 13:42: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: text/plain; charset="us-ascii" Subject: RE: Clarification of ISO-IEC 18014 documents Date: Thu, 18 Jan 2007 13:42:12 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B3ED6@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of ISO-IEC 18014 documents Thread-Index: Acc6pGNf6iChZe6kS3KzPe8bWavt3gAWMpJQ From: "Tobias Gondrom" To: "Young H Etheridge" , "Carl Wallace" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0ICgRMV059666 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To my knowledge about at least 6 implementations of ERS already exist - some of them done by large or very large ISVs (in its draft versions between 06 and 09) - and at least some of them have been long waiting for the ERS to be released and definitely consider the ISO 18014 under no circumstances as an alternative (but as an extension) nor will they shift their development to it. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Young H Etheridge > Sent: Thursday, January 18, 2007 2:47 AM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: Re: Clarification of ISO-IEC 18014 documents > > > Yes, the spec is rather opaque in that regard. Fortunately, > 18014-1-revised will do so. > > It seems to me that aggregation would need to be built into extRenewal > or other EXTENSIONS in a standard way. > > I agree the opportunity for change has been waiting about for well over > a year. How many applications are ready for this draft to be a standard? > > Carl Wallace wrote: > > > > I see. So it does address the coverage of original and current hashes > > (if only the spec had included language about verification of > > extRenewal I might have caught that). How about support for > > aggregation? > > > > Aside from the technical bits, there's also the question of whether an > > 11th hour request like this is justifiable. > > > > > -----Original Message----- > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > Sent: Wednesday, January 17, 2007 5:33 PM > > > To: Carl Wallace > > > Cc: ietf-ltans@imc.org > > > Subject: Re: Clarification of ISO-IEC 18014 documents > > > > > > As I understand the process: > > > > > > A TSA that supports renewal requests, in response: > > > - generates a new TSTInfo, > > > - copies the hash value from the request into the TSTInfo, > > > - copies the extRenewal extension from the request into an > > > extRenewal > > > extension of the TSTInfo with this extRenewal containing > > > the desired > > > original TS, > > > - sets the current time and fills in the other fields of > > > TSTInfo, and > > > - proceeds to generate the renewal timestamp token for this TSTInfo. > > > > > > Unless I misunderstand the process this renewal timestamp > > > token covers both the submitted hash value and the previous > > > timestamp token regardless of the method is used by the TSA > > > for generating the ContentInfo. > > > > > > This process is echoed in the revised 18014-1text. > > > > > > Carl Wallace wrote: > > > > > > > > In response to Denis' post, I reviewed the mechanisms in > > > 18014-3. How > > > > do those align with the text from -1? > > > > > > > > > -----Original Message----- > > > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > > > Sent: Wednesday, January 17, 2007 4:19 PM > > > > > To: CWallace@cygnacom.com > > > > > Cc: ietf-ltans@imc.org > > > > > Subject: Clarification of ISO-IEC 18014 documents > > > > > > > > > > Carl, > > > > > > > > > > A clarification of the ISO 18014 documents may be useful. > > > > > > > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend > > > TS renewal > > > > > in the terms as expressed in WG communications of late. I quote: > > > > > "A time-stamp re-issue may also be necessary when the > > > hash--function > > > > > used to form the hash value from the original data is called into > > > > > question. In this case, both the old time-stamp token and the > > > > > original data must be included in the newly calculated hash value > > > > > submitted for time-stamp reissue." > > > > > > > > > > A revision of 18014-1 is in-progress. The term reissue is being > > > > > replaced with renewal along with descriptive information > > > that makes > > > > > the point clear that a renewal contains a hash of the data along > > > > > with the hash of the original TS that is being renewed. The new > > > > > description is quite clear in regard to creation and > > > verification of > > > > > renewal. > > > > > > > > > > Furthermore, ANSI X9.95 is consistent on renewal with > > > those found in > > > > > 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > > > > > > > > > I hope this helps. > > > > > > > > > > yhe > > > > > > > > > > > > > > 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 l0ICQAP5057959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 05:26:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0ICQAR2057958; Thu, 18 Jan 2007 05:26:10 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0ICQ7jM057947 for ; Thu, 18 Jan 2007 05:26:10 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 17663 invoked from network); 18 Jan 2007 12:25:16 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;18 Jan 2007 12:25:16 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 18 Jan 2007 12:25:16 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Jan 2007 07:26:04 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D8AE@scygmxs1.cygnacom.com> From: Carl Wallace To: Young H Etheridge Cc: ietf-ltans@imc.org Subject: RE: Clarification of ISO-IEC 18014 documents Date: Thu, 18 Jan 2007 07:26:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73AFB.D252139F" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73AFB.D252139F Content-Type: text/plain > -----Original Message----- > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > Sent: Wednesday, January 17, 2007 8:47 PM > Subject: Re: Clarification of ISO-IEC 18014 documents > > Yes, the spec is rather opaque in that regard. Fortunately, > 18014-1-revised will do so. > > It seems to me that aggregation would need to be built into > extRenewal or other EXTENSIONS in a standard way. So the ISO spec would need to be enhanced and ported into the IETF. ERS achieves these ends now and is already there. > I agree the opportunity for change has been waiting about for > well over a year. How many applications are ready for this > draft to be a standard? Several implementations have been cited on the list and at the WG meetings over the last year or so. There is also an XML version out there (Aleksej?). ------_=_NextPart_001_01C73AFB.D252139F Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Clarification of ISO-IEC 18014 documents

> -----Original Message-----
> From: Young H Etheridge [mailto:yhe@yhetheridge.org] =
> Sent: Wednesday, January 17, 2007 8:47 = PM
> Subject: Re: Clarification of ISO-IEC 18014 = documents
>
> Yes, the spec is rather opaque in that = regard.  Fortunately,
> 18014-1-revised will do so.
>
> It seems to me that aggregation would need to = be built into
> extRenewal or other EXTENSIONS in a standard = way.

So the ISO spec would need to be enhanced and ported = into the IETF.  ERS achieves these ends now and is already = there.
 
> I agree the opportunity for change has been = waiting about for
> well over a year.  How many applications = are ready for this
> draft to be a standard?

Several implementations have been cited on the list = and at the WG meetings over the last year or so.  There is also an = XML version out there (Aleksej?). 

------_=_NextPart_001_01C73AFB.D252139F-- 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 l0I1l3fH011680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 18:47:03 -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 l0I1l3X0011679; Wed, 17 Jan 2007 18:47:03 -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 burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0I1l12e011673 for ; Wed, 17 Jan 2007 18:47:02 -0700 (MST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.22] (ullapool.yandk.org [192.168.1.22]) by burrens.yandk.org (Postfix) with ESMTP id 26EFB164B2; Wed, 17 Jan 2007 20:47:01 -0500 (EST) Message-ID: <45AED195.8050708@yhetheridge.org> Date: Wed, 17 Jan 2007 20:47:01 -0500 From: Young H Etheridge User-Agent: Thunderbird 2.0b1 (X11/20061206) MIME-Version: 1.0 To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: Clarification of ISO-IEC 18014 documents References: <886F5D4C78AFB14D87261206BFB9612E1C41D89E@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1C41D89E@scygmxs1.cygnacom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, the spec is rather opaque in that regard. Fortunately, 18014-1-revised will do so. It seems to me that aggregation would need to be built into extRenewal or other EXTENSIONS in a standard way. I agree the opportunity for change has been waiting about for well over a year. How many applications are ready for this draft to be a standard? Carl Wallace wrote: > > I see. So it does address the coverage of original and current hashes > (if only the spec had included language about verification of > extRenewal I might have caught that). How about support for > aggregation? > > Aside from the technical bits, there's also the question of whether an > 11th hour request like this is justifiable. > > > -----Original Message----- > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > Sent: Wednesday, January 17, 2007 5:33 PM > > To: Carl Wallace > > Cc: ietf-ltans@imc.org > > Subject: Re: Clarification of ISO-IEC 18014 documents > > > > As I understand the process: > > > > A TSA that supports renewal requests, in response: > > - generates a new TSTInfo, > > - copies the hash value from the request into the TSTInfo, > > - copies the extRenewal extension from the request into an > > extRenewal > > extension of the TSTInfo with this extRenewal containing > > the desired > > original TS, > > - sets the current time and fills in the other fields of > > TSTInfo, and > > - proceeds to generate the renewal timestamp token for this TSTInfo. > > > > Unless I misunderstand the process this renewal timestamp > > token covers both the submitted hash value and the previous > > timestamp token regardless of the method is used by the TSA > > for generating the ContentInfo. > > > > This process is echoed in the revised 18014-1text. > > > > Carl Wallace wrote: > > > > > > In response to Denis' post, I reviewed the mechanisms in > > 18014-3. How > > > do those align with the text from -1? > > > > > > > -----Original Message----- > > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > > Sent: Wednesday, January 17, 2007 4:19 PM > > > > To: CWallace@cygnacom.com > > > > Cc: ietf-ltans@imc.org > > > > Subject: Clarification of ISO-IEC 18014 documents > > > > > > > > Carl, > > > > > > > > A clarification of the ISO 18014 documents may be useful. > > > > > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend > > TS renewal > > > > in the terms as expressed in WG communications of late. I quote: > > > > "A time­stamp re­issue may also be necessary when the > > hash-­function > > > > used to form the hash value from the original data is called into > > > > question. In this case, both the old time­stamp token and the > > > > original data must be included in the newly calculated hash value > > > > submitted for time­stamp reissue." > > > > > > > > A revision of 18014-1 is in-progress. The term reissue is being > > > > replaced with renewal along with descriptive information > > that makes > > > > the point clear that a renewal contains a hash of the data along > > > > with the hash of the original TS that is being renewed. The new > > > > description is quite clear in regard to creation and > > verification of > > > > renewal. > > > > > > > > Furthermore, ANSI X9.95 is consistent on renewal with > > those found in > > > > 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > > > > > > > I hope this helps. > > > > > > > > yhe > > > > > > > > > > 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 l0HMwnM0099617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 15:58:49 -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 l0HMwn3E099616; Wed, 17 Jan 2007 15:58:49 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0HMwki5099609 for ; Wed, 17 Jan 2007 15:58:47 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 21639 invoked from network); 17 Jan 2007 22:57:57 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;17 Jan 2007 22:57:57 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 17 Jan 2007 22:57:56 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Jan 2007 17:58:44 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D89E@scygmxs1.cygnacom.com> From: Carl Wallace To: Young H Etheridge Cc: ietf-ltans@imc.org Subject: RE: Clarification of ISO-IEC 18014 documents Date: Wed, 17 Jan 2007 17:58:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A8B.09A68792" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73A8B.09A68792 Content-Type: text/plain I see. So it does address the coverage of original and current hashes (if only the spec had included language about verification of extRenewal I might have caught that). How about support for aggregation? Aside from the technical bits, there's also the question of whether an 11th hour request like this is justifiable. > -----Original Message----- > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > Sent: Wednesday, January 17, 2007 5:33 PM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: Re: Clarification of ISO-IEC 18014 documents > > As I understand the process: > > A TSA that supports renewal requests, in response: > - generates a new TSTInfo, > - copies the hash value from the request into the TSTInfo, > - copies the extRenewal extension from the request into an > extRenewal > extension of the TSTInfo with this extRenewal containing > the desired > original TS, > - sets the current time and fills in the other fields of > TSTInfo, and > - proceeds to generate the renewal timestamp token for this TSTInfo. > > Unless I misunderstand the process this renewal timestamp > token covers both the submitted hash value and the previous > timestamp token regardless of the method is used by the TSA > for generating the ContentInfo. > > This process is echoed in the revised 18014-1text. > > Carl Wallace wrote: > > > > In response to Denis' post, I reviewed the mechanisms in > 18014-3. How > > do those align with the text from -1? > > > > > -----Original Message----- > > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > > Sent: Wednesday, January 17, 2007 4:19 PM > > > To: CWallace@cygnacom.com > > > Cc: ietf-ltans@imc.org > > > Subject: Clarification of ISO-IEC 18014 documents > > > > > > Carl, > > > > > > A clarification of the ISO 18014 documents may be useful. > > > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend > TS renewal > > > in the terms as expressed in WG communications of late. I quote: > > > "A time-stamp re-issue may also be necessary when the > hash--function > > > used to form the hash value from the original data is called into > > > question. In this case, both the old time-stamp token and the > > > original data must be included in the newly calculated hash value > > > submitted for time-stamp reissue." > > > > > > A revision of 18014-1 is in-progress. The term reissue is being > > > replaced with renewal along with descriptive information > that makes > > > the point clear that a renewal contains a hash of the data along > > > with the hash of the original TS that is being renewed. The new > > > description is quite clear in regard to creation and > verification of > > > renewal. > > > > > > Furthermore, ANSI X9.95 is consistent on renewal with > those found in > > > 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > > > > > I hope this helps. > > > > > > yhe > > > > > > ------_=_NextPart_001_01C73A8B.09A68792 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Clarification of ISO-IEC 18014 documents

I see.  So it does address the coverage of = original and current hashes (if only the spec had included language = about verification of extRenewal I might have caught that).  How = about support for aggregation? 

Aside from the technical bits, there's also the = question of whether an 11th hour request like this is justifiable. =

> -----Original Message-----
> From: Young H Etheridge [mailto:yhe@yhetheridge.org] =
> Sent: Wednesday, January 17, 2007 5:33 = PM
> To: Carl Wallace
> Cc: ietf-ltans@imc.org
> Subject: Re: Clarification of ISO-IEC 18014 = documents
>
> As I understand the process:
>
> A TSA that supports renewal requests, in = response:
>   - generates a new TSTInfo,
>   - copies the hash value from the = request into the TSTInfo,
>   - copies the extRenewal extension = from the request into an
> extRenewal
>     extension of the = TSTInfo with this extRenewal containing
> the desired
>     original TS,
>   - sets the current time and fills = in the other fields of
> TSTInfo, and
>   - proceeds to generate the renewal = timestamp token for this TSTInfo.
>
> Unless I misunderstand the process this renewal = timestamp
> token covers both the submitted hash value and = the previous
> timestamp token regardless of the method is = used by the TSA
> for generating the ContentInfo.
>
> This process is echoed in the revised = 18014-1text.
>
> Carl Wallace wrote:
> >
> > In response to Denis' post, I reviewed the = mechanisms in
> 18014-3.  How
> > do those align with the text from = -1?
> >
> > > -----Original Message-----
> > > From: Young H Etheridge [mailto:yhe@yhetheridge.org]
> > > Sent: Wednesday, January 17, 2007 = 4:19 PM
> > > To: CWallace@cygnacom.com
> > > Cc: ietf-ltans@imc.org
> > > Subject: Clarification of ISO-IEC = 18014 documents
> > >
> > > Carl,
> > >
> > > A clarification of the ISO 18014 = documents may be useful.
> > >
> > > ISO-IEC 18014-1-2002 uses the term TS = reissue to intend
> TS renewal
> > > in the terms as expressed in WG = communications of late.  I quote:
> > > "A time­stamp re­issue = may also be necessary when the
> hash-­function
> > > used to form the hash value from the = original data is called into
> > > question.  In this case, both = the old time­stamp token and the
> > > original data must be included in the = newly calculated hash value
> > > submitted for time­stamp = reissue."
> > >
> > > A revision of 18014-1 is = in-progress.  The term reissue is being
> > > replaced with renewal along with = descriptive information
> that makes
> > > the point clear that a renewal = contains a hash of the data along
> > > with the hash of the original TS that = is being renewed.  The new
> > > description is quite clear in regard = to creation and
> verification of
> > > renewal.
> > >
> > > Furthermore, ANSI X9.95 is consistent = on renewal with
> those found in
> > > 18014-2-2002, 18014-3-2004 and the = revision of 18014-1-2002.
> > >
> > > I hope this helps.
> > >
> > > yhe
> > >
> >
>

------_=_NextPart_001_01C73A8B.09A68792-- 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 l0HMWot9097943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 15:32:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HMWo6c097942; Wed, 17 Jan 2007 15:32:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HMWmCK097935 for ; Wed, 17 Jan 2007 15:32:49 -0700 (MST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.22] (ullapool.yandk.org [192.168.1.22]) by burrens.yandk.org (Postfix) with ESMTP id 75AED164D5; Wed, 17 Jan 2007 17:32:46 -0500 (EST) Message-ID: <45AEA40E.7010500@yhetheridge.org> Date: Wed, 17 Jan 2007 17:32:46 -0500 From: Young H Etheridge User-Agent: Thunderbird 2.0b1 (X11/20061206) MIME-Version: 1.0 To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: Clarification of ISO-IEC 18014 documents References: <886F5D4C78AFB14D87261206BFB9612E1C41D897@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1C41D897@scygmxs1.cygnacom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As I understand the process: A TSA that supports renewal requests, in response: - generates a new TSTInfo, - copies the hash value from the request into the TSTInfo, - copies the extRenewal extension from the request into an extRenewal extension of the TSTInfo with this extRenewal containing the desired original TS, - sets the current time and fills in the other fields of TSTInfo, and - proceeds to generate the renewal timestamp token for this TSTInfo. Unless I misunderstand the process this renewal timestamp token covers both the submitted hash value and the previous timestamp token regardless of the method is used by the TSA for generating the ContentInfo. This process is echoed in the revised 18014-1text. Carl Wallace wrote: > > In response to Denis' post, I reviewed the mechanisms in 18014-3. How > do those align with the text from -1? > > > -----Original Message----- > > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > > Sent: Wednesday, January 17, 2007 4:19 PM > > To: CWallace@cygnacom.com > > Cc: ietf-ltans@imc.org > > Subject: Clarification of ISO-IEC 18014 documents > > > > Carl, > > > > A clarification of the ISO 18014 documents may be useful. > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend TS > > renewal in the terms as expressed in WG communications of > > late. I quote: > > "A time­stamp re­issue may also be necessary when the > > hash-­function used to form the hash value from the original > > data is called into question. In this case, both the old > > time­stamp token and the original data must be included in > > the newly calculated hash value submitted for time­stamp reissue." > > > > A revision of 18014-1 is in-progress. The term reissue is > > being replaced with renewal along with descriptive > > information that makes the point clear that a renewal > > contains a hash of the data along with the hash of the > > original TS that is being renewed. The new description is > > quite clear in regard to creation and verification of renewal. > > > > Furthermore, ANSI X9.95 is consistent on renewal with those > > found in 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > > > I hope this helps. > > > > yhe > > > 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 l0HLPKar094433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 14:25:20 -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 l0HLPKEu094432; Wed, 17 Jan 2007 14:25:20 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0HLPHq8094425 for ; Wed, 17 Jan 2007 14:25:19 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 13601 invoked from network); 17 Jan 2007 21:24:14 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;17 Jan 2007 21:24:14 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 17 Jan 2007 21:24:13 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Jan 2007 16:25:01 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D897@scygmxs1.cygnacom.com> From: Carl Wallace To: Young H Etheridge Cc: ietf-ltans@imc.org Subject: RE: Clarification of ISO-IEC 18014 documents Date: Wed, 17 Jan 2007 16:25:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A7D.F20EC32C" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73A7D.F20EC32C Content-Type: text/plain In response to Denis' post, I reviewed the mechanisms in 18014-3. How do those align with the text from -1? > -----Original Message----- > From: Young H Etheridge [mailto:yhe@yhetheridge.org] > Sent: Wednesday, January 17, 2007 4:19 PM > To: CWallace@cygnacom.com > Cc: ietf-ltans@imc.org > Subject: Clarification of ISO-IEC 18014 documents > > Carl, > > A clarification of the ISO 18014 documents may be useful. > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend TS > renewal in the terms as expressed in WG communications of > late. I quote: > "A time-stamp re-issue may also be necessary when the > hash--function used to form the hash value from the original > data is called into question. In this case, both the old > time-stamp token and the original data must be included in > the newly calculated hash value submitted for time-stamp reissue." > > A revision of 18014-1 is in-progress. The term reissue is > being replaced with renewal along with descriptive > information that makes the point clear that a renewal > contains a hash of the data along with the hash of the > original TS that is being renewed. The new description is > quite clear in regard to creation and verification of renewal. > > Furthermore, ANSI X9.95 is consistent on renewal with those > found in 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. > > I hope this helps. > > yhe > ------_=_NextPart_001_01C73A7D.F20EC32C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Clarification of ISO-IEC 18014 documents

In response to Denis' post, I reviewed the mechanisms = in 18014-3.  How do those align with the text from -1?  =

> -----Original Message-----
> From: Young H Etheridge [mailto:yhe@yhetheridge.org] =
> Sent: Wednesday, January 17, 2007 4:19 = PM
> To: CWallace@cygnacom.com
> Cc: ietf-ltans@imc.org
> Subject: Clarification of ISO-IEC 18014 = documents
>
> Carl,
>
> A clarification of the ISO 18014 documents may = be useful.
>
> ISO-IEC 18014-1-2002 uses the term TS reissue = to intend TS
> renewal in the terms as expressed in WG = communications of
> late.  I quote: 
> "A time­stamp re­issue may also be = necessary when the
> hash-­function used to form the hash value = from the original
> data is called into question.  In this = case, both the old
> time­stamp token and the original data must = be included in
> the newly calculated hash value submitted for = time­stamp reissue."
>
> A revision of 18014-1 is in-progress.  The = term reissue is
> being replaced with renewal along with = descriptive
> information that makes the point clear that a = renewal
> contains a hash of the data along with the hash = of the
> original TS that is being renewed.  The = new description is
> quite clear in regard to creation and = verification of renewal.
>
> Furthermore, ANSI X9.95 is consistent on = renewal with those
> found in 18014-2-2002, 18014-3-2004 and the = revision of 18014-1-2002.
>
> I hope this helps.
>
> yhe
>

------_=_NextPart_001_01C73A7D.F20EC32C-- 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 l0HLIpli093973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 14:18:51 -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 l0HLIpRC093972; Wed, 17 Jan 2007 14:18:51 -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 burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HLIojr093966 for ; Wed, 17 Jan 2007 14:18:51 -0700 (MST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.22] (ullapool.yandk.org [192.168.1.22]) by burrens.yandk.org (Postfix) with ESMTP id B6B7A164D5; Wed, 17 Jan 2007 16:18:47 -0500 (EST) Message-ID: <45AE92B7.4070909@yhetheridge.org> Date: Wed, 17 Jan 2007 16:18:47 -0500 From: Young H Etheridge User-Agent: Thunderbird 2.0b1 (X11/20061206) MIME-Version: 1.0 To: CWallace@cygnacom.com Cc: ietf-ltans@imc.org Subject: Clarification of ISO-IEC 18014 documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, A clarification of the ISO 18014 documents may be useful. ISO-IEC 18014-1-2002 uses the term TS reissue to intend TS renewal in the terms as expressed in WG communications of late. I quote: "A time­stamp re­issue may also be necessary when the hash-­function used to form the hash value from the original data is called into question. In this case, both the old time­stamp token and the original data must be included in the newly calculated hash value submitted for time­stamp reissue." A revision of 18014-1 is in-progress. The term reissue is being replaced with renewal along with descriptive information that makes the point clear that a renewal contains a hash of the data along with the hash of the original TS that is being renewed. The new description is quite clear in regard to creation and verification of renewal. Furthermore, ANSI X9.95 is consistent on renewal with those found in 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002. I hope this helps. yhe 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 l0GG3L1Y068066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 09:03:21 -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 l0GG3LAG068064; Tue, 16 Jan 2007 09:03:21 -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 l0GG3ISF068053; Tue, 16 Jan 2007 09:03:19 -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 l0GG37lk029380; Tue, 16 Jan 2007 17:03:07 +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_01C73987.CF9C8287" Subject: RE: Cross review of draft ERS from LTANS WG until Jan 23 rd Date: Tue, 16 Jan 2007 17:03:06 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B3C9C@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cross review of draft ERS from LTANS WG until Jan 23 rd Thread-Index: Acc5hYz5NAgBpvv/Qy61Kh5xd84cXQAAGWEQ From: "Tobias Gondrom" To: "Denis Pinkas" , "Carl Wallace" , Cc: 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_01C73987.CF9C8287 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis, =20 Small comment:=20 I agree with, that ARI and validate is not mature. I agree that LTAP still needs some improvement for WGLC - though I believe it is in good shape. I obviously do not agree with that ERS is not mature.=20 And I totally disagree that ERS cannot be sent alone to the IESG.=20 =20 Concerning the last two disagreements:=20 1. As Carl already pointed out it seems there might be a misunderstanding of the relationship between ERS and REQS:=20 ERS is definitely not the complete answer to all requirements from REQS, but fulfils its part. Other things shall be defined by LTAP and some REQS may even be addressed at a later time (or only by individual implementations but not by an I-D). (The goal of REQS is to help choose the right technical solutions and approach by defining the objective targets for the specifications.) 2. ERS as the data structure for the records is valuable on its own and has with intent been only loosely coupled with LTAP. So we can progress ERS. This makes the work of the WG easier and more efficient as we then can focus on LTAP and ARI and validate (note: the last two are only intended to be informational). =20 Thanks, Tobias =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, January 16, 2007 4:32 PM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd =20 Carl, =20 I will have lo leave the discussion here for a few days, since I need to attend different meetings. =20 This leaves you more time to look again at the arguments explained in my three e-mails and to my proposal where the new proposed ASN.1 fulfils the LTANS requirements=20 whereas ERS does not. =20 I simply reiterate my position: =20 - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements.=20 - ERS is not mature. - LTAP is not mature. - ARI is not mature. - validate is not mature. - ERS needs major revisions.=20 - ERS cannot be sent alone to the IESG. =20 Denis =20 =20 ________________________________ inline... =20 =09 ________________________________ From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 Sent: Tuesday, January 16, 2007 3:27 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Russ Housley' Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd Carl, =20 ERS + LTAP do not meet the requirements.=20 [CRW] ERS is currently the focus. Not LTAP.=20 =20 =20 The archival policy, the archival time period and the crypto maintenance policy are never mentioned.=20 Since they are currently not part of ERS, they appear nowhere. [CRW] "Policy" is cited throughout and is included in the RequestInformation structure. "Archival policy" and "crypto maintenance policy" are not distinguished. They should be, but not in ERS. =20 It is never mentioned that a response is signed. =20 =20 ERS + LTAP contain no signature from a LTA agent.=20 [CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g. SignedData or EnvelopedData." =20 =20 About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that=20 the server does not maintain a trace record of the delete operation". A trace record would not be sufficient.=20 Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of=20 the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion=20 can occur. This is mentioned nowhere in the document. =20 [CRW] This should be added. =20 Once again, the current set of documents does not meet the requirements. =20 I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it.=20 [CRW] Most of your suggestions apply to a different document, in my opinion. I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer. Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance: =20 ArchiveTimeStamp ::=3D SEQUENCE {=20 digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,=20 reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,=20 attributes [2] Attributes OPTIONAL,=20 timeStamp ContentInfo}=20 =20 I think the other matters can and should be addressed in the context of LTAP. =20 Carl ________________________________ ------_=_NextPart_001_01C73987.CF9C8287 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Denis,

 

Small comment: =

I agree with, = that ARI and validate is not mature.

I agree that = LTAP still needs some improvement for WGLC – though I believe it is in good = shape.

I obviously do = not agree with that ERS is not mature.

And I totally = disagree that ERS cannot be sent alone to the IESG.

 =

Concerning the = last two disagreements:

1. As Carl = already pointed out it seems there might be a misunderstanding of the = relationship between ERS and REQS:

ERS is = definitely not the complete answer to all requirements from REQS, but fulfils its part. = Other things shall be defined by LTAP and some REQS may even be addressed at a = later time (or only by individual implementations but not by an I-D). (The = goal of REQS is to help choose the right technical solutions and approach by = defining the objective targets for the = specifications.)

2. ERS as the = data structure for the records is valuable on its own and has with intent = been only loosely coupled with LTAP. So we can progress ERS. This makes the work = of the WG easier and more efficient as we then can focus on LTAP and ARI and = validate (note: the last two are only intended to be = informational).

 =

Thanks, = Tobias

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Denis Pinkas
Sent: Tuesday, January = 16, 2007 4:32 PM
To: Carl Wallace; ietf-smime@imc.org
Cc: = ietf-ltans@imc.org
Subject: Re: Cross review = of draft ERS from LTANS WG until Jan 23 rd

 

Carl,

 

I will have lo leave the discussion here for a few days, since I = need to attend different meetings.

 

This leaves you more time to look again at the = arguments explained in my three e-mails
and to my proposal where the new proposed ASN.1 fulfils the LTANS = requirements
whereas ERS does not.

 

I simply reiterate my position:

 

 - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements. 

 - ERS is not mature.

 - LTAP is not mature.

 - ARI is not mature.

 - validate is not mature.

 - ERS needs major revisions.

 - ERS cannot be sent alone to the = IESG.

 

Denis  

 

inline...

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Tuesday, January = 16, 2007 3:27 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; = 'Russ Housley'
Subject: Re: Cross review = of draft ERS from LTANS WG until Jan 23 rd

Carl,

 

ERS + LTAP do not meet the requirements. 

[CRW] ERS is currently the = focus.  Not LTAP. 

 

 <snip> 

The archival policy, the archival time period and the crypto maintenance policy are never mentioned. =

Since they are currently not part of ERS, they appear = nowhere.

[CRW] "Policy" is cited throughout and is included in the RequestInformation structure.  "Archival policy" and "crypto maintenance policy" = are not distinguished.  They should be, but not in = ERS.

 

It is never mentioned that a response is = signed.  

 

ERS + LTAP contain no signature from a LTA = agent. 

[CRW] See the following in section = 8: "These data are optionally encapsulated by CMS content types that = provide for authentication and/or confidentiality, e.g.  SignedData or EnvelopedData."  =

 

About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that
the server does not maintain a trace record of the delete = operation". A trace record would not be sufficient.

Deletion of an archive shall normally not happen, since the LTA = is trusted to keep the data until the end of

the archive period. A signed permission of deletion, by the = owner of the data shall be given, before deletion

can occur. This is mentioned nowhere in the = document.

 

[CRW] This should be = added.

 

Once again, the current set of documents does not meet the requirements.

 

I guess you reacted too quickly to my proposal from = yesterday and you should pay more attention to it. 

[CRW] Most of your suggestions = apply to a different document, in my opinion.  I do think you were correct = w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp = layer.  Towards that end, my counter-proposal yesterday may serve us better = if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes = field, where policy could be an instance:

 

   ArchiveTimeStamp ::=3D = SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier = OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, 
     attributes     &nb= sp;    [2] Attributes OPTIONAL,
     timeStamp       ContentInfo}

 

I think the other matters can and = should be addressed in the context of LTAP.

 

Carl

------_=_NextPart_001_01C73987.CF9C8287-- 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 l0GFVnnt065623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 08:31:49 -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 l0GFVntJ065621; Tue, 16 Jan 2007 08:31:49 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0GFVlXn065609; Tue, 16 Jan 2007 08:31:48 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23248; Tue, 16 Jan 2007 16:35:20 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011616314066:14869 ; Tue, 16 Jan 2007 16:31:40 +0100 Date: Tue, 16 Jan 2007 16:31:38 +0100 From: "Denis Pinkas" To: "Carl Wallace" , "ietf-smime@imc.org" Cc: "ietf-ltans@imc.org" Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 16:31:40, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 16:31:43, Serialize complete at 16/01/2007 16:31:43 Message-ID: Content-Type: multipart/alternative; boundary="=====003_Dragon650452802867_=====" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --=====003_Dragon650452802867_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Carl, I will have lo leave the discussion here for a few days, since I need to attend different meetings. This leaves you more time to look again at the arguments explained in my three e-mails and to my proposal where the new proposed ASN.1 fulfils the LTANS requirements whereas ERS does not. I simply reiterate my position: - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements. - ERS is not mature. - LTAP is not mature. - ARI is not mature. - validate is not mature. - ERS needs major revisions. - ERS cannot be sent alone to the IESG. Denis inline... From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Tuesday, January 16, 2007 3:27 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Russ Housley' Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd Carl, ERS + LTAP do not meet the requirements. [CRW] ERS is currently the focus. Not LTAP. The archival policy, the archival time period and the crypto maintenance policy are never mentioned. Since they are currently not part of ERS, they appear nowhere. [CRW] "Policy" is cited throughout and is included in the RequestInformation structure. "Archival policy" and "crypto maintenance policy" are not distinguished. They should be, but not in ERS. It is never mentioned that a response is signed. ERS + LTAP contain no signature from a LTA agent. [CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g. SignedData or EnvelopedData." About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that the server does not maintain a trace record of the delete operation". A trace record would not be sufficient. Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion can occur. This is mentioned nowhere in the document. [CRW] This should be added. Once again, the current set of documents does not meet the requirements. I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. [CRW] Most of your suggestions apply to a different document, in my opinion. I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer. Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, attributes [2] Attributes OPTIONAL, timeStamp ContentInfo} I think the other matters can and should be addressed in the context of LTAP. Carl --=====003_Dragon650452802867_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="iso-8859-1"
Carl,
 
I will have lo leave the discussion here for a few days, since I need to attend different meetings.
 
This leaves you more time to look again at the arguments explained in my three e-mails
and to my proposal where the new proposed ASN.1 fulfils the LTANS requirements
whereas ERS does not.
 
I simply reiterate my position:
 
 - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements. 
 - ERS is not mature.
 - LTAP is not mature.
 - ARI is not mature.
 - validate is not mature.
 - ERS needs major revisions.
 - ERS cannot be sent alone to the IESG.
 
Denis  
 
inline...

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Tuesday, January 16, 2007 3:27 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; 'Russ Housley'
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd

Carl,
 
ERS + LTAP do not meet the requirements. 
[CRW] ERS is currently the focus.  Not LTAP. 
 
 <snip> 
The archival policy, the archival time period and the crypto maintenance policy are never mentioned.
Since they are currently not part of ERS, they appear nowhere.
[CRW] "Policy" is cited throughout and is included in the RequestInformation structure.  "Archival policy" and "crypto maintenance policy" are not distinguished.  They should be, but not in ERS.
 
It is never mentioned that a response is signed.  
 
ERS + LTAP contain no signature from a LTA agent. 
[CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g.  SignedData or EnvelopedData." 
 
About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that
the server does not maintain a trace record of the delete operation". A trace record would not be sufficient.
Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of
the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion
can occur. This is mentioned nowhere in the document.
 
[CRW] This should be added.
 
Once again, the current set of documents does not meet the requirements.
 
I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. 
[CRW] Most of your suggestions apply to a different document, in my opinion.  I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer.  Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance:
 
   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, 
     attributes          [2] Attributes OPTIONAL,
     timeStamp       ContentInfo}
 
I think the other matters can and should be addressed in the context of LTAP.
 
Carl
--=====003_Dragon650452802867_=====-- 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 l0GFV0ud065563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 08:31:00 -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 l0GFV0Bk065561; Tue, 16 Jan 2007 08:31:00 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0GFUv0P065547; Tue, 16 Jan 2007 08:30:58 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23200; Tue, 16 Jan 2007 16:34:32 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011616305514:14813 ; Tue, 16 Jan 2007 16:30:55 +0100 Date: Tue, 16 Jan 2007 16:30:51 +0100 From: "Denis Pinkas" To: "Peter Sylvester" Cc: "ietf-smime@imc.org" , "ietf-ltans@imc.org" Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 16:30:55, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 16:30:55, Serialize complete at 16/01/2007 16:30:55 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, You said: >The details how a delete request is authenticated is outside of scope of >LTAP as well as management of ownerships etc. Many aspects seem to be outside the scope of the document, whereas they should not.. >A trace record means: "At this place there had been some data which can >be described by (list of some metadata), >they had been deleted (metadata about that fact)." It is not the backend >LTA that creates all these metedata, >the frontend that authenticates the request prepares some of them. The >LTA does not make complicated decisions. A trace record from the LTA would be insufficient in case of a dispute. An LTA is providing a service for someone. An LTA has to be made responsible of its actions, and therfor must give back some proof for each deposit or for an addition to a former deposit. In case the owner of the data decides to shorten the original archival time period (BTW mentioned nowhere in ERS or in LTAP), then the LTA must be able to present some proof of that will, otherwise the owner of the data could pretend that the archive was deleted by the LTA before the end of the original archival period. (text deleted) Denis >Peter 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 l0GDt4rg055484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 06:55:05 -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 l0GDt4sR055482; Tue, 16 Jan 2007 06:55: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0GDt2cO055470; Tue, 16 Jan 2007 06:55:03 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l0GDsj510900; Tue, 16 Jan 2007 14:54:45 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 16 Jan 2007 14:54:49 +0100 (MET) Message-ID: <45ACD8AA.5040009@edelweb.fr> Date: Tue, 16 Jan 2007 14:52:42 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace CC: Denis Pinkas , ietf-smime@imc.org, ietf-ltans@imc.org, "'Russ Housley'" Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd References: <886F5D4C78AFB14D87261206BFB9612E1C41D7DD@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1C41D7DD@scygmxs1.cygnacom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030007080403040006090406" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030007080403040006090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > [CRW] ERS is currently the focus. Not LTAP. > Right. > > ERS + LTAP contain no signature from a LTA agent. > [CRW] See the following in section 8: "These data are optionally > encapsulated by CMS content types that provide for authentication > and/or confidentiality, e.g. SignedData or EnvelopedData." > > About the DELETE operation, what is worse is the following > sentence: "Note that this does not mean that > the server does not maintain a trace record of the delete > operation". A trace record would not be sufficient. > Deletion of an archive shall normally not happen, since the LTA is > trusted to keep the data until the end of > the archive period. A signed permission of deletion, by the owner > of the data shall be given, before deletion > can occur. This is mentioned nowhere in the document. > > [CRW] This should be added. > The details how a delete request is authenticated is outside of scope of LTAP as well as management of ownerships etc. A trace record means: "At this place there had been some data which can be described by (list of some metadata), they had been deleted (metadata about that fact)." It is not the backend LTA that creates all these metedata, the frontend that authenticates the request prepares some of them. The LTA does not make complicated decisions. An example of a higher level front end protocol on can take something like the French proposal of the National Archives. Peter --------------ms030007080403040006090406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE2MTM1MjQyWjAjBgkqhkiG9w0B CQQxFgQUYX3Hev9Buectqc2RAc12OApMIJowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA5a/FVmsMc+QILj/f MYZJAS5jpI2EdUOLw+Ds4FVbPoYxyRQx8hqFeVNlaHqL8dwirf15xjidONU0+N2bDw3U3x5q aiBKzlQ6Du1PGm/upEBWaC7wtTX90N2XKRNi1zQ/cAIJ5RPt1g1U36mFOK/2jyGtUbAh/Ijn IH4v47ENZ5sAAAAAAAA= --------------ms030007080403040006090406-- 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 l0GBcmeo042621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 04:38:48 -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 l0GBcmUw042619; Tue, 16 Jan 2007 04:38:48 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0GBckqx042605 for ; Tue, 16 Jan 2007 04:38:46 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 6943 invoked from network); 16 Jan 2007 11:38:00 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Jan 2007 11:38:00 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 16 Jan 2007 11:37:59 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Jan 2007 06:38:45 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D7DD@scygmxs1.cygnacom.com> From: Carl Wallace To: Denis Pinkas , ietf-smime@imc.org Cc: ietf-ltans@imc.org, "'Russ Housley'" Subject: RE: Cross review of draft ERS from LTANS WG until Jan 23 rd Date: Tue, 16 Jan 2007 06:38:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73962.E0FD5E36" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73962.E0FD5E36 Content-Type: text/plain inline... _____ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Tuesday, January 16, 2007 3:27 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Russ Housley' Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd Carl, ERS + LTAP do not meet the requirements. [CRW] ERS is currently the focus. Not LTAP. The archival policy, the archival time period and the crypto maintenance policy are never mentioned. Since they are currently not part of ERS, they appear nowhere. [CRW] "Policy" is cited throughout and is included in the RequestInformation structure. "Archival policy" and "crypto maintenance policy" are not distinguished. They should be, but not in ERS. It is never mentioned that a response is signed. ERS + LTAP contain no signature from a LTA agent. [CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g. SignedData or EnvelopedData." About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that the server does not maintain a trace record of the delete operation". A trace record would not be sufficient. Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion can occur. This is mentioned nowhere in the document. [CRW] This should be added. Once again, the current set of documents does not meet the requirements. I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. [CRW] Most of your suggestions apply to a different document, in my opinion. I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer. Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, attributes [2] Attributes OPTIONAL, timeStamp ContentInfo} I think the other matters can and should be addressed in the context of LTAP. Carl ------_=_NextPart_001_01C73962.E0FD5E36 Content-Type: text/html
inline...

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Tuesday, January 16, 2007 3:27 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; 'Russ Housley'
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd

Carl,
 
ERS + LTAP do not meet the requirements. 
[CRW] ERS is currently the focus.  Not LTAP. 
 
 <snip> 
The archival policy, the archival time period and the crypto maintenance policy are never mentioned.
Since they are currently not part of ERS, they appear nowhere.
[CRW] "Policy" is cited throughout and is included in the RequestInformation structure.  "Archival policy" and "crypto maintenance policy" are not distinguished.  They should be, but not in ERS.
 
It is never mentioned that a response is signed.  
 
ERS + LTAP contain no signature from a LTA agent. 
[CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g.  SignedData or EnvelopedData." 
 
About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that
the server does not maintain a trace record of the delete operation". A trace record would not be sufficient.
Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of
the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion
can occur. This is mentioned nowhere in the document.
 
[CRW] This should be added.
 
Once again, the current set of documents does not meet the requirements.
 
I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. 
[CRW] Most of your suggestions apply to a different document, in my opinion.  I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer.  Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance:
 
   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, 
     attributes          [2] Attributes OPTIONAL,
     timeStamp       ContentInfo}
 
I think the other matters can and should be addressed in the context of LTAP.
 
Carl
------_=_NextPart_001_01C73962.E0FD5E36-- 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 l0G8RRud025763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 01:27:28 -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 l0G8RRQS025762; Tue, 16 Jan 2007 01:27:27 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0G8ROi4025748; Tue, 16 Jan 2007 01:27:25 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA12628; Tue, 16 Jan 2007 09:30:51 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011609271344:3931 ; Tue, 16 Jan 2007 09:27:13 +0100 Date: Tue, 16 Jan 2007 09:27:08 +0100 From: "Denis Pinkas" To: "Carl Wallace" , "ietf-smime@imc.org" Cc: "ietf-ltans@imc.org" , "'Russ Housley'" Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 09:27:13, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/01/2007 09:27:15, Serialize complete at 16/01/2007 09:27:15 Message-ID: Content-Type: multipart/alternative; boundary="=====003_Dragon304872843802_=====" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --=====003_Dragon304872843802_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Carl, ERS + LTAP do not meet the requirements. In order to understand LTAP, there is the need to wait until page 28, where the operations are only sketched : - The ARCHIVE operation applies to "rawData and a messageDigest" without any information on these two pieces of information and their relationship, if any, with ERS. - The STATUS operation is hardly defined. - The EXPORT operation returns "data and metadata of the object" without any information on these two pieces of information and their relationship, if any, with ERS. - The DELETE operation "returns the updated metadata (or nothing)" without any information on this piece of information and its relationship, if any, with ERS. The archival policy, the archival time period and the crypto maintenance policy are never mentioned. Since they are currently not part of ERS, they appear nowhere. It is never mentioned that a response is signed. ERS + LTAP contain no signature from a LTA agent. About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that the server does not maintain a trace record of the delete operation". A trace record would not be sufficient. Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion can occur. This is mentioned nowhere in the document. Once again, the current set of documents does not meet the requirements. I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. Denis Denis, Thanks for the analysis. Regarding: ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ? We've been proceeding with ERS + LTAP intended to meet the requirements, not ERS in isolation. Thus, some of the information you mentioned is addressed at the protocol level, not in the evidence record. I think this is certainly true of items 1, 2 and 4. For item 3, the service can provide the evidence without contributing signatures to the evidence record. It simply has to be trusted to take the appropriate renewal actions at the right times. For item 7, the period is implied by the time in the innermost timestamp and the outermost timestamp and the evidence record is itself the evidence being provided. For items 5 and 6, I agree that the ArchiveTimestamp is probably the best place to represent the policies to meet this requirement. Since these values can change over time, they are not as easily represented in an outer wrapper applied at the protocol level. Perhaps the following: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, policy [1] OBJECT IDENTIFIER OPTIONAL, timeStamp ContentInfo} Using this structure, the policy would be asserted when a renewal is performed. Carl ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Monday, January 15, 2007 9:59 AM To: ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Russ Housley' Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd I said in an earlier e-mail: "The WG has to justify why it would not fulfill its needs". Carl has provided interesting information to explain the differences with ISO ISO-18014-3 and why ERS is different. The main advantage is the use of "ordinary" time-stamps rather than time-stamps with specific extensions. However, this information should not be lost and be used to write an informative annex. There are indeed much more important topics. ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ? However, many of the requirements that are present in the requirements document are not met by the current ERS draft. Here are a few examples : 1. ltans-reqs-10 defines an Archival Period as "The period during which an archived data object is preserved by a long-term archive service". How may a long term-archive service be held responsible of storing the data during that time-period, since the information to know the time period is not present in the ER ? 2. ltans-reqs-10 defines a Cryp! tographic Maintenance Policy. There is no corresponding element in ERS. How can a long term-archive service know which maintenance to apply, since the information to perform the maintenance correctly is not present in ER ? 3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence that may be used to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time. The ER is supposed to be the basic piece of data to support that evidence. However, it is not signed by the long term-archive service, thus it cannot be used "to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time". 4. ltans-reqs-10 adds on page 7: "Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object". However, ER does not contain the names of the LTA(s) that have participated in the preservation of the archived data object. 5. ltans-reqs-10 states on page 9: "A long-term archive service must operate in accordance with a long-term archive service policy that defines characteristics of the implementation of the long-term archive service". However, ER does not contain a data item to support the "long-term archive service policy". 6. ltans-reqs-10 adds on page 10: " Over the course of many years, the policies under which an LTA operates may undergo modification. Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object." However, the ER does not contain such an information. 7. ltans-reqs-10 states on page 11: "A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible from the time it received the data until the expiration of the archival period of the data". However, no data item is specified in ER to provide this evidence. This means that much work is still needed on the document to fulfill the requirements. Now, let us see what should be done. The following is obviously an unpolished strawman proposal. In order to reduce the number of time stamps, it is necessary to be able to aggregate data before applying a time stamp on it. For doing it, the following structure (close to the structure of ArchiveTimeStamp, but different) would fulfill the need). TimeStampedNode ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, reducedHashtree SEQUENCE OF PartialHashtree, timeStamp TimeStampToken } PartialHashtree ::= SEQUENCE OF OCTET STRING ArchivalPolicy::= OBJECT IDENTIFIER ArchivalTimePeriod ::= SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime } CryptoMaintenancePolicy would need more work to be defined, but basically would contain a sequence of algorithm identifiers with their parameters. The CryptoMaintenancePolicy applies to the data in the tree and to the crypto of the time stamp token. The hash included in the TimeStampToken is computed on the reducedHashtree element. If this structure is signed by an agent from an archival service, then it can be used to demonstrate that a given agent from an LTA has accepted to archive, under a given policy for a given time period, the data items that are under the hash tree. This means that TimeStampedNode must be the eContent of a CMS message signed by an LTA agent in order to form a SignedNode. Later on, the same, another or more LTA agents may need to add some other data to a signed Node, without loosing the previous time-stamp and signature. This leads to the following structure: EvidenceNode ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, evidenceRecord EvidenceRecord, -- the evidence record that serves -- for the construction signedNodeSequence SignedNodeSequence OPTIONAL, -- the elements that are added -- to the previous evidence timeStamp TimeStampToken } with: signedNodeSequence ::= SEQUENCE OF SignedNode The CryptoMaintenancePolicy applies to the previous evidence record, to all the data that are in the tree and to the crypto of the time stamp token. The hash included in the TimeStampToken is computed on the concatenation of the evidenceRecord element and of the signedNodeSequence element. This means that EvidenceNode must be the eContent of a CMS message signed by an LTA agent in order to form an EvidenceRecord. This new proposal fulfills the seven requirements mentioned here above. Denis ________________________________ Tony, I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis. However, I'll try to make the case in the other direction. I don't think it's simply a case of too many options that require profiling. One motivation often cited during the development of ERS is support for aggregations of data. This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure. This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again. The ISO spec uses the ExtRenewal extension for timestamp renewal. This is roughly analogous to the timestamp renewal feature in ERS. However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed. In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data. In the ISO spec, an existing timestamp token is presented for renewal but the original data is not. It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension). I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS. ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations. For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec. Carl ________________________________ From: Tony Capel [mailto:capel@comgate.com] Sent: Thursday, January 11, 2007 11:04 AM To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl: I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed). Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind. In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology. Tony -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for details. Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord. You made a sweeping comment that lacked any details and called for fairly drastic measures. I simply asked for justification. ________________________________ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis ________________________________ --=====003_Dragon304872843802_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="iso-8859-1"
Carl,
 
ERS + LTAP do not meet the requirements.
 
In order to understand LTAP, there is the need to wait until page 28,
where the operations are only sketched :
 
- The ARCHIVE operation applies to "rawData and a messageDigest"
   without any information on these two pieces of information and
   their relationship, if any, with ERS.
 
 - The STATUS operation is hardly defined.
 
 - The EXPORT operation returns "data and metadata of the object"
   without any information on these two pieces of information and
   their relationship, if any, with ERS.
 
 - The DELETE operation "returns the updated metadata (or nothing)"
   without any information on this piece of information and its relationship,
   if any, with ERS.
 
The archival policy, the archival time period and the crypto maintenance policy are never mentioned.
Since they are currently not part of ERS, they appear nowhere.
 
It is never mentioned that a response is signed.
 
ERS + LTAP contain no signature from a LTA agent.
 
About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that
the server does not maintain a trace record of the delete operation". A trace record would not be sufficient.
Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of
the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion
can occur. This is mentioned nowhere in the document.
 
Once again, the current set of documents does not meet the requirements.
 
I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it.
 
Denis
 

Denis,
 
Thanks for the analysis.  Regarding:
 
ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?
 
We've been proceeding with ERS + LTAP intended to meet the requirements, not ERS in isolation.  Thus, some of the information you mentioned is addressed at the protocol level, not in the evidence record.  I think this is certainly true of items 1, 2 and 4.  For item 3, the service can provide the evidence without contributing signatures to the evidence record.  It simply has to be trusted to take the appropriate renewal actions at the right times.  For item 7, the period is implied by the time in the innermost timestamp and the outermost timestamp and the evidence record is itself the evidence being provided.


For items 5 and 6, I agree that the ArchiveTimestamp is probably the best place to represent the policies to meet this requirement.  Since these values can change over time, they are not as easily represented in an outer wrapper applied at the protocol level.  Perhaps the following:


   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
     policy          [1] OBJECT IDENTIFIER OPTIONAL,
     timeStamp       ContentInfo}

Using this structure, the policy would be asserted when a renewal is performed.
 
Carl


________________________________

        From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas
        Sent: Monday, January 15, 2007 9:59 AM
        To: ietf-smime@imc.org
        Cc: ietf-ltans@imc.org; 'Russ Housley'
        Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd
       
       

        I said in an earlier e-mail: "The WG has to justify why it would not fulfill its needs".

        Carl has provided interesting information to explain the differences with ISO ISO-18014-3

        and why ERS is different. The main advantage is the use of "ordinary" time-stamps rather

        than time-stamps with specific extensions. However, this information should not be lost

        and be used to write an informative annex.

        

        There are indeed much more important topics.

        

        ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?

        

        However, many of the requirements that are present in the requirements document

        are not met by the current ERS draft.

        

        Here are a few examples :

                1. ltans-reqs-10 defines an Archival Period as "The period during which an archived
        data object is preserved by a long-term archive service". How may a long term-archive
        service be held responsible of storing the data during that time-period, since
        the information to know the time period is not present in the ER ?
                2. ltans-reqs-10 defines a Cryp!
        tographic Maintenance Policy. There is no corresponding
        element in ERS. How can a long term-archive service know which maintenance to apply,
        since the information to perform the maintenance correctly is not present in ER ?

                3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence
        that may be used to demonstrate the existence of an archived data object at a given time
        and the integrity of the archived data object since that time. The ER is supposed
        to be the basic piece of data to support that evidence. However, it is not signed
        by the long term-archive service, thus it cannot be used "to demonstrate the existence
        of an archived data object at a given time and the integrity of the archived data object
        since that time".
                4. ltans-reqs-10 adds on page 7: "Additionally, the evidence identifies the LTA(s)
        that have participated in the preservation of the archived data object". However,
        ER does not contain the names of the LTA(s) that have participated in the preservation
        of the archived data object.
                5. ltans-reqs-10 states on page 9: "A long-term archive service must operate in accordance
        with a long-term archive service policy that defines characteristics of the implementation
        of the long-term archive service". However, ER does not contain a data item to support
        the "long-term archive service policy".
                6. ltans-reqs-10 adds on page 10: " Over the course of many years, the policies under which
        an LTA operates may undergo modification.  Thus, an evidence record may feature multiple
        indications of policies active at various points during the life of an archived data object."
        However, the ER does not contain such an information.

                7. ltans-reqs-10 states on page 11: "A long-term archive service must be capable of providing
        evidence that can be used to demonstrate the integrity of data for which it is responsible
        from the time it received the data until the expiration of the archival period of the data".
        However, no data item is specified in ER to provide this evidence.
       
        This means that much work is still needed on the document to fulfill the requirements.

        

        Now, let us see what should be done. The following is obviously an unpolished strawman proposal.

        

        In order to reduce the number of time stamps, it is necessary to be able to aggregate data
        before applying a time stamp on it. For doing it, the following structure (close to the
        structure of ArchiveTimeStamp, but different) would fulfill the need).

        

           TimeStampedNode ::= SEQUENCE {

             digestAlgorithm        [0] AlgorithmIdentifier OPTIONAL,

             archivalPolicy             ArchivalPolicy,

             archivalTimePeriod         ArchivalTimePeriod,

             cryptoMaintenancePolicy    CryptoMaintenancePolicy,

             reducedHashtree            SEQUENCE OF PartialHashtree,

             timeStamp                  TimeStampToken }

        

           PartialHashtree ::= SEQUENCE OF OCTET STRING

        

           ArchivalPolicy::= OBJECT IDENTIFIER

                

           ArchivalTimePeriod ::= SEQUENCE {

                notBefore      GeneralizedTime,

                notAfter       GeneralizedTime }

                

        CryptoMaintenancePolicy would need more work to be defined, but basically
        would contain a sequence of algorithm identifiers with their parameters.

                

        The CryptoMaintenancePolicy applies to the data in the tree and to the crypto of
        the time stamp token.

        

        The hash included in the TimeStampToken is computed on the reducedHashtree element.

        

        If this structure is signed by an agent from an archival service, then it can be used
        to demonstrate that a given agent from an LTA has accepted to archive, under a given
        policy for a given time period, the data items that are under the hash tree.

        

        This means that TimeStampedNode must be the eContent of a CMS message signed by
        an LTA agent in order to form a SignedNode.

        

        Later on, the same, another or more LTA agents may need to add some other data to
        a signed Node, without loosing the previous time-stamp and signature.

        

        This leads to the following structure:

        

           EvidenceNode ::= SEQUENCE {

              version                        INTEGER { v1(1) } ,

              digestAlgorithms               SEQUENCE OF AlgorithmIdentifier,

              archivalPolicy                 ArchivalPolicy,

              archivalTimePeriod             ArchivalTimePeriod,

              cryptoMaintenancePolicy        CryptoMaintenancePolicy,

              evidenceRecord                 EvidenceRecord,

                                             -- the evidence record that serves

                                             -- for the construction

              signedNodeSequence             SignedNodeSequence   OPTIONAL,

                                             -- the elements that are added

                                             -- to the previous evidence

              timeStamp                      TimeStampToken }

        

        with:

        

           signedNodeSequence ::= SEQUENCE OF SignedNode

        

        The CryptoMaintenancePolicy applies to the previous evidence record, to all
        the data that are in the tree and to the crypto of the time stamp token.

        

        The hash included in the TimeStampToken is computed on the concatenation of the
        evidenceRecord element and of the signedNodeSequence element.

        

        This means that EvidenceNode must be the eContent of a CMS message signed by
        an LTA agent in order to form an EvidenceRecord.

        

        This new proposal fulfills the seven requirements mentioned here above.

        

        Denis

        

________________________________

                Tony,
        
        I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis.  However, I'll try to make the case in the other direction.

        
                I don't think it's simply a case of too many options that require profiling.  One motivation often cited during the development of ERS is support for aggregations of data.  This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure.  This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again.

        
        The ISO spec uses the ExtRenewal extension for timestamp renewal.  This is roughly analogous to the timestamp renewal feature in ERS.  However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed.  In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data.  In the ISO spec, an existing timestamp token is presented for renewal but the original data is not.  It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension).  I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS. 

        
        ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations.  For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec.

        
        Carl


________________________________

                From: Tony Capel [mailto:capel@comgate.com]
                Sent: Thursday, January 11, 2007 11:04 AM
                To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
                Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley'
                Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

               
               
                Carl:
                
                I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed).

                
                Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind.  In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology.

                
                Tony

                

                -----Original Message-----
                From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace
                Sent: January 11, 2007 10:16 AM
                To: Denis Pinkas; ietf-smime@imc.org
                Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley
                Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

               
               
                My response wasn't a reversal of the question but a request for details.  Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord.  You made a sweeping comment that lacked any details and called for fairly drastic measures.  I simply asked for justification.


________________________________

                        From: Denis Pinkas [mailto:denis.pinkas@bull.net]
                        Sent: Thursday, January 11, 2007 9:46 AM
                        To: Carl Wallace; ietf-smime@imc.org
                        Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
                        Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

                       
                       
                        Carl,
                        
                        Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.

                        I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
                        A profile would make sense, since ISO 18014-3 has many options.
                        
                        Denis

________________________________

--=====003_Dragon304872843802_=====-- 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 l0FFkOS5046448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 08:46:24 -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 l0FFkOM1046447; Mon, 15 Jan 2007 08:46:24 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0FFkMWb046435 for ; Mon, 15 Jan 2007 08:46:23 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 12432 invoked from network); 15 Jan 2007 15:45:27 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Jan 2007 15:45:27 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 15 Jan 2007 15:45:26 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Jan 2007 10:46:10 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D79E@scygmxs1.cygnacom.com> From: Carl Wallace To: Denis Pinkas , ietf-smime@imc.org Cc: ietf-ltans@imc.org, "'Russ Housley'" Subject: RE: Cross review of draft ERS from LTANS WG until Jan 23 rd Date: Mon, 15 Jan 2007 10:46:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C738BC.41E169EE" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C738BC.41E169EE Content-Type: text/plain Denis, Thanks for the analysis. Regarding: ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ? We've been proceeding with ERS + LTAP intended to meet the requirements, not ERS in isolation. Thus, some of the information you mentioned is addressed at the protocol level, not in the evidence record. I think this is certainly true of items 1, 2 and 4. For item 3, the service can provide the evidence without contributing signatures to the evidence record. It simply has to be trusted to take the appropriate renewal actions at the right times. For item 7, the period is implied by the time in the innermost timestamp and the outermost timestamp and the evidence record is itself the evidence being provided. For items 5 and 6, I agree that the ArchiveTimestamp is probably the best place to represent the policies to meet this requirement. Since these values can change over time, they are not as easily represented in an outer wrapper applied at the protocol level. Perhaps the following: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, policy [1] OBJECT IDENTIFIER OPTIONAL, timeStamp ContentInfo} Using this structure, the policy would be asserted when a renewal is performed. Carl ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Monday, January 15, 2007 9:59 AM To: ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Russ Housley' Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd I said in an earlier e-mail: "The WG has to justify why it would not fulfill its needs". Carl has provided interesting information to explain the differences with ISO ISO-18014-3 and why ERS is different. The main advantage is the use of "ordinary" time-stamps rather than time-stamps with specific extensions. However, this information should not be lost and be used to write an informative annex. There are indeed much more important topics. ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ? However, many of the requirements that are present in the requirements document are not met by the current ERS draft. Here are a few examples : 1. ltans-reqs-10 defines an Archival Period as "The period during which an archived data object is preserved by a long-term archive service". How may a long term-archive service be held responsible of storing the data during that time-period, since the information to know the time period is not present in the ER ? 2. ltans-reqs-10 defines a Cryp! tographic Maintenance Policy. There is no corresponding element in ERS. How can a long term-archive service know which maintenance to apply, since the information to perform the maintenance correctly is not present in ER ? 3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence that may be used to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time. The ER is supposed to be the basic piece of data to support that evidence. However, it is not signed by the long term-archive service, thus it cannot be used "to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time". 4. ltans-reqs-10 adds on page 7: "Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object". However, ER does not contain the names of the LTA(s) that have participated in the preservation of the archived data object. 5. ltans-reqs-10 states on page 9: "A long-term archive service must operate in accordance with a long-term archive service policy that defines characteristics of the implementation of the long-term archive service". However, ER does not contain a data item to support the "long-term archive service policy". 6. ltans-reqs-10 adds on page 10: " Over the course of many years, the policies under which an LTA operates may undergo modification. Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object." However, the ER does not contain such an information. 7. ltans-reqs-10 states on page 11: "A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible from the time it received the data until the expiration of the archival period of the data". However, no data item is specified in ER to provide this evidence. This means that much work is still needed on the document to fulfill the requirements. Now, let us see what should be done. The following is obviously an unpolished strawman proposal. In order to reduce the number of time stamps, it is necessary to be able to aggregate data before applying a time stamp on it. For doing it, the following structure (close to the structure of ArchiveTimeStamp, but different) would fulfill the need). TimeStampedNode ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, reducedHashtree SEQUENCE OF PartialHashtree, timeStamp TimeStampToken } PartialHashtree ::= SEQUENCE OF OCTET STRING ArchivalPolicy::= OBJECT IDENTIFIER ArchivalTimePeriod ::= SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime } CryptoMaintenancePolicy would need more work to be defined, but basically would contain a sequence of algorithm identifiers with their parameters. The CryptoMaintenancePolicy applies to the data in the tree and to the crypto of the time stamp token. The hash included in the TimeStampToken is computed on the reducedHashtree element. If this structure is signed by an agent from an archival service, then it can be used to demonstrate that a given agent from an LTA has accepted to archive, under a given policy for a given time period, the data items that are under the hash tree. This means that TimeStampedNode must be the eContent of a CMS message signed by an LTA agent in order to form a SignedNode. Later on, the same, another or more LTA agents may need to add some other data to a signed Node, without loosing the previous time-stamp and signature. This leads to the following structure: EvidenceNode ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, evidenceRecord EvidenceRecord, -- the evidence record that serves -- for the construction signedNodeSequence SignedNodeSequence OPTIONAL, -- the elements that are added -- to the previous evidence timeStamp TimeStampToken } with: signedNodeSequence ::= SEQUENCE OF SignedNode The CryptoMaintenancePolicy applies to the previous evidence record, to all the data that are in the tree and to the crypto of the time stamp token. The hash included in the TimeStampToken is computed on the concatenation of the evidenceRecord element and of the signedNodeSequence element. This means that EvidenceNode must be the eContent of a CMS message signed by an LTA agent in order to form an EvidenceRecord. This new proposal fulfills the seven requirements mentioned here above. Denis ________________________________ Tony, I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis. However, I'll try to make the case in the other direction. I don't think it's simply a case of too many options that require profiling. One motivation often cited during the development of ERS is support for aggregations of data. This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure. This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again. The ISO spec uses the ExtRenewal extension for timestamp renewal. This is roughly analogous to the timestamp renewal feature in ERS. However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed. In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data. In the ISO spec, an existing timestamp token is presented for renewal but the original data is not. It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension). I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS. ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations. For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec. Carl ________________________________ From: Tony Capel [mailto:capel@comgate.com] Sent: Thursday, January 11, 2007 11:04 AM To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl: I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed). Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind. In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology. Tony -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for details. Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord. You made a sweeping comment that lacked any details and called for fairly drastic measures. I simply asked for justification. ________________________________ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis ________________________________ ------_=_NextPart_001_01C738BC.41E169EE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cross review of draft ERS from LTANS WG until Jan 23 = rd

Denis,
 
Thanks for the analysis.  Regarding:
 
ERS is supposed to respond to = draft-ietf-ltans-reqs-10.txt, isn'it ?
 
We've been proceeding with ERS + LTAP intended to = meet the requirements, not ERS in isolation.  Thus, some of the = information you mentioned is addressed at the protocol level, not in = the evidence record.  I think this is certainly true of items 1, 2 = and 4.  For item 3, the service can provide the evidence without = contributing signatures to the evidence record.  It simply has to = be trusted to take the appropriate renewal actions at the right = times.  For item 7, the period is implied by the time in the = innermost timestamp and the outermost timestamp and the evidence record = is itself the evidence being provided.

 
For items 5 and 6, I agree that the ArchiveTimestamp = is probably the best place to represent the policies to meet this = requirement.  Since these values can change over time, they are = not as easily represented in an outer wrapper applied at the protocol = level.  Perhaps the following:

 
   ArchiveTimeStamp ::=3D SEQUENCE = {
     digestAlgorithm [0] = AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] = SEQUENCE OF PartialHashtree OPTIONAL,
     = policy          [1] OBJECT = IDENTIFIER OPTIONAL,
     = timeStamp       ContentInfo}

Using this structure, the policy would be asserted = when a renewal is performed.
 
Carl


________________________________

        From: = owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@ma= il.imc.org] On Behalf Of Denis Pinkas
        Sent: = Monday, January 15, 2007 9:59 AM
        To: = ietf-smime@imc.org
        Cc: = ietf-ltans@imc.org; 'Russ Housley'
        Subject: = Re: Cross review of draft ERS from LTANS WG until Jan 23 rd
       =20
       =20

        I said in = an earlier e-mail: "The WG has to justify why it would not fulfill its = needs".

        Carl has = provided interesting information to explain the differences with ISO = ISO-18014-3

        and why = ERS is different. The main advantage is the use of "ordinary" = time-stamps rather

        than = time-stamps with specific extensions. However, this information should = not be lost

        and be = used to write an informative annex.

         =

        There are = indeed much more important topics.

         =

        ERS is = supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?

         =

        However, = many of the requirements that are present in the requirements document =

        are not = met by the current ERS draft.

         =

        Here are a = few examples :

        =         1. = ltans-reqs-10 defines an Archival Period as "The period during which an = archived
        data = object is preserved by a long-term archive service". How may a long = term-archive
        service = be held responsible of storing the data during that time-period, since =
        the = information to know the time period is not present in the ER ?
        =         2. = ltans-reqs-10 defines a Cryp!
        tographic = Maintenance Policy. There is no corresponding
        element = in ERS. How can a long term-archive service know which maintenance to = apply,
        since the = information to perform the maintenance correctly is not present in ER = ?

        =         3. = ltans-reqs-10 states on page 7: A long-term archive service provides = evidence
        that may = be used to demonstrate the existence of an archived data object at a = given time
        and the = integrity of the archived data object since that time. The ER is = supposed
        to be the = basic piece of data to support that evidence. However, it is not signed =
        by the = long term-archive service, thus it cannot be used "to demonstrate the = existence
        of an = archived data object at a given time and the integrity of the archived = data object
        since = that time".
        =         4. = ltans-reqs-10 adds on page 7: "Additionally, the evidence identifies = the LTA(s)
        that have = participated in the preservation of the archived data object". However, =
        ER does = not contain the names of the LTA(s) that have participated in the = preservation
        of the = archived data object.
        =         5. = ltans-reqs-10 states on page 9: "A long-term archive service must = operate in accordance
        with a = long-term archive service policy that defines characteristics of the = implementation
        of the = long-term archive service". However, ER does not contain a data item to = support
        the = "long-term archive service policy".
        =         6. = ltans-reqs-10 adds on page 10: " Over the course of many years, the = policies under which
        an LTA = operates may undergo modification.  Thus, an evidence record may = feature multiple
        indications of policies active at various points during the = life of an archived data object."
        However, = the ER does not contain such an information.

        =         7. = ltans-reqs-10 states on page 11: "A long-term archive service must be = capable of providing
        evidence = that can be used to demonstrate the integrity of data for which it is = responsible
        from the = time it received the data until the expiration of the archival period = of the data".
        However, = no data item is specified in ER to provide this evidence.
       =20
        This = means that much work is still needed on the document to fulfill the = requirements.

         =

        Now, let = us see what should be done. The following is obviously an unpolished = strawman proposal.

         =

        In order = to reduce the number of time stamps, it is necessary to be able to = aggregate data
        before = applying a time stamp on it. For doing it, the following structure = (close to the
        structure = of ArchiveTimeStamp, but different) would fulfill the need).

         =

           TimeStampedNode ::=3D SEQUENCE {

             = digestAlgorithm        [0] = AlgorithmIdentifier OPTIONAL,

             = archivalPolicy         &nbs= p;   ArchivalPolicy,

             = archivalTimePeriod         = ArchivalTimePeriod,

             = cryptoMaintenancePolicy    = CryptoMaintenancePolicy,

             = reducedHashtree         &nb= sp;  SEQUENCE OF PartialHashtree,

             = timeStamp          &nb= sp;       TimeStampToken }

         =

           PartialHashtree ::=3D SEQUENCE OF OCTET = STRING

         =

           ArchivalPolicy::=3D OBJECT IDENTIFIER

        =         

           ArchivalTimePeriod ::=3D SEQUENCE {

                = notBefore      GeneralizedTime,

                = notAfter       GeneralizedTime }

        =         

        CryptoMaintenancePolicy would need more work to be defined, = but basically
        would = contain a sequence of algorithm identifiers with their = parameters.

        =         

        The = CryptoMaintenancePolicy applies to the data in the tree and to the = crypto of
        the time = stamp token.

         =

        The hash = included in the TimeStampToken is computed on the reducedHashtree = element.

         =

        If this = structure is signed by an agent from an archival service, then it can = be used
        to = demonstrate that a given agent from an LTA has accepted to archive, = under a given
        policy = for a given time period, the data items that are under the hash = tree.

         =

        This means = that TimeStampedNode must be the eContent of a CMS message signed by =
        an LTA = agent in order to form a SignedNode.

         =

        Later on, = the same, another or more LTA agents may need to add some other data to =
        a signed = Node, without loosing the previous time-stamp and signature.

         =

        This leads = to the following structure:

         =

           EvidenceNode ::=3D SEQUENCE {

              version    &= nbsp;           &= nbsp;       INTEGER { v1(1) } ,

              = digestAlgorithms         &n= bsp;     SEQUENCE OF AlgorithmIdentifier,

              = archivalPolicy         &nbs= p;       ArchivalPolicy,

              = archivalTimePeriod         =     ArchivalTimePeriod,

              = cryptoMaintenancePolicy        = CryptoMaintenancePolicy,

              = evidenceRecord         &nbs= p;       EvidenceRecord,

                  &nb= sp;           &nb= sp;           &nb= sp;  -- the evidence record that serves

                  &nb= sp;           &nb= sp;           &nb= sp;  -- for the construction

              = signedNodeSequence         =     SignedNodeSequence   OPTIONAL,

                  &nb= sp;           &nb= sp;           &nb= sp;  -- the elements that are added

                  &nb= sp;           &nb= sp;           &nb= sp;  -- to the previous evidence

              = timeStamp          &nb= sp;           = TimeStampToken }

         =

        with:

         =

           signedNodeSequence ::=3D SEQUENCE OF = SignedNode

         =

        The = CryptoMaintenancePolicy applies to the previous evidence record, to all =
        the data = that are in the tree and to the crypto of the time stamp token.

         =

        The hash = included in the TimeStampToken is computed on the concatenation of the =
        evidenceRecord element and of the signedNodeSequence = element.

         =

        This means = that EvidenceNode must be the eContent of a CMS message signed by =
        an LTA = agent in order to form an EvidenceRecord.

         =

        This new = proposal fulfills the seven requirements mentioned here above.

         =

        Denis

         =

________________________________

        =         Tony,
         =
        I think = Denis should provide additional details when calling for a working = group item to be dropped, especially when making this request this late = in the process with non-freely available documents as the basis.  = However, I'll try to make the case in the other direction.

         =
        =         I don't think = it's simply a case of too many options that require profiling.  = One motivation often cited during the development of ERS is support for = aggregations of data.  This is represented in ERS via the = reducedHashtree field in the ArchiveTimeStamp structure.  This = field and the related ArchiveTimeStampChain and = ArchiveTimeStampSequence structures allow handling of the aggregation = when the initial timestamp is generated, when simple timestamp renewal = is required as well as when simple timestamp renewal is not sufficient = and the original data must be hashed again.

         =
        The ISO = spec uses the ExtRenewal extension for timestamp renewal.  This is = roughly analogous to the timestamp renewal feature in ERS.  = However, there does not seem to be sufficient support for cases where = the hash algorithm is updated and the original data must be = rehashed.  In ERS, when a hash algorithm update is necessary, the = preceding timestamp tokens are hashed along with the original = data.  In the ISO spec, an existing timestamp token is presented = for renewal but the original data is not.  It may be possible to = make this work using the extHash extension, but I don't see any = description of this in the current spec (nor do I see any text that = describes verification of the ExtRenewal extension).  I don't = follow how the aggregation mechanisms in the ISO spec can be used to = aggregate data for the initial timestamp well enough to compare them to = ERS. 

         =
        ERS = support for aggregation is more clearly stated and ERS provides more = complete handling of renewal operations.  For these reasons, I = think we should proceed with ERS instead of trying to enhance the ISO = spec.

         =
        Carl


________________________________

            &n= bsp;   From: Tony Capel [mailto:capel@comgate.com]
        =         Sent: = Thursday, January 11, 2007 11:04 AM
        =         To: 'Carl = Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
        =         Cc: = ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley'
        =         Subject: RE: = RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

        =        =20
        =        =20
        =         Carl:
        =         
        =         I think Denis = asks simply for the justification for the introduction of new = technology to solve a problem which may already be solved with an = existing ISO standard (which has already been published and is = presumably more mature than what is being proposed).

        =         
        =         Denis notes = (in his previous comment) that perhaps the ISO standard offers too many = options and that perhaps a Profile of this ISO standard might be = published as an RFC to tailor the ISO standard for the specific = application(s) you have in mind.  In such a case the RFC should = profile (see ISO/IEC TR10000) the ISO standard and not introduce new = technology.

        =         
        =         Tony

        =         

        =         -----Original = Message-----
        =         From: = owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@ma= il.imc.org] On Behalf Of Carl Wallace
        =         Sent: January = 11, 2007 10:16 AM
        =         To: Denis = Pinkas; ietf-smime@imc.org
        =         Cc: = ietf-ltans@imc.org; Tobias Gondrom; Russ Housley
        =         Subject: RE: = RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

        =        =20
        =        =20
        =         My response = wasn't a reversal of the question but a request for details.  = Folks on the list have previously discussed these specifications, = including their use within an EvidenceRecord.  You made a sweeping = comment that lacked any details and called for fairly drastic = measures.  I simply asked for justification.


________________________________

        =         =         From: Denis = Pinkas [mailto:denis.pinkas@bull.net] =
        =         =         Sent: = Thursday, January 11, 2007 9:46 AM
        =         =         To: Carl = Wallace; ietf-smime@imc.org
        =         =         Cc: = ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
        =         =         Subject: Re: = RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

        =         =        =20
        =         =        =20
        =         =         Carl,
        =         =         
        =         =         Please do not = reverse the question. ISO 18014-3 already exists. The WG has to justify = why it would not fulfill its needs.

        =         =         I will refine = my question: Why is a profile of ISO 18014-3 not adequate to fulfill = the needs ?
        =         =         A profile = would make sense, since ISO 18014-3 has many options.
        =         =         
        =         =         Denis

________________________________

------_=_NextPart_001_01C738BC.41E169EE-- 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 l0FFTUUn045099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 08:29:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0FFTUaB045098; Mon, 15 Jan 2007 08:29:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0FFTRu6045085; Mon, 15 Jan 2007 08:29:28 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SlJ6+uQ/cVJ+6y1rs8fO5genZqG0GKgXB/YAgxHnkjAbFr9G2KbhehUApSTvBwP+; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.6.185] (helo=gw) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H6Tm1-0005nO-Gh; Mon, 15 Jan 2007 10:29:27 -0500 Message-ID: <3a9101c738ba$bb244f60$2101a8c0@home.glassey.com> From: "todd glassey" To: "Denis Pinkas" , Cc: , "'Russ Housley'" References: Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd Date: Mon, 15 Jan 2007 07:35:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3A8E_01C73877.AB26D120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79467be4553ac673812d3a8c1ba579ccc4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.6.185 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_3A8E_01C73877.AB26D120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Denis ----- Original Message -----=20 From: Denis Pinkas=20 To: ietf-smime@imc.org=20 Cc: ietf-ltans@imc.org ; 'Russ Housley'=20 Sent: Monday, January 15, 2007 6:59 AM Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd I said in an earlier e-mail: "The WG has to justify why it would not = fulfill its needs".=20 Carl has provided interesting information to explain the differences = with ISO ISO-18014-3=20 and why ERS is different. The main advantage is the use of "ordinary" = time-stamps rather=20 than time-stamps with specific extensions. However, this information = should not be lost=20 and be used to write an informative annex. =20 There are indeed much more important topics.=20 ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ? =20 However, many of the requirements that are present in the requirements = document=20 are not met by the current ERS draft.=20 =20 Here are a few examples : 1. ltans-reqs-10 defines an Archival Period as "The period during which = an archiveddata object is preserved by a long-term archive service". How = may a long term-archive service be held responsible of storing the data = during that time-period, since the information to know the time period = is not present in the ER ? Denis this is one of the key disagreement's = you and I have with timestamping. There is NO need to keep that = information online or mechanically provable in a methodology that = remains consistant with any taks than proving the signature at the time = of its signing in the technology available at the time of the signing. = 2. ltans-reqs-10 defines a Cr! yp! tographic Maintenance Policy. There is no corresponding element in ERS. = How can a long term-archive service know which maintenance to apply, = since the information to perform the maintenance correctly is not = present in ER ? 3. ltans-reqs-10 states on page 7: A long-term archive service provides = evidence that may be used to demonstrate the existence of an archived = data object at a given time and the integrity of the archived data = object since that time. The ER is supposed to be the basic piece of data = to support that evidence. However, it is not signed by the long = term-archive service, thus it cannot be used "to demonstrate the = existence of an archived data object at a given time and the integrity = of the archived data object since that time".4. ltans-reqs-10 adds on = page 7: "Additionally, the evidence identifies the LTA(s) that have = participated in the preservation of the archived data object". However, = ER does not contain the names of the LTA(s) that have participated in = the preservation of the archived data object.5. ltans-reqs-10 states on = page 9: "A long-term archive service must operate in accordance with a = long-term archive service policy that defines characteristics of the = implementation of the long-term archive service". However, ER does not = contain a data item to support the "long-term archive service policy". = There is no specification in the protocol drafts that these 'policies = and control features' be a part of the mechanical processes of the LTANS = service Denis...6. ltans-reqs-10 adds on page 10: " Over the course of = many years, the policies under which an LTA operates may undergo = modification. Thus, an evidence record may feature multiple indications = of policies active at various points during the life of an archived data = object." However, the ER does not contain such an information. 7. ltans-reqs-10 states on page 11: "A long-term archive service must be = capable of providing evidence that can be used to demonstrate the = integrity of data for which it is responsible from the time it received = the data until the expiration of the archival period of the data". = However, no data item is specified in ER to provide this evidence.This = means that much work is still needed on the document to fulfill the = requirements. =20 Now, let us see what should be done. The following is obviously an = unpolished strawman proposal. =20 In order to reduce the number of time stamps, it is necessary to be = able to aggregate data=20 before applying a time stamp on it. For doing it, the following = structure (close to the=20 structure of ArchiveTimeStamp, but different) would fulfill the need). =20 TimeStampedNode ::=3D SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, reducedHashtree SEQUENCE OF PartialHashtree, timeStamp TimeStampToken } =20 PartialHashtree ::=3D SEQUENCE OF OCTET STRING =20 ArchivalPolicy::=3D OBJECT IDENTIFIER ArchivalTimePeriod ::=3D SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime } CryptoMaintenancePolicy would need more work to be defined, but = basically=20 would contain a sequence of algorithm identifiers with their = parameters. =20 The CryptoMaintenancePolicy applies to the data in the tree and to the = crypto of=20 the time stamp token. =20 The hash included in the TimeStampToken is computed on the = reducedHashtree element. =20 If this structure is signed by an agent from an archival service, then = it can be used=20 to demonstrate that a given agent from an LTA has accepted to archive, = under a given=20 policy for a given time period, the data items that are under the hash = tree. =20 This means that TimeStampedNode must be the eContent of a CMS message = signed by=20 an LTA agent in order to form a SignedNode. =20 Later on, the same, another or more LTA agents may need to add some = other data to=20 a signed Node, without loosing the previous time-stamp and signature.=20 =20 This leads to the following structure: =20 EvidenceNode ::=3D SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, archivalPolicy ArchivalPolicy, archivalTimePeriod ArchivalTimePeriod, cryptoMaintenancePolicy CryptoMaintenancePolicy, evidenceRecord EvidenceRecord, -- the evidence record that = serves=20 -- for the construction signedNodeSequence SignedNodeSequence OPTIONAL, -- the elements that are added=20 -- to the previous evidence timeStamp TimeStampToken } =20 with: =20 signedNodeSequence ::=3D SEQUENCE OF SignedNode =20 The CryptoMaintenancePolicy applies to the previous evidence record, = to all=20 the data that are in the tree and to the crypto of the time stamp = token. =20 The hash included in the TimeStampToken is computed on the = concatenation of the=20 evidenceRecord element and of the signedNodeSequence element. =20 This means that EvidenceNode must be the eContent of a CMS message = signed by=20 an LTA agent in order to form an EvidenceRecord. This new proposal fulfills the seven requirements mentioned here = above. =20 Denis =20 -------------------------------------------------------------------------= ----- Tony, I think Denis should provide additional details when calling for a = working group item to be dropped, especially when making this request = this late in the process with non-freely available documents as the = basis. However, I'll try to make the case in the other direction. I don't think it's simply a case of too many options that require = profiling. One motivation often cited during the development of ERS is = support for aggregations of data. This is represented in ERS via the = reducedHashtree field in the ArchiveTimeStamp structure. This field and = the related ArchiveTimeStampChain and ArchiveTimeStampSequence = structures allow handling of the aggregation when the initial timestamp = is generated, when simple timestamp renewal is required as well as when = simple timestamp renewal is not sufficient and the original data must be = hashed again. The ISO spec uses the ExtRenewal extension for timestamp renewal. = This is roughly analogous to the timestamp renewal feature in ERS. = However, there does not seem to be sufficient support for cases where = the hash algorithm is updated and the original data must be rehashed. = In ERS, when a hash algorithm update is necessary, the preceding = timestamp tokens are hashed along with the original data. In the ISO = spec, an existing timestamp token is presented for renewal but the = original data is not. It may be possible to make this work using the = extHash extension, but I don't see any description of this in the = current spec (nor do I see any text that describes verification of the = ExtRenewal extension). I don't follow how the aggregation mechanisms in = the ISO spec can be used to aggregate data for the initial timestamp = well enough to compare them to ERS. =20 ERS support for aggregation is more clearly stated and ERS provides = more complete handling of renewal operations. For these reasons, I = think we should proceed with ERS instead of trying to enhance the ISO = spec. Carl -------------------------------------------------------------------------= --- From: Tony Capel [mailto:capel@comgate.com]=20 Sent: Thursday, January 11, 2007 11:04 AM To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: = WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl: I think Denis asks simply for the justification for the introduction = of new technology to solve a problem which may already be solved with an = existing ISO standard (which has already been published and is = presumably more mature than what is being proposed). Denis notes (in his previous comment) that perhaps the ISO standard = offers too many options and that perhaps a Profile of this ISO standard = might be published as an RFC to tailor the ISO standard for the specific = application(s) you have in mind. In such a case the RFC should profile = (see ISO/IEC TR10000) the ISO standard and not introduce new technology. Tony -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: = WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for = details. Folks on the list have previously discussed these = specifications, including their use within an EvidenceRecord. You made = a sweeping comment that lacked any details and called for fairly drastic = measures. I simply asked for justification. -------------------------------------------------------------------------= - From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: = WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, Please do not reverse the question. ISO 18014-3 already exists. = The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not = adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis -------------------------------------------------------------------------= ----- ------=_NextPart_000_3A8E_01C73877.AB26D120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Denis
----- Original Message -----
From:=20 Denis=20 Pinkas
Cc: ietf-ltans@imc.org ; 'Russ=20 Housley'
Sent: Monday, January 15, 2007 = 6:59=20 AM
Subject: Re: Cross review of = draft ERS=20 from LTANS WG until Jan 23 rd

I=20 said in an earlier e-mail: =93The WG has to justify why it would not = fulfill its=20 needs=94.

Carl=20 has provided interesting information to explain the differences with = ISO=20 ISO-18014-3

and=20 why ERS is different. The main advantage is the use of =93ordinary=94 = time-stamps=20 rather

than=20 time-stamps with specific extensions. However, this information should = not be=20 lost

and=20 be used to write an informative annex.

 

There=20 are indeed much more important topics.

 

ERS=20 is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn=92it=20 ?

 

However,=20 many of the requirements that are present in the requirements document =

are=20 not met by the current ERS draft.

 

Here=20 are a few examples :

1. =
ltans-reqs-10 defines an Archival Period as =93The period during which =
an archived
data object is preserved by a =
long-term archive service=94. How may a long term-archive =

service be held responsible of =
storing the data during that time-period, since 
the information to =
know the time period is not present in the ER =
?
 
Denis this is one of the key disagreement's you and I have with =
timestamping. There is NO need to keep that information online or =
mechanically provable in a methodology that remains consistant with any =
taks than proving the signature at the time of its signing in the =
technology available at the time of the =
signing.
 
2. ltans-reqs-10 defines a =
Cr!
 yp!
tographic Maintenance Policy. There is no corresponding 
element in =
ERS. How can a long term-archive service know which maintenance to =
apply, 
since the information to perform the maintenance correctly is =
not present in ER ?

3. =
ltans-reqs-10 states on page 7: A long-term archive service provides =
evidence 
that may be used to demonstrate the existence of an =
archived data object at a given time 
and the integrity of the =
archived data object since that time. The ER is supposed 
to be the =
basic piece of data to support that evidence. However, it is not signed =

by the long term-archive service, thus it cannot be used =93to =
demonstrate the existence 
of an archived data object at a given time =
and the integrity of the archived data object 
since that =
time=94.
4. ltans-reqs-10 =
adds on page 7: =93Additionally, the evidence identifies the LTA(s) =

that have participated in the preservation of the archived data =
object=94. However, 
ER does not contain the names of the LTA(s) that =
have participated in the preservation 
of the archived data =
object.
5. ltans-reqs-10 states on =
page 9: =93A long-term archive service must operate in accordance =

with a long-term archive service policy that defines characteristics =
of the implementation 
of the long-term archive service=94. However, =
ER does not contain a data item to support 
the =93long-term archive =
service policy=94. 
There  is =
no specification in the protocol drafts that these 'policies and control =
features' be a part of the mechanical processes of the LTANS service =
Denis...
 
6. ltans-reqs-10 adds on =
page 10: =93 Over the course of many years, the policies under which =

an LTA operates may undergo modification.  Thus, an evidence record may =
feature multiple 
indications of policies active at various points =
during the life of an archived data object.=94 
However, the ER does =
not contain such an information.

7. =
ltans-reqs-10 states on page 11: =93A long-term archive service must be =
capable of providing 
evidence that can be used to demonstrate the =
integrity of data for which it is responsible 
from the time it =
received the data until the expiration of the archival period of the =
data=94. 
However, no data item is specified in ER to provide this =
evidence.

This=20 means that much work is still needed on the document to fulfill the=20 requirements.

 

Now,=20 let us see what should be done. The following is obviously an = unpolished=20 strawman proposal.

 

In=20 order to reduce the number of time stamps, it is necessary to be able = to=20 aggregate data
before applying a time stamp on it. For doing it, = the=20 following structure (close to the
structure of ArchiveTimeStamp, = but=20 different) would fulfill the need).

 

   TimeStampedNode ::=3D = SEQUENCE=20 {

     = digestAlgorithm=20        [0]=20 AlgorithmIdentifier OPTIONAL,

     = archivalPolicy           &n= bsp;=20 ArchivalPolicy,

    =20 archivalTimePeriod        =20 ArchivalTimePeriod,

    =20 cryptoMaintenancePolicy  =20  CryptoMaintenancePolicy,

     = reducedHashtree=20            SEQUENCE=20 OF PartialHashtree,

     = timeStamp       =            TimeStampToke= n=20 }

 

   PartialHashtree ::=3D = SEQUENCE OF=20 OCTET STRING

 

   ArchivalPolicy::=3D OBJECT=20 IDENTIFIER

 

   ArchivalTimePeriod = ::=3D=20 SEQUENCE=20 {

        = notBefore     =20 GeneralizedTime,

        = notAfter      =20 GeneralizedTime }

 

CryptoMaintenancePolicy=20 would need more work to be defined, but basically
would contain a = sequence=20 of algorithm identifiers with their parameters.

 

The=20 CryptoMaintenancePolicy applies to the data in the tree and to the = crypto of=20
the time stamp token.

 

The=20 hash included in the TimeStampToken is computed on the reducedHashtree = element.

 

If=20 this structure is signed by an agent from an archival service, then it = can be=20 used
to demonstrate that a given agent from an LTA has accepted to = archive, under a given
policy for a given time period, the data = items that=20 are under the hash tree.

 

This=20 means that TimeStampedNode must be the eContent of a CMS message = signed by=20
an LTA agent in order to form a SignedNode.

 

Later=20 on, the same, another or more LTA agents may need to add some other = data to=20
a signed Node, without loosing the previous time-stamp and = signature.=20

 

This=20 leads to the following structure:

 

   EvidenceNode ::=3D = SEQUENCE=20 {

      = version           &n= bsp;     =20       INTEGER { v1(1) }=20 ,

     =20 digestAlgorithms        =20       SEQUENCE OF=20 AlgorithmIdentifier,

     =20 archivalPolicy           &n= bsp;    =20 ArchivalPolicy,

     =20 archivalTimePeriod           &n= bsp;=20 ArchivalTimePeriod,

     =20 cryptoMaintenancePolicy        = CryptoMaintenancePolicy,

     =20 evidenceRecord           &n= bsp; =20    EvidenceRecord,

               &n= bsp;           &nb= sp;         -- the evidence record = that=20 serves

           &n= bsp;           &nb= sp;           &nbs= p;=20 -- for the construction

     =20 signedNodeSequence             SignedNodeSequence   = OPTIONAL,

              &n= bsp;           &nb= sp;          -- the elements = that are=20 added

           &n= bsp;           &nb= sp;           &nbs= p;=20 -- to the previous evidence

      = timeStamp       =            &n= bsp;   TimeStampToken=20 }

 

with:

 

   signedNodeSequence = ::=3D SEQUENCE=20 OF SignedNode

 

The=20 CryptoMaintenancePolicy applies to the previous evidence = record, to all=20
the data that are in the tree and to the crypto of the time stamp=20 token.

 

The=20 hash included in the TimeStampToken is computed on the concatenation = of the=20
evidenceRecord element and of the signedNodeSequence=20 element.

 

This=20 means that EvidenceNode must be the eContent of a CMS message signed = by
an=20 LTA agent in order to form an EvidenceRecord.

 

This=20 new proposal fulfills the seven requirements mentioned here=20 above.

 

Denis

 

Tony,
 
I think Denis should provide additional = details when=20 calling for a working group item to be dropped, especially when making = this=20 request this late in the process = with=20 non-freely available documents as the basis.  However, I'll try = to make=20 the case in the other direction.
 
I don't think it's simply a case of too many = options that=20 require profiling.  One motivation often cited during the = development of=20 ERS is support for aggregations of data.  This is represented in = ERS via=20 the reducedHashtree field in the ArchiveTimeStamp structure.  = This field=20 and the related ArchiveTimeStampChain and ArchiveTimeStampSequence = structures=20 allow handling of the aggregation when the initial timestamp=20 is generated, when simple timestamp renewal is required = as well=20 as when simple timestamp renewal is not sufficient and the original = data must=20 be hashed again.
 
The ISO spec uses the ExtRenewal extension for timestamp = renewal.  This is=20 roughly analogous to the timestamp renewal feature in ERS.  = However,=20 there does not seem to be sufficient support for cases where the hash=20 algorithm is updated and the original data must be rehashed.  In = ERS,=20 when a hash algorithm update is necessary, the preceding timestamp = tokens are=20 hashed along with the original data.  In the ISO spec, an = existing=20 timestamp token is presented for renewal but the original data is = not. =20 It may be possible to make this work using the extHash extension, but = I don't=20 see any description of this in the current spec (nor do I see any text = that=20 describes verification of the ExtRenewal extension).  = I don't follow how the aggregation = mechanisms in=20 the ISO spec can be used to aggregate data for the initial timestamp = well=20 enough to compare them to = ERS.  
 
ERS = support for=20 aggregation is more clearly stated and ERS provides more complete = handling of renewal operations.  For these reasons, I think we = should=20 proceed with ERS instead of trying to enhance the ISO=20 spec.
 
Carl

From: Tony Capel = [mailto:capel@comgate.com]=20
Sent: Thursday, January 11, 2007 11:04 AM
To: = 'Carl=20 Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
Cc:=20 ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ = Housley'
Subject: RE:=20 RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca=20 ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl:
 
I=20 think Denis asks simply for the justification for the introduction=20 of new technology to solve a problem which may already be = solved with=20 an existing ISO standard (which has already been published and is = presumably=20 more mature than what is being proposed).
 
Denis notes (in his previous = comment) that=20 perhaps the ISO standard offers too many options and that perhaps a = Profile=20 of this ISO standard might be published as an RFC to tailor the ISO = standard=20 for the specific application(s) you have in mind.  In such a = case the=20 RFC should profile (see ISO/IEC TR10000) the ISO standard and not = introduce=20 new technology.
 
Tony

 

-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Carl Wallace
Sent: January 11, 2007 10:16=20 AM
To: Denis Pinkas; ietf-smime@imc.org
Cc:=20 ietf-ltans@imc.org; Tobias Gondrom; Russ Housley
Subject: = RE: RE:=20 RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca=20 ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

My response wasn't a reversal of the = question but=20 a request for details.  Folks on the list have previously = discussed=20 these specifications, including their use within an = EvidenceRecord. =20 You made a sweeping comment that lacked any details and called for = fairly=20 drastic measures.  I simply asked for=20 justification.

From: Denis Pinkas=20 [mailto:denis.pinkas@bull.net]
Sent: Thursday, January = 11, 2007=20 9:46 AM
To: Carl Wallace; = ietf-smime@imc.org
Cc:=20 ietf-ltans@imc.org; Russ Housley; Tobias = Gondrom
Subject: Re:=20 RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca=20 ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,
 
Please do not reverse the question. ISO 18014-3 already = exists. The=20 WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 = not=20 adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many=20 options.
 
Denis
------=_NextPart_000_3A8E_01C73877.AB26D120-- 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 l0FExGFu042399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 07:59: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 l0FExGKU042398; Mon, 15 Jan 2007 07:59:16 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0FExCJS042379; Mon, 15 Jan 2007 07:59:13 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA48848; Mon, 15 Jan 2007 16:02:42 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011515590522:162362 ; Mon, 15 Jan 2007 15:59:05 +0100 Date: Mon, 15 Jan 2007 15:59:02 +0100 From: "Denis Pinkas" To: "ietf-smime@imc.org" Cc: "ietf-ltans@imc.org" , "'Russ Housley'" Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 15/01/2007 15:59:05, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 15/01/2007 15:59:06, Serialize complete at 15/01/2007 15:59:06 Message-ID: Content-Type: multipart/alternative; boundary="=====003_Dragon810844471340_=====" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --=====003_Dragon810844471340_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" SSBzYWlkIGluIGFuIGVhcmxpZXIgZS1tYWlsOiCTVGhlIFdHIGhhcyB0byBqdXN0aWZ5IHdoeSBp dCB3b3VsZCBub3QgZnVsZmlsbCBpdHMgbmVlZHOULiANCkNhcmwgaGFzIHByb3ZpZGVkIGludGVy ZXN0aW5nIGluZm9ybWF0aW9uIHRvIGV4cGxhaW4gdGhlIGRpZmZlcmVuY2VzIHdpdGggSVNPIElT Ty0xODAxNC0zIA0KYW5kIHdoeSBFUlMgaXMgZGlmZmVyZW50LiBUaGUgbWFpbiBhZHZhbnRhZ2Ug aXMgdGhlIHVzZSBvZiCTb3JkaW5hcnmUIHRpbWUtc3RhbXBzIHJhdGhlciANCnRoYW4gdGltZS1z dGFtcHMgd2l0aCBzcGVjaWZpYyBleHRlbnNpb25zLiBIb3dldmVyLCB0aGlzIGluZm9ybWF0aW9u IHNob3VsZCBub3QgYmUgbG9zdCANCmFuZCBiZSB1c2VkIHRvIHdyaXRlIGFuIGluZm9ybWF0aXZl IGFubmV4Lg0KIA0KVGhlcmUgYXJlIGluZGVlZCBtdWNoIG1vcmUgaW1wb3J0YW50IHRvcGljcy4g DQoNCkVSUyBpcyBzdXBwb3NlZCB0byByZXNwb25kIHRvIGRyYWZ0LWlldGYtbHRhbnMtcmVxcy0x MC50eHQsIGlzbpJpdCA/DQogDQpIb3dldmVyLCBtYW55IG9mIHRoZSByZXF1aXJlbWVudHMgdGhh dCBhcmUgcHJlc2VudCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IA0KYXJlIG5vdCBtZXQg YnkgdGhlIGN1cnJlbnQgRVJTIGRyYWZ0LiANCiANCkhlcmUgYXJlIGEgZmV3IGV4YW1wbGVzIDoN CjEuIGx0YW5zLXJlcXMtMTAgZGVmaW5lcyBhbiBBcmNoaXZhbCBQZXJpb2QgYXMgk1RoZSBwZXJp b2QgZHVyaW5nIHdoaWNoIGFuIGFyY2hpdmVkZGF0YSBvYmplY3QgaXMgcHJlc2VydmVkIGJ5IGEg bG9uZy10ZXJtIGFyY2hpdmUgc2VydmljZZQuIEhvdyBtYXkgYSBsb25nIHRlcm0tYXJjaGl2ZSBz ZXJ2aWNlIGJlIGhlbGQgcmVzcG9uc2libGUgb2Ygc3RvcmluZyB0aGUgZGF0YSBkdXJpbmcgdGhh dCB0aW1lLXBlcmlvZCwgc2luY2UgdGhlIGluZm9ybWF0aW9uIHRvIGtub3cgdGhlIHRpbWUgcGVy aW9kIGlzIG5vdCBwcmVzZW50IGluIHRoZSBFUiA/DQoNCjIuIGx0YW5zLXJlcXMtMTAgZGVmaW5l cyBhIENyeXB0b2dyYXBoaWMgTWFpbnRlbmFuY2UgUG9saWN5LiBUaGVyZSBpcyBubyBjb3JyZXNw b25kaW5nIGVsZW1lbnQgaW4gRVJTLiBIb3cgY2FuIGEgbG9uZyB0ZXJtLWFyY2hpdmUgc2Vydmlj ZSBrbm93IHdoaWNoIG1haW50ZW5hbmNlIHRvIGFwcGx5LCBzaW5jZSB0aGUgaW5mb3JtYXRpb24g dG8gcGVyZm9ybSB0aGUgbWFpbnRlbmFuY2UgY29ycmVjdGx5IGlzIG5vdCBwcmVzZW50IGluIEVS ID8NCjMuIGx0YW5zLXJlcXMtMTAgc3RhdGVzIG9uIHBhZ2UgNzogQSBsb25nLXRlcm0gYXJjaGl2 ZSBzZXJ2aWNlIHByb3ZpZGVzIGV2aWRlbmNlIHRoYXQgbWF5IGJlIHVzZWQgdG8gZGVtb25zdHJh dGUgdGhlIGV4aXN0ZW5jZSBvZiBhbiBhcmNoaXZlZCBkYXRhIG9iamVjdCBhdCBhIGdpdmVuIHRp bWUgYW5kIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGFyY2hpdmVkIGRhdGEgb2JqZWN0IHNpbmNlIHRo YXQgdGltZS4gVGhlIEVSIGlzIHN1cHBvc2VkIHRvIGJlIHRoZSBiYXNpYyBwaWVjZSBvZiBkYXRh IHRvIHN1cHBvcnQgdGhhdCBldmlkZW5jZS4gSG93ZXZlciwgaXQgaXMgbm90IHNpZ25lZCBieSB0 aGUgbG9uZyB0ZXJtLWFyY2hpdmUgc2VydmljZSwgdGh1cyBpdCBjYW5ub3QgYmUgdXNlZCCTdG8g ZGVtb25zdHJhdGUgdGhlIGV4aXN0ZW5jZSBvZiBhbiBhcmNoaXZlZCBkYXRhIG9iamVjdCBhdCBh IGdpdmVuIHRpbWUgYW5kIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGFyY2hpdmVkIGRhdGEgb2JqZWN0 IHNpbmNlIHRoYXQgdGltZZQuDQoNCjQuIGx0YW5zLXJlcXMtMTAgYWRkcyBvbiBwYWdlIDc6IJNB ZGRpdGlvbmFsbHksIHRoZSBldmlkZW5jZSBpZGVudGlmaWVzIHRoZSBMVEEocykgdGhhdCBoYXZl IHBhcnRpY2lwYXRlZCBpbiB0aGUgcHJlc2VydmF0aW9uIG9mIHRoZSBhcmNoaXZlZCBkYXRhIG9i amVjdJQuIEhvd2V2ZXIsIEVSIGRvZXMgbm90IGNvbnRhaW4gdGhlIG5hbWVzIG9mIHRoZSBMVEEo cykgdGhhdCBoYXZlIHBhcnRpY2lwYXRlZCBpbiB0aGUgcHJlc2VydmF0aW9uIG9mIHRoZSBhcmNo aXZlZCBkYXRhIG9iamVjdC4NCg0KNS4gbHRhbnMtcmVxcy0xMCBzdGF0ZXMgb24gcGFnZSA5OiCT QSBsb25nLXRlcm0gYXJjaGl2ZSBzZXJ2aWNlIG11c3Qgb3BlcmF0ZSBpbiBhY2NvcmRhbmNlIHdp dGggYSBsb25nLXRlcm0gYXJjaGl2ZSBzZXJ2aWNlIHBvbGljeSB0aGF0IGRlZmluZXMgY2hhcmFj dGVyaXN0aWNzIG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgbG9uZy10ZXJtIGFyY2hpdmUg c2VydmljZZQuIEhvd2V2ZXIsIEVSIGRvZXMgbm90IGNvbnRhaW4gYSBkYXRhIGl0ZW0gdG8gc3Vw cG9ydCB0aGUgk2xvbmctdGVybSBhcmNoaXZlIHNlcnZpY2UgcG9saWN5lC4gDQoNCjYuIGx0YW5z LXJlcXMtMTAgYWRkcyBvbiBwYWdlIDEwOiCTIE92ZXIgdGhlIGNvdXJzZSBvZiBtYW55IHllYXJz LCB0aGUgcG9saWNpZXMgdW5kZXIgd2hpY2ggYW4gTFRBIG9wZXJhdGVzIG1heSB1bmRlcmdvIG1v ZGlmaWNhdGlvbi4gIFRodXMsIGFuIGV2aWRlbmNlIHJlY29yZCBtYXkgZmVhdHVyZSBtdWx0aXBs ZSBpbmRpY2F0aW9ucyBvZiBwb2xpY2llcyBhY3RpdmUgYXQgdmFyaW91cyBwb2ludHMgZHVyaW5n IHRoZSBsaWZlIG9mIGFuIGFyY2hpdmVkIGRhdGEgb2JqZWN0LpQgSG93ZXZlciwgdGhlIEVSIGRv ZXMgbm90IGNvbnRhaW4gc3VjaCBhbiBpbmZvcm1hdGlvbi4NCjcuIGx0YW5zLXJlcXMtMTAgc3Rh dGVzIG9uIHBhZ2UgMTE6IJNBIGxvbmctdGVybSBhcmNoaXZlIHNlcnZpY2UgbXVzdCBiZSBjYXBh YmxlIG9mIHByb3ZpZGluZyBldmlkZW5jZSB0aGF0IGNhbiBiZSB1c2VkIHRvIGRlbW9uc3RyYXRl IHRoZSBpbnRlZ3JpdHkgb2YgZGF0YSBmb3Igd2hpY2ggaXQgaXMgcmVzcG9uc2libGUgZnJvbSB0 aGUgdGltZSBpdCByZWNlaXZlZCB0aGUgZGF0YSB1bnRpbCB0aGUgZXhwaXJhdGlvbiBvZiB0aGUg YXJjaGl2YWwgcGVyaW9kIG9mIHRoZSBkYXRhlC4gSG93ZXZlciwgbm8gZGF0YSBpdGVtIGlzIHNw ZWNpZmllZCBpbiBFUiB0byBwcm92aWRlIHRoaXMgZXZpZGVuY2UuDQoNClRoaXMgbWVhbnMgdGhh dCBtdWNoIHdvcmsgaXMgc3RpbGwgbmVlZGVkIG9uIHRoZSBkb2N1bWVudCB0byBmdWxmaWxsIHRo ZSByZXF1aXJlbWVudHMuDQogDQpOb3csIGxldCB1cyBzZWUgd2hhdCBzaG91bGQgYmUgZG9uZS4g VGhlIGZvbGxvd2luZyBpcyBvYnZpb3VzbHkgYW4gdW5wb2xpc2hlZCBzdHJhd21hbiBwcm9wb3Nh bC4NCiANCkluIG9yZGVyIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHRpbWUgc3RhbXBzLCBpdCBp cyBuZWNlc3NhcnkgdG8gYmUgYWJsZSB0byBhZ2dyZWdhdGUgZGF0YSANCmJlZm9yZSBhcHBseWlu ZyBhIHRpbWUgc3RhbXAgb24gaXQuIEZvciBkb2luZyBpdCwgdGhlIGZvbGxvd2luZyBzdHJ1Y3R1 cmUgKGNsb3NlIHRvIHRoZSANCnN0cnVjdHVyZSBvZiBBcmNoaXZlVGltZVN0YW1wLCBidXQgZGlm ZmVyZW50KSB3b3VsZCBmdWxmaWxsIHRoZSBuZWVkKS4NCiANCiAgIFRpbWVTdGFtcGVkTm9kZSA6 Oj0gU0VRVUVOQ0Ugew0KICAgICBkaWdlc3RBbGdvcml0aG0gICAgICAgIFswXSBBbGdvcml0aG1J ZGVudGlmaWVyIE9QVElPTkFMLA0KICAgICBhcmNoaXZhbFBvbGljeSAgICAgICAgICAgICBBcmNo aXZhbFBvbGljeSwNCiAgICAgYXJjaGl2YWxUaW1lUGVyaW9kICAgICAgICAgQXJjaGl2YWxUaW1l UGVyaW9kLA0KICAgICBjcnlwdG9NYWludGVuYW5jZVBvbGljeSAgICBDcnlwdG9NYWludGVuYW5j ZVBvbGljeSwNCiAgICAgcmVkdWNlZEhhc2h0cmVlICAgICAgICAgICAgU0VRVUVOQ0UgT0YgUGFy dGlhbEhhc2h0cmVlLA0KICAgICB0aW1lU3RhbXAgICAgICAgICAgICAgICAgICBUaW1lU3RhbXBU b2tlbiB9DQogDQogICBQYXJ0aWFsSGFzaHRyZWUgOjo9IFNFUVVFTkNFIE9GIE9DVEVUIFNUUklO Rw0KDQogICBBcmNoaXZhbFBvbGljeTo6PSBPQkpFQ1QgSURFTlRJRklFUg0KDQogICBBcmNoaXZh bFRpbWVQZXJpb2QgOjo9IFNFUVVFTkNFIHsNCiAgICAgICAgbm90QmVmb3JlICAgICAgR2VuZXJh bGl6ZWRUaW1lLA0KICAgICAgICBub3RBZnRlciAgICAgICBHZW5lcmFsaXplZFRpbWUgfQ0KDQpD cnlwdG9NYWludGVuYW5jZVBvbGljeSB3b3VsZCBuZWVkIG1vcmUgd29yayB0byBiZSBkZWZpbmVk LCBidXQgYmFzaWNhbGx5IA0Kd291bGQgY29udGFpbiBhIHNlcXVlbmNlIG9mIGFsZ29yaXRobSBp ZGVudGlmaWVycyB3aXRoIHRoZWlyIHBhcmFtZXRlcnMuDQogDQpUaGUgQ3J5cHRvTWFpbnRlbmFu Y2VQb2xpY3kgYXBwbGllcyB0byB0aGUgZGF0YSBpbiB0aGUgdHJlZSBhbmQgdG8gdGhlIGNyeXB0 byBvZiANCnRoZSB0aW1lIHN0YW1wIHRva2VuLg0KIA0KVGhlIGhhc2ggaW5jbHVkZWQgaW4gdGhl IFRpbWVTdGFtcFRva2VuIGlzIGNvbXB1dGVkIG9uIHRoZSByZWR1Y2VkSGFzaHRyZWUgZWxlbWVu dC4NCiANCklmIHRoaXMgc3RydWN0dXJlIGlzIHNpZ25lZCBieSBhbiBhZ2VudCBmcm9tIGFuIGFy Y2hpdmFsIHNlcnZpY2UsIHRoZW4gaXQgY2FuIGJlIHVzZWQgDQp0byBkZW1vbnN0cmF0ZSB0aGF0 IGEgZ2l2ZW4gYWdlbnQgZnJvbSBhbiBMVEEgaGFzIGFjY2VwdGVkIHRvIGFyY2hpdmUsIHVuZGVy IGEgZ2l2ZW4gDQpwb2xpY3kgZm9yIGEgZ2l2ZW4gdGltZSBwZXJpb2QsIHRoZSBkYXRhIGl0ZW1z IHRoYXQgYXJlIHVuZGVyIHRoZSBoYXNoIHRyZWUuDQogDQpUaGlzIG1lYW5zIHRoYXQgVGltZVN0 YW1wZWROb2RlIG11c3QgYmUgdGhlIGVDb250ZW50IG9mIGEgQ01TIG1lc3NhZ2Ugc2lnbmVkIGJ5 IA0KYW4gTFRBIGFnZW50IGluIG9yZGVyIHRvIGZvcm0gYSBTaWduZWROb2RlLg0KIA0KTGF0ZXIg b24sIHRoZSBzYW1lLCBhbm90aGVyIG9yIG1vcmUgTFRBIGFnZW50cyBtYXkgbmVlZCB0byBhZGQg c29tZSBvdGhlciBkYXRhIHRvIA0KYSBzaWduZWQgTm9kZSwgd2l0aG91dCBsb29zaW5nIHRoZSBw cmV2aW91cyB0aW1lLXN0YW1wIGFuZCBzaWduYXR1cmUuIA0KIA0KVGhpcyBsZWFkcyB0byB0aGUg Zm9sbG93aW5nIHN0cnVjdHVyZToNCiANCiAgIEV2aWRlbmNlTm9kZSA6Oj0gU0VRVUVOQ0Ugew0K ICAgICAgdmVyc2lvbiAgICAgICAgICAgICAgICAgICAgICAgIElOVEVHRVIgeyB2MSgxKSB9ICwN CiAgICAgIGRpZ2VzdEFsZ29yaXRobXMgICAgICAgICAgICAgICBTRVFVRU5DRSBPRiBBbGdvcml0 aG1JZGVudGlmaWVyLA0KICAgICAgYXJjaGl2YWxQb2xpY3kgICAgICAgICAgICAgICAgIEFyY2hp dmFsUG9saWN5LA0KICAgICAgYXJjaGl2YWxUaW1lUGVyaW9kICAgICAgICAgICAgIEFyY2hpdmFs VGltZVBlcmlvZCwNCiAgICAgIGNyeXB0b01haW50ZW5hbmNlUG9saWN5ICAgICAgICBDcnlwdG9N YWludGVuYW5jZVBvbGljeSwNCiAgICAgIGV2aWRlbmNlUmVjb3JkICAgICAgICAgICAgICAgICBF dmlkZW5jZVJlY29yZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSB0 aGUgZXZpZGVuY2UgcmVjb3JkIHRoYXQgc2VydmVzIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIGZvciB0aGUgY29uc3RydWN0aW9uDQogICAgICBzaWduZWROb2RlU2Vx dWVuY2UgICAgICAgICAgICAgU2lnbmVkTm9kZVNlcXVlbmNlICAgT1BUSU9OQUwsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gdGhlIGVsZW1lbnRzIHRoYXQgYXJlIGFk ZGVkIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIHRvIHRoZSBwcmV2 aW91cyBldmlkZW5jZQ0KICAgICAgdGltZVN0YW1wICAgICAgICAgICAgICAgICAgICAgIFRpbWVT dGFtcFRva2VuIH0NCiANCndpdGg6DQogDQogICBzaWduZWROb2RlU2VxdWVuY2UgOjo9IFNFUVVF TkNFIE9GIFNpZ25lZE5vZGUNCiANClRoZSBDcnlwdG9NYWludGVuYW5jZVBvbGljeSBhcHBsaWVz IHRvIHRoZSBwcmV2aW91cyBldmlkZW5jZSByZWNvcmQsIHRvIGFsbCANCnRoZSBkYXRhIHRoYXQg YXJlIGluIHRoZSB0cmVlIGFuZCB0byB0aGUgY3J5cHRvIG9mIHRoZSB0aW1lIHN0YW1wIHRva2Vu Lg0KIA0KVGhlIGhhc2ggaW5jbHVkZWQgaW4gdGhlIFRpbWVTdGFtcFRva2VuIGlzIGNvbXB1dGVk IG9uIHRoZSBjb25jYXRlbmF0aW9uIG9mIHRoZSANCmV2aWRlbmNlUmVjb3JkIGVsZW1lbnQgYW5k IG9mIHRoZSBzaWduZWROb2RlU2VxdWVuY2UgZWxlbWVudC4NCiANClRoaXMgbWVhbnMgdGhhdCBF dmlkZW5jZU5vZGUgbXVzdCBiZSB0aGUgZUNvbnRlbnQgb2YgYSBDTVMgbWVzc2FnZSBzaWduZWQg YnkgDQphbiBMVEEgYWdlbnQgaW4gb3JkZXIgdG8gZm9ybSBhbiBFdmlkZW5jZVJlY29yZC4NCg0K VGhpcyBuZXcgcHJvcG9zYWwgZnVsZmlsbHMgdGhlIHNldmVuIHJlcXVpcmVtZW50cyBtZW50aW9u ZWQgaGVyZSBhYm92ZS4NCg0KRGVuaXMNCg0KDQoNCg0KVG9ueSwNCg0KSSB0aGluayBEZW5pcyBz aG91bGQgcHJvdmlkZSBhZGRpdGlvbmFsIGRldGFpbHMgd2hlbiBjYWxsaW5nIGZvciBhIHdvcmtp bmcgZ3JvdXAgaXRlbSB0byBiZSBkcm9wcGVkLCBlc3BlY2lhbGx5IHdoZW4gbWFraW5nIHRoaXMg cmVxdWVzdCB0aGlzIGxhdGUgaW4gdGhlIHByb2Nlc3Mgd2l0aCBub24tZnJlZWx5IGF2YWlsYWJs ZSBkb2N1bWVudHMgYXMgdGhlIGJhc2lzLiAgSG93ZXZlciwgSSdsbCB0cnkgdG8gbWFrZSB0aGUg Y2FzZSBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLg0KDQpJIGRvbid0IHRoaW5rIGl0J3Mgc2ltcGx5 IGEgY2FzZSBvZiB0b28gbWFueSBvcHRpb25zIHRoYXQgcmVxdWlyZSBwcm9maWxpbmcuICBPbmUg bW90aXZhdGlvbiBvZnRlbiBjaXRlZCBkdXJpbmcgdGhlIGRldmVsb3BtZW50IG9mIEVSUyBpcyBz dXBwb3J0IGZvciBhZ2dyZWdhdGlvbnMgb2YgZGF0YS4gIFRoaXMgaXMgcmVwcmVzZW50ZWQgaW4g RVJTIHZpYSB0aGUgcmVkdWNlZEhhc2h0cmVlIGZpZWxkIGluIHRoZSBBcmNoaXZlVGltZVN0YW1w IHN0cnVjdHVyZS4gIFRoaXMgZmllbGQgYW5kIHRoZSByZWxhdGVkIEFyY2hpdmVUaW1lU3RhbXBD aGFpbiBhbmQgQXJjaGl2ZVRpbWVTdGFtcFNlcXVlbmNlIHN0cnVjdHVyZXMgYWxsb3cgaGFuZGxp bmcgb2YgdGhlIGFnZ3JlZ2F0aW9uIHdoZW4gdGhlIGluaXRpYWwgdGltZXN0YW1wIGlzIGdlbmVy YXRlZCwgd2hlbiBzaW1wbGUgdGltZXN0YW1wIHJlbmV3YWwgaXMgcmVxdWlyZWQgYXMgd2VsbCBh cyB3aGVuIHNpbXBsZSB0aW1lc3RhbXAgcmVuZXdhbCBpcyBub3Qgc3VmZmljaWVudCBhbmQgdGhl IG9yaWdpbmFsIGRhdGEgbXVzdCBiZSBoYXNoZWQgYWdhaW4uDQoNClRoZSBJU08gc3BlYyB1c2Vz IHRoZSBFeHRSZW5ld2FsIGV4dGVuc2lvbiBmb3IgdGltZXN0YW1wIHJlbmV3YWwuICBUaGlzIGlz IHJvdWdobHkgYW5hbG9nb3VzIHRvIHRoZSB0aW1lc3RhbXAgcmVuZXdhbCBmZWF0dXJlIGluIEVS Uy4gIEhvd2V2ZXIsIHRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgc3VmZmljaWVudCBzdXBwb3J0 IGZvciBjYXNlcyB3aGVyZSB0aGUgaGFzaCBhbGdvcml0aG0gaXMgdXBkYXRlZCBhbmQgdGhlIG9y aWdpbmFsIGRhdGEgbXVzdCBiZSByZWhhc2hlZC4gIEluIEVSUywgd2hlbiBhIGhhc2ggYWxnb3Jp dGhtIHVwZGF0ZSBpcyBuZWNlc3NhcnksIHRoZSBwcmVjZWRpbmcgdGltZXN0YW1wIHRva2VucyBh cmUgaGFzaGVkIGFsb25nIHdpdGggdGhlIG9yaWdpbmFsIGRhdGEuICBJbiB0aGUgSVNPIHNwZWMs IGFuIGV4aXN0aW5nIHRpbWVzdGFtcCB0b2tlbiBpcyBwcmVzZW50ZWQgZm9yIHJlbmV3YWwgYnV0 IHRoZSBvcmlnaW5hbCBkYXRhIGlzIG5vdC4gIEl0IG1heSBiZSBwb3NzaWJsZSB0byBtYWtlIHRo aXMgd29yayB1c2luZyB0aGUgZXh0SGFzaCBleHRlbnNpb24sIGJ1dCBJIGRvbid0IHNlZSBhbnkg ZGVzY3JpcHRpb24gb2YgdGhpcyBpbiB0aGUgY3VycmVudCBzcGVjIChub3IgZG8gSSBzZWUgYW55 IHRleHQgdGhhdCBkZXNjcmliZXMgdmVyaWZpY2F0aW9uIG9mIHRoZSBFeHRSZW5ld2FsIGV4dGVu c2lvbikuICBJIGRvbid0IGZvbGxvdyBob3cgdGhlIGFnZ3JlZ2F0aW9uIG1lY2hhbmlzbXMgaW4g dGhlIElTTyBzcGVjIGNhbiBiZSB1c2VkIHRvIGFnZ3JlZ2F0ZSBkYXRhIGZvciB0aGUgaW5pdGlh bCB0aW1lc3RhbXAgd2VsbCBlbm91Z2ggdG8gY29tcGFyZSB0aGVtIHRvIEVSUy4gIA0KDQpFUlMg c3VwcG9ydCBmb3IgYWdncmVnYXRpb24gaXMgbW9yZSBjbGVhcmx5IHN0YXRlZCBhbmQgRVJTIHBy b3ZpZGVzIG1vcmUgY29tcGxldGUgaGFuZGxpbmcgb2YgcmVuZXdhbCBvcGVyYXRpb25zLiAgRm9y IHRoZXNlIHJlYXNvbnMsIEkgdGhpbmsgd2Ugc2hvdWxkIHByb2NlZWQgd2l0aCBFUlMgaW5zdGVh ZCBvZiB0cnlpbmcgdG8gZW5oYW5jZSB0aGUgSVNPIHNwZWMuDQoNCkNhcmwNCg0KDQoNCg0KRnJv bTogVG9ueSBDYXBlbCBbbWFpbHRvOmNhcGVsQGNvbWdhdGUuY29tXSANClNlbnQ6IFRodXJzZGF5 LCBKYW51YXJ5IDExLCAyMDA3IDExOjA0IEFNDQpUbzogJ0NhcmwgV2FsbGFjZSc7ICdEZW5pcyBQ aW5rYXMnOyBpZXRmLXNtaW1lQGltYy5vcmcNCkNjOiBpZXRmLWx0YW5zQGltYy5vcmc7ICdUb2Jp YXMgR29uZHJvbSc7ICdSdXNzIEhvdXNsZXknDQpTdWJqZWN0OiBSRTogUkU6IFJFOiBDcm9zcyBy ZXZpZXcgb2YgZHJhZnQgRVJTIGZyb20gTFRBTlMgV0cgLSBSRTogV0cgTGFzdCBDYSBsbDpkcmFm dC1pZXRmLWx0YW5zLWVycy0wOS50eHQtIHVudGlsSmFuIDIzcmQNCg0KDQpDYXJsOg0KDQpJIHRo aW5rIERlbmlzIGFza3Mgc2ltcGx5IGZvciB0aGUganVzdGlmaWNhdGlvbiBmb3IgdGhlIGludHJv ZHVjdGlvbiBvZiBuZXcgdGVjaG5vbG9neSB0byBzb2x2ZSBhIHByb2JsZW0gd2hpY2ggbWF5IGFs cmVhZHkgYmUgc29sdmVkIHdpdGggYW4gZXhpc3RpbmcgSVNPIHN0YW5kYXJkICh3aGljaCBoYXMg YWxyZWFkeSBiZWVuIHB1Ymxpc2hlZCBhbmQgaXMgcHJlc3VtYWJseSBtb3JlIG1hdHVyZSB0aGFu IHdoYXQgaXMgYmVpbmcgcHJvcG9zZWQpLg0KDQpEZW5pcyBub3RlcyAoaW4gaGlzIHByZXZpb3Vz IGNvbW1lbnQpIHRoYXQgcGVyaGFwcyB0aGUgSVNPIHN0YW5kYXJkIG9mZmVycyB0b28gbWFueSBv cHRpb25zIGFuZCB0aGF0IHBlcmhhcHMgYSBQcm9maWxlIG9mIHRoaXMgSVNPIHN0YW5kYXJkIG1p Z2h0IGJlIHB1Ymxpc2hlZCBhcyBhbiBSRkMgdG8gdGFpbG9yIHRoZSBJU08gc3RhbmRhcmQgZm9y IHRoZSBzcGVjaWZpYyBhcHBsaWNhdGlvbihzKSB5b3UgaGF2ZSBpbiBtaW5kLiAgSW4gc3VjaCBh IGNhc2UgdGhlIFJGQyBzaG91bGQgcHJvZmlsZSAoc2VlIElTTy9JRUMgVFIxMDAwMCkgdGhlIElT TyBzdGFuZGFyZCBhbmQgbm90IGludHJvZHVjZSBuZXcgdGVjaG5vbG9neS4NCg0KVG9ueQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItaWV0Zi1zbWltZUBtYWlsLmlt Yy5vcmcgW21haWx0bzpvd25lci1pZXRmLXNtaW1lQG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9m IENhcmwgV2FsbGFjZQ0KU2VudDogSmFudWFyeSAxMSwgMjAwNyAxMDoxNiBBTQ0KVG86IERlbmlz IFBpbmthczsgaWV0Zi1zbWltZUBpbWMub3JnDQpDYzogaWV0Zi1sdGFuc0BpbWMub3JnOyBUb2Jp YXMgR29uZHJvbTsgUnVzcyBIb3VzbGV5DQpTdWJqZWN0OiBSRTogUkU6IFJFOiBDcm9zcyByZXZp ZXcgb2YgZHJhZnQgRVJTIGZyb20gTFRBTlMgV0cgLSBSRTogV0cgTGFzdCBDYSBsbDpkcmFmdC1p ZXRmLWx0YW5zLWVycy0wOS50eHQtIHVudGlsSmFuIDIzcmQNCg0KDQpNeSByZXNwb25zZSB3YXNu J3QgYSByZXZlcnNhbCBvZiB0aGUgcXVlc3Rpb24gYnV0IGEgcmVxdWVzdCBmb3IgZGV0YWlscy4g IEZvbGtzIG9uIHRoZSBsaXN0IGhhdmUgcHJldmlvdXNseSBkaXNjdXNzZWQgdGhlc2Ugc3BlY2lm aWNhdGlvbnMsIGluY2x1ZGluZyB0aGVpciB1c2Ugd2l0aGluIGFuIEV2aWRlbmNlUmVjb3JkLiAg WW91IG1hZGUgYSBzd2VlcGluZyBjb21tZW50IHRoYXQgbGFja2VkIGFueSBkZXRhaWxzIGFuZCBj YWxsZWQgZm9yIGZhaXJseSBkcmFzdGljIG1lYXN1cmVzLiAgSSBzaW1wbHkgYXNrZWQgZm9yIGp1 c3RpZmljYXRpb24uDQoNCg0KDQoNCkZyb206IERlbmlzIFBpbmthcyBbbWFpbHRvOmRlbmlzLnBp bmthc0BidWxsLm5ldF0gDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMSwgMjAwNyA5OjQ2IEFN DQpUbzogQ2FybCBXYWxsYWNlOyBpZXRmLXNtaW1lQGltYy5vcmcNCkNjOiBpZXRmLWx0YW5zQGlt Yy5vcmc7IFJ1c3MgSG91c2xleTsgVG9iaWFzIEdvbmRyb20NClN1YmplY3Q6IFJlOiBSRTogUkU6 IENyb3NzIHJldmlldyBvZiBkcmFmdCBFUlMgZnJvbSBMVEFOUyBXRyAtIFJFOiBXRyBMYXN0IENh IGxsOmRyYWZ0LWlldGYtbHRhbnMtZXJzLTA5LnR4dC0gdW50aWxKYW4gMjNyZA0KDQoNCkNhcmws DQoNClBsZWFzZSBkbyBub3QgcmV2ZXJzZSB0aGUgcXVlc3Rpb24uIElTTyAxODAxNC0zIGFscmVh ZHkgZXhpc3RzLiBUaGUgV0cgaGFzIHRvIGp1c3RpZnkgd2h5IGl0IHdvdWxkIG5vdCBmdWxmaWxs IGl0cyBuZWVkcy4NCkkgd2lsbCByZWZpbmUgbXkgcXVlc3Rpb246IFdoeSBpcyBhIHByb2ZpbGUg b2YgSVNPIDE4MDE0LTMgbm90IGFkZXF1YXRlIHRvIGZ1bGZpbGwgdGhlIG5lZWRzID8NCkEgcHJv ZmlsZSB3b3VsZCBtYWtlIHNlbnNlLCBzaW5jZSBJU08gMTgwMTQtMyBoYXMgbWFueSBvcHRpb25z Lg0KDQpEZW5pcw0K --=====003_Dragon810844471340_===== Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="iso-8859-1"

I said in an earlier e-mail: “The WG has to justify why it would not fulfill its needs”.

Carl has provided interesting information to explain the differences with ISO ISO-18014-3

and why ERS is different. The main advantage is the use of “ordinary” time-stamps rather

than time-stamps with specific extensions. However, this information should not be lost

and be used to write an informative annex.

 

There are indeed much more important topics.

 

ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn’it ?

 

However, many of the requirements that are present in the requirements document

are not met by the current ERS draft.

 

Here are a few examples :

1. ltans-reqs-10 defines an Archival Period as “The period during which an archived
data object is preserved by a long-term archive service”. How may a long term-archive 
service be held responsible of storing the data during that time-period, since 
the information to know the time period is not present in the ER ?
2. ltans-reqs-10 defines a Cryp!
tographic Maintenance Policy. There is no corresponding 
element in ERS. How can a long term-archive service know which maintenance to apply, 
since the information to perform the maintenance correctly is not present in ER ?

3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence 
that may be used to demonstrate the existence of an archived data object at a given time 
and the integrity of the archived data object since that time. The ER is supposed 
to be the basic piece of data to support that evidence. However, it is not signed 
by the long term-archive service, thus it cannot be used “to demonstrate the existence 
of an archived data object at a given time and the integrity of the archived data object 
since that time”.
4. ltans-reqs-10 adds on page 7: “Additionally, the evidence identifies the LTA(s) 
that have participated in the preservation of the archived data object”. However, 
ER does not contain the names of the LTA(s) that have participated in the preservation 
of the archived data object.
5. ltans-reqs-10 states on page 9: “A long-term archive service must operate in accordance 
with a long-term archive service policy that defines characteristics of the implementation 
of the long-term archive service”. However, ER does not contain a data item to support 
the “long-term archive service policy”. 
6. ltans-reqs-10 adds on page 10: “ Over the course of many years, the policies under which 
an LTA operates may undergo modification.  Thus, an evidence record may feature multiple 
indications of policies active at various points during the life of an archived data object.” 
However, the ER does not contain such an information.

7. ltans-reqs-10 states on page 11: “A long-term archive service must be capable of providing 
evidence that can be used to demonstrate the integrity of data for which it is responsible 
from the time it received the data until the expiration of the archival period of the data”. 
However, no data item is specified in ER to provide this evidence.

This means that much work is still needed on the document to fulfill the requirements.

 

Now, let us see what should be done. The following is obviously an unpolished strawman proposal.

 

In order to reduce the number of time stamps, it is necessary to be able to aggregate data
before applying a time stamp on it. For doing it, the following structure (close to the
structure of ArchiveTimeStamp, but different) would fulfill the need).

 

   TimeStampedNode ::= SEQUENCE {

     digestAlgorithm        [0] AlgorithmIdentifier OPTIONAL,

     archivalPolicy             ArchivalPolicy,

     archivalTimePeriod         ArchivalTimePeriod,

     cryptoMaintenancePolicy    CryptoMaintenancePolicy,

     reducedHashtree            SEQUENCE OF PartialHashtree,

     timeStamp                  TimeStampToken }

 

   PartialHashtree ::= SEQUENCE OF OCTET STRING

 

   ArchivalPolicy::= OBJECT IDENTIFIER

 

   ArchivalTimePeriod ::= SEQUENCE {

        notBefore      GeneralizedTime,

        notAfter       GeneralizedTime }

 

CryptoMaintenancePolicy would need more work to be defined, but basically
would contain a sequence of algorithm identifiers with their parameters.

 

The CryptoMaintenancePolicy applies to the data in the tree and to the crypto of
the time stamp token.

 

The hash included in the TimeStampToken is computed on the reducedHashtree element.

 

If this structure is signed by an agent from an archival service, then it can be used
to demonstrate that a given agent from an LTA has accepted to archive, under a given
policy for a given time period, the data items that are under the hash tree.

 

This means that TimeStampedNode must be the eContent of a CMS message signed by
an LTA agent in order to form a SignedNode.

 

Later on, the same, another or more LTA agents may need to add some other data to
a signed Node, without loosing the previous time-stamp and signature.

 

This leads to the following structure:

 

   EvidenceNode ::= SEQUENCE {

      version                        INTEGER { v1(1) } ,

      digestAlgorithms               SEQUENCE OF AlgorithmIdentifier,

      archivalPolicy                 ArchivalPolicy,

      archivalTimePeriod             ArchivalTimePeriod,

      cryptoMaintenancePolicy        CryptoMaintenancePolicy,

      evidenceRecord                 EvidenceRecord,

                                     -- the evidence record that serves

                                     -- for the construction

      signedNodeSequence             SignedNodeSequence   OPTIONAL,

                                     -- the elements that are added

                                     -- to the previous evidence

      timeStamp                      TimeStampToken }

 

with:

 

   signedNodeSequence ::= SEQUENCE OF SignedNode

 

The CryptoMaintenancePolicy applies to the previous evidence record, to all
the data that are in the tree and to the crypto of the time stamp token.

 

The hash included in the TimeStampToken is computed on the concatenation of the
evidenceRecord element and of the signedNodeSequence element.

 

This means that EvidenceNode must be the eContent of a CMS message signed by
an LTA agent in order to form an EvidenceRecord.

 

This new proposal fulfills the seven requirements mentioned here above.

 

Denis

 

Tony,
 
I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis.  However, I'll try to make the case in the other direction.
 
I don't think it's simply a case of too many options that require profiling.  One motivation often cited during the development of ERS is support for aggregations of data.  This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure.  This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again.
 
The ISO spec uses the ExtRenewal extension for timestamp renewal.  This is roughly analogous to the timestamp renewal feature in ERS.  However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed.  In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data.  In the ISO spec, an existing timestamp token is presented for renewal but the original data is not.  It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension).  I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS.  
 
ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations.  For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec.
 
Carl

From: Tony Capel [mailto:capel@comgate.com]
Sent: Thursday, January 11, 2007 11:04 AM
To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley'
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl:
 
I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed).
 
Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind.  In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology.
 
Tony

 

-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace
Sent: January 11, 2007 10:16 AM
To: Denis Pinkas; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

My response wasn't a reversal of the question but a request for details.  Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord.  You made a sweeping comment that lacked any details and called for fairly drastic measures.  I simply asked for justification.

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Thursday, January 11, 2007 9:46 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,
 
Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many options.
 
Denis
--=====003_Dragon810844471340_=====-- 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 l0BIKAAS080494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 11:20:10 -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 l0BIKAA4080492; Thu, 11 Jan 2007 11:20:10 -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 l0BIK7hw080481; Thu, 11 Jan 2007 11:20:08 -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 l0BIJrnh002492; Thu, 11 Jan 2007 19:19:58 +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_01C735AD.170DF02D" Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call:draft-ietf-ltans-ers-09.txt- untilJan 23rd Date: Thu, 11 Jan 2007 19:19:53 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B380B@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call:draft-ietf-ltans-ers-09.txt- untilJan 23rd Thread-Index: Acc1oyS94EAZ5ocYR1utQNa4AasSTAABn4GQ From: "Tobias Gondrom" To: "Carl Wallace" , "Tony Capel" , "Denis Pinkas" , Cc: , "Russ Housley" 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_01C735AD.170DF02D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony and Denis, =20 about 12 months LTANS investigated and discussed the relationship and use of other timestamps from the ISO-18014 family.=20 The result was that ISO-18014 timestamps/tokens could be used instead of the RFC-3161 timestamps within the ERS structure.=20 18014-3 definitely can not replace or even be directly compared to ERS - both specs refer to different goals and technical concepts.=20 It would be like comparing apples and oranges, to use a metaphor (for a comparison which is not valid).=20 =20 Tobias =20 =20 =20 ________________________________ From: Carl Wallace [mailto:CWallace@cygnacom.com]=20 Sent: Thursday, January 11, 2007 6:08 PM To: Tony Capel; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd =20 Tony, =20 I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis. However, I'll try to make the case in the other direction. =20 I don't think it's simply a case of too many options that require profiling. One motivation often cited during the development of ERS is support for aggregations of data. This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure. This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again. =20 The ISO spec uses the ExtRenewal extension for timestamp renewal. This is roughly analogous to the timestamp renewal feature in ERS. However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed. In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data. In the ISO spec, an existing timestamp token is presented for renewal but the original data is not. It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension). I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS. =20 =20 ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations. For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec. =20 Carl =20 =09 ________________________________ From: Tony Capel [mailto:capel@comgate.com]=20 Sent: Thursday, January 11, 2007 11:04 AM To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl: =20 I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed). =20 Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind. In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology. =20 Tony =20 -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for details. Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord. You made a sweeping comment that lacked any details and called for fairly drastic measures. I simply asked for justification. =20 =09 ________________________________ From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, =20 Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. =20 Denis ------_=_NextPart_001_01C735AD.170DF02D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Tony and = Denis,

 

about 12 months = LTANS investigated and discussed the relationship and use of other timestamps = from the ISO-18014 family.

The result was = that ISO-18014 timestamps/tokens could be used instead of the RFC-3161 = timestamps within the ERS structure.

18014-3 = definitely can not replace or even be directly compared to ERS – both specs refer to = different goals and technical concepts.

It would be like comparing apples and oranges, to use a metaphor (for a comparison which = is not valid).

 =

Tobias=

 =

 =

 =

From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Thursday, January = 11, 2007 6:08 PM
To: Tony Capel; 'Denis = Pinkas'; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Tobias Gondrom; 'Russ = Housley'
Subject: RE: RE: RE: = Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

 

Tony,

 

I think Denis should provide = additional details when calling for a working group item to be dropped, especially = when making this request this late in the process with non-freely available documents as the basis.  However, I'll try to make the case in the = other direction.

 

I don't think it's simply a case of = too many options that require profiling.  One motivation often cited = during the development of ERS is support for aggregations of data.  This = is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure.  This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation = when the initial timestamp is generated, when simple timestamp renewal = is required as well as when simple timestamp renewal is not sufficient and the = original data must be hashed again.

 

The ISO spec uses the ExtRenewal extension for timestamp renewal.  This is = roughly analogous to the timestamp renewal feature in ERS.  However, = there does not seem to be sufficient support for cases where the hash = algorithm is updated and the original data must be rehashed.  In ERS, when a = hash algorithm update is necessary, the preceding timestamp tokens are hashed = along with the original data.  In the ISO spec, an existing timestamp = token is presented for renewal but the original data is not.  It may be = possible to make this work using the extHash extension, but I don't see any = description of this in the current spec (nor do I see any text that describes = verification of the ExtRenewal extension).  I don't follow how the = aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to = ERS.  

 

ERS support for aggregation is more = clearly stated and ERS provides more complete handling of renewal operations.  For these reasons, I think we should proceed with ERS = instead of trying to enhance the ISO = spec.

 

Carl

 

From: Tony Capel [mailto:capel@comgate.com]
Sent: Thursday, January = 11, 2007 11:04 AM
To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ = Housley'
Subject: RE: RE: RE: = Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl:

 

I think Denis asks simply for the justification for the introduction of new technology to solve a = problem which may already be solved with an existing ISO standard (which has = already been published and is presumably more mature than what is being = proposed).

 

Denis notes (in his previous = comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the = ISO standard for the specific application(s) you have in mind.  In such = a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not = introduce new technology.

 

Tony

 

-----Original Message-----
From: = owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace
Sent: January 11, 2007 = 10:16 AM
To: Denis Pinkas; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ = Housley
Subject: RE: RE: RE: = Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

My response wasn't a reversal = of the question but a request for details.  Folks on the list have = previously discussed these specifications, including their use within an = EvidenceRecord.  You made a sweeping comment that lacked any details and called for = fairly drastic measures.  I simply asked for = justification.

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Thursday, January = 11, 2007 9:46 AM
To: Carl Wallace; = ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias = Gondrom
Subject: Re: RE: RE: = Cross review of draft ERS from LTANS WG - RE: WG Last Ca = ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,

 

Please do not reverse the question. ISO 18014-3 already exists. = The WG has to justify why it would not fulfill its = needs.

I will refine my question: Why is a profile of ISO 18014-3 not = adequate to fulfill the needs ?

A profile would make sense, since ISO 18014-3 has many = options.

 

Denis

------_=_NextPart_001_01C735AD.170DF02D-- 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 l0BI2HPJ078887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 11:02:17 -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 l0BI2HoY078886; Thu, 11 Jan 2007 11:02:17 -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 l0BI2E1x078861; Thu, 11 Jan 2007 11:02:15 -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 l0BI22cl001934; Thu, 11 Jan 2007 19:02:02 +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_01C735AA.984610C8" Subject: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd Date: Thu, 11 Jan 2007 19:02:01 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689B380A@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd Thread-Index: Acc1gFzEGX/G+TLQQ4eRM4UlAkbhxgAIkdbQ From: "Tobias Gondrom" To: "Denis Pinkas" Cc: , "Russ Housley" , "Carl Wallace" , Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C735AA.984610C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Denis,=20 =20 Thank you for your time and the review. As Carl already commented on most of your comments, and I fully agree with him, I will only add a few things: =20 1. At first to set one thing straight: The ERS document has been discussed extensively over the last two years and there have been literally hundreds of emails with comments and discussion about it on the mailing-list and there are world wide several companies who already implemented ERS some months ago (based o the draft versions 5-8 which are very similar to version 9). So I can only assume that you are not talking about ERS but about validate or ari, which are like add-ons to explain ERS further but still very young - those two documents documents are NOT in WGLC - only ERS! (note: the work on the next version of validate with the new second author is currently in progress and a new version should be ready in about 3-4 weeks.) =20 2. I will propose to LTANS improvements according to the last two comments in your review:=20 a) make the separation of the protection mechanisms clearer=20 > - the key of a Time-Stamping Unit has been compromised,=20 > - an asymmetric algorithm has been broken for a given key size,=20 > - a hash algorithm exhibits collisions.=20 and b) clarify whether Appendix A's annex is informative or normative and explain the benefits of including an EvidenceRecord as an unsigned attribute. =20 So again also from my side, thank you for your review. =20 Tobias =20 =20 =20 =20 =20 ________________________________ From: Carl Wallace [mailto:CWallace@cygnacom.com]=20 Sent: Thursday, January 11, 2007 2:00 PM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd =20 Comments inline...=20 > From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 > Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG=20 > Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd=20 >=20 >=20 > Nearly no comments were sent on the LTANS mailing list on=20 > these documents.=20 There is just one document that has been submitted for working group last call.=20 > It may be questionable why. The fact is that these documents=20 > are badly written, and thus it takes an enormous amount of=20 > time to attempt to understand them.=20 >=20 > Even though, most readers will fail, but will not dare to=20 > report that they did.=20 > I am unsure that I understood them, but I dare to report it.=20 >=20 > This draft and its companion documents namely=20 > draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00=20 > raise a number of questions to be solved.=20 These two drafts were prepared quickly in advance of the last working group meeting. During the meeting, a call was made for additional co-authors to help clarify and complete the documents. One person has joined Tobias in this effort but no follow-up drafts have been released yet. > Let us look now at the details of ERS.=20 >=20 > No ASN.1 compiler has been used to validate the syntax,=20 > otherwise, it would have been noticed that there is an=20 > obvious ASN.1 error on EvidenceRecord.=20 The ASN.1 was changed as a result of comments during the previous working group last call. Minor errors can be corrected without much cause for alarm. I assume in this case you are referring to the missing 's' at the end of EncryptionInfo. Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER. =20 >=20 > EvidenceRecord ::=3D SEQUENCE {=20 > version INTEGER { v1(1) } ,=20 > digestAlgorithms SEQUENCE OF AlgorithmIdentifier,=20 > cryptoInfos [0] CryptoInfos OPTIONAL,=20 > encryptionInfo [1] EncryptionInfo OPTIONAL,=20 > archiveTimeStampSequence ArchiveTimeStampSequence,=20 > ...=20 > }=20 >=20 > Later on the text defines ArchiveTimeStampSequence as:=20 >=20 > ArchiveTimeStampSequence ::=3D SEQUENCE OF=20 > ArchiveTimeStampChain and=20 >=20 > ArchiveTimeStampChain ::=3D SEQUENCE OF ArchiveTimeStamp=20 >=20 > and=20 >=20 > ArchiveTimeStamp ::=3D SEQUENCE {=20 > digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,=20 > reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,=20 > timeStamp ContentInfo}=20 >=20 > PartialHashtree ::=3D SEQUENCE OF OCTET STRING=20 >=20 > Note that this information is spread all around the document,=20 > rather than presented in sequence which does not ease its reading.=20 >=20 > ContentInfo is supposed to carry a TST. This means that=20 > timeStamp should be defined as TimeStampToken rather than ContentInfo. timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken to be used. =20 >=20 > There is no explanation in section 4.1 (top of page 11) to=20 > know on which data the digest contained in the TimeStampToken=20 > is computed.=20 This info appears in Section 4 (middle of page 10): "The root hash value, which represents unambiguously all data objects, is timestamped." >=20 > If another kind of time-stamp token would need to be carried,=20 > the syntax would need to be changed. This comes into=20 > contradiction with the following sentence :=20 >=20 > Other types of timestamp MAY be used, if they contain time data,=20 > timestamped data and a cryptographically secure=20 > confirmation from the=20 > TSA of these data.=20 See above.=20 >=20 > CryptoInfos from EvidenceRecord should be suppressed, since=20 > it is not proven that this additional item will ever be=20 > useful: encryption techniques may be different for each data=20 > item and thus cannot apply globally at the level of an EvidenceRecord. > EncryptionInfo should be suppressed too. No interoperability=20 > can be obtained on these two fields using this specification.=20 This comment was made during a previous last call and resulted in Tobias' posting to the list a few instances of structures that could be conveyed in these fields. These could be defined in a peer document or defined in this draft. =20 > ArchiveTimeStampSequence is a sequence of=20 > ArchiveTimeStampChain which is itself a sequence of=20 > ArchiveTimeStamp. However, there is no way to make a=20 > difference between an ArchiveTimeStampChain and an=20 > ArchiveTimeStampSequence.=20 The two are not used interchangably. Why is this a problem?=20 =20 > If within an EvidenceRecord, one element within of an=20 > archiveTimeStampSequence is suppressed (e.g. a=20 > ArchiveTimeStamp) this is not detectable. What is the real=20 > value of the EvidenceRecord structure ? One would expect that=20 > an EvidenceRecord includes a time stamp. However, it does not not.=20 Why would one element be suppressed? What would you want to have happen in this case? As-is, verification would fail. I have commented previously that it might be better if the chain supported shallow verification, which would enable you to suppress a contiguous set of elements from the beginning of the chain up to the point from which verification was desired. There was no support for making a change along these lines, and there seemed to be no real need to have this feature. =20 What do you mean the EvidenceRecord does not include a timestamp? It includes ArchiveTimeStampSequence, which may have one or more timestamps. =20 > The current draft does not allow to apply the processing=20 > recursively. Having constructed one EvidenceRecord (that=20 > would include a time stamp), it is currently not possible to=20 > construct another one using a previous one.=20 An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence. The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence. I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer alternative suggestions. =20 =20 > This document is supposed to apply to a long term archive=20 > service. However, there is no signature from an archive=20 > service. The TSA should not be confused with a Archive=20 > Authority. With the current structure the Archive service may=20 > not be held responsible of the storage of the data.=20 This document defines a syntax for representing a chain of cryptographic evidence. This syntax may be used by an archive service. However, no archive service is required to produce an evidence record. Archive service signatures are addressed in the context of a protocol for interacting with an archive service. =20 > The draft claims to protect against weak algorithms or keys.=20 > However, it does not make a clear and clean separation=20 > between the cases of :=20 >=20 > - the key of a Time-Stamping Unit has been compromised,=20 > - an asymmetric algorithm has been broken for a given key size,=20 > - a hash algorithm exhibits collisions.=20 >=20 > With "Timestamp renewal" the text omits to say that it is=20 > necessary using "out of bands means" that a given key from a=20 > Time Stamping Unit has been compromised or a that given=20 > asymmetric algorithm has been broken for a given key size.=20 This should be clarified.=20 >=20 > "Hash-Tree renewal" would apply when hash algorithm exhibits=20 > collisions. However a complete reconstruction is needed and=20 > it is not clearly explained which data from the previous=20 > structure may re-used.=20 >=20 > Appendix A contains an annex and it is not said whether it is=20 > informative or normative.=20 > Nevertheless, the benefits of the inclusion of an=20 > EvidenceRecord as an unsigned attribute are not explained.=20 > The advantages and drawbacks of each case is not explained either.=20 Good point.=20 >=20 > CONCLUSION=20 >=20 > In my opinion, none of these documents is ready to be sent to=20 > the IESG and it does not make sense to send ERS alone. The=20 > usefulness of the whole work is very questionable. These=20 > documents are not mature and contain numerous typos.=20 We should not cloud the review of ERS by referring to typos in -ari and -validate.=20 =20 > The primary question is : " Is this work really needed ?". SC=20 > 27 has issued ISO 18014-3:=20 > "Time-stamp services. Mechanisms producing linked tokens"=20 > that is very close.=20 >=20 > It would be interesting that the authors position their=20 > documents towards the ISO standard. Duplication of work=20 > should be avoided. If there is no duplication, then this=20 > should be explained in an informative annex. If no acceptable=20 > explanations may be given, then this work should be stopped.=20 The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats. >=20 > P.S. I spent several hours to read the documents and to write=20 > this message,=20 > but I do not have the time available to sustain long=20 > discussions on that topic.=20 Thanks for the review.=20 >=20 > Denis=20 >=20 ------_=_NextPart_001_01C735AA.984610C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd

Hi Denis, =

 =

Thank you for = your time and the review. As Carl already commented on most of your comments, and I = fully agree with him, I will only add a few things:

 =

1. At first to = set one thing straight:

The ERS document = has been discussed extensively over the last two years and there have been = literally hundreds of emails with comments and discussion about it on the mailing-list and = there are world wide several companies who already implemented ERS some months = ago (based o the draft versions 5-8 which are very similar to version 9). So = I can only assume that you are not talking about ERS but about validate or = ari, which are like add-ons to explain ERS further but still very young =  – those two documents documents are NOT in WGLC – only = ERS!

(note: the work = on the next version of validate with the new second author is currently in progress = and a new version should be ready in about 3-4 = weeks.)

 =

2. I will = propose to LTANS improvements according to the last two comments in your review: =

a) make the = separation of the protection mechanisms clearer

> -     the key of a Time-Stamping Unit has been compromised,
> -     an asymmetric algorithm has been broken for a = given key size,
> -     a hash algorithm exhibits = collisions.
and

b) clarify = whether Appendix A’s annex is informative or normative and explain the = benefits of including an EvidenceRecord as an unsigned = attribute.

 =

So again also = from my side, thank you for your review.

 =

   = ;         = Tobias

 =

 =

 =

 =

 =

From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Thursday, January = 11, 2007 2:00 PM
To: Denis Pinkas; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias = Gondrom
Subject: RE: Cross review = of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until = Jan 23rd

 

Comments inline...

> From: Denis Pinkas [mailto:denis.pinkas@bull.net]
> Subject: Re: Cross = review of draft ERS from LTANS WG - RE: WG
> Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd
>
>
> Nearly no comments = were sent on the LTANS mailing list on
> these documents. =

There is just one document that has been submitted for working group last = call.

> It may be questionable why. The fact is that these documents =
> are badly written, = and thus it takes an enormous amount of
> time to attempt to = understand them.
>
> Even though, most = readers will fail, but will not dare to
> report that they = did.
> I am unsure that I = understood them, but I dare to report it.
>
> This draft and its = companion documents namely
> = draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00
> raise a number of = questions to be solved.

These two drafts were prepared quickly in advance of the last working group meeting.  During the meeting, a call was made for additional = co-authors to help clarify and complete the documents.  One person has joined = Tobias in this effort but no follow-up drafts have been released = yet.

> Let us look now at the details of ERS.
>
> No ASN.1 compiler = has been used to validate the syntax,
> otherwise, it would = have been noticed that there is an
> obvious ASN.1 error = on EvidenceRecord.

The ASN.1 was changed as a result of comments during the previous working group = last call.  Minor errors can be corrected without much cause for = alarm.  I assume in this case you are referring to the missing 's' at the end of = EncryptionInfo.  Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External = values are missing OBJECT IDENTIFIER. 

>
>    EvidenceRecord ::=3D SEQUENCE {
>       version           =         INTEGER { v1(1) } ,
>       digestAlgorithms          = SEQUENCE OF AlgorithmIdentifier,
>       cryptoInfos          &n= bsp;    [0] CryptoInfos OPTIONAL,
>       encryptionInfo          = ;  [1] EncryptionInfo OPTIONAL,
>       archiveTimeStampSequence  ArchiveTimeStampSequence, =
>       ...
>       }
>
> Later on the text = defines ArchiveTimeStampSequence as:
>
>    ArchiveTimeStampSequence ::=3D SEQUENCE OF
>       =             &= nbsp;           &n= bsp; ArchiveTimeStampChain and
>
>    ArchiveTimeStampChain ::=3D SEQUENCE OF ArchiveTimeStamp =
>
> and =
>
>    = ArchiveTimeStamp ::=3D SEQUENCE {
>      digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
>      reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, =
>      timeStamp       ContentInfo} =
>
>    PartialHashtree ::=3D SEQUENCE OF OCTET STRING
>
> Note that this = information is spread all around the document,
> rather than = presented in sequence which does not ease its reading.
>
> ContentInfo is = supposed to carry a TST. This means that
> timeStamp should be = defined as TimeStampToken rather than ContentInfo.

timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken = to be used. 

>
> There is no = explanation in section 4.1 (top of page 11) to
> know on which data = the digest contained in the TimeStampToken
> is computed. =

This info appears in Section 4 (middle of page 10): "The root hash value, = which represents unambiguously all data objects, is = timestamped."

>
> If another kind of = time-stamp token would need to be carried,
> the syntax would = need to be changed. This comes into
> contradiction with = the following sentence :
>
>    = Other types of timestamp MAY be used, if they contain time data,
>    = timestamped data and a cryptographically secure
> confirmation from = the
>    = TSA of these data.

See above.

>
> CryptoInfos from EvidenceRecord should be suppressed, since
> it is not proven = that this additional item will ever be
> useful: encryption = techniques may be different for each data
> item and thus = cannot apply globally at the level of an EvidenceRecord.
> EncryptionInfo = should be suppressed too. No interoperability
> can be obtained on = these two fields using this specification.

This comment was made during a previous last call and resulted in Tobias' = posting to the list a few instances of structures that could be conveyed in these fields.  These could be defined in a peer document or defined in = this draft.

 
> = ArchiveTimeStampSequence is a sequence of
> = ArchiveTimeStampChain which is itself a sequence of
> ArchiveTimeStamp. = However, there is no way to make a
> difference between = an ArchiveTimeStampChain and an
> = ArchiveTimeStampSequence.

The two are not used interchangably.  Why is this a problem? =
  =
> If within an = EvidenceRecord, one element within of an
> = archiveTimeStampSequence is suppressed (e.g. a
> ArchiveTimeStamp) = this is not detectable. What is the real
> value of the = EvidenceRecord structure ? One would expect that
> an EvidenceRecord = includes a time stamp. However, it does not not.

Why would one element be suppressed?  What would you want to have happen in = this case?  As-is, verification would fail.  I have commented = previously that it might be better if the chain supported shallow verification, = which would enable you to suppress a contiguous set of elements from the = beginning of the chain up to the point from which verification was desired.  = There was no support for making a change along these lines, and there seemed to be = no real need to have this feature. 

What do you mean the EvidenceRecord does not include a timestamp?  It = includes ArchiveTimeStampSequence, which may have one or more = timestamps.

 
> The current draft = does not allow to apply the processing
> recursively. Having constructed one EvidenceRecord (that
> would include a = time stamp), it is currently not possible to
> construct another = one using a previous one.

An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence.  = The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to = add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer = alternative suggestions. 

 
> This document is = supposed to apply to a long term archive
> service. However, = there is no signature from an archive
> service. The TSA = should not be confused with a Archive
> Authority. With the = current structure the Archive service may
> not be held = responsible of the storage of the data.

This document defines a syntax for representing a chain of cryptographic evidence.  This syntax may be used by an archive service.  = However, no archive service is required to produce an evidence record.  = Archive service signatures are addressed in the context of a protocol for interacting = with an archive service.

 
> The draft claims to = protect against weak algorithms or keys.
> However, it does = not make a clear and clean separation
> between the cases = of :
>
> = -     the key of a Time-Stamping Unit has been compromised,
> = -     an asymmetric algorithm has been broken for a given key size, =
> = -     a hash algorithm exhibits collisions.
>
> With = "Timestamp renewal" the text omits to say that it is
> necessary using = "out of bands means" that a given key from a
> Time Stamping Unit = has been compromised or a that given
> asymmetric = algorithm has been broken for a given key size.

This should be clarified.

>
> "Hash-Tree = renewal" would apply when hash algorithm exhibits
> collisions. However = a complete reconstruction is needed and
> it is not clearly = explained which data from the previous
> structure may = re-used.
>
> Appendix A contains = an annex and it is not said whether it is
> informative or = normative.
> Nevertheless, the = benefits of the inclusion of an
> EvidenceRecord as = an unsigned attribute are not explained.
> The advantages and = drawbacks of each case is not explained either.

Good point.

>
> = CONCLUSION
>
> In my opinion, none = of these documents is ready to be sent to
> the IESG and it = does not make sense to send ERS alone. The
> usefulness of the = whole work is very questionable. These
> documents are not = mature and contain numerous typos.

We should not cloud the review of ERS by referring to typos in -ari and = -validate.
  =
> The primary = question is : " Is this work really needed ?". SC
> 27 has issued ISO = 18014-3:
> "Time-stamp = services. Mechanisms producing linked tokens"
> that is very = close.
>
> It would be = interesting that the authors position their
> documents towards = the ISO standard. Duplication of work
> should be avoided. = If there is no duplication, then this
> should be explained = in an informative annex. If no acceptable
> explanations may be = given, then this work should be stopped.

The ISO drafts have been discussed on the list and are referenced by this = document as a source for alternative timestamp formats.

>
> P.S. I spent = several hours to read the documents and to write
> this message, =
>       =   but I do not have the time available to sustain long
> discussions on that = topic.

Thanks for the review.

>
> Denis =
> =

------_=_NextPart_001_01C735AA.984610C8-- 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 l0BH8Ua1075040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 10:08:31 -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 l0BH8UBf075039; Thu, 11 Jan 2007 10:08:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0BH8SoO075026 for ; Thu, 11 Jan 2007 10:08:29 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 26767 invoked from network); 11 Jan 2007 17:07:48 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jan 2007 17:07:48 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 11 Jan 2007 17:07:48 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Jan 2007 12:08:27 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D6B7@scygmxs1.cygnacom.com> From: Carl Wallace To: Tony Capel , "'Denis Pinkas'" , ietf-smime@imc.org Cc: ietf-ltans@imc.org, "'Tobias Gondrom'" , "'Russ Housley'" Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Las t Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Date: Thu, 11 Jan 2007 12:08:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C735A3.1C18511A" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C735A3.1C18511A Content-Type: text/plain Tony, I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis. However, I'll try to make the case in the other direction. I don't think it's simply a case of too many options that require profiling. One motivation often cited during the development of ERS is support for aggregations of data. This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure. This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again. The ISO spec uses the ExtRenewal extension for timestamp renewal. This is roughly analogous to the timestamp renewal feature in ERS. However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed. In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data. In the ISO spec, an existing timestamp token is presented for renewal but the original data is not. It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension). I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS. ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations. For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec. Carl _____ From: Tony Capel [mailto:capel@comgate.com] Sent: Thursday, January 11, 2007 11:04 AM To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley' Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl: I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed). Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind. In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology. Tony -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for details. Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord. You made a sweeping comment that lacked any details and called for fairly drastic measures. I simply asked for justification. _____ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis ------_=_NextPart_001_01C735A3.1C18511A Content-Type: text/html Message
Tony,
 
I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis.  However, I'll try to make the case in the other direction.
 
I don't think it's simply a case of too many options that require profiling.  One motivation often cited during the development of ERS is support for aggregations of data.  This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure.  This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again.
 
The ISO spec uses the ExtRenewal extension for timestamp renewal.  This is roughly analogous to the timestamp renewal feature in ERS.  However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed.  In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data.  In the ISO spec, an existing timestamp token is presented for renewal but the original data is not.  It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension).  I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS.  
 
ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations.  For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec.
 
Carl

From: Tony Capel [mailto:capel@comgate.com]
Sent: Thursday, January 11, 2007 11:04 AM
To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; 'Tobias Gondrom'; 'Russ Housley'
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl:
 
I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed).
 
Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind.  In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology.
 
Tony

 

-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace
Sent: January 11, 2007 10:16 AM
To: Denis Pinkas; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

My response wasn't a reversal of the question but a request for details.  Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord.  You made a sweeping comment that lacked any details and called for fairly drastic measures.  I simply asked for justification.

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Thursday, January 11, 2007 9:46 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,
 
Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many options.
 
Denis
------_=_NextPart_001_01C735A3.1C18511A-- 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 l0BG4UQd069159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 09:04:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0BG4Ubp069158; Thu, 11 Jan 2007 09:04:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2-6.spamtrap.magma.ca (mx2-6.spamtrap.magma.ca [209.217.78.165]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0BG4SrR069148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 09:04:29 -0700 (MST) (envelope-from capel@comgate.com) Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx2-6.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l0BG4JIO005255; Thu, 11 Jan 2007 11:04:19 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l0BG4DU8020173; Thu, 11 Jan 2007 11:04:19 -0500 From: "Tony Capel" To: "'Carl Wallace'" , "'Denis Pinkas'" , Cc: , "'Tobias Gondrom'" , "'Russ Housley'" Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Date: Thu, 11 Jan 2007 11:04:09 -0500 Message-ID: <001601c7359a$227028c0$02b5a8c0@tony> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C73570.399A20C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1C41D6A9@scygmxs1.cygnacom.com> Importance: Normal X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: 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_0017_01C73570.399A20C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Carl: =20 I think Denis asks simply for the justification for the introduction of = new technology to solve a problem which may already be solved with an = existing ISO standard (which has already been published and is presumably more mature = than what is being proposed). =20 Denis notes (in his previous comment) that perhaps the ISO standard = offers too many options and that perhaps a Profile of this ISO standard might be = published as an RFC to tailor the ISO standard for the specific application(s) you = have in mind. In such a case the RFC should profile (see ISO/IEC TR10000) the = ISO standard and not introduce new technology. =20 Tony =20 -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl Wallace Sent: January 11, 2007 10:16 AM To: Denis Pinkas; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Tobias Gondrom; Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG = Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd My response wasn't a reversal of the question but a request for details. = Folks on the list have previously discussed these specifications, including = their use within an EvidenceRecord. You made a sweeping comment that lacked any = details and called for fairly drastic measures. I simply asked for = justification. _____ =20 From: Denis Pinkas [mailto:denis.pinkas@bull.net]=20 Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG = Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, =20 Please do not reverse the question. ISO 18014-3 already exists. The WG = has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate = to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. =20 Denis ------=_NextPart_000_0017_01C73570.399A20C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Carl:
 
I=20 think Denis asks simply for the justification for the introduction = of new=20 technology to solve a problem which may already be solved with an = existing ISO=20 standard (which has already been published and is presumably more mature = than=20 what is being proposed).
 
Denis notes (in his previous comment) = that perhaps=20 the ISO standard offers too many options and that perhaps a Profile of = this ISO=20 standard might be published as an RFC to tailor the ISO standard for the = specific application(s) you have in mind.  In such a case the RFC = should=20 profile (see ISO/IEC TR10000) the ISO standard and not introduce new=20 technology.
 
Tony

 

-----Original Message-----
From: = owner-ietf-smime@mail.imc.org=20 [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Carl=20 Wallace
Sent: January 11, 2007 10:16 AM
To: Denis = Pinkas;=20 ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Tobias Gondrom; = Russ=20 Housley
Subject: RE: RE: RE: Cross review of draft ERS from = LTANS WG -=20 RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan=20 23rd

My response wasn't a reversal of the = question but a=20 request for details.  Folks on the list have previously discussed = these=20 specifications, including their use within an EvidenceRecord.  You = made a=20 sweeping comment that lacked any details and called for fairly drastic=20 measures.  I simply asked for = justification.

From: Denis Pinkas=20 [mailto:denis.pinkas@bull.net]
Sent: Thursday, January 11, = 2007=20 9:46 AM
To: Carl Wallace; ietf-smime@imc.org
Cc:=20 ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: = Re: RE:=20 RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca=20 ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,
 
Please do not reverse the question. ISO 18014-3 already exists. = The WG=20 has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not = adequate=20 to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many=20 options.
 
Denis
------=_NextPart_000_0017_01C73570.399A20C0-- 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 l0BFGDnF064267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 08:16:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0BFGD09064265; Thu, 11 Jan 2007 08:16:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0BFGAlu064236 for ; Thu, 11 Jan 2007 08:16:13 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 16490 invoked from network); 11 Jan 2007 15:15:30 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jan 2007 15:15:30 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 11 Jan 2007 15:15:30 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Jan 2007 10:16:09 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D6A9@scygmxs1.cygnacom.com> From: Carl Wallace To: Denis Pinkas , ietf-smime@imc.org Cc: ietf-ltans@imc.org, Tobias Gondrom , Russ Housley Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Las t Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Date: Thu, 11 Jan 2007 10:16:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73593.6AB6E266" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73593.6AB6E266 Content-Type: text/plain My response wasn't a reversal of the question but a request for details. Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord. You made a sweeping comment that lacked any details and called for fairly drastic measures. I simply asked for justification. _____ From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Thursday, January 11, 2007 9:46 AM To: Carl Wallace; ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd Carl, Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis ------_=_NextPart_001_01C73593.6AB6E266 Content-Type: text/html
My response wasn't a reversal of the question but a request for details.  Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord.  You made a sweeping comment that lacked any details and called for fairly drastic measures.  I simply asked for justification.

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Thursday, January 11, 2007 9:46 AM
To: Carl Wallace; ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,
 
Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many options.
 
Denis
------_=_NextPart_001_01C73593.6AB6E266-- 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 l0BEjmAG061884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 07:45:48 -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 l0BEjmNY061883; Thu, 11 Jan 2007 07:45:48 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0BEjjRv061870; Thu, 11 Jan 2007 07:45:46 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA33758; Thu, 11 Jan 2007 15:49:13 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011115453925:73730 ; Thu, 11 Jan 2007 15:45:39 +0100 Date: Thu, 11 Jan 2007 15:45:37 +0100 From: "Denis Pinkas" To: "Carl Wallace" , "ietf-smime@imc.org" Cc: "ietf-ltans@imc.org" , "Russ Housley" , "Tobias Gondrom" Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 15:45:39, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 15:45:40, Serialize complete at 11/01/2007 15:45:40 Message-ID: Content-Type: multipart/alternative; boundary="=====003_Dragon467742503416_=====" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --=====003_Dragon467742503416_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Carl, Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs. I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ? A profile would make sense, since ISO 18014-3 has many options. Denis From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Thursday, January 11, 2007 8:50 AM To: ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd Thank you for your quick response. I will make a quicker answer. You said: " The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats". Why is the ISO format insufficient ? Why was there a need to develop these documents ? Unless the responses to these questions are given and added to the document, I do not think that the documents should continue to progress. [CRW] Can you summarize why you feel the ISO formats obviate the need for ERS? Other working group members have sought to use these formats as alternatives to RFC3161 timestamps within an EvidenceRecord. --=====003_Dragon467742503416_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="iso-8859-1"
Carl,
 
Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many options.
 
Denis
 
 
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas
Sent: Thursday, January 11, 2007 8:50 AM
To: ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd

Thank you for your quick response. I will make a quicker answer. You said:
 
" The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats".
 
Why is the ISO format insufficient ? Why was there a need to develop these documents ?
Unless the responses to these questions are given and added to the document,
I do not think that the documents should continue to progress. 
[CRW] Can you summarize why you feel the ISO formats obviate the need for ERS?  Other working group members have sought to use these formats as alternatives to RFC3161 timestamps within an EvidenceRecord.
--=====003_Dragon467742503416_=====-- 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 l0BEOKVx059790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 07:24:20 -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 l0BEOKxB059788; Thu, 11 Jan 2007 07:24:20 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0BEOIb4059767 for ; Thu, 11 Jan 2007 07:24:19 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 11137 invoked from network); 11 Jan 2007 14:23:39 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jan 2007 14:23:39 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 11 Jan 2007 14:23:39 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Jan 2007 09:24:17 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D69F@scygmxs1.cygnacom.com> From: Carl Wallace To: Denis Pinkas , ietf-smime@imc.org Cc: ietf-ltans@imc.org, Russ Housley , Tobias Gondrom Subject: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll: draft-ietf-ltans-ers-09.txt- untilJan 23rd Date: Thu, 11 Jan 2007 09:24:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7358C.2C7FA53E" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7358C.2C7FA53E Content-Type: text/plain _____ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Thursday, January 11, 2007 8:50 AM To: ietf-smime@imc.org Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom Subject: Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd Thank you for your quick response. I will make a quicker answer. You said: " The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats". Why is the ISO format insufficient ? Why was there a need to develop these documents ? Unless the responses to these questions are given and added to the document, I do not think that the documents should continue to progress. [CRW] Can you summarize why you feel the ISO formats obviate the need for ERS? Other working group members have sought to use these formats as alternatives to RFC3161 timestamps within an EvidenceRecord. ------_=_NextPart_001_01C7358C.2C7FA53E Content-Type: text/html
 
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas
Sent: Thursday, January 11, 2007 8:50 AM
To: ietf-smime@imc.org
Cc: ietf-ltans@imc.org; Russ Housley; Tobias Gondrom
Subject: Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd

Thank you for your quick response. I will make a quicker answer. You said:
 
" The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats".
 
Why is the ISO format insufficient ? Why was there a need to develop these documents ?
Unless the responses to these questions are given and added to the document,
I do not think that the documents should continue to progress. 
[CRW] Can you summarize why you feel the ISO formats obviate the need for ERS?  Other working group members have sought to use these formats as alternatives to RFC3161 timestamps within an EvidenceRecord.
------_=_NextPart_001_01C7358C.2C7FA53E-- 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 l0BDo0OH055914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 06:50:00 -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 l0BDo0J6055910; Thu, 11 Jan 2007 06:50:00 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0BDnuid055891; Thu, 11 Jan 2007 06:49:57 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA34802; Thu, 11 Jan 2007 14:53:28 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011114495446:72105 ; Thu, 11 Jan 2007 14:49:54 +0100 Date: Thu, 11 Jan 2007 14:49:51 +0100 From: "Denis Pinkas" To: "ietf-smime@imc.org" Cc: "ietf-ltans@imc.org" , "Russ Housley" , "Tobias Gondrom" Subject: Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 14:49:54, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 14:49:55, Serialize complete at 11/01/2007 14:49:55 Message-ID: Content-Type: multipart/alternative; boundary="=====003_Dragon665334633732_=====" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --=====003_Dragon665334633732_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Thank you for your quick response. I will make a quicker answer. You said: " The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats". Why is the ISO format insufficient ? Why was there a need to develop these documents ? Unless the responses to these questions are given and added to the document, I do not think that the documents should continue to progress. Denis Comments inline... > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG > Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd > > > Nearly no comments were sent on the LTANS mailing list on > these documents. There is just one document that has been submitted for working group last call. > It may be questionable why. The fact is that these documents > are badly written, and thus it takes an enormous amount of > time to attempt to understand them. > > Even though, most readers will fail, but will not dare to > report that they did. > I am unsure that I understood them, but I dare to report it. > > This draft and its companion documents namely > draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00 > raise a number of questions to be solved. These two drafts were prepared quickly in advance of the last working group meeting. During the meeting, a call was made for additional co-authors to help clarify and complete the documents. One person has joined Tobias in this effort but no follow-up drafts have been released yet. > Let us look now at the details of ERS. > > No ASN.1 compiler has been used to validate the syntax, > otherwise, it would have been noticed that there is an > obvious ASN.1 error on EvidenceRecord. The ASN.1 was changed as a result of comments during the previous working group last call. Minor errors can be corrected without much cause for alarm. I assume in this case you are referring to the missing 's' at the end of EncryptionInfo. Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER. > > EvidenceRecord ::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > cryptoInfos [0] CryptoInfos OPTIONAL, > encryptionInfo [1] EncryptionInfo OPTIONAL, > archiveTimeStampSequence ArchiveTimeStampSequence, > ... > } > > Later on the text defines ArchiveTimeStampSequence as: > > ArchiveTimeStampSequence ::= SEQUENCE OF > ArchiveTimeStampChain and > > ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp > > and > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, > reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > Note that this information is spread all around the document, > rather than presented in sequence which does not ease its reading. > > ContentInfo is supposed to carry a TST. This means that > timeStamp should be defined as TimeStampToken rather than ContentInfo. timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken to be used. > > There is no explanation in section 4.1 (top of page 11) to > know on which data the digest contained in the TimeStampToken > is computed. This info appears in Section 4 (middle of page 10): "The root hash value, which represents unambiguously all data objects, is timestamped." > > If another kind of time-stamp token would need to be carried, > the syntax would need to be changed. This comes into > contradiction with the following sentence : > > Other types of timestamp MAY be used, if they contain time data, > timestamped data and a cryptographically secure > confirmation from the > TSA of these data. See above. > > CryptoInfos from EvidenceRecord should be suppressed, since > it is not proven that this additional item will ever be > useful: encryption techniques may be different for each data > item and thus cannot apply globally at the level of an EvidenceRecord. > EncryptionInfo should be suppressed too. No interoperability > can be obtained on these two fields using this specification. This comment was made during a previous last call and resulted in Tobias' posting to the list a few instances of structures that could be conveyed in these fields. These could be defined in a peer document or defined in this draft. > ArchiveTimeStampSequence is a sequence of > ArchiveTimeStampChain which is itself a sequence of > ArchiveTimeStamp. However, there is no way to make a > difference between an ArchiveTimeStampChain and an > ArchiveTimeStampSequence. The two are not used interchangably. Why is this a problem? > If within an EvidenceRecord, one element within of an > archiveTimeStampSequence is suppressed (e.g. a > ArchiveTimeStamp) this is not detectable. What is the real > value of the EvidenceRecord structure ? One would expect that > an EvidenceRecord includes a time stamp. However, it does not not. Why would one element be suppressed? What would you want to have happen in this case? As-is, verification would fail. I have commented previously that it might be better if the chain supported shallow verification, which would enable you to suppress a contiguous set of elements from the beginning of the chain up to the point from which verification was desired. There was no support for making a change along these lines, and there seemed to be no real need to have this feature. What do you mean the EvidenceRecord does not include a timestamp? It includes ArchiveTimeStampSequence, which may have one or more timestamps. > The current draft does not allow to apply the processing > recursively. Having constructed one EvidenceRecord (that > would include a time stamp), it is currently not possible to > construct another one using a previous one. An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence. The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence. I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer alternative suggestions. > This document is supposed to apply to a long term archive > service. However, there is no signature from an archive > service. The TSA should not be confused with a Archive > Authority. With the current structure the Archive service may > not be held responsible of the storage of the data. This document defines a syntax for representing a chain of cryptographic evidence. This syntax may be used by an archive service. However, no archive service is required to produce an evidence record. Archive service signatures are addressed in the context of a protocol for interacting with an archive service. > The draft claims to protect against weak algorithms or keys. > However, it does not make a clear and clean separation > between the cases of : > > - the key of a Time-Stamping Unit has been compromised, > - an asymmetric algorithm has been broken for a given key size, > - a hash algorithm exhibits collisions. > > With "Timestamp renewal" the text omits to say that it is > necessary using "out of bands means" that a given key from a > Time Stamping Unit has been compromised or a that given > asymmetric algorithm has been broken for a given key size. This should be clarified. > > "Hash-Tree renewal" would apply when hash algorithm exhibits > collisions. However a complete reconstruction is needed and > it is not clearly explained which data from the previous > structure may re-used. > > Appendix A contains an annex and it is not said whether it is > informative or normative. > Nevertheless, the benefits of the inclusion of an > EvidenceRecord as an unsigned attribute are not explained. > The advantages and drawbacks of each case is not explained either. Good point. > > CONCLUSION > > In my opinion, none of these documents is ready to be sent to > the IESG and it does not make sense to send ERS alone. The > usefulness of the whole work is very questionable. These > documents are not mature and contain numerous typos. We should not cloud the review of ERS by referring to typos in -ari and -validate. > The primary question is : " Is this work really needed ?". SC > 27 has issued ISO 18014-3: > "Time-stamp services. Mechanisms producing linked tokens" > that is very close. > > It would be interesting that the authors position their > documents towards the ISO standard. Duplication of work > should be avoided. If there is no duplication, then this > should be explained in an informative annex. If no acceptable > explanations may be given, then this work should be stopped. The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats. > > P.S. I spent several hours to read the documents and to write > this message, > but I do not have the time available to sustain long > discussions on that topic. Thanks for the review. > > Denis > --=====003_Dragon665334633732_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="iso-8859-1"
Thank you for your quick response. I will make a quicker answer. You said:
 
" The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats".
 
Why is the ISO format insufficient ? Why was there a need to develop these documents ?
Unless the responses to these questions are given and added to the document,
I do not think that the documents should continue to progress.
 
Denis
 

Comments inline...

> From: Denis Pinkas [mailto:denis.pinkas@bull.net]
> Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG
> Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd
>
>
> Nearly no comments were sent on the LTANS mailing list on
> these documents.

There is just one document that has been submitted for working group last call.

> It may be questionable why. The fact is that these documents
> are badly written, and thus it takes an enormous amount of
> time to attempt to understand them.
>
> Even though, most readers will fail, but will not dare to
> report that they did.
> I am unsure that I understood them, but I dare to report it.
>
> This draft and its companion documents namely
> draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00
> raise a number of questions to be solved.

These two drafts were prepared quickly in advance of the last working group meeting.  During the meeting, a call was made for additional co-authors to help clarify and complete the documents.  One person has joined Tobias in this effort but no follow-up drafts have been released yet.

> Let us look now at the details of ERS.
>
> No ASN.1 compiler has been used to validate the syntax,
> otherwise, it would have been noticed that there is an
> obvious ASN.1 error on EvidenceRecord.

The ASN.1 was changed as a result of comments during the previous working group last call.  Minor errors can be corrected without much cause for alarm.  I assume in this case you are referring to the missing 's' at the end of EncryptionInfo.  Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER. 

>
>    EvidenceRecord ::= SEQUENCE {
>       version                   INTEGER { v1(1) } ,
>       digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
>       cryptoInfos               [0] CryptoInfos OPTIONAL,
>       encryptionInfo            [1] EncryptionInfo OPTIONAL,
>       archiveTimeStampSequence  ArchiveTimeStampSequence,
>       ...
>       }
>
> Later on the text defines ArchiveTimeStampSequence as:
>
>    ArchiveTimeStampSequence ::= SEQUENCE OF
>                                 ArchiveTimeStampChain and
>
>    ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
>
> and
>
>    ArchiveTimeStamp ::= SEQUENCE {
>      digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
>      reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
>      timeStamp       ContentInfo}
>
>    PartialHashtree ::= SEQUENCE OF OCTET STRING
>
> Note that this information is spread all around the document,
> rather than presented in sequence which does not ease its reading.
>
> ContentInfo is supposed to carry a TST. This means that
> timeStamp should be defined as TimeStampToken rather than ContentInfo.

timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken to be used. 

>
> There is no explanation in section 4.1 (top of page 11) to
> know on which data the digest contained in the TimeStampToken
> is computed.

This info appears in Section 4 (middle of page 10): "The root hash value, which represents unambiguously all data objects, is timestamped."

>
> If another kind of time-stamp token would need to be carried,
> the syntax would need to be changed. This comes into
> contradiction with the following sentence :
>
>    Other types of timestamp MAY be used, if they contain time data,
>    timestamped data and a cryptographically secure
> confirmation from the
>    TSA of these data.

See above.

>
> CryptoInfos from EvidenceRecord should be suppressed, since
> it is not proven that this additional item will ever be
> useful: encryption techniques may be different for each data
> item and thus cannot apply globally at the level of an EvidenceRecord.
> EncryptionInfo should be suppressed too. No interoperability
> can be obtained on these two fields using this specification.

This comment was made during a previous last call and resulted in Tobias' posting to the list a few instances of structures that could be conveyed in these fields.  These could be defined in a peer document or defined in this draft.


> ArchiveTimeStampSequence is a sequence of
> ArchiveTimeStampChain which is itself a sequence of
> ArchiveTimeStamp. However, there is no way to make a
> difference between an ArchiveTimeStampChain and an
> ArchiveTimeStampSequence.

The two are not used interchangably.  Why is this a problem?
 
> If within an EvidenceRecord, one element within of an
> archiveTimeStampSequence is suppressed (e.g. a
> ArchiveTimeStamp) this is not detectable. What is the real
> value of the EvidenceRecord structure ? One would expect that
> an EvidenceRecord includes a time stamp. However, it does not not.

Why would one element be suppressed?  What would you want to have happen in this case?  As-is, verification would fail.  I have commented previously that it might be better if the chain supported shallow verification, which would enable you to suppress a contiguous set of elements from the beginning of the chain up to the point from which verification was desired.  There was no support for making a change along these lines, and there seemed to be no real need to have this feature. 

What do you mean the EvidenceRecord does not include a timestamp?  It includes ArchiveTimeStampSequence, which may have one or more timestamps.


> The current draft does not allow to apply the processing
> recursively. Having constructed one EvidenceRecord (that
> would include a time stamp), it is currently not possible to
> construct another one using a previous one.

An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence.  The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer alternative suggestions. 


> This document is supposed to apply to a long term archive
> service. However, there is no signature from an archive
> service. The TSA should not be confused with a Archive
> Authority. With the current structure the Archive service may
> not be held responsible of the storage of the data.

This document defines a syntax for representing a chain of cryptographic evidence.  This syntax may be used by an archive service.  However, no archive service is required to produce an evidence record.  Archive service signatures are addressed in the context of a protocol for interacting with an archive service.


> The draft claims to protect against weak algorithms or keys.
> However, it does not make a clear and clean separation
> between the cases of :
>
> -     the key of a Time-Stamping Unit has been compromised,
> -     an asymmetric algorithm has been broken for a given key size,
> -     a hash algorithm exhibits collisions.
>
> With "Timestamp renewal" the text omits to say that it is
> necessary using "out of bands means" that a given key from a
> Time Stamping Unit has been compromised or a that given
> asymmetric algorithm has been broken for a given key size.

This should be clarified.

>
> "Hash-Tree renewal" would apply when hash algorithm exhibits
> collisions. However a complete reconstruction is needed and
> it is not clearly explained which data from the previous
> structure may re-used.
>
> Appendix A contains an annex and it is not said whether it is
> informative or normative.
> Nevertheless, the benefits of the inclusion of an
> EvidenceRecord as an unsigned attribute are not explained.
> The advantages and drawbacks of each case is not explained either.

Good point.

>
> CONCLUSION
>
> In my opinion, none of these documents is ready to be sent to
> the IESG and it does not make sense to send ERS alone. The
> usefulness of the whole work is very questionable. These
> documents are not mature and contain numerous typos.

We should not cloud the review of ERS by referring to typos in -ari and -validate.
 
> The primary question is : " Is this work really needed ?". SC
> 27 has issued ISO 18014-3:
> "Time-stamp services. Mechanisms producing linked tokens"
> that is very close.
>
> It would be interesting that the authors position their
> documents towards the ISO standard. Duplication of work
> should be avoided. If there is no duplication, then this
> should be explained in an informative annex. If no acceptable
> explanations may be given, then this work should be stopped.

The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats.

>
> P.S. I spent several hours to read the documents and to write
> this message,
>         but I do not have the time available to sustain long
> discussions on that topic.

Thanks for the review.

>
> Denis
>

--=====003_Dragon665334633732_=====-- 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 l0BCxfWQ052694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 05:59:41 -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 l0BCxfBZ052692; Thu, 11 Jan 2007 05:59:41 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0BCxcwE052671 for ; Thu, 11 Jan 2007 05:59:38 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 3463 invoked from network); 11 Jan 2007 12:58:54 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jan 2007 12:58:54 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 11 Jan 2007 12:58:54 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Jan 2007 07:59:32 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1C41D691@scygmxs1.cygnacom.com> From: Carl Wallace To: Denis Pinkas , ietf-smime@imc.org Cc: ietf-ltans@imc.org, Russ Housley , Tobias Gondrom Subject: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd Date: Thu, 11 Jan 2007 07:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73580.56375F88" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73580.56375F88 Content-Type: text/plain Comments inline... > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG > Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd > > > Nearly no comments were sent on the LTANS mailing list on > these documents. There is just one document that has been submitted for working group last call. > It may be questionable why. The fact is that these documents > are badly written, and thus it takes an enormous amount of > time to attempt to understand them. > > Even though, most readers will fail, but will not dare to > report that they did. > I am unsure that I understood them, but I dare to report it. > > This draft and its companion documents namely > draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00 > raise a number of questions to be solved. These two drafts were prepared quickly in advance of the last working group meeting. During the meeting, a call was made for additional co-authors to help clarify and complete the documents. One person has joined Tobias in this effort but no follow-up drafts have been released yet. > Let us look now at the details of ERS. > > No ASN.1 compiler has been used to validate the syntax, > otherwise, it would have been noticed that there is an > obvious ASN.1 error on EvidenceRecord. The ASN.1 was changed as a result of comments during the previous working group last call. Minor errors can be corrected without much cause for alarm. I assume in this case you are referring to the missing 's' at the end of EncryptionInfo. Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER. > > EvidenceRecord ::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > cryptoInfos [0] CryptoInfos OPTIONAL, > encryptionInfo [1] EncryptionInfo OPTIONAL, > archiveTimeStampSequence ArchiveTimeStampSequence, > ... > } > > Later on the text defines ArchiveTimeStampSequence as: > > ArchiveTimeStampSequence ::= SEQUENCE OF > ArchiveTimeStampChain and > > ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp > > and > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, > reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > Note that this information is spread all around the document, > rather than presented in sequence which does not ease its reading. > > ContentInfo is supposed to carry a TST. This means that > timeStamp should be defined as TimeStampToken rather than ContentInfo. timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken to be used. > > There is no explanation in section 4.1 (top of page 11) to > know on which data the digest contained in the TimeStampToken > is computed. This info appears in Section 4 (middle of page 10): "The root hash value, which represents unambiguously all data objects, is timestamped." > > If another kind of time-stamp token would need to be carried, > the syntax would need to be changed. This comes into > contradiction with the following sentence : > > Other types of timestamp MAY be used, if they contain time data, > timestamped data and a cryptographically secure > confirmation from the > TSA of these data. See above. > > CryptoInfos from EvidenceRecord should be suppressed, since > it is not proven that this additional item will ever be > useful: encryption techniques may be different for each data > item and thus cannot apply globally at the level of an EvidenceRecord. > EncryptionInfo should be suppressed too. No interoperability > can be obtained on these two fields using this specification. This comment was made during a previous last call and resulted in Tobias' posting to the list a few instances of structures that could be conveyed in these fields. These could be defined in a peer document or defined in this draft. > ArchiveTimeStampSequence is a sequence of > ArchiveTimeStampChain which is itself a sequence of > ArchiveTimeStamp. However, there is no way to make a > difference between an ArchiveTimeStampChain and an > ArchiveTimeStampSequence. The two are not used interchangably. Why is this a problem? > If within an EvidenceRecord, one element within of an > archiveTimeStampSequence is suppressed (e.g. a > ArchiveTimeStamp) this is not detectable. What is the real > value of the EvidenceRecord structure ? One would expect that > an EvidenceRecord includes a time stamp. However, it does not not. Why would one element be suppressed? What would you want to have happen in this case? As-is, verification would fail. I have commented previously that it might be better if the chain supported shallow verification, which would enable you to suppress a contiguous set of elements from the beginning of the chain up to the point from which verification was desired. There was no support for making a change along these lines, and there seemed to be no real need to have this feature. What do you mean the EvidenceRecord does not include a timestamp? It includes ArchiveTimeStampSequence, which may have one or more timestamps. > The current draft does not allow to apply the processing > recursively. Having constructed one EvidenceRecord (that > would include a time stamp), it is currently not possible to > construct another one using a previous one. An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence. The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence. I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer alternative suggestions. > This document is supposed to apply to a long term archive > service. However, there is no signature from an archive > service. The TSA should not be confused with a Archive > Authority. With the current structure the Archive service may > not be held responsible of the storage of the data. This document defines a syntax for representing a chain of cryptographic evidence. This syntax may be used by an archive service. However, no archive service is required to produce an evidence record. Archive service signatures are addressed in the context of a protocol for interacting with an archive service. > The draft claims to protect against weak algorithms or keys. > However, it does not make a clear and clean separation > between the cases of : > > - the key of a Time-Stamping Unit has been compromised, > - an asymmetric algorithm has been broken for a given key size, > - a hash algorithm exhibits collisions. > > With "Timestamp renewal" the text omits to say that it is > necessary using "out of bands means" that a given key from a > Time Stamping Unit has been compromised or a that given > asymmetric algorithm has been broken for a given key size. This should be clarified. > > "Hash-Tree renewal" would apply when hash algorithm exhibits > collisions. However a complete reconstruction is needed and > it is not clearly explained which data from the previous > structure may re-used. > > Appendix A contains an annex and it is not said whether it is > informative or normative. > Nevertheless, the benefits of the inclusion of an > EvidenceRecord as an unsigned attribute are not explained. > The advantages and drawbacks of each case is not explained either. Good point. > > CONCLUSION > > In my opinion, none of these documents is ready to be sent to > the IESG and it does not make sense to send ERS alone. The > usefulness of the whole work is very questionable. These > documents are not mature and contain numerous typos. We should not cloud the review of ERS by referring to typos in -ari and -validate. > The primary question is : " Is this work really needed ?". SC > 27 has issued ISO 18014-3: > "Time-stamp services. Mechanisms producing linked tokens" > that is very close. > > It would be interesting that the authors position their > documents towards the ISO standard. Duplication of work > should be avoided. If there is no duplication, then this > should be explained in an informative annex. If no acceptable > explanations may be given, then this work should be stopped. The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats. > > P.S. I spent several hours to read the documents and to write > this message, > but I do not have the time available to sustain long > discussions on that topic. Thanks for the review. > > Denis > ------_=_NextPart_001_01C73580.56375F88 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: = draft-ietf-ltans-ers-09.txt- until Jan 23rd

Comments inline...

> From: Denis Pinkas [mailto:denis.pinkas@bull.net] =
> Subject: Re: Cross review of draft ERS from = LTANS WG - RE: WG
> Last Call: draft-ietf-ltans-ers-09.txt- until = Jan 23rd
>
>
> Nearly no comments were sent on the LTANS = mailing list on
> these documents.

There is just one document that has been submitted = for working group last call.

> It may be questionable why. The fact is that = these documents
> are badly written, and thus it takes an = enormous amount of
> time to attempt to understand them.
>
> Even though, most readers will fail, but will = not dare to
> report that they did.
> I am unsure that I understood them, but I dare = to report it.
>
> This draft and its companion documents namely =
> draft-ietf-ltans-ari-00 and = draft-ietf-ltans-validate-00
> raise a number of questions to be = solved.

These two drafts were prepared quickly in advance of = the last working group meeting.  During the meeting, a call was = made for additional co-authors to help clarify and complete the = documents.  One person has joined Tobias in this effort but no = follow-up drafts have been released yet.

> Let us look now at the details of ERS.
>
> No ASN.1 compiler has been used to validate the = syntax,
> otherwise, it would have been noticed that = there is an
> obvious ASN.1 error on EvidenceRecord.

The ASN.1 was changed as a result of comments during = the previous working group last call.  Minor errors can be = corrected without much cause for alarm.  I assume in this case you = are referring to the missing 's' at the end of EncryptionInfo.  = Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External = values are missing OBJECT IDENTIFIER. 

>
>    EvidenceRecord ::=3D SEQUENCE = {
>       = version           = ;        INTEGER { v1(1) } ,
>       = digestAlgorithms          = SEQUENCE OF AlgorithmIdentifier,
>       = cryptoInfos          &= nbsp;    [0] CryptoInfos OPTIONAL,
>       = encryptionInfo         &nbs= p;  [1] EncryptionInfo OPTIONAL,
>       = archiveTimeStampSequence  ArchiveTimeStampSequence,
>       ...
>       }
>
> Later on the text defines = ArchiveTimeStampSequence as:
>
>    ArchiveTimeStampSequence = ::=3D SEQUENCE OF
>          = ;            = ;           = ArchiveTimeStampChain and
>
>    ArchiveTimeStampChain ::=3D = SEQUENCE OF ArchiveTimeStamp
>
> and
>
>    ArchiveTimeStamp ::=3D = SEQUENCE {
>      digestAlgorithm = [0] AlgorithmIdentifier OPTIONAL,
>      reducedHashtree = [1] SEQUENCE OF PartialHashtree OPTIONAL,
>      = timeStamp       ContentInfo}
>
>    PartialHashtree ::=3D = SEQUENCE OF OCTET STRING
>
> Note that this information is spread all around = the document,
> rather than presented in sequence which does = not ease its reading.
>
> ContentInfo is supposed to carry a TST. This = means that
> timeStamp should be defined as TimeStampToken = rather than ContentInfo.

timeStamp was defined as a ContentInfo to allow a = type other than TimeStampToken to be used. 

>
> There is no explanation in section 4.1 (top of = page 11) to
> know on which data the digest contained in the = TimeStampToken
> is computed.

This info appears in Section 4 (middle of page 10): = "The root hash value, which represents unambiguously all data = objects, is timestamped."

>
> If another kind of time-stamp token would need = to be carried,
> the syntax would need to be changed. This comes = into
> contradiction with the following sentence = :
>
>    Other types of timestamp MAY = be used, if they contain time data,
>    timestamped data and a = cryptographically secure
> confirmation from the
>    TSA of these data.

See above.

>
> CryptoInfos from EvidenceRecord should be = suppressed, since
> it is not proven that this additional item will = ever be
> useful: encryption techniques may be different = for each data
> item and thus cannot apply globally at the = level of an EvidenceRecord.
> EncryptionInfo should be suppressed too. No = interoperability
> can be obtained on these two fields using this = specification.

This comment was made during a previous last call and = resulted in Tobias' posting to the list a few instances of structures = that could be conveyed in these fields.  These could be defined in = a peer document or defined in this draft.

 
> ArchiveTimeStampSequence is a sequence of =
> ArchiveTimeStampChain which is itself a = sequence of
> ArchiveTimeStamp. However, there is no way to = make a
> difference between an ArchiveTimeStampChain and = an
> ArchiveTimeStampSequence.

The two are not used interchangably.  Why is = this a problem?
 
> If within an EvidenceRecord, one element within = of an
> archiveTimeStampSequence is suppressed (e.g. a =
> ArchiveTimeStamp) this is not detectable. What = is the real
> value of the EvidenceRecord structure ? One = would expect that
> an EvidenceRecord includes a time stamp. = However, it does not not.

Why would one element be suppressed?  What would = you want to have happen in this case?  As-is, verification would = fail.  I have commented previously that it might be better if the = chain supported shallow verification, which would enable you to = suppress a contiguous set of elements from the beginning of the chain = up to the point from which verification was desired.  There was no = support for making a change along these lines, and there seemed to be = no real need to have this feature. 

What do you mean the EvidenceRecord does not include = a timestamp?  It includes ArchiveTimeStampSequence, which may have = one or more timestamps.

 
> The current draft does not allow to apply the = processing
> recursively. Having constructed one = EvidenceRecord (that
> would include a time stamp), it is currently = not possible to
> construct another one using a previous one. =

An EvidenceRecord is a wrapper around an = ArchiveTimeStampSequence.  The draft describes how to add = additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an = ArchiveTimeStampSequence as well as how to add a new = ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I don't = disagree that trying to follow discussion of these three = similarly-named structures is difficult, but have failed to come up = with clearer alternative suggestions. 

 
> This document is supposed to apply to a long = term archive
> service. However, there is no signature from an = archive
> service. The TSA should not be confused with a = Archive
> Authority. With the current structure the = Archive service may
> not be held responsible of the storage of the = data.

This document defines a syntax for representing a = chain of cryptographic evidence.  This syntax may be used by an = archive service.  However, no archive service is required to = produce an evidence record.  Archive service signatures are = addressed in the context of a protocol for interacting with an archive = service.

 
> The draft claims to protect against weak = algorithms or keys.
> However, it does not make a clear and clean = separation
> between the cases of :
>
> -     the key of a = Time-Stamping Unit has been compromised,
> -     an asymmetric = algorithm has been broken for a given key size,
> -     a hash algorithm = exhibits collisions.
>
> With "Timestamp renewal" the text omits to say = that it is
> necessary using "out of bands means" that a = given key from a
> Time Stamping Unit has been compromised or a = that given
> asymmetric algorithm has been broken for a = given key size.

This should be clarified.

>
> "Hash-Tree renewal" would apply when hash = algorithm exhibits
> collisions. However a complete reconstruction = is needed and
> it is not clearly explained which data from the = previous
> structure may re-used.
>
> Appendix A contains an annex and it is not said = whether it is
> informative or normative.
> Nevertheless, the benefits of the inclusion of = an
> EvidenceRecord as an unsigned attribute are not = explained.
> The advantages and drawbacks of each case is = not explained either.

Good point.

>
> CONCLUSION
>
> In my opinion, none of these documents is ready = to be sent to
> the IESG and it does not make sense to send ERS = alone. The
> usefulness of the whole work is very = questionable. These
> documents are not mature and contain numerous = typos.

We should not cloud the review of ERS by referring to = typos in -ari and -validate.
 
> The primary question is : " Is this work really = needed ?". SC
> 27 has issued ISO 18014-3:
> "Time-stamp services. Mechanisms producing = linked tokens"
> that is very close.
>
> It would be interesting that the authors = position their
> documents towards the ISO standard. Duplication = of work
> should be avoided. If there is no duplication, = then this
> should be explained in an informative annex. If = no acceptable
> explanations may be given, then this work = should be stopped.

The ISO drafts have been discussed on the list and = are referenced by this document as a source for alternative timestamp = formats.

>
> P.S. I spent several hours to read the = documents and to write
> this message,
>         = but I do not have the time available to sustain long
> discussions on that topic.

Thanks for the review.

>
> Denis
>

------_=_NextPart_001_01C73580.56375F88-- 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 l0BAKUtr038229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 03:20:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0BAKUbt038228; Thu, 11 Jan 2007 03:20:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0BAKOBX038214; Thu, 11 Jan 2007 03:20:27 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA32186; Thu, 11 Jan 2007 11:23:55 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007011111201809:66438 ; Thu, 11 Jan 2007 11:20:18 +0100 Date: Thu, 11 Jan 2007 11:20:15 +0100 From: "Denis Pinkas" To: "ietf-smime@imc.org" Cc: "Carl Wallace" , "ietf-ltans@imc.org" , "Russ Housley" Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 11:20:18, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/01/2007 11:20:20, Serialize complete at 11/01/2007 11:20:20 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l0BAKTBY038219 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nearly no comments were sent on the LTANS mailing list on these documents. It may be questionable why. The fact is that these documents are badly written, and thus it takes an enormous amount of time to attempt to understand them. Even though, most readers will fail, but will not dare to report that they did. I am unsure that I understood them, but I dare to report it. This draft and its companion documents namely draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00 raise a number of questions to be solved. Let us look now at the details of ERS. No ASN.1 compiler has been used to validate the syntax, otherwise, it would have been noticed that there is an obvious ASN.1 error on EvidenceRecord. EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryptionInfo [1] EncryptionInfo OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence, ... } Later on the text defines ArchiveTimeStampSequence as: ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain and ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp and ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} PartialHashtree ::= SEQUENCE OF OCTET STRING Note that this information is spread all around the document, rather than presented in sequence which does not ease its reading. ContentInfo is supposed to carry a TST. This means that timeStamp should be defined as TimeStampToken rather than ContentInfo. There is no explanation in section 4.1 (top of page 11) to know on which data the digest contained in the TimeStampToken is computed. If another kind of time-stamp token would need to be carried, the syntax would need to be changed. This comes into contradiction with the following sentence : Other types of timestamp MAY be used, if they contain time data, timestamped data and a cryptographically secure confirmation from the TSA of these data. CryptoInfos from EvidenceRecord should be suppressed, since it is not proven that this additional item will ever be useful: encryption techniques may be different for each data item and thus cannot apply globally at the level of an EvidenceRecord. EncryptionInfo should be suppressed too. No interoperability can be obtained on these two fields using this specification. ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain which is itself a sequence of ArchiveTimeStamp. However, there is no way to make a difference between an ArchiveTimeStampChain and an ArchiveTimeStampSequence. If within an EvidenceRecord, one element within of an archiveTimeStampSequence is suppressed (e.g. a ArchiveTimeStamp) this is not detectable. What is the real value of the EvidenceRecord structure ? One would expect that an EvidenceRecord includes a time stamp. However, it does not not. The current draft does not allow to apply the processing recursively. Having constructed one EvidenceRecord (that would include a time stamp), it is currently not possible to construct another one using a previous one. This document is supposed to apply to a long term archive service. However, there is no signature from an archive service. The TSA should not be confused with a Archive Authority. With the current structure the Archive service may not be held responsible of the storage of the data. The draft claims to protect against weak algorithms or keys. However, it does not make a clear and clean separation between the cases of : - the key of a Time-Stamping Unit has been compromised, - an asymmetric algorithm has been broken for a given key size, - a hash algorithm exhibits collisions. With “Timestamp renewal” the text omits to say that it is necessary using “out of bands means” that a given key from a Time Stamping Unit has been compromised or a that given asymmetric algorithm has been broken for a given key size. “Hash-Tree renewal” would apply when hash algorithm exhibits collisions. However a complete reconstruction is needed and it is not clearly explained which data from the previous structure may re-used. Appendix A contains an annex and it is not said whether it is informative or normative. Nevertheless, the benefits of the inclusion of an EvidenceRecord as an unsigned attribute are not explained. The advantages and drawbacks of each case is not explained either. CONCLUSION In my opinion, none of these documents is ready to be sent to the IESG and it does not make sense to send ERS alone. The usefulness of the whole work is very questionable. These documents are not mature and contain numerous typos. The primary question is : “ Is this work really needed ?”. SC 27 has issued ISO 18014-3: “Time-stamp services. Mechanisms producing linked tokens” that is very close. It would be interesting that the authors position their documents towards the ISO standard. Duplication of work should be avoided. If there is no duplication, then this should be explained in an informative annex. If no acceptable explanations may be given, then this work should be stopped. P.S. I spent several hours to read the documents and to write this message, but I do not have the time available to sustain long discussions on that topic. Denis >Hello dear SMIME WG, > >at the last meeting of the LTANS WG in San Diego, Russ recommended to >ask your WG for a cross review of the ERS draft in its final stage (it >is currently in WGLC). > >http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt > >It would be nice if some of you could read the draft, review it and >provide your feedback. > >(As probably most of you already know the draft is about the data >structure for an Evidence Record to ensure and protect integrity of data >and signatures even when the algorithms used at signing time become >insecure at a later point in time.) > >WG Last Call runs until January 23rd. >If some of you need longer, please send me a note about how much time >you need. > >Thank you very much for your help, Tobias >Chair of LTANS > > > >> -----Original Message----- >> From: Tobias Gondrom >> Sent: Tuesday, January 09, 2007 8:12 PM >> To: ietf-ltans@imc.org >> Cc: 'Carl Wallace' >> Subject: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd >> Importance: High >> >> Hello dear LTANS WG, >> >> with the small adjustments made in version-9, based on the discussion >at >> the meeting in San Diego, I again initiate the formal final WG last >call. >> (Hopefully this time it will really be the last one ;-) ) >> >> Additionally I will also ask the SMIME WG for cross review of the >draft as >> it has been discussed and decided at the last meeting in San Diego. >> >> WG Last Call closes on January 23rd. After which the revised document >will >> hopefully be ready for submission to the IESG. >> >> Thank you, Tobias >> >> >> Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now >in >> its final preparation phase by the IETF editor team. >> >> >> >> > -----Original Message----- >> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- >> ltans@mail.imc.org] >> > On Behalf Of Internet-Drafts@ietf.org >> > Sent: Friday, January 05, 2007 12:50 AM >> > To: i-d-announce@ietf.org >> > Cc: ietf-ltans@imc.org >> > Subject: I-D ACTION:draft-ietf-ltans-ers-09.txt >> > >> > 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-09.txt >> > Pages : 29 >> > Date : 2007-1-4 >> > >> > 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-09.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-09.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-09.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. 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 l09JMEKV068041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jan 2007 12:22:14 -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 l09JMEfl068038; Tue, 9 Jan 2007 12:22:14 -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 l09JMCfG068027; Tue, 9 Jan 2007 12:22:12 -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 l09JM8lk012255; Tue, 9 Jan 2007 20:22:09 +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: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd Date: Tue, 9 Jan 2007 20:22:07 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786893845F@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd Thread-Index: AccwXXGL+OsSET5oRdyh3NelwVPjJQDw409gAABLTCA= From: "Tobias Gondrom" To: Cc: "Carl Wallace" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l09JMDfH068028 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello dear SMIME WG, at the last meeting of the LTANS WG in San Diego, Russ recommended to ask your WG for a cross review of the ERS draft in its final stage (it is currently in WGLC). http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt It would be nice if some of you could read the draft, review it and provide your feedback. (As probably most of you already know the draft is about the data structure for an Evidence Record to ensure and protect integrity of data and signatures even when the algorithms used at signing time become insecure at a later point in time.) WG Last Call runs until January 23rd. If some of you need longer, please send me a note about how much time you need. Thank you very much for your help, Tobias Chair of LTANS > -----Original Message----- > From: Tobias Gondrom > Sent: Tuesday, January 09, 2007 8:12 PM > To: ietf-ltans@imc.org > Cc: 'Carl Wallace' > Subject: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd > Importance: High > > Hello dear LTANS WG, > > with the small adjustments made in version-9, based on the discussion at > the meeting in San Diego, I again initiate the formal final WG last call. > (Hopefully this time it will really be the last one ;-) ) > > Additionally I will also ask the SMIME WG for cross review of the draft as > it has been discussed and decided at the last meeting in San Diego. > > WG Last Call closes on January 23rd. After which the revised document will > hopefully be ready for submission to the IESG. > > Thank you, Tobias > > > Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now in > its final preparation phase by the IETF editor team. > > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Friday, January 05, 2007 12:50 AM > > To: i-d-announce@ietf.org > > Cc: ietf-ltans@imc.org > > Subject: I-D ACTION:draft-ietf-ltans-ers-09.txt > > > > 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-09.txt > > Pages : 29 > > Date : 2007-1-4 > > > > 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-09.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-09.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-09.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. 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 l09JC1Ye067186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jan 2007 12:12:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l09JC1C8067184; Tue, 9 Jan 2007 12:12:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l09JBu1G067165 for ; Tue, 9 Jan 2007 12:11:57 -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 l09JBolk012204; Tue, 9 Jan 2007 20:11:51 +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: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd Date: Tue, 9 Jan 2007 20:11:49 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786893845E@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd Thread-Index: AccwXXGL+OsSET5oRdyh3NelwVPjJQDw409g X-Priority: 1 Importance: high From: "Tobias Gondrom" To: Cc: "Carl Wallace" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l09JBw1G067173 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello dear LTANS WG, with the small adjustments made in version-9, based on the discussion at the meeting in San Diego, I again initiate the formal final WG last call. (Hopefully this time it will really be the last one ;-) ) Additionally I will also ask the SMIME WG for cross review of the draft as it has been discussed and decided at the last meeting in San Diego. WG Last Call closes on January 23rd. After which the revised document will hopefully be ready for submission to the IESG. Thank you, Tobias Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now in its final preparation phase by the IETF editor team. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Friday, January 05, 2007 12:50 AM > To: i-d-announce@ietf.org > Cc: ietf-ltans@imc.org > Subject: I-D ACTION:draft-ietf-ltans-ers-09.txt > > 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-09.txt > Pages : 29 > Date : 2007-1-4 > > 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-09.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-09.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-09.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. 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 l04No6Lw038242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 16:50:06 -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 l04No6GY038241; Thu, 4 Jan 2007 16:50:06 -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 ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l04No5HJ038235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Jan 2007 16:50:05 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7B6E22ACD5; Thu, 4 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2cLS-0007Nt-6C; Thu, 04 Jan 2007 18:50:02 -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-09.txt Message-Id: Date: Thu, 04 Jan 2007 18:50:02 -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-09.txt Pages : 29 Date : 2007-1-4 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-09.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-09.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-09.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-1-4151528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-4151528.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 l04FaAfX005422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 08:36:10 -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 l04FaA6t005421; Thu, 4 Jan 2007 08:36:10 -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 ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l04Fa8U1005412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Jan 2007 08:36:09 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 332F832934; Thu, 4 Jan 2007 15:36:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2UdU-0006DP-3Y; Thu, 04 Jan 2007 10:36:08 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ltans mailing list , ltans chair Subject: Document Action: 'Long-Term Archive Service Requirements' to Informational RFC Message-Id: Date: Thu, 04 Jan 2007 10:36:08 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has approved the following document: - 'Long-Term Archive Service Requirements ' as an Informational RFC This document is the product of the Long-Term Archive and Notary Services Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-10.txt Technical Summary There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. Working Group Summary This document is a product of the Long-Term Archive and Notary Services (LTANS) Working Group. The document was reviewed by LTANS WG members and chairs. Protocol Quality This document does not specify a protocol. It documents the requirements for protocols and data structures that will be specified in other documents. There are at least two implementations of a protocol and a data structure that meet the requirements in this document. This document was reviewed by Russ Housley for the IESG. 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 l04CnRlU091457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 05:49:27 -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 l04CnRqU091456; Thu, 4 Jan 2007 05:49:27 -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 l04CnPmj091448 for ; Thu, 4 Jan 2007 05:49:26 -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 l04CnApa017363; Thu, 4 Jan 2007 13:49:21 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LTANS summary Date: Thu, 4 Jan 2007 13:49:07 +0100 Content-Type: multipart/signed; boundary="----=_NextPart_000_001F_01C73007.1ABCE5C0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868937ECB@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS summary Thread-Index: AccuYr/JX5ECAyJwRHSNKkFBQCcCewBmnO0A 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_001F_01C73007.1ABCE5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, hi all,=20 ok. You are right, I was not aware that they are 100% interoperable. "CryptographicMessageSyntax2004 -- FROM [RFC3852]" Interoperable with "ContentInfo FROM PKCS-7" "AlgorithmIdentifier FROM PKIX1Explicit88" Interoperable with "AlgorithmIdentifier FROM AuthenticationFramework" Where I am unsure is whether to=20 A) list the current (version 09) ASN.1 structure and put the other = imports that you propose in the appendix or=20 B) vice versa (i.e. as you proposed below). Is there a strong reason/opinion why we should choose option B? Thank you, Tobias > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > Sent: Tuesday, January 02, 2007 12:38 PM > To: Tobias Gondrom > Cc: Carl Wallace; ietf-ltans@imc.org > Subject: Re: LTANS summary >=20 > Tobias Gondrom wrote: > > Hi Peter and Carl, > > > > I do not agree: I do not think that two alternative imports is a = good > idea. Because the definition and import to the document should be > unambiguous. (How can developers decide which imports to use or have = been > used, and how to ensure interoperability of different implementers? = For > this we would have to implement an own additional ID just to define = which > import has been used.) > > > > But maybe I misunderstood s.th.? > > > > > Indeed, I have this impression: >=20 > The proposal is to have TWO asn1 modules. One is written in current > asn.1 and uses only imports from > modules that are also of that kind. This is the normative module. For > convenience of implementors that > do not dispose of tools that can handle current ASN.1, a module > using 88 syntax could be provided. >=20 > The data structures which are imported are identical. They = interoperate. >=20 >=20 > -- > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorit=E9; > die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch. ------=_NextPart_000_001F_01C73007.1ABCE5C0 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 DQEJBTEPFw0wNzAxMDQxMjQ5MDdaMCMGCSqGSIb3DQEJBDEWBBSyhA/EMVwR9ajglJ+ay6ZrfIM1 1TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAC9wvZbZnFSh3vBXG9oEMjye7WsEplpDwLLE7DAwfd3+BwLA4Rbd9KjCBf8E DGZ7chNKkWCYZ2bygCx82uYKsRJ8T14SQNug9lmJR4PQ6aKqNWmNr8TBGQVD3Ckg06MaPsljGQOS f8ws1V5E9gPyTcLm56avyZj/+T68aDdpCSFp5zMe2dgTlsVisCWRbsE5IxLixkKM/sa1ukQjF7Q/ UOuCAK7nA89uFYFv7x/BPyRPMcpwXLVQQKRxIhzw+WGd/0Dmw5p742M5LHKPJ6PdYVALBXD896O1 EILsVQoap7hAf0HmGo8hy502KzcTNVCeK02BWSt7jMspuGm6+nzTWS94fk6tDZD0bgBKknX5VB5+ DjaMhkky7fvq7qXl7QWsTBtPAhZ1DB9sokjo1BclaZNDB1z2ddjBplkZFQfe8a0iIj/XxxuUpiV/ ozK0A6MYadIAlSyhFHJuJmlrRFHwSxs4aSlcfW40Ir1Sda8UXC7A0U+SoTrW6pDpWULrgZMlzgYK NJnnXeDEPIXCJSQWw9PzVBLKA6o4chaGha1cm+oPQSzFtsuCF/pC6bnRvBb3CceiOhLAKYoBwT1l JWB6SYt4cEaAljl23E2OaIWXPcSWn1aXDFFjSC2Xf/QZrRPqTK77Pz+JMs3Eqh9S0f9Vfvfku7vf now8J2gKf2rV8hJWAAAAAAAA ------=_NextPart_000_001F_01C73007.1ABCE5C0-- 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 l02Bdw5x049686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jan 2007 04:39:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l02Bdwjn049685; Tue, 2 Jan 2007 04:39:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l02Bdulp049673 for ; Tue, 2 Jan 2007 04:39:57 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l02Bde527137; Tue, 2 Jan 2007 12:39:40 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 2 Jan 2007 12:39:46 +0100 (MET) Message-ID: <459A4402.5060907@edelweb.fr> Date: Tue, 02 Jan 2007 12:37:38 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom CC: Carl Wallace , ietf-ltans@imc.org Subject: Re: LTANS summary References: <2666EB2A846BAC4BB2D7F593301A78689379EC@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78689379EC@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060105010802040905090700" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms060105010802040905090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Tobias Gondrom wrote: > Hi Peter and Carl, > > I do not agree: I do not think that two alternative imports is a good idea. Because the definition and import to the document should be unambiguous. (How can developers decide which imports to use or have been used, and how to ensure interoperability of different implementers? For this we would have to implement an own additional ID just to define which import has been used.) > > But maybe I misunderstood s.th.? > > Indeed, I have this impression: The proposal is to have TWO asn1 modules. One is written in current asn.1 and uses only imports from modules that are also of that kind. This is the normative module. For convenience of implementors that do not dispose of tools that can handle current ASN.1, a module using 88 syntax could be provided. The data structures which are imported are identical. They interoperate. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms060105010802040905090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTAyMTEzNzM4WjAjBgkqhkiG9w0B CQQxFgQUbO/HkDGIAzS3T985SJm3hBs4KBIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAOrb9K0hsO0+WCTrA qhIquvxGb4CK5drbdKRDbklbHzknDEv7vmVCF5wJf1N8aGtZ98jxK9k/tHE/cFyW0yRkEvlt j8Mb5VSvMZCAf1zM9vYnK+z6rQsWTLVQnUwxFEeXCdBJMTk5ozlv63+HETpHjz0cprBJ+asO CLwGogC8s3YAAAAAAAA= --------------ms060105010802040905090700--