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 k6DDZ8Bk012058; Thu, 13 Jul 2006 06:35:08 -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 k6DDZ8eh012057; Thu, 13 Jul 2006 06:35:08 -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 k6DDZ6Vh012039 for ; Thu, 13 Jul 2006 06:35:07 -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 k6DDYb028830; Thu, 13 Jul 2006 15:34:37 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 13 Jul 2006 15:34:43 +0200 (MET DST) Message-ID: <44B64B80.1080506@edelweb.fr> Date: Thu, 13 Jul 2006 15:32:48 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, Russ Housley , hartmans-ietf@mit.edu, saag@mit.edu, Carl Wallace Subject: Re: WG LTANS meeting Summary - July 10th, 2006 References: <2666EB2A846BAC4BB2D7F593301A7868436CAF@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868436CAF@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070400010808070101020007" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070400010808070101020007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As I understand there was a remark probably concerning the the import of AlgorithmIdentifier in ERS. I have found at least three different definitions, the first one is not current asn1 syntax any more, and does not allow to specify properly several constraints. The second is from X.509, it allows constaints via the SupportedAlgorithms as a global global feature. The third one come from pkcs1. PKIX88: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } AuthenticationFramework ALGORITHM ::= *TYPE-IDENTIFIER* AlgorithmIdentifier ::= *SEQUENCE* { algorithm ALGORITHM .&id({SupportedAlgorithms }), parameters ALGORITHM .&Type({SupportedAlgorithms }{@algorithm}) *OPTIONAL* } SupportedAlgorithms ALGORITHM ::= {...} pkcs1: ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= SEQUENCE { algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet} {@algorithm}) OPTIONAL } The latter allows us to use something like inside some ERS specific module the supported hash algorithms in a formal way, i.e. allowing a good asn.1 tool to treat this automatically. DigestAlgorithms ALGORITHM-IDENTIFIER ::= { { NULL IDENTIFIED BY id-sha1 } | { NULL IDENTIFIED BY id-sha256 } | { NULL IDENTIFIED BY id-sha384 } | { NULL IDENTIFIED BY id-sha512 }, ... -- Allows for future expansion } --------------ms070400010808070101020007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEzMTMzMjQ4WjAjBgkqhkiG9w0B CQQxFgQU+mrB7gqCeXOZc+5Qup0NHnIpxgkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAJ/7NwRs6qeSXhwSc IIswaaE/Xys8XGsp/S30Q168zbSXsRIydPaxiE20wrUzSDie0HuR49/ks9YGTIMI4gUAxYlR G27FXJq4h8HOy4TWdFuPy0cSzihraPWLP04DiwX4QtCZbH+uLLq4xO88WEcGh15FgHsuDwz6 /YaQaz/f63IAAAAAAAA= --------------ms070400010808070101020007-- 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 k6CAgmhM013050; Wed, 12 Jul 2006 03:42:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6CAgmdg013049; Wed, 12 Jul 2006 03:42:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6CAgku3013027 for ; Wed, 12 Jul 2006 03:42:47 -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 k6CAg1023842; Wed, 12 Jul 2006 12:42:01 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Wed, 12 Jul 2006 12:42:06 +0200 (MET DST) Message-ID: <44B4D18D.8050708@edelweb.fr> Date: Wed, 12 Jul 2006 12:40:13 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, Russ Housley , hartmans-ietf@mit.edu, saag@mit.edu Subject: Re: WG LTANS meeting Summary - July 10th, 2006 References: <2666EB2A846BAC4BB2D7F593301A7868436CA8@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868436CA8@MUCXGC2.opentext.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004040200090603090700" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms050004040200090603090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Tobias Gondrom wrote: > > - ERS will stick to the IMPORTS and NOT define the structures itself > (hard comment from Russ Housley (AD): "use these or it > > will come back"). > Would you please clarify this point. In particular, which data are to be imported and from where. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms050004040200090603090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEyMTA0MDEzWjAjBgkqhkiG9w0B CQQxFgQUQBE+shGVioZw6ZFZFtxNqPOvfXgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAoVGggp+6UflkAM5m 6W/g00W8ObyCtMlolE2fuauJlDGEZJfoQu13xCRdPL6JFv4TjeC8RCBwhcj3Mt0VlPmCByVL wHnXT33sISd2b9xsD5shrjAb3XxWyaZkAT+xusQKQR6asZ2i9g8jfnpSXxjag1WsCl+YBWcn dN02BxbBZE0AAAAAAAA= --------------ms050004040200090603090700-- 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 k6AKWJVD030575; Mon, 10 Jul 2006 13:32:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AKWJwB030574; Mon, 10 Jul 2006 13:32:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AKWHq0030566 for ; Mon, 10 Jul 2006 13:32:18 -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 k6AKWFLt006545; Mon, 10 Jul 2006 22:32:16 +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_01C6A45F.EE424253" Subject: WG LTANS meeting Summary - July 10th, 2006 Date: Mon, 10 Jul 2006 22:32:15 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868436CAF@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LTANS meeting Summary - July 10th, 2006 Thread-Index: AcakW2kn7Yw8pbcQQ6WZLOfb7VOwfw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: , "Russ Housley" , 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_01C6A45F.EE424253 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 below can find the summary of the LTANS WG meeting. Slides and minutes = have been uploaded to the IETF Meeting Materials pages. Summary: IETF meeting July 10th 13:00 - 14:00 location Montreal: attendees: 18 + 8 via Jabber (had Audio stream and screen sharing running - Audio stream had nearly = all Jabber users as participants, screen sharing none) After the first five minutes of Administrative, Tobias did a first = review of the current milestone situation. Milestones got revised and = current schedule for Working group is to complete until April 2007 and = then shutdown. Presentation of ERS showed a few technical questions, as raised before = on the mailing-list: - ERS will stick to the IMPORTS and NOT define the structures itself = (hard comment from Russ Housley (AD): "use these or it will come back"). = - Second decision is that we will add tags to the ArchiveTimeStamps = structure to make it unambiguous (the OPTIONAL digestAlgorithm field = caused some trouble here). - ERS will split the field of reducedHashtree (Sequence of Sequence of = Octet String) to Sequence of PartialHashtree (:=3D Sequence of Octet = String) for better usability with the compilers.=20 - ERS version 07 did reduce chapter 5 (about encrypted content) to a = generic bucket - it can be addressed in a separate specification if = needed. - mapping of ERS to XML is on the way (done by Aleksej) - Aleksej mentioned that there is a third implementation for ERS = underway (SETCCE will have ERS implementation with IBM) - ERS will start second WG last call with these changes on version 08. Carl gave LTAP presentation (for Peter as he couldn't attend = personally). LTAP raised a few questions and comments, we will have new improved = version by end of August. Discussion went around metadata and EvidenceRecord validation will be = done in a separate draft coming in the next months to support ERS/SCVP = and the others. ERS/SCVP status update: minor revisions between the -00 and -01 versions = were recapped. Carl gave presentation about EvidenceRecord Validation rules: Discussion of the need for the data necessary for the verification of = ERS data structures. where to get, where to store, etc. Parallels to RFC 3280. The following questions have been risen: where = shall respective policies be defined, shall ArchiveTimeStamps be = self-contained? Best regards, Tobias & Carl __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C6A45F.EE424253 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG LTANS meeting Summary - July 10th, 2006

