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 k4JHPD77068651; Fri, 19 May 2006 10:25:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JHPDdE068650; Fri, 19 May 2006 10:25:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JHPCag068634 for ; Fri, 19 May 2006 10:25:12 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4JHP3L23634; Fri, 19 May 2006 19:25:03 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Fri, 19 May 2006 19:25:04 +0200 (MET DST) Message-ID: <446DFF0F.1070804@edelweb.fr> Date: Fri, 19 May 2006 19:23:27 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Julien Stern CC: ietf-ltans@imc.org Subject: Re: ERS tagging References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> <446603E4.2020707@edelweb.fr> <20060516155620.GA22690@cryptolog.com> <446A0CFE.5050701@edelweb.fr> <446A1212.4050507@edelweb.fr> <20060516181643.GB22690@cryptolog.com> In-Reply-To: <20060516181643.GB22690@cryptolog.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000809020004010702060700" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000809020004010702060700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julien Stern wrote: > Peter, > > I guess that smart decoders would read the algorithm identifier > as an opaque sequence and check if there is something else prior > to continuing to decode. > in ASN.1 there is no need to create such "smart" (inefficient) decoders. The goal of a asn.1 is to allow fast creation and decoding of data. If one would allow such syntaxes then you would require decoders to always behave like that. Why would you stop at one level? You could as well ask that as soon as you are able to find one pattern that matches. > But at any rate, you are right. I do not have the norm handy > but I after checking in an ASN.1 book it does seem that the current > ArchiveTimeStamp syntax is ambiguous. > Yes, ASN.1 specifies for SEQUENCE types *4.5.1* Where there are one or more consecutive occurrences of "ComponentType" that are all marked *OPTIONAL* or *DEFAULT*, the tags of those "ComponentType"s and of any immediately following component type in the series shall be distinct (see clause 30). If automatic tagging was selected, the requirement that tags be distinct applies only after automatic tagging has been performed, and will always be satisfied. --------------ms000809020004010702060700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTE5MTcyMzI3WjAjBgkqhkiG9w0B CQQxFgQUt/BlJtFGdNDnlWxSiag1NtmfiUEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAWP0pnC1we/7oR1E3 G49WL8JR+UAEptnGK3hL4+Kf6H2CkX844LSkY8qsuxE5N3Ekgy0H9kUzZLhzWiDbHUMcJbql ofCW1ZxgN6Mmg9EyzSLIt2waXlUCdCLV4qbbyClf0D1falf0bPkD0WhZlA8b5kBILFZe3w8k I7O5qwU5swMAAAAAAAA= --------------ms000809020004010702060700-- 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 k4IEBWgL003935; Thu, 18 May 2006 07:11:32 -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 k4IEBW8i003934; Thu, 18 May 2006 07:11:32 -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 EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IEBVZk003908 for ; Thu, 18 May 2006 07:11:31 -0700 (MST) (envelope-from cwallace@orionsec.com) 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: I-D ACTION:draft-ietf-ltans-ers-scvp-01.txt Date: Thu, 18 May 2006 07:11:25 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87902CFF191@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ltans-ers-scvp-01.txt thread-index: AcZ57eK4XJzgCghHRq2CY6sxVNu1EgAlq1cg From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4IEBVZk003929 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This draft features slight modifications to the -00 draft. The primary change is that this version targets the CertReply.cert field when an evidence record for a certificate is requested instead of assuming the certificate will be returned as a replyWantBack. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, May 17, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: ietf-ltans@imc.org > Subject: I-D ACTION:draft-ietf-ltans-ers-scvp-01.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Long-Term Archive and Notary > Services Working Group of the IETF. > > Title : Using SCVP to Convey Long-term > Evidence Records > Author(s) : C. Wallace > Filename : draft-ietf-ltans-ers-scvp-01.txt > Pages : 16 > Date : 2006-5-17 > > The Simple Certificate Validation Protocol (SCVP) defines an > extensible means of delegating the development and validation > of certification paths to a server. It can be used to > support the development and validation of certification paths > well after the expiration of the certificates in the path by > specifying a time of interest in the past. The Evidence > Record Syntax (ERS) defines structures, called evidence > records, to support non-repudiation of existence of data. > Evidence records can be used to preserve materials that > comprise a certification path such that trust can be > established in the certificates after the expiration of the > certificates in the path and after the cryptographic > algorithms used to sign the certificates in the path are no > longer secure. This document describes an application of > SCVP to serve this purpose using the WantBack feature of SCVP > to convey evidence records. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-01.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-ltans-ers-scvp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ltans-ers-scvp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > 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 k4HJoD4n064273; Wed, 17 May 2006 12:50:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HJoDVJ064272; Wed, 17 May 2006 12:50:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HJoDRk064245 for ; Wed, 17 May 2006 12:50:13 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4HJo2et019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgS1y-0002Am-4B; Wed, 17 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-scvp-01.txt Message-Id: Date: Wed, 17 May 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Using SCVP to Convey Long-term Evidence Records Author(s) : C. Wallace Filename : draft-ietf-ltans-ers-scvp-01.txt Pages : 16 Date : 2006-5-17 The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust can be established in the certificates after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-scvp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-scvp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-17105610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-17105610.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HJoBkf064263; Wed, 17 May 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HJoBL6064262; Wed, 17 May 2006 12:50:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HJoAYQ064242 for ; Wed, 17 May 2006 12:50:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4HJo267000975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgS1y-0002Ac-2v; Wed, 17 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-07.txt Message-Id: Date: Wed, 17 May 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-Term Archive Service Requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-07.txt Pages : 19 Date : 2006-5-17 There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-reqs-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-reqs-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-17105341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-17105341.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H6igqL083355; Tue, 16 May 2006 23:44:42 -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 k4H6ig0c083354; Tue, 16 May 2006 23:44:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H6idao083337 for ; Tue, 16 May 2006 23:44:40 -0700 (MST) (envelope-from reiglmai@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4H6ibLt017895; Wed, 17 May 2006 08:44:38 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Why are the hash values sorted? Date: Wed, 17 May 2006 08:44:37 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680D8D3B@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why are the hash values sorted? Thread-Index: AcZ5DYBQvosDE9eAT1GSuaY5j0OOrAAav4VA From: "Robert Eiglmaier" To: , "Tilo Kienitz" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4H6ifao083348 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Tilo, I have some comments on your comments: > But searching something in the tree is a seldom operation. Actually, no. If your documents contain a personal signature the person who verifies it must also verify the timestamp to be sure that the signature has been created while the client certificate was valid (not before, not after). If the document doesn't even have a client signature verification can only be that of the timestamp. In each case you must look up the document's hash in the hashtree. > If for example a parent node on a middle level has 1000 children, > then these 1000 hashes have to be there in the reduced hash tree > and not only 999. That's a bit absurd. Who would create a hashtree with an arity of 1000? Typical values are 2 or 3. If you have e. g. a tree of arity 3 and on each level you put 3 hashvalues instead of only 2 neighbors this already means an increase of 50% in size. With a binary tree it would mean doubling the size. But finally I think the most important reason why preserving the order wouldn't be a good idea is not a technical one. I'll try to explain: Situation 1.) So far we have ArchiSig with hashtrees with sorted hash values. If you stand in front of a judge with an evidence record this allows to prove that a certain document already existed at a certain point in time and it has not been modified. This works. No further information needed. Nothing else proved. Situation 2.) We have ArchiSig with hashvalues in the order of arrival. You want to convince the judge that one document in the list is older than another because of the hash value's position in the tree. Now you would have to also prove that your application that you used to create the hashtree actually does what you claim, that exactly that application has been used for that certain hashtree, that nobody has tempered around on your machine etc... This is what I meant in my first mail: hash value ordering can only be a hint - it is no proof. To prove the order of document arrival you must put a single timestamp on each document. You can then put the hashvalues of those single timestamps into a hashtree and renew the signatures every n years. That way you have both, information (and proof) of the order of the document arrivals and renewal of signatures with ArchiSig. Kind regards Robert -----Original Message----- From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] Sent: Dienstag, 16. Mai 2006 19:24 To: Robert Eiglmaier Cc: ietf-ltans@imc.org Subject: Re: Why are the hash values sorted? Hi Robert, thank you for your comments. > there are some more (technical) reasons for sorting the hashes: > > In an unsorted hashtree searching a certain hash value becomes > slow whereas in a sorted tree you can look it up real quick > with binary search. > Sorting is done only once when creating the tree, searching > is done everytime a document needs to be verified. That's right. But searching something in the tree is a seldom operation. We only need to do it when an algorithm in the original document's signature has expired and still somebody is interested in verifying the signature. Of course that will happen sometimes, but the older a documents gets the less often it will be used. Furthermore the hash tree is the logical structure and there may be a different physical structure in the data base. The data base could create an index which might for example contain a binary sorted tree. > The format of the reduced hashtree would have to be changed > for unsorted hashtrees because for all the middle levels of the > tree only the neighbor hashvalue(s) are given. There is no > information where to put the calculated hashvalue. Left or right > or if the arity > 2 somewhere between the neighbors? > If they are sorted, this is unambiguous. Right. It would be necessary to put each required node completely into the reduced hash tree. If for example a parent node on a middle level has 1000 children, then these 1000 hashes have to be there in the reduced hash tree and not only 999. I do not see a problem in this change. > And finally ArchiSig hashtrees have not been designed to prove > the order in which the documents arrived in an archive. Even if > the hashvalues would represent that order, this would be a hint > but no proof. So we will need a flag which expresses that in this hash tree the order of the hashes represents the order in which the hashes arrived in the archive. By order in the hash tree I mean a depth-first-enumeration of the leafs starting with the left-most leaf. > You might create an additional document with references (hashes) > of your documents and e. g. the current date & time and add it > to the archive before creating the hashtree so that it is > timestamped. We thought about it and it is possible. But it makes the data structure more complicated. Some of our customers need to know the order in which the documents arrived in the archive. The easiest way to achieve this is to maintain the order in the tree. We could do it more complicated with additional documents and time stamps, but why should we? Kind regards Tilo 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 k4GJtNaD045891; Tue, 16 May 2006 12:55:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GJtNQX045890; Tue, 16 May 2006 12:55:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJtNex045866 for ; Tue, 16 May 2006 12:55:23 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-ltans-reqs-06.txt Date: Tue, 16 May 2006 12:55:17 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87902C6D71C@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ltans-reqs-06.txt thread-index: AcZqokiF2onhi8+MRDCGBKaEIaY5FwATLHkgA4zc7xA= From: "Carl Wallace" To: "Larry Masinter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GJtNex045885 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks, Larry. A new version with each of your suggestions executed will be posted and progressed. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter > Sent: Friday, April 28, 2006 5:22 PM > To: ietf-ltans@imc.org > Subject: RE: WG Last Call: draft-ietf-ltans-reqs-06.txt > > > Minor editorial comments: > > > Typo: > "A long-term archive service provides a evidence that may > be used to" > > "provides a evidence" => "provides evidence" > > > The next to last paragraph of section 6 (Security Considerations): > > Additional mechanisms, applications or tools may be > needed to preserve the value of evidence records associated with > original archived data object. Other specifications of LTANS, in > particular certification services will address these problems. > > > but "LTANS" isn't defined in this document. I suggest just > deleting the "Other specifications..." sentence, since it's > not needed. > > I wonder about Appendix B, because it isn't referenced in the > text and doesn't seem directly related to the topic of the document. > The simplest edit would be just to remove it. Otherwise, you > should explain how it relates to the main document. > > Larry > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GIGsFf025175; Tue, 16 May 2006 11:16: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 k4GIGseq025174; Tue, 16 May 2006 11:16: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 kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GIGrYk025159 for ; Tue, 16 May 2006 11:16:53 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 16EA540E2D for ; Tue, 16 May 2006 20:16:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id CE5274410B for ; Tue, 16 May 2006 20:17:15 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15823-04 for ; Tue, 16 May 2006 20:17:10 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 27E3C44104 for ; Tue, 16 May 2006 20:17:09 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 16 May 2006 20:16:45 +0200 From: "Julien Stern" Date: Tue, 16 May 2006 20:16:44 +0200 To: ietf-ltans@imc.org Subject: Re: ERS tagging Message-ID: <20060516181643.GB22690@cryptolog.com> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> <446603E4.2020707@edelweb.fr> <20060516155620.GA22690@cryptolog.com> <446A0CFE.5050701@edelweb.fr> <446A1212.4050507@edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <446A1212.4050507@edelweb.fr> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, I guess that smart decoders would read the algorithm identifier as an opaque sequence and check if there is something else prior to continuing to decode. But at any rate, you are right. I do not have the norm handy but I after checking in an ASN.1 book it does seem that the current ArchiveTimeStamp syntax is ambiguous. I guess I was confused by the fact that SEQUENCE ::= { a someType, b someType OPTIONAL } is correct while SEQUENCE ::= { b someType OPTIONAL, a someType } is ambiguous when streaming. Quite logical when one thinks about it ;) Anyway, I agree with Peter that the syntax is ambiguous and that a tag needs to be added on either digestAlgorithm or timeStamp. -- Julien On Tue, May 16, 2006 at 07:55:30PM +0200, Peter Sylvester wrote: > I meant decoders. > > I know that many asn.1 tools/parsers/compiler do not check for > ambiguous syntaxes, i.e. they don't warn you. I was hit by that > several times, that why the DVCS syntax has little bugs. > > >ArchiveTimeStamp ::= SEQUENCE { > > digestAlgorithm AlgorithmIdentifier OPTIONAL, > > reducedHashtree [0] SEQUENCE OF PartialHashtree OPTIONAL, > > timeStamp ContentInfo} > > When decoding 30 LLLL 30 LLLL probably decoders decide > that there is an AlgorithmIdentifier. > > If you coder ALWAYS sets an algorithmidentifier, then you don't even get > an error when decoding with a decoder produced by some tools. > But as soon as you only encode the timeStamp ... you may not get an error > either, it is just that at best the timeStamp appears as > algorithmIdentifier. > > >ASN.1 parsers are streaming, i.e. are not looking ahead. > >Any syntax must be constructed in a such a way that only by looking > >at the tag > >you know what it means. > > > > > -- > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorité; > die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. > 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 k4GI9tw7023686; Tue, 16 May 2006 11:09:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GI9teX023685; Tue, 16 May 2006 11:09:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GI9tqo023650 for ; Tue, 16 May 2006 11:09:55 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: ERS tagging Date: Tue, 16 May 2006 11:09:49 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01C678F2.61982EE0" Message-ID: <82D5657AE1F54347A734BDD33637C87902C6D437@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ERS tagging thread-index: AcZ5ERJWWcU3JQZAToifIlsfVy5+BwAACmjg From: "Carl Wallace" To: "Peter Sylvester" , "Julien Stern" , Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C678F2.61982EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On a side note, there are two errors in the new module that prevent successful compilation. There's no semi-colon after the IMPORTS/EXPORTS section and there's a missing comma in the CryptoInfo definition.=20 With regard to the ambiguity, I think Peter is right. We should = redefine the structure with tags on both of the OPTIONAL fields: ArchiveTimeStamp ::=3D SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} PartialHashtree ::=3D SEQUENCE OF OCTET STRING > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org=20 > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Peter Sylvester > Sent: Tuesday, May 16, 2006 1:34 PM > To: Julien Stern; ietf-ltans@imc.org > Subject: Re: ERS tagging >=20 > Julien Stern wrote: > > Folks, > > > > I would personally be happy with any syntax. However, I find it=20 > > somewhat weird to choose one syntax over an other just=20 > because of bugs=20 > > in one ASN.1 compiler or an other. > > =20 > And as far as I was informed one of the compilers seemed to be fixed. > > Anyway, to be best of my ASN.1 knowledge, the current syntax is not=20 > > ambiguous because the ContentInfo is not optional. Therefore, it is=20 > > possible to figure out if we are reading the digestAlgorithm or the=20 > > timestamp based on the number of elements in the structure,=20 > even when=20 > > the reducedHashtree is absent. However, adding a tag on the=20 > timestamp=20 > > (or on the digestAlgorithm actually) may help some ASN.1=20 > processors,=20 > > notably those with streaming capabilities. > > > > =20 > ASN.1 parsers are streaming, i.e. are not looking ahead. > Any syntax must be constructed in a such a way that only by=20 > looking at the tag you know what it means. >=20 > -- > To verify the signature, see http://edelpki.edelweb.fr/ Cela=20 > vous permet de charger le certificat de l'autorit=E9; die Liste=20 > mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 >=20 >=20 ------=_NextPart_000_0022_01C678F2.61982EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMDCCBEAw ggMooAMCAQICBEClE7wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE0MzA1NVoXDTA3MDUxNzE1MDA1NVowWzELMAkGA1UE BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95 ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALLi +sA/Id5PcQ8uPHjuKlWcxrb8kQkBkJrn4Vv/KNrpZZcIO0mTxp28yVqg3fJRWszamV3cbE77oXV/ 0AFxrRhf89avN0lrUmqSBsf7ph8Zfz8HMbNODQvGOsKCGa4HA1jujeTnIqgrlCyyUORELVu4i2a7 uErbLjIX7SHNxGtlAgMBAAGjggGHMIIBgzALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVY3dhbGxh Y2VAb3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8G A1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cu b3Jpb25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxn ZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY 0jAdBgNVHQ4EFgQUB0yg8DWubbASzzui5JhAF3+oIRYwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAE DDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAYh0dywIAWMho3sca3AwuMZiepipLDF/+ +vrm9Md+P9AfS6pjwRbsBNcS9425jr56ANJXALioZoxDMKlRKXy+Hmj8wXq8nMgPkmfLYhvP+PVn KgOkoQtT3ym7FSCwrDJEvO0azG6uRxhuIevShRsBaxsCCjdnf6xG6OGV0KrniweAsnNoZPdq6bHI 2ZAk8hZNWHWwGmYo1lP9MeZ+5aYvG1T3OoKI7Kyg4SM/OjjqxwuGC1Zoh1nAJHrBuvRxvhrzvf9t 5ff5r7/YEguVTRfnviUhAyB56auTb1+lY+sz+NQB0kBkSXwvq1+R6pJ3eBWH7o9h5QI87j0IbrL/ ZXhj0zCCBG0wggNVoAMCAQICBEClPlowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBB dXRob3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA2MDMxNjExNDI0M1oXDTA5MDMxNjEyMTI0M1ow WzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UE CxMJRW1wbG95ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAJj2L4V9bKgndsWwpRiVZVWHSOz64C51pN3lHqW4Z7JngddkDMJTQgMndKpQnMm+Upmr NwtBn5F27PA7hPppS+eqZrwVQdqDuiSlAzrFYfggzHaiLSDv5XIqraUv7IsPOAPrlyUa63ENwyjj AasbL11IM6vkHEeD1ovImgkuE06PAgMBAAGjggG0MIIBsDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQw IoAPMjAwNjAzMTYxMTQyNDNagQ8yMDA4MDQyMTE2MTI0M1owIAYDVR0RBBkwF4EVY3dhbGxhY2VA b3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8GA1UE ChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhv cml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cub3Jp b25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVz ZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAd BgNVHQ4EFgQU0kRLkKUbCoZeTPUKX2mP3iFf+HQwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAK GwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAfj4SP2DX+0YgInGCzrK6Oom5mXNyKVgjmyiI UnvZ4JN5SbEcuIc81be23CgCKqZtjGgnlk3qyc8Ge2z7tNO1pFJqEuzzB0uLwceQddRszga4r5nz h/sfdFOzM9bMghLItanJonRsrPybZM8zIDH+5MFHir1MUaf6ksItF+e4HUBJkggI2Cq2+YCsB2wx qTLenzpsg6H3bmG9aGUmcdlj8jk7vpJvx3oz7xkMzxtQ+viakqsv7XJZg3mX9aIrWjOsdmUlxo9w DqZvxch8fe8vJXjvtDlTG6iddyyHSrtGQdQbRIa79ZCePExEt93gLMB7t8RixMh4frpitspnFj6i kzCCBXcwggRfoAMCAQICBEClE1EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNV BAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNDE5MDMxMloXDTI0MDUxNDE5MzMxMlowYjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZ Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoJjL4nDMben23Cn1KTo4DfHDtfNZGOWwBW2XI9djn/VuXXO2hj6nX4r4 G1lNwtCpDYn7Lp80dHRFdpn7GnqrfNMHIsKDaRYxpJ0fgi4gE9LdMwnmsEE8WONj7yPVRuI6Xq43 nfO8LTZehHaN+NwUdgh/rXDQLru1AaxYbaJftkpGGwyMDmPwtfgV3TvNf8g50mCTcAripDVm2tzC 4vIOdNCYQJfsRoQggtLwby9nNyxwHKHHh7OlEZPqVJPGn1S1qzFxKjRcLHwzP4vKD6H8nY5ndVk3 4CLZ5jq59kcpoVTDMLySl5PTg6zBuS+1S0nngBAW9FOqUOTBRMyxqHkmgwIDAQABo4ICMzCCAi8w ggGEBgNVHR8EggF7MIIBdzB5oHegdaRzMHExCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBT ZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAK BgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDovL3d3dy5vcmlvbnNlYy5jb20v Q1JML2NhMV9jcmxmaWxlNC5jcmwwgZSggZGggY6GgYtsZGFwOi8vU0JFVEVMR0VVU0UvY249V2lu Q29tYmluZWQ0LG91PUNBMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1PcmlvbiUy MFNlY3VyaXR5JTIwU29sdXRpb25zLGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9CYXNl MC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDArBgNVHRAE JDAigA8yMDA0MDUxNDE5MDMxMlqBDzIwMjQwNTE0MTkzMzEyWjALBgNVHQ8EBAMCAQYwHwYDVR0j BBgwFoAUyLI83rqa64kJoNY0MpsZQobMmNIwHQYDVR0OBBYEFMiyPN66muuJCaDWNDKbGUKGzJjS MAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMDo0LjADAgSQMA0GCSqGSIb3DQEB BQUAA4IBAQA9LSuraaiw3bO+TdsvCuppT4dbud3+lw6LekUzC9uVFzKbVpVUohUezNJ4zz7FbTV3 0zFNBUrjM8twoSJQ+pbAdJRhrva9zztJp+zR1hDiF4xUfQ/VhcW5HQ8AuduMAdDOyDbc2qQFeUwR YfonnJpWZINiCyUavFXKoTKoG6KkaDfrBiKLtOXy6m09Qr1dQ7wGnL8i+iEDGVFiCjlJ1JeP0vDP g+oOwWYTraW69me5EfXXhhvghAbYtkwoEfxS8hAxRfFqh+8LTIf9nL8ug9ImcfQqVZhRBsC8W2+Y TzLrexngHUpedXJuas/XVSW1+COqOt/gU9lWPD+GD+59FYJIMYIC0jCCAs4CAQEwajBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClPlowCQYFKw4DAhoFAKCCAb4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTE2MTgwOTQ0WjAj BgkqhkiG9w0BCQQxFgQUyC9l5zo/5q5+Rbxt8XZswkFORO0wZwYJKoZIhvcNAQkPMVowWDAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUweQYJKwYBBAGCNxAEMWwwajBiMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE7wwewYLKoZIhvcNAQkQAgsxbKBqMGIx CzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUTvDANBgkqhkiG9w0B AQEFAASBgC4UWZMeowEfAdJMM0/+MgKU4GJQwU2oMl1dLPZA43WINVj/jhx+TOlDwQXorRdcmaZg Dib07SIv76xjogH4R07R2B5GfVSaCJ4A60vzMxKzHV9dyS70WNK6su5fVoGF+0URo5wnDuT2//v1 QPRteIYu4PMp71H4iomEYOfA0Uv0AAAAAAAA ------=_NextPart_000_0022_01C678F2.61982EE0-- 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 k4GHvArY020776; Tue, 16 May 2006 10:57: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 k4GHvAdZ020775; Tue, 16 May 2006 10:57: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GHv8Cs020768 for ; Tue, 16 May 2006 10:57:09 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4GHv6L14529; Tue, 16 May 2006 19:57:06 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 16 May 2006 19:57:06 +0200 (MET DST) Message-ID: <446A1212.4050507@edelweb.fr> Date: Tue, 16 May 2006 19:55:30 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Peter Sylvester CC: Julien Stern , ietf-ltans@imc.org Subject: Re: ERS tagging References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> <446603E4.2020707@edelweb.fr> <20060516155620.GA22690@cryptolog.com> <446A0CFE.5050701@edelweb.fr> In-Reply-To: <446A0CFE.5050701@edelweb.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080401040203060103030701" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms080401040203060103030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I meant decoders. I know that many asn.1 tools/parsers/compiler do not check for ambiguous syntaxes, i.e. they don't warn you. I was hit by that several times, that why the DVCS syntax has little bugs. > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm AlgorithmIdentifier OPTIONAL, > reducedHashtree [0] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} When decoding 30 LLLL 30 LLLL probably decoders decide that there is an AlgorithmIdentifier. If you coder ALWAYS sets an algorithmidentifier, then you don't even get an error when decoding with a decoder produced by some tools. But as soon as you only encode the timeStamp ... you may not get an error either, it is just that at best the timeStamp appears as algorithmIdentifier. > ASN.1 parsers are streaming, i.e. are not looking ahead. > Any syntax must be constructed in a such a way that only by looking > at the tag > you know what it means. > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms080401040203060103030701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTE2MTc1NTMwWjAjBgkqhkiG9w0B CQQxFgQUf3L1OKB9/AeJG64arqagY6mcfCIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAXBrZ0xJBjtXXhT1e /HVysk9A6k7OrNzcqsMRjCAhzqN8qvf1/lbrGN66kl0PSnt8QoZpfn6e47Hi4NLZkHDf+KKV Ym2bMiRvTEGGQaYCEU8VFl1/1g9NyvnBmZtlAcVfhu5Qisn9Ia/95E9I+0dNshqd5/DYwHDh CR22DkhfgvgAAAAAAAA= --------------ms080401040203060103030701-- 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 k4GHZjDh016172; Tue, 16 May 2006 10:35:45 -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 k4GHZjjQ016171; Tue, 16 May 2006 10:35:45 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GHZh9K016156 for ; Tue, 16 May 2006 10:35:44 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4GHZQL14260; Tue, 16 May 2006 19:35:26 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 16 May 2006 19:35:26 +0200 (MET DST) Message-ID: <446A0CFE.5050701@edelweb.fr> Date: Tue, 16 May 2006 19:33:50 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Julien Stern , ietf-ltans@imc.org Subject: Re: ERS tagging References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> <446603E4.2020707@edelweb.fr> <20060516155620.GA22690@cryptolog.com> In-Reply-To: <20060516155620.GA22690@cryptolog.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030400080202040007070209" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030400080202040007070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Julien Stern wrote: > Folks, > > I would personally be happy with any syntax. However, I find it > somewhat weird to choose one syntax over an other just because of > bugs in one ASN.1 compiler or an other. > And as far as I was informed one of the compilers seemed to be fixed. > Anyway, to be best of my ASN.1 knowledge, the current syntax is not > ambiguous because the ContentInfo is not optional. Therefore, it is > possible to figure out if we are reading the digestAlgorithm or the > timestamp based on the number of elements in the structure, even when > the reducedHashtree is absent. However, adding a tag on the timestamp > (or on the digestAlgorithm actually) may help some ASN.1 processors, > notably those with streaming capabilities. > > ASN.1 parsers are streaming, i.e. are not looking ahead. Any syntax must be constructed in a such a way that only by looking at the tag you know what it means. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms030400080202040007070209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTE2MTczMzUwWjAjBgkqhkiG9w0B CQQxFgQUkKu1BFWOpmtPSGzTO1uKtIAJkAgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGASEeZeF1Zcujoa8yk 1yn5Ur6Ecp5WIkv1hKncGbxk1sgmjB/eqwgK3h855DFMli65TCKuuBqnhYdiSMxMFDZY3l55 Tn7dtlvkcztyC3FDCwAtSjbe7b08QBJVmX+Dr9yMWT/Ww29kJ9dZzZxKM4e4UIzcIhzXQEk3 DZgwIlKIwPcAAAAAAAA= --------------ms030400080202040007070209-- 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 k4GHNYT4013496; Tue, 16 May 2006 10:23:34 -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 k4GHNYij013494; Tue, 16 May 2006 10:23:34 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GHNUi0013463 for ; Tue, 16 May 2006 10:23:30 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 21999 invoked from network); 16 May 2006 17:27:06 -0000 Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 16 May 2006 17:27:06 -0000 Message-ID: <446A0AB1.3070507@seccommerce.de> Date: Tue, 16 May 2006 19:24:01 +0200 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, Robert Eiglmaier Subject: Re: Why are the hash values sorted? References: <2666EB2A846BAC4BB2D7F593301A7868256647@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868256647@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tobias, thank your for your comments. Some of your concerns are based on a wrong wording I used. I wrote about sorting according to the signature time and what I meant was sorting according to the arrival time in the archive. In some cases the result is the same, but of course the archive system shall not inspect the data to find out the signature time. It shall only conserve the sequence of the documents. If data is written on a WORM information about the sequence in which the documents have been archived will be available after years and the hash tree should provide the same, in oder to provide an evidence of the sequence with an equal quality as the WORM provides. > And I must disagree with your reasons: > 1. you are right, SHA-256 seems pretty secure at the moment (at least > today - let's see what the next Workshops at NIST and > Crypto-conferences > turns up) and other Hash algs are also good for this spec - but the > freedom of reordering all hash-values in the tree is an absolutely > unnecessary security risk and might increase future potential > collision > attacks. For the best security of the system the specification should > be clear and unambiguous as good as possible. I assume that the possibilities to find collisions given by reordering all hash-values are only a subset of the possibilities given by inserting arbitrary hash-values into the tree. The latter cannot be prevented. I'm no cryptographer and cannot prove my assumption. And I don't have to, since collisions are not what an attacker needs here. He needs something much more difficult: a second pre-image for the root hash. Finding collisions means finding any two documents with the same hash and which specific hash it is, doesn't matter. Here, the root hash is fixed. The attacker needs to reorder the hashes or insert hashes in such a way, that the same fixed root hash is the result. If this was possible, then the hash algorithm would be useless and could not be used for digital signatures any longer. So I don't see that the security of the system is influenced by the possibility to reorder the hashes. > 2. The thought of IBM to insist that the order of the tree should > reflect the order in which the documents have been signed is - to say > it blunt - silly. > > A. you can NOT use this ordering as "proof" of order of signing time: > you can never rely on the ordering you receive from ERS-system, so you > could never rely on that it is not otherwise received or ordered. > A-a) any user can send data in any order to the ERS-system. > A-b) to fulfil your idea the ERS system would need to inspect the data > it preserves which can not be possible in all cases (thinking of > formats > the ERS-system does not know, or content that is encrypted) - What > would > you do if this ordering would be in conflict with the times in the > timestamps of the signatures. > A-c) and in case you really would want to do this, you might also have > to certify such a server as trusted and the sorting mechanism > according > to your proposal by a government agency to be able to rely on this > information. You are right, that the ordering information is not proof on the same level as the existence of the hash values is. For certain use cases, however, it suffices to fulfil some requirements - Today a WORM is accepted as an evidence in some important cases. > B. the information about the signing time (and order) should > definitely > be in the signature and NOT be deducted from the order of the tree - > as > you know there is a very good mechanism called timestamp which gives > absolutely clear information about the order of the signing times. That's true only if the time stamp server sets the optional "ordering" field in the time stamp (RFC 3161). Besides a qualified time stamp for each document is expensive, requires a lot of extra space in the data base compared to small hashes and slows down the archiving process significantly. I could collect documents into an ordered tree and get a time stamp only for the root hash, which means nothing else than to use the archive hash tree for this. > C. small remark: your proposal is absolutely NOT required by the > German > ArchiSig project (and as one of the key project members I must know > it). Right. We (SecCommerce) need a solution which fulfils the ArchiSig requirements and gives us the order of the arrival in the archive. The latter is not required by ArchiSig but by some of our customers. > D. to me your proposal looks like a cheap "hack" for a proprietary not > though-out/figured out system - your business goal SHOULD definitely > be > achieved otherwise. This is definitely NOT worth taking any risk (and > be > it even the slightest) of easier collision attacks against the hash > tree in the future. This is your opinion. I commented on the collision risk already. > E. and as a last remark: all my talks with government agencies (and > there were quite some German included) did explicitly NEVER show this > idea or strange requirement. (of course all of them need ERS and > solutions conform to ERS) > > So I strongly recommend that you use a different and more mature > approach for your idea - as Robert already explained there are many > possible approaches not in conflict with ERS and a lot better than > your proposal. I hope I was able to resolve some of your concerns in this mail. Please do not assume that I'm leading this lengthy discussion to annoy you or to invent requirements which are not needed in reality. Kind regards Tilo 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 k4GHNYwn013495; Tue, 16 May 2006 10:23:34 -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 k4GHNYRu013493; Tue, 16 May 2006 10:23:34 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GHNThA013462 for ; Tue, 16 May 2006 10:23:30 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 9830 invoked from network); 16 May 2006 17:27:05 -0000 Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 16 May 2006 17:27:05 -0000 Message-ID: <446A0AAD.6070008@seccommerce.de> Date: Tue, 16 May 2006 19:23:57 +0200 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Eiglmaier CC: ietf-ltans@imc.org Subject: Re: Why are the hash values sorted? References: <2666EB2A846BAC4BB2D7F593301A78680D8D08@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78680D8D08@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Robert, thank you for your comments. > there are some more (technical) reasons for sorting the hashes: > > In an unsorted hashtree searching a certain hash value becomes > slow whereas in a sorted tree you can look it up real quick > with binary search. > Sorting is done only once when creating the tree, searching > is done everytime a document needs to be verified. That's right. But searching something in the tree is a seldom operation. We only need to do it when an algorithm in the original document's signature has expired and still somebody is interested in verifying the signature. Of course that will happen sometimes, but the older a documents gets the less often it will be used. Furthermore the hash tree is the logical structure and there may be a different physical structure in the data base. The data base could create an index which might for example contain a binary sorted tree. > The format of the reduced hashtree would have to be changed > for unsorted hashtrees because for all the middle levels of the > tree only the neighbor hashvalue(s) are given. There is no > information where to put the calculated hashvalue. Left or right > or if the arity > 2 somewhere between the neighbors? > If they are sorted, this is unambiguous. Right. It would be necessary to put each required node completely into the reduced hash tree. If for example a parent node on a middle level has 1000 children, then these 1000 hashes have to be there in the reduced hash tree and not only 999. I do not see a problem in this change. > And finally ArchiSig hashtrees have not been designed to prove > the order in which the documents arrived in an archive. Even if > the hashvalues would represent that order, this would be a hint > but no proof. So we will need a flag which expresses that in this hash tree the order of the hashes represents the order in which the hashes arrived in the archive. By order in the hash tree I mean a depth-first-enumeration of the leafs starting with the left-most leaf. > You might create an additional document with references (hashes) > of your documents and e. g. the current date & time and add it > to the archive before creating the hashtree so that it is > timestamped. We thought about it and it is possible. But it makes the data structure more complicated. Some of our customers need to know the order in which the documents arrived in the archive. The easiest way to achieve this is to maintain the order in the tree. We could do it more complicated with additional documents and time stamps, but why should we? Kind regards Tilo > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tilo Kienitz > Sent: Freitag, 28. April 2006 19:07 > To: Tobias Gondrom > Cc: ietf-ltans@imc.org; Boris Baltzer > Subject: Re: Why are the hash values sorted? > > > > Hello Tobias, > > > We sort the hash values (binary ascending) to reduce the risk of > > collision attacks by resorting the hash values in another combination > > and by this getting another hash value for the parent node. > > I understand these arguments, but they do not convince me. If there > was a realistic risk of collision attacks, a better hash algorithm > should be used to prohibit such an attack. The draft does not demand > a certain hash algorithm and an upgrade would be conformal. I am no > cryptographer and maybe missing something, but it is my understanding > that we do not have to expect collision attacks against for example > SHA-256 within the next years. > If your concern is that of a collision attack, you will also have > to consider the possibility of inserting arbitrary values into the > hash tree in order to perform such an attack. In my perception, > inserting arbitrary values into the hash tree provides possibilities > for collision attacks similar to those of resorting the hashes. In > this respect, sorting the hashes to prevent collisions seems like > installing a bigger lock on the door while the window remains open. > > In short: I think that collision attacks have to be prevented by the > hash algorithm, not by the way the tree is sorted. > > > And as we > > only secure the root hash with the time stamp we think that it is > > mandatory that the mapping/transformation from a given set of hash > > values to the root hash MUST be unambiguous. > > I suggest to compute the parent hash on the hashes below it in the > exact order in which they appear in the ASN.1-sequence. This is > an unambiguous rule. > > > I understand the need for grouping of objects, but the order in the > > hash > > tree is not the right element for the information of the order of the > > documents in an application/document specific context. > > For many of our customers like IBM and major German authorities it > is an important feature to be able to prove the order in which the > documents have been signed. They insist that the hash tree is the > natural place for this proof. It is important for us to have a > solution compatible to the ArchiSig standard and therefore to > LTANS-ERS. Therefore I suggest to make the sorting optional and > insert a flag into the evidence record which shows whether the > values have to be binary sorted before verification or just taken > as they are. > > Kind regards > Tilo > > > -- > Tilo Kienitz > SecCommerce Informationssysteme GmbH > Obenhauptstr. 5 > D - 22335 Hamburg http://www.seccommerce.de > Germany Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GGdDvP003097; Tue, 16 May 2006 09:39:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GGdDtU003096; Tue, 16 May 2006 09:39:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GGdC6R003069 for ; Tue, 16 May 2006 09:39:13 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ERS tagging Date: Tue, 16 May 2006 09:39:06 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87902C6D242@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS tagging thread-index: AcZ5BCzQBxAQR4YBTa+UpSl3g+Y5wgAAjBmw From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GGdD6R003091 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I would personally be happy with any syntax. However, I find > it somewhat weird to choose one syntax over an other just > because of bugs in one ASN.1 compiler or an other. Agree. We didn't have just one instance of the problem though. Several implementations exhibited misbehavior with the original definition. Even if the original definition is syntactically correct, given the relative lack of legacy concerns we ought to try to settle on a definition that's easier to digest. > Is there any other reason than a bug in one compiler to > justify this change though? If we want to clarify the syntax, > it might be preferable to split the SEQUENCE of SEQUENCE, e.g.: > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm AlgorithmIdentifier OPTIONAL, > reducedHashtree [0] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} > > PartialHashtree ::= SEQUENCE OF OCTET STRING The above syntax works for me. 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 k4GFuW2O093602; Tue, 16 May 2006 08:56:32 -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 k4GFuWqN093601; Tue, 16 May 2006 08:56:32 -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 kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GFuUqZ093592 for ; Tue, 16 May 2006 08:56:31 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 6EC1B40F2D for ; Tue, 16 May 2006 17:56:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 0677F4410B for ; Tue, 16 May 2006 17:56:53 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15033-01 for ; Tue, 16 May 2006 17:56:46 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 36FBD44104 for ; Tue, 16 May 2006 17:56:45 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 16 May 2006 17:56:21 +0200 From: "Julien Stern" Date: Tue, 16 May 2006 17:56:21 +0200 To: ietf-ltans@imc.org Subject: Re: ERS tagging Message-ID: <20060516155620.GA22690@cryptolog.com> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> <446603E4.2020707@edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <446603E4.2020707@edelweb.fr> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, I would personally be happy with any syntax. However, I find it somewhat weird to choose one syntax over an other just because of bugs in one ASN.1 compiler or an other. Anyway, to be best of my ASN.1 knowledge, the current syntax is not ambiguous because the ContentInfo is not optional. Therefore, it is possible to figure out if we are reading the digestAlgorithm or the timestamp based on the number of elements in the structure, even when the reducedHashtree is absent. However, adding a tag on the timestamp (or on the digestAlgorithm actually) may help some ASN.1 processors, notably those with streaming capabilities. Regarding the tag on the reducedHashtree, both IMPLICIT and EXPLICIT are fine. Changing for EXPLICIT to IMPLICIT breaks compatibility, but I assume there are not so many implementations already largely deployed. Is there any other reason than a bug in one compiler to justify this change though? If we want to clarify the syntax, it might be preferable to split the SEQUENCE of SEQUENCE, e.g.: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} PartialHashtree ::= SEQUENCE OF OCTET STRING Anyway, any kind of tagging/splitting would be fine by us. These were just my 2 cents... -- Julien On Sat, May 13, 2006 at 06:05:56PM +0200, Peter Sylvester wrote: > Carl Wallace wrote: > >>-----Original Message----- > >>From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > >>Subject: Re: ERS tagging > >> > >>I don't think that Carl's conclusion to add EXPLICIT is the > >>right way to remove the confusion. It changes the encoding. > >>In order to avoid any confusion one can add IMPLICIT. This > >>would be redundant but legal. > >> > > > >Redundantly tagging with IMPLICIT is fine with me. I'll try compiling a > >module with IMPLICIT in the definition instead of EXPLICIT. I'd still > >prefer to see the structures refactored a bit for readability. > > > > > >>In any case the syntax is still ambiguous. > >> > > > >What about the syntax is ambiguous? > > > There was a missing tag at timeStamp. You could not distinguish it from > digestAlgorithm. > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm AlgorithmIdentifier OPTIONAL, > reducedHashtree [0] IMPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING > OPTIONAL, > > timeStamp [1] IMPLICIT ContentInfo} > > > -- > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorité; > die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. > 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 k4FJoA1D026918; Mon, 15 May 2006 12:50: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 k4FJoAT0026917; Mon, 15 May 2006 12:50: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 pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4FJo9lU026886 for ; Mon, 15 May 2006 12:50:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4FJo2XO002320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ffj4s-0007UC-5E; Mon, 15 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-07.txt Message-Id: Date: Mon, 15 May 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-07.txt Pages : 25 Date : 2006-5-15 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-15105055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-15105055.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DG7a33096394; Sat, 13 May 2006 09:07:36 -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 k4DG7aeB096393; Sat, 13 May 2006 09:07:36 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DG7Yb7096379 for ; Sat, 13 May 2006 09:07:35 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4DG7VL02354; Sat, 13 May 2006 18:07:32 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sat, 13 May 2006 18:07:32 +0200 (MET DST) Message-ID: <446603E4.2020707@edelweb.fr> Date: Sat, 13 May 2006 18:05:56 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace CC: ietf-ltans@imc.org Subject: Re: ERS tagging References: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010006020701040407030000" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms010006020701040407030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Carl Wallace wrote: >> -----Original Message----- >> From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] >> Subject: Re: ERS tagging >> >> I don't think that Carl's conclusion to add EXPLICIT is the >> right way to remove the confusion. It changes the encoding. >> In order to avoid any confusion one can add IMPLICIT. This >> would be redundant but legal. >> > > Redundantly tagging with IMPLICIT is fine with me. I'll try compiling a > module with IMPLICIT in the definition instead of EXPLICIT. I'd still > prefer to see the structures refactored a bit for readability. > > >> In any case the syntax is still ambiguous. >> > > What about the syntax is ambiguous? > There was a missing tag at timeStamp. You could not distinguish it from digestAlgorithm. ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] IMPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING OPTIONAL, timeStamp [1] IMPLICIT ContentInfo} -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms010006020701040407030000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMTYwNTU2WjAjBgkqhkiG9w0B CQQxFgQU14K5EXn4XdSM7u6IfVpEXwu1ND8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAMyvahEBWhrNx5w7p eNKB9aD+znH0HXlpwGdgO8ziGSCzcVRHiW717V9hUlYzPD6sIbOGY3sHBWJQ57RCL36PM2N9 aZVbCj277EYc7mfvBHpHUUTATbPZxkAJ+GEwTI/LjvdHK/DBZfKs04Lb6igctp+JNrQbG3GV duOcyzEAIAgAAAAAAAA= --------------ms010006020701040407030000-- 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 k4DFQUsG087425; Sat, 13 May 2006 08:26:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4DFQUbE087424; Sat, 13 May 2006 08:26:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DFQTGp087397 for ; Sat, 13 May 2006 08:26:29 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: ERS tagging Date: Sat, 13 May 2006 08:26:22 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003D_01C67680.0FD9C7E0" Message-ID: <82D5657AE1F54347A734BDD33637C87902B95DB8@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ERS tagging thread-index: AcZ2lRfajpT1cRQrSiaGWQ/FxFPPZgAC24OA From: "Carl Wallace" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C67680.0FD9C7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > Subject: Re: ERS tagging > > I don't think that Carl's conclusion to add EXPLICIT is the > right way to remove the confusion. It changes the encoding. > In order to avoid any confusion one can add IMPLICIT. This > would be redundant but legal. Redundantly tagging with IMPLICIT is fine with me. I'll try compiling a module with IMPLICIT in the definition instead of EXPLICIT. I'd still prefer to see the structures refactored a bit for readability. > In any case the syntax is still ambiguous. What about the syntax is ambiguous? ------=_NextPart_000_003D_01C67680.0FD9C7E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMDCCBEAw ggMooAMCAQICBEClE7wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE0MzA1NVoXDTA3MDUxNzE1MDA1NVowWzELMAkGA1UE BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95 ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALLi +sA/Id5PcQ8uPHjuKlWcxrb8kQkBkJrn4Vv/KNrpZZcIO0mTxp28yVqg3fJRWszamV3cbE77oXV/ 0AFxrRhf89avN0lrUmqSBsf7ph8Zfz8HMbNODQvGOsKCGa4HA1jujeTnIqgrlCyyUORELVu4i2a7 uErbLjIX7SHNxGtlAgMBAAGjggGHMIIBgzALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVY3dhbGxh Y2VAb3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8G A1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cu b3Jpb25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxn ZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY 0jAdBgNVHQ4EFgQUB0yg8DWubbASzzui5JhAF3+oIRYwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAE DDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAYh0dywIAWMho3sca3AwuMZiepipLDF/+ +vrm9Md+P9AfS6pjwRbsBNcS9425jr56ANJXALioZoxDMKlRKXy+Hmj8wXq8nMgPkmfLYhvP+PVn KgOkoQtT3ym7FSCwrDJEvO0azG6uRxhuIevShRsBaxsCCjdnf6xG6OGV0KrniweAsnNoZPdq6bHI 2ZAk8hZNWHWwGmYo1lP9MeZ+5aYvG1T3OoKI7Kyg4SM/OjjqxwuGC1Zoh1nAJHrBuvRxvhrzvf9t 5ff5r7/YEguVTRfnviUhAyB56auTb1+lY+sz+NQB0kBkSXwvq1+R6pJ3eBWH7o9h5QI87j0IbrL/ ZXhj0zCCBG0wggNVoAMCAQICBEClPlowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBB dXRob3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA2MDMxNjExNDI0M1oXDTA5MDMxNjEyMTI0M1ow WzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UE CxMJRW1wbG95ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAJj2L4V9bKgndsWwpRiVZVWHSOz64C51pN3lHqW4Z7JngddkDMJTQgMndKpQnMm+Upmr NwtBn5F27PA7hPppS+eqZrwVQdqDuiSlAzrFYfggzHaiLSDv5XIqraUv7IsPOAPrlyUa63ENwyjj AasbL11IM6vkHEeD1ovImgkuE06PAgMBAAGjggG0MIIBsDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQw IoAPMjAwNjAzMTYxMTQyNDNagQ8yMDA4MDQyMTE2MTI0M1owIAYDVR0RBBkwF4EVY3dhbGxhY2VA b3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8GA1UE ChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhv cml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cub3Jp b25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVz ZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAd BgNVHQ4EFgQU0kRLkKUbCoZeTPUKX2mP3iFf+HQwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAK GwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAfj4SP2DX+0YgInGCzrK6Oom5mXNyKVgjmyiI UnvZ4JN5SbEcuIc81be23CgCKqZtjGgnlk3qyc8Ge2z7tNO1pFJqEuzzB0uLwceQddRszga4r5nz h/sfdFOzM9bMghLItanJonRsrPybZM8zIDH+5MFHir1MUaf6ksItF+e4HUBJkggI2Cq2+YCsB2wx qTLenzpsg6H3bmG9aGUmcdlj8jk7vpJvx3oz7xkMzxtQ+viakqsv7XJZg3mX9aIrWjOsdmUlxo9w DqZvxch8fe8vJXjvtDlTG6iddyyHSrtGQdQbRIa79ZCePExEt93gLMB7t8RixMh4frpitspnFj6i kzCCBXcwggRfoAMCAQICBEClE1EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNV BAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNDE5MDMxMloXDTI0MDUxNDE5MzMxMlowYjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZ Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoJjL4nDMben23Cn1KTo4DfHDtfNZGOWwBW2XI9djn/VuXXO2hj6nX4r4 G1lNwtCpDYn7Lp80dHRFdpn7GnqrfNMHIsKDaRYxpJ0fgi4gE9LdMwnmsEE8WONj7yPVRuI6Xq43 nfO8LTZehHaN+NwUdgh/rXDQLru1AaxYbaJftkpGGwyMDmPwtfgV3TvNf8g50mCTcAripDVm2tzC 4vIOdNCYQJfsRoQggtLwby9nNyxwHKHHh7OlEZPqVJPGn1S1qzFxKjRcLHwzP4vKD6H8nY5ndVk3 4CLZ5jq59kcpoVTDMLySl5PTg6zBuS+1S0nngBAW9FOqUOTBRMyxqHkmgwIDAQABo4ICMzCCAi8w ggGEBgNVHR8EggF7MIIBdzB5oHegdaRzMHExCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBT ZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAK BgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDovL3d3dy5vcmlvbnNlYy5jb20v Q1JML2NhMV9jcmxmaWxlNC5jcmwwgZSggZGggY6GgYtsZGFwOi8vU0JFVEVMR0VVU0UvY249V2lu Q29tYmluZWQ0LG91PUNBMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1PcmlvbiUy MFNlY3VyaXR5JTIwU29sdXRpb25zLGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9CYXNl MC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDArBgNVHRAE JDAigA8yMDA0MDUxNDE5MDMxMlqBDzIwMjQwNTE0MTkzMzEyWjALBgNVHQ8EBAMCAQYwHwYDVR0j BBgwFoAUyLI83rqa64kJoNY0MpsZQobMmNIwHQYDVR0OBBYEFMiyPN66muuJCaDWNDKbGUKGzJjS MAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMDo0LjADAgSQMA0GCSqGSIb3DQEB BQUAA4IBAQA9LSuraaiw3bO+TdsvCuppT4dbud3+lw6LekUzC9uVFzKbVpVUohUezNJ4zz7FbTV3 0zFNBUrjM8twoSJQ+pbAdJRhrva9zztJp+zR1hDiF4xUfQ/VhcW5HQ8AuduMAdDOyDbc2qQFeUwR YfonnJpWZINiCyUavFXKoTKoG6KkaDfrBiKLtOXy6m09Qr1dQ7wGnL8i+iEDGVFiCjlJ1JeP0vDP g+oOwWYTraW69me5EfXXhhvghAbYtkwoEfxS8hAxRfFqh+8LTIf9nL8ug9ImcfQqVZhRBsC8W2+Y TzLrexngHUpedXJuas/XVSW1+COqOt/gU9lWPD+GD+59FYJIMYIC0jCCAs4CAQEwajBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClPlowCQYFKw4DAhoFAKCCAb4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMTUyNjIyWjAj BgkqhkiG9w0BCQQxFgQUuCxKVhlqAPJc7NmQWWh4zbHE2+4wZwYJKoZIhvcNAQkPMVowWDAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUweQYJKwYBBAGCNxAEMWwwajBiMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE7wwewYLKoZIhvcNAQkQAgsxbKBqMGIx CzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUTvDANBgkqhkiG9w0B AQEFAASBgH+0sIVK4gvZbr2vvGR0K9KUx//On6ukz3AlRamUvEx2kAtaZJYfA+VZSoph1MqfYL4y 7ys2OvqZIWdfQHWnKgmLK8MPOdDgBXtnIG0/rS+Sec4JVmWskYUq6H33s350iB9EqceVO+i93+Hw C/Zi5eMBC9wFGPHxwlY7a0aI1BDGAAAAAAAA ------=_NextPart_000_003D_01C67680.0FD9C7E0-- 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 k4DDseOG068062; Sat, 13 May 2006 06:54:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4DDse1U068061; Sat, 13 May 2006 06:54:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4DDscBc068053 for ; Sat, 13 May 2006 06:54:39 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4DDsTL28699; Sat, 13 May 2006 15:54:30 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sat, 13 May 2006 15:54:30 +0200 (MET DST) Message-ID: <4465E4B6.2090900@edelweb.fr> Date: Sat, 13 May 2006 15:52:54 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Carl Wallace CC: Robert Eiglmaier , ietf-ltans@imc.org, Tobias Gondrom , Susanne Okunick , Thomas Kunz Subject: Re: ERS tagging References: <82D5657AE1F54347A734BDD33637C87901DEA560@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87901DEA560@EXVS01.ex.dslextreme.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702000701040401070103" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms040702000701040401070103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I don't think that Carl's conclusion to add EXPLICIT is the right way to remove the confusion. It changes the encoding. In order to avoid any confusion one can add IMPLICIT. This would be redundant but legal. In any case the syntax is still ambiguous. Are there existing data structures that need to be preserved? Carl Wallace wrote: > > >> Does the fact that reducedHashtree appears somewhere in this >> IMPLICIT TAGS block: >> >> DEFINITIONS IMPLICIT TAGS ::= >> BEGIN >> ... >> ArchiveTimeStamp ::= SEQUENCE { >> digestAlgorithm AlgorithmIdentifier, >> reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING >> ... >> END >> >> ... mean that everything has to be tagged IMPLICIT? >> > > When the module defaults to IMPLICIT, everything with a context specific > tag is tagged implicitly with a few exceptions. If the definition > includes an EXPLICIT indication, then the tag is explicitly encoded. If > the type tagged with the context tag is a CHOICE then it is encoded > explicitly. The question here is whether or not there is another rule > that forces the tag to be explcit. We polled the room during the WG > session on Monday and there was agreement that it should be implicitly > encoded. > > >> Then why don't we also make the HashGroup implicitely tagged? >> > > Because it does not feature a context specific tag. > > > >> Conclusion: I still don't know which way is the correct one. >> >> Any hints would be gladly appreciated, especially those >> containing references to official specifications! >> > > I searched through X.690 and found the following snips: > > "30.6 The tagging construction specifies explicit tagging if any of the > following holds: > a) the "Tag EXPLICIT Type" alternative is used; > b) the "Tag Type" alternative is used and the value of "TagDefault" for > the module is either EXPLICIT TAGS > or is empty; > c) the "Tag Type" alternative is used and the value of "TagDefault" for > the module is IMPLICIT TAGS or > AUTOMATIC TAGS, but the type defined by "Type" is an untagged choice > type, an untagged open type, or > an untagged "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, > 8.3). > > The tagging construction specifies implicit tagging otherwise." > > "The only notation in this Recommendation | International Standard which > is an open type notation is the > "ObjectClassFieldType" specified in ITU-T Rec. X.681 | ISO/IEC 8824-2, > clause 14, where the "FieldName" denotes either a type field or a > variable-type value field." > > As I read these, IMPLICIT is correct in this case. Of course, we could > simply put an EXPLICIT on the definition as below and eliminate > potential confusion. (I'd still prefer to see the nested sequences > factored out into types.) > > >> HashGroup ::= SEQUENCE SIZE (1..MAX) OF OCTET STRING >> ReducedHashtree ::= SEQUENCE SIZE (1..MAX) OF HashGroup >> >> ArchiveTimeStamp ::= SEQUENCE { >> digestAlgorithm AlgorithmIdentifier OPTIONAL, >> reducedHashtree [0] EXPLICIT ReducedHashtree OPTIONAL, >> timeStamp ContentInfo} >> > > or > > >> ... >> ArchiveTimeStamp ::= SEQUENCE { >> digestAlgorithm AlgorithmIdentifier, >> reducedHashtree [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET >> > STRING > >> ... >> > > > > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms040702000701040401070103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMTM1MjU0WjAjBgkqhkiG9w0B CQQxFgQUfNb07Ho2U2f+fBcbo/cos3o1UJ8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGApVgc6k6vH/1pC6BR etaLoN4+OdNf8nw1jECc5gadpla8f2BJBsTA57x8Ar+iDAbMmVCLA+hhU6vwcB9VHxRpAlbz 4uq6/XMnm7uUCCiqLu0yuzmbK9/gNef8ESJX2OijB8wxdxV8qqXrDA2WY+m6b+lbsGo1Hcx2 ZT6xrQkeAHkAAAAAAAA= --------------ms040702000701040401070103-- 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 k4D9aXot012637; Sat, 13 May 2006 02:36:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4D9aXNk012636; Sat, 13 May 2006 02:36:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4D9aWsF012629 for ; Sat, 13 May 2006 02:36:33 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4D9aSL25490; Sat, 13 May 2006 11:36:28 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sat, 13 May 2006 11:36:28 +0200 (MET DST) Message-ID: <4465A83D.7090100@edelweb.fr> Date: Sat, 13 May 2006 11:34:53 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 CC: Tobias Gondrom , ietf-ltans@imc.org Subject: Re: WG last call on ERS References: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> <44659FE1.9080401@edelweb.fr> In-Reply-To: <44659FE1.9080401@edelweb.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010601020504070205020006" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms010601020504070205020006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For your info: 1: rfc modules in the ITU database are at http://www.itu.int/ITU-T/asn1/database/ietf/rfc/index.html 2: I chceked the ERS syntax with the online version of asn1c at http://lionet.info I replaced the IMPORTS of the ERS module by the necessary definitions for simplicity. In ers-06 the timeStamp field in the ArchiveTimeStamp needed a tag ERS {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(1) id-mod-ers(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- ContentInfo ::= SEQUENCE { content-type CMS-CONTENT-TYPE.&id({CMSContentTable}), pkcs7-content [0] CMS-CONTENT-TYPE.&Type({CMSContentTable}) } CMS-CONTENT-TYPE ::= TYPE-IDENTIFIER CMSContentTable CMS-CONTENT-TYPE ::= {...} ALGORITHM ::= TYPE-IDENTIFIER AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id({SupportedAlgorithms}), parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL } SupportedAlgorithms ALGORITHM ::= {...} -- LTANS specific idnetifiers id-ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } id-em OBJECT IDENTIFIER ::= { id-ltans 2 } -- ERS encryption methods ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING OPTIONAL, timeStamp [1] ContentInfo} ArchiveTimeStampChain::= SEQUENCE SIZE (1..MAX) OF ArchiveTimeStamp ArchiveTimeStampSequence::= SEQUENCE SIZE (1..MAX) OF ArchiveTimeStampChain EncryptionMethod ::= SEQUENCE { encryptionAlgorithm TYPE-IDENTIFIER.&id({EncryptionMethods}), encryptionParameters TYPE-IDENTIFIER.&Type({EncryptionMethods}{@encryptionAlgorithm}) OPTIONAL } EncryptionMethods TYPE-IDENTIFIER ::= {cms-Encryption ,... -- dynamically extensible information object set --} cms-Encryption TYPE-IDENTIFIER ::= { CMSEncryptionParams IDENTIFIED BY id-em } CMSEncryptionParams ::= SEQUENCE { encryptionCover ContentInfo, publicKey [0] BIT STRING OPTIONAL, params CHOICE { privateKey BIT STRING, encryptionKeyRan EncryptionKeyRandom} } EncryptionKeyRandom::= SEQUENCE { encryptionKey OCTET STRING, randomValue BIT STRING } EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) }, digestAlgorithms SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier, cryptoInfos [0] SEQUENCE SIZE (1..MAX) OF CryptoInfo OPTIONAL, encryption [1] EncryptionMethod OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence} CryptoInfo ::= SEQUENCE { cryptoInfoType TYPE-IDENTIFIER.&id({CryptoInfos}), cryptoInfoValue TYPE-IDENTIFIER.&Type({ECryptoInfos}{@cryptoInfoType}) OPTIONAL } CryptoInfos TYPE-IDENTIFIER ::= {... -- dynamically extensible information object set --} END --------------ms010601020504070205020006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMDkzNDUzWjAjBgkqhkiG9w0B CQQxFgQUdgpbj0LAYwpO4+SkMlnfELW/ajAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAZbevZNt6FWhmVLno 1TsyDiDSM0PxXxWfT/BxA4uIsEYpNARXpVhhj/zfi9uFdk0PH76wevTJLxlFI8FHdO+7EJEC V6OscCjtFKpmKTFeY0wjNjXhtkaXPDZBO8pq84xAtr2PsOTI1otF32x5hAwnDYBrYYmvUueP mY2iGZrsjQsAAAAAAAA= --------------ms010601020504070205020006-- 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 k4D91GJb005104; Sat, 13 May 2006 02:01:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4D91GKp005103; Sat, 13 May 2006 02:01:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4D91Ftt005096 for ; Sat, 13 May 2006 02:01:16 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4D90mL24907; Sat, 13 May 2006 11:00:48 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sat, 13 May 2006 11:00:48 +0200 (MET DST) Message-ID: <44659FE1.9080401@edelweb.fr> Date: Sat, 13 May 2006 10:59:13 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: WG last call on ERS References: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090608070809050405090409" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms090608070809050405090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The ASN.1 syntax of ERS is difficult to treat because of the imports of from modules that contain obsolete syntaxes. AlgorithmIdentifier should not come from an 88 version module but rather from its original AuthenticationFramework AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4} which may be somewhat heavy so one could use PKIX1Explicit93.asn PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} for which in the ITU asn1 data base there is also a small subset calle P1.asn which can be used instead of the real PKIX1Explicit93.asn PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} DEFINITIONS EXPLICIT TAGS ::= BEGIN AID ::= CLASS {&id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX {OID &id [PARMS &Type] } AlgorithmIdentifier ::= SEQUENCE { algorithm AID.&id({SupportedAlgorithms}), parameters AID.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL } Abc ::= INTEGER SupportedAlgorithms AID ::= {rsaPublicKey} rsaPublicKey AID ::= {OID rsaEncryption PARMS NULL } rsaEncryption OBJECT IDENTIFIER ::= {so(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1} END -- PKIX1Explicit93 (RFC 2459:1999) ---- TimeStampToken is imported by not used at all because the field timeStamp uses ContentInfo. So this doesn't need to be imported. ----- ContentInfo: There we have in the ITU database a usable cryptoGraphicSyntax.asn which is identified by CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} which contains a version of the rfc2630 module in non-obsolete syntax. ------ By looking at that module, I think about my previous mail about adding EXPLICIT: I can imagime ASN.1 compilers that have a problem with a glowbal defailt IMPLICIT TAGS. So one might add IMPLICIT at all context tags (as in smime) in handle that. There are other context tags in the syntax. isn't there the same "compatibility problem"? have fun --------------ms090608070809050405090409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMDg1OTEzWjAjBgkqhkiG9w0B CQQxFgQUb38ZdUHEx9TF7HOSqO/ucOW56UcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAuhMVNt4cXHG6/0HU xpYlYS0RFHDwoA4Hp4E76+cYLgALwO6mxVSJEND7y9FQqIQ5T/Fw4kvPsYXdrYRLpuFuY6RP NMarsDgW99shyo7MPcK48cdHmUCUjWNt2IusRcRCLyU72qDfHBgKK6nvRTK+ju4GpFqYxgTi 8wZBS2U+VksAAAAAAAA= --------------ms090608070809050405090409-- 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 k4D8LJj2096403; Sat, 13 May 2006 01:21:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4D8LJ9w096402; Sat, 13 May 2006 01:21:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4D8LIi1096388 for ; Sat, 13 May 2006 01:21:18 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k4D8KeL24408; Sat, 13 May 2006 10:20:41 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sat, 13 May 2006 10:20:41 +0200 (MET DST) Message-ID: <4465967A.7040104@edelweb.fr> Date: Sat, 13 May 2006 10:19:06 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: WG last call on ERS References: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060005040909030505090408" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms060005040909030505090408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I mildly object to this change unless you give better justification. - Compatibility are not relevant. - Which ASN.1 compiler does this kind of error? - What do you mean by 'in the past'. The syntax of the spec is rather recent. regards. Peter Tobias Gondrom wrote: > > Hello all, > > I received the following comments to ERS during the WG last call and > integrated them in a last version 07 of ERS: > > 1. from Carl and others: the request to introduce the “EXPLICIT” tag > to the reduced hashtrees as this had given some trouble with some > compatibility tests and ASN-compilers in the past. > > So change from: > > reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING > > OPTIONAL, > > To: > > reducedHashtree [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING > > OPTIONAL, > > 2. to order the terminology completely alphabetically (putting > “Archive Time-Stamp Chain” and “Archive Time-Stamp Sequence”) right > after “Archive Time-Stamp” of the Terminology chapter. > > 3. from Santosh, Carl and others: chapter 5 about the encryption seems > to provoke some confusion. We don’t have a real implementation with > encrypted content and are not fully sure about it. So we should to > keep the chapter 5 (about special parameters needed for encrypted > content) very short and enable a reference to another RFC to be > defined by the WG for this complex matter. This way ERS can fulfil its > purpose for all electronically designed documents without limiting > potential parameters necessary for encrypted documents. > > I hope that the draft now includes all your comments and is ready for > submission to IESG. > > Tobias > > Ps.: it may take a few hours/one or two days until the IETF will > publish the 07-draft to the list. > > Pss.: I will be on holiday the next three weeks and may not be able to > answer to emails during this time. > > * From: * owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] *On Behalf Of * Tobias Gondrom > *Sent:* Friday, April 21, 2006 10:04 AM > *To:* ietf-ltans@imc.org > *Subject:* WG last call on ERS > > Folks, > > as announced in Dallas , we hereby initiate WG last call for ERS: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > Please provide final comments to the list by May 5^th . > > Thanks, > > Carl & Tobias > > Chairs of LTANS > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms060005040909030505090408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNTEzMDgxOTA2WjAjBgkqhkiG9w0B CQQxFgQU4x0Mw5efpBqgLIfszSBNt5+nW3IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGALmXtv7srClY0oB60 +VtKA+r8SfMaB3QnP0byymEf/3BnxRqZNsBbCO2zfAD0LD1QrxHv9I4wcJnDfYOhI+pTGTuo YgrtdjGStoenfL49YpvAdGsU8dXtG24XkBQjLPKDzXzr4/0TVF6AlGlOeFsfB3AqL7YbUR4z W8FVXevX/SwAAAAAAAA= --------------ms060005040909030505090408-- 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 k4CICkdC020665; Fri, 12 May 2006 11:12:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CICkGm020664; Fri, 12 May 2006 11:12:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CICis4020649 for ; Fri, 12 May 2006 11:12:45 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4CICaLx010340; Fri, 12 May 2006 20:12:38 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG last call on ERS - verification data in local structures Date: Fri, 12 May 2006 20:12:35 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78682C2D35@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on ERS - verification data in local structures Thread-Index: AcZ12VjpxqwTkLRRToqr5vJZ5svZ0gAFZVFA From: "Tobias Gondrom" To: "Julien Stern" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4CICjs4020659 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julien, I agree that the timestamps should include all necessary verification data. This should at least be the complete chain of certificates. And depending on the source of the timestamps also all other data: CRL or OCSP, etc. In the case that the source of the timestamp is an officially certified trust center (e.g. with government guarantees or s.th. like that) it may also be sufficient to only store the complete certificate chain up to the root. (one might assume that a trust center certified and protected by certain guarantees from the government will not loose its own keys without notice by the public. So the CRL/OCSP might not be necessary. Tobias Ps.: will be on holiday the next three weeks and not be able to answer until June 4th. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Julien Stern > Sent: Friday, May 12, 2006 5:25 PM > To: ietf-ltans@imc.org > Subject: Re: WG last call on ERS - verification data in local structures > > > Tobias, > > I concur and think that this should be specified more clearly. It is not > the same to include certificates and CRL/OCSP in the timestamps and in > the CryptoInfos. > > I actually wonder if the security is not entirely at risk if we do not > include ALL verification information in the timestamps themselves. > > As a matter of fact, if, within one timestamp chain, the key of > one authority is compromised (because it was too small, for instance), > we will not have any mean to verify the initial timestamp, because we > will not have any reliable source to obtain the verification/revocation > information at that time. > > Therefore it seems to me that every individual timestamp should contain > absolutely every information (certificate, chain, CRLs, CRL signer > certificate if different, etc) in order to execute the X.509 validation > algorithm at the date specified by the timestamp. > > Or have I missed something? Maybe we trust the autority that performed > (n+1)-th timestamp to have (fully) verified the n-th timestamp at the > time it timestamped it? > > Regards, > > -- > Julien > > On Fri, May 12, 2006 at 03:56:50PM +0200, Tobias Gondrom wrote: > > Hi Carl and Julien, > > > > yes I would strongly recommend to store the information needed for the > > verification of the signatures and timestamps in the specific structures > > themselves. I.e. Certificates and CRL/OCSP responses should be stored in > > the data structures verified by this data. > > (e.g. the timestamps should integrate the certificates of the various > > authorities.) > > > > This way as Carl already explained the information is also protected by > > the ERS data structures and can also be used at later times. > > > > Tobias > > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of Carl Wallace > > > Sent: Thursday, May 04, 2006 3:38 PM > > > To: ietf-ltans@imc.org > > > Subject: RE: WG last call on ERS > > > > > > > > > I agree. I think a section that describes the verification of a > > > timestamp type (e.g., RFC3161) including processing of certs and rev > > > info from the CryptoInfos field and handling of time of interest > > should > > > be added. > > > > > > Similar detail for other timestamp types could be provided in > > subsequent > > > docs, if desired, but at least one should be treated in detail here > > for > > > sake of interoperability. > > > > > > I also have a concern about the placement of the CryptoInfos field in > > > the structure. Currently, it's in the outermost layer. Thus, the > > > contents of the field are not covered by the preservation layers and > > > requires verifiers to sift through and sort out which artifacts apply > > to > > > which timestamp in the EvidenceRecord. CryptoInfos might be better > > > placed in the ArchiveTimestamp structure to support the production of > > > self-contained evidence records (i.e., to avoid the need to access > > other > > > sources when verifying and without losing preservation of the > > artifacts > > > used during verification). The cert and crl bags of the timestamp > > > structure offer another place such materials could be incorporated in > > a > > > way that the artifacts are preserved. However, CMS doesn't provide a > > > place to convey trust anchors. > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > > > > Sent: Wednesday, May 03, 2006 10:45 AM > > > > To: ietf-ltans@imc.org > > > > Subject: Re: WG last call on ERS > > > > > > > > > > > > Folks, > > > > > > > > thanks a lot for the latest draft and your work. > > > > > > > > We have completed our first test implementation of ERS and we > > > > were wondering if the WG planned to add more details about > > > > the "CryptoInfos" > > > > sequence either in ERS (or a future version) or in an other > > > > document of the WG. > > > > > > > > While we understand the intent to leave this field fairly > > > > free for specific needs, we also believe it would be nice to > > > > have a small set of defined OIDs for, say, certificates, > > > > CRLs, OCSP responses, trust anchors... > > > > > > > > Altough this work may be outside the scope of this WG, we > > > > feel that several RFC now use a field morally containing "all > > > > the crypto material needed for verification" without more > > > > specification, which may hinder interoperability. > > > > > > > > If we take the example of revocation information, some people > > > > will want to use, for instance the "CompleteRevocationRefs" > > > > from RFC3126, while some other will choose the "RevInfos" > > > > from SCVP, and some others the "RevocationInfoChoices" from CMS ... > > > > > > > > Regards, > > > > > > > > -- > > > > Julien > > > > > > > > On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: > > > > > Folks, > > > > > > > > > > as announced in Dallas, we hereby initiate WG last call for ERS: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > > > > > > > > > Please provide final comments to the list by May 5th. > > > > > > > > > > Thanks, > > > > > > > > > > Carl & Tobias > > > > > Chairs of LTANS > > > > > > > > > > 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 k4CHxVep018052; Fri, 12 May 2006 10:59:31 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CHxVSO018051; Fri, 12 May 2006 10:59:31 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CHxSFa018034 for ; Fri, 12 May 2006 10:59:29 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4CHxPEc001213 for ; Fri, 12 May 2006 19:59:28 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C675EB.D24023F0" Subject: RE: WG last call on ERS Date: Fri, 12 May 2006 19:45:12 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78682C2D2D@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on ERS Thread-Index: AcZlGjT7hFDWocNiS72VubNcD8NK8gQrxjCA From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C675EB.D24023F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 I received the following comments to ERS during the WG last call and integrated them in a last version 07 of ERS:=20 =20 1. from Carl and others: the request to introduce the "EXPLICIT" tag to the reduced hashtrees as this had given some trouble with some compatibility tests and ASN-compilers in the past. =20 So change from: reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING=20 OPTIONAL, To: reducedHashtree [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING=20 OPTIONAL, =20 2. to order the terminology completely alphabetically (putting "Archive Time-Stamp Chain" and "Archive Time-Stamp Sequence") right after "Archive Time-Stamp" of the Terminology chapter. =20 =20 3. from Santosh, Carl and others: chapter 5 about the encryption seems to provoke some confusion. We don't have a real implementation with encrypted content and are not fully sure about it. So we should to keep the chapter 5 (about special parameters needed for encrypted content) very short and enable a reference to another RFC to be defined by the WG for this complex matter. This way ERS can fulfil its purpose for all electronically designed documents without limiting potential parameters necessary for encrypted documents. =20 I hope that the draft now includes all your comments and is ready for submission to IESG. =20 =20 Tobias =20 Ps.: it may take a few hours/one or two days until the IETF will publish the 07-draft to the list. Pss.: I will be on holiday the next three weeks and may not be able to answer to emails during this time. =20 =20 =20 =20 =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Friday, April 21, 2006 10:04 AM To: ietf-ltans@imc.org Subject: WG last call on ERS =20 Folks, as announced in Dallas, we hereby initiate WG last call for ERS: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt =20 Please provide final comments to the list by May 5th.=20 Thanks,=20 Carl & Tobias Chairs of LTANS ------_=_NextPart_001_01C675EB.D24023F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG last call on ERS

