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 l2U0vJU1011611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 17:57: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 l2U0vJgS011609; Thu, 29 Mar 2007 17:57: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 nit.isi.edu (nit.isi.edu [128.9.160.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2U0uwjm011590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Mar 2007 17:57:19 -0700 (MST) (envelope-from apache@nit.isi.edu) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l2U0uuw6004125; Thu, 29 Mar 2007 16:56:56 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l2U0uuq6004124; Thu, 29 Mar 2007 17:56:56 -0700 Date: Thu, 29 Mar 2007 17:56:56 -0700 Message-Id: <200703300056.l2U0uuq6004124@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4810 on Long-Term Archive Service Requirements From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ltans@imc.org Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new Request for Comments is now available in online RFC libraries. RFC 4810 Title: Long-Term Archive Service Requirements Author: C. Wallace, U. Pordesch, R. Brandner Status: Informational Date: March 2007 Mailbox: cwallace@cygnacom.com, ulrich.pordesch@zv.fraunhofer.de, ralf.brandner@intercomponentware.com Pages: 17 Characters: 35690 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ltans-reqs-10.txt URL: http://www.rfc-editor.org/rfc/rfc4810.txt There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community. This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... 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 l2RF0TnT081054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 08:00:29 -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 l2RF0TCs081053; Tue, 27 Mar 2007 08:00:29 -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 l2RF07GZ081027 for ; Tue, 27 Mar 2007 08:00:27 -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 l2RExq511283; Tue, 27 Mar 2007 16:59:52 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 27 Mar 2007 16:59:57 +0200 (MET DST) Message-ID: <460930E7.6000909@edelweb.fr> Date: Tue, 27 Mar 2007 16:57:43 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Greg Werner CC: Santosh Chokhani , ietf-ltans@imc.org Subject: Re: TSA key and revocation checking References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> In-Reply-To: <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080702020706060503050509" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms080702020706060503050509 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. --------------ms080702020706060503050509 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMzI3MTQ1NzQzWjAjBgkqhkiG9w0B CQQxFgQU149mUCur9tGibPFH2Ow6o4bHUkYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAtACVBTXB01PYEobI J1YCcBiU/oGgrLDR0wglGJZ3sXHyynLxLme93oyMLlJYV+MCcsax2rTwv89noERVYHEvsHYA HK/Qm7Bes800rTHv8paJ8Ry8rU/yHiX5aRDhPvhD1vCf4n0+Af5Bbyt0760Vy06gTMYmmS5g kDGkyz++W4EAAAAAAAA= --------------ms080702020706060503050509-- 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 l2QDfApe086999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 06:41:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2QDfADB086998; Mon, 26 Mar 2007 06:41:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2QDemna086982 for ; Mon, 26 Mar 2007 06:41:08 -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 l2QDeClk022121; Mon, 26 Mar 2007 15:40:22 +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: validate draft - RE: TSA key and revocation checking Date: Mon, 26 Mar 2007 15:40:10 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868C07558@MUCXGC2.opentext.net> In-Reply-To: <004601c76d5f$fabc3eb0$174f7d40@home.glassey.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: validate draft - RE: TSA key and revocation checking Thread-Index: AcdtX/zbrD1VXaY9QFmkuRFfvpsWDgCSxXkQ From: "Tobias Gondrom" To: "todd glassey" , "Julien Stern" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2QDf9na086993 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Todd, > > 3. is there consensus that we only need either an OCSP _or_ a CRL - but > > not both to verify the validity of a certificate? > > no - both should be available. > Why are _both_ needed to verify? >From my understanding for LTAs and a later party verifying an ERS it is only important to know and verify that a certificate has been valid at the time of use (and not been compromised until the time of protection via the LTA. This information can be gained from either CRL or OCSP. Could you please explain which necessary information you can not get from one of the two (either CRL or OCSP). So that you need to also retrieve the second one additionally? Tobias 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 l2NFVjJo070192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 08:31: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 l2NFVjuc070191; Fri, 23 Mar 2007 08:31: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 elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2NFVig8070180 for ; Fri, 23 Mar 2007 08:31:44 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ys9/vdp+O2cSMzWPqePvKbOdcu7gytlZfeFl/BCGpCpcTvyswK41hSh4NXQkHmcE; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HUlk0-0006et-2L; Fri, 23 Mar 2007 11:31:44 -0400 Message-ID: <005201c76d60$5d49bcb0$174f7d40@home.glassey.com> From: "todd glassey" To: "Julien Stern" , References: <886F5D4C78AFB14D87261206BFB9612E1CD70C3B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071ADBD7@EXVS01.ex.dslextreme.net> <20070323085952.GA30562@mars.cry.pto> Subject: Re: validate draft - RE: TSA key and revocation checking Date: Fri, 23 Mar 2007 08:31:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79df2befaf79b4586f8f999627957e4aef350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julien - this pertains to "Public TSA's" only as far as I can tell and a TSA that was operated internally to some institution may not have the same requirements on its use. That said, the real issue is how the system's to be used I think. Todd Glassey ----- Original Message ----- From: "Julien Stern" To: Sent: Friday, March 23, 2007 1:59 AM Subject: Re: validate draft - RE: TSA key and revocation checking > > Tobias, > > I now agree too with Carl. > Having a Trusted TSA would indeed be nice to avoid the online lookup > at verification time, but that does not weight against the ability > to revoke the certificate. Notably because the RootCA will typically > be offline and rarely used, while the TSA will be online and heavily > used. > > -- > Julien > > On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote: >> Tobias, >> >> >> >> I agree with Carl. >> >> >> >> For the refreshed time stamps, all the artifacts can be part of the time >> stamp or obtained from the PKI archive per I-D drafted by Carl. >> >> >> >> For current time stamp, objects should be available a la regular PKI. >> >> ________________________________ >> >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace >> Sent: Thursday, March 22, 2007 3:49 PM >> To: ietf-ltans@imc.org >> Subject: RE: validate draft - RE: TSA key and revocation checking >> >> >> >> In this case, I did correctly understand the intent of your proposal and >> feel the revocation status of the TSA certs should be checked. I don't >> see where this complicates things. The TSA is simply another EE >> certificate and artifacts necessary to verify EE certificates will >> already be preserved to verify signatures on documents. >> >> >> >> >> ________________________________ >> >> >> From: Tobias Gondrom [mailto:tgondrom@opentext.com] >> Sent: Thursday, March 22, 2007 3:33 PM >> To: ietf-ltans@imc.org >> Cc: Carl Wallace >> Subject: validate draft - RE: TSA key and revocation checking >> >> Hello Carl, Peter, Santosh and Julien, >> >> >> >> thank you for bringing this is up: >> >> At first this is just a _proposal_ about how to verify and what might be >> needed. >> >> Stefanie and I thought about what people need to store within the TS in >> ERS to verify it at any later point in time. >> >> (although we have the protection of the later ArchiveTimestampchains >> and -sequences for the integrity of the inner data, but still some >> problems arise due to the fact that you can expect _online_ status >> requests to fail e.g. when TSAs shut down or even after guaranteed >> timeframes of availability of about 30 years.) >> >> >> >> My thoughts in the presentation (as well as in the validate-draft) are >> the following: >> >> 0) theoretically to verify a TS it is necessary to store all certificates >> up to the root plus check their status (especially for revocation). >> >> (and in the case that you are not able to make the status request live >> and online you may also start to consider to also store all certificates >> used in signing the OCSP or CRLs, and their certificate chains and their >> OCSP responses, etc.) >> >> >> >> 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a >> government body itself or certified by a government body) it could be >> (depending on the laws and customs of the specific country) sufficient to >> only store all certificates up to the root in the RFC3161-TS structures. >> >> This idea is based on the fact that it would be (inevitably) publicly >> known when a key of a certified TSA would be compromised (and revoked). >> >> This way you would not need to store OCSP or CRL for all certificates (up >> to the root) used in the TS - and this would make things a lot easier. >> >> >> >> Tobias >> >> >> >> >> >> >> >> >> >> >> >> >> ________________________________ >> >> >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace >> Sent: Thursday, March 22, 2007 3:28 PM >> To: ietf-ltans@imc.org >> Subject: RE: TSA key and revocation checking >> >> >> >> I took the comment during the meeting to refer to scenario 2. >> >> >> >> >> ________________________________ >> >> >> From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr] >> Sent: Thursday, March 22, 2007 7:50 AM >> To: Carl Wallace >> Cc: ietf-ltans@imc.org >> Subject: Re: TSA key and revocation checking >> >> Carl Wallace a écrit : >> >> During yesterday's meeting, Tobias mentioned that a TSA key could be >> trusted without checking its revocation status because compromise of the >> key would be a widely known problem. I asked, via Jabber, how one could >> confirm they had the correct TSA key and was directed to the mailing >> list. While it may be true that the compromise of the TSA would be >> widely known, would the revocation of a certificate issued in error to >> the same name be as widely known? Recommending that revocation status >> not be checked seems like a bad idea. We have means for representing and >> processing revocation information, including the time of compromise, and >> should simply use them. >> >> I am not sure what scenario is addressed: >> >> 1 - a client that obtains a time stamp and determines the aujthenticity >> of the response >> 2 - a relying party that verifies the time stamp >> >> >> >> > 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 l2NFTL3K069927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2NFTLfb069926; Fri, 23 Mar 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2NFT0Al069866 for ; Fri, 23 Mar 2007 08:29:20 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jrdhU1XPPz+yJ2kIoUlUHAefG6pZfcONGzGWDWN8VoXyzwDD8hIzy1281W2kE8NK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HUlhK-0001UW-NZ; Fri, 23 Mar 2007 11:28:58 -0400 Message-ID: <004601c76d5f$fabc3eb0$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , "Julien Stern" , References: <2666EB2A846BAC4BB2D7F593301A7868C073DC@MUCXGC2.opentext.net> Subject: Re: validate draft - RE: TSA key and revocation checking Date: Fri, 23 Mar 2007 08:28:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bbca6825b724fa0afc50f2d2ee9bb73b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Tobias Gondrom" To: "Julien Stern" ; Sent: Friday, March 23, 2007 6:59 AM Subject: RE: validate draft - RE: TSA key and revocation checking > > Hello all, > > Ok. (I still do not fully agree, but will wait whether further emails are > send to the mailing list on that item. If not I will modify the validate > draft as you propose.) > > Please let me use the opportunity and ask for your opinion on a few items: > 1. in the CMS of the TS we can easily store the certificates and the CRLs > in the according fields of the structure SignedData. What is the intent and use in storing the cert's themselves inside the CMS? - storing the certs may actually lead to instances where a stored cert could be invalidated in the external world for some cause and that would not be known to the LTANS provider. > Any comments on where to best store OCSP responses in the structure? If you are looking to store validation control information then the CMS area is probably reasonable. > > 2. as OCSP and CRLs are typically signed: (responses...) > a) Shall we also store the certificates with which they are signed? > b) and shall we also store the OCSP/CRL for the certificates that have > been used to sign the OCSP responses? If there is a need to create an evidence model such that all components of the decision/integrity control features are evidenced within the individual document instance, then yes you must store all the relevant data from that signing. > > 3. is there consensus that we only need either an OCSP _or_ a CRL - but > not both to verify the validity of a certificate? no - both should be available. > > Any comments? > > Tobias > > > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] >> On Behalf Of Julien Stern >> Sent: Friday, March 23, 2007 10:00 AM >> To: ietf-ltans@imc.org >> Subject: Re: validate draft - RE: TSA key and revocation checking >> >> >> Tobias, >> >> I now agree too with Carl. >> Having a Trusted TSA would indeed be nice to avoid the online lookup >> at verification time, but that does not weight against the ability >> to revoke the certificate. Notably because the RootCA will typically >> be offline and rarely used, while the TSA will be online and heavily >> used. >> >> -- >> Julien >> >> On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote: >> > Tobias, >> > >> > >> > >> > I agree with Carl. >> > >> > >> > >> > For the refreshed time stamps, all the artifacts can be part of the >> > time >> stamp or obtained from the PKI archive per I-D drafted by Carl. >> > >> > >> > >> > For current time stamp, objects should be available a la regular PKI. >> > >> > ________________________________ >> > >> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- >> ltans@mail.imc.org] On Behalf Of Carl Wallace >> > Sent: Thursday, March 22, 2007 3:49 PM >> > To: ietf-ltans@imc.org >> > Subject: RE: validate draft - RE: TSA key and revocation checking >> > >> > >> > >> > In this case, I did correctly understand the intent of your proposal >> > and >> feel the revocation status of the TSA certs should be checked. I don't >> see where this complicates things. The TSA is simply another EE >> certificate and artifacts necessary to verify EE certificates will >> already >> be preserved to verify signatures on documents. >> > >> > >> > >> > >> > ________________________________ >> > >> > >> > From: Tobias Gondrom [mailto:tgondrom@opentext.com] >> > Sent: Thursday, March 22, 2007 3:33 PM >> > To: ietf-ltans@imc.org >> > Cc: Carl Wallace >> > Subject: validate draft - RE: TSA key and revocation checking >> > >> > Hello Carl, Peter, Santosh and Julien, >> > >> > >> > >> > thank you for bringing this is up: >> > >> > At first this is just a _proposal_ about how to verify and what >> might be needed. >> > >> > Stefanie and I thought about what people need to store within the TS >> in ERS to verify it at any later point in time. >> > >> > (although we have the protection of the later ArchiveTimestampchains >> and -sequences for the integrity of the inner data, but still some >> problems arise due to the fact that you can expect _online_ status >> requests to fail e.g. when TSAs shut down or even after guaranteed >> timeframes of availability of about 30 years.) >> > >> > >> > >> > My thoughts in the presentation (as well as in the validate-draft) >> are the following: >> > >> > 0) theoretically to verify a TS it is necessary to store all >> certificates up to the root plus check their status (especially for >> revocation). >> > >> > (and in the case that you are not able to make the status request >> live and online you may also start to consider to also store all >> certificates used in signing the OCSP or CRLs, and their certificate >> chains and their OCSP responses, etc.) >> > >> > >> > >> > 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a >> government body itself or certified by a government body) it could be >> (depending on the laws and customs of the specific country) sufficient to >> only store all certificates up to the root in the RFC3161-TS structures. >> > >> > This idea is based on the fact that it would be (inevitably) >> publicly known when a key of a certified TSA would be compromised (and >> revoked). >> > >> > This way you would not need to store OCSP or CRL for all >> certificates (up to the root) used in the TS - and this would make things >> a lot easier. >> > >> > >> > >> > Tobias >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > ________________________________ >> > >> > >> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- >> ltans@mail.imc.org] On Behalf Of Carl Wallace >> > Sent: Thursday, March 22, 2007 3:28 PM >> > To: ietf-ltans@imc.org >> > Subject: RE: TSA key and revocation checking >> > >> > >> > >> > I took the comment during the meeting to refer to scenario 2. >> > >> > >> > >> > >> > ________________________________ >> > >> > >> > From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr] >> > Sent: Thursday, March 22, 2007 7:50 AM >> > To: Carl Wallace >> > Cc: ietf-ltans@imc.org >> > Subject: Re: TSA key and revocation checking >> > >> > Carl Wallace a écrit : >> > >> > During yesterday's meeting, Tobias mentioned that a TSA key >> could be trusted without checking its revocation status because >> compromise >> of the key would be a widely known problem. I asked, via Jabber, how one >> could confirm they had the correct TSA key and was directed to the >> mailing >> list. While it may be true that the compromise of the TSA would be >> widely >> known, would the revocation of a certificate issued in error to the same >> name be as widely known? Recommending that revocation status not be >> checked seems like a bad idea. We have means for representing and >> processing revocation information, including the time of compromise, and >> should simply use them. >> > >> > I am not sure what scenario is addressed: >> > >> > 1 - a client that obtains a time stamp and determines the >> aujthenticity of the response >> > 2 - a relying party that verifies the time stamp >> > >> > >> > >> > > > 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 l2NEIDZp062614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 07:18: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 l2NEIDKw062613; Fri, 23 Mar 2007 07:18:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2NEHk5L062538 for ; Fri, 23 Mar 2007 07:18:08 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 11105 invoked from network); 23 Mar 2007 14:17:43 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Mar 2007 14:17:43 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 23 Mar 2007 14:17:42 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Mar 2007 10:17:42 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70C6F@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: RE: validate draft - RE: TSA key and revocation checking Date: Fri, 23 Mar 2007 10:17:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76D56.04D5C1D8" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76D56.04D5C1D8 Content-Type: text/plain; charset="ISO-8859-1" > 1. in the CMS of the TS we can easily store the certificates > and the CRLs in the according fields of the structure > SignedData. Any comments on where to best store OCSP > responses in the structure? OCSP responses can be stored in the same place. RFC3852 defines the CRLs bag as a RevocationInfoChoices. I'm not sure if an OID has been defined for this purpose yet. RevocationInfoChoices ::= SET OF RevocationInfoChoice RevocationInfoChoice ::= CHOICE { crl CertificateList, other [1] IMPLICIT OtherRevocationInfoFormat } OtherRevocationInfoFormat ::= SEQUENCE { otherRevInfoFormat OBJECT IDENTIFIER, otherRevInfo ANY DEFINED BY otherRevInfoFormat } > 2. as OCSP and CRLs are typically signed: > a) Shall we also store the certificates with which they are signed? > b) and shall we also store the OCSP/CRL for the certificates > that have been used to sign the OCSP responses? I think these are configuration options. The materials could be stored in each object or could be stored separately under a different evidence record. > 3. is there consensus that we only need either an OCSP _or_ a > CRL - but not both to verify the validity of a certificate? Either seems fine to me, no need for both. > Any comments? My preference is to store the artifacts separately from the documents and to store a single cumulative CRL once a CA has reached the end of its life. However, the specs will support a range of options, from storing all materials in each object to storing artifacts once centrally. The verifier has the responsibility for verifying each signature fully (including revocation checks) in accord with their algorithm policy. > Tobias > > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: Friday, March 23, 2007 10:00 AM > > To: ietf-ltans@imc.org > > Subject: Re: validate draft - RE: TSA key and revocation checking > > > > > > Tobias, > > > > I now agree too with Carl. > > Having a Trusted TSA would indeed be nice to avoid the > online lookup > > at verification time, but that does not weight against the > ability to > > revoke the certificate. Notably because the RootCA will > typically be > > offline and rarely used, while the TSA will be online and heavily > > used. > > > > -- > > Julien > > > > On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote: > > > Tobias, > > > > > > > > > > > > I agree with Carl. > > > > > > > > > > > > For the refreshed time stamps, all the artifacts can be > part of the > > > time > > stamp or obtained from the PKI archive per I-D drafted by Carl. > > > > > > > > > > > > For current time stamp, objects should be available a la > regular PKI. > > > > > > ________________________________ > > > > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > > ltans@mail.imc.org] On Behalf Of Carl Wallace > > > Sent: Thursday, March 22, 2007 3:49 PM > > > To: ietf-ltans@imc.org > > > Subject: RE: validate draft - RE: TSA key and revocation checking > > > > > > > > > > > > In this case, I did correctly understand the intent of > your proposal > > > and > > feel the revocation status of the TSA certs should be checked. I > > don't see where this complicates things. The TSA is simply > another EE > > certificate and artifacts necessary to verify EE certificates will > > already be preserved to verify signatures on documents. > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Tobias Gondrom [mailto:tgondrom@opentext.com] > > > Sent: Thursday, March 22, 2007 3:33 PM > > > To: ietf-ltans@imc.org > > > Cc: Carl Wallace > > > Subject: validate draft - RE: TSA key and revocation checking > > > > > > Hello Carl, Peter, Santosh and Julien, > > > > > > > > > > > > thank you for bringing this is up: > > > > > > At first this is just a _proposal_ about how to verify and what > > might be needed. > > > > > > Stefanie and I thought about what people need to store > within the > > > TS > > in ERS to verify it at any later point in time. > > > > > > (although we have the protection of the later > > > ArchiveTimestampchains > > and -sequences for the integrity of the inner data, but still some > > problems arise due to the fact that you can expect _online_ status > > requests to fail e.g. when TSAs shut down or even after guaranteed > > timeframes of availability of about 30 years.) > > > > > > > > > > > > My thoughts in the presentation (as well as in the > validate-draft) > > are the following: > > > > > > 0) theoretically to verify a TS it is necessary to store all > > certificates up to the root plus check their status (especially for > > revocation). > > > > > > (and in the case that you are not able to make the > status request > > live and online you may also start to consider to also store all > > certificates used in signing the OCSP or CRLs, and their > certificate > > chains and their OCSP responses, etc.) > > > > > > > > > > > > 1) What I proposed is that to verify a TS from a > trusted TSA (e.g. > > > a > > government body itself or certified by a government body) > it could be > > (depending on the laws and customs of the specific country) > sufficient > > to only store all certificates up to the root in the > RFC3161-TS structures. > > > > > > This idea is based on the fact that it would be (inevitably) > > publicly known when a key of a certified TSA would be > compromised (and > > revoked). > > > > > > This way you would not need to store OCSP or CRL for all > > certificates (up to the root) used in the TS - and this would make > > things a lot easier. > > > > > > > > > > > > Tobias > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > > ltans@mail.imc.org] On Behalf Of Carl Wallace > > > Sent: Thursday, March 22, 2007 3:28 PM > > > To: ietf-ltans@imc.org > > > Subject: RE: TSA key and revocation checking > > > > > > > > > > > > I took the comment during the meeting to refer to scenario 2. > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Peter Sylvester > [mailto:peter.sylvester@edelweb.fr] > > > Sent: Thursday, March 22, 2007 7:50 AM > > > To: Carl Wallace > > > Cc: ietf-ltans@imc.org > > > Subject: Re: TSA key and revocation checking > > > > > > Carl Wallace a écrit : > > > > > > During yesterday's meeting, Tobias mentioned > that a TSA key > > could be trusted without checking its revocation status because > > compromise of the key would be a widely known problem. I > asked, via > > Jabber, how one could confirm they had the correct TSA key and was > > directed to the mailing list. While it may be true that the > > compromise of the TSA would be widely known, would the > revocation of a > > certificate issued in error to the same name be as widely known? > > Recommending that revocation status not be checked seems like a bad > > idea. We have means for representing and processing revocation > > information, including the time of compromise, and should > simply use them. > > > > > > I am not sure what scenario is addressed: > > > > > > 1 - a client that obtains a time stamp and > determines the > > aujthenticity of the response > > > 2 - a relying party that verifies the time stamp > > > > > > > > > > > > > > ------_=_NextPart_001_01C76D56.04D5C1D8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: validate draft - RE: TSA key and revocation checking

> 1. in the CMS of the TS we can easily store the = certificates
> and the CRLs in the according fields of the = structure
> SignedData. Any comments on where to best store = OCSP
> responses in the structure?

OCSP responses can be stored in the same place.  = RFC3852 defines the CRLs bag as a RevocationInfoChoices.  I'm not = sure if an OID has been defined for this purpose yet.

      RevocationInfoChoices = ::=3D SET OF RevocationInfoChoice

      RevocationInfoChoice = ::=3D CHOICE {
        crl = CertificateList,
        other [1] = IMPLICIT OtherRevocationInfoFormat }

      = OtherRevocationInfoFormat ::=3D SEQUENCE {
        = otherRevInfoFormat OBJECT IDENTIFIER,
        = otherRevInfo ANY DEFINED BY otherRevInfoFormat }
 
> 2. as OCSP and CRLs are typically signed: =
> a) Shall we also store the certificates with = which they are signed?
> b) and shall we also store the OCSP/CRL for the = certificates
> that have been used to sign the OCSP = responses?