Hello,

below = can find the summary of the LTANS WG meeting. Slides and minutes have been uploaded to the = IETF Meeting Materials pages.

Summary:

IETF = meeting

July = 10th 13:00 - 14:00

location Montreal:

attendees: 18 + 8 via Jabber

(had = Audio stream and screen sharing running - Audio stream had nearly all = Jabber users as participants, screen sharing none)

After = the first five minutes of Administrative, Tobias did a first review of = the current milestone situation. Milestones got revised and current = schedule for Working group is to complete until April 2007 and then = shutdown.

Presentation of ERS showed a few technical questions, as = raised before on the mailing-list:

- ERS = will stick to the IMPORTS and NOT define the structures itself (hard = comment from Russ Housley (AD): "use these or it will come = back").

- = Second decision is that we will add tags to the ArchiveTimeStamps = structure to make it unambiguous (the OPTIONAL digestAlgorithm field = caused some trouble here).

- ERS = will split the field of reducedHashtree (Sequence of Sequence of Octet = String) to Sequence of PartialHashtree (:=3D Sequence of Octet String) = for better usability with the compilers.

- ERS = version 07 did reduce chapter 5 (about encrypted content) to a generic = bucket - it can be addressed in a separate specification if = needed.

- = mapping of ERS to XML is on the way (done by Aleksej)

