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 l3UEFxd7073947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 07:15: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 l3UEFxE7073946; Mon, 30 Apr 2007 07:15: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 ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UEFat6073854 for ; Mon, 30 Apr 2007 07:15:56 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 54B0B13; Mon, 30 Apr 2007 16:15:22 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08191-10; Mon, 30 Apr 2007 16:15:19 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 010B1F; Mon, 30 Apr 2007 16:15:19 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007043016151794:228348 ; Mon, 30 Apr 2007 16:15:17 +0200 Message-ID: <4635F972.9040108@edelweb.fr> Date: Mon, 30 Apr 2007 16:13:06 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tobias Gondrom Cc: Carl Wallace , "ietf-ltans@imc.org" Subject: Re: LTANS: clean-up of ltans oid structure - next revision of OID Registry References: <2666EB2A846BAC4BB2D7F593301A7868E386E7@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868E386E7@MUCXGC2.opentext.net> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/30/2007 04:15:18 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/30/2007 04:15:18 PM, Serialize complete at 04/30/2007 04:15:18 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070707060104020408090501" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070707060104020408090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I think we are getting closer. But some comments anyway. First, only the id-* need to be defined with global names. They are in fact defined in each of the asn.1 modules for ers or ltap, etc. The other ids are not global definitions. They are not intended to be importable from anywhere. ltans, ers and ltap are special: They are used locally in the ers or ltap module to define the parents of some id-* unless we follow the logic of the ITU to have a useful definitions module where we can even import oid of moduls, there is no reason to them a name, they are just object identifier values. Second, mste values should have names at the last component, i.e. all except the module identifiers whether the last is just the version number. I still don't think that pushing down the module arc below ers or ltap is a good idea, since other working groups don't do that. IMO it does too much of delegation to a topic writer like ers or ltap. Well, the actual logic means: "Dear ltans contributor, if you want to contribute some work, tell us how many asn1 modules you want, and we give you an arc root where you are supposed to add one mod(2) mod88(1) and you can use the rest of the arc as you wish. I prefer at least for tyhe modules: 'Write one or two modules', chose a NAME for the module, we (ltans) give you an identifier for that. " ... BtW, in any case I'd prefer module(0) instead of mod(2) Tobias Gondrom wrote: > Hello Peter, hello all, > > sorry, that this answer took me so long, but I have been occupied the last week with some other things. :-( > > > I agree, we are on the same page. > As mentioned before, the intention is to list the OIDs we will register at the LTANS OID registry at http://www.imc.org/ietf-ltans/ltans-oid.asn > I don't see what is supposed to be registered and how. The only OID, in fact, it value is the { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } I don't think that we need an actual global definition id-ltans or ltans for it. If the name is a hint that instruct module writers to include a local definition of that kind, then, why not, so in the ers modules one would have the definitions ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } -- LTANS Arcs ers OBJECT IDENTIFIER ::= { ltans ers(1) } - Evidence Record Syntax in order to be able to says id-ers-em OBJECT IDENTIFIER ::= { ers em(3) } instead of id-ers-em OBJECT IDENTIFIER ::= { ltans ers(1) em(3) } or id-ers-em OBJECT IDENTIFIER ::= { so(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) em(3) } Note the NAMES ers and em on the right side! > 1. As no one else had any additional comments concerning the naming convention (module vs. module97) I will follow your proposal. > > 2. As I learned also from our discussion my naming convention was in some cases a bit confusing (and ambiguous), so I looked again at the other OID lists and revised the draft for LTANS-OIDs slightly to be unambiguous by using the name of the father node as the prefix for the name of the child-node (as done by PKIX and SMIME). Other OID lists follow the guidance to always use the short code of the level above as the prefix for the identifiers one level below, without the WG father node, e.g. at PKIX id-swb-pkc-cert-path being a child of id-swb. > > Please note: I only revised the names, the structures stayed exactly the same. And I hope that the new names and convention are acceptable. > > If not, please reply until May-07 to the list. > > One small additional comment concerning the prefix "id": > I only used it for some of the identifiers, if there is a WG consensus to use the id-prefix for all identifiers, I will of course follow this guidance, but I would vote for the names as listed below: > The NAMES on the left side are global since the registry is not part of an asn.1 modul, so you cannot just import the values. This "asn" file just uses some asn.1 syntax but this seems inappropriate to me. > > -- LTANS Object Identifier Registry > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > > -- LTANS Arcs > ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > { ltans ers(1) } > ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol > { ltans ltap(2) } Thus one I already meantioned above. > -- ERS Modules > ers-mod88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax > { ers mod88(1) } > ers-mod OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax > { ers mod(2) } I'd prefer 0 as in other specs. and cann it module(0) > id-ers-em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method in ERS { ers em(3) } > } > > -- Version for ERS Module 88 > ers-mod88-ver OBJECT IDENTIFIER ::= { ers-mod88 1 } - Version number for RFC > > -- Version for ERS Module > ers-mod-ver OBJECT IDENTIFIER ::= { ers-mod 1 } - Version number for RFC > > -- ERS Encryption Methods > id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em 1} > id-ers-em-er-external OBJECT IDENTIFIER ::= {id-ers-em 2} > > id-ers-em-er-internal OBJECT IDENTIFIER ::= {id-ers-em er-internal(1)} etc > -- LTAP Modules > ltap-mod88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax > ltap-mod OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax > { ltap mod88(1) } { ltap mod(2) } > -- for LTAP Module 88 > ltap-mod88-ver OBJECT IDENTIFIER ::= { ltap-mod88 1 } - Version number for RFC > > -- for LTAP Module > ltap-mod-ver OBJECT IDENTIFIER ::= { ltap-mod 1 } - Version number for RFC > > The names on the right side are necssary since we want to write ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) mod(2) 1 } or as I prefer ERS MODULE { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) module(0) ers(1) 1 } > > Best regards, Tobias > > > Have fun. --------------ms070707060104020408090501 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 BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+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 S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDMwMTQxMzA2WjAjBgkqhkiG9w0B CQQxFgQUlLf6R0S6Fi0yOu6I+uMWZDOrnr8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAFyA+dD6jc9MTds7F YoEYXWaBW6p52muDG9lyi0NAQle+H3d+P4P2Xvd5z4BU8zc0kEDFKgS3vTKytGfalihEyfpL NdDarlC8ZOWbXfMWW8bBZfFDZrN+HCvuCT+Gkn63g61S5UCKGsgw4XRPdpax7BV7cf9oSI/1 YaUxd5N8DVIAAAAAAAA= --------------ms070707060104020408090501-- 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 l3UCfWa2062047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 05:41: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 l3UCfW8R062046; Mon, 30 Apr 2007 05:41: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 mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UCf8xj062023 for ; Mon, 30 Apr 2007 05:41: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 l3UCf5np016903; Mon, 30 Apr 2007 14:41:06 +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: I-D ACTION:draft-ietf-ltans-ers-12.txt Date: Mon, 30 Apr 2007 14:41:03 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868E387A3@MUCXGC2.opentext.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ltans-ers-12.txt Thread-Index: Acd7V4VY7hQjz9uMQY2BfvBIGr2M5QPx6A9w From: "Tobias Gondrom" To: "Denis Pinkas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3UCfTxj062041 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Denis, thank you for your review and please excuse that it took me so long to answer. 0. As ERS is in IETF LC (started 2007-02-21), I will treat and document your comments also as IETF LC comments. But now concerning your comments: 1. This is as designed. When an initial EvidenceRecord is created there is only one ArchiveTimeStamp in it. Further ArchiveTimeStamps (in the ArchiveTimeStampChain are added when Timestamp-renewald are necessary (this means there is always just one further ArchiveTimestamp added to the chain). and similar to that of with new ArchiveTimestamps created by hashtree-renewal. So the use case (to create at one point in time multiple ArchiveTimestamps within the same ArchiveTimestampchain) you described actually never applies. 2. In fact it is very easy to find out which documents are stored/covered by and ArchiveTimeStamp: the hash values of the documents (which can be computed easily) are stored in the first ArchiveTimeStamp. So it is trivial to relate documents to the EvidenceRecord. 3. CryptoInfos and EncryptionInfo follow two very different goals: CryptoInfos to provide information (like all used algorithms) at the higher level of the EveidenceRecord to make processing easier (or to make it easy to decide for an implementation whether it shall proceed with the evaluation or abort if it may not be able to compute one of thee listed algorithms.) encryptionInfo has the intend to ensure a bi-directional mapping between used encryption methods (like e.g. splitting the bits between several archive systems) and the documents. (Note in some cases such an encryption algorithm might use additional parameters and only be surjective but not be bijective. The encryptionInfo field is allow the user to provide all necessary information to make the operation fully bijective. (By this the proof that the decrypted information mathematically unambiguously matches the encrypted and by the EvidenceRecord protected content.) 4. a) An unlimited number of levels in the hashtree is definitely possible with the current structure. (It is not limited to 3 levels.) b) every node is unambiguous. c) at first the structure of the EvidenceRecord is obviously intended to be extended every time algorithms get weak and a timestamp-renewal or hashtree-renewal occurs. So it is not intended to include an EvidenceRecord within another for this need (the equivalent of your idea is that ArchiveTimestamps protect the preceeding ArchiveTimestamps, which is the case). At any given time an existing EvidenceRecord can be extended (also by another party) and if it is necessary (although I can see no clear use case for that) it can of course also be stored and protected itself as a data object protected by an EvidenceRecord. d) we have added several hooks for extensibility with the Attributes in the ArchiveTimeStamp structure. (btw. inspired by your last review) e) it is not intended to stack time-stamp tokens with CRLs by a one-to-one relationship. Additional verification data for the timestamps should be stored in the timestamp structures themselves or in the cryptoInfos. Summarizing: The comments above are due to misunderstanding but do not demonstrate a defect in the draft or data structure. I can see no need to make any changes to the draft, except for the wording: there had been a few wording comments from the AD review and those will be addressed in a new version. The new draft is scheduled to be submitted in one week and will (if no further objections occur) then be processed further in the IETF LC. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Tuesday, April 10, 2007 11:44 AM > To: ietf-ltans@imc.org > Subject: Re: I-D ACTION:draft-ietf-ltans-ers-12.txt > > > Comments on draft-ietf-ltans-ers-12 > > Major comments 1 to 4 > > The current syntax is defined as: > > EvidenceRecord ::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > cryptoInfos [0] CryptoInfos OPTIONAL, > encryptionInfo [1] EncryptionInfo OPTIONAL, > archiveTimeStampSequence ArchiveTimeStampSequence > } > > ArchiveTimeStampSequence ::= SEQUENCE OF > ArchiveTimeStampChain > > ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp > > ArchiveTimeStamp ::= SEQUENCE { > digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, > attributes [1] Attributes OPTIONAL, > reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, > timeStamp ContentInfo} > > Attributes ::= SET SIZE (1..MAX) OF Attribute > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > There are several problems with this syntax: > > 1) Within ArchiveTimeStamp, the timeStamp element is mandatory. > When an ArchiveTimeStampChain is being built, several time stamp tokens > will be needed whereas only one time stamp token at the top of the > hierarchy > is really needed. It should be possible to have a timeStamp element > present > in the EvidenceRecord structure. > > 2) When the Evidence Record is stored separate from the archived data, > the syntax does not allow to interoperate, since there is no way to know > how to build or reconstruct the right sequence of PartialHashtrees. > > PartialHashtree ::= SEQUENCE OF OCTET STRING > > One way to solve this issue would be to add the name of each element used > to construct the hash tree, so that that name can be used to locate and > fetch > the corresponding file. > > 3) cryptoInfos and encryptionInfo are currently defined as follows: > > CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute > > EncryptionInfo ::= SEQUENCE { > encryptionInfoType OBJECT IDENTIFIER, > encryptionInfoValue ANY DEFINED BY encryptionInfoType > } > > cryptoInfos and encryptionInfo do not allow any kind of interoperability. > It would more appropriate to define generic extensions, like for > certificates and CRLs: > > extensions Extensions OPTIONAL, > > 4) The current syntax does not allow : > > - an unlimited number of levels in the tree (only three levels are > possible); > - to identify a node; > - to incorporate into an Evidence Record, previously computed Evidence > Records; > - to add new extensions; > - to stack time-stamp tokens and CRLs. > > The following syntax would solve the issue: > > EvidenceRecord::= SEQUENCE { > version INTEGER { v1(1) } , > digestAlgorithms SEQUENCE OF AlgorithmIdentifier, > reducedHashtree ReducedHashtree OPTIONAL, > otherEvidenceRecords SEQUENCE OF EvidenceRecord OPTIONAL, > extensions Extensions OPTIONAL, > timeStamps SEQUENCE OF TimeStamp > } > > ReducedHashTree ::= SEQUENCE { > hashTreeElements SEQUENCE OF HashTreeElement, > reducedHashTree SEQUENCE OF ReducedHashTree OPTIONAL > } > > HashTreeElement ::= SEQUENCE { > node BOOLEAN DEFAULT FALSE, > digestAlgorithm AlgorithmIdentifier, > elementHash OCTET STRING, > elementName GeneralName OPTIONAL, > } > > TimeStamp ::= SEQUENCE { > tst ContentInfo, > crl CertificateList OPTIONAL > } > > Sections 3.2 and 3.3 would need to be rewritten. > > Minor comment > > The word non-repudiation is misused in several places. For example, on > page 6: > > " each Archive Timestamp preserves non-repudiation of the previous Archive > Timestamp" . > There is no need to use the word non-repudiation here, since the following > sentence is sufficient: > " each new time-stamp maintains the validity of the previous time-stamp". > > Denis > > ================================================================ > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Long-Term Archive and Notary Services > Working Group of the IETF. > > > > Title : Evidence Record Syntax (ERS) > > Author(s) : R. Brandner, et al. > > Filename : draft-ietf-ltans-ers-12.txt > > Pages : 34 > > Date : 2007-3-8 > > > > In many scenarios, users must be able prove the existence and > > integrity of data, including digitally signed data, in a common and > > reproducible way over a long and possibly undetermined period of > > time. This document specifies the syntax and processing of an > > Evidence Record, a structure designed to support long-term non- > > repudiation of existence of data. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-ltans-ers-12.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-ltans-ers-12.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > Content-Type: text/plain > > Content-ID: < 2007-3-8122718.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-ltans-ers-12.txt > > > > Regards, > > Denis Pinkas 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 l3RFqBF0051086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 08:52: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 l3RFqBHZ051085; Fri, 27 Apr 2007 08:52: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 mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RFpnAi051041 for ; Fri, 27 Apr 2007 08:52:10 -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 l3RFpdlk015999; Fri, 27 Apr 2007 17:51:40 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LTANS: clean-up of ltans oid structure - next revision of OID Registry Date: Fri, 27 Apr 2007 17:51:39 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0087_01C788F4.B4D600B0" Message-ID: <2666EB2A846BAC4BB2D7F593301A7868E386E7@MUCXGC2.opentext.net> In-Reply-To: <461E296A.6050705@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: clean-up of ltans oid structure - next revision of OID Registry Thread-Index: Acd9AH3OSqXp9uheQeisUCSE/4ud5wL09Z8A From: "Tobias Gondrom" To: "Peter Sylvester" Cc: , "Carl Wallace" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C788F4.B4D600B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Peter, hello all, sorry, that this answer took me so long, but I have been occupied the = last week with some other things. :-( I agree, we are on the same page.=20 As mentioned before, the intention is to list the OIDs we will register = at the LTANS OID registry at http://www.imc.org/ietf-ltans/ltans-oid.asn = 1. As no one else had any additional comments concerning the naming = convention (module vs. module97) I will follow your proposal. 2. As I learned also from our discussion my naming convention was in = some cases a bit confusing (and ambiguous), so I looked again at the = other OID lists and revised the draft for LTANS-OIDs slightly to be = unambiguous by using the name of the father node as the prefix for the = name of the child-node (as done by PKIX and SMIME). Other OID lists = follow the guidance to always use the short code of the level above as = the prefix for the identifiers one level below, without the WG father = node, e.g. at PKIX id-swb-pkc-cert-path being a child of id-swb. Please note: I only revised the names, the structures stayed exactly the = same. And I hope that the new names and convention are acceptable.=20 If not, please reply until May-07 to the list.=20 One small additional comment concerning the prefix "id": I only used it for some of the identifiers, if there is a WG consensus = to use the id-prefix for all identifiers, I will of course follow this = guidance, but I would vote for the names as listed below: -- LTANS Object Identifier Registry ltans OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3)=20 dod(6) internet(1) security(5) mechanisms(5) ltans(11) } -- LTANS Arcs ers OBJECT IDENTIFIER ::=3D { ltans 1 } - Evidence Record Syntax ltap OBJECT IDENTIFIER ::=3D { ltans 2 } - Long Term Archive Protocol -- ERS Modules ers-mod88 OBJECT IDENTIFIER ::=3D { ers 1 } - Module ASN.1 1988-Syntax ers-mod OBJECT IDENTIFIER ::=3D { ers 2 } - Module ASN.1 1997-Syntax id-ers-em OBJECT IDENTIFIER ::=3D { ers 3 } - Encryption Method in ERS -- Version for ERS Module 88 ers-mod88-ver OBJECT IDENTIFIER ::=3D { ers-mod88 1 } - Version number = for RFC -- Version for ERS Module ers-mod-ver OBJECT IDENTIFIER ::=3D { ers-mod 1 } - Version number for = RFC -- ERS Encryption Methods id-ers-em-er-internal OBJECT IDENTIFIER ::=3D {id-ers-em 1} id-ers-em-er-external OBJECT IDENTIFIER ::=3D {id-ers-em 2} -- LTAP Modules ltap-mod88 OBJECT IDENTIFIER ::=3D { ltap 1 } - Module ASN.1 = 1988-Syntax ltap-mod OBJECT IDENTIFIER ::=3D { ltap 2 } - Module ASN.1 = 1997-Syntax -- for LTAP Module 88 ltap-mod88-ver OBJECT IDENTIFIER ::=3D { ltap-mod88 1 } - Version number = for RFC -- for LTAP Module ltap-mod-ver OBJECT IDENTIFIER ::=3D { ltap-mod 1 } - Version number = for RFC Best regards, Tobias =00 ------=_NextPart_000_0087_01C788F4.B4D600B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA0MjcxNTUxMzlaMCMGCSqGSIb3DQEJBDEWBBRr5q4jVVLeszUkc17SkkTqAl+v tzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICABaoqpcdP78vv4/rBG6UlQ4Bg+efh70Oxryi+wtTVMbYlSNAztGxfjJ/Xivj 6apdKDBFvOPX7tLfMgmxeSqOCMXhgqYEBrbf1q8OdN+Ie7tsfHiH1+7tic6A4m2/JYN2vX+6eWjV NjHeeejbS/xxNGCvHYBkFVCXXLcUvJZO7oNiONcAQl+fP5c8/MqmJ6QZ/Vv5r6ploRm28gDOWcfL 1gpQU401esDXxXB3Lp6NxQbKPLsAgiNc8CJUc/kWrxsvL/T9WZyJnpZpQhbwMbqQhaY0bYkiLAKv D1bTfQDnTehR4Ja5dpWe++P57tIubk3nl6Q1Fg3rknNt+YV2N0zDkYbNN7eocg9wKaq9AyJzN2kP VrFAsRzcz2lX8T0vDoJtItyWN/jhrMvGYaLhMCDtM2UjOj8J3QAgP/7zMWtDeVMaT+6gWAckSfC6 ZYEtc+ANsBSUxKkeC28nXXwQRxWAlT/Irfm9WhnuHupiCtESpZG0fIAqEn+XzKWsMrISrCkdExnI wGekH5KzkYXGUZDs9BYw3jJeVbbl1kcFbSak+8WRkOXUWMB4ir97KCI5kwdoQrlropGIrNFgccxY Agn18O6PF+EPcacIPMeNPHms4BjugQfiJRoCc6esrvt1ngOqCK7HsMA6WDGsWQPvSjbtjbxXUukC hQxxWTaYpsMYXhZjAAAAAAAA ------=_NextPart_000_0087_01C788F4.B4D600B0-- 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 l3CD5B2n099114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:05: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 l3CD5BWR099113; Thu, 12 Apr 2007 06:05:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CD59AX099106 for ; Thu, 12 Apr 2007 06:05:09 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 7948D1F; Thu, 12 Apr 2007 14:45:37 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30294-07; Thu, 12 Apr 2007 14:45:33 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 0DC591E; Thu, 12 Apr 2007 14:45:33 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007041214453176:199418 ; Thu, 12 Apr 2007 14:45:31 +0200 Message-ID: <461E296A.6050705@edelweb.fr> Date: Thu, 12 Apr 2007 14:43:22 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tobias Gondrom Cc: ietf-ltans@imc.org, Carl Wallace Subject: Re: LTANS: clean-up of ltans oid structure References: <2666EB2A846BAC4BB2D7F593301A7868D3EAD9@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868D3EAD9@MUCXGC2.opentext.net> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/12/2007 02:45:31 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/12/2007 02:45:32 PM, Serialize complete at 04/12/2007 02:45:32 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000805050609050902030601" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000805050609050902030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tobias Gondrom wrote: > Hello Peter, > my comments inline. > > >> I got the ideas of your changes but there are some errors. >> >> The basic change is inverting the tree between asn1 syntax version >> and module prefix. That's ok, but I disagree with the indication >> of 97 syntax. This is a rathole. >> > > I do not understand this metaphor and I do not see a problem with the 97 > suffix. From my belief I see no reason to not treat both modules (the 88 and > current/97) equally, which would result in module88 and module97 or > module2002. (But to be honest I have no strong feelings about this.) > Well, if one wants to indicate each version or correction. Anyway we are already at version2002 at least. Since ITU does not create different equivalent versions of their modules depending on the ASN.1 syntax version, or at least, there is no convention to do indicate this, I don't think it is necessary to indicate module1997 module2002 module2002amendment1 etc. 97 is already wrong anyway, and see the last but one comment later. > > >> The following also does not make a clear distinction between >> >> id-something --- usable in encodings as encoded object identifiers. >> something --- a GLOBAL identifier identifying a module. >> Something --- definition of a module >> >> and which are GLOBAL and which are just local for convenience >> inside each module. >> >> To get inspired by the ITU definitions, there is the following convention >> >> When "Something" (like AuthenticationFramework) is a module, >> then "something" is an OBJECT IDENTIFIER value notation that >> of that thing and it is defined in a UsefulDefinitions module. >> >> Thus the global OBJECT IDENTFIER value noration "ers" should not >> be the tree root of ers but the Ers module value. If one needs ers/ltans >> etc in IDs then call the global value definition >> >> id-ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >> >> dod(6) internet(1) security(5) mechanisms(5) ltans(11) } >> >> id-ers OBJECT IDENTIFIER ::= { id-ltans 1 } - Evidence Record Syntax >> > > I do not understand the need for the id-prefix for ltans and ers. > My proposal is guided by the structures as they are also used by e.g. PKIX > and IPSec. Both only use a small subset of their ids with this prefix: > PKIX: > http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.5.5.7&action=displa > y > No, they are not guide by all the example. The point is not allocating a number and a relaive name to latnas or ers or ltao. The point is not the value, i.e. the right side of ::=, the point is the left side of an exported OBJECT IDENTIFIER value notation. In thes example about pkix you have id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) > IPSec as well: > http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.5.5.8&action=displa > y > > For ipsec you do not have a global value notation. > So I do not join your proposed convention. Could you maybe provide a link to > the resource where this convention is described? > > So far I can not see a problem with the syntax without the prefix: > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) } > According with pkix and others this would be id-ltans > ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > and this id-ers OBJECT IDENTFIER ::= { id-ltans ers(1) } > > > >> Tobias Gondrom wrote: >> >>> Hello, >>> >>> thanks to Peter ' s initiative, Carl and I worked again through the >>> LTANS OID structure and want to use the last opportunity (before ERS >>> is published) to clean a few things up . In the past we added a few >>> OIDs to the LTANS tree which were onl y referenced in drafts but later >>> removed again. So now is the good time to clean this up. >>> >>> Based on Peter's proposal but not completely following it, we plan to >>> use the following structure . >>> >>> At the bottom I give some reasons why Carl and I c hose the structure >>> as listed below. >>> >>> P lease take a look at it and post comments or objections to the >>> mailing-list until April-12 . >>> >>> ( comment: it ' s only the structure of the LTANS OID number tree with >>> no real impact , so a short review time should be sufficient . ) >>> >>> >>> >>> * But now to the structure: * >>> >>> Starting with the g eneral prefix: >>> >>> ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >>> >>> dod(6) internet(1) security(5) mechanisms(5) ltans(11) } >>> >>> below this level we will have: >>> >>> ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax >>> >>> ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol >>> >>> >> I am not sure WHERE you want to define these GLOBAL identifiers. Inside >> each of the ltans modules? >> >> > > We should register these GLOBAL identifiers in our OID registry and also > define them inside the according LTANS RFCs. > The conventions used elsewhere are: - id-something to indicate OIDs that are potentially usable in encodings. - "Something" is the name for a module, it can have several version indicated by different module oids. (e.g. AuthenticationFramework has 5 versions - "something" is a global OBJECT IDENTIFIER value notation for a "Something" which is defined in some "UsefulDefinitions" module, so that one can import something FROM MyCurrentBestChoiceOfModules whatever FROM Something something > > >>> And below ers and ltap the different module versions: >>> >>> module88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax >>> >>> module97 OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax >>> >>> module88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax >>> >>> module97 OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax >>> >>> >> You are confusing something. You don't define such "GLOBAL" objects >> anywhere. >> You just define a module with a version like >> ers88 OBJECT IDENTIFIER ::= { ers module88(1) 1 } >> >> Or, This does not define global identifiers. You would need to say >> somethiung like >> >> ers88-moduleprefix OBJECT IDENTIFIER ::= { ers module88(1) } - Module >> ASN.1 1988-Syntax >> ers-moduleprefix OBJECT IDENTIFIER ::= { ers module97(2) } - Module >> ASN.1 1991-Syntax >> etap88-moduleprefix OBJECT IDENTIFIER ::= { ltap module88(1) } - Module >> ASN.1 1988-Syntax >> etap-moduleprefix OBJECT IDENTIFIER ::= { ltap module97(2) } - Module >> ASN.1 1991-Syntax >> >> But these definitions are not needed in any case because the only places >> where they are used >> are the module definition itself or imports which also don't need the >> prefix. >> >> > > OK, maybe my description has been a bit chaotic and formal. > The intention was to clearly specify the module based on the type (ERS or > LTAP) and the module syntax (88-conform, 97-conform, ...) > > In comparison to your proposal from march-04 just in the switched order > (instead of module-syntax and below that the spec). > Citing your email: > " a general prefix for ltans which is > > iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) > > - then two identifiers for modules > module(1) > module88(2) > id-em(3) ** renumbered ** > > in order to clearly separate the same modules > in different syntax. > > - under both trees use the same numbers for the > corresponding modules. e.g. > module(1) ers(1) > module88(2) ers(1)" > > > Instead my proposal would be described in your writing style: > Of course the same general prefix for ltans which is > > iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) > > - then identifiers for specifications > ers(1) > ltap(2) > > - under both trees use growing numbers for the > corresponding module syntaxes. e.g. > ers(1) module88(1) > ers(1) module97(2) > ltap(2) module88(1) > ltap(2) module97(2) > Besides the module97 I agree with that structure but I can live with it. > > >>> And below this , for both ers and ltap each: >>> >>> (also inspired by your LTAP draft , we will add a version number for >>> the module - just in case we later need to update it - citing the LTAP >>> draft: version numbers of 0 relate to all draft status, version number >>> is 1 with the release of the RFC): >>> >>> version OBJECT IDENTIFIER ::= { module88 1 } - Version number for this >>> RFC >>> >>> version OBJECT IDENTIFIER ::= { module97 1 } - Version number for this >>> >> RFC >> >> You don' want such definitions at all. >> >>> Or to be more precise: >>> >>> For ERS: >>> >>> version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >>> dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) >>> module88(1) version(1) } - Version number for ERS RFC >>> >>> version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >>> dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) >>> module97(2) version(1) } - Version number for ERS RFC >>> >>> and for LTAP: >>> >>> version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >>> dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) >>> module88(1) version(1) } - Version number for LTAP RFC >>> >>> version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) >>> dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) >>> module97(2) version(1) } - Version number for LTAP RFC >>> >>> >>> >> This doesn't make sense. What you want to define above is not a version >> but one module for each asn1 syntax. >> >> ers88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } - >> Version number for ERS RFC >> ers OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 } - >> Version number for ERS RFC >> ltap88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module88(1) 1 } >> - Version number for ERS RFC >> ltap OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module(2) 1 } - >> Version number for ERS RFC >> > > > Ok, I see. My initial define of "version" was an unlucky naming. So we are > on the same page here. But I currently still do not agree with the other > changes you proposed above (renaming module97 to module). I would still > propose the following structure: > > ers88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } - > Version number for ERS RFC > No you would say that the current module is { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } whether you define an OBJECT identifier is another question. > ers97 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ers(1) module97(2) 1 } - > Version number for ERS RFC > ltap88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module88(1) 1 } - > Version number for ERS RFC > ltap97 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module97(2) 1 } - > Version number for ERS RFC > > >> where ers corresponds to a module >> >> Ers MODULE iso(1) identified-organization(3) dod(6) internet(1) >> security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 >> >> >> so you could have >> >> IMPORT ers FROM LtansUsefulDefinitions iso(1) identified-organization(3) >> dod(6) internet(1) security(5) mechanisms(5) ltans(11) >> usefuldefinitions(0) module(2) 1 >> >> whatever FROM ers >> >> ; >> >> I prefer Ers and Ltap instead of Ers97 and Ltap97. Indeed, each >> correction to asn.1 may result >> in an impossiblity to use an existing compiler. But I don't think that >> it is a good solution to >> make a full two dimensional matriw of versions aof a module and of all >> possible technical >> amendments of asn.1. >> > > In fact I see no technical problem with such a matrix. (and we do not need > to fill all the filed of the matrix, but only the ones which are really > used/specified) (and btw. I understood your proposal from March-04 also as > such a matrix.) > Ok, as long as nobody is supposed to create all versions for 88 93, 97, 2002, ... but only an 88 and ONE of the others, but one actually have to invent a modulexxxx each time. We are in 2002 already and maybe 2004. It is very difficult to say what you are actually matching, the syntax or encoding rules, etc. > Citing: > " ERS iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) module(1) ers(1) 1 > > ERS iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) module88(1) ers(1) 1 > > LTAP iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) module(1) ltap(2) 1 > > LTAP iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) > ltans(11) module88(1) ltap(2) 1" > > > > >> Ltap and Ers should import from the Authentication/InformationFramework >> 5 modules which >> are from 2005. They are the most current. There should not be hint about >> a particular version. >> >> Also Ers88 etc is NOT needed, both modules can be named Ers. >> > > But it improves readability greatly to extend the name of the modules with > the syntax-version. > in none of the ITU versions you have that feature of readability as far as I know. There is only one and one current ASN.1 > >>> And at last, the EncryptionMethod oids from the ERS draft : >>> >>> id- em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method >>> >>> or written in the long form: >>> >>> id-em OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) >>> internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) } >>> >>> and below that, the two identifiers used in ERS: >>> >>> id- er-internal OBJECT IDENTIFIER ::= { id- em 1} >>> >>> id- er-external OBJECT IDENTIFIER ::= { id- em 2} >>> >>> ( this is only _ / renaming / _ the existing identifiers, describing >>> the selection method when using ER S with CMS - this is only replacing >>> the existing identifier _ / names / _ (nothing else!) >>> >>> Old names were: id-EvidenceRecord-Internal and >>> id-EvidenceRecord-External - new names: id- er-internal and id- >>> er-external >>> >>> >>> >>> * There are several OIDs that ** have only been used ** in ** old ** >>> er ** and ** already ** expired versions of ** drafts; ** we will ** >>> actively state that they be removed ** from the registry ** . ** * >>> These are: id-ct, id-em, id-mod-ers, id-evidence-record, >>> id-em-env-data. ** >>> >>> * Reasons and thoughts about the organization: * >>> >>> 1. I strongly prefer to order the tree at the first level semantically >>> (ers/ltap/...) and then by module version (module88/module97/...). In >>> my opinion the semantics is more important than the syntax version >>> (and at a later point in time new syntax might be presented for an >>> existing semantic) >>> >>> >> I can live with that. except that I don't see a need for 97 because it >> is already wrong. >> > > I suppose you would prefer just "module" instead of "module97", correct? > >From my belief I see no reason to not treat both modules (the 88 and > current/97) equally, which would result in module88 and module97 or > module2002. (but to be honest I have no strong feelings about this). > Yes, just module. > >>> 2. By intent, we ordered module88 and module97 with the numbers >>> growing with the ASN.1 syntax number s , so 1 and 2 . (the higher the >>> number the later and more current the version) . >>> >>> >> Ok. >> >>> With the following reason s : 1) we should list both modules sheer >>> technically and that is as 88 and 97 compliant - there may be other >>> changes to ASN.1 in the future and so there may be other newer modules >>> (maybe " module2010 " ) in the future. A nd 2) in case there m ight be >>> newer module version s (let's say " module2010 " ) in the future, I'd >>> prefer them to appear in chronological order , so that everyon e can >>> deduct that the higher numbered versions are the more recent ones and >>> choose these . ( A lthough I know that this can not be guaranteed) >>> (comment: F or this reason we chose module88(1) and module97(2) and >>> not module9 7 (1). ) >>> >>> >> Using 97 is not a good choice because it is wrong already. >> > > Just to help me understand: you propose to name it instead as "module" - not > module2002 or module2005? > Yes. > >> I don't >> really think that any of our versions of modules will require: >> If there is a change to ltap or ers that makes use of let's say a new >> element in AuthenticationFramework of version 22 which >> is based on a new SYNTAX feature in ASN.1, then we still have to >> downgrade the thingy to the 88 version. >> Do we also want to downgrade it to 93 like the pkix 93 version have >> removed the parameterized types. Already >> making the 88 version (in pkix) is a horrible task, I'd prefer to >> develop a free asn.1 tool instead. And even PKIX gave >> up the 93 version. >> > > *smiling* Oh yes, I would definitely prefer to have the free and fully > comprehensive asn.1 compiler - and even more not to have to provide and > stick to old asn.1 in parallel, simply doubling our work. ;-) > Right. But DOUBLE, not TRIPLE. > But until we have one which is accepted by all, I need to keep the door open > to at least theoretically be able to cover multiple versions of asn.1 in > parallel. > But then you already have a problem indicating which modulennnn you actually have, by looking into AuthenticationFramework, InformationFramework etc this is not so easy, there are more than 50 modules to include. I'd rather see module indicating current and then maybe module88 or modulennnn in case that this may arise. I don't think that the ITU will again modify ASN.1 and delete features, well, I am 100% sure. At least I don't think that they will remove a feature that was actually useful, implementable, implemented and used. > >>> I hope these reasons are comprehensible . As I said, if you have >>> questions, comments or concerns please send them to the mailing-list ( >>> or contact Carl and me directly ) . >>> >>> >> After this lengthy text, I can provide the module headers. >> I think that we basically agree with the concept with some small differences. --------------ms000805050609050902030601 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 BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+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 S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDEyMTI0MzIyWjAjBgkqhkiG9w0B CQQxFgQUDuzDmPUsnsecHLGCqAs9yfYlg1swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGARa1IsoBw2tBFI9J7 yMP6zcJAJwEvS9bR6YnNbdZQP7AKy1uf9V3lIbQj6HLubAxsU7/eu6OGx5S4byYbqse95a4q t+DkWxmLPS2IxNtcDkyZcYLKCKRztoDAHsF5tQVMrjitVISjvpY2XqOBSJTu9FMgpOKxVLbt kG0zT2d8XXYAAAAAAAA= --------------ms000805050609050902030601-- 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 l3AJ3OBf081436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 12:03: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 l3AJ3OWF081435; Tue, 10 Apr 2007 12:03: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 l3AJ3125081427 for ; Tue, 10 Apr 2007 12:03: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 l3AJ2utu002550; Tue, 10 Apr 2007 21:02:57 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LTANS: clean-up of ltans oid structure Date: Tue, 10 Apr 2007 21:02:55 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A7_01C77BB3.9C0600B0" Message-ID: <2666EB2A846BAC4BB2D7F593301A7868D3EAD9@MUCXGC2.opentext.net> In-Reply-To: <46161938.90102@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: clean-up of ltans oid structure Thread-Index: Acd4MihEMX5KqglpTP68J+KOHvZUJwDZ+rjQ From: "Tobias Gondrom" To: "Peter Sylvester" Cc: , "Carl Wallace" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C77BB3.9C0600B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Peter, my comments inline. > I got the ideas of your changes but there are some errors. > > The basic change is inverting the tree between asn1 syntax version > and module prefix. That's ok, but I disagree with the indication > of 97 syntax. This is a rathole. I do not understand this metaphor and I do not see a problem with the 97 suffix. From my belief I see no reason to not treat both modules (the 88 and current/97) equally, which would result in module88 and module97 or module2002. (But to be honest I have no strong feelings about this.) > The following also does not make a clear distinction between > > id-something --- usable in encodings as encoded object identifiers. > something --- a GLOBAL identifier identifying a module. > Something --- definition of a module > > and which are GLOBAL and which are just local for convenience > inside each module. > > To get inspired by the ITU definitions, there is the following convention > > When "Something" (like AuthenticationFramework) is a module, > then "something" is an OBJECT IDENTIFIER value notation that > of that thing and it is defined in a UsefulDefinitions module. > > Thus the global OBJECT IDENTFIER value noration "ers" should not > be the tree root of ers but the Ers module value. If one needs ers/ltans > etc in IDs then call the global value definition > > id-ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > id-ers OBJECT IDENTIFIER ::= { id-ltans 1 } - Evidence Record Syntax I do not understand the need for the id-prefix for ltans and ers. My proposal is guided by the structures as they are also used by e.g. PKIX and IPSec. Both only use a small subset of their ids with this prefix: PKIX: http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.5.5.7&action=displa y IPSec as well: http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.5.5.8&action=displa y So I do not join your proposed convention. Could you maybe provide a link to the resource where this convention is described? So far I can not see a problem with the syntax without the prefix: ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > Tobias Gondrom wrote: > > > > Hello, > > > > thanks to Peter ' s initiative, Carl and I worked again through the > > LTANS OID structure and want to use the last opportunity (before ERS > > is published) to clean a few things up . In the past we added a few > > OIDs to the LTANS tree which were onl y referenced in drafts but later > > removed again. So now is the good time to clean this up. > > > > Based on Peter's proposal but not completely following it, we plan to > > use the following structure . > > > > At the bottom I give some reasons why Carl and I c hose the structure > > as listed below. > > > > P lease take a look at it and post comments or objections to the > > mailing-list until April-12 . > > > > ( comment: it ' s only the structure of the LTANS OID number tree with > > no real impact , so a short review time should be sufficient . ) > > > > > > > > * But now to the structure: * > > > > Starting with the g eneral prefix: > > > > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > > > below this level we will have: > > > > ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > > > > ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol > > > > I am not sure WHERE you want to define these GLOBAL identifiers. Inside > each of the ltans modules? > We should register these GLOBAL identifiers in our OID registry and also define them inside the according LTANS RFCs. > > And below ers and ltap the different module versions: > > > > module88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax > > > > module97 OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax > > > > module88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax > > > > module97 OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax > > > You are confusing something. You don't define such "GLOBAL" objects > anywhere. > You just define a module with a version like > ers88 OBJECT IDENTIFIER ::= { ers module88(1) 1 } > > Or, This does not define global identifiers. You would need to say > somethiung like > > ers88-moduleprefix OBJECT IDENTIFIER ::= { ers module88(1) } - Module > ASN.1 1988-Syntax > ers-moduleprefix OBJECT IDENTIFIER ::= { ers module97(2) } - Module > ASN.1 1991-Syntax > etap88-moduleprefix OBJECT IDENTIFIER ::= { ltap module88(1) } - Module > ASN.1 1988-Syntax > etap-moduleprefix OBJECT IDENTIFIER ::= { ltap module97(2) } - Module > ASN.1 1991-Syntax > > But these definitions are not needed in any case because the only places > where they are used > are the module definition itself or imports which also don't need the > prefix. > OK, maybe my description has been a bit chaotic and formal. The intention was to clearly specify the module based on the type (ERS or LTAP) and the module syntax (88-conform, 97-conform, ...) In comparison to your proposal from march-04 just in the switched order (instead of module-syntax and below that the spec). Citing your email: " a general prefix for ltans which is iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) - then two identifiers for modules module(1) module88(2) id-em(3) ** renumbered ** in order to clearly separate the same modules in different syntax. - under both trees use the same numbers for the corresponding modules. e.g. module(1) ers(1) module88(2) ers(1)" Instead my proposal would be described in your writing style: Of course the same general prefix for ltans which is iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) - then identifiers for specifications ers(1) ltap(2) - under both trees use growing numbers for the corresponding module syntaxes. e.g. ers(1) module88(1) ers(1) module97(2) ltap(2) module88(1) ltap(2) module97(2) > > > And below this , for both ers and ltap each: > > > > (also inspired by your LTAP draft , we will add a version number for > > the module - just in case we later need to update it - citing the LTAP > > draft: version numbers of 0 relate to all draft status, version number > > is 1 with the release of the RFC): > > > > version OBJECT IDENTIFIER ::= { module88 1 } - Version number for this > > RFC > > > > version OBJECT IDENTIFIER ::= { module97 1 } - Version number for this > RFC > > > You don' want such definitions at all. > > > > Or to be more precise: > > > > For ERS: > > > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) > > module88(1) version(1) } - Version number for ERS RFC > > > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) > > module97(2) version(1) } - Version number for ERS RFC > > > > and for LTAP: > > > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) > > module88(1) version(1) } - Version number for LTAP RFC > > > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) > > module97(2) version(1) } - Version number for LTAP RFC > > > > > This doesn't make sense. What you want to define above is not a version > but one module for each asn1 syntax. > > ers88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } - > Version number for ERS RFC > ers OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 } - > Version number for ERS RFC > ltap88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module88(1) 1 } > - Version number for ERS RFC > ltap OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module(2) 1 } - > Version number for ERS RFC Ok, I see. My initial define of "version" was an unlucky naming. So we are on the same page here. But I currently still do not agree with the other changes you proposed above (renaming module97 to module). I would still propose the following structure: ers88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } - Version number for ERS RFC ers97 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module97(2) 1 } - Version number for ERS RFC ltap88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module88(1) 1 } - Version number for ERS RFC ltap97 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module97(2) 1 } - Version number for ERS RFC > > where ers corresponds to a module > > Ers MODULE iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 > > > so you could have > > IMPORT ers FROM LtansUsefulDefinitions iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) > usefuldefinitions(0) module(2) 1 > > whatever FROM ers > > ; > > I prefer Ers and Ltap instead of Ers97 and Ltap97. Indeed, each > correction to asn.1 may result > in an impossiblity to use an existing compiler. But I don't think that > it is a good solution to > make a full two dimensional matriw of versions aof a module and of all > possible technical > amendments of asn.1. In fact I see no technical problem with such a matrix. (and we do not need to fill all the filed of the matrix, but only the ones which are really used/specified) (and btw. I understood your proposal from March-04 also as such a matrix.) Citing: " ERS iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) module(1) ers(1) 1 ERS iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) module88(1) ers(1) 1 LTAP iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) module(1) ltap(2) 1 LTAP iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) module88(1) ltap(2) 1" > Ltap and Ers should import from the Authentication/InformationFramework > 5 modules which > are from 2005. They are the most current. There should not be hint about > a particular version. > > Also Ers88 etc is NOT needed, both modules can be named Ers. But it improves readability greatly to extend the name of the modules with the syntax-version. > > And at last, the EncryptionMethod oids from the ERS draft : > > > > id- em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method > > > > or written in the long form: > > > > id-em OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > > internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) } > > > > and below that, the two identifiers used in ERS: > > > > id- er-internal OBJECT IDENTIFIER ::= { id- em 1} > > > > id- er-external OBJECT IDENTIFIER ::= { id- em 2} > > > > ( this is only _ / renaming / _ the existing identifiers, describing > > the selection method when using ER S with CMS - this is only replacing > > the existing identifier _ / names / _ (nothing else!) > > > > Old names were: id-EvidenceRecord-Internal and > > id-EvidenceRecord-External - new names: id- er-internal and id- > > er-external > > > > > > > * There are several OIDs that ** have only been used ** in ** old ** > > er ** and ** already ** expired versions of ** drafts; ** we will ** > > actively state that they be removed ** from the registry ** . ** * > > These are: id-ct, id-em, id-mod-ers, id-evidence-record, > > id-em-env-data. ** > > > > * Reasons and thoughts about the organization: * > > > > 1. I strongly prefer to order the tree at the first level semantically > > (ers/ltap/...) and then by module version (module88/module97/...). In > > my opinion the semantics is more important than the syntax version > > (and at a later point in time new syntax might be presented for an > > existing semantic) > > > I can live with that. except that I don't see a need for 97 because it > is already wrong. I suppose you would prefer just "module" instead of "module97", correct? >From my belief I see no reason to not treat both modules (the 88 and current/97) equally, which would result in module88 and module97 or module2002. (but to be honest I have no strong feelings about this). > > > 2. By intent, we ordered module88 and module97 with the numbers > > growing with the ASN.1 syntax number s , so 1 and 2 . (the higher the > > number the later and more current the version) . > > > Ok. > > > > With the following reason s : 1) we should list both modules sheer > > technically and that is as 88 and 97 compliant - there may be other > > changes to ASN.1 in the future and so there may be other newer modules > > (maybe " module2010 " ) in the future. A nd 2) in case there m ight be > > newer module version s (let's say " module2010 " ) in the future, I'd > > prefer them to appear in chronological order , so that everyon e can > > deduct that the higher numbered versions are the more recent ones and > > choose these . ( A lthough I know that this can not be guaranteed) > > (comment: F or this reason we chose module88(1) and module97(2) and > > not module9 7 (1). ) > > > Using 97 is not a good choice because it is wrong already. Just to help me understand: you propose to name it instead as "module" - not module2002 or module2005? > I don't > really think that any of our versions of modules will require: > If there is a change to ltap or ers that makes use of let's say a new > element in AuthenticationFramework of version 22 which > is based on a new SYNTAX feature in ASN.1, then we still have to > downgrade the thingy to the 88 version. > Do we also want to downgrade it to 93 like the pkix 93 version have > removed the parameterized types. Already > making the 88 version (in pkix) is a horrible task, I'd prefer to > develop a free asn.1 tool instead. And even PKIX gave > up the 93 version. *smiling* Oh yes, I would definitely prefer to have the free and fully comprehensive asn.1 compiler - and even more not to have to provide and stick to old asn.1 in parallel, simply doubling our work. ;-) But until we have one which is accepted by all, I need to keep the door open to at least theoretically be able to cover multiple versions of asn.1 in parallel. > > > I hope these reasons are comprehensible . As I said, if you have > > questions, comments or concerns please send them to the mailing-list ( > > or contact Carl and me directly ) . > > > After this lengthy text, I can provide the module headers. ------=_NextPart_000_00A7_01C77BB3.9C0600B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA0MTAxOTAyNTVaMCMGCSqGSIb3DQEJBDEWBBTFaoVDWs36+9hedVCuCEos/Oy3 PzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAFykdgXucsEf9/jMi6gCrCBYFRUqp30b92rd5AjAtyek/3DKH2RwuahCh1jp 3NOIcs8P0NbJGar5h0nnZ7VgCbO9PwHuP39RWeaTduln4geRY2Hgj4QTUHS6GYmh2CYNB1+0TJjb vshvtITthBdOOXxsQ2HjtaMldWE1GaetjZ+zfdyuyjmBmRb3TJ4ys48a4BxHLw2+BD3fYuPC47MI luANtczP4Vtaunsx4pVCI2x+qXAtleYxhUhfg2sDnqhZf4NzQqwN0sGuWVd6cQMyvo0jif6IatBT xLK8oT3XD60f0WLf8bA7KYO1MlpLo9WI3/bF0VcN/ffFnGa7p+gN+t8oiHVUnJ/Jv8NpyDGAVIJ2 GTxINSL34KHGV0kRf7/TY+u+wbrs6gTwcMOcSgZJFU6HsjVrxL6nOhBImwqmNvXn1yBz3h2xq7RS sW7tFCt0aTx6o2EN46Zi5VMQ8yATFQKABtaV7hfz+ewa+vQtp9/v50iUBP1VHdmhleC06Qlb06ZC FK+KB8qIOx+MuLgbgGK2lXB83CHeyzfjg/be444VmlSyaXn2ww2+urESlLEynsm9674s6MdkO0td U2uo3rvwtvDBICy9fA4r8zJaCL9yZvwGFHbs0GqGDV1nAKi3tkuVGSn3zGQRlndmzGQJcIg06vRe y/psJoVCnDH4ghMQAAAAAAAA ------=_NextPart_000_00A7_01C77BB3.9C0600B0-- 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 l3A9isvq034802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 02:44: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 l3A9isCN034801; Tue, 10 Apr 2007 02:44: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3A9iV3h034777 for ; Tue, 10 Apr 2007 02:44:52 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA22914 for ; Tue, 10 Apr 2007 11:49:16 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007041011450213:7539 ; Tue, 10 Apr 2007 11:45:02 +0200 Date: Tue, 10 Apr 2007 11:44:26 +0200 From: "Denis Pinkas" To: "ietf-ltans@imc.org" Subject: Re: I-D ACTION:draft-ietf-ltans-ers-12.txt X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 10/04/2007 11:45:02, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 10/04/2007 11:45:03, Serialize complete at 10/04/2007 11:45:03 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l3A9is3h034793 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Comments on draft-ietf-ltans-ers-12 Major comments 1 to 4 The current syntax is defined as: EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryptionInfo [1] EncryptionInfo OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence } ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, attributes [1] Attributes OPTIONAL, reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} Attributes ::= SET SIZE (1..MAX) OF Attribute PartialHashtree ::= SEQUENCE OF OCTET STRING There are several problems with this syntax: 1) Within ArchiveTimeStamp, the timeStamp element is mandatory. When an ArchiveTimeStampChain is being built, several time stamp tokens will be needed whereas only one time stamp token at the top of the hierarchy is really needed. It should be possible to have a timeStamp element present in the EvidenceRecord structure. 2) When the Evidence Record is stored separate from the archived data, the syntax does not allow to interoperate, since there is no way to know how to build or reconstruct the right sequence of PartialHashtrees. PartialHashtree ::= SEQUENCE OF OCTET STRING One way to solve this issue would be to add the name of each element used to construct the hash tree, so that that name can be used to locate and fetch the corresponding file. 3) cryptoInfos and encryptionInfo are currently defined as follows: CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute EncryptionInfo ::= SEQUENCE { encryptionInfoType OBJECT IDENTIFIER, encryptionInfoValue ANY DEFINED BY encryptionInfoType } cryptoInfos and encryptionInfo do not allow any kind of interoperability. It would more appropriate to define generic extensions, like for certificates and CRLs: extensions Extensions OPTIONAL, 4) The current syntax does not allow : - an unlimited number of levels in the tree (only three levels are possible); - to identify a node; - to incorporate into an Evidence Record, previously computed Evidence Records; - to add new extensions; - to stack time-stamp tokens and CRLs. The following syntax would solve the issue: EvidenceRecord::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, reducedHashtree ReducedHashtree OPTIONAL, otherEvidenceRecords SEQUENCE OF EvidenceRecord OPTIONAL, extensions Extensions OPTIONAL, timeStamps SEQUENCE OF TimeStamp } ReducedHashTree ::= SEQUENCE { hashTreeElements SEQUENCE OF HashTreeElement, reducedHashTree SEQUENCE OF ReducedHashTree OPTIONAL } HashTreeElement ::= SEQUENCE { node BOOLEAN DEFAULT FALSE, digestAlgorithm AlgorithmIdentifier, elementHash OCTET STRING, elementName GeneralName OPTIONAL, } TimeStamp ::= SEQUENCE { tst ContentInfo, crl CertificateList OPTIONAL } Sections 3.2 and 3.3 would need to be rewritten. Minor comment The word non-repudiation is misused in several places. For example, on page 6: “ each Archive Timestamp preserves non-repudiation of the previous Archive Timestamp” . There is no need to use the word non-repudiation here, since the following sentence is sufficient: “ each new time-stamp maintains the validity of the previous time-stamp”. Denis ================================================================ > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. > > Title : Evidence Record Syntax (ERS) > Author(s) : R. Brandner, et al. > Filename : draft-ietf-ltans-ers-12.txt > Pages : 34 > Date : 2007-3-8 > > In many scenarios, users must be able prove the existence and > integrity of data, including digitally signed data, in a common and > reproducible way over a long and possibly undetermined period of > time. This document specifies the syntax and processing of an > Evidence Record, a structure designed to support long-term non- > repudiation of existence of data. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-ltans-ers-12.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ltans-ers-12.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > Content-Type: text/plain > Content-ID: < 2007-3-8122718.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-ltans-ers-12.txt > Regards, Denis Pinkas 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 l369wj1f058301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 02:58: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 l369wjkq058300; Fri, 6 Apr 2007 02:58: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 l369wNm3058277 for ; Fri, 6 Apr 2007 02:58: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 l369wH522660; Fri, 6 Apr 2007 11:58:17 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Fri, 6 Apr 2007 11:58:18 +0200 (MET DST) Message-ID: <46161938.90102@edelweb.fr> Date: Fri, 06 Apr 2007 11:56:08 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, Carl Wallace Subject: Re: LTANS: clean-up of ltans oid structure References: <2666EB2A846BAC4BB2D7F593301A7868D3E912@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868D3E912@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020709060202050803030907" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020709060202050803030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I got the ideas of your changes but there are some errors. The basic change is inverting the tree between asn1 syntax version and module prefix. That's ok, but I disagree with the indication of 97 syntax. This is a rathole. The following also does not make a clear distinction between id-something --- usable in encodings as encoded object identifiers. something --- a GLOBAL identifier identifying a module. Something --- definition of a module and which are GLOBAL and which are just local for convenience inside each module. To get inspired by the ITU definitions, there is the following convention When "Something" (like AuthenticationFramework) is a module, then "something" is an OBJECT IDENTIFIER value notation that of that thing and it is defined in a UsefulDefinitions module. Thus the global OBJECT IDENTFIER value noration "ers" should not be the tree root of ers but the Ers module value. If one needs ers/ltans etc in IDs then call the global value definition id-ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } id-ers OBJECT IDENTIFIER ::= { id-ltans 1 } - Evidence Record Syntax Tobias Gondrom wrote: > > Hello, > > thanks to Peter ’ s initiative, Carl and I worked again through the > LTANS OID structure and want to use the last opportunity (before ERS > is published) to clean a few things up . In the past we added a few > OIDs to the LTANS tree which were onl y referenced in drafts but later > removed again. So now is the good time to clean this up. > > Based on Peter's proposal but not completely following it, we plan to > use the following structure . > > At the bottom I give some reasons why Carl and I c hose the structure > as listed below. > > P lease take a look at it and post comments or objections to the > mailing-list until April-12 . > > ( comment: it ’ s only the structure of the LTANS OID number tree with > no real impact , so a short review time should be sufficient . ) > > > > * But now to the structure: * > > Starting with the g eneral prefix: > > ltans OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) ltans(11) } > > below this level we will have: > > ers OBJECT IDENTIFIER ::= { ltans 1 } - Evidence Record Syntax > > ltap OBJECT IDENTIFIER ::= { ltans 2 } - Long Term Archive Protocol > I am not sure WHERE you want to define these GLOBAL identifiers. Inside each of the ltans modules? > And below ers and ltap the different module versions: > > module88 OBJECT IDENTIFIER ::= { ers 1 } - Module ASN.1 1988-Syntax > > module97 OBJECT IDENTIFIER ::= { ers 2 } - Module ASN.1 1997-Syntax > > module88 OBJECT IDENTIFIER ::= { ltap 1 } - Module ASN.1 1988-Syntax > > module97 OBJECT IDENTIFIER ::= { ltap 2 } - Module ASN.1 1997-Syntax > You are confusing something. You don't define such "GLOBAL" objects anywhere. You just define a module with a version like ers88 OBJECT IDENTIFIER ::= { ers module88(1) 1 } Or, This does not define global identifiers. You would need to say somethiung like ers88-moduleprefix OBJECT IDENTIFIER ::= { ers module88(1) } - Module ASN.1 1988-Syntax ers-moduleprefix OBJECT IDENTIFIER ::= { ers module97(2) } - Module ASN.1 1991-Syntax etap88-moduleprefix OBJECT IDENTIFIER ::= { ltap module88(1) } - Module ASN.1 1988-Syntax etap-moduleprefix OBJECT IDENTIFIER ::= { ltap module97(2) } - Module ASN.1 1991-Syntax But these definitions are not needed in any case because the only places where they are used are the module definition itself or imports which also don't need the prefix. > And below this , for both ers and ltap each: > > (also inspired by your LTAP draft , we will add a version number for > the module - just in case we later need to update it - citing the LTAP > draft: version numbers of 0 relate to all draft status, version number > is 1 with the release of the RFC): > > version OBJECT IDENTIFIER ::= { module88 1 } - Version number for this > RFC > > version OBJECT IDENTIFIER ::= { module97 1 } - Version number for this RFC > You don' want such definitions at all. > > Or to be more precise: > > For ERS: > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) > module88(1) version(1) } - Version number for ERS RFC > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) > module97(2) version(1) } - Version number for ERS RFC > > and for LTAP: > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) > module88(1) version(1) } - Version number for LTAP RFC > > version OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) > module97(2) version(1) } - Version number for LTAP RFC > > This doesn't make sense. What you want to define above is not a version but one module for each asn1 syntax. ers88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module88(1) 1 } - Version number for ERS RFC ers OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 } - Version number for ERS RFC ltap88 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module88(1) 1 } - Version number for ERS RFC ltap OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(2) module(2) 1 } - Version number for ERS RFC where ers corresponds to a module Ers MODULE iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) module(2) 1 so you could have IMPORT ers FROM LtansUsefulDefinitions iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) usefuldefinitions(0) module(2) 1 whatever FROM ers ; I prefer Ers and Ltap instead of Ers97 and Ltap97. Indeed, each correction to asn.1 may result in an impossiblity to use an existing compiler. But I don't think that it is a good solution to make a full two dimensional matriw of versions aof a module and of all possible technical amendments of asn.1. Ltap and Ers should import from the Authentication/InformationFramework 5 modules which are from 2005. They are the most current. There should not be hint about a particular version. Also Ers88 etc is NOT needed, both modules can be named Ers. > And at last, the EncryptionMethod oids from the ERS draft : > > id- em OBJECT IDENTIFIER ::= { ers 3 } - Encryption Method > > or written in the long form: > > id-em OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) } > > and below that, the two identifiers used in ERS: > > id- er-internal OBJECT IDENTIFIER ::= { id- em 1} > > id- er-external OBJECT IDENTIFIER ::= { id- em 2} > > ( this is only _ / renaming / _ the existing identifiers, describing > the selection method when using ER S with CMS - this is only replacing > the existing identifier _ / names / _ (nothing else!) > > Old names were: id-EvidenceRecord-Internal and > id-EvidenceRecord-External – new names: id- er-internal and id- > er-external > > > * There are several OIDs that ** have only been used ** in ** old ** > er ** and ** already ** expired versions of ** drafts; ** we will ** > actively state that they be removed ** from the registry ** . ** * > These are: id-ct, id-em, id-mod-ers, id-evidence-record, > id-em-env-data. ** > > * Reasons and thoughts about the organization: * > > 1. I strongly prefer to order the tree at the first level semantically > (ers/ltap/...) and then by module version (module88/module97/...). In > my opinion the semantics is more important than the syntax version > (and at a later point in time new syntax might be presented for an > existing semantic) > I can live with that. except that I don't see a need for 97 because it is already wrong. > 2. By intent, we ordered module88 and module97 with the numbers > growing with the ASN.1 syntax number s , so 1 and 2 . (the higher the > number the later and more current the version) . > Ok. > > With the following reason s : 1) we should list both modules sheer > technically and that is as 88 and 97 compliant - there may be other > changes to ASN.1 in the future and so there may be other newer modules > (maybe “ module2010 ” ) in the future. A nd 2) in case there m ight be > newer module version s (let's say “ module2010 ” ) in the future, I'd > prefer them to appear in chronological order , so that everyon e can > deduct that the higher numbered versions are the more recent ones and > choose these . ( A lthough I know that this can not be guaranteed) > (comment: F or this reason we chose module88(1) and module97(2) and > not module9 7 (1). ) > Using 97 is not a good choice because it is wrong already. I don't really think that any of our versions of modules will require: If there is a change to ltap or ers that makes use of let's say a new element in AuthenticationFramework of version 22 which is based on a new SYNTAX feature in ASN.1, then we still have to downgrade the thingy to the 88 version. Do we also want to downgrade it to 93 like the pkix 93 version have removed the parameterized types. Already making the 88 version (in pkix) is a horrible task, I'd prefer to develop a free asn.1 tool instead. And even PKIX gave up the 93 version. > I hope these reasons are comprehensible . As I said, if you have > questions, comments or concerns please send them to the mailing-list ( > or contact Carl and me directly ) . > After this lengthy text, I can provide the module headers. --------------ms020709060202050803030907 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 BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+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 S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA2MDk1NjA4WjAjBgkqhkiG9w0B CQQxFgQUo3uFwgnP63+KIHEJBCt733A2PjQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAW+FckGQhm7tNqsgY NOCdyJV/nHJtYI1uDbQ24CP33xVj6nwBC1Ob1PtzOGU1NU/FbU1pmCQHCVBIrFAd1KV8b2r/ dkqe2KCDCjKyqDhgE7p5i1XJ3rYkl3DBPZE6FiTM0FppNAeelmsoLWBUKzfCFAP+Ob7gSosP i7sN4qnGOkMAAAAAAAA= --------------ms020709060202050803030907-- 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 l35HA5Ek069084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 10:10:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l35HA4iF069083; Thu, 5 Apr 2007 10:10:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35H9glo068959 for ; Thu, 5 Apr 2007 10:10:03 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l35H9Nlk026724; Thu, 5 Apr 2007 19:09: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: multipart/alternative; boundary="----_=_NextPart_001_01C777A5.283957B3" Subject: LTANS: clean-up of ltans oid structure Date: Thu, 5 Apr 2007 19:09:21 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868D3E912@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: clean-up of ltans oid structure Thread-Index: Acd3pSdo5jSuA+K8SLyCZOR9k87WoA== 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_01C777A5.283957B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, thanks to Peter's initiative, Carl and I worked again through the LTANS = OID structure and want to use the last opportunity (before ERS is = published) to clean a few things up. In the past we added a few OIDs to = the LTANS tree which were only referenced in drafts but later removed = again. So now is the good time to clean this up.=20 Based on Peter's proposal but not completely following it, we plan to = use the following structure. At the bottom I give some reasons why Carl and I chose the structure as = listed below. Please take a look at it and post comments or objections to the = mailing-list until April-12.=20 (comment: it's only the structure of the LTANS OID number tree with no = real impact, so a short review time should be sufficient.) But now to the structure: Starting with the general prefix:=20 ltans OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3)=20 dod(6) internet(1) security(5) mechanisms(5) ltans(11) } below this level we will have: ers OBJECT IDENTIFIER ::=3D { ltans 1 } - Evidence Record Syntax ltap OBJECT IDENTIFIER ::=3D { ltans 2 } - Long Term Archive Protocol =20 And below ers and ltap the different module versions: module88 OBJECT IDENTIFIER ::=3D { ers 1 } - Module ASN.1 1988-Syntax module97 OBJECT IDENTIFIER ::=3D { ers 2 } - Module ASN.1 1997-Syntax module88 OBJECT IDENTIFIER ::=3D { ltap 1 } - Module ASN.1 1988-Syntax module97 OBJECT IDENTIFIER ::=3D { ltap 2 } - Module ASN.1 1997-Syntax And below this, for both ers and ltap each: (also inspired by your LTAP draft, we will add a version number for the = module - just in case we later need to update it - citing the LTAP = draft: version numbers of 0 relate to all draft status, version number = is 1 with the release of the RFC): version OBJECT IDENTIFIER ::=3D { module88 1 } - Version number for = this RFC version OBJECT IDENTIFIER ::=3D { module97 1 } - Version number for = this RFC Or to be more precise: For ERS:=20 version OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) = dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) = module88(1) version(1) } - Version number for ERS RFC version OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) = dod(6) internet(1) security(5) mechanisms(5) ltans(11) ers(1) = module97(2) version(1) } - Version number for ERS RFC and for LTAP: version OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) = dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) = module88(1) version(1) } - Version number for LTAP RFC version OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) = dod(6) internet(1) security(5) mechanisms(5) ltans(11) ltap(1) = module97(2) version(1) } - Version number for LTAP RFC =20 And at last, the EncryptionMethod oids from the ERS draft: id-em OBJECT IDENTIFIER ::=3D { ers 3 } - Encryption Method or written in the long form:=20 id-em OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) = internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) }=20 and below that, the two identifiers used in ERS:=20 id-er-internal OBJECT IDENTIFIER ::=3D {id-em 1} id-er-external OBJECT IDENTIFIER ::=3D {id-em 2} (this is only _renaming_ the existing identifiers, describing the = selection method when using ERS with CMS - this is only replacing the = existing identifier _names_ (nothing else!)=20 Old names were: id-EvidenceRecord-Internal and = id-EvidenceRecord-External - new names: id-er-internal and = id-er-external =20 There are several OIDs that have only been used in older and already = expired versions of drafts; we will actively state that they be removed = from the registry. These are: id-ct, id-em, id-mod-ers, = id-evidence-record, id-em-env-data. =20 Reasons and thoughts about the organization:=20 1. I strongly prefer to order the tree at the first level semantically = (ers/ltap/...) and then by module version (module88/module97/...). In my = opinion the semantics is more important than the syntax version (and at = a later point in time new syntax might be presented for an existing = semantic) 2. By intent, we ordered module88 and module97 with the numbers growing = with the ASN.1 syntax numbers, so 1 and 2. (the higher the number the = later and more current the version).=20 With the following reasons: 1) we should list both modules sheer = technically and that is as 88 and 97 compliant - there may be other = changes to ASN.1 in the future and so there may be other newer modules = (maybe "module2010") in the future. And 2) in case there might be newer = module versions (let's say "module2010") in the future, I'd prefer them = to appear in chronological order, so that everyone can deduct that the = higher numbered versions are the more recent ones and choose these. = (Although I know that this can not be guaranteed) (comment: For this = reason we chose module88(1) and module97(2) and not module97(1).) I hope these reasons are comprehensible. As I said, if you have = questions, comments or concerns please send them to the mailing-list (or = contact Carl and me directly).=20 Thanks,=20 Tobias Chair of LTANS __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C777A5.283957B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS: clean-up of ltans oid structure