I think these are configuration options.  The = materials could be stored in each object or could be stored separately = under a different evidence record. 

 
> 3. is there consensus that we only need either = an OCSP _or_ a
> CRL - but not both to verify the validity of a = certificate?

Either seems fine to me, no need for both.
 
> Any comments?

My preference is to store the artifacts separately = from the documents and to store a single cumulative CRL once a CA has = reached the end of its life.  However, the specs will support a = range of options, from storing all materials in each object to storing = artifacts once centrally.  The verifier has the responsibility for = verifying each signature fully (including revocation checks) in accord = with their algorithm policy.   

 
> Tobias
>
>
>
> > -----Original Message-----
> > From: owner-ietf-ltans@mail.imc.org =
> > [mailto:owner-ietf-ltans@ma= il.imc.org]
> > On Behalf Of Julien Stern
> > Sent: Friday, March 23, 2007 10:00 = AM
> > To: ietf-ltans@imc.org
> > Subject: Re: validate draft - RE: TSA key = and revocation checking
> >
> >
> > Tobias,
> >
> > I now agree too with Carl.
> > Having a Trusted TSA would indeed be nice = to avoid the
> online lookup
> > at verification time, but that does not = weight against the
> ability to
> > revoke the certificate. Notably because = the RootCA will
> typically be
> > offline and rarely used, while the TSA = will be online and heavily
> > used.
> >
> > --
> > Julien
> >
> > On Thu, Mar 22, 2007 at 07:07:17PM -0700, = Santosh Chokhani wrote:
> > > Tobias,
> > >
> > >
> > >
> > > I agree with Carl.
> > >
> > >
> > >
> > > For the refreshed time stamps, all = the artifacts can be
> part of the
> > > time
> > stamp or obtained from the PKI archive per = I-D drafted by Carl.
> > >
> > >
> > >
> > > For current time stamp, objects = should be available a la
> regular PKI.
> > >
> > > = ________________________________
> > >
> > > From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-
> > ltans@mail.imc.org] On Behalf Of Carl = Wallace
> > > Sent: Thursday, March 22, 2007 3:49 = PM
> > > To: ietf-ltans@imc.org
> > > Subject: RE: validate draft - RE: TSA = key and revocation checking
> > >
> > >
> > >
> > > In this case, I did correctly = understand the intent of
> your proposal
> > > and
> > feel the revocation status of the TSA = certs should be checked.  I
> > don't see where this complicates = things.  The TSA is simply
> another EE
> > certificate and artifacts necessary to = verify EE certificates will
> > already be preserved to verify signatures = on documents.
> > >
> > >
> > >
> > >
> > > = ________________________________
> > >
> > >
> > >   From: Tobias Gondrom [mailto:tgondrom@opentext.com]<= /FONT>
> > >   Sent: Thursday, March 22, 2007 = 3:33 PM
> > >   To: ietf-ltans@imc.org
> > >   Cc: Carl Wallace
> > >   Subject: validate draft - RE: = TSA key and revocation checking
> > >
> > >   Hello Carl, Peter, Santosh and = Julien,
> > >
> > >
> > >
> > >   thank you for bringing this is = up:
> > >
> > >   At first this is just a = _proposal_ about how to verify and what
> > might be needed.
> > >
> > >   Stefanie and I thought about = what people need to store
> within the
> > > TS
> > in ERS to verify it at any later point in = time.
> > >
> > >   (although we have the = protection of the later
> > > ArchiveTimestampchains
> > and -sequences for the integrity of the = inner data, but still some
> > problems arise due to the fact that you = can expect _online_ status
> > requests to fail e.g. when TSAs shut down = or even after guaranteed
> > timeframes of availability of about 30 = years.)
> > >
> > >
> > >
> > >   My thoughts in the = presentation (as well as in the
> validate-draft)
> > are the following:
> > >
> > >   0) theoretically to verify a = TS it is necessary to store all
> > certificates up to the root plus check = their status (especially for
> > revocation).
> > >
> > >   (and in the case that you are = not able to make the
> status request
> > live and online you may also start to = consider to also store all
> > certificates used in signing the OCSP or = CRLs, and their
> certificate
> > chains and their OCSP responses, = etc.)
> > >
> > >
> > >
> > >   1) What I proposed is that to = verify a TS from a
> trusted TSA (e.g.
> > > a
> > government body itself or certified by a = government body)
> it could be
> > (depending on the laws and customs of the = specific country)
> sufficient
> > to only store all certificates up to the = root in the
> RFC3161-TS structures.
> > >
> > >   This idea is based on the fact = that it would be (inevitably)
> > publicly known when a key of a certified = TSA would be
> compromised (and
> > revoked).
> > >
> > >   This way you would not need to = store OCSP or CRL for all
> > certificates (up to the root) used in the = TS - and this would make
> > things a lot easier.
> > >
> > >
> > >
> > >   Tobias
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > = ________________________________
> > >
> > >
> > >   From: = owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-
> > ltans@mail.imc.org] On Behalf Of Carl = Wallace
> > >   Sent: Thursday, March 22, 2007 = 3:28 PM
> > >   To: ietf-ltans@imc.org
> > >   Subject: RE: TSA key and = revocation checking
> > >
> > >
> > >
> > >   I took the comment during the = meeting to refer to scenario 2.
> > >
> > >
> > >
> > >
> > > = ________________________________
> > >
> > >
> > >   =         From: Peter Sylvester =
> [mailto:peter.sylvester@edelwe= b.fr]
> > >   =         Sent: Thursday, March 22, = 2007 7:50 AM
> > >   =         To: Carl Wallace
> > >   =         Cc: = ietf-ltans@imc.org
> > >   =         Subject: Re: TSA key and = revocation checking
> > >
> > >   =         Carl Wallace a =E9crit = :
> > >
> > >   =         During yesterday's meeting, = Tobias mentioned
> that a TSA key
> > could be trusted without checking its = revocation status because
> > compromise of the key would be a widely = known problem.  I
> asked, via
> > Jabber, how one could confirm they had the = correct TSA key and was
> > directed to the mailing list.  While = it may be true that the
> > compromise of the TSA would be widely = known, would the
> revocation of a
> > certificate issued in error to the same = name be as widely known? 
> > Recommending that revocation status not be = checked seems like a bad
> > idea.  We have means for representing = and processing revocation
> > information, including the time of = compromise, and should
> simply use them.
> > >
> > >   =          I am not sure what = scenario is addressed:
> > >
> > >   =         1 -  a client that = obtains a time stamp and
> determines the
> > aujthenticity of the response
> > >   =         2 -  a relying party = that verifies the time stamp
> > >
> > >
> > >
> > >
>
>