- = Aleksej mentioned that there is a third implementation for ERS underway = (SETCCE will have ERS implementation with IBM)

- ERS = will start second WG last call with these changes on version = 08.

Carl = gave LTAP presentation (for Peter as he couldn't attend = personally).

LTAP = raised a few questions and comments, we will have new improved version = by end of August.

Discussion went around metadata and EvidenceRecord = validation will be done in a separate draft coming in the next months to = support ERS/SCVP and the others.

ERS/SCVP status update: minor revisions between the -00 = and -01 versions were recapped.

Carl = gave presentation about EvidenceRecord Validation = rules:

Discussion of the need for the data necessary for the = verification of ERS data structures. where to get, where to store, = etc.

Parallels to RFC 3280. The following questions = have been risen: where shall respective policies be defined, shall = ArchiveTimeStamps be self-contained?



Best = regards, Tobias & Carl


__________________________________________
Tobias = Gondrom
Senior = Security Architect
Head of Open Text Security Team

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

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

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

------_=_NextPart_001_01C6A45F.EE424253-- 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 k6AK0l3R024322; Mon, 10 Jul 2006 13:00:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AK0lI7024321; Mon, 10 Jul 2006 13:00:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AK0iOm024302 for ; Mon, 10 Jul 2006 13:00:45 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k6AK0gLt006444; Mon, 10 Jul 2006 22:00:43 +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_01C6A45B.860C62A2" Subject: WG LTANS meeting Summary - July 10th, 2006 Date: Mon, 10 Jul 2006 21:59:54 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868436CA8@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LTANS meeting Summary - July 10th, 2006 Thread-Index: AcakW2kn7Yw8pbcQQ6WZLOfb7VOwfw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: , "Russ Housley" , Cc: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A45B.860C62A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 below can find the summary of the LTANS WG meeting. Slides and minutes = have been uploaded to the IETF Meeting Materials pages. Summary: IETF meeting July 10th 13:00 - 14:00 location Montreal: attendees: 18 + 8 via Jabber (had Audio stream and screen sharing running - Audio stream had nearly = all Jabber users as participants, screen sharing none) After the first five minutes of Administrative, Tobias did a first = review of the current milestone situation. Milestones got=20 revised and current schedule for Working group is to complete until = April 2007 and then shutdown. Presentation of ERS showed a few technical questions, as raised before = on the mailing-list: - ERS will stick to the IMPORTS and NOT define the structures itself = (hard comment from Russ Housley (AD): "use these or it=20 will come back").=20 - Second decision is that we will add tags to the ArchiveTimeStamps = structure to make it unambiguous (the OPTIONAL=20 digestAlgorithm field caused some trouble here). - ERS will split the field of reducedHashtree (Sequence of Sequence of = Octet String) to Sequence of PartialHashtree (:=3D=20 Sequence of Octet String) for better usability with the compilers.=20 - ERS version 07 did reduce chapter 5 (about encrypted content) to a = generic bucket - it can be addressed in a separate=20 specification if needed. - mapping of ERS to XML is on the way (done by Aleksej) - Aleksej mentioned that there is a third implementation for ERS = underway (SETCCE will have ERS implementation with IBM) - ERS will start second WG last call with these changes on version 08. Carl gave LTAP presentation (for Peter as he couldn't attend = personally). LTAP raised a few questions and comments, we will have new improved = version by end of August. Discussion went around metadata and=20 EvidenceRecord validation will be done in a separate draft coming in the = next months to support ERS/SCVP and the others. ERS/SCVP status update: minor revisions between the -00 and -01 versions = were recapped. Carl gave presentation about EvidenceRecord Validation rules: Discussion of the need for the data necessary for the verification of = ERS data structures. where to get, where to store, etc. Parallels to RFC 3280. The question have been risen: where shall = respective policies be defined, shall ArchiveTimeStamps be = self-contained? Best regards, Tobias & Carl __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C6A45B.860C62A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG LTANS meeting Summary - July 10th, 2006

Hello, =

below = can find the summary of the LTANS WG meeting. Slides and minutes have been uploaded to the IETF Meeting = Materials pages.

Summary:

IETF = meeting

July = 10th 13:00 - 14:00

location Montreal:

attendees: 18 + 8 via Jabber

(had = Audio stream and screen sharing running - Audio stream had nearly all = Jabber users as participants, screen sharing none)

After = the first five minutes of Administrative, Tobias did a first review of the current = milestone situation. Milestones got

revised and current schedule for Working group is to = complete until April 2007 and then shutdown.

Presentation of ERS showed a few technical questions, as = raised before on the mailing-list:

- ERS = will stick to the IMPORTS and NOT define the structures itself (hard = comment from Russ Housley (AD): "use these or it

will = come back").

- = Second decision is that we will add tags to the ArchiveTimeStamps = structure to make it unambiguous = (the OPTIONAL

digestAlgorithm field caused some trouble = here).

- ERS = will split the field of reducedHashtree (Sequence of Sequence of Octet = String) to Sequence of PartialHashtree (:=3D

Sequence of Octet String) for better usability with the = compilers.

- ERS = version 07 did reduce chapter 5 (about encrypted content) to a generic = bucket - it can be addressed in a separate

specification if needed.

- = mapping of ERS to XML is on the way (done by Aleksej)

- = Aleksej mentioned that there is a third implementation for ERS underway = (SETCCE will have ERS implementation with IBM)

- ERS = will start second WG last call with these changes on version = 08.

Carl = gave LTAP presentation (for Peter as he couldn't attend = personally).

LTAP = raised a few questions and comments, we will have new improved version = by end of August.

Discussion went around metadata and

EvidenceRecord validation will be done in a separate = draft coming in the next months to support ERS/SCVP and the = others.

ERS/SCVP status update: minor revisions between the -00 = and -01 versions were recapped.

Carl = gave presentation about EvidenceRecord Validation = rules:

Discussion of the need for the data necessary for the = verification of ERS data structures. where to get, where to store, = etc.

Parallels = to RFC 3280. The question have been risen: where shall respective = policies be defined, shall ArchiveTimeStamps be  self-contained?



Best = regards, Tobias & Carl


__________________________________________
Tobias = Gondrom
Senior = Security Architect
Head of Open Text Security Team

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

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

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

------_=_NextPart_001_01C6A45B.860C62A2-- 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 k6ADJQfV017459; Mon, 10 Jul 2006 06:19:26 -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 k6ADJQmK017456; Mon, 10 Jul 2006 06:19:26 -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 k6ADJOKk017414 for ; Mon, 10 Jul 2006 06:19:25 -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 k6ADJMLt002607 for ; Mon, 10 Jul 2006 15:19:23 +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_01C6A423.74D15F00" Subject: IETF meeting today at 13:00 EST - meetig data Date: Mon, 10 Jul 2006 15:19:23 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868436C24@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF meeting today at 13:00 EST - meetig data Thread-Index: AcakI3XWLKs1bBP4SwC2AU8CkfE/Ig== X-Priority: 1 Importance: high From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A423.74D15F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, as you know we will have our IETF-conference meeting today at 13:00 EST. As some of us might not had the chance to come to Canada, I looked = around and with the help of the local IT guys, we will try to offer the = following media to give you the best chance to follow the discussion and = add comments: 1. slides can be found at: = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 6=20 2. Jabber: room ltans at rooms.jabber.ietf.org (this is where you can = give your comments - they will be given to the audience during the = meeting as at the last time.) 3. we will have a live audio stream from our room 513B = http://videolab.uoregon.edu/events/ietf/=20 4. screen sharing with the slides (unfortunately only for Windows = clients): = https://meetingzoneci.opentext.com/meeting/jsp/attendmeeting.jsp?meetingi= d=3DFCZNMDEY&pc=3D (no passcode required and email and name are just = used to send you a technical log of the meeting afterwards.=20 (as we do 3 & 4 the first time, there might be some performance issues, = so please primarily rely on 1 and 2) Best regards and talk to you in a few hours, Tobias __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C6A423.74D15F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF meeting today at 13:00 EST - meetig data

Hello = all,

as = you know = we will have our IETF-conference meeting today at 13:00 EST.

As = some of us might not had the chance to come to Canada, I looked around = and with the help of the local = IT guys, we will try to offer the following media to give you the = best chance to follow the discussion and add comments:

1.      slides can be found at: = https://datatracker.ietf.org/public/meeting_materials.cgi?= meeting_num=3D66
2.      Jabber: room ltans at rooms.jabber.ietf.org  (this is where you can give your = comments – = they will be given = to the audience during the meeting as at the last = time.)

3.      we will have a live audio = stream from our room 513B  = http://videolab.uoregon.edu/events/ietf/= =
4.      screen sharing with the = slides (unfortunately only for Windows clients): https://meetingzoneci.opentext.com/meeting/jsp/attendmeeti= ng.jsp?meetingid=3DFCZNMDEY&pc=3D = (no passcode required and email and name are just used to send = you a technical log of the = meeting afterwards.

(as = we do 3 = & 4 = the first time, there might be some performance issues, so please = primarily rely on 1 and 2)

Best = regards and talk to you in a few hours,

Tobias

__________________________________________
Tobias = Gondrom
Senior = Security Architect
Head of Open Text Security Team

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

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

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

------_=_NextPart_001_01C6A423.74D15F00-- 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 k68EHnjh082557; Sat, 8 Jul 2006 07:17:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k68EHn31082556; Sat, 8 Jul 2006 07:17:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k68EHmnB082522 for ; Sat, 8 Jul 2006 07:17:48 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: meeting Date: Sat, 8 Jul 2006 07:17:38 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87903A20872@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: meeting thread-index: AcaimUQDnoWrIz5cQliJgNKVWf1xmg== From: "Carl Wallace" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k68EHmnB082551 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, The LTANS meeting is at Monday at 13:00 EDT. As with the last meeting, we will use Jabber during the session (see http://www3.ietf.org/meetings/text_conf.html for configuration details). Slides will be posted in advance of the meeting (by Monday morning). Carl 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 k63AVsW2072096; Mon, 3 Jul 2006 03:31: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 k63AVsYV072095; Mon, 3 Jul 2006 03:31: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 e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k63AVqVL072062 for ; Mon, 3 Jul 2006 03:31:53 -0700 (MST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200607031031.k63AVqVL072062@balder-227.proper.com> Received: (qmail 27331 invoked from network); 3 Jul 2006 10:31:51 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 3 Jul 2006 10:31:51 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 27028-04 for ; Mon, 3 Jul 2006 12:31:49 +0200 (CEST) Received: (qmail 27326 invoked from network); 3 Jul 2006 10:31:49 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 3 Jul 2006 10:31:49 -0000 From: "A. Jerman Blazic" To: Subject: RE: Questions about LTAP extension Date: Mon, 3 Jul 2006 12:34:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <44A6A2AB.9000105@aspector.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcadLCRQmmyzvkpfR9CNwiKAG+hfLQBXPADg X-Virus-Scanned: amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Bernard Thank you for your remarks. See my comments inline > I am currently implementing LTAP as the standard interface to > a LTANS server. The server is a commercially oriented > product/service development with differerent target scenarios: > > (1) you can run it as an extension to your archive within > your own company (internal operation) or > > (2) you can offer separate LTAN services for multiple clients > (as a kind of trustee operation) > > My first question is: Should the trustee operation be covered > by a basic LTAP definition at all? > > If yes, than some extensions to the current definition are > needed. While the current LTAP definition supports the first > scenario (internal > operation) quite well, it lacks some support for the trustee scenario: LTAP operates per service polices, which describes the characteristics and behavior of a LTA service. LTAP was never designed to carry more than needed information except the one needed for basic operations of submit/retrieve. The protocol itself does rely on the lower layer protocols or parallel protocols if you want so. So in this case all extensions are not needed, as the operation requested is identified by the policies used. However, the current specification does enable clients to define their own sets of operating instructions if needed. > First of all a client may want to use the (external) LTAN > service whithout revealing the content of confidential or > even secret documents. > This would be possible if the client could sent message > imprints instead of document raw data to the service > (requires simple changes to the ARCHIVE/VERIFY request definition). All services already have three options: - raw data (submit a complete data to be preserved) - message imprint (submit only message imprints) - reference (deliver only the reference to data) Mind you that not all services find all three options sufficient to perform a requested operation. For example if a piece of data carries a signature and the requested service delivers option of maintaining the validity of a signature, message imprint would not meet the needs to perform the operation - validate the signature for example (only in the case the submitted message imprint matches the one used with the signature). > But for the client to know which digest algorithm should be > used for computing the message imprint, he need to be able to > query the service about that information. I think that using > policies for that is the best way to do that. So a LTANS > policy should include a digest algorithm information the > client can use to compute message imprints for ARCHIVE > operations based on that policy. Message imprint information is already included. > What is needed is a POLICY request, where a client can query > the LTANS policies first, then selects a policy based on its > preferences and starts calculating message imprints sent to > the server via ARCHIVCE (or > VERIFY) requests. This is an interesting point but the LTAP protocol was designed to hold the basic operation of a LTA submit/retrieve. This means that service policy is included only for the sole purpose to identify the service to be (or that was) executed over submitted data. Service description is thus out of the scope of LTAP. Characteristics such as archive policy should be obtained using other means such as WSDL for example prior to LTAP interaction. In general it is very interesting to see the implementation of the protocol. Looking forward for additional feedback. Regards Aleksej > Do you think that these extension make sense in the LTAP > framework or should LTAN services implement their own > extensions to LTAP to suite their own needs? > > Regards, > Bernd. > > -- > gpg fp: F722 2826 40C2 B3C4 E136 6DE5 1DC0 7A20 513B C8F4 > 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 k61GRiGh031099; Sat, 1 Jul 2006 09:27:44 -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 k61GRiuT031098; Sat, 1 Jul 2006 09:27:44 -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 ms7.webland.ch (ms7.webland.ch [194.209.78.137]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k61GRg0t031049 for ; Sat, 1 Jul 2006 09:27:43 -0700 (MST) (envelope-from Bernd.Fix@aspector.com) Received: from [192.168.23.10] ([85.2.85.76]) by ms7.webland.ch (Webland.MailServer.v.8.3.5) with ASMTP (SSL) id FXC45537 for ; Sat, 1 Jul 2006 18:27:37 +0200 Message-ID: <44A6A2AB.9000105@aspector.com> Date: Sat, 01 Jul 2006 18:28:27 +0200 From: "Bernd R. Fix" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ietf-ltans@vpnc.org Subject: Questions about LTAP extension X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-WLGenuine-Reason: [FILTER]=Local or Smtp Auth Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am currently implementing LTAP as the standard interface to a LTANS server. The server is a commercially oriented product/service development with differerent target scenarios: (1) you can run it as an extension to your archive within your own company (internal operation) or (2) you can offer separate LTAN services for multiple clients (as a kind of trustee operation) My first question is: Should the trustee operation be covered by a basic LTAP definition at all? If yes, than some extensions to the current definition are needed. While the current LTAP definition supports the first scenario (internal operation) quite well, it lacks some support for the trustee scenario: First of all a client may want to use the (external) LTAN service whithout revealing the content of confidential or even secret documents. This would be possible if the client could sent message imprints instead of document raw data to the service (requires simple changes to the ARCHIVE/VERIFY request definition). But for the client to know which digest algorithm should be used for computing the message imprint, he need to be able to query the service about that information. I think that using policies for that is the best way to do that. So a LTANS policy should include a digest algorithm information the client can use to compute message imprints for ARCHIVE operations based on that policy. What is needed is a POLICY request, where a client can query the LTANS policies first, then selects a policy based on its preferences and starts calculating message imprints sent to the server via ARCHIVCE (or VERIFY) requests. Do you think that these extension make sense in the LTAP framework or should LTAN services implement their own extensions to LTAP to suite their own needs? Regards, Bernd. -- gpg fp: F722 2826 40C2 B3C4 E136 6DE5 1DC0 7A20 513B C8F4