Hello,

thanks to Peter’s initiative, Carl and I worked again through = the LTANS OID = structure = and want to use the last opportunity (before ERS is published) to clean a few things up. = In the past we added a few OIDs to the LTANS tree which were = only referenced in drafts but later removed again. So now is the good time to clean this = up.

Based = on Peter's proposal but not completely following it, we plan = to use the following structure.

At = the bottom I give some reasons why Carl and I chose the structure as listed below.

Please take a look at it and post comments or objections = to the mailing-list = until April-12.

(comment: it’s only the structure of the LTANS OID number tree = with no real impact, = so a short review time should be sufficient.)



But now to the structure:

Starting with the general prefix:

ltans = OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) =

         &nbs= p;    dod(6) internet(1) security(5) mechanisms(5) = ltans(11) }

below = this level we will = have:

ers = OBJECT IDENTIFIER ::=3D { ltans 1 }   - Evidence Record = Syntax

ltap = OBJECT IDENTIFIER ::=3D { ltans 2 }  - Long Term Archive = Protocol

 

And = below ers and ltap the different module versions:

module88 OBJECT IDENTIFIER ::=3D { ers 1 }   - = Module ASN.1 1988-Syntax

module97 OBJECT IDENTIFIER ::=3D { ers 2 }   - = Module ASN.1 1997-Syntax