------_=_NextPart_001_01C76D56.04D5C1D8-- 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 l2NE01s6061192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 07:00:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2NE01j0061191; Fri, 23 Mar 2007 07:00:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2NDxbif061129 for ; Fri, 23 Mar 2007 07:00:00 -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 l2NDxNlk029791; Fri, 23 Mar 2007 14:59:24 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: validate draft - RE: TSA key and revocation checking Date: Fri, 23 Mar 2007 14:59:22 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868C073DC@MUCXGC2.opentext.net> In-Reply-To: <20070323085952.GA30562@mars.cry.pto> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: validate draft - RE: TSA key and revocation checking Thread-Index: AcdtLCuxP6zkyfR0T9aH2lbdQh5hvgAJb0fg From: "Tobias Gondrom" To: "Julien Stern" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2NE00if061184 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello all, Ok. (I still do not fully agree, but will wait whether further emails are send to the mailing list on that item. If not I will modify the validate draft as you propose.) Please let me use the opportunity and ask for your opinion on a few items: 1. in the CMS of the TS we can easily store the certificates and the CRLs in the according fields of the structure SignedData. Any comments on where to best store OCSP responses in the structure? 2. as OCSP and CRLs are typically signed: a) Shall we also store the certificates with which they are signed? b) and shall we also store the OCSP/CRL for the certificates that have been used to sign the OCSP responses? 3. is there consensus that we only need either an OCSP _or_ a CRL - but not both to verify the validity of a certificate? Any comments? Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Julien Stern > Sent: Friday, March 23, 2007 10:00 AM > To: ietf-ltans@imc.org > Subject: Re: validate draft - RE: TSA key and revocation checking > > > Tobias, > > I now agree too with Carl. > Having a Trusted TSA would indeed be nice to avoid the online lookup > at verification time, but that does not weight against the ability > to revoke the certificate. Notably because the RootCA will typically > be offline and rarely used, while the TSA will be online and heavily > used. > > -- > Julien > > On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote: > > Tobias, > > > > > > > > I agree with Carl. > > > > > > > > For the refreshed time stamps, all the artifacts can be part of the time > stamp or obtained from the PKI archive per I-D drafted by Carl. > > > > > > > > For current time stamp, objects should be available a la regular PKI. > > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Thursday, March 22, 2007 3:49 PM > > To: ietf-ltans@imc.org > > Subject: RE: validate draft - RE: TSA key and revocation checking > > > > > > > > In this case, I did correctly understand the intent of your proposal and > feel the revocation status of the TSA certs should be checked. I don't > see where this complicates things. The TSA is simply another EE > certificate and artifacts necessary to verify EE certificates will already > be preserved to verify signatures on documents. > > > > > > > > > > ________________________________ > > > > > > From: Tobias Gondrom [mailto:tgondrom@opentext.com] > > Sent: Thursday, March 22, 2007 3:33 PM > > To: ietf-ltans@imc.org > > Cc: Carl Wallace > > Subject: validate draft - RE: TSA key and revocation checking > > > > Hello Carl, Peter, Santosh and Julien, > > > > > > > > thank you for bringing this is up: > > > > At first this is just a _proposal_ about how to verify and what > might be needed. > > > > Stefanie and I thought about what people need to store within the TS > in ERS to verify it at any later point in time. > > > > (although we have the protection of the later ArchiveTimestampchains > and -sequences for the integrity of the inner data, but still some > problems arise due to the fact that you can expect _online_ status > requests to fail e.g. when TSAs shut down or even after guaranteed > timeframes of availability of about 30 years.) > > > > > > > > My thoughts in the presentation (as well as in the validate-draft) > are the following: > > > > 0) theoretically to verify a TS it is necessary to store all > certificates up to the root plus check their status (especially for > revocation). > > > > (and in the case that you are not able to make the status request > live and online you may also start to consider to also store all > certificates used in signing the OCSP or CRLs, and their certificate > chains and their OCSP responses, etc.) > > > > > > > > 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a > government body itself or certified by a government body) it could be > (depending on the laws and customs of the specific country) sufficient to > only store all certificates up to the root in the RFC3161-TS structures. > > > > This idea is based on the fact that it would be (inevitably) > publicly known when a key of a certified TSA would be compromised (and > revoked). > > > > This way you would not need to store OCSP or CRL for all > certificates (up to the root) used in the TS - and this would make things > a lot easier. > > > > > > > > Tobias > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Thursday, March 22, 2007 3:28 PM > > To: ietf-ltans@imc.org > > Subject: RE: TSA key and revocation checking > > > > > > > > I took the comment during the meeting to refer to scenario 2. > > > > > > > > > > ________________________________ > > > > > > From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr] > > Sent: Thursday, March 22, 2007 7:50 AM > > To: Carl Wallace > > Cc: ietf-ltans@imc.org > > Subject: Re: TSA key and revocation checking > > > > Carl Wallace a écrit : > > > > During yesterday's meeting, Tobias mentioned that a TSA key > could be trusted without checking its revocation status because compromise > of the key would be a widely known problem. I asked, via Jabber, how one > could confirm they had the correct TSA key and was directed to the mailing > list. While it may be true that the compromise of the TSA would be widely > known, would the revocation of a certificate issued in error to the same > name be as widely known? Recommending that revocation status not be > checked seems like a bad idea. We have means for representing and > processing revocation information, including the time of compromise, and > should simply use them. > > > > I am not sure what scenario is addressed: > > > > 1 - a client that obtains a time stamp and determines the > aujthenticity of the response > > 2 - a relying party that verifies the time stamp > > > > > > > > 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 l2N90SLj038086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 02:00:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2N90St5038085; Fri, 23 Mar 2007 02:00:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2N906rY038000 for ; Fri, 23 Mar 2007 02:00:27 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 7BDDF4F465 for ; Fri, 23 Mar 2007 09:59:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A673344146 for ; Fri, 23 Mar 2007 10:01:11 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20608-10 for ; Fri, 23 Mar 2007 10:01:08 +0100 (CET) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 1516344145 for ; Fri, 23 Mar 2007 10:01:07 +0100 (CET) Received: by mars.cry.pto (sSMTP sendmail emulation); Fri, 23 Mar 2007 09:59:59 +0100 From: "Julien Stern" Date: Fri, 23 Mar 2007 09:59:59 +0100 To: ietf-ltans@imc.org Subject: Re: validate draft - RE: TSA key and revocation checking Message-ID: <20070323085952.GA30562@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <886F5D4C78AFB14D87261206BFB9612E1CD70C3B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071ADBD7@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <82D5657AE1F54347A734BDD33637C879071ADBD7@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, I now agree too with Carl. Having a Trusted TSA would indeed be nice to avoid the online lookup at verification time, but that does not weight against the ability to revoke the certificate. Notably because the RootCA will typically be offline and rarely used, while the TSA will be online and heavily used. -- Julien On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote: > Tobias, > > > > I agree with Carl. > > > > For the refreshed time stamps, all the artifacts can be part of the time stamp or obtained from the PKI archive per I-D drafted by Carl. > > > > For current time stamp, objects should be available a la regular PKI. > > ________________________________ > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: Thursday, March 22, 2007 3:49 PM > To: ietf-ltans@imc.org > Subject: RE: validate draft - RE: TSA key and revocation checking > > > > In this case, I did correctly understand the intent of your proposal and feel the revocation status of the TSA certs should be checked. I don't see where this complicates things. The TSA is simply another EE certificate and artifacts necessary to verify EE certificates will already be preserved to verify signatures on documents. > > > > > ________________________________ > > > From: Tobias Gondrom [mailto:tgondrom@opentext.com] > Sent: Thursday, March 22, 2007 3:33 PM > To: ietf-ltans@imc.org > Cc: Carl Wallace > Subject: validate draft - RE: TSA key and revocation checking > > Hello Carl, Peter, Santosh and Julien, > > > > thank you for bringing this is up: > > At first this is just a _proposal_ about how to verify and what might be needed. > > Stefanie and I thought about what people need to store within the TS in ERS to verify it at any later point in time. > > (although we have the protection of the later ArchiveTimestampchains and -sequences for the integrity of the inner data, but still some problems arise due to the fact that you can expect _online_ status requests to fail e.g. when TSAs shut down or even after guaranteed timeframes of availability of about 30 years.) > > > > My thoughts in the presentation (as well as in the validate-draft) are the following: > > 0) theoretically to verify a TS it is necessary to store all certificates up to the root plus check their status (especially for revocation). > > (and in the case that you are not able to make the status request live and online you may also start to consider to also store all certificates used in signing the OCSP or CRLs, and their certificate chains and their OCSP responses, etc.) > > > > 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a government body itself or certified by a government body) it could be (depending on the laws and customs of the specific country) sufficient to only store all certificates up to the root in the RFC3161-TS structures. > > This idea is based on the fact that it would be (inevitably) publicly known when a key of a certified TSA would be compromised (and revoked). > > This way you would not need to store OCSP or CRL for all certificates (up to the root) used in the TS - and this would make things a lot easier. > > > > Tobias > > > > > > > > > > > > > ________________________________ > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: Thursday, March 22, 2007 3:28 PM > To: ietf-ltans@imc.org > Subject: RE: TSA key and revocation checking > > > > I took the comment during the meeting to refer to scenario 2. > > > > > ________________________________ > > > From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr] > Sent: Thursday, March 22, 2007 7:50 AM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > Carl Wallace a écrit : > > During yesterday's meeting, Tobias mentioned that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem. I asked, via Jabber, how one could confirm they had the correct TSA key and was directed to the mailing list. While it may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as widely known? Recommending that revocation status not be checked seems like a bad idea. We have means for representing and processing revocation information, including the time of compromise, and should simply use them. > > I am not sure what scenario is addressed: > > 1 - a client that obtains a time stamp and determines the aujthenticity of the response > 2 - a relying party that verifies the time stamp > > > > 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 l2N2M4Wx013686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 19:22:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2N2M4WH013685; Thu, 22 Mar 2007 19:22: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 EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2N2Lior013632 for ; Thu, 22 Mar 2007 19:22:04 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76CF0.06680354" Subject: RE: validate draft - RE: TSA key and revocation checking Date: Thu, 22 Mar 2007 19:07:17 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879071ADBD7@EXVS01.ex.dslextreme.net> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1CD70C3B@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: validate draft - RE: TSA key and revocation checking thread-index: AcdsvTTJqcPfCAzkQdi8oSK999ynLAAMkWXA References: <886F5D4C78AFB14D87261206BFB9612E1CD70C3B@scygmxs1.cygnacom.com> From: "Santosh Chokhani" 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_01C76CF0.06680354 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tobias, =20 I agree with Carl. =20 For the refreshed time stamps, all the artifacts can be part of the time = stamp or obtained from the PKI archive per I-D drafted by Carl. =20 For current time stamp, objects should be available a la regular PKI. ________________________________ From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, March 22, 2007 3:49 PM To: ietf-ltans@imc.org Subject: RE: validate draft - RE: TSA key and revocation checking =20 In this case, I did correctly understand the intent of your proposal and = feel the revocation status of the TSA certs should be checked. I don't = see where this complicates things. The TSA is simply another EE = certificate and artifacts necessary to verify EE certificates will = already be preserved to verify signatures on documents. =20 =09 ________________________________ From: Tobias Gondrom [mailto:tgondrom@opentext.com]=20 Sent: Thursday, March 22, 2007 3:33 PM To: ietf-ltans@imc.org Cc: Carl Wallace Subject: validate draft - RE: TSA key and revocation checking Hello Carl, Peter, Santosh and Julien,=20 =20 thank you for bringing this is up: At first this is just a _proposal_ about how to verify and what might = be needed.=20 Stefanie and I thought about what people need to store within the TS in = ERS to verify it at any later point in time. (although we have the protection of the later ArchiveTimestampchains = and -sequences for the integrity of the inner data, but still some = problems arise due to the fact that you can expect _online_ status = requests to fail e.g. when TSAs shut down or even after guaranteed = timeframes of availability of about 30 years.) =20 My thoughts in the presentation (as well as in the validate-draft) are = the following: 0) theoretically to verify a TS it is necessary to store all = certificates up to the root plus check their status (especially for = revocation).=20 (and in the case that you are not able to make the status request live = and online you may also start to consider to also store all certificates = used in signing the OCSP or CRLs, and their certificate chains and their = OCSP responses, etc.) =20 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a = government body itself or certified by a government body) it could be = (depending on the laws and customs of the specific country) sufficient = to only store all certificates up to the root in the RFC3161-TS = structures.=20 This idea is based on the fact that it would be (inevitably) publicly = known when a key of a certified TSA would be compromised (and revoked). This way you would not need to store OCSP or CRL for all certificates = (up to the root) used in the TS - and this would make things a lot = easier.=20 =20 Tobias =20 =20 =20 =20 =20 =09 ________________________________ From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, March 22, 2007 3:28 PM To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking =20 I took the comment during the meeting to refer to scenario 2. =20 =09 ________________________________ From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr]=20 Sent: Thursday, March 22, 2007 7:50 AM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Carl Wallace a =E9crit :=20 During yesterday's meeting, Tobias mentioned that a TSA key could be = trusted without checking its revocation status because compromise of the = key would be a widely known problem. I asked, via Jabber, how one could = confirm they had the correct TSA key and was directed to the mailing = list. While it may be true that the compromise of the TSA would be = widely known, would the revocation of a certificate issued in error to = the same name be as widely known? Recommending that revocation status = not be checked seems like a bad idea. We have means for representing = and processing revocation information, including the time of compromise, = and should simply use them. I am not sure what scenario is addressed: =09 1 - a client that obtains a time stamp and determines the = aujthenticity of the response 2 - a relying party that verifies the time stamp =09 =09 =09 ------_=_NextPart_001_01C76CF0.06680354 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TSA key and revocation checking

