From owner-ietf-ltans@mail.imc.org Wed Jan 02 12:11:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA78F-0000Oo-6x for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 02 Jan 2008 12:11:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA78D-0005hA-C3 for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 02 Jan 2008 12:11:55 -0500 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 m02GnBMo030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 09:49: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 m02GnBGB030698; Wed, 2 Jan 2008 09:49:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02Gn9xe030690 for ; Wed, 2 Jan 2008 09:49:10 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id CA6411F; Wed, 2 Jan 2008 17:49:07 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01372-08; Wed, 2 Jan 2008 17:49:03 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 32E4444; Wed, 2 Jan 2008 17:49:03 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008010217490104:187337 ; Wed, 2 Jan 2008 17:49:01 +0100 Message-ID: <477BC07D.6090003@edelweb.fr> Date: Wed, 02 Jan 2008 17:49:01 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Jesus Maria Mendez Perez Cc: Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:49:01 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:49:02 PM, Serialize complete at 01/02/2008 05:49:02 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904010506020201080909" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.1 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a cryptographically signed message in MIME format. --------------ms060904010506020201080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jesus Maria Mendez Perez wrote: > Hello Tobias, I=B4m Jesus. Merry Christmas. > > I have some questions and I hope you can help me. > > First, about what happen with the gap of time that pass while you send = > a data object and finally at the evening the ERS-system build > the hastree for all documents that were archived during that day?. For = > example, if you send a data object at 3:00 pm and the ERS-system build = > the hashtree at 8:00 pm... you have 5 hours during which that data=20 > object could lose its integrity. What can we do in this situation? > Could be the solution to timestamp every data object separately and=20 > inmediately after they are sent by the client and when the ERS-system=20 > have to build the hashtree, the hash-tree will built with all these=20 > data objects and its timestamps? IMO opinion you need to distingusih two events: A 3:00pm a client enters = something into an archive.Looking at LTAP, this may result in a first 'receipt', indicating that archiving = is 'in progress'. At 8:00 or even a day later (when backup copies etc are made), the archive may=20 return a 'now we have a safe archived copy' message. > > And now about the ARCHIVE operation. In the LTAP Protocol draft is=20 > said LTAP Protocol is asynchronous by nature. And my question is about = > then second response (service response). Will a client receive the=20 > second response when the TAS hast just received the data object or=20 > when the archive operation has just finished (the hashtree has been=20 > built)? The second message is sent when the TAS can safely assume that it has a=20 good recoverable copy. If ERS is part of the policy of the TAS, then the TAS most likely does=20 not respond before having created a good tree, and backups and backups of the trees ... etc > If the ARCHIVE operation is asynchronous we really need another=20 > operation to permit a client to check if the full archive operation=20 > has finished... Which is the case with LTAP. The protocol does not necessarily be mapped to HTTP, you can map the second ack to a mail based service. The abstract protocol allows to 'poll for a response' in several ways: After having received the initial response or even before, you can=20 repeat the archive operation using the hash of the data as reference or the reference=20 return by the initial ack. You do this until you get the final response. What this means is that a client does have to do some housekeeping in=20 some 'spooling server' similar to email or to a tcp stack. Even the initial ack is conceptually asynchronous allow a client API=20 implementation to be completely non-blocking, etc. > > Finally about the information called "Complementary data" in the=20 > article "Long-term trusted preservation service using service=20 > interaction protocol and evidence records", does it include only=20 > timestamping certificates?, or does it include timestamps' certificates= > and user signer=B4s certificates?. Are they obtain by SCVP and save up = > as complementary data in the archive operation? I let Aljosa answer this. > > Thanks and Happy Christmas > Happy new year. Peter --=20 To verify the signature, see http://edelpki.edelweb.fr/=20 Cela vous permet de charger le certificat de l'autorit=E9;=20 die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 --------------ms060904010506020201080909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODAxMDIxNjQ5MDFaMCMGCSqGSIb3DQEJBDEWBBT+04SFrWI/cy9/hrkxiR32mjuqjDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYCaR7NrhXk0IqSOs2z4csTgBQp4JODworkxWAqkVJY/HDugWnSvD/FD0+BQ SIA1o/suj/nnHcj/SfVQce/qyWycrFIiP6GKS7QaxQxq0T4rcV7S5RKxnWZAtPAMEpRDBIQE obtIa/P9AyIrk7wCCiBgFhVuEr70t9qd5XeEODVkfgAAAAAAAA== --------------ms060904010506020201080909-- From owner-ietf-ltans@mail.imc.org Wed Jan 02 12:17:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA7DT-0005Y4-0X for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 02 Jan 2008 12:17:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA7DS-0005oN-FA for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 02 Jan 2008 12:17:18 -0500 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 m02Gw7oj031386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 09:58:07 -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 m02Gw7px031385; Wed, 2 Jan 2008 09:58:07 -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 ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02Gw5Uu031376 for ; Wed, 2 Jan 2008 09:58:06 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id EBFED43; Wed, 2 Jan 2008 17:58:02 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01480-03; Wed, 2 Jan 2008 17:58:00 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 7FD682C; Wed, 2 Jan 2008 17:58:00 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008010217575976:187343 ; Wed, 2 Jan 2008 17:57:59 +0100 Message-ID: <477BC297.5080008@edelweb.fr> Date: Wed, 02 Jan 2008 17:57:59 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: todd glassey Cc: Jesus Maria Mendez Perez , Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> <054301c84823$352520a0$174f7d40@home.glassey.com> In-Reply-To: <054301c84823$352520a0$174f7d40@home.glassey.com> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:57:59 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:58:00 PM, Serialize complete at 01/02/2008 05:58:00 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040405070401050002030504" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.1 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a cryptographically signed message in MIME format. --------------ms040405070401050002030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable > > As to your commentary - Those five hours of data are spoiled and well=20 > - that makes this a real issue I think. > What is the issue in your opinion? - The archive does not yet agree to have a safe copy? (and may be in=20 fact it is lying?) - The archive may loose everything withing these 5 hours (+1 day etc),=20 before sending the ack. If you want to make the group listen to you comments you should provide at least more details of the problem space, ideas of possibles approaches= or ask for clarifications about something concrete. The approach used in this group (as well as in others) is to define=20 technology not just as a minimalistic reaction to whatever concrete legislation or=20 jurisprudence. No games between 'Hase und Igel'. Happy new year Peter --=20 To verify the signature, see http://edelpki.edelweb.fr/=20 Cela vous permet de charger le certificat de l'autorit=E9;=20 die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 --------------ms040405070401050002030504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODAxMDIxNjU3NTlaMCMGCSqGSIb3DQEJBDEWBBQiu7W/BgX+V4FLlwnl9gOQGQBWYzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYDOwKOPRkWAUpCcFxwUGHd4pJPKMrIdEDL8nRn1XNHNlLutWM2631lcjXxn riNs00FQYo91IwUyhmFSpmLwRzeNIv6hkX7rxeM/gJBCAHZUwO+f9ONDfjHeq6tF8/fOR700 TGpHhROouJ9ncjSlbAz41GZEEySDmEgL/lV+Iiv7jQAAAAAAAA== --------------ms040405070401050002030504-- From owner-ietf-ltans@mail.imc.org Thu Jan 17 17:31:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdGP-0005l4-I2 for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 17:31:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFdGO-00081u-6A for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 17:31:09 -0500 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 m0HMFpqR054193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 15:15: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 m0HMFpXk054192; Thu, 17 Jan 2008 15:15: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 elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HMFnFV054186 for ; Thu, 17 Jan 2008 15:15:50 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MOhEJn6Z/Lb+VxkIZIrke/MqzAMssPuDlZfBiAeEzTnhMSJLN0H3+7nXuYnCoo7B; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JFd1X-0007O4-IJ; Thu, 17 Jan 2008 17:15:47 -0500 Message-ID: <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> From: "todd glassey" To: "Thomas Kunz" , "Turner, Sean P." Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 17 Jan 2008 13:07:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798268f76afcfec7383791a6715200c55a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f ----- Original Message ----- From: "Thomas Kunz" To: "Turner, Sean P." Cc: Sent: Friday, December 07, 2007 7:06 AM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > We think, our flat sequence is sufficient. Actually - this is the problem we are facing now Thomas, that is from an evidence management perspective, this "We Think" is not sufficient to assure LTANS encapsulated documents meet the emerging and followon legal constraints for document archiving is a key flaw in the mindset. > > The goal of a policy is to specify a range for specific (safety-critical) > parameters of an algorithm. Therefor it's not necessary to define all > parameters. Uh NO... A policy is a 'rule based on a set of constraints' and as such those constraints and the policy itself need to be defined and verifiable as well. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > one value is defined (namely q). By NIST a q_length of 160 is suitable > until 2010. But NIST itself nor BSI are underwriting anyone and those are the key issues. Also ANY service MUST meet the new US Rules of Civil Procedure and the updated Federal Rules of Evidence in specific to that content's admissibility in US Courts as 'ESI'... > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: >> Yes I did misunderstand. With algorithms like DSA where there are few >> parameters your structure might work but for EC algorithms (I attached >> some >> of the ASN.1 for their parameters) I don't think the flat sequence of >> will >> work. >> >> ECParameters ::= CHOICE { >> namedCurve CURVE.&id({NamedCurve}), >> specifiedCuve SpecifiedCurve, >> implicitCurve NULL >> } >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> WITH SYNTAX { ID &id } >> >> NamedCurve CURVE ::= { >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> ... -- Extensible >> } >> >> SpecifiedCurve ::= SEQUENCE { >> version SpecifiedCurveVersion >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> fieldID FieldID {{FieldTypes}}, >> curve Curve, -- Curve E >> base ECPoint, -- Base point P >> order INTEGER, -- Order n of the base point >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> hash HashAlgorithm OPTIONAL, >> ... -- Extensible >> } >> >> SpecifiedCurveVersion ::= INTEGER { >> ecpVer1(1), >> ecpVer2(2), >> ecpVer3(3), >> ... -- Extensible >> } >> FIELD-ID ::= TYPE-IDENTIFIER >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> FIELD-ID.&id({IOSet}), >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> } >> >> FieldTypes FIELD-ID ::= { >> { Prime-p IDENTIFIED BY prime-field } | >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> ... -- Extensible >> } >> >> prime-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> Prime-p ::= INTEGER >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> Characteristic-two ::= SEQUENCE { >> m INTEGER, -- Field size 2^m >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> } >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> { NULL IDENTIFIED BY gnBasis } | >> { Trinomial IDENTIFIED BY tpBasis } | >> { Pentanomial IDENTIFIED BY ppBasis } | >> ... -- Extensible >> } >> >> gnBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 1 } >> >> tpBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 2 } >> >> Trinomial ::= INTEGER >> >> ppBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 3 } >> >> Pentanomial ::= SEQUENCE { >> k1 INTEGER, -- k1 > 0 >> k2 INTEGER, -- k2 > k1 >> k3 INTEGER -- k3 > k2 >> } >> >> Curve ::= SEQUENCE { >> a FieldElement, >> b FieldElement, >> seed BIT STRING OPTIONAL >> -- Shall be present if used in SpecifiedCurve >> -- with version of ecdpVer2 or ecdpVer3 >> } >> FieldElement ::= OCTET STRING >> >> ECPoint ::= OCTET STRING >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>> Sent: Thursday, December 06, 2007 4:52 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> We think, You misunderstood our last post. >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>> that we CANNOT use the AlgorithmIdentifier. >>> >>> The reason is, we cannot model the following cases: >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>> case of DSA). >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>> >>> The main problem is that AlgorithmIdentifier describes entirely one >>> algorithm with all its parameters. Therefor it is not possible to set >>> different constraints for the parameters. >>> >>> so & tk >>> >>> >>> >>> Turner, Sean P. schrieb: >>>> This would work for me. >>>> >>>> spt >>>> >>>>> -----Original Message----- >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>> To: Turner, Sean P. >>>>> Cc: ietf-ltans@imc.org >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>> >>>>> The problem with your suggested syntax is the definition of the our >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>> structure, we >>>>> would integrate the constraints as follows: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>> identifier AlgorithmIdentifier, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> It's not possible to determine constraints for more than one parameter >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>> 2048 and modulus > 1024). >>>>> >>>>> >>>>> so & tk >>>>> >>>>> >>>>> Turner, Sean P. schrieb: >>>>>> I'm only commenting on the Parameter structure in the >>> ASN.1. I think >>>>>> that it might be better to change Algorithm to be a sequence of >>>>>> algorithmIdentifier, validity, and information - call it >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>> algorithm's object identifier also define the parameters. So it >>>>>> probably makes sense to reuse this structure. >>>>>> >>>>>> 2. The parameters structures for some of the newer >>>>> algorithms is quite >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>> [RFC3279] >>>>>> aren't just an OID they are nested structure. >>>>>> >>>>>> (not sure how to do it in XML) >>>>>> >>>>>> Replace: >>>>>> >>>>>> Algorithm ::= SEQUENCE { >>>>>> algorithmIdentifier AlgID, >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>> validity [1] Validity, >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>> } >>>>>> >>>>>> AlgID ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>> } >>>>>> >>>>>> Parameter ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> } >>>>>> } >>>>>> >>>>>> With: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>> AlgorithmIdentifier, >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> Validity ::= SEQUENCE { >>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>> >>>>>> -- From RFC3280 >>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>> algorithm OBJECT IDENTIFIER, >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>> -- contains a value of the type >>>>>> -- registered for use with the >>>>>> -- algorithm object >>> identifier value >>>>>> spt >>>>>> >>>>>> >>>> >> >> > From owner-ietf-ltans@mail.imc.org Thu Jan 17 19:02:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFegb-0003j9-SI for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 19:02:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFega-0001Dx-B8 for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 19:02:17 -0500 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 m0HNnsE5060707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 16:49:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HNnsro060706; Thu, 17 Jan 2008 16:49:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HNnoRH060696 for ; Thu, 17 Jan 2008 16:49:53 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=qFnC0pdVGmf/P0auWwDk2P4+utxqNYm39uYcADorlgjmh/1WIJy9euFethPkS7VA; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.15.49] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JFeUU-0002TR-1d; Thu, 17 Jan 2008 18:49:48 -0500 Message-ID: <479004B6.EDCA48CF@ix.netcom.com> Date: Thu, 17 Jan 2008 17:45:26 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: todd glassey CC: Thomas Kunz , "Turner, Sean P." , ietf-ltans@imc.org, Dan Swanson , DHS cert , DHS info Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606886ee2220f5d74ee50feddaf9fa00deaf4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.15.49 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Todd and all, I believe that Todd has a good and valuable point here that should not be discounted or otherwise ignored. It could be however that whomever the "WE" is which Thomas is referring to is unknown or not specifically defined or is a broader group that has little or no concern or consideration as to whether all are defined, ergo some international rather than US based/centric legalistic requirement. If so, and I cannot myself determine base on what I have seen or read thus far clearly enough to make such a definitive determination, than I can only logically conclude that the "Flat sequence" approach in this protocol will face significant resistance as a viable standard. As such, it may be that the IETF will face some significant resistance as a comprehensive standards body. From my own perspective, I am beginning to find these latest comments in this dialog, increasingly troubling.... Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 todd glassey wrote: > ----- Original Message ----- > From: "Thomas Kunz" > To: "Turner, Sean P." > Cc: > Sent: Friday, December 07, 2007 7:06 AM > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > We think, our flat sequence is sufficient. > > Actually - this is the problem we are facing now Thomas, that is from an > evidence management perspective, this "We Think" is not sufficient to assure > LTANS encapsulated documents meet the emerging and followon legal > constraints for document archiving is a key flaw in the mindset. > > > > > The goal of a policy is to specify a range for specific (safety-critical) > > parameters of an algorithm. Therefor it's not necessary to define all > > parameters. > > Uh NO... A policy is a 'rule based on a set of constraints' and as such > those constraints and the policy itself need to be defined and verifiable as > well. > > > > > In the evaluations of BSI and NIST > > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > > one value is defined (namely q). By NIST a q_length of 160 is suitable > > until 2010. > > But NIST itself nor BSI are underwriting anyone and those are the key > issues. Also ANY service MUST meet the new US Rules of Civil Procedure and > the updated Federal Rules of Evidence in specific to that content's > admissibility in US Courts as 'ESI'... > > > > > In this case, the XML structure would be: > > > > > > > > EC-DSA 160 > > ... > > > > 160 > > 2010-12-31 > > > > > > > > so & tk > > > > > > > > > > > > Turner, Sean P. schrieb: > >> Yes I did misunderstand. With algorithms like DSA where there are few > >> parameters your structure might work but for EC algorithms (I attached > >> some > >> of the ASN.1 for their parameters) I don't think the flat sequence of > >> will > >> work. > >> > >> ECParameters ::= CHOICE { > >> namedCurve CURVE.&id({NamedCurve}), > >> specifiedCuve SpecifiedCurve, > >> implicitCurve NULL > >> } > >> > >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > >> WITH SYNTAX { ID &id } > >> > >> NamedCurve CURVE ::= { > >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > >> ... -- Extensible > >> } > >> > >> SpecifiedCurve ::= SEQUENCE { > >> version SpecifiedCurveVersion > >> ( ecpVer1 | ecpVer2 | ecpVer3 ), > >> fieldID FieldID {{FieldTypes}}, > >> curve Curve, -- Curve E > >> base ECPoint, -- Base point P > >> order INTEGER, -- Order n of the base point > >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > >> hash HashAlgorithm OPTIONAL, > >> ... -- Extensible > >> } > >> > >> SpecifiedCurveVersion ::= INTEGER { > >> ecpVer1(1), > >> ecpVer2(2), > >> ecpVer3(3), > >> ... -- Extensible > >> } > >> FIELD-ID ::= TYPE-IDENTIFIER > >> > >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType > >> FIELD-ID.&id({IOSet}), > >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) > >> } > >> > >> FieldTypes FIELD-ID ::= { > >> { Prime-p IDENTIFIED BY prime-field } | > >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | > >> ... -- Extensible > >> } > >> > >> prime-field OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > >> > >> Prime-p ::= INTEGER > >> > >> characteristic-two-field OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > >> > >> Characteristic-two ::= SEQUENCE { > >> m INTEGER, -- Field size 2^m > >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), > >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > >> } > >> > >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > >> > >> BasisTypes CHARACTERISTIC-TWO ::= { > >> { NULL IDENTIFIED BY gnBasis } | > >> { Trinomial IDENTIFIED BY tpBasis } | > >> { Pentanomial IDENTIFIED BY ppBasis } | > >> ... -- Extensible > >> } > >> > >> gnBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 1 } > >> > >> tpBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 2 } > >> > >> Trinomial ::= INTEGER > >> > >> ppBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 3 } > >> > >> Pentanomial ::= SEQUENCE { > >> k1 INTEGER, -- k1 > 0 > >> k2 INTEGER, -- k2 > k1 > >> k3 INTEGER -- k3 > k2 > >> } > >> > >> Curve ::= SEQUENCE { > >> a FieldElement, > >> b FieldElement, > >> seed BIT STRING OPTIONAL > >> -- Shall be present if used in SpecifiedCurve > >> -- with version of ecdpVer2 or ecdpVer3 > >> } > >> FieldElement ::= OCTET STRING > >> > >> ECPoint ::= OCTET STRING > >>> -----Original Message----- > >>> From: owner-ietf-ltans@mail.imc.org > >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >>> Sent: Thursday, December 06, 2007 4:52 AM > >>> To: Turner, Sean P. > >>> Cc: ietf-ltans@imc.org > >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>> > >>> We think, You misunderstood our last post. > >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show > >>> that we CANNOT use the AlgorithmIdentifier. > >>> > >>> The reason is, we cannot model the following cases: > >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in > >>> case of DSA). > >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >>> > >>> The main problem is that AlgorithmIdentifier describes entirely one > >>> algorithm with all its parameters. Therefor it is not possible to set > >>> different constraints for the parameters. > >>> > >>> so & tk > >>> > >>> > >>> > >>> Turner, Sean P. schrieb: > >>>> This would work for me. > >>>> > >>>> spt > >>>> > >>>>> -----Original Message----- > >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>>> To: Turner, Sean P. > >>>>> Cc: ietf-ltans@imc.org > >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>>> > >>>>> The problem with your suggested syntax is the definition of the our > >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >>> structure, we > >>>>> would integrate the constraints as follows: > >>>>> > >>>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>>> identifier AlgorithmIdentifier, > >>>>> constraint CHOICE { > >>>>> exact [0] OCTET STRING, > >>>>> min [1] OCTET STRING, > >>>>> max [2] OCTET STRING, > >>>>> range [3] Range, > >>>>> other [4] OtherConstraints > >>>>> validity Validity OPTIONAL, > >>>>> information Information OPTIONAL } > >>>>> > >>>>> It's not possible to determine constraints for more than one parameter > >>>>> (e.g. p > 1024 and q > 160 in case of DSA). > >>>>> Additionally defining ranges is impossible (e.g. modulus < > >>>>> 2048 and modulus > 1024). > >>>>> > >>>>> > >>>>> so & tk > >>>>> > >>>>> > >>>>> Turner, Sean P. schrieb: > >>>>>> I'm only commenting on the Parameter structure in the > >>> ASN.1. I think > >>>>>> that it might be better to change Algorithm to be a sequence of > >>>>>> algorithmIdentifier, validity, and information - call it > >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>>> > >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>>> algorithm's object identifier also define the parameters. So it > >>>>>> probably makes sense to reuse this structure. > >>>>>> > >>>>>> 2. The parameters structures for some of the newer > >>>>> algorithms is quite > >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>>> [RFC3279] > >>>>>> aren't just an OID they are nested structure. > >>>>>> > >>>>>> (not sure how to do it in XML) > >>>>>> > >>>>>> Replace: > >>>>>> > >>>>>> Algorithm ::= SEQUENCE { > >>>>>> algorithmIdentifier AlgID, > >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>>> validity [1] Validity, > >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>>> } > >>>>>> > >>>>>> AlgID ::= SEQUENCE { > >>>>>> name UTF8String, > >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>>> } > >>>>>> > >>>>>> Parameter ::= SEQUENCE { > >>>>>> name UTF8String, > >>>>>> constraint CHOICE { > >>>>>> exact [0] OCTET STRING, > >>>>>> min [1] OCTET STRING, > >>>>>> max [2] OCTET STRING, > >>>>>> range [3] Range, > >>>>>> other [4] OtherConstraints > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> With: > >>>>>> > >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>>> AlgorithmIdentifier, > >>>>>> validity Validity OPTIONAL, > >>>>>> information Information OPTIONAL } > >>>>>> > >>>>>> Validity ::= SEQUENCE { > >>>>>> start [0] GeneralizedTime OPTIONAL, > >>>>>> end [1] GeneralizedTime OPTIONAL } > >>>>>> > >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>>> > >>>>>> -- From RFC3280 > >>>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>>> algorithm OBJECT IDENTIFIER, > >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>>> -- contains a value of the type > >>>>>> -- registered for use with the > >>>>>> -- algorithm object > >>> identifier value > >>>>>> spt > >>>>>> > >>>>>> > >>>> > >> > >> > > From owner-ietf-ltans@mail.imc.org Thu Jan 17 20:42:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFgFH-0006XM-9Y for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 20:42:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFgFE-0002ph-9X for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 17 Jan 2008 20:42:11 -0500 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 m0I1Tswg066878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 18:29:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I1TsSU066877; Thu, 17 Jan 2008 18:29:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I1TqYx066869 for ; Thu, 17 Jan 2008 18:29:52 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gND7QN1Tr1VC9s6z1WZjSPmjKUsqCBIfwrbeD8c8/hE0Fdfs3MXaCT2qBL6aD22v; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JFg3J-0001dp-LP; Thu, 17 Jan 2008 20:29:50 -0500 Message-ID: <001501c85971$9e00d3d0$6401a8c0@tsg1> From: "TS Glassey" To: "Jeffrey A. Williams" Cc: "Thomas Kunz" , "Turner, Sean P." , , "Dan Swanson" , "DHS cert" , "DHS info" References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> <479004B6.EDCA48CF@ix.netcom.com> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 17 Jan 2008 17:29:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b852fdee61bdadfcb48c550a66c9651e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 ----- Original Message ----- From: "Jeffrey A. Williams" To: "todd glassey" Cc: "Thomas Kunz" ; "Turner, Sean P." ; ; "Dan Swanson" ; "DHS cert" ; "DHS info" Sent: Thursday, January 17, 2008 5:45 PM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > Todd and all, > > I believe that Todd has a good and valuable point here that > should not be discounted or otherwise ignored. The issue is simple here - these protocols are to perform tasks which have an actual impact under the law and as such the effect they produce or which can be had by using the protocol MUST be properly defined otherwise there is NO POSSIBLE REASON for building this protocol since it will be prevented from its being used by the Audit and Insurance Industry who will simply say they wont bond or recognize those that use the protocol. What we need is formal support and buy-in from any number of professional industries for LTANS and if we cannot get it, then anyone who uses the protocol will have to have their own protocol certified individually including the entire design. The problem is that this would give them leverage over what anyone else did with that protocol, since that certification would be for a specific implementation and not the actual protocol standard under their workproduct. The problem with this is that this 'commercial ownership of the certification' will encumber ALL of the other users who claim that their protocol is 'certified' as well. The reasoning is that one where basic protocol of party "A" was certified, to derivative claims against those other users by the first party to have their protocol certified. This also includes damages against the IETF in the process, and with this type of liability, IMHO no one will touch LTANS with a ten foot pole. That said, this can all be set aside by soliciting outside critique of the LTANS protocol by the people who would be responsible for using it and auditing it's implementation and use. Just my two cents Todd Glassey > It could > be however that whomever the "WE" is which Thomas is referring > to is unknown or not specifically defined or is a broader group that > has little or no concern or consideration as to whether all > are defined, ergo some international rather than US based/centric > legalistic requirement. If so, and I cannot myself determine base > on what I have seen or read thus far clearly enough to make such > a definitive determination, than I can only logically conclude that > the "Flat sequence" approach in this protocol will face significant > resistance as a viable standard. As such, it may be that the IETF > will face some significant resistance as a comprehensive standards > body. > > From my own perspective, I am beginning to find these latest > comments in this dialog, increasingly troubling.... > > Regards, > > Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > My Phone: 214-244-4827 > > todd glassey wrote: > >> ----- Original Message ----- >> From: "Thomas Kunz" >> To: "Turner, Sean P." >> Cc: >> Sent: Friday, December 07, 2007 7:06 AM >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> > We think, our flat sequence is sufficient. >> >> Actually - this is the problem we are facing now Thomas, that is from an >> evidence management perspective, this "We Think" is not sufficient to >> assure >> LTANS encapsulated documents meet the emerging and followon legal >> constraints for document archiving is a key flaw in the mindset. >> >> > >> > The goal of a policy is to specify a range for specific >> > (safety-critical) >> > parameters of an algorithm. Therefor it's not necessary to define all >> > parameters. >> >> Uh NO... A policy is a 'rule based on a set of constraints' and as such >> those constraints and the policy itself need to be defined and verifiable >> as >> well. >> >> > >> > In the evaluations of BSI and NIST >> > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms >> > only >> > one value is defined (namely q). By NIST a q_length of 160 is suitable >> > until 2010. >> >> But NIST itself nor BSI are underwriting anyone and those are the key >> issues. Also ANY service MUST meet the new US Rules of Civil Procedure >> and >> the updated Federal Rules of Evidence in specific to that content's >> admissibility in US Courts as 'ESI'... >> >> > >> > In this case, the XML structure would be: >> > >> > >> > >> > EC-DSA 160 >> > ... >> > >> > 160 >> > 2010-12-31 >> > >> > >> > >> > so & tk >> > >> > >> > >> > >> > >> > Turner, Sean P. schrieb: >> >> Yes I did misunderstand. With algorithms like DSA where there are few >> >> parameters your structure might work but for EC algorithms (I attached >> >> some >> >> of the ASN.1 for their parameters) I don't think the flat sequence of >> >> will >> >> work. >> >> >> >> ECParameters ::= CHOICE { >> >> namedCurve CURVE.&id({NamedCurve}), >> >> specifiedCuve SpecifiedCurve, >> >> implicitCurve NULL >> >> } >> >> >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> >> WITH SYNTAX { ID &id } >> >> >> >> NamedCurve CURVE ::= { >> >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> >> ... -- Extensible >> >> } >> >> >> >> SpecifiedCurve ::= SEQUENCE { >> >> version SpecifiedCurveVersion >> >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> >> fieldID FieldID {{FieldTypes}}, >> >> curve Curve, -- Curve E >> >> base ECPoint, -- Base point P >> >> order INTEGER, -- Order n of the base point >> >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> >> hash HashAlgorithm OPTIONAL, >> >> ... -- Extensible >> >> } >> >> >> >> SpecifiedCurveVersion ::= INTEGER { >> >> ecpVer1(1), >> >> ecpVer2(2), >> >> ecpVer3(3), >> >> ... -- Extensible >> >> } >> >> FIELD-ID ::= TYPE-IDENTIFIER >> >> >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> >> FIELD-ID.&id({IOSet}), >> >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> >> } >> >> >> >> FieldTypes FIELD-ID ::= { >> >> { Prime-p IDENTIFIED BY prime-field } | >> >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> >> ... -- Extensible >> >> } >> >> >> >> prime-field OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> >> >> Prime-p ::= INTEGER >> >> >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> >> >> Characteristic-two ::= SEQUENCE { >> >> m INTEGER, -- Field size 2^m >> >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> >> } >> >> >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> >> { NULL IDENTIFIED BY gnBasis } | >> >> { Trinomial IDENTIFIED BY tpBasis } | >> >> { Pentanomial IDENTIFIED BY ppBasis } | >> >> ... -- Extensible >> >> } >> >> >> >> gnBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 1 } >> >> >> >> tpBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 2 } >> >> >> >> Trinomial ::= INTEGER >> >> >> >> ppBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 3 } >> >> >> >> Pentanomial ::= SEQUENCE { >> >> k1 INTEGER, -- k1 > 0 >> >> k2 INTEGER, -- k2 > k1 >> >> k3 INTEGER -- k3 > k2 >> >> } >> >> >> >> Curve ::= SEQUENCE { >> >> a FieldElement, >> >> b FieldElement, >> >> seed BIT STRING OPTIONAL >> >> -- Shall be present if used in SpecifiedCurve >> >> -- with version of ecdpVer2 or ecdpVer3 >> >> } >> >> FieldElement ::= OCTET STRING >> >> >> >> ECPoint ::= OCTET STRING >> >>> -----Original Message----- >> >>> From: owner-ietf-ltans@mail.imc.org >> >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> >>> Sent: Thursday, December 06, 2007 4:52 AM >> >>> To: Turner, Sean P. >> >>> Cc: ietf-ltans@imc.org >> >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>> >> >>> We think, You misunderstood our last post. >> >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to >> >>> show >> >>> that we CANNOT use the AlgorithmIdentifier. >> >>> >> >>> The reason is, we cannot model the following cases: >> >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 >> >>> in >> >>> case of DSA). >> >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >>> >> >>> The main problem is that AlgorithmIdentifier describes entirely one >> >>> algorithm with all its parameters. Therefor it is not possible to set >> >>> different constraints for the parameters. >> >>> >> >>> so & tk >> >>> >> >>> >> >>> >> >>> Turner, Sean P. schrieb: >> >>>> This would work for me. >> >>>> >> >>>> spt >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >> >>>>> To: Turner, Sean P. >> >>>>> Cc: ietf-ltans@imc.org >> >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>>> >> >>>>> The problem with your suggested syntax is the definition of the our >> >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> >>> structure, we >> >>>>> would integrate the constraints as follows: >> >>>>> >> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >> >>>>> identifier AlgorithmIdentifier, >> >>>>> constraint CHOICE { >> >>>>> exact [0] OCTET STRING, >> >>>>> min [1] OCTET STRING, >> >>>>> max [2] OCTET STRING, >> >>>>> range [3] Range, >> >>>>> other [4] OtherConstraints >> >>>>> validity Validity OPTIONAL, >> >>>>> information Information OPTIONAL } >> >>>>> >> >>>>> It's not possible to determine constraints for more than one >> >>>>> parameter >> >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >> >>>>> Additionally defining ranges is impossible (e.g. modulus < >> >>>>> 2048 and modulus > 1024). >> >>>>> >> >>>>> >> >>>>> so & tk >> >>>>> >> >>>>> >> >>>>> Turner, Sean P. schrieb: >> >>>>>> I'm only commenting on the Parameter structure in the >> >>> ASN.1. I think >> >>>>>> that it might be better to change Algorithm to be a sequence of >> >>>>>> algorithmIdentifier, validity, and information - call it >> >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >> >>>>>> >> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >> >>>>>> algorithm's object identifier also define the parameters. So it >> >>>>>> probably makes sense to reuse this structure. >> >>>>>> >> >>>>>> 2. The parameters structures for some of the newer >> >>>>> algorithms is quite >> >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> >>>>> [RFC3279] >> >>>>>> aren't just an OID they are nested structure. >> >>>>>> >> >>>>>> (not sure how to do it in XML) >> >>>>>> >> >>>>>> Replace: >> >>>>>> >> >>>>>> Algorithm ::= SEQUENCE { >> >>>>>> algorithmIdentifier AlgID, >> >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >> >>>>>> validity [1] Validity, >> >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >> >>>>>> } >> >>>>>> >> >>>>>> AlgID ::= SEQUENCE { >> >>>>>> name UTF8String, >> >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >> >>>>>> } >> >>>>>> >> >>>>>> Parameter ::= SEQUENCE { >> >>>>>> name UTF8String, >> >>>>>> constraint CHOICE { >> >>>>>> exact [0] OCTET STRING, >> >>>>>> min [1] OCTET STRING, >> >>>>>> max [2] OCTET STRING, >> >>>>>> range [3] Range, >> >>>>>> other [4] OtherConstraints >> >>>>>> } >> >>>>>> } >> >>>>>> >> >>>>>> With: >> >>>>>> >> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >> >>>>>> AlgorithmIdentifier, >> >>>>>> validity Validity OPTIONAL, >> >>>>>> information Information OPTIONAL } >> >>>>>> >> >>>>>> Validity ::= SEQUENCE { >> >>>>>> start [0] GeneralizedTime OPTIONAL, >> >>>>>> end [1] GeneralizedTime OPTIONAL } >> >>>>>> >> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >>>>>> >> >>>>>> -- From RFC3280 >> >>>>>> AlgorithmIdentifier ::= SEQUENCE { >> >>>>>> algorithm OBJECT IDENTIFIER, >> >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >> >>>>>> -- contains a value of the type >> >>>>>> -- registered for use with the >> >>>>>> -- algorithm object >> >>> identifier value >> >>>>>> spt >> >>>>>> >> >>>>>> >> >>>> >> >> >> >> >> > > From owner-ietf-ltans@mail.imc.org Sat Jan 19 20:34:59 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGP5P-0002gI-7K for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 19 Jan 2008 20:34:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGP5O-00055S-NW for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 19 Jan 2008 20:34:59 -0500 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 m0K1LIQU082825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 18:21:18 -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 m0K1LIfm082824; Sat, 19 Jan 2008 18:21:18 -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-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0K1LGaC082818 for ; Sat, 19 Jan 2008 18:21:17 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=k5SdujPYhZyizsQxeI7HlFKp3y5Ci9IPHlnZbmM9VRg+Gc2g4/hCJr0tCBq+eqso; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGOs7-0000Z0-OG; Sat, 19 Jan 2008 20:21:16 -0500 Message-ID: <009301c85b02$c1292320$6401a8c0@tsg1> From: "TS Glassey" To: Cc: Subject: Rechartering the LTANS WG. Date: Sat, 19 Jan 2008 17:21:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79360b62ca8f8b5ae5d298ad3630946bc6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey From owner-ietf-ltans@mail.imc.org Sat Jan 19 22:07:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGQWw-000596-ML for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 19 Jan 2008 22:07:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGQWv-0006Rk-UY for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 19 Jan 2008 22:07:30 -0500 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 m0K2ur8a087579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 19:56:53 -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 m0K2urb8087578; Sat, 19 Jan 2008 19:56:53 -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-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0K2upJi087572 for ; Sat, 19 Jan 2008 19:56:52 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=KLHKjM03exNxpSSgXQ3UnEELSwLaXheX8eSTdgVJ5GhvDF98UJySS9VB5bki0oGl; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.21.61] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGQMY-0007da-6c; Sat, 19 Jan 2008 21:56:46 -0500 Message-ID: <4792D38F.39311D8B@ix.netcom.com> Date: Sat, 19 Jan 2008 20:52:31 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: TS Glassey CC: tobias.gondrom@gondrom.org, ietf-ltans@imc.org Subject: Re: Rechartering the LTANS WG. References: <009301c85b02$c1292320$6401a8c0@tsg1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688486db32b7eade17f612eea96b4bebd71350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.21.61 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Todd and all, This your proposal, seems like a very good idea... Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 TS Glassey wrote: > The LTANS WG is scheduled to review the charter in the May time frame. I > want to propose the addition of language to the charter to provide key > support in establishing an industry review panel to review this work which > will extend the LTANS operations for an additional year while those external > parties who want time to review and comment on the RFC's prior to their > standardization or advancement along the Standards Practice. > > Todd Glassey From owner-ietf-ltans@mail.imc.org Sun Jan 20 20:27:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGlRd-000188-Q2 for ltans-archive-ba2WohFa@lists.ietf.org; Sun, 20 Jan 2008 20:27:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGlRc-0000tG-97 for ltans-archive-ba2WohFa@lists.ietf.org; Sun, 20 Jan 2008 20:27:25 -0500 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 m0L1CAaA070737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2008 18:12: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 m0L1CAle070736; Sun, 20 Jan 2008 18:12: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 m0L1C7OE070728 for ; Sun, 20 Jan 2008 18:12:09 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 28126 invoked from network); 21 Jan 2008 01:05:18 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Jan 2008 01:05:18 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Jan 2008 01:05:18 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Rechartering the LTANS WG. Date: Sun, 20 Jan 2008 20:12:05 -0500 Message-ID: in-reply-to: <009301c85b02$c1292320$6401a8c0@tsg1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering the LTANS WG. Thread-Index: AchbA1eneHiS012cTrKZrPPP3sKx7wAxx5Hw References: <009301c85b02$c1292320$6401a8c0@tsg1> From: "Carl Wallace" To: "TS Glassey" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0L1CAOE070731 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a OK. There's no need to wait until May to commence the review. The specs are and have been available for review for quite some time. Tobias and I have tried to stimulate broader review (with limited success). If you can facilitate this, that'd be great. Thanks. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of TS Glassey Sent: Saturday, January 19, 2008 8:21 PM To: tobias.gondrom@gondrom.org Cc: ietf-ltans@imc.org Subject: Rechartering the LTANS WG. The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey From owner-ietf-ltans@mail.imc.org Sun Jan 20 21:32:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGmSL-00089s-IG for ltans-archive-ba2WohFa@lists.ietf.org; Sun, 20 Jan 2008 21:32:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGmSL-0001mG-3T for ltans-archive-ba2WohFa@lists.ietf.org; Sun, 20 Jan 2008 21:32:13 -0500 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 m0L2KC6F074736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2008 19:20:12 -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 m0L2KBAk074735; Sun, 20 Jan 2008 19:20:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0L2KAlI074729 for ; Sun, 20 Jan 2008 19:20:10 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fncgW1VLcyU2toRIx1+tZ7+BMVaR/j+48Z5mUKYAzd9rAac7eZTnsEiAiAE1F4+/; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGmGe-0003bg-KB; Sun, 20 Jan 2008 21:20:08 -0500 Message-ID: <002501c85bd4$24c231c0$6401a8c0@tsg1> From: "TS Glassey" To: "Carl Wallace" , Cc: , "Adrian McCullagh" , "Theodore Tso" References: <009301c85b02$c1292320$6401a8c0@tsg1> Subject: Re: Rechartering the LTANS WG. Date: Sun, 20 Jan 2008 18:19:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7998fb49d1d18a958841fdbe4e96565546350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Thanks Carl - my intent is to foster a public set of use models for using LTANS in an evidentiary manner. It will be interesting to see if the ISC itself comments on the technology and its use which was my intent. Todd Glassey ----- Original Message ----- From: "Carl Wallace" To: "TS Glassey" ; Cc: Sent: Sunday, January 20, 2008 5:12 PM Subject: RE: Rechartering the LTANS WG. OK. There's no need to wait until May to commence the review. The specs are and have been available for review for quite some time. Tobias and I have tried to stimulate broader review (with limited success). If you can facilitate this, that'd be great. Thanks. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of TS Glassey Sent: Saturday, January 19, 2008 8:21 PM To: tobias.gondrom@gondrom.org Cc: ietf-ltans@imc.org Subject: Rechartering the LTANS WG. The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey 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 m0L2KC6F074736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2008 19:20:12 -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 m0L2KBAk074735; Sun, 20 Jan 2008 19:20:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0L2KAlI074729 for ; Sun, 20 Jan 2008 19:20:10 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fncgW1VLcyU2toRIx1+tZ7+BMVaR/j+48Z5mUKYAzd9rAac7eZTnsEiAiAE1F4+/; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGmGe-0003bg-KB; Sun, 20 Jan 2008 21:20:08 -0500 Message-ID: <002501c85bd4$24c231c0$6401a8c0@tsg1> From: "TS Glassey" To: "Carl Wallace" , Cc: , "Adrian McCullagh" , "Theodore Tso" References: <009301c85b02$c1292320$6401a8c0@tsg1> Subject: Re: Rechartering the LTANS WG. Date: Sun, 20 Jan 2008 18:19:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7998fb49d1d18a958841fdbe4e96565546350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks Carl - my intent is to foster a public set of use models for using LTANS in an evidentiary manner. It will be interesting to see if the ISC itself comments on the technology and its use which was my intent. Todd Glassey ----- Original Message ----- From: "Carl Wallace" To: "TS Glassey" ; Cc: Sent: Sunday, January 20, 2008 5:12 PM Subject: RE: Rechartering the LTANS WG. OK. There's no need to wait until May to commence the review. The specs are and have been available for review for quite some time. Tobias and I have tried to stimulate broader review (with limited success). If you can facilitate this, that'd be great. Thanks. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of TS Glassey Sent: Saturday, January 19, 2008 8:21 PM To: tobias.gondrom@gondrom.org Cc: ietf-ltans@imc.org Subject: Rechartering the LTANS WG. The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey 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 m0L1CAaA070737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2008 18:12: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 m0L1CAle070736; Sun, 20 Jan 2008 18:12: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 m0L1C7OE070728 for ; Sun, 20 Jan 2008 18:12:09 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 28126 invoked from network); 21 Jan 2008 01:05:18 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Jan 2008 01:05:18 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Jan 2008 01:05:18 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Rechartering the LTANS WG. Date: Sun, 20 Jan 2008 20:12:05 -0500 Message-ID: in-reply-to: <009301c85b02$c1292320$6401a8c0@tsg1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering the LTANS WG. Thread-Index: AchbA1eneHiS012cTrKZrPPP3sKx7wAxx5Hw References: <009301c85b02$c1292320$6401a8c0@tsg1> From: "Carl Wallace" To: "TS Glassey" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0L1CAOE070731 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OK. There's no need to wait until May to commence the review. The specs are and have been available for review for quite some time. Tobias and I have tried to stimulate broader review (with limited success). If you can facilitate this, that'd be great. Thanks. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of TS Glassey Sent: Saturday, January 19, 2008 8:21 PM To: tobias.gondrom@gondrom.org Cc: ietf-ltans@imc.org Subject: Rechartering the LTANS WG. The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey 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 m0K2ur8a087579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 19:56:53 -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 m0K2urb8087578; Sat, 19 Jan 2008 19:56:53 -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-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0K2upJi087572 for ; Sat, 19 Jan 2008 19:56:52 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=KLHKjM03exNxpSSgXQ3UnEELSwLaXheX8eSTdgVJ5GhvDF98UJySS9VB5bki0oGl; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.21.61] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGQMY-0007da-6c; Sat, 19 Jan 2008 21:56:46 -0500 Message-ID: <4792D38F.39311D8B@ix.netcom.com> Date: Sat, 19 Jan 2008 20:52:31 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: TS Glassey CC: tobias.gondrom@gondrom.org, ietf-ltans@imc.org Subject: Re: Rechartering the LTANS WG. References: <009301c85b02$c1292320$6401a8c0@tsg1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688486db32b7eade17f612eea96b4bebd71350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.21.61 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Todd and all, This your proposal, seems like a very good idea... Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 TS Glassey wrote: > The LTANS WG is scheduled to review the charter in the May time frame. I > want to propose the addition of language to the charter to provide key > support in establishing an industry review panel to review this work which > will extend the LTANS operations for an additional year while those external > parties who want time to review and comment on the RFC's prior to their > standardization or advancement along the Standards Practice. > > Todd Glassey 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 m0K1LIQU082825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 18:21:18 -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 m0K1LIfm082824; Sat, 19 Jan 2008 18:21:18 -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-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0K1LGaC082818 for ; Sat, 19 Jan 2008 18:21:17 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=k5SdujPYhZyizsQxeI7HlFKp3y5Ci9IPHlnZbmM9VRg+Gc2g4/hCJr0tCBq+eqso; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JGOs7-0000Z0-OG; Sat, 19 Jan 2008 20:21:16 -0500 Message-ID: <009301c85b02$c1292320$6401a8c0@tsg1> From: "TS Glassey" To: Cc: Subject: Rechartering the LTANS WG. Date: Sat, 19 Jan 2008 17:21:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79360b62ca8f8b5ae5d298ad3630946bc6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The LTANS WG is scheduled to review the charter in the May time frame. I want to propose the addition of language to the charter to provide key support in establishing an industry review panel to review this work which will extend the LTANS operations for an additional year while those external parties who want time to review and comment on the RFC's prior to their standardization or advancement along the Standards Practice. Todd Glassey 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 m0I1Tswg066878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 18:29:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I1TsSU066877; Thu, 17 Jan 2008 18:29:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I1TqYx066869 for ; Thu, 17 Jan 2008 18:29:52 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gND7QN1Tr1VC9s6z1WZjSPmjKUsqCBIfwrbeD8c8/hE0Fdfs3MXaCT2qBL6aD22v; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JFg3J-0001dp-LP; Thu, 17 Jan 2008 20:29:50 -0500 Message-ID: <001501c85971$9e00d3d0$6401a8c0@tsg1> From: "TS Glassey" To: "Jeffrey A. Williams" Cc: "Thomas Kunz" , "Turner, Sean P." , , "Dan Swanson" , "DHS cert" , "DHS info" References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> <479004B6.EDCA48CF@ix.netcom.com> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 17 Jan 2008 17:29:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b852fdee61bdadfcb48c550a66c9651e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Jeffrey A. Williams" To: "todd glassey" Cc: "Thomas Kunz" ; "Turner, Sean P." ; ; "Dan Swanson" ; "DHS cert" ; "DHS info" Sent: Thursday, January 17, 2008 5:45 PM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > Todd and all, > > I believe that Todd has a good and valuable point here that > should not be discounted or otherwise ignored. The issue is simple here - these protocols are to perform tasks which have an actual impact under the law and as such the effect they produce or which can be had by using the protocol MUST be properly defined otherwise there is NO POSSIBLE REASON for building this protocol since it will be prevented from its being used by the Audit and Insurance Industry who will simply say they wont bond or recognize those that use the protocol. What we need is formal support and buy-in from any number of professional industries for LTANS and if we cannot get it, then anyone who uses the protocol will have to have their own protocol certified individually including the entire design. The problem is that this would give them leverage over what anyone else did with that protocol, since that certification would be for a specific implementation and not the actual protocol standard under their workproduct. The problem with this is that this 'commercial ownership of the certification' will encumber ALL of the other users who claim that their protocol is 'certified' as well. The reasoning is that one where basic protocol of party "A" was certified, to derivative claims against those other users by the first party to have their protocol certified. This also includes damages against the IETF in the process, and with this type of liability, IMHO no one will touch LTANS with a ten foot pole. That said, this can all be set aside by soliciting outside critique of the LTANS protocol by the people who would be responsible for using it and auditing it's implementation and use. Just my two cents Todd Glassey > It could > be however that whomever the "WE" is which Thomas is referring > to is unknown or not specifically defined or is a broader group that > has little or no concern or consideration as to whether all > are defined, ergo some international rather than US based/centric > legalistic requirement. If so, and I cannot myself determine base > on what I have seen or read thus far clearly enough to make such > a definitive determination, than I can only logically conclude that > the "Flat sequence" approach in this protocol will face significant > resistance as a viable standard. As such, it may be that the IETF > will face some significant resistance as a comprehensive standards > body. > > From my own perspective, I am beginning to find these latest > comments in this dialog, increasingly troubling.... > > Regards, > > Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > My Phone: 214-244-4827 > > todd glassey wrote: > >> ----- Original Message ----- >> From: "Thomas Kunz" >> To: "Turner, Sean P." >> Cc: >> Sent: Friday, December 07, 2007 7:06 AM >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> > We think, our flat sequence is sufficient. >> >> Actually - this is the problem we are facing now Thomas, that is from an >> evidence management perspective, this "We Think" is not sufficient to >> assure >> LTANS encapsulated documents meet the emerging and followon legal >> constraints for document archiving is a key flaw in the mindset. >> >> > >> > The goal of a policy is to specify a range for specific >> > (safety-critical) >> > parameters of an algorithm. Therefor it's not necessary to define all >> > parameters. >> >> Uh NO... A policy is a 'rule based on a set of constraints' and as such >> those constraints and the policy itself need to be defined and verifiable >> as >> well. >> >> > >> > In the evaluations of BSI and NIST >> > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms >> > only >> > one value is defined (namely q). By NIST a q_length of 160 is suitable >> > until 2010. >> >> But NIST itself nor BSI are underwriting anyone and those are the key >> issues. Also ANY service MUST meet the new US Rules of Civil Procedure >> and >> the updated Federal Rules of Evidence in specific to that content's >> admissibility in US Courts as 'ESI'... >> >> > >> > In this case, the XML structure would be: >> > >> > >> > >> > EC-DSA 160 >> > ... >> > >> > 160 >> > 2010-12-31 >> > >> > >> > >> > so & tk >> > >> > >> > >> > >> > >> > Turner, Sean P. schrieb: >> >> Yes I did misunderstand. With algorithms like DSA where there are few >> >> parameters your structure might work but for EC algorithms (I attached >> >> some >> >> of the ASN.1 for their parameters) I don't think the flat sequence of >> >> will >> >> work. >> >> >> >> ECParameters ::= CHOICE { >> >> namedCurve CURVE.&id({NamedCurve}), >> >> specifiedCuve SpecifiedCurve, >> >> implicitCurve NULL >> >> } >> >> >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> >> WITH SYNTAX { ID &id } >> >> >> >> NamedCurve CURVE ::= { >> >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> >> ... -- Extensible >> >> } >> >> >> >> SpecifiedCurve ::= SEQUENCE { >> >> version SpecifiedCurveVersion >> >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> >> fieldID FieldID {{FieldTypes}}, >> >> curve Curve, -- Curve E >> >> base ECPoint, -- Base point P >> >> order INTEGER, -- Order n of the base point >> >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> >> hash HashAlgorithm OPTIONAL, >> >> ... -- Extensible >> >> } >> >> >> >> SpecifiedCurveVersion ::= INTEGER { >> >> ecpVer1(1), >> >> ecpVer2(2), >> >> ecpVer3(3), >> >> ... -- Extensible >> >> } >> >> FIELD-ID ::= TYPE-IDENTIFIER >> >> >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> >> FIELD-ID.&id({IOSet}), >> >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> >> } >> >> >> >> FieldTypes FIELD-ID ::= { >> >> { Prime-p IDENTIFIED BY prime-field } | >> >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> >> ... -- Extensible >> >> } >> >> >> >> prime-field OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> >> >> Prime-p ::= INTEGER >> >> >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> >> >> Characteristic-two ::= SEQUENCE { >> >> m INTEGER, -- Field size 2^m >> >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> >> } >> >> >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> >> { NULL IDENTIFIED BY gnBasis } | >> >> { Trinomial IDENTIFIED BY tpBasis } | >> >> { Pentanomial IDENTIFIED BY ppBasis } | >> >> ... -- Extensible >> >> } >> >> >> >> gnBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 1 } >> >> >> >> tpBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 2 } >> >> >> >> Trinomial ::= INTEGER >> >> >> >> ppBasis OBJECT IDENTIFIER ::= { >> >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >> characteristic-two-basis(2) 3 } >> >> >> >> Pentanomial ::= SEQUENCE { >> >> k1 INTEGER, -- k1 > 0 >> >> k2 INTEGER, -- k2 > k1 >> >> k3 INTEGER -- k3 > k2 >> >> } >> >> >> >> Curve ::= SEQUENCE { >> >> a FieldElement, >> >> b FieldElement, >> >> seed BIT STRING OPTIONAL >> >> -- Shall be present if used in SpecifiedCurve >> >> -- with version of ecdpVer2 or ecdpVer3 >> >> } >> >> FieldElement ::= OCTET STRING >> >> >> >> ECPoint ::= OCTET STRING >> >>> -----Original Message----- >> >>> From: owner-ietf-ltans@mail.imc.org >> >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> >>> Sent: Thursday, December 06, 2007 4:52 AM >> >>> To: Turner, Sean P. >> >>> Cc: ietf-ltans@imc.org >> >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>> >> >>> We think, You misunderstood our last post. >> >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to >> >>> show >> >>> that we CANNOT use the AlgorithmIdentifier. >> >>> >> >>> The reason is, we cannot model the following cases: >> >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 >> >>> in >> >>> case of DSA). >> >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >>> >> >>> The main problem is that AlgorithmIdentifier describes entirely one >> >>> algorithm with all its parameters. Therefor it is not possible to set >> >>> different constraints for the parameters. >> >>> >> >>> so & tk >> >>> >> >>> >> >>> >> >>> Turner, Sean P. schrieb: >> >>>> This would work for me. >> >>>> >> >>>> spt >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >> >>>>> To: Turner, Sean P. >> >>>>> Cc: ietf-ltans@imc.org >> >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>>> >> >>>>> The problem with your suggested syntax is the definition of the our >> >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> >>> structure, we >> >>>>> would integrate the constraints as follows: >> >>>>> >> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >> >>>>> identifier AlgorithmIdentifier, >> >>>>> constraint CHOICE { >> >>>>> exact [0] OCTET STRING, >> >>>>> min [1] OCTET STRING, >> >>>>> max [2] OCTET STRING, >> >>>>> range [3] Range, >> >>>>> other [4] OtherConstraints >> >>>>> validity Validity OPTIONAL, >> >>>>> information Information OPTIONAL } >> >>>>> >> >>>>> It's not possible to determine constraints for more than one >> >>>>> parameter >> >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >> >>>>> Additionally defining ranges is impossible (e.g. modulus < >> >>>>> 2048 and modulus > 1024). >> >>>>> >> >>>>> >> >>>>> so & tk >> >>>>> >> >>>>> >> >>>>> Turner, Sean P. schrieb: >> >>>>>> I'm only commenting on the Parameter structure in the >> >>> ASN.1. I think >> >>>>>> that it might be better to change Algorithm to be a sequence of >> >>>>>> algorithmIdentifier, validity, and information - call it >> >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >> >>>>>> >> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >> >>>>>> algorithm's object identifier also define the parameters. So it >> >>>>>> probably makes sense to reuse this structure. >> >>>>>> >> >>>>>> 2. The parameters structures for some of the newer >> >>>>> algorithms is quite >> >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> >>>>> [RFC3279] >> >>>>>> aren't just an OID they are nested structure. >> >>>>>> >> >>>>>> (not sure how to do it in XML) >> >>>>>> >> >>>>>> Replace: >> >>>>>> >> >>>>>> Algorithm ::= SEQUENCE { >> >>>>>> algorithmIdentifier AlgID, >> >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >> >>>>>> validity [1] Validity, >> >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >> >>>>>> } >> >>>>>> >> >>>>>> AlgID ::= SEQUENCE { >> >>>>>> name UTF8String, >> >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >> >>>>>> } >> >>>>>> >> >>>>>> Parameter ::= SEQUENCE { >> >>>>>> name UTF8String, >> >>>>>> constraint CHOICE { >> >>>>>> exact [0] OCTET STRING, >> >>>>>> min [1] OCTET STRING, >> >>>>>> max [2] OCTET STRING, >> >>>>>> range [3] Range, >> >>>>>> other [4] OtherConstraints >> >>>>>> } >> >>>>>> } >> >>>>>> >> >>>>>> With: >> >>>>>> >> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >> >>>>>> AlgorithmIdentifier, >> >>>>>> validity Validity OPTIONAL, >> >>>>>> information Information OPTIONAL } >> >>>>>> >> >>>>>> Validity ::= SEQUENCE { >> >>>>>> start [0] GeneralizedTime OPTIONAL, >> >>>>>> end [1] GeneralizedTime OPTIONAL } >> >>>>>> >> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >>>>>> >> >>>>>> -- From RFC3280 >> >>>>>> AlgorithmIdentifier ::= SEQUENCE { >> >>>>>> algorithm OBJECT IDENTIFIER, >> >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >> >>>>>> -- contains a value of the type >> >>>>>> -- registered for use with the >> >>>>>> -- algorithm object >> >>> identifier value >> >>>>>> spt >> >>>>>> >> >>>>>> >> >>>> >> >> >> >> >> > > 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 m0HNnsE5060707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 16:49:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HNnsro060706; Thu, 17 Jan 2008 16:49:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HNnoRH060696 for ; Thu, 17 Jan 2008 16:49:53 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=qFnC0pdVGmf/P0auWwDk2P4+utxqNYm39uYcADorlgjmh/1WIJy9euFethPkS7VA; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.15.49] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JFeUU-0002TR-1d; Thu, 17 Jan 2008 18:49:48 -0500 Message-ID: <479004B6.EDCA48CF@ix.netcom.com> Date: Thu, 17 Jan 2008 17:45:26 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: todd glassey CC: Thomas Kunz , "Turner, Sean P." , ietf-ltans@imc.org, Dan Swanson , DHS cert , DHS info Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606886ee2220f5d74ee50feddaf9fa00deaf4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.15.49 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Todd and all, I believe that Todd has a good and valuable point here that should not be discounted or otherwise ignored. It could be however that whomever the "WE" is which Thomas is referring to is unknown or not specifically defined or is a broader group that has little or no concern or consideration as to whether all are defined, ergo some international rather than US based/centric legalistic requirement. If so, and I cannot myself determine base on what I have seen or read thus far clearly enough to make such a definitive determination, than I can only logically conclude that the "Flat sequence" approach in this protocol will face significant resistance as a viable standard. As such, it may be that the IETF will face some significant resistance as a comprehensive standards body. From my own perspective, I am beginning to find these latest comments in this dialog, increasingly troubling.... Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 todd glassey wrote: > ----- Original Message ----- > From: "Thomas Kunz" > To: "Turner, Sean P." > Cc: > Sent: Friday, December 07, 2007 7:06 AM > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > We think, our flat sequence is sufficient. > > Actually - this is the problem we are facing now Thomas, that is from an > evidence management perspective, this "We Think" is not sufficient to assure > LTANS encapsulated documents meet the emerging and followon legal > constraints for document archiving is a key flaw in the mindset. > > > > > The goal of a policy is to specify a range for specific (safety-critical) > > parameters of an algorithm. Therefor it's not necessary to define all > > parameters. > > Uh NO... A policy is a 'rule based on a set of constraints' and as such > those constraints and the policy itself need to be defined and verifiable as > well. > > > > > In the evaluations of BSI and NIST > > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > > one value is defined (namely q). By NIST a q_length of 160 is suitable > > until 2010. > > But NIST itself nor BSI are underwriting anyone and those are the key > issues. Also ANY service MUST meet the new US Rules of Civil Procedure and > the updated Federal Rules of Evidence in specific to that content's > admissibility in US Courts as 'ESI'... > > > > > In this case, the XML structure would be: > > > > > > > > EC-DSA 160 > > ... > > > > 160 > > 2010-12-31 > > > > > > > > so & tk > > > > > > > > > > > > Turner, Sean P. schrieb: > >> Yes I did misunderstand. With algorithms like DSA where there are few > >> parameters your structure might work but for EC algorithms (I attached > >> some > >> of the ASN.1 for their parameters) I don't think the flat sequence of > >> will > >> work. > >> > >> ECParameters ::= CHOICE { > >> namedCurve CURVE.&id({NamedCurve}), > >> specifiedCuve SpecifiedCurve, > >> implicitCurve NULL > >> } > >> > >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > >> WITH SYNTAX { ID &id } > >> > >> NamedCurve CURVE ::= { > >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > >> ... -- Extensible > >> } > >> > >> SpecifiedCurve ::= SEQUENCE { > >> version SpecifiedCurveVersion > >> ( ecpVer1 | ecpVer2 | ecpVer3 ), > >> fieldID FieldID {{FieldTypes}}, > >> curve Curve, -- Curve E > >> base ECPoint, -- Base point P > >> order INTEGER, -- Order n of the base point > >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > >> hash HashAlgorithm OPTIONAL, > >> ... -- Extensible > >> } > >> > >> SpecifiedCurveVersion ::= INTEGER { > >> ecpVer1(1), > >> ecpVer2(2), > >> ecpVer3(3), > >> ... -- Extensible > >> } > >> FIELD-ID ::= TYPE-IDENTIFIER > >> > >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType > >> FIELD-ID.&id({IOSet}), > >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) > >> } > >> > >> FieldTypes FIELD-ID ::= { > >> { Prime-p IDENTIFIED BY prime-field } | > >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | > >> ... -- Extensible > >> } > >> > >> prime-field OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > >> > >> Prime-p ::= INTEGER > >> > >> characteristic-two-field OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > >> > >> Characteristic-two ::= SEQUENCE { > >> m INTEGER, -- Field size 2^m > >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), > >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > >> } > >> > >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > >> > >> BasisTypes CHARACTERISTIC-TWO ::= { > >> { NULL IDENTIFIED BY gnBasis } | > >> { Trinomial IDENTIFIED BY tpBasis } | > >> { Pentanomial IDENTIFIED BY ppBasis } | > >> ... -- Extensible > >> } > >> > >> gnBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 1 } > >> > >> tpBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 2 } > >> > >> Trinomial ::= INTEGER > >> > >> ppBasis OBJECT IDENTIFIER ::= { > >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >> characteristic-two-basis(2) 3 } > >> > >> Pentanomial ::= SEQUENCE { > >> k1 INTEGER, -- k1 > 0 > >> k2 INTEGER, -- k2 > k1 > >> k3 INTEGER -- k3 > k2 > >> } > >> > >> Curve ::= SEQUENCE { > >> a FieldElement, > >> b FieldElement, > >> seed BIT STRING OPTIONAL > >> -- Shall be present if used in SpecifiedCurve > >> -- with version of ecdpVer2 or ecdpVer3 > >> } > >> FieldElement ::= OCTET STRING > >> > >> ECPoint ::= OCTET STRING > >>> -----Original Message----- > >>> From: owner-ietf-ltans@mail.imc.org > >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >>> Sent: Thursday, December 06, 2007 4:52 AM > >>> To: Turner, Sean P. > >>> Cc: ietf-ltans@imc.org > >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>> > >>> We think, You misunderstood our last post. > >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show > >>> that we CANNOT use the AlgorithmIdentifier. > >>> > >>> The reason is, we cannot model the following cases: > >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in > >>> case of DSA). > >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >>> > >>> The main problem is that AlgorithmIdentifier describes entirely one > >>> algorithm with all its parameters. Therefor it is not possible to set > >>> different constraints for the parameters. > >>> > >>> so & tk > >>> > >>> > >>> > >>> Turner, Sean P. schrieb: > >>>> This would work for me. > >>>> > >>>> spt > >>>> > >>>>> -----Original Message----- > >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>>> To: Turner, Sean P. > >>>>> Cc: ietf-ltans@imc.org > >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>>> > >>>>> The problem with your suggested syntax is the definition of the our > >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >>> structure, we > >>>>> would integrate the constraints as follows: > >>>>> > >>>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>>> identifier AlgorithmIdentifier, > >>>>> constraint CHOICE { > >>>>> exact [0] OCTET STRING, > >>>>> min [1] OCTET STRING, > >>>>> max [2] OCTET STRING, > >>>>> range [3] Range, > >>>>> other [4] OtherConstraints > >>>>> validity Validity OPTIONAL, > >>>>> information Information OPTIONAL } > >>>>> > >>>>> It's not possible to determine constraints for more than one parameter > >>>>> (e.g. p > 1024 and q > 160 in case of DSA). > >>>>> Additionally defining ranges is impossible (e.g. modulus < > >>>>> 2048 and modulus > 1024). > >>>>> > >>>>> > >>>>> so & tk > >>>>> > >>>>> > >>>>> Turner, Sean P. schrieb: > >>>>>> I'm only commenting on the Parameter structure in the > >>> ASN.1. I think > >>>>>> that it might be better to change Algorithm to be a sequence of > >>>>>> algorithmIdentifier, validity, and information - call it > >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>>> > >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>>> algorithm's object identifier also define the parameters. So it > >>>>>> probably makes sense to reuse this structure. > >>>>>> > >>>>>> 2. The parameters structures for some of the newer > >>>>> algorithms is quite > >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>>> [RFC3279] > >>>>>> aren't just an OID they are nested structure. > >>>>>> > >>>>>> (not sure how to do it in XML) > >>>>>> > >>>>>> Replace: > >>>>>> > >>>>>> Algorithm ::= SEQUENCE { > >>>>>> algorithmIdentifier AlgID, > >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>>> validity [1] Validity, > >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>>> } > >>>>>> > >>>>>> AlgID ::= SEQUENCE { > >>>>>> name UTF8String, > >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>>> } > >>>>>> > >>>>>> Parameter ::= SEQUENCE { > >>>>>> name UTF8String, > >>>>>> constraint CHOICE { > >>>>>> exact [0] OCTET STRING, > >>>>>> min [1] OCTET STRING, > >>>>>> max [2] OCTET STRING, > >>>>>> range [3] Range, > >>>>>> other [4] OtherConstraints > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> With: > >>>>>> > >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>>> AlgorithmIdentifier, > >>>>>> validity Validity OPTIONAL, > >>>>>> information Information OPTIONAL } > >>>>>> > >>>>>> Validity ::= SEQUENCE { > >>>>>> start [0] GeneralizedTime OPTIONAL, > >>>>>> end [1] GeneralizedTime OPTIONAL } > >>>>>> > >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>>> > >>>>>> -- From RFC3280 > >>>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>>> algorithm OBJECT IDENTIFIER, > >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>>> -- contains a value of the type > >>>>>> -- registered for use with the > >>>>>> -- algorithm object > >>> identifier value > >>>>>> spt > >>>>>> > >>>>>> > >>>> > >> > >> > > 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 m0HMFpqR054193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 15:15: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 m0HMFpXk054192; Thu, 17 Jan 2008 15:15: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 elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HMFnFV054186 for ; Thu, 17 Jan 2008 15:15:50 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MOhEJn6Z/Lb+VxkIZIrke/MqzAMssPuDlZfBiAeEzTnhMSJLN0H3+7nXuYnCoo7B; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JFd1X-0007O4-IJ; Thu, 17 Jan 2008 17:15:47 -0500 Message-ID: <06ec01c85956$82a8f6f0$174f7d40@home.glassey.com> From: "todd glassey" To: "Thomas Kunz" , "Turner, Sean P." Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 17 Jan 2008 13:07:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798268f76afcfec7383791a6715200c55a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Thomas Kunz" To: "Turner, Sean P." Cc: Sent: Friday, December 07, 2007 7:06 AM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > We think, our flat sequence is sufficient. Actually - this is the problem we are facing now Thomas, that is from an evidence management perspective, this "We Think" is not sufficient to assure LTANS encapsulated documents meet the emerging and followon legal constraints for document archiving is a key flaw in the mindset. > > The goal of a policy is to specify a range for specific (safety-critical) > parameters of an algorithm. Therefor it's not necessary to define all > parameters. Uh NO... A policy is a 'rule based on a set of constraints' and as such those constraints and the policy itself need to be defined and verifiable as well. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > one value is defined (namely q). By NIST a q_length of 160 is suitable > until 2010. But NIST itself nor BSI are underwriting anyone and those are the key issues. Also ANY service MUST meet the new US Rules of Civil Procedure and the updated Federal Rules of Evidence in specific to that content's admissibility in US Courts as 'ESI'... > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: >> Yes I did misunderstand. With algorithms like DSA where there are few >> parameters your structure might work but for EC algorithms (I attached >> some >> of the ASN.1 for their parameters) I don't think the flat sequence of >> will >> work. >> >> ECParameters ::= CHOICE { >> namedCurve CURVE.&id({NamedCurve}), >> specifiedCuve SpecifiedCurve, >> implicitCurve NULL >> } >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> WITH SYNTAX { ID &id } >> >> NamedCurve CURVE ::= { >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> ... -- Extensible >> } >> >> SpecifiedCurve ::= SEQUENCE { >> version SpecifiedCurveVersion >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> fieldID FieldID {{FieldTypes}}, >> curve Curve, -- Curve E >> base ECPoint, -- Base point P >> order INTEGER, -- Order n of the base point >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> hash HashAlgorithm OPTIONAL, >> ... -- Extensible >> } >> >> SpecifiedCurveVersion ::= INTEGER { >> ecpVer1(1), >> ecpVer2(2), >> ecpVer3(3), >> ... -- Extensible >> } >> FIELD-ID ::= TYPE-IDENTIFIER >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> FIELD-ID.&id({IOSet}), >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> } >> >> FieldTypes FIELD-ID ::= { >> { Prime-p IDENTIFIED BY prime-field } | >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> ... -- Extensible >> } >> >> prime-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> Prime-p ::= INTEGER >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> Characteristic-two ::= SEQUENCE { >> m INTEGER, -- Field size 2^m >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> } >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> { NULL IDENTIFIED BY gnBasis } | >> { Trinomial IDENTIFIED BY tpBasis } | >> { Pentanomial IDENTIFIED BY ppBasis } | >> ... -- Extensible >> } >> >> gnBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 1 } >> >> tpBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 2 } >> >> Trinomial ::= INTEGER >> >> ppBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 3 } >> >> Pentanomial ::= SEQUENCE { >> k1 INTEGER, -- k1 > 0 >> k2 INTEGER, -- k2 > k1 >> k3 INTEGER -- k3 > k2 >> } >> >> Curve ::= SEQUENCE { >> a FieldElement, >> b FieldElement, >> seed BIT STRING OPTIONAL >> -- Shall be present if used in SpecifiedCurve >> -- with version of ecdpVer2 or ecdpVer3 >> } >> FieldElement ::= OCTET STRING >> >> ECPoint ::= OCTET STRING >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>> Sent: Thursday, December 06, 2007 4:52 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> We think, You misunderstood our last post. >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>> that we CANNOT use the AlgorithmIdentifier. >>> >>> The reason is, we cannot model the following cases: >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>> case of DSA). >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>> >>> The main problem is that AlgorithmIdentifier describes entirely one >>> algorithm with all its parameters. Therefor it is not possible to set >>> different constraints for the parameters. >>> >>> so & tk >>> >>> >>> >>> Turner, Sean P. schrieb: >>>> This would work for me. >>>> >>>> spt >>>> >>>>> -----Original Message----- >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>> To: Turner, Sean P. >>>>> Cc: ietf-ltans@imc.org >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>> >>>>> The problem with your suggested syntax is the definition of the our >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>> structure, we >>>>> would integrate the constraints as follows: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>> identifier AlgorithmIdentifier, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> It's not possible to determine constraints for more than one parameter >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>> 2048 and modulus > 1024). >>>>> >>>>> >>>>> so & tk >>>>> >>>>> >>>>> Turner, Sean P. schrieb: >>>>>> I'm only commenting on the Parameter structure in the >>> ASN.1. I think >>>>>> that it might be better to change Algorithm to be a sequence of >>>>>> algorithmIdentifier, validity, and information - call it >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>> algorithm's object identifier also define the parameters. So it >>>>>> probably makes sense to reuse this structure. >>>>>> >>>>>> 2. The parameters structures for some of the newer >>>>> algorithms is quite >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>> [RFC3279] >>>>>> aren't just an OID they are nested structure. >>>>>> >>>>>> (not sure how to do it in XML) >>>>>> >>>>>> Replace: >>>>>> >>>>>> Algorithm ::= SEQUENCE { >>>>>> algorithmIdentifier AlgID, >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>> validity [1] Validity, >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>> } >>>>>> >>>>>> AlgID ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>> } >>>>>> >>>>>> Parameter ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> } >>>>>> } >>>>>> >>>>>> With: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>> AlgorithmIdentifier, >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> Validity ::= SEQUENCE { >>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>> >>>>>> -- From RFC3280 >>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>> algorithm OBJECT IDENTIFIER, >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>> -- contains a value of the type >>>>>> -- registered for use with the >>>>>> -- algorithm object >>> identifier value >>>>>> spt >>>>>> >>>>>> >>>> >> >> > 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 m02Gw7oj031386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 09:58:07 -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 m02Gw7px031385; Wed, 2 Jan 2008 09:58:07 -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 ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02Gw5Uu031376 for ; Wed, 2 Jan 2008 09:58:06 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id EBFED43; Wed, 2 Jan 2008 17:58:02 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01480-03; Wed, 2 Jan 2008 17:58:00 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 7FD682C; Wed, 2 Jan 2008 17:58:00 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008010217575976:187343 ; Wed, 2 Jan 2008 17:57:59 +0100 Message-ID: <477BC297.5080008@edelweb.fr> Date: Wed, 02 Jan 2008 17:57:59 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: todd glassey Cc: Jesus Maria Mendez Perez , Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> <054301c84823$352520a0$174f7d40@home.glassey.com> In-Reply-To: <054301c84823$352520a0$174f7d40@home.glassey.com> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:57:59 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:58:00 PM, Serialize complete at 01/02/2008 05:58:00 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040405070401050002030504" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms040405070401050002030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable > > As to your commentary - Those five hours of data are spoiled and well=20 > - that makes this a real issue I think. > What is the issue in your opinion? - The archive does not yet agree to have a safe copy? (and may be in=20 fact it is lying?) - The archive may loose everything withing these 5 hours (+1 day etc),=20 before sending the ack. If you want to make the group listen to you comments you should provide at least more details of the problem space, ideas of possibles approaches= or ask for clarifications about something concrete. The approach used in this group (as well as in others) is to define=20 technology not just as a minimalistic reaction to whatever concrete legislation or=20 jurisprudence. No games between 'Hase und Igel'. Happy new year Peter --=20 To verify the signature, see http://edelpki.edelweb.fr/=20 Cela vous permet de charger le certificat de l'autorit=E9;=20 die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 --------------ms040405070401050002030504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODAxMDIxNjU3NTlaMCMGCSqGSIb3DQEJBDEWBBQiu7W/BgX+V4FLlwnl9gOQGQBWYzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYDOwKOPRkWAUpCcFxwUGHd4pJPKMrIdEDL8nRn1XNHNlLutWM2631lcjXxn riNs00FQYo91IwUyhmFSpmLwRzeNIv6hkX7rxeM/gJBCAHZUwO+f9ONDfjHeq6tF8/fOR700 TGpHhROouJ9ncjSlbAz41GZEEySDmEgL/lV+Iiv7jQAAAAAAAA== --------------ms040405070401050002030504-- 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 m02GnBMo030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 09:49: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 m02GnBGB030698; Wed, 2 Jan 2008 09:49:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02Gn9xe030690 for ; Wed, 2 Jan 2008 09:49:10 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id CA6411F; Wed, 2 Jan 2008 17:49:07 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01372-08; Wed, 2 Jan 2008 17:49:03 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 32E4444; Wed, 2 Jan 2008 17:49:03 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008010217490104:187337 ; Wed, 2 Jan 2008 17:49:01 +0100 Message-ID: <477BC07D.6090003@edelweb.fr> Date: Wed, 02 Jan 2008 17:49:01 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Jesus Maria Mendez Perez Cc: Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:49:01 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 01/02/2008 05:49:02 PM, Serialize complete at 01/02/2008 05:49:02 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904010506020201080909" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms060904010506020201080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jesus Maria Mendez Perez wrote: > Hello Tobias, I=B4m Jesus. Merry Christmas. > > I have some questions and I hope you can help me. > > First, about what happen with the gap of time that pass while you send = > a data object and finally at the evening the ERS-system build > the hastree for all documents that were archived during that day?. For = > example, if you send a data object at 3:00 pm and the ERS-system build = > the hashtree at 8:00 pm... you have 5 hours during which that data=20 > object could lose its integrity. What can we do in this situation? > Could be the solution to timestamp every data object separately and=20 > inmediately after they are sent by the client and when the ERS-system=20 > have to build the hashtree, the hash-tree will built with all these=20 > data objects and its timestamps? IMO opinion you need to distingusih two events: A 3:00pm a client enters = something into an archive.Looking at LTAP, this may result in a first 'receipt', indicating that archiving = is 'in progress'. At 8:00 or even a day later (when backup copies etc are made), the archive may=20 return a 'now we have a safe archived copy' message. > > And now about the ARCHIVE operation. In the LTAP Protocol draft is=20 > said LTAP Protocol is asynchronous by nature. And my question is about = > then second response (service response). Will a client receive the=20 > second response when the TAS hast just received the data object or=20 > when the archive operation has just finished (the hashtree has been=20 > built)? The second message is sent when the TAS can safely assume that it has a=20 good recoverable copy. If ERS is part of the policy of the TAS, then the TAS most likely does=20 not respond before having created a good tree, and backups and backups of the trees ... etc > If the ARCHIVE operation is asynchronous we really need another=20 > operation to permit a client to check if the full archive operation=20 > has finished... Which is the case with LTAP. The protocol does not necessarily be mapped to HTTP, you can map the second ack to a mail based service. The abstract protocol allows to 'poll for a response' in several ways: After having received the initial response or even before, you can=20 repeat the archive operation using the hash of the data as reference or the reference=20 return by the initial ack. You do this until you get the final response. What this means is that a client does have to do some housekeeping in=20 some 'spooling server' similar to email or to a tcp stack. Even the initial ack is conceptually asynchronous allow a client API=20 implementation to be completely non-blocking, etc. > > Finally about the information called "Complementary data" in the=20 > article "Long-term trusted preservation service using service=20 > interaction protocol and evidence records", does it include only=20 > timestamping certificates?, or does it include timestamps' certificates= > and user signer=B4s certificates?. Are they obtain by SCVP and save up = > as complementary data in the archive operation? I let Aljosa answer this. > > Thanks and Happy Christmas > Happy new year. Peter --=20 To verify the signature, see http://edelpki.edelweb.fr/=20 Cela vous permet de charger le certificat de l'autorit=E9;=20 die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 --------------ms060904010506020201080909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODAxMDIxNjQ5MDFaMCMGCSqGSIb3DQEJBDEWBBT+04SFrWI/cy9/hrkxiR32mjuqjDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYCaR7NrhXk0IqSOs2z4csTgBQp4JODworkxWAqkVJY/HDugWnSvD/FD0+BQ SIA1o/suj/nnHcj/SfVQce/qyWycrFIiP6GKS7QaxQxq0T4rcV7S5RKxnWZAtPAMEpRDBIQE obtIa/P9AyIrk7wCCiBgFhVuEr70t9qd5XeEODVkfgAAAAAAAA== --------------ms060904010506020201080909--