module88 OBJECT IDENTIFIER ::=3D { ltap 1 }   - = Module ASN.1 1988-Syntax

module97 OBJECT IDENTIFIER ::=3D { ltap 2 }   - = Module ASN.1 1997-Syntax

And = below this, = for both ers and ltap each:

(also = inspired by your LTAP draft, = we will add a version number for the module - just in = case we later need to update it - citing the = LTAP draft: version numbers of 0 relate to all draft status, version = number is 1 with the release of the RFC):

version OBJECT IDENTIFIER ::=3D { module88 1 = }   - Version number for this RFC

version OBJECT IDENTIFIER ::=3D { module97 1 = }   - Version number for this RFC

Or to = be more precise:

For = ERS:

version OBJECT IDENTIFIER ::=3D { iso(1) = identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) = ltans(11) ers(1) module88(1) version(1) }   - Version number = for ERS RFC

version OBJECT IDENTIFIER ::=3D { iso(1) = identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) = ltans(11) ers(1) module97(2) version(1) }   - Version number = for ERS RFC

and = for LTAP:

version OBJECT IDENTIFIER ::=3D { iso(1) = identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) = ltans(11) ltap(1) module88(1) version(1) }   - Version number = for LTAP RFC

version OBJECT IDENTIFIER ::=3D { iso(1) = identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) = ltans(11) ltap(1) module97(2) version(1) }   - Version number = for LTAP RFC

 