Tobias,

=

 

I agree with = Carl.

 

For the refreshed time stamps, all = the artifacts can be part of the time stamp or obtained from the PKI archive = per I-D drafted by Carl.

 

For current time stamp, objects = should be available a la regular PKI.

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl = Wallace
Sent: Thursday, March 22, = 2007 3:49 PM
To: ietf-ltans@imc.org
Subject: RE: validate = draft - RE: TSA key and revocation checking

 

In this case, I = did correctly understand the intent of your proposal and feel the revocation = status of the TSA certs should be checked.  I don't see where this = complicates things.  The TSA is simply another EE certificate and artifacts = necessary to verify EE certificates will already be preserved to verify signatures = on documents.

 

From: Tobias = Gondrom [mailto:tgondrom@opentext.com]
Sent: Thursday, March 22, = 2007 3:33 PM
To: ietf-ltans@imc.org
Cc: Carl Wallace
Subject: validate draft - = RE: TSA key and revocation checking

Hello Carl, = Peter, Santosh and Julien,

 =

thank you for = bringing this is up:

At first this is = just a _proposal_ about how to verify and = what might be needed.

Stefanie and I = thought about what people need to store within the TS in ERS to verify it at any = later point in time.

(although we = have the protection of the later ArchiveTimestampchains and -sequences for the = integrity of the inner data, but still some problems arise due to the fact that = you can expect _online_ status = requests to fail e.g. when TSAs shut down or even after guaranteed timeframes of availability of about 30 years.)

 =

My thoughts in = the presentation (as well as in the validate-draft) are the = following:

0) theoretically = to verify a TS it is necessary to store all certificates up to the root = plus check their status (especially for revocation).

(and in the case = that you are not able to make the status request live and online you may also = start to consider to also store all certificates used in signing the OCSP or = CRLs, and their certificate chains and their OCSP responses, = etc.)

 =

1) What I = proposed is that to verify a TS from a trusted TSA (e.g. a government body itself or certified by a government body) it could be (depending on the laws and = customs of the specific country) sufficient to only store all certificates up to = the root in the RFC3161-TS structures.

This idea is = based on the fact that it would be (inevitably) publicly known when a key of a = certified TSA would be compromised (and revoked).

This way you = would not need to store OCSP or CRL for all certificates (up to the root) used in = the TS - and this would make things a lot easier.

 =

Tobias=

 =

 =

 =

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl = Wallace
Sent: Thursday, March 22, = 2007 3:28 PM
To: ietf-ltans@imc.org
Subject: RE: TSA key and revocation checking

 

I took the = comment during the meeting to refer to scenario 2.

 

From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr]
Sent: Thursday, March 22, = 2007 7:50 AM
To: Carl Wallace
Cc: ietf-ltans@imc.org
Subject: Re: TSA key and revocation checking

Carl = Wallace a =E9crit :

During yesterday's meeting, Tobias mentioned = that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem.  I asked, = via Jabber, how one could confirm they had the correct TSA key and was = directed to the mailing list.  While it may be true that the compromise of the = TSA would be widely known, would the revocation of a certificate issued in = error to the same name be as widely known?  Recommending that revocation = status not be checked seems like a bad idea.  We have means for representing = and processing revocation information, including the time of compromise, and = should simply use them.

 I am not sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the = aujthenticity of the response
2 -  a relying party that verifies the time stamp


------_=_NextPart_001_01C76CF0.06680354-- 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 l2MJnqSf087427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 12:49:52 -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 l2MJnqnh087426; Thu, 22 Mar 2007 12:49:52 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2MJnVMN087407 for ; Thu, 22 Mar 2007 12:49:51 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 3673 invoked from network); 22 Mar 2007 19:49:29 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Mar 2007 19:49:29 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 22 Mar 2007 19:49:29 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Mar 2007 15:49:29 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70C3B@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: RE: validate draft - RE: TSA key and revocation checking Date: Thu, 22 Mar 2007 15:49:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76CBB.34754B36" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76CBB.34754B36 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In this case, I did correctly understand the intent of your proposal = and feel the revocation status of the TSA certs should be checked. I don't = see where this complicates things. The TSA is simply another EE = certificate and artifacts necessary to verify EE certificates will already be preserved = to verify signatures on documents. _____ =20 From: Tobias Gondrom [mailto:tgondrom@opentext.com]=20 Sent: Thursday, March 22, 2007 3:33 PM To: ietf-ltans@imc.org Cc: Carl Wallace Subject: validate draft - RE: TSA key and revocation checking Hello Carl, Peter, Santosh and Julien,=20 =20 thank you for bringing this is up: At first this is just a _proposal_ about how to verify and what might = be needed.=20 Stefanie and I thought about what people need to store within the TS in = ERS to verify it at any later point in time. (although we have the protection of the later ArchiveTimestampchains = and -sequences for the integrity of the inner data, but still some problems arise due to the fact that you can expect _online_ status requests to = fail e.g. when TSAs shut down or even after guaranteed timeframes of = availability of about 30 years.) =20 My thoughts in the presentation (as well as in the validate-draft) are = the following: 0) theoretically to verify a TS it is necessary to store all = certificates up to the root plus check their status (especially for revocation).=20 (and in the case that you are not able to make the status request live = and online you may also start to consider to also store all certificates = used in signing the OCSP or CRLs, and their certificate chains and their OCSP responses, etc.) =20 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a government body itself or certified by a government body) it could be (depending on the laws and customs of the specific country) sufficient = to only store all certificates up to the root in the RFC3161-TS = structures.=20 This idea is based on the fact that it would be (inevitably) publicly = known when a key of a certified TSA would be compromised (and revoked). This way you would not need to store OCSP or CRL for all certificates = (up to the root) used in the TS - and this would make things a lot easier.=20 =20 Tobias =20 =20 =20 =20 =20 _____ =20 From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, March 22, 2007 3:28 PM To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking =20 I took the comment during the meeting to refer to scenario 2. =20 _____ =20 From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr]=20 Sent: Thursday, March 22, 2007 7:50 AM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Carl Wallace a =E9crit :=20 During yesterday's meeting, Tobias mentioned that a TSA key could be = trusted without checking its revocation status because compromise of the key = would be a widely known problem. I asked, via Jabber, how one could confirm = they had the correct TSA key and was directed to the mailing list. While it = may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as = widely known? Recommending that revocation status not be checked seems like a = bad idea. We have means for representing and processing revocation = information, including the time of compromise, and should simply use them. I am not sure what scenario is addressed: 1 - a client that obtains a time stamp and determines the = aujthenticity of the response 2 - a relying party that verifies the time stamp ------_=_NextPart_001_01C76CBB.34754B36 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable TSA key and revocation checking
In this case, I did correctly understand the = intent of your=20 proposal and feel the revocation status of the TSA certs should be=20 checked.  I don't see where this complicates things.  The TSA = is=20 simply another EE certificate and artifacts necessary to verify EE = certificates=20 will already be preserved to verify signatures on=20 documents.

From: Tobias Gondrom=20 [mailto:tgondrom@opentext.com]
Sent: Thursday, March 22, = 2007 3:33=20 PM
To: ietf-ltans@imc.org
Cc: Carl=20 Wallace
Subject: validate draft - RE: TSA key and = revocation=20 checking

Hello = Carl, Peter,=20 Santosh and Julien,

 

thank you = for=20 bringing this is up:

At first = this is just=20 a _proposal_ about = how to=20 verify and what might be needed.

Stefanie = and I=20 thought about what people need to store within the TS in ERS to = verify it at=20 any later point in time.

(although = we have the=20 protection of the later ArchiveTimestampchains and -sequences for the = integrity of the inner data, but still some problems arise due to the = fact=20 that you can expect _online_=20 status requests to fail e.g. when TSAs shut down or even after = guaranteed=20 timeframes of availability of about 30 = years.)

 

My = thoughts in the=20 presentation (as well as in the validate-draft) are the=20 following:

0) = theoretically to=20 verify a TS it is necessary to store all certificates up to the root = plus=20 check their status (especially for revocation). =

(and in = the case that=20 you are not able to make the status request live and online you may = also start=20 to consider to also store all certificates used in signing the OCSP = or CRLs,=20 and their certificate chains and their OCSP responses,=20 etc.)

 

1) What I = proposed is=20 that to verify a TS from a trusted TSA (e.g. a government body itself = or=20 certified by a government body) it could be (depending on the laws = and customs=20 of the specific country) sufficient to only store all certificates up = to the=20 root in the RFC3161-TS structures.

This idea = is based on=20 the fact that it would be (inevitably) publicly known when a key of a = certified TSA would be compromised (and = revoked).

This way = you would=20 not need to store OCSP or CRL for all certificates (up to the root) = used in=20 the TS - and this would make things a lot easier.=20

 

Tobias

 

 

 

 

 

From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Carl = Wallace
Sent: Thursday, March 22, 2007 = 3:28=20 PM
To:=20 ietf-ltans@imc.org
Subject:=20 RE: TSA key and revocation checking

 

I took the = comment=20 during the meeting to refer to scenario = 2.

 

From: Peter Sylvester=20 [mailto:peter.sylvester@edelweb.fr]
Sent: Thursday, March 22, = 2007 7:50=20 AM
To: Carl=20 Wallace
Cc:=20 ietf-ltans@imc.org
Subject:=20 Re: TSA key and revocation checking

Carl Wallace a =E9crit :=20

During yesterday's meeting, Tobias = mentioned that a=20 TSA key could be trusted without checking its revocation status = because=20 compromise of the key would be a widely known problem.  I = asked, via=20 Jabber, how one could confirm they had the correct TSA key and was = directed=20 to the mailing list.  While it may be true that the compromise = of the=20 TSA would be widely known, would the revocation of a certificate = issued in=20 error to the same name be as widely known?  Recommending that=20 revocation status not be checked seems like a bad idea.  We = have means=20 for representing and processing revocation information, including = the time=20 of compromise, and should simply use = them.

 I am = not sure what=20 scenario is addressed:

1 -  a client that obtains a = time stamp=20 and determines the aujthenticity of the response
2 -  a = relying=20 party that verifies the time=20 = stamp



------_=_NextPart_001_01C76CBB.34754B36-- 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 l2MJXoBr086330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 12:33:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2MJXopr086329; Thu, 22 Mar 2007 12:33:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MJXSVx086316 for ; Thu, 22 Mar 2007 12:33:49 -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 l2MJXPIq008779; Thu, 22 Mar 2007 20:33:26 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76CB8.F57876D7" Subject: validate draft - RE: TSA key and revocation checking Date: Thu, 22 Mar 2007 20:33:24 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868C07295@MUCXGC2.opentext.net> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1CD70BFA@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: validate draft - RE: TSA key and revocation checking Thread-Index: AcdskBelV/Nb4P9SRdGGuKxENmnE0gAJg4+Q 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_01C76CB8.F57876D7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Carl, Peter, Santosh and Julien,=20 =20 thank you for bringing this is up: At first this is just a _proposal_ about how to verify and what might be = needed.=20 Stefanie and I thought about what people need to store within the TS in = ERS to verify it at any later point in time. (although we have the protection of the later ArchiveTimestampchains and = -sequences for the integrity of the inner data, but still some problems = arise due to the fact that you can expect _online_ status requests to = fail e.g. when TSAs shut down or even after guaranteed timeframes of = availability of about 30 years.) =20 My thoughts in the presentation (as well as in the validate-draft) are = the following: 0) theoretically to verify a TS it is necessary to store all = certificates up to the root plus check their status (especially for = revocation).=20 (and in the case that you are not able to make the status request live = and online you may also start to consider to also store all certificates = used in signing the OCSP or CRLs, and their certificate chains and their = OCSP responses, etc.) =20 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a = government body itself or certified by a government body) it could be = (depending on the laws and customs of the specific country) sufficient = to only store all certificates up to the root in the RFC3161-TS = structures.=20 This idea is based on the fact that it would be (inevitably) publicly = known when a key of a certified TSA would be compromised (and revoked). This way you would not need to store OCSP or CRL for all certificates = (up to the root) used in the TS - and this would make things a lot = easier.=20 =20 Tobias =20 =20 =20 =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, March 22, 2007 3:28 PM To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking =20 I took the comment during the meeting to refer to scenario 2. =20 =09 ________________________________ From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr]=20 Sent: Thursday, March 22, 2007 7:50 AM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Carl Wallace a =E9crit :=20 During yesterday's meeting, Tobias mentioned that a TSA key could be = trusted without checking its revocation status because compromise of the = key would be a widely known problem. I asked, via Jabber, how one could = confirm they had the correct TSA key and was directed to the mailing = list. While it may be true that the compromise of the TSA would be = widely known, would the revocation of a certificate issued in error to = the same name be as widely known? Recommending that revocation status = not be checked seems like a bad idea. We have means for representing = and processing revocation information, including the time of compromise, = and should simply use them. I am not sure what scenario is addressed: =09 1 - a client that obtains a time stamp and determines the = aujthenticity of the response 2 - a relying party that verifies the time stamp =09 =09 =09 =09 ------_=_NextPart_001_01C76CB8.F57876D7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TSA key and revocation checking

Hello Carl, = Peter, Santosh and Julien,

 =

thank you for = bringing this is up:

At first this is = just a _proposal_ about how to verify and = what might be needed.

Stefanie and I = thought about what people need to store within the TS in ERS to verify it at any = later point in time.

(although we = have the protection of the later ArchiveTimestampchains and –sequences for = the integrity of the inner data, but still some problems arise due to the fact that = you can expect _online_ status = requests to fail e.g. when TSAs shut down or even after guaranteed timeframes of availability of about 30 years.)

 =