Hello = all,

 

I received the = following comments to ERS during the WG last call and integrated them in a last version 07 = of ERS:

 =

1.       from Carl and others: the request to introduce the = “EXPLICIT” tag to the reduced hashtrees as this had given some trouble with some compatibility tests and ASN-compilers in the = past.

 =

So change = from:

reducedHashtree   [0] SEQUENCE OF SEQUENCE OF OCTET STRING

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      OPTIONAL,

To:

reducedHashtree   [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING =

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      OPTIONAL,

 =

2. to order the = terminology completely alphabetically (putting “Archive Time-Stamp = Chain” and “Archive Time-Stamp Sequence”) right after “Archive Time-Stamp” = of the Terminology chapter.

 =

 =

3. from Santosh, = Carl and others: chapter 5 about the encryption seems to provoke some confusion. = We don’t have a real implementation with encrypted content and are not fully sure = about it. So we should to keep the chapter 5 (about special parameters needed = for encrypted content) very short and enable a reference to another RFC to = be defined by the WG for this complex matter. This way ERS can fulfil its = purpose for all electronically designed documents without limiting potential = parameters necessary for encrypted documents.

 =

I hope that the = draft now includes all your comments and is ready for submission to = IESG.

 =

 =

Tobias=

 =

Ps.: it may take = a few hours/one or two days until the IETF will publish the 07-draft to the = list.

Pss.: I will be = on holiday the next three weeks and may not be able to answer to emails = during this time.

 =

 =

 =

 =

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Tobias Gondrom
Sent: Friday, April 21, = 2006 10:04 AM
To: = ietf-ltans@imc.org
Subject: WG last call on = ERS

 

Folks,

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

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

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

Thanks,

Carl & Tobias

Chairs of LTANS

------_=_NextPart_001_01C675EB.D24023F0-- 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 k4CFPBRK087516; Fri, 12 May 2006 08:25: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 k4CFPBVF087515; Fri, 12 May 2006 08:25: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 kraid.nerim.net (smtp-105-friday.nerim.net [62.4.16.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFP9bT087508 for ; Fri, 12 May 2006 08:25:10 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 791CA40ED9 for ; Fri, 12 May 2006 17:25:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id C5F6E4410B for ; Fri, 12 May 2006 17:25:29 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16904-01 for ; Fri, 12 May 2006 17:25:22 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 7897F440ED for ; Fri, 12 May 2006 17:25:21 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Fri, 12 May 2006 17:24:59 +0200 From: "Julien Stern" Date: Fri, 12 May 2006 17:24:59 +0200 To: ietf-ltans@imc.org Subject: Re: WG last call on ERS - verification data in local structures Message-ID: <20060512152458.GC12548@cryptolog.com> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <2666EB2A846BAC4BB2D7F593301A78682C2CEE@MUCXGC2.opentext.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78682C2CEE@MUCXGC2.opentext.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, I concur and think that this should be specified more clearly. It is not the same to include certificates and CRL/OCSP in the timestamps and in the CryptoInfos. I actually wonder if the security is not entirely at risk if we do not include ALL verification information in the timestamps themselves. As a matter of fact, if, within one timestamp chain, the key of one authority is compromised (because it was too small, for instance), we will not have any mean to verify the initial timestamp, because we will not have any reliable source to obtain the verification/revocation information at that time. Therefore it seems to me that every individual timestamp should contain absolutely every information (certificate, chain, CRLs, CRL signer certificate if different, etc) in order to execute the X.509 validation algorithm at the date specified by the timestamp. Or have I missed something? Maybe we trust the autority that performed (n+1)-th timestamp to have (fully) verified the n-th timestamp at the time it timestamped it? Regards, -- Julien On Fri, May 12, 2006 at 03:56:50PM +0200, Tobias Gondrom wrote: > Hi Carl and Julien, > > yes I would strongly recommend to store the information needed for the > verification of the signatures and timestamps in the specific structures > themselves. I.e. Certificates and CRL/OCSP responses should be stored in > the data structures verified by this data. > (e.g. the timestamps should integrate the certificates of the various > authorities.) > > This way as Carl already explained the information is also protected by > the ERS data structures and can also be used at later times. > > Tobias > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Carl Wallace > > Sent: Thursday, May 04, 2006 3:38 PM > > To: ietf-ltans@imc.org > > Subject: RE: WG last call on ERS > > > > > > I agree. I think a section that describes the verification of a > > timestamp type (e.g., RFC3161) including processing of certs and rev > > info from the CryptoInfos field and handling of time of interest > should > > be added. > > > > Similar detail for other timestamp types could be provided in > subsequent > > docs, if desired, but at least one should be treated in detail here > for > > sake of interoperability. > > > > I also have a concern about the placement of the CryptoInfos field in > > the structure. Currently, it's in the outermost layer. Thus, the > > contents of the field are not covered by the preservation layers and > > requires verifiers to sift through and sort out which artifacts apply > to > > which timestamp in the EvidenceRecord. CryptoInfos might be better > > placed in the ArchiveTimestamp structure to support the production of > > self-contained evidence records (i.e., to avoid the need to access > other > > sources when verifying and without losing preservation of the > artifacts > > used during verification). The cert and crl bags of the timestamp > > structure offer another place such materials could be incorporated in > a > > way that the artifacts are preserved. However, CMS doesn't provide a > > place to convey trust anchors. > > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > > > Sent: Wednesday, May 03, 2006 10:45 AM > > > To: ietf-ltans@imc.org > > > Subject: Re: WG last call on ERS > > > > > > > > > Folks, > > > > > > thanks a lot for the latest draft and your work. > > > > > > We have completed our first test implementation of ERS and we > > > were wondering if the WG planned to add more details about > > > the "CryptoInfos" > > > sequence either in ERS (or a future version) or in an other > > > document of the WG. > > > > > > While we understand the intent to leave this field fairly > > > free for specific needs, we also believe it would be nice to > > > have a small set of defined OIDs for, say, certificates, > > > CRLs, OCSP responses, trust anchors... > > > > > > Altough this work may be outside the scope of this WG, we > > > feel that several RFC now use a field morally containing "all > > > the crypto material needed for verification" without more > > > specification, which may hinder interoperability. > > > > > > If we take the example of revocation information, some people > > > will want to use, for instance the "CompleteRevocationRefs" > > > from RFC3126, while some other will choose the "RevInfos" > > > from SCVP, and some others the "RevocationInfoChoices" from CMS ... > > > > > > Regards, > > > > > > -- > > > Julien > > > > > > On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: > > > > Folks, > > > > > > > > as announced in Dallas, we hereby initiate WG last call for ERS: > > > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > > > > > > > Please provide final comments to the list by May 5th. > > > > > > > > Thanks, > > > > > > > > Carl & Tobias > > > > Chairs of LTANS > > > > > > > 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 k4CFICld087046; Fri, 12 May 2006 08:18: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 k4CFICBV087045; Fri, 12 May 2006 08:18:12 -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 EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFIBna087039 for ; Fri, 12 May 2006 08:18:11 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Timestamp renewals Date: Fri, 12 May 2006 08:18:00 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87902B95329@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timestamp renewals thread-index: AcZ1CeEKM8cdNHVaQZa77spG8ziSbgAyqMSAAACBfIA= From: "Carl Wallace" To: "Tobias Gondrom" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4CFIBna087040 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Provided the hash tree renewal is prepared before the hash algorithm is broken, there shouldn't be a problem with relying on the hash of the last timestamp. If the hash alg is broken at the time hash tree renewal is performed, then you have a invalid chain anyway (assuming algorithm validity periods are checked during verification). Renewal must be performed while the outgoing algorithm is still viable. > -----Original Message----- > From: Tobias Gondrom [mailto:tgondrom@opentext.com] > Sent: Friday, May 12, 2006 11:05 AM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: RE: Timestamp renewals > Importance: Low > > Carl, > > This was a problem Uli, Ralf and I discussed for several days > when we thought about the best implementation and what > information is necessary to be able to provide a "proof". > Problem with only hashing in the last timestamp from the > previous chain, is that unfortunately this value does not > securely protect the complete chain anymore after the hash > alg has been broken (which is the precondition of the > hashtree renewal) > > After a hash algorithm has been broken an attacker might be > able to construct any hashtree with a top node matching the > one in the timestamp. So the only way to build a 100% > airtight proof is that you MUST hash both information with > the new hash-algorithm: the document and all data you > collected so far (meaning the reducedHashtree and not only > the last timestamp). > > Tobias > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Carl Wallace > > Sent: Thursday, May 11, 2006 4:48 PM > > To: ietf-ltans@imc.org > > Subject: Timestamp renewals > > > > > > Hash tree renewal is described in section 4.2 and includes the > following > > statement: > > > > 3. atsc(i) is the encoded ArchiveTimeStampSequence, the > > concatenation of all previous Archive Time-Stamp Chains (in > > chronological order) related to data object d(i). > > Generate hash value ha(i) = H(atsc(i)). > > Note: The ArchiveTimeStampChains used are DER encoded, i.e. > they > > contain sequence and length tags. > > > > Is it desirable for the reducedHashtree field to be a > factor in this > > renewal operation? Including it requires the generator to > prepare the > > sequence of chains for each reduced hash tree. Why not > factor in the > > last timestamp from the previous chain plus a new set of > data object > > hashes instead? > > > > For timestamp renewal, the new timestamp is generated for a hash of > the > > timestamp field of its predecessor, and thus does not factor in the > > reducedHashtree field. For timestamp renewal, it seems like the > > reducedHashtree field should be absent (i.e., the reducedHashtree > field > > should only be populated in the first element of an > > ArchiveTimeStampChain). However, section 4.1 states that > "within an > > ArchiveTimeStampChain all reducedHashtrees of the contained > > ArchiveTimeStamps MUST use the same Hash-Algorithm." In an > > ArchiveTimeStampChain, why would any elements other than the first > > element include a reducedHashtree? Is it really necessary > to support > > aggregation at each renewal point? Aggregation for the first > timestamp > > in each chain seems good enough. > > 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 k4CFBOXc086761; Fri, 12 May 2006 08:11:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CFBOq4086760; Fri, 12 May 2006 08:11:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CFBMpA086749 for ; Fri, 12 May 2006 08:11:22 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4CFBJRs028836; Fri, 12 May 2006 17:11:21 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Timestamp renewals Date: Fri, 12 May 2006 17:04:48 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78682C2D0B@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timestamp renewals Thread-Index: AcZ1CeEKM8cdNHVaQZa77spG8ziSbgAyqMSA X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Carl Wallace" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4CFBNpA086754 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, This was a problem Uli, Ralf and I discussed for several days when we thought about the best implementation and what information is necessary to be able to provide a "proof". Problem with only hashing in the last timestamp from the previous chain, is that unfortunately this value does not securely protect the complete chain anymore after the hash alg has been broken (which is the precondition of the hashtree renewal) After a hash algorithm has been broken an attacker might be able to construct any hashtree with a top node matching the one in the timestamp. So the only way to build a 100% airtight proof is that you MUST hash both information with the new hash-algorithm: the document and all data you collected so far (meaning the reducedHashtree and not only the last timestamp). Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Carl Wallace > Sent: Thursday, May 11, 2006 4:48 PM > To: ietf-ltans@imc.org > Subject: Timestamp renewals > > > Hash tree renewal is described in section 4.2 and includes the following > statement: > > 3. atsc(i) is the encoded ArchiveTimeStampSequence, the > concatenation of all previous Archive Time-Stamp Chains (in > chronological order) related to data object d(i). > Generate hash value ha(i) = H(atsc(i)). > Note: The ArchiveTimeStampChains used are DER encoded, i.e. they > contain sequence and length tags. > > Is it desirable for the reducedHashtree field to be a factor in this > renewal operation? Including it requires the generator to prepare the > sequence of chains for each reduced hash tree. Why not factor in the > last timestamp from the previous chain plus a new set of data object > hashes instead? > > For timestamp renewal, the new timestamp is generated for a hash of the > timestamp field of its predecessor, and thus does not factor in the > reducedHashtree field. For timestamp renewal, it seems like the > reducedHashtree field should be absent (i.e., the reducedHashtree field > should only be populated in the first element of an > ArchiveTimeStampChain). However, section 4.1 states that "within an > ArchiveTimeStampChain all reducedHashtrees of the contained > ArchiveTimeStamps MUST use the same Hash-Algorithm." In an > ArchiveTimeStampChain, why would any elements other than the first > element include a reducedHashtree? Is it really necessary to support > aggregation at each renewal point? Aggregation for the first timestamp > in each chain seems good enough. 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 k4CDuuHI084206; Fri, 12 May 2006 06:56:56 -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 k4CDuuwD084205; Fri, 12 May 2006 06:56:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDusCD084199 for ; Fri, 12 May 2006 06:56:55 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4CDuji7026784; Fri, 12 May 2006 15:56:52 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG last call on ERS - verification data in local structures Date: Fri, 12 May 2006 15:56:50 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78682C2CEE@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on ERS - verification data in local structures Thread-Index: AcZuwnIcqI/Mpq9yRd+BB2sC6e09FwAsy+AAAZVxTFA= X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Carl Wallace" , "Julien Stern" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4CDutCD084200 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Carl and Julien, yes I would strongly recommend to store the information needed for the verification of the signatures and timestamps in the specific structures themselves. I.e. Certificates and CRL/OCSP responses should be stored in the data structures verified by this data. (e.g. the timestamps should integrate the certificates of the various authorities.) This way as Carl already explained the information is also protected by the ERS data structures and can also be used at later times. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Carl Wallace > Sent: Thursday, May 04, 2006 3:38 PM > To: ietf-ltans@imc.org > Subject: RE: WG last call on ERS > > > I agree. I think a section that describes the verification of a > timestamp type (e.g., RFC3161) including processing of certs and rev > info from the CryptoInfos field and handling of time of interest should > be added. > > Similar detail for other timestamp types could be provided in subsequent > docs, if desired, but at least one should be treated in detail here for > sake of interoperability. > > I also have a concern about the placement of the CryptoInfos field in > the structure. Currently, it's in the outermost layer. Thus, the > contents of the field are not covered by the preservation layers and > requires verifiers to sift through and sort out which artifacts apply to > which timestamp in the EvidenceRecord. CryptoInfos might be better > placed in the ArchiveTimestamp structure to support the production of > self-contained evidence records (i.e., to avoid the need to access other > sources when verifying and without losing preservation of the artifacts > used during verification). The cert and crl bags of the timestamp > structure offer another place such materials could be incorporated in a > way that the artifacts are preserved. However, CMS doesn't provide a > place to convey trust anchors. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > > Sent: Wednesday, May 03, 2006 10:45 AM > > To: ietf-ltans@imc.org > > Subject: Re: WG last call on ERS > > > > > > Folks, > > > > thanks a lot for the latest draft and your work. > > > > We have completed our first test implementation of ERS and we > > were wondering if the WG planned to add more details about > > the "CryptoInfos" > > sequence either in ERS (or a future version) or in an other > > document of the WG. > > > > While we understand the intent to leave this field fairly > > free for specific needs, we also believe it would be nice to > > have a small set of defined OIDs for, say, certificates, > > CRLs, OCSP responses, trust anchors... > > > > Altough this work may be outside the scope of this WG, we > > feel that several RFC now use a field morally containing "all > > the crypto material needed for verification" without more > > specification, which may hinder interoperability. > > > > If we take the example of revocation information, some people > > will want to use, for instance the "CompleteRevocationRefs" > > from RFC3126, while some other will choose the "RevInfos" > > from SCVP, and some others the "RevocationInfoChoices" from CMS ... > > > > Regards, > > > > -- > > Julien > > > > On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: > > > Folks, > > > > > > as announced in Dallas, we hereby initiate WG last call for ERS: > > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > > > > > Please provide final comments to the list by May 5th. > > > > > > Thanks, > > > > > > Carl & Tobias > > > Chairs of LTANS > > > > 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 k4CDg4sE083467; Fri, 12 May 2006 06:42:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4CDg4W8083466; Fri, 12 May 2006 06:42:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4CDg00S083457 for ; Fri, 12 May 2006 06:42:01 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k4CDfUO9026389; Fri, 12 May 2006 15:41:55 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C675C8.E50C0766" Subject: RE: WG Last Call: draft-ietf-ltans-reqs-06.txt Date: Fri, 12 May 2006 15:35:11 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78682C2CCE@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ltans-reqs-06.txt Thread-Index: AcZqokiF2onhi8+MRDCGBKaEIaY5FwLJQOpQ X-Priority: 1 Importance: high From: "Tobias Gondrom" To: Cc: "Carl Wallace" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C675C8.E50C0766 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Ok. I hereby declare the WG last call for the ltans-reqs to be closed. =20 After the long years of discussion and work at this document we received = one more comment during this WG last call for = draft-ietf-ltans-reqs-06.txt. =20 Carl, as one of the editors: please make the minor editorial change = requested by Larry and initiate the next Last call step on reqs with the = IESG. (I would prefer to keep the Appendix B as it does not hurt, but have no = strong opinion on that.) =20 Note: draft-ietf-ltans-reqs will be submitted to the IESG as = "INFORMATIONAL". =20 Best regards and thanks a lot to all of you,=20 =20 Tobias Chair of LTANS =20 =20 =20 Comment from Larry: "Minor editorial comments: =20 Typo: "A long-term archive service provides a evidence that may be used to" =20 "provides a evidence" =3D> "provides evidence" =20 =20 The next to last paragraph of section 6 (Security Considerations): =20 Additional mechanisms, applications or tools may be needed to preserve the value of evidence records associated with original archived data object. Other specifications of LTANS, in particular certification services will address these problems. =20 =20 but "LTANS" isn't defined in this document. I suggest just deleting the = "Other specifications..." sentence, since it's not needed. =20 I wonder about Appendix B, because it isn't referenced in the text and = doesn't seem directly related to the topic of the document. The simplest = edit would be just to remove it. Otherwise, you should explain how it = relates to the main document. =20 Larry" =20 =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Friday, April 28, 2006 11:01 AM To: ietf-ltans@imc.org Cc: Carl Wallace Subject: WG Last Call: draft-ietf-ltans-reqs-06.txt=20 =20 Hey folks, As we had very little further comments on this one, Carl and I think = that the discussion can be concluded and that it is also ready for WG = Last Call: WG last call for the "Long-Term Archive Service Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-06.txt = =20 (note: this I-D will be submitted as "Informational".) Please provide final comments to the list by May 9th.=20 Thanks,=20 Carl & Tobias Chairs of LTANS =20 __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com = =20 Internet: http://www.opentext.com/ =20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C675C8.E50C0766 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG Last Call: draft-ietf-ltans-reqs-06.txt

Hello,

 

Ok. I hereby = declare the WG last call for the ltans-reqs to be = closed.

 =

After the long = years of discussion and work at this document we received one more comment during this WG = last call for draft-ietf-ltans-reqs-06.txt.

 =

Carl, as one of = the editors: please make the minor editorial change requested by Larry and initiate = the next Last call step on reqs with the IESG.

(I would prefer = to keep the Appendix B as it does not hurt, but have no strong opinion on = that.)

 =

= Note: draft-ietf-ltans-reqs will be submitted to the IESG as = “INFORMATIONAL”.

 =

Best regards and = thanks a lot to all of you,

 =

Tobias=

Chair of = LTANS

 =

 =

 =

Comment from = Larry:

“Minor = editorial comments:

 

Typo:

=A0=A0 = "A long-term archive service provides a evidence that may be used = to"

 

"provides a evidence" =3D> "provides = evidence"

 

 

The = next to last paragraph of section 6 (Security = Considerations):

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Additional mechanisms, applications or tools may = be

=A0=A0 = needed to preserve the value of evidence records associated = with

=A0=A0 = original archived data object.=A0=A0 Other specifications of LTANS, = in

=A0=A0 = particular certification services will address these = problems.

 

 

but "LTANS" isn't defined in this document. I suggest just = deleting the "Other specifications..." sentence, since it's not = needed.

 

I = wonder about Appendix B, because it isn't referenced in the text and doesn't seem = directly related to the topic of the document. The simplest edit would be just to = remove it. Otherwise, you should explain how it relates to the main = document.

 

Larry”

 =

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Tobias Gondrom
Sent: Friday, April 28, = 2006 11:01 AM
To: = ietf-ltans@imc.org
Cc: Carl Wallace
Subject: WG Last Call: draft-ietf-ltans-reqs-06.txt

 

Hey folks,

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

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

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

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

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

Thanks,

Carl & Tobias

Chairs of LTANS

 

______________________________= ____________
Tobias Gondrom
Senior Security Architect
Head of Open Text Security Team

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

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

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

------_=_NextPart_001_01C675C8.E50C0766-- 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 k4BElxZb027006; Thu, 11 May 2006 07:47:59 -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 k4BElxfv027005; Thu, 11 May 2006 07:47:59 -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 EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4BElwDM026997 for ; Thu, 11 May 2006 07:47:58 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Timestamp renewals Date: Thu, 11 May 2006 07:47:51 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87902B4B08D@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timestamp renewals thread-index: AcZ1CeEKM8cdNHVaQZa77spG8ziSbg== From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4BElwDM026999 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hash tree renewal is described in section 4.2 and includes the following statement: 3. atsc(i) is the encoded ArchiveTimeStampSequence, the concatenation of all previous Archive Time-Stamp Chains (in chronological order) related to data object d(i). Generate hash value ha(i) = H(atsc(i)). Note: The ArchiveTimeStampChains used are DER encoded, i.e. they contain sequence and length tags. Is it desirable for the reducedHashtree field to be a factor in this renewal operation? Including it requires the generator to prepare the sequence of chains for each reduced hash tree. Why not factor in the last timestamp from the previous chain plus a new set of data object hashes instead? For timestamp renewal, the new timestamp is generated for a hash of the timestamp field of its predecessor, and thus does not factor in the reducedHashtree field. For timestamp renewal, it seems like the reducedHashtree field should be absent (i.e., the reducedHashtree field should only be populated in the first element of an ArchiveTimeStampChain). However, section 4.1 states that "within an ArchiveTimeStampChain all reducedHashtrees of the contained ArchiveTimeStamps MUST use the same Hash-Algorithm." In an ArchiveTimeStampChain, why would any elements other than the first element include a reducedHashtree? Is it really necessary to support aggregation at each renewal point? Aggregation for the first timestamp in each chain seems good enough. 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 k48GImjb052030; Mon, 8 May 2006 09:18:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48GImOd052029; Mon, 8 May 2006 09:18:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48GImbt052022 for ; Mon, 8 May 2006 09:18:48 -0700 (MST) (envelope-from cwallace@orionsec.com) Received: from f2265248 ([204.249.77.1]) by host15.websitesource.com (8.13.6/8.12.10) with ESMTP id k48GIlnP003524; Mon, 8 May 2006 12:18:47 -0400 Message-ID: <000501c672bb$15b5bac0$75f111ac@ic.fbi.gov> From: "Carl Wallace" To: "Young H. Etheridge" Cc: References: <82D5657AE1F54347A734BDD33637C8790298E805@EXVS01.ex.dslextreme.net> <445F67C7.5020307@yhetheridge.org> Subject: Re: WG last call on ERS Date: Mon, 8 May 2006 12:18:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't see it as a problem related to the cost of the other specs but a gap unique to this application of what the other specs describe. The timestamp specs describe the verification of a timestamp relative to the current time. These descriptions do not adequately capture the verification of nested timestamps. For example, when verifying an evidence record, the outer layer will be verified more or less as described in the existing timestamp specs, but the interior layers may require usage of trust anchors, certificates and revocation data that are not current. How this data is processed should be specified in this document for at least one timestamp type to ensure interoperability. The old TAP I-D specified how data preserved by one layer could be used to verify the adjacent interior layer and ultimately the original signed data. Something along these lines is what I had in mind. ----- Original Message ----- From: "Young H. Etheridge" To: "Carl Wallace" Cc: Sent: Monday, May 08, 2006 11:46 AM Subject: Re: WG last call on ERS > Since descriptions of the verification processes already exist in other > standards documents, e.g. ANSI X9.95 and ISO 18014-[1-3], would reference > to specific document sections be adequate? Or, would WG members prefer > to have these sections rewritten since the referenced documents generally > must be bought? > > Carl Wallace wrote, On 05/04/2006 09:38 AM: >> I agree. I think a section that describes the verification of a >> timestamp type (e.g., RFC3161) including processing of certs and rev >> info from the CryptoInfos field and handling of time of interest should >> be added. >> Similar detail for other timestamp types could be provided in subsequent >> docs, if desired, but at least one should be treated in detail here for >> sake of interoperability. >> >> I also have a concern about the placement of the CryptoInfos field in >> the structure. Currently, it's in the outermost layer. Thus, the >> contents of the field are not covered by the preservation layers and >> requires verifiers to sift through and sort out which artifacts apply to >> which timestamp in the EvidenceRecord. CryptoInfos might be better >> placed in the ArchiveTimestamp structure to support the production of >> self-contained evidence records (i.e., to avoid the need to access other >> sources when verifying and without losing preservation of the artifacts >> used during verification). The cert and crl bags of the timestamp >> structure offer another place such materials could be incorporated in a >> way that the artifacts are preserved. However, CMS doesn't provide a >> place to convey trust anchors. >> >> >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern >>> Sent: Wednesday, May 03, 2006 10:45 AM >>> To: ietf-ltans@imc.org >>> Subject: Re: WG last call on ERS >>> >>> >>> Folks, >>> >>> thanks a lot for the latest draft and your work. >>> >>> We have completed our first test implementation of ERS and we were >>> wondering if the WG planned to add more details about the "CryptoInfos" >>> sequence either in ERS (or a future version) or in an other document of >>> the WG. >>> >>> While we understand the intent to leave this field fairly free for >>> specific needs, we also believe it would be nice to have a small set of >>> defined OIDs for, say, certificates, CRLs, OCSP responses, trust >>> anchors... >>> >>> Altough this work may be outside the scope of this WG, we feel that >>> several RFC now use a field morally containing "all the crypto material >>> needed for verification" without more specification, which may hinder >>> interoperability. >>> >>> If we take the example of revocation information, some people will want >>> to use, for instance the "CompleteRevocationRefs" from RFC3126, while >>> some other will choose the "RevInfos" from SCVP, and some others the >>> "RevocationInfoChoices" from CMS ... >>> >>> Regards, >>> >>> -- >>> Julien >>> >>> On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: >>> >>>> Folks, >>>> >>>> as announced in Dallas, we hereby initiate WG last call for ERS: >>>> http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt >>>> >>>> Please provide final comments to the list by May 5th. >>>> Thanks, >>>> >>>> Carl & Tobias >>>> Chairs of LTANS >>>> >>> >> >> > > 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 k48FkPBM050701; Mon, 8 May 2006 08:46:25 -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 k48FkP8u050700; Mon, 8 May 2006 08:46:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48FkOJY050694 for ; Mon, 8 May 2006 08:46:24 -0700 (MST) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.11] (moors.yandk.org [192.168.1.11]) by burrens.yandk.org (Postfix) with ESMTP id 5FA5D11E33; Mon, 8 May 2006 11:46:15 -0400 (EDT) Message-ID: <445F67C7.5020307@yhetheridge.org> Date: Mon, 08 May 2006 11:46:15 -0400 From: "Young H. Etheridge" User-Agent: Thunderbird 1.5.0.2 (X11/20060308) MIME-Version: 1.0 To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: WG last call on ERS References: <82D5657AE1F54347A734BDD33637C8790298E805@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C8790298E805@EXVS01.ex.dslextreme.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Since descriptions of the verification processes already exist in other standards documents, e.g. ANSI X9.95 and ISO 18014-[1-3], would reference to specific document sections be adequate? Or, would WG members prefer to have these sections rewritten since the referenced documents generally must be bought? Carl Wallace wrote, On 05/04/2006 09:38 AM: > I agree. I think a section that describes the verification of a > timestamp type (e.g., RFC3161) including processing of certs and rev > info from the CryptoInfos field and handling of time of interest should > be added. > > Similar detail for other timestamp types could be provided in subsequent > docs, if desired, but at least one should be treated in detail here for > sake of interoperability. > > I also have a concern about the placement of the CryptoInfos field in > the structure. Currently, it's in the outermost layer. Thus, the > contents of the field are not covered by the preservation layers and > requires verifiers to sift through and sort out which artifacts apply to > which timestamp in the EvidenceRecord. CryptoInfos might be better > placed in the ArchiveTimestamp structure to support the production of > self-contained evidence records (i.e., to avoid the need to access other > sources when verifying and without losing preservation of the artifacts > used during verification). The cert and crl bags of the timestamp > structure offer another place such materials could be incorporated in a > way that the artifacts are preserved. However, CMS doesn't provide a > place to convey trust anchors. > > > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern >> Sent: Wednesday, May 03, 2006 10:45 AM >> To: ietf-ltans@imc.org >> Subject: Re: WG last call on ERS >> >> >> Folks, >> >> thanks a lot for the latest draft and your work. >> >> We have completed our first test implementation of ERS and we >> were wondering if the WG planned to add more details about >> the "CryptoInfos" >> sequence either in ERS (or a future version) or in an other >> document of the WG. >> >> While we understand the intent to leave this field fairly >> free for specific needs, we also believe it would be nice to >> have a small set of defined OIDs for, say, certificates, >> CRLs, OCSP responses, trust anchors... >> >> Altough this work may be outside the scope of this WG, we >> feel that several RFC now use a field morally containing "all >> the crypto material needed for verification" without more >> specification, which may hinder interoperability. >> >> If we take the example of revocation information, some people >> will want to use, for instance the "CompleteRevocationRefs" >> from RFC3126, while some other will choose the "RevInfos" >> from SCVP, and some others the "RevocationInfoChoices" from CMS ... >> >> Regards, >> >> -- >> Julien >> >> On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: >> >>> Folks, >>> >>> as announced in Dallas, we hereby initiate WG last call for ERS: >>> http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt >>> >>> Please provide final comments to the list by May 5th. >>> >>> Thanks, >>> >>> Carl & Tobias >>> Chairs of LTANS >>> >> > > 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 k44DcVhm092415; Thu, 4 May 2006 06:38:31 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44DcV21092414; Thu, 4 May 2006 06:38:31 -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 EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44DcUq6092408 for ; Thu, 4 May 2006 06:38:30 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG last call on ERS Date: Thu, 4 May 2006 06:38:23 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790298E805@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on ERS Thread-Index: AcZuwnIcqI/Mpq9yRd+BB2sC6e09FwAsy+AA From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k44DcUq6092409 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree. I think a section that describes the verification of a timestamp type (e.g., RFC3161) including processing of certs and rev info from the CryptoInfos field and handling of time of interest should be added. Similar detail for other timestamp types could be provided in subsequent docs, if desired, but at least one should be treated in detail here for sake of interoperability. I also have a concern about the placement of the CryptoInfos field in the structure. Currently, it's in the outermost layer. Thus, the contents of the field are not covered by the preservation layers and requires verifiers to sift through and sort out which artifacts apply to which timestamp in the EvidenceRecord. CryptoInfos might be better placed in the ArchiveTimestamp structure to support the production of self-contained evidence records (i.e., to avoid the need to access other sources when verifying and without losing preservation of the artifacts used during verification). The cert and crl bags of the timestamp structure offer another place such materials could be incorporated in a way that the artifacts are preserved. However, CMS doesn't provide a place to convey trust anchors. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, May 03, 2006 10:45 AM > To: ietf-ltans@imc.org > Subject: Re: WG last call on ERS > > > Folks, > > thanks a lot for the latest draft and your work. > > We have completed our first test implementation of ERS and we > were wondering if the WG planned to add more details about > the "CryptoInfos" > sequence either in ERS (or a future version) or in an other > document of the WG. > > While we understand the intent to leave this field fairly > free for specific needs, we also believe it would be nice to > have a small set of defined OIDs for, say, certificates, > CRLs, OCSP responses, trust anchors... > > Altough this work may be outside the scope of this WG, we > feel that several RFC now use a field morally containing "all > the crypto material needed for verification" without more > specification, which may hinder interoperability. > > If we take the example of revocation information, some people > will want to use, for instance the "CompleteRevocationRefs" > from RFC3126, while some other will choose the "RevInfos" > from SCVP, and some others the "RevocationInfoChoices" from CMS ... > > Regards, > > -- > Julien > > On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: > > Folks, > > > > as announced in Dallas, we hereby initiate WG last call for ERS: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > > > Please provide final comments to the list by May 5th. > > > > Thanks, > > > > Carl & Tobias > > Chairs of LTANS > > 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 k43Ej0Nv030987; Wed, 3 May 2006 07:45:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43Ej0c3030986; Wed, 3 May 2006 07:45:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43EixkM030980 for ; Wed, 3 May 2006 07:44:59 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id AAC894F40B for ; Wed, 3 May 2006 16:44:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 0C56B44104 for ; Wed, 3 May 2006 16:45:14 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09034-02 for ; Wed, 3 May 2006 16:45:09 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 16CAE440ED for ; Wed, 3 May 2006 16:45:08 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 3 May 2006 16:44:51 +0200 From: "Julien Stern" Date: Wed, 3 May 2006 16:44:51 +0200 To: ietf-ltans@imc.org Subject: Re: WG last call on ERS Message-ID: <20060503144451.GA1985@cryptolog.com> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <2666EB2A846BAC4BB2D7F593301A78681E174F@MUCXGC2.opentext.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78681E174F@MUCXGC2.opentext.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, thanks a lot for the latest draft and your work. We have completed our first test implementation of ERS and we were wondering if the WG planned to add more details about the "CryptoInfos" sequence either in ERS (or a future version) or in an other document of the WG. While we understand the intent to leave this field fairly free for specific needs, we also believe it would be nice to have a small set of defined OIDs for, say, certificates, CRLs, OCSP responses, trust anchors... Altough this work may be outside the scope of this WG, we feel that several RFC now use a field morally containing "all the crypto material needed for verification" without more specification, which may hinder interoperability. If we take the example of revocation information, some people will want to use, for instance the "CompleteRevocationRefs" from RFC3126, while some other will choose the "RevInfos" from SCVP, and some others the "RevocationInfoChoices" from CMS ... Regards, -- Julien On Fri, Apr 21, 2006 at 10:04:25AM +0200, Tobias Gondrom wrote: > Folks, > > as announced in Dallas, we hereby initiate WG last call for ERS: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-06.txt > > Please provide final comments to the list by May 5th. > > Thanks, > > Carl & Tobias > Chairs of LTANS 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 k42GaZgZ065032; Tue, 2 May 2006 09:36:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42GaZ4R065031; Tue, 2 May 2006 09:36:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42GaXCq065023 for ; Tue, 2 May 2006 09:36:34 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k42GaVLt002540; Tue, 2 May 2006 18:36:32 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Why are the hash values sorted? Date: Tue, 2 May 2006 18:36:31 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868256647@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why are the hash values sorted? Thread-Index: AcZq5/JnoUbUH6IsStahXcp2RN4i0gCzLGFQABJtuzA= X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Tilo Kienitz" Cc: , "Robert Eiglmaier" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k42GaZCq065025 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tilo, at first I fully agree with the technical reasons of Robert so far. (The performance and tree parsing is an important reason I forgot.) And I must disagree with your reasons: 1. you are right, SHA-256 seems pretty secure at the moment (at least today - let's see what the next Workshops at NIST and Crypto-conferences turns up) and other Hash algs are also good for this spec - but the freedom of reordering all hash-values in the tree is an absolutely unnecessary security risk and might increase future potential collision attacks. For the best security of the system the specification should be clear and unambiguous as good as possible. 2. The thought of IBM to insist that the order of the tree should reflect the order in which the documents have been signed is - to say it blunt - silly. A. you can NOT use this ordering as "proof" of order of signing time: you can never rely on the ordering you receive from ERS-system, so you could never rely on that it is not otherwise received or ordered. A-a) any user can send data in any order to the ERS-system. A-b) to fulfil your idea the ERS system would need to inspect the data it preserves which can not be possible in all cases (thinking of formats the ERS-system does not know, or content that is encrypted) - What would you do if this ordering would be in conflict with the times in the timestamps of the signatures. A-c) and in case you really would want to do this, you might also have to certify such a server as trusted and the sorting mechanism according to your proposal by a government agency to be able to rely on this information. B. the information about the signing time (and order) should definitely be in the signature and NOT be deducted from the order of the tree - as you know there is a very good mechanism called timestamp which gives absolutely clear information about the order of the signing times. C. small remark: your proposal is absolutely NOT required by the German ArchiSig project (and as one of the key project members I must know it). D. to me your proposal looks like a cheap "hack" for a proprietary not though-out/figured out system - your business goal SHOULD definitely be achieved otherwise. This is definitely NOT worth taking any risk (and be it even the slightest) of easier collision attacks against the hash tree in the future. E. and as a last remark: all my talks with government agencies (and there were quite some German included) did explicitly NEVER show this idea or strange requirement. (of course all of them need ERS and solutions conform to ERS) So I strongly recommend that you use a different and more mature approach for your idea - as Robert already explained there are many possible approaches not in conflict with ERS and a lot better than your proposal. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Robert Eiglmaier > Sent: Tuesday, May 02, 2006 9:07 AM > To: Tilo Kienitz; ietf-ltans@imc.org > Subject: RE: Why are the hash values sorted? > > > Hi Tilo, > > there are some more (technical) reasons for sorting the hashes: > > In an unsorted hashtree searching a certain hash value becomes > slow whereas in a sorted tree you can look it up real quick > with binary search. > > Sorting is done only once when creating the tree, searching > is done everytime a document needs to be verified. > > The format of the reduced hashtree would have to be changed > for unsorted hashtrees because for all the middle levels of the > tree only the neighbor hashvalue(s) are given. There is no > information where to put the calculated hashvalue. Left or right > or if the arity > 2 somewhere between the neighbors? > If they are sorted, this is unambiguous. > > And finally ArchiSig hashtrees have not been designed to prove > the order in which the documents arrived in an archive. Even if > the hashvalues would represent that order, this would be a hint > but no proof. > > You might create an additional document with references (hashes) > of your documents and e. g. the current date & time and add it > to the archive before creating the hashtree so that it is > timestamped. > > Robert > > > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tilo Kienitz > Sent: Freitag, 28. April 2006 19:07 > To: Tobias Gondrom > Cc: ietf-ltans@imc.org; Boris Baltzer > Subject: Re: Why are the hash values sorted? > > > > Hello Tobias, > > > We sort the hash values (binary ascending) to reduce the risk of > > collision attacks by resorting the hash values in another combination > > and by this getting another hash value for the parent node. > > I understand these arguments, but they do not convince me. If there > was a realistic risk of collision attacks, a better hash algorithm > should be used to prohibit such an attack. The draft does not demand > a certain hash algorithm and an upgrade would be conformal. I am no > cryptographer and maybe missing something, but it is my understanding > that we do not have to expect collision attacks against for example > SHA-256 within the next years. > If your concern is that of a collision attack, you will also have > to consider the possibility of inserting arbitrary values into the > hash tree in order to perform such an attack. In my perception, > inserting arbitrary values into the hash tree provides possibilities > for collision attacks similar to those of resorting the hashes. In > this respect, sorting the hashes to prevent collisions seems like > installing a bigger lock on the door while the window remains open. > > In short: I think that collision attacks have to be prevented by the > hash algorithm, not by the way the tree is sorted. > > > And as we > > only secure the root hash with the time stamp we think that it is > > mandatory that the mapping/transformation from a given set of hash > > values to the root hash MUST be unambiguous. > > I suggest to compute the parent hash on the hashes below it in the > exact order in which they appear in the ASN.1-sequence. This is > an unambiguous rule. > > > I understand the need for grouping of objects, but the order in the > > hash > > tree is not the right element for the information of the order of the > > documents in an application/document specific context. > > For many of our customers like IBM and major German authorities it > is an important feature to be able to prove the order in which the > documents have been signed. They insist that the hash tree is the > natural place for this proof. It is important for us to have a > solution compatible to the ArchiSig standard and therefore to > LTANS-ERS. Therefore I suggest to make the sorting optional and > insert a flag into the evidence record which shows whether the > values have to be binary sorted before verification or just taken > as they are. > > Kind regards > Tilo > > > -- > Tilo Kienitz > SecCommerce Informationssysteme GmbH > Obenhauptstr. 5 > D - 22335 Hamburg http://www.seccommerce.de > Germany > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4277Ow4038490; Tue, 2 May 2006 00:07:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4277Ov5038489; Tue, 2 May 2006 00:07:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4277K2h038467 for ; Tue, 2 May 2006 00:07:23 -0700 (MST) (envelope-from reiglmai@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k427781Z028115; Tue, 2 May 2006 09:07:19 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Why are the hash values sorted? Date: Tue, 2 May 2006 09:07:07 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680D8D08@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why are the hash values sorted? Thread-Index: AcZq5/JnoUbUH6IsStahXcp2RN4i0gCzLGFQ From: "Robert Eiglmaier" To: "Tilo Kienitz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4277N2h038474 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Tilo, there are some more (technical) reasons for sorting the hashes: In an unsorted hashtree searching a certain hash value becomes slow whereas in a sorted tree you can look it up real quick with binary search. Sorting is done only once when creating the tree, searching is done everytime a document needs to be verified. The format of the reduced hashtree would have to be changed for unsorted hashtrees because for all the middle levels of the tree only the neighbor hashvalue(s) are given. There is no information where to put the calculated hashvalue. Left or right or if the arity > 2 somewhere between the neighbors? If they are sorted, this is unambiguous. And finally ArchiSig hashtrees have not been designed to prove the order in which the documents arrived in an archive. Even if the hashvalues would represent that order, this would be a hint but no proof. You might create an additional document with references (hashes) of your documents and e. g. the current date & time and add it to the archive before creating the hashtree so that it is timestamped. Robert -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tilo Kienitz Sent: Freitag, 28. April 2006 19:07 To: Tobias Gondrom Cc: ietf-ltans@imc.org; Boris Baltzer Subject: Re: Why are the hash values sorted? Hello Tobias, > We sort the hash values (binary ascending) to reduce the risk of > collision attacks by resorting the hash values in another combination > and by this getting another hash value for the parent node. I understand these arguments, but they do not convince me. If there was a realistic risk of collision attacks, a better hash algorithm should be used to prohibit such an attack. The draft does not demand a certain hash algorithm and an upgrade would be conformal. I am no cryptographer and maybe missing something, but it is my understanding that we do not have to expect collision attacks against for example SHA-256 within the next years. If your concern is that of a collision attack, you will also have to consider the possibility of inserting arbitrary values into the hash tree in order to perform such an attack. In my perception, inserting arbitrary values into the hash tree provides possibilities for collision attacks similar to those of resorting the hashes. In this respect, sorting the hashes to prevent collisions seems like installing a bigger lock on the door while the window remains open. In short: I think that collision attacks have to be prevented by the hash algorithm, not by the way the tree is sorted. > And as we > only secure the root hash with the time stamp we think that it is > mandatory that the mapping/transformation from a given set of hash > values to the root hash MUST be unambiguous. I suggest to compute the parent hash on the hashes below it in the exact order in which they appear in the ASN.1-sequence. This is an unambiguous rule. > I understand the need for grouping of objects, but the order in the > hash > tree is not the right element for the information of the order of the > documents in an application/document specific context. For many of our customers like IBM and major German authorities it is an important feature to be able to prove the order in which the documents have been signed. They insist that the hash tree is the natural place for this proof. It is important for us to have a solution compatible to the ArchiSig standard and therefore to LTANS-ERS. Therefore I suggest to make the sorting optional and insert a flag into the evidence record which shows whether the values have to be binary sorted before verification or just taken as they are. Kind regards Tilo -- Tilo Kienitz SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 Hamburg http://www.seccommerce.de Germany