And = at last, the EncryptionMethod oids from the ERS draft:

id-em = OBJECT IDENTIFIER ::=3D { ers 3 = }  - Encryption Method

or = written in the long form:

id-em = OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) = internet(1) security(5) mechanisms(5) ltans(11) ers(1) id-em(3) } =

and = below that, the = two identifiers used in ERS:

id-er-internal OBJECT IDENTIFIER ::=3D {id-em = 1}

id-er-external OBJECT IDENTIFIER ::=3D {id-em = 2}

(this is only _renaming_ = the existing identifiers, describing the selection method when using = ERS with CMS - = this is only replacing the existing identifier _names_ = (nothing else!)

Old = names were: id-EvidenceRecord-Internal and id-EvidenceRecord-External – = new names: id-er-internal and id-er-external


 

There are several OIDs that have only been = used in older and already expired versions = of drafts; we = will actively state that they be = removed from the registry. These are: id-ct, id-em, id-mod-ers, id-evidence-record, = id-em-env-data.

 

Reasons and thoughts about the organization: =

1. I strongly prefer to order the tree at the first level = semantically (ers/ltap/...) and then by module version = (module88/module97/...). In my opinion the semantics is more important = than the syntax version (and at a later point in time new syntax might be = presented for an existing semantic)

2. By intent, we = ordered module88 and module97 with the numbers growing with the ASN.1 = syntax = numbers, = so 1 and 2. = (the higher the number the later and more current the version).

With = the following reasons: = 1) we should list both modules sheer technically and that = is as 88 and 97 compliant - there may be other changes = to ASN.1 in the future and so there may be other newer modules (maybe “module2010”) in the future. And = 2) in case there might = be newer module versions = (let's say “module2010”) = in the future, I'd prefer them to appear in chronological order, so that everyone = can deduct that the higher numbered versions are the more recent = ones = and choose these. (Although I know that this can not be = guaranteed) (comment: For = this reason we chose module88(1) and module97(2) and not module97(1).)

I = hope these reasons are comprehensible. As I said, if you have questions, comments or = concerns please send them to the mailing-list (or = contact Carl and me directly).

Thanks,

Tobias

Chair = of LTANS



__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift = 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | = Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 = 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C777A5.283957B3-- 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 l33FKCT2071877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 08:20: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 l33FKCsN071876; Tue, 3 Apr 2007 08:20: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 mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l33FJoiC071845 for ; Tue, 3 Apr 2007 08:20:11 -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 l33FJ28N014890; Tue, 3 Apr 2007 17:19:21 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: TSA key and revocation checking Content-Type: multipart/signed; boundary="----=_NextPart_000_0005_01C77614.2B1553F0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Date: Tue, 3 Apr 2007 17:19:01 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868D3E552@MUCXGC2.opentext.net> In-Reply-To: <460930E7.6000909@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking Thread-Index: Acdwgplf9yx+HuUiRaOWuwcu9xD83gFgDv7A X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Greg Werner" Cc: "Santosh Chokhani" , , "Peter Sylvester" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C77614.2B1553F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Peter's interpretation and would assume you mean "time stamps" and not "time stamp records", otherwise I also don't understand your comment? - Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Peter Sylvester > Sent: Tuesday, March 27, 2007 4:58 PM > To: Greg Werner > Cc: Santosh Chokhani; ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > Greg Werner wrote: > > >From a technical perspective once the user receives an EOL notification > for a particular TSA he/she would have to manually refresh all roots to > establish new and updated trust points. Or, another preventive option is > to check revocation status for outer layer trust anchors on a periodic > basis (once per day or week) and if the TSA root is no longer valid > (revoked) then time stamp records from that particular authority should no > longer be accepted. > > > > > I have a little problem understand this. When should "time stamp > records" no longer be accepted? > I assume first, time stamp records means 'time stamps' according to RFC > 3161 or ISO stuff. > > Accepting a time stamp occurs: > > - by the requesting party, at this time revocation checking can be done > as usual. > > - by a relying party that shortly after the event, i.e. in the normal > course of the distributed workflow. Also I don't see a problem > using whatever normal checking is done. > > I am not considering the third case: > > - by whoever trying to 'reverify' a time stamp LONG time > after the event. > ------=_NextPart_000_0005_01C77614.2B1553F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA0MDMxNTE4NTlaMCMGCSqGSIb3DQEJBDEWBBR2BfGc+WC0zCQ8oTzrXZnZJllv JTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICADnoy9U07xy6Gny9MZCeiioW2busMJLrl0U8N7jt0IPOfCBbU6gGK45L6TZ2 uN+z8rZ1gWIgkeWoL7oq0fKg5nEkwo051Vt/Y8PxMKZ0Lk3Y7FZxLgiViKo2c4A3RNMk5HmRd00P RHJ/nO0A9Yolb1AVDCdZf/Gs3Ir2RgcffeiQMwYx4svTQB6weSinwyUwzhTekUVZsICgEIz3c9JO WewpoM/mz4aJEG6FWZ6CbtmrLrHIOSV6RrHENf8KWiXVK3fww6Gi+C6KJEaVPSf2hTOCphtYun22 OyMc9nS2qVUoMt/EiSQT6Xsz3Tmr13r+4ONpIV0pDPIvoIsfOyf3N/PqI6YCOqe8FfQCGfJueYIk BAGuvNt5I+8Ze/qx3RSbdQGl4tyVZzuquv/LCTRQlRCUBhEmqcXGJBxNzbFyxgoiGzHREGx2jD0w 4O3kLFa0skJI/WpA9hAtoYM98/MtyB7eLet4YrqMHbepwurqSO/wWQVuxOEHY8JRxjRvb8rBPoxa l7po0o7wy7V84iCUJ428YilWCw6manZGdXdRyENVnkVX18+hFLQTywzIHJ0H+73fkZg8QGHMOIvd oXrBx4IWOtCx/EnOEMGge7fijRXcx6AjgC3kf9fh1raYDVZZYPPXEm3e8c6uzevQgmYFgwhZmmsE ABRXwQEoDC6zAaG3AAAAAAAA ------=_NextPart_000_0005_01C77614.2B1553F0--