My thoughts in = the presentation (as well as in the validate-draft) are the = following:

0) theoretically = to verify a TS it is necessary to store all certificates up to the root = plus check their status (especially for revocation).

(and in the case = that you are not able to make the status request live and online you may also = start to consider to also store all certificates used in signing the OCSP or = CRLs, and their certificate chains and their OCSP responses, = etc.)

 =

1) What I = proposed is that to verify a TS from a trusted TSA (e.g. a government body itself or = certified by a government body) it could be (depending on the laws and customs of = the specific country) sufficient to only store all certificates up to the root in the RFC3161-TS structures.

This idea is = based on the fact that it would be (inevitably) publicly known when a key of a = certified TSA would be compromised (and revoked).

This way you = would not need to store OCSP or CRL for all certificates (up to the root) used in = the TS – and this would make things a lot easier.

 =

Tobias=

 =

 =

 =

 =

 =

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Thursday, March 22, = 2007 3:28 PM
To: = ietf-ltans@imc.org
Subject: RE: TSA key and revocation checking

 

I took the comment during the = meeting to refer to scenario 2.

 

From: Peter = Sylvester [mailto:peter.sylvester@edelweb.fr]
Sent: Thursday, March 22, = 2007 7:50 AM
To: Carl Wallace
Cc: = ietf-ltans@imc.org
Subject: Re: TSA key and revocation checking

Carl Wallace a =E9crit : =

During yesterday's meeting, Tobias mentioned that a TSA key could be trusted = without checking its revocation status because compromise of the key would be a = widely known problem.  I asked, via Jabber, how one could confirm they had = the correct TSA key and was directed to the mailing list.  While it may = be true that the compromise of the TSA would be widely known, would the = revocation of a certificate issued in error to the same name be as widely = known?  Recommending that revocation status not be checked seems like a bad = idea.  We have means for representing and processing revocation information, = including the time of compromise, and should simply use = them.

 I am not = sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the = aujthenticity of the response
2 -  a relying party that verifies the time stamp



------_=_NextPart_001_01C76CB8.F57876D7-- 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 l2MESlCt065163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 07:28: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 l2MESleH065162; Thu, 22 Mar 2007 07:28: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2MESPZL065127 for ; Thu, 22 Mar 2007 07:28:46 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 1435 invoked from network); 22 Mar 2007 14:28:23 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Mar 2007 14:28:23 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 22 Mar 2007 14:28:23 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Mar 2007 10:28:23 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70BFA@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking Date: Thu, 22 Mar 2007 10:28:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C8E.58751240" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76C8E.58751240 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I took the comment during the meeting to refer to scenario 2. _____ =20 From: Peter Sylvester [mailto:peter.sylvester@edelweb.fr]=20 Sent: Thursday, March 22, 2007 7:50 AM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Carl Wallace a =E9crit :=20 During yesterday's meeting, Tobias mentioned that a TSA key could be = trusted without checking its revocation status because compromise of the key = would be a widely known problem. I asked, via Jabber, how one could confirm = they had the correct TSA key and was directed to the mailing list. While it = may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as = widely known? Recommending that revocation status not be checked seems like a = bad idea. We have means for representing and processing revocation = information, including the time of compromise, and should simply use them. I am not sure what scenario is addressed: 1 - a client that obtains a time stamp and determines the = aujthenticity of the response 2 - a relying party that verifies the time stamp ------_=_NextPart_001_01C76C8E.58751240 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable TSA key and revocation checking
I took the comment during the meeting to refer = to scenario 2.

From: Peter Sylvester=20 [mailto:peter.sylvester@edelweb.fr]
Sent: Thursday, March = 22, 2007=20 7:50 AM
To: Carl Wallace
Cc:=20 ietf-ltans@imc.org
Subject: Re: TSA key and revocation=20 checking

Carl Wallace a =E9crit :=20

During yesterday's meeting, Tobias mentioned that = a TSA key=20 could be trusted without checking its revocation status because = compromise=20 of the key would be a widely known problem.  I asked, via = Jabber, how=20 one could confirm they had the correct TSA key and was directed to = the=20 mailing list.  While it may be true that the compromise of the = TSA=20 would be widely known, would the revocation of a certificate issued = in error=20 to the same name be as widely known?  Recommending that = revocation=20 status not be checked seems like a bad idea.  We have means = for=20 representing and processing revocation information, including the = time of=20 compromise, and should simply use = them.

 I am not=20 sure what scenario is addressed:

1 -  a client that = obtains a time=20 stamp and determines the aujthenticity of the response
2 -  a = relying=20 party that verifies the time=20 stamp




------_=_NextPart_001_01C76C8E.58751240-- 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 l2MBoFEW051106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 04:50:15 -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 l2MBoFBr051105; Thu, 22 Mar 2007 04:50:15 -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 l2MBnsBl051064 for ; Thu, 22 Mar 2007 04:50:14 -0700 (MST) (envelope-from peter.sylvester@edelweb.fr) Received: from [130.129.50.116] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l2MBno504782; Thu, 22 Mar 2007 12:49:50 +0100 (MET) Message-ID: <46026D5B.3070505@edelweb.fr> Date: Thu, 22 Mar 2007 12:49:47 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Carl Wallace CC: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> Content-Type: multipart/alternative; boundary="------------060203070402050504070103" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------060203070402050504070103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Carl Wallace a écrit : > > During yesterday's meeting, Tobias mentioned that a TSA key could be > trusted without checking its revocation status because compromise of > the key would be a widely known problem. I asked, via Jabber, how one > could confirm they had the correct TSA key and was directed to the > mailing list. While it may be true that the compromise of the TSA > would be widely known, would the revocation of a certificate issued in > error to the same name be as widely known? Recommending that > revocation status not be checked seems like a bad idea. We have means > for representing and processing revocation information, including the > time of compromise, and should simply use them. > I am not sure what scenario is addressed: 1 - a client that obtains a time stamp and determines the aujthenticity of the response 2 - a relying party that verifies the time stamp --------------060203070402050504070103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Carl Wallace a écrit :
TSA key and revocation checking

During yesterday's meeting, Tobias mentioned that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem.  I asked, via Jabber, how one could confirm they had the correct TSA key and was directed to the mailing list.  While it may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as widely known?  Recommending that revocation status not be checked seems like a bad idea.  We have means for representing and processing revocation information, including the time of compromise, and should simply use them.

 I am not sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the aujthenticity of the response
2 -  a relying party that verifies the time stamp




--------------060203070402050504070103-- 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 l2LIQtNE082310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 11:26:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LIQttk082309; Wed, 21 Mar 2007 11:26:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LIQXsa082277 for ; Wed, 21 Mar 2007 11:26:54 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 051884105F for ; Wed, 21 Mar 2007 19:26:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id EAB6244146 for ; Wed, 21 Mar 2007 19:27:38 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21250-01 for ; Wed, 21 Mar 2007 19:27:28 +0100 (CET) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id B2C3044145 for ; Wed, 21 Mar 2007 19:27:27 +0100 (CET) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 21 Mar 2007 19:26:21 +0100 From: "Julien Stern" Date: Wed, 21 Mar 2007 19:26:21 +0100 To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Message-ID: <20070321182620.GL1235@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh, Carl, thanks to you both for your replies. To summarize: - a TSA cert is certified by a CA and chains to a Trust Anchor - the old revocation artifacts of the inner timestamps need not be retrieved as they have been checked during refreshing (and/or have been protected by inner timestamps) - the old revocation artifacts of the outer timestamp needs not be retrieved as the revocation checking is done at current time This prohibits the revocation followed by the Remove_From_CRL of the TSA certificate, but I guess no-one would want to do that anyway :) After your clarification, I'm definitely also for standard revocation checking of the TSA certificate and not for out-of-band mechanisms. Sorry for the interruption and thanks again. -- Julien On Wed, Mar 21, 2007 at 10:51:51AM -0700, Santosh Chokhani wrote: > > Julien, > > As Carl Wallace said, for the out most time stamp you need not save the > trust anchor or CRL. That should be verified as of present time. > > I may be wrong, but the LTANS specs do not address compromise recovery, > i.e., what to do about time stamps if the TSA revoked (compromised) > before a time stamp is refreshed. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 11:07 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: > > > > Julien, > > > > If you have not used LTANS work of trusted archive (time stamp > refresh) > > and protected the payload, you should be able to verify the time stamp > > as of the time of time stamp using the revocation artifacts as of that > > time. > > > > If you are using LTANS trusted archive, look at the step 3 in Section > > 5.3 of ERS I-D. It calls for verifying each time stamp as of the time > > of the next time stamp. In other words, time stamp must be refreshed > > before the TSA is revoked or expires. > > Santosh, > > I'm all for avoiding the need to store old revocation artifacts, > especially since they may become invalid at any time after a compromise. > > Also, I have no issue with all the "internal" layers. My only question > regards the outer layer. In order to verify the outer timestamp > signature, it seems to me that you need in any case to retrieve the > revocation artifacts at the time the timestamp was made. But maybe I'm > missing an hypothesis that enables verification with current revocation > information instead. > > -- > Julien > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > > Sent: Wednesday, March 21, 2007 10:08 AM > > To: ietf-ltans@imc.org > > Subject: Re: TSA key and revocation checking > > > > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > > I agree with Carl. Not checking revocation status and relying on > > > non-automated, other means is a bad idea. > > > > I agree on the general principle. But in the specific LTANS settings, > I > > think the TSA certificate will be in some sense more "trusted" than > the > > CA that issued it. > > > > The specific setting I have in mind is the following: > > - say you are doing long term archiving (of signatures for instance) > > - also say that you have archived ALL artifacts (certs, OCSP, CRLs, > etc) > > - Many years after, you want to check your archive > > > > If the TSA key is not trusted out-of-band, you need information to > > verify its revocation status, but this information cannot be included > > in the timestamped archive itself as that would cause a chicken and > egg > > problem. Question: how do you obtain it ? > > > > I one can come up with a solution that solves this chicken and egg > > and allows for revocation checking, I'm all for it, but we have to > > keep this issue in mind. > > > > -- > > Julien > > > > > ________________________________ > > > > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > > Sent: Wednesday, March 21, 2007 6:46 AM > > > To: ietf-ltans@imc.org > > > Subject: TSA key and revocation checking > > > > > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > > > trusted without checking its revocation status because compromise of > > the > > > key would be a widely known problem. I asked, via Jabber, how one > > could > > > confirm they had the correct TSA key and was directed to the mailing > > > list. While it may be true that the compromise of the TSA would be > > > widely known, would the revocation of a certificate issued in error > to > > > the same name be as widely known? Recommending that revocation > status > > > not be checked seems like a bad idea. We have means for > representing > > > and processing revocation information, including the time of > > compromise, > > > and should simply use them. > > > > > > > > > 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 l2LIOI7P082150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 11:24:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LIOI2v082149; Wed, 21 Mar 2007 11:24:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LINv16082099 for ; Wed, 21 Mar 2007 11:24:18 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=M+BwWDLAqk4OlLB5+jrppIjgWxParBPO9AmUQ1CWBsH4diOLV9Gel1OMA2k1mwgF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HU5TY-0007cN-J0; Wed, 21 Mar 2007 14:23:56 -0400 Message-ID: <006f01c76be6$16705860$174f7d40@home.glassey.com> From: "todd glassey" To: "Greg Werner" , "Santosh Chokhani" , References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> Subject: Re: TSA key and revocation checking Date: Wed, 21 Mar 2007 11:23:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec797e6c03d4e0344a7bd009e6dbf0f62b53350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Greg Werner" To: "Santosh Chokhani" ; Sent: Wednesday, March 21, 2007 11:11 AM Subject: RE: TSA key and revocation checking > > From what I understand Policies and Practices would define mechanisms for > infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, > etc.). Each country or region would define these mechanisms in order to > establish procedures and the proper legal framework for continued > operations. The problem is in digitally negotiating which T's and C's are constraining any TST's and the legal framework therein. > > 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. This is reasonable > 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. > > Does this make sense? yes, periodic review of the TSA Integrity is a good idea... but should be capable of being optionally ignored. > > -----Mensaje original----- > De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > En nombre de Santosh Chokhani > Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m. > Para: ietf-ltans@imc.org > Asunto: RE: TSA key and revocation checking > > > Julien, > > As Carl Wallace said, for the out most time stamp you need not save the > trust anchor or CRL. That should be verified as of present time. > > I may be wrong, but the LTANS specs do not address compromise recovery, > i.e., what to do about time stamps if the TSA revoked (compromised) > before a time stamp is refreshed. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 11:07 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: >> >> Julien, >> >> If you have not used LTANS work of trusted archive (time stamp > refresh) >> and protected the payload, you should be able to verify the time stamp >> as of the time of time stamp using the revocation artifacts as of that >> time. >> >> If you are using LTANS trusted archive, look at the step 3 in Section >> 5.3 of ERS I-D. It calls for verifying each time stamp as of the time >> of the next time stamp. In other words, time stamp must be refreshed >> before the TSA is revoked or expires. > > Santosh, > > I'm all for avoiding the need to store old revocation artifacts, > especially since they may become invalid at any time after a compromise. > > Also, I have no issue with all the "internal" layers. My only question > regards the outer layer. In order to verify the outer timestamp > signature, it seems to me that you need in any case to retrieve the > revocation artifacts at the time the timestamp was made. But maybe I'm > missing an hypothesis that enables verification with current revocation > information instead. > > -- > Julien > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern >> Sent: Wednesday, March 21, 2007 10:08 AM >> To: ietf-ltans@imc.org >> Subject: Re: TSA key and revocation checking >> >> >> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: >> > I agree with Carl. Not checking revocation status and relying on >> > non-automated, other means is a bad idea. >> >> I agree on the general principle. But in the specific LTANS settings, > I >> think the TSA certificate will be in some sense more "trusted" than > the >> CA that issued it. >> >> The specific setting I have in mind is the following: >> - say you are doing long term archiving (of signatures for instance) >> - also say that you have archived ALL artifacts (certs, OCSP, CRLs, > etc) >> - Many years after, you want to check your archive >> >> If the TSA key is not trusted out-of-band, you need information to >> verify its revocation status, but this information cannot be included >> in the timestamped archive itself as that would cause a chicken and > egg >> problem. Question: how do you obtain it ? >> >> I one can come up with a solution that solves this chicken and egg >> and allows for revocation checking, I'm all for it, but we have to >> keep this issue in mind. >> >> -- >> Julien >> >> > ________________________________ >> > >> > From: owner-ietf-ltans@mail.imc.org >> > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace >> > Sent: Wednesday, March 21, 2007 6:46 AM >> > To: ietf-ltans@imc.org >> > Subject: TSA key and revocation checking >> > >> > >> > >> > During yesterday's meeting, Tobias mentioned that a TSA key could be >> > trusted without checking its revocation status because compromise of >> the >> > key would be a widely known problem. I asked, via Jabber, how one >> could >> > confirm they had the correct TSA key and was directed to the mailing >> > list. While it may be true that the compromise of the TSA would be >> > widely known, would the revocation of a certificate issued in error > to >> > the same name be as widely known? Recommending that revocation > status >> > not be checked seems like a bad idea. We have means for > representing >> > and processing revocation information, including the time of >> compromise, >> > and should simply use them. >> > >> >> > > > > 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 l2LIKcAC081818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 11:20:38 -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 l2LIKcHT081817; Wed, 21 Mar 2007 11:20:38 -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 (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LIKcJY081811 for ; Wed, 21 Mar 2007 11:20:38 -0700 (MST) (envelope-from chokhani@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="iso-8859-1" Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 11:20:14 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87907110BEA@EXVS01.ex.dslextreme.net> In-Reply-To: <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking thread-index: AcdrzJOpxjlGqlUhS6iDL1DXQ1XabQAFMRSQAABfvPAAAJk9QA== References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> From: "Santosh Chokhani" To: "Greg Werner" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2LIKcJY081812 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg, Unless you define procedural means, there is a residual threat on detection of TSA compromise before the time stamp is refreshed. It is possible that if the immediately inner layer is still valid (nothing expired or revoked) and in that case, throwing out the outer layer and getting a new time stamp from a new authority makes sense. -----Original Message----- From: Greg Werner [mailto:gwerner@advantage-security.com] Sent: Wednesday, March 21, 2007 2:11 PM To: Santosh Chokhani; ietf-ltans@imc.org Subject: RE: TSA key and revocation checking >From what I understand Policies and Practices would define mechanisms for infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, etc.). Each country or region would define these mechanisms in order to establish procedures and the proper legal framework for continued operations. >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. Does this make sense? -----Mensaje original----- De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] En nombre de Santosh Chokhani Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m. Para: ietf-ltans@imc.org Asunto: RE: TSA key and revocation checking Julien, As Carl Wallace said, for the out most time stamp you need not save the trust anchor or CRL. That should be verified as of present time. I may be wrong, but the LTANS specs do not address compromise recovery, i.e., what to do about time stamps if the TSA revoked (compromised) before a time stamp is refreshed. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, March 21, 2007 11:07 AM To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: > > Julien, > > If you have not used LTANS work of trusted archive (time stamp refresh) > and protected the payload, you should be able to verify the time stamp > as of the time of time stamp using the revocation artifacts as of that > time. > > If you are using LTANS trusted archive, look at the step 3 in Section > 5.3 of ERS I-D. It calls for verifying each time stamp as of the time > of the next time stamp. In other words, time stamp must be refreshed > before the TSA is revoked or expires. Santosh, I'm all for avoiding the need to store old revocation artifacts, especially since they may become invalid at any time after a compromise. Also, I have no issue with all the "internal" layers. My only question regards the outer layer. In order to verify the outer timestamp signature, it seems to me that you need in any case to retrieve the revocation artifacts at the time the timestamp was made. But maybe I'm missing an hypothesis that enables verification with current revocation information instead. -- Julien > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 10:08 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > I agree with Carl. Not checking revocation status and relying on > > non-automated, other means is a bad idea. > > I agree on the general principle. But in the specific LTANS settings, I > think the TSA certificate will be in some sense more "trusted" than the > CA that issued it. > > The specific setting I have in mind is the following: > - say you are doing long term archiving (of signatures for instance) > - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) > - Many years after, you want to check your archive > > If the TSA key is not trusted out-of-band, you need information to > verify its revocation status, but this information cannot be included > in the timestamped archive itself as that would cause a chicken and egg > problem. Question: how do you obtain it ? > > I one can come up with a solution that solves this chicken and egg > and allows for revocation checking, I'm all for it, but we have to > keep this issue in mind. > > -- > Julien > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Wednesday, March 21, 2007 6:46 AM > > To: ietf-ltans@imc.org > > Subject: TSA key and revocation checking > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > > trusted without checking its revocation status because compromise of > the > > key would be a widely known problem. I asked, via Jabber, how one > could > > confirm they had the correct TSA key and was directed to the mailing > > list. While it may be true that the compromise of the TSA would be > > widely known, would the revocation of a certificate issued in error to > > the same name be as widely known? Recommending that revocation status > > not be checked seems like a bad idea. We have means for representing > > and processing revocation information, including the time of > compromise, > > and should simply use them. > > > > 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 l2LIAMIL080967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 11:10:22 -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 l2LIAMtJ080966; Wed, 21 Mar 2007 11:10:22 -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 advantage-security.com ([200.77.233.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LIA18O080899 for ; Wed, 21 Mar 2007 11:10:22 -0700 (MST) (envelope-from gwerner@advantage-security.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 12:11:06 -0600 Message-ID: <1815FE0A4A30A44BA2F9E367E1B00AB17B726B@corporativo.production.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking Thread-Index: AcdrzJOpxjlGqlUhS6iDL1DXQ1XabQAFMRSQAABfvPA= References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> From: "Greg Werner" To: "Santosh Chokhani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2LIAM8O080961 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From what I understand Policies and Practices would define mechanisms for infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, etc.). Each country or region would define these mechanisms in order to establish procedures and the proper legal framework for continued operations. >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. Does this make sense? -----Mensaje original----- De: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] En nombre de Santosh Chokhani Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m. Para: ietf-ltans@imc.org Asunto: RE: TSA key and revocation checking Julien, As Carl Wallace said, for the out most time stamp you need not save the trust anchor or CRL. That should be verified as of present time. I may be wrong, but the LTANS specs do not address compromise recovery, i.e., what to do about time stamps if the TSA revoked (compromised) before a time stamp is refreshed. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, March 21, 2007 11:07 AM To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: > > Julien, > > If you have not used LTANS work of trusted archive (time stamp refresh) > and protected the payload, you should be able to verify the time stamp > as of the time of time stamp using the revocation artifacts as of that > time. > > If you are using LTANS trusted archive, look at the step 3 in Section > 5.3 of ERS I-D. It calls for verifying each time stamp as of the time > of the next time stamp. In other words, time stamp must be refreshed > before the TSA is revoked or expires. Santosh, I'm all for avoiding the need to store old revocation artifacts, especially since they may become invalid at any time after a compromise. Also, I have no issue with all the "internal" layers. My only question regards the outer layer. In order to verify the outer timestamp signature, it seems to me that you need in any case to retrieve the revocation artifacts at the time the timestamp was made. But maybe I'm missing an hypothesis that enables verification with current revocation information instead. -- Julien > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 10:08 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > I agree with Carl. Not checking revocation status and relying on > > non-automated, other means is a bad idea. > > I agree on the general principle. But in the specific LTANS settings, I > think the TSA certificate will be in some sense more "trusted" than the > CA that issued it. > > The specific setting I have in mind is the following: > - say you are doing long term archiving (of signatures for instance) > - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) > - Many years after, you want to check your archive > > If the TSA key is not trusted out-of-band, you need information to > verify its revocation status, but this information cannot be included > in the timestamped archive itself as that would cause a chicken and egg > problem. Question: how do you obtain it ? > > I one can come up with a solution that solves this chicken and egg > and allows for revocation checking, I'm all for it, but we have to > keep this issue in mind. > > -- > Julien > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Wednesday, March 21, 2007 6:46 AM > > To: ietf-ltans@imc.org > > Subject: TSA key and revocation checking > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > > trusted without checking its revocation status because compromise of > the > > key would be a widely known problem. I asked, via Jabber, how one > could > > confirm they had the correct TSA key and was directed to the mailing > > list. While it may be true that the compromise of the TSA would be > > widely known, would the revocation of a certificate issued in error to > > the same name be as widely known? Recommending that revocation status > > not be checked seems like a bad idea. We have means for representing > > and processing revocation information, including the time of > compromise, > > and should simply use them. > > > > 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 l2LHqTKs079225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 10:52:29 -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 l2LHqTUO079224; Wed, 21 Mar 2007 10:52:29 -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 (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LHq9PA079082 for ; Wed, 21 Mar 2007 10:52:29 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 10:51:51 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87907110B3F@EXVS01.ex.dslextreme.net> In-Reply-To: <20070321150714.GK1235@mars.cry.pto> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking thread-index: AcdrzJOpxjlGqlUhS6iDL1DXQ1XabQAFMRSQ References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> <20070321150714.GK1235@mars.cry.pto> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2LHqTPA079219 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julien, As Carl Wallace said, for the out most time stamp you need not save the trust anchor or CRL. That should be verified as of present time. I may be wrong, but the LTANS specs do not address compromise recovery, i.e., what to do about time stamps if the TSA revoked (compromised) before a time stamp is refreshed. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, March 21, 2007 11:07 AM To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: > > Julien, > > If you have not used LTANS work of trusted archive (time stamp refresh) > and protected the payload, you should be able to verify the time stamp > as of the time of time stamp using the revocation artifacts as of that > time. > > If you are using LTANS trusted archive, look at the step 3 in Section > 5.3 of ERS I-D. It calls for verifying each time stamp as of the time > of the next time stamp. In other words, time stamp must be refreshed > before the TSA is revoked or expires. Santosh, I'm all for avoiding the need to store old revocation artifacts, especially since they may become invalid at any time after a compromise. Also, I have no issue with all the "internal" layers. My only question regards the outer layer. In order to verify the outer timestamp signature, it seems to me that you need in any case to retrieve the revocation artifacts at the time the timestamp was made. But maybe I'm missing an hypothesis that enables verification with current revocation information instead. -- Julien > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 10:08 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > I agree with Carl. Not checking revocation status and relying on > > non-automated, other means is a bad idea. > > I agree on the general principle. But in the specific LTANS settings, I > think the TSA certificate will be in some sense more "trusted" than the > CA that issued it. > > The specific setting I have in mind is the following: > - say you are doing long term archiving (of signatures for instance) > - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) > - Many years after, you want to check your archive > > If the TSA key is not trusted out-of-band, you need information to > verify its revocation status, but this information cannot be included > in the timestamped archive itself as that would cause a chicken and egg > problem. Question: how do you obtain it ? > > I one can come up with a solution that solves this chicken and egg > and allows for revocation checking, I'm all for it, but we have to > keep this issue in mind. > > -- > Julien > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Wednesday, March 21, 2007 6:46 AM > > To: ietf-ltans@imc.org > > Subject: TSA key and revocation checking > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > > trusted without checking its revocation status because compromise of > the > > key would be a widely known problem. I asked, via Jabber, how one > could > > confirm they had the correct TSA key and was directed to the mailing > > list. While it may be true that the compromise of the TSA would be > > widely known, would the revocation of a certificate issued in error to > > the same name be as widely known? Recommending that revocation status > > not be checked seems like a bad idea. We have means for representing > > and processing revocation information, including the time of > compromise, > > and should simply use them. > > > > 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 l2LF7jYu067630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 08:07: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 l2LF7jId067629; Wed, 21 Mar 2007 08:07: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 kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LF7NkJ067600 for ; Wed, 21 Mar 2007 08:07:44 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id C71044118F for ; Wed, 21 Mar 2007 16:07:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 404DA4413C for ; Wed, 21 Mar 2007 16:08:28 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19765-03 for ; Wed, 21 Mar 2007 16:08:22 +0100 (CET) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 2D2CD44103 for ; Wed, 21 Mar 2007 16:08:21 +0100 (CET) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 21 Mar 2007 16:07:15 +0100 From: "Julien Stern" Date: Wed, 21 Mar 2007 16:07:15 +0100 To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Message-ID: <20070321150714.GK1235@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote: > > Julien, > > If you have not used LTANS work of trusted archive (time stamp refresh) > and protected the payload, you should be able to verify the time stamp > as of the time of time stamp using the revocation artifacts as of that > time. > > If you are using LTANS trusted archive, look at the step 3 in Section > 5.3 of ERS I-D. It calls for verifying each time stamp as of the time > of the next time stamp. In other words, time stamp must be refreshed > before the TSA is revoked or expires. Santosh, I'm all for avoiding the need to store old revocation artifacts, especially since they may become invalid at any time after a compromise. Also, I have no issue with all the "internal" layers. My only question regards the outer layer. In order to verify the outer timestamp signature, it seems to me that you need in any case to retrieve the revocation artifacts at the time the timestamp was made. But maybe I'm missing an hypothesis that enables verification with current revocation information instead. -- Julien > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 10:08 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > I agree with Carl. Not checking revocation status and relying on > > non-automated, other means is a bad idea. > > I agree on the general principle. But in the specific LTANS settings, I > think the TSA certificate will be in some sense more "trusted" than the > CA that issued it. > > The specific setting I have in mind is the following: > - say you are doing long term archiving (of signatures for instance) > - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) > - Many years after, you want to check your archive > > If the TSA key is not trusted out-of-band, you need information to > verify its revocation status, but this information cannot be included > in the timestamped archive itself as that would cause a chicken and egg > problem. Question: how do you obtain it ? > > I one can come up with a solution that solves this chicken and egg > and allows for revocation checking, I'm all for it, but we have to > keep this issue in mind. > > -- > Julien > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Wednesday, March 21, 2007 6:46 AM > > To: ietf-ltans@imc.org > > Subject: TSA key and revocation checking > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > > trusted without checking its revocation status because compromise of > the > > key would be a widely known problem. I asked, via Jabber, how one > could > > confirm they had the correct TSA key and was directed to the mailing > > list. While it may be true that the compromise of the TSA would be > > widely known, would the revocation of a certificate issued in error to > > the same name be as widely known? Recommending that revocation status > > not be checked seems like a bad idea. We have means for representing > > and processing revocation information, including the time of > compromise, > > and should simply use them. > > > > 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 l2LF7Z0L067615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 08:07:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LF7ZjC067614; Wed, 21 Mar 2007 08:07:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2LF7YJk067606 for ; Wed, 21 Mar 2007 08:07:34 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 24772 invoked from network); 21 Mar 2007 15:07:33 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Mar 2007 15:07:33 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 Mar 2007 15:07:33 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Mar 2007 11:07:33 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70BAB@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 11:07:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BCA.A60101C8" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76BCA.A60101C8 Content-Type: text/plain > Doesn't this mean that you need to provide the verification > algorithm with the current trust anchor and the revocation > information AT THE TIME the outer layer was timestamped? > (Implying the need to keep all revocation material for the > current CAs for a long time). No. The outer layer must be valid at verification time. There's no need to capture to revocation information and trust anchor at the time it was timestamped. This should be captured when the next timestamp is applied. ------_=_NextPart_001_01C76BCA.A60101C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: TSA key and revocation checking

> Doesn't this mean that you need to provide the = verification
> algorithm with the current trust anchor and the = revocation
> information AT THE TIME the outer layer was = timestamped?
> (Implying the need to keep all revocation = material for the
> current CAs for a long time).

No.  The outer layer must be valid at = verification time.  There's no need to capture to revocation = information and trust anchor at the time it was timestamped.  This = should be captured when the next timestamp is applied.

------_=_NextPart_001_01C76BCA.A60101C8-- 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 l2LF17C0067191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 08:01:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LF17j5067190; Wed, 21 Mar 2007 08:01:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LF16kH067184 for ; Wed, 21 Mar 2007 08:01:06 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 6B4C04F4C2 for ; Wed, 21 Mar 2007 16:00:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 37B274413C for ; Wed, 21 Mar 2007 16:02:11 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19724-02 for ; Wed, 21 Mar 2007 16:02:06 +0100 (CET) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id B2D4D44103 for ; Wed, 21 Mar 2007 16:02:05 +0100 (CET) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 21 Mar 2007 16:00:59 +0100 From: "Julien Stern" Date: Wed, 21 Mar 2007 16:00:59 +0100 To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Message-ID: <20070321150059.GJ1235@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <886F5D4C78AFB14D87261206BFB9612E1CD70BA3@scygmxs1.cygnacom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1CD70BA3@scygmxs1.cygnacom.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 21, 2007 at 10:28:52AM -0400, Carl Wallace wrote: > There is no chicken and egg problem because the outer layer is verifed using > current information. You must have the current trust anchor available > through trusted means and can use it to verify the TSA signature. Interior > layers are protected by the adjacent outer layer. Doesn't this mean that you need to provide the verification algorithm with the current trust anchor and the revocation information AT THE TIME the outer layer was timestamped? (Implying the need to keep all revocation material for the current CAs for a long time). -- Julien > This issue was addressed in the pre-LTANS TAP draft. Maybe there needs to > be a mechanism included in LTAP to obtain historical trust anchors. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > > Sent: Wednesday, March 21, 2007 10:08 AM > > To: ietf-ltans@imc.org > > Subject: Re: TSA key and revocation checking > > > > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > > I agree with Carl. Not checking revocation status and relying on > > > non-automated, other means is a bad idea. > > > > I agree on the general principle. But in the specific LTANS > > settings, I think the TSA certificate will be in some sense > > more "trusted" than the CA that issued it. > > > > The specific setting I have in mind is the following: > > - say you are doing long term archiving (of signatures for instance) > > - also say that you have archived ALL artifacts (certs, OCSP, > > CRLs, etc) > > - Many years after, you want to check your archive > > > > If the TSA key is not trusted out-of-band, you need > > information to verify its revocation status, but this > > information cannot be included in the timestamped archive > > itself as that would cause a chicken and egg problem. > > Question: how do you obtain it ? > > > > I one can come up with a solution that solves this chicken > > and egg and allows for revocation checking, I'm all for it, > > but we have to keep this issue in mind. > > > > -- > > Julien > > > > > ________________________________ > > > > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > > Sent: Wednesday, March 21, 2007 6:46 AM > > > To: ietf-ltans@imc.org > > > Subject: TSA key and revocation checking > > > > > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key > > could be > > > trusted without checking its revocation status because > > compromise of > > > the key would be a widely known problem. I asked, via > > Jabber, how one > > > could confirm they had the correct TSA key and was directed to the > > > mailing list. While it may be true that the compromise of the TSA > > > would be widely known, would the revocation of a > > certificate issued in > > > error to the same name be as widely known? Recommending that > > > revocation status not be checked seems like a bad idea. We > > have means > > > for representing and processing revocation information, > > including the > > > time of compromise, and should simply use them. > > > > > 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 l2LEpExe066433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 07:51:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LEpExl066432; Wed, 21 Mar 2007 07:51:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LEpDuS066426 for ; Wed, 21 Mar 2007 07:51:14 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 07:50:41 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879071107C5@EXVS01.ex.dslextreme.net> In-Reply-To: <20070321140826.GI1235@mars.cry.pto> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking thread-index: AcdrxJ8xjhgpRCKTRJGaKzMOm6KYGwAAN8Zw References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> <20070321140826.GI1235@mars.cry.pto> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2LEpEuS066427 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Julien, If you have not used LTANS work of trusted archive (time stamp refresh) and protected the payload, you should be able to verify the time stamp as of the time of time stamp using the revocation artifacts as of that time. If you are using LTANS trusted archive, look at the step 3 in Section 5.3 of ERS I-D. It calls for verifying each time stamp as of the time of the next time stamp. In other words, time stamp must be refreshed before the TSA is revoked or expires. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern Sent: Wednesday, March 21, 2007 10:08 AM To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > I agree with Carl. Not checking revocation status and relying on > non-automated, other means is a bad idea. I agree on the general principle. But in the specific LTANS settings, I think the TSA certificate will be in some sense more "trusted" than the CA that issued it. The specific setting I have in mind is the following: - say you are doing long term archiving (of signatures for instance) - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) - Many years after, you want to check your archive If the TSA key is not trusted out-of-band, you need information to verify its revocation status, but this information cannot be included in the timestamped archive itself as that would cause a chicken and egg problem. Question: how do you obtain it ? I one can come up with a solution that solves this chicken and egg and allows for revocation checking, I'm all for it, but we have to keep this issue in mind. -- Julien > ________________________________ > > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: Wednesday, March 21, 2007 6:46 AM > To: ietf-ltans@imc.org > Subject: TSA key and revocation checking > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > trusted without checking its revocation status because compromise of the > key would be a widely known problem. I asked, via Jabber, how one could > confirm they had the correct TSA key and was directed to the mailing > list. While it may be true that the compromise of the TSA would be > widely known, would the revocation of a certificate issued in error to > the same name be as widely known? Recommending that revocation status > not be checked seems like a bad idea. We have means for representing > and processing revocation information, including the time of compromise, > and should simply use them. > 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 l2LETRTP063860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 07:29:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LETRBh063859; Wed, 21 Mar 2007 07:29:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2LET5M7063700 for ; Wed, 21 Mar 2007 07:29:26 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 24452 invoked from network); 21 Mar 2007 14:29:03 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Mar 2007 14:29:03 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 Mar 2007 14:29:03 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Mar 2007 10:29:03 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70BA3@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 10:28:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BC5.3FF4E4A8" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76BC5.3FF4E4A8 Content-Type: text/plain There is no chicken and egg problem because the outer layer is verifed using current information. You must have the current trust anchor available through trusted means and can use it to verify the TSA signature. Interior layers are protected by the adjacent outer layer. This issue was addressed in the pre-LTANS TAP draft. Maybe there needs to be a mechanism included in LTAP to obtain historical trust anchors. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, March 21, 2007 10:08 AM > To: ietf-ltans@imc.org > Subject: Re: TSA key and revocation checking > > > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > > I agree with Carl. Not checking revocation status and relying on > > non-automated, other means is a bad idea. > > I agree on the general principle. But in the specific LTANS > settings, I think the TSA certificate will be in some sense > more "trusted" than the CA that issued it. > > The specific setting I have in mind is the following: > - say you are doing long term archiving (of signatures for instance) > - also say that you have archived ALL artifacts (certs, OCSP, > CRLs, etc) > - Many years after, you want to check your archive > > If the TSA key is not trusted out-of-band, you need > information to verify its revocation status, but this > information cannot be included in the timestamped archive > itself as that would cause a chicken and egg problem. > Question: how do you obtain it ? > > I one can come up with a solution that solves this chicken > and egg and allows for revocation checking, I'm all for it, > but we have to keep this issue in mind. > > -- > Julien > > > ________________________________ > > > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > > Sent: Wednesday, March 21, 2007 6:46 AM > > To: ietf-ltans@imc.org > > Subject: TSA key and revocation checking > > > > > > > > During yesterday's meeting, Tobias mentioned that a TSA key > could be > > trusted without checking its revocation status because > compromise of > > the key would be a widely known problem. I asked, via > Jabber, how one > > could confirm they had the correct TSA key and was directed to the > > mailing list. While it may be true that the compromise of the TSA > > would be widely known, would the revocation of a > certificate issued in > > error to the same name be as widely known? Recommending that > > revocation status not be checked seems like a bad idea. We > have means > > for representing and processing revocation information, > including the > > time of compromise, and should simply use them. > > > ------_=_NextPart_001_01C76BC5.3FF4E4A8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: TSA key and revocation checking

There is no chicken and egg problem because the outer = layer is verifed using current information.  You must have the = current trust anchor available through trusted means and can use it to = verify the TSA signature.  Interior layers are protected by the = adjacent outer layer. 

This issue was addressed in the pre-LTANS TAP = draft.  Maybe there needs to be a mechanism included in LTAP to = obtain historical trust anchors.

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
> [mailto:owner-ietf-ltans@ma= il.imc.org] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: ietf-ltans@imc.org
> Subject: Re: TSA key and revocation = checking
>
>
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, = Santosh Chokhani wrote:
> > I agree with Carl.  Not checking = revocation status and relying on
> > non-automated, other means is a bad = idea.
>
> I agree on the general principle. But in the = specific LTANS
> settings, I think the TSA certificate will be = in some sense
> more "trusted" than the CA that = issued it.
>
> The specific setting I have in mind is the = following:
> - say you are doing long term archiving (of = signatures for instance)
> - also say that you have archived ALL artifacts = (certs, OCSP,
> CRLs, etc)
> - Many years after, you want to check your = archive
>
> If the TSA key is not trusted out-of-band, you = need
> information to verify its revocation status, = but this
> information cannot be included in the = timestamped archive
> itself as that would cause a chicken and egg = problem.
> Question: how do you obtain it ?
>
> I one can come up with a solution that solves = this chicken
> and egg and allows for revocation checking, I'm = all for it,
> but we have to keep this issue in mind.
>
> --
> Julien
>
> > ________________________________
> >
> > From: owner-ietf-ltans@mail.imc.org
> > [mailto:owner-ietf-ltans@ma= il.imc.org] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 = AM
> > To: ietf-ltans@imc.org
> > Subject: TSA key and revocation = checking
> >
> > 
> >
> > During yesterday's meeting, Tobias = mentioned that a TSA key
> could be
> > trusted without checking its revocation = status because
> compromise of
> > the key would be a widely known = problem.  I asked, via
> Jabber, how one
> > could confirm they had the correct TSA key = and was directed to the
> > mailing list.  While it may be true = that the compromise of the TSA
> > would be widely known, would the = revocation of a
> certificate issued in
> > error to the same name be as widely = known?  Recommending that
> > revocation status not be checked seems = like a bad idea.  We
> have means
> > for representing and processing revocation = information,
> including the
> > time of compromise, and should simply use = them.
> >
>

------_=_NextPart_001_01C76BC5.3FF4E4A8-- 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 l2LE93tE062033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 07:09:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LE93G0062032; Wed, 21 Mar 2007 07:09:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LE8geb062014 for ; Wed, 21 Mar 2007 07:09:02 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 879A64F4A5 for ; Wed, 21 Mar 2007 15:08:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 9F4C74413C for ; Wed, 21 Mar 2007 15:09:46 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19089-06 for ; Wed, 21 Mar 2007 15:09:33 +0100 (CET) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id C13B444103 for ; Wed, 21 Mar 2007 15:09:32 +0100 (CET) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 21 Mar 2007 15:08:26 +0100 From: "Julien Stern" Date: Wed, 21 Mar 2007 15:08:26 +0100 To: ietf-ltans@imc.org Subject: Re: TSA key and revocation checking Message-ID: <20070321140826.GI1235@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-ltans@imc.org References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote: > I agree with Carl. Not checking revocation status and relying on > non-automated, other means is a bad idea. I agree on the general principle. But in the specific LTANS settings, I think the TSA certificate will be in some sense more "trusted" than the CA that issued it. The specific setting I have in mind is the following: - say you are doing long term archiving (of signatures for instance) - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc) - Many years after, you want to check your archive If the TSA key is not trusted out-of-band, you need information to verify its revocation status, but this information cannot be included in the timestamped archive itself as that would cause a chicken and egg problem. Question: how do you obtain it ? I one can come up with a solution that solves this chicken and egg and allows for revocation checking, I'm all for it, but we have to keep this issue in mind. -- Julien > ________________________________ > > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace > Sent: Wednesday, March 21, 2007 6:46 AM > To: ietf-ltans@imc.org > Subject: TSA key and revocation checking > > > > During yesterday's meeting, Tobias mentioned that a TSA key could be > trusted without checking its revocation status because compromise of the > key would be a widely known problem. I asked, via Jabber, how one could > confirm they had the correct TSA key and was directed to the mailing > list. While it may be true that the compromise of the TSA would be > widely known, would the revocation of a certificate issued in error to > the same name be as widely known? Recommending that revocation status > not be checked seems like a bad idea. We have means for representing > and processing revocation information, including the time of compromise, > and should simply use them. > 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 l2LDgZVq060110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 06:42:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LDgZEG060109; Wed, 21 Mar 2007 06:42:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LDgEkQ060081 for ; Wed, 21 Mar 2007 06:42:34 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BBE.BD882CD3" Subject: RE: TSA key and revocation checking Date: Wed, 21 Mar 2007 06:41:52 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879071106A4@EXVS01.ex.dslextreme.net> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSA key and revocation checking thread-index: AcdrqLuks3OG6vm1RSuQeRvTdIFqLwAFeD8g References: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> From: "Santosh Chokhani" To: "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_01C76BBE.BD882CD3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Carl. Not checking revocation status and relying on non-automated, other means is a bad idea. =20 ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Wednesday, March 21, 2007 6:46 AM To: ietf-ltans@imc.org Subject: TSA key and revocation checking =20 During yesterday's meeting, Tobias mentioned that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem. I asked, via Jabber, how one could confirm they had the correct TSA key and was directed to the mailing list. While it may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as widely known? Recommending that revocation status not be checked seems like a bad idea. We have means for representing and processing revocation information, including the time of compromise, and should simply use them. ------_=_NextPart_001_01C76BBE.BD882CD3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TSA key and revocation checking

I agree with Carl.  Not = checking revocation status and relying on non-automated, other means is a bad = idea.

 

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Carl Wallace
Sent: Wednesday, March = 21, 2007 6:46 AM
To: ietf-ltans@imc.org
Subject: TSA key and = revocation checking

 

During yesterday's meeting, Tobias mentioned that a TSA key could be trusted = without checking its revocation status because compromise of the key would be a = widely known problem.  I asked, via Jabber, how one could confirm they had = the correct TSA key and was directed to the mailing list.  While it may = be true that the compromise of the TSA would be widely known, would the = revocation of a certificate issued in error to the same name be as widely = known?  Recommending that revocation status not be checked seems like a bad = idea.  We have means for representing and processing revocation information, = including the time of compromise, and should simply use = them.

------_=_NextPart_001_01C76BBE.BD882CD3-- 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 l2LAkC3U045421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 03:46:12 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LAkCRc045420; Wed, 21 Mar 2007 03:46: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2LAjp7q045391 for ; Wed, 21 Mar 2007 03:46:11 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 23131 invoked from network); 21 Mar 2007 10:45:49 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Mar 2007 10:45:49 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 Mar 2007 10:45:49 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Mar 2007 06:45:49 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1CD70B71@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: TSA key and revocation checking Date: Wed, 21 Mar 2007 06:45:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BA6.142921F4" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C76BA6.142921F4 Content-Type: text/plain During yesterday's meeting, Tobias mentioned that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem. I asked, via Jabber, how one could confirm they had the correct TSA key and was directed to the mailing list. While it may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as widely known? Recommending that revocation status not be checked seems like a bad idea. We have means for representing and processing revocation information, including the time of compromise, and should simply use them. ------_=_NextPart_001_01C76BA6.142921F4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable TSA key and revocation checking

During yesterday's meeting, Tobias mentioned that a = TSA key could be trusted without checking its revocation status because = compromise of the key would be a widely known problem.  I asked, = via Jabber, how one could confirm they had the correct TSA key and was = directed to the mailing list.  While it may be true that the = compromise of the TSA would be widely known, would the revocation of a = certificate issued in error to the same name be as widely known?  = Recommending that revocation status not be checked seems like a bad = idea.  We have means for representing and processing revocation = information, including the time of compromise, and should simply use = them.

------_=_NextPart_001_01C76BA6.142921F4-- 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 l2JGHBRj068501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 09:17: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 l2JGHBkY068500; Mon, 19 Mar 2007 09:17: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 mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JGGnFN068429 for ; Mon, 19 Mar 2007 09:17:10 -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 l2JGGl5q013908 for ; Mon, 19 Mar 2007 17:16:48 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A41.FE531238" Subject: LTANS WG meeting tomorrow Date: Mon, 19 Mar 2007 17:16:47 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868B6C544@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS WG meeting tomorrow Thread-Index: AcdqQf4zYYLDiH08TlWniXB1yU8ASw== 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_01C76A41.FE531238 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, the WG meeting tomorrow has an audio stream: = http://videolab.uoregon.edu/events/ietf/ietf687.m3u (find link also at: http://videolab.uoregon.edu/events/ietf/ - room = Karlin II ) And I hope I still find a volunteer for the jabber scribe: Room: ltans Server: jabber.ietf.org Agenda etc. can be found on the IETF meeting agenda - slides will be = uploaded tomorrow morning. 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_01C76A41.FE531238 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG meeting tomorrow

Hello,

the = WG meeting tomorrow has an = audio stream: http://videolab.uoregon.edu/events/ietf/ietf687.m3u=

(find link also at: http://videolab.uoregon.edu/events/ietf/=   - room Karlin = II )

And I = hope I still find a volunteer for the jabber scribe:

Room: = ltans

Server: jabber.ietf.org

Agenda etc. can be found on the IETF meeting = agenda – slides will be uploaded tomorrow = morning.

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_01C76A41.FE531238-- 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 l2CIarta095015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 11:36:53 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2CIaruc095014; Mon, 12 Mar 2007 11:36:53 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2CIapJT095006 for ; Mon, 12 Mar 2007 11:36:52 -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 l2CIanlk019919 for ; Mon, 12 Mar 2007 19:36:50 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C764D5.654B5EE3" Subject: agenda for upcoming WG meeting in Prague Date: Mon, 12 Mar 2007 19:36:48 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868B6BCA1@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: agenda for upcoming WG meeting in Prague Thread-Index: Acdk1WUQBy0MKNQ7QzqlGexIS3j6TQ== 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_01C764D5.654B5EE3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello dear WG members, this is the agenda for the upcoming WG meeting on Tuesday, March 20th in = Prague. (am still searching for a Jabber scribe, and I expect we will have an = audio broadcast from that room) http://www3.ietf.org/proceedings/07mar/agenda/ltans.txt=20 LTANS meeting Meeting : IETF 68, TUESDAY, March 20, 2007. Location: Hilton Prague, room Karlin II, 1850-1950. Chairs : Tobias Gondrom , Carl Wallace = Jabber : ltans@rooms.jabber.ietf.org URL : http://www.ietf.org/html.charters/ltans-charter.html Agenda : version 1.0 Meeting Agenda: A. MeetinG Administrativia - 5 minutes (chairs) B. Milestone Review - 5 minutes (Tobias) C. LTAP update - 10 minutes (Peter) - draft-ietf-ltans-ltap-04 D. Validation document updates - 5 minutes (Tobias) - draft-ietf-ltans-validate-01 E. XMLERS - status and presentation - 10 minutes (Aleksej&Svetlana) - draft-ietf-ltans-xmlers-00.txt=20 F. Implementation of ERS by Fraunhofer: Archisoft - 10 minutes (Michael = Herfert) G. Use of other timestamp formats with ERS - 5 minutes (Tobias) H. Future/Milestone recap/Wrap-up - 10 minutes (chairs) Drafts you should read to prepare for the meeting: LTAP, XMLERS, VALIDATE, (and optional: ARI, ERS/SCVP and ERS) See you next week,=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_01C764D5.654B5EE3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable agenda for upcoming WG meeting in Prague

Hello = dear WG members,

this is the = agenda for the upcoming WG meeting on Tuesday, = March = 20th in Prague.

(am = still searching for a Jabber scribe, and I expect we will have an audio broadcast = from that room)

http://www3.ietf.org/proceedings/07mar/agenda/ltans.txt

LTANS meeting

Meeting : IETF 68, TUESDAY, March 20, = 2007.

Location: Hilton Prague, room Karlin II, = 1850-1950.

Chairs  : Tobias Gondrom = <tgondrom@opentext.com>, Carl Wallace = <cwallace@orionsec.com>

Jabber  : = ltans@rooms.jabber.ietf.org

URL     : http://www.= ietf.org/html.charters/ltans-charter.html

Agenda  : version 1.0

Meeting Agenda:

A. = MeetinG Administrativia - 5 minutes (chairs)

B. = Milestone Review - 5 minutes (Tobias)

C. = LTAP update - 10 minutes (Peter)

- = draft-ietf-ltans-ltap-04

D. = Validation document updates - 5 minutes (Tobias)

- = draft-ietf-ltans-validate-01

E. = XMLERS - status and presentation - 10 minutes = (Aleksej&Svetlana)

- = draft-ietf-ltans-xmlers-00.txt

F. = Implementation of ERS by Fraunhofer: Archisoft - 10 minutes (Michael = Herfert)

G. = Use of other timestamp formats with ERS - 5 minutes = (Tobias)

H. = Future/Milestone recap/Wrap-up - 10 minutes (chairs)

Drafts you should read to prepare for the = meeting:

LTAP, = XMLERS, VALIDATE, (and optional: ARI, ERS/SCVP and = ERS)


See = you next week,

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_01C764D5.654B5EE3-- 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 l28MsWGD016817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2007 15:54: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 l28MsWbk016816; Thu, 8 Mar 2007 15:54: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 ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l28MsVmo016810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Mar 2007 15:54:31 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E1535175D0; Thu, 8 Mar 2007 22:54:30 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPRVG-0000rB-MB; Thu, 08 Mar 2007 17:54:30 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-ltans-ers (Evidence Record Syntax (ERS)) to Proposed Standard Reply-To: ietf@ietf.org Cc: Message-Id: Date: Thu, 08 Mar 2007 17:54:30 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the Long-Term Archive and Notary Services WG (ltans) to consider the following document: - 'Evidence Record Syntax (ERS) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11588&rfc_flag=0 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 l28Ko9k6010382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2007 13:50:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l28Ko9sC010381; Thu, 8 Mar 2007 13:50:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l28Ko8C6010375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Mar 2007 13:50:09 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 08706176CD; Thu, 8 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007HP-OK; Thu, 08 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-12.txt Message-Id: Date: Thu, 08 Mar 2007 15:50:03 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8122718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8122718.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25No4FR021932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2007 16:50:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l25No35J021931; Mon, 5 Mar 2007 16:50:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25No2CW021925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Mar 2007 16:50:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7DE0F3294A; Mon, 5 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOMwM-0000y6-Bc; Mon, 05 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ltap-04.txt Message-Id: Date: Mon, 05 Mar 2007 18:50:02 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-term Archive Protocol (LTAP) Author(s) : A. Jerman-Blazic, et al. Filename : draft-ietf-ltans-ltap-04.txt Pages : 50 Date : 2007-3-5 This document describes a service operated as a trusted third party to securely archive electronic document called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-04.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-ltap-04.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-ltap-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-5154241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ltap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ltap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5154241.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l24DWMAa083586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Mar 2007 06:32:22 -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 l24DWMLh083585; Sun, 4 Mar 2007 06:32:22 -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 l24DWLxZ083572 for ; Sun, 4 Mar 2007 06:32:22 -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 l24DW0520601 for ; Sun, 4 Mar 2007 14:32:09 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sun, 4 Mar 2007 14:32:09 +0100 (MET) Message-ID: <45EAC9D1.4020008@edelweb.fr> Date: Sun, 04 Mar 2007 14:29:53 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: asn.1 module identification Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203000905000301060200" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms010203000905000301060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hello, before the first technical spec get into stone, I'd suggest a convention for the ASN.1 module identifiers. it follows the logic that is used in X.500 etc (as far as I understand it). example: AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4} We have: - 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) - last, add a version. The X509 are at version 4, it is unlikely that we get many version but in case of, this is a very simply way to distinguish versions. The number has no identifier. in total this would give something like 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 Besides some renumbering this doesn't change anything in the current specs. If id-em should remain 2 then module88 could be 3. --------------ms010203000905000301060200 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMzA0MTMyOTUzWjAjBgkqhkiG9w0B CQQxFgQUivUsT5mnIK17zRN1+OcDs9P/Ts4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAoUxifyX3qDVrMZnY BmCcn1h5pOWwa3WnMUvbtjVM+X9v3JcZg9htR0seje6spgoGaAzLsrA52V2lQaj68YUqtQ6C 7xTIgiZU1YXj/U8tbs3sSc9YQamtHtge93a8fDozXaM+CWSe3S3udVP2ZVfpEX75pwmCFmSp JJmTjXYpayQAAAAAAAA= --------------ms010203000905000301060200-- 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 l21EKPXm035731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2007 07:20:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l21EKP03035730; Thu, 1 Mar 2007 07:20:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l21EKN29035714 for ; Thu, 1 Mar 2007 07:20:24 -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 l21EKLlk024142 for ; Thu, 1 Mar 2007 15:20:22 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75C0C.BEC4E729" Subject: LTANS meeting in Prague - agenda items? Date: Thu, 1 Mar 2007 15:20:22 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868B0033F@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS meeting in Prague - agenda items? Thread-Index: AcdcDL+SJxGHYL42TdiHMUHcHfhN2g== 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_01C75C0C.BEC4E729 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello dear working group, our meeting at the 68th IETF conference in Prague has been scheduled for = Tuesday, March 20, 2007, 18:50-19:50 local time (https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D= 68)=20 Please send your input for presentation topics and discussion slots to = me within the next few days (latest March-10). (presentation slides themselves can be submitted until one day before = the meeting - Monday, March 19, 2007) Some of my current ideas for discussion would be: - XMLERS (use of tags and attributes in XML version, - LTAP: stabilize version to prepare for WGLC - VALIDATE: need which further info? - ARI: shall ARI specify which requirements from REQS are solved in = which I-D - ERS-SCVP: status and stabilize - List of implementations/products of ERS - prepare coordination of = compatibility tests for after final release Who would like to give presentations to some of the above topics or = others? Please send proposals for the agenda and presentations via emails = directly to me. Thanks, Tobias Chair of LTANS Ps.: and some small good news: the REQS draft is now with the editor for = publishing as informational RFC and ERS has finally been submitted to = the IESG. __________________________________________ 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_01C75C0C.BEC4E729 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS meeting in Prague - agenda items?

Hello = dear working group,

our = meeting at the 68th IETF conference in Prague has been scheduled for Tuesday, = March 20, 2007, 18:50-19:50 local time

(https://datatracker.ietf.org/public/meeting_agenda_html.cg= i?meeting_num=3D68)

Please send = your input for presentation = topics = and discussion slots to me within the next few days (latest March-10).

(presentation slides themselves can be submitted until one day before the = meeting – = Monday, March 19, 2007)

Some = of my current ideas for discussion = would be:

-       XMLERS (use of tags and attributes in XML = version,
-       LTAP: stabilize version to prepare for WGLC
-       VALIDATE: need which further info?
-       ARI: = shall ARI specify which requirements from REQS are solved in which I-D
-       ERS-SCVP: status and stabilize
-       List of implementations/products of ERS – = prepare coordination of compatibility tests for after final release

Who = would like to give presentations to some of the above topics or others?

Please send proposals for the agenda and presentations via emails directly to me.

Thanks, Tobias

Chair = of LTANS


Ps.: = and some small good news: the REQS = draft is now with the editor for publishing as informational RFC and ERS has finally been submitted to the IESG.



__________________________________________
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_01C75C0C.BEC4E729--