From owner-ietf-pkix Tue Jan 1 16:18:21 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g020ILO23311 for ietf-pkix-bks; Tue, 1 Jan 2002 16:18:21 -0800 (PST) Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g020II323307 for ; Tue, 1 Jan 2002 16:18:19 -0800 (PST) Received: from hadrian.staff.apnic.net (hadrian.apnic.net [202.12.29.249]) by whois3.apnic.net (8.9.3/8.9.3) with ESMTP id KAA04073 for ; Wed, 2 Jan 2002 10:18:20 +1000 (EST) Received: from sanjaya (localhost [127.0.0.1]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id KAA04527 for ; Wed, 2 Jan 2002 10:17:52 +1000 (EST) Reply-To: From: "Sanjaya" To: Subject: RE: Attribute Certificate for IP address allocation object Date: Wed, 2 Jan 2002 10:18:48 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.0.1.4.2.20011231085957.02cecc68@exna07.securitydynamics.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Hi Russ, Thanks for the quick response! I have been studying the draft but don't have a clue where to put the IP block information. Should we just create a new attribute field in the AC? Cheers, Sanjaya > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Selasa, Januari 01, 2002 00:01 > To: Sanjaya > Cc: ietf-pkix@imc.org > Subject: Re: Attribute Certificate for IP address allocation object > > > Sanjaya: > > This seems like a straightforward application of > draft-ietf-pkix-ac509prof-09.txt. > > Russ > > > At 11:49 AM 12/31/2001 +1000, Sanjaya wrote: > > >Hi, > >We are investigating the use of Attribute Certificate for IP address > >allocation object. The idea is to bind the right to use certain IP blocks > >to the organization that receives the allocation from an IP registry > >(e.g APNIC/ARIN/RIPE). This certificate can be validated by > >the service provider before inserting the block into the routing table. > > > >Is this topic within the scope of PKIX working group? Appreciate > >any advise. Thanks! > > > >Happy New Year 2001! > >Sanjaya > >Senior Project Manager > >APNIC (http://www.apnic.net) > From owner-ietf-pkix Wed Jan 2 03:56:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02Buoa02936 for ietf-pkix-bks; Wed, 2 Jan 2002 03:56:50 -0800 (PST) Received: from odin2.bull.net ([192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02BuR302928 for ; Wed, 2 Jan 2002 03:56:28 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA10084; Wed, 2 Jan 2002 12:57:08 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16380; Wed, 2 Jan 2002 12:55:28 +0100 Message-ID: <3C32F55C.F5EF2C43@bull.net> Date: Wed, 02 Jan 2002 12:56:12 +0100 From: Denis Pinkas Organization: Integris. A Bull Company X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: stefan.kraxberger@iaik.at, a.caccia@innovery.net, Peter.Sylvester@edelweb.fr, cristian.marinescu@omicron.at, bianca.taglialagamba@sia.it, pgut001@cs.auckland.ac.nz, tho@andxor.com, tho@com-and.com CC: pkix Subject: Progression of RFC 3161 (TSP) to Draft Standard Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g02BuT302929 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: As advertised at the last IETF meeting in Salt Lake City, from information received on the mail list and directly, there exists at least seven experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP) available for individual testing: - four from Italy, - one from New-Zealand, - one from France, - one from Austria. The goal is to be able to perform interoperability testing among at least two of these implementations, so that we can report on these tests at the next IETF meeting in Minneapolis. This is a necessary step to be able to progress RFC 3161 from Proposed Standard to Draft Standard. [From section 6.2 of RFC 2026] A specification shall remain at the Proposed Standard level for at least six (6) months. [From section 4.1.2 of RFC 2026] A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used.(…). The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. Hereafter is information about the implementations I have been made aware of. If more exist, please let us know. ________________________ C&A experimental TSA service (http://www.com-and.com) Date: Fri, 24 Aug 2001 From: tho or If anyone would like another TSA to test here you can find ours: http://195.223.2.6:8080 It is a freebsd box with an apache module that acts as a front-end and translator to a socket based protocol backend. The backend is still directly reached at address 195.223.2.6 port 3318. Available interfaces are: http at url: http://195.223.2.6:8080/timestamp you have to POST a time stamp request wrapped into an application/timestamp-query MIME object. tcp at 195.223.2.6, port 3318 ________________________ Cryptographic Appliances (Peter Gutman) Date: Tue, 21 Aug 2001 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS 140-1 level 4 device (it's just a demo which runs single-threaded, so if you throw a huge number of concurrent requests at it you may get some refused connections, although I doubt it'll be a big issue for now). Date: Tue, 28 Aug 2001 I've now updated the TSA to conform to the latest draft (except for the TSA cert, because I'm using a shared generic cert which gets recycled for SSL, OCSP, CMP, and everything else). ________________________ SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A) Date: Thu, 8 Nov 2001 From: Taglialagamba Bianca We have developed a Time Stamping Authority according with the RFC 3161. If you would like to do some interoperability tests with it, the IP address is 193.203.230.166 and the port is 318 (using socket based protocol). The service can be available from 9.00 a.m. to 6.00 p.m. ________________________ Computer and Network Security Group (CNSG) from Politecnico di Torino Date: Mon, 03 Dec 2001 From: Cristian Marinescu Please take a look to http://security.polito.it/test/tsp/ Address: tsp.test.polito.it port:318. Pure TCP. Testing purposes only. Contact : tsp-dev@security.polito.it ________________________ EdelWeb Experimental Time Stamping Service Date: Mon, 03 Dec 2001 From: Peter Sylvester See the descriptions in: http://www.edelweb.fr/tsa.html This service uses a standard HTTP protocol to communicate. ________________________ Innovery True Time Date: Thu, 06 Dec 2001 From: Andrea Caccia on, 17 Dec 2001 23:36:18 +0100 Product name: Innovery True Time. Version: 1.1 Company name & address: Innovery srl Via Faravelli 8 20149 Milano - Italy Contact person: Andrea Caccia ________________________ Graz University of Technology (IAIK -Austria) Contact person: stefan.kraxberger@iaik.at ________________________ I encourage "contact persons" to contact themselves. :-) Denis. TSP lead editor. From owner-ietf-pkix Wed Jan 2 05:37:13 2002 Received: by above.proper.com (8.11.6/8.11.3) id g02DbDO09501 for ietf-pkix-bks; Wed, 2 Jan 2002 05:37:13 -0800 (PST) Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g02DbB309497 for ; Wed, 2 Jan 2002 05:37:11 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jan 2002 13:36:53 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA06123 for ; Wed, 2 Jan 2002 08:37:11 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g02DbAv28274 for ; Wed, 2 Jan 2002 08:37:10 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 08:37:09 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.90]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NCSSQ; Wed, 2 Jan 2002 08:37:03 -0500 Message-ID: <5.0.1.4.2.20020102082419.02ec2f70@exna07.securitydynamics.com> From: "Housley, Russ" To: sanjaya@apnic.net Cc: ietf-pkix@imc.org Subject: RE: Attribute Certificate for IP address allocation object Date: Wed, 2 Jan 2002 08:26:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Sanjaya: Yes. You will need to define a new attribute. You may want to define two attributes, one for IPv4 address blocks and another for IPv6 address blocks. I will be glad to review the syntax of your new attribute. Russ At 10:18 AM 1/2/2002 +1000, Sanjaya wrote: >Hi Russ, >Thanks for the quick response! I have been studying the >draft but don't have a clue where to put the IP block >information. Should we just create a new attribute field >in the AC? > >Cheers, >Sanjaya > > > -----Original Message----- > > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > > Sent: Selasa, Januari 01, 2002 00:01 > > To: Sanjaya > > Cc: ietf-pkix@imc.org > > Subject: Re: Attribute Certificate for IP address allocation object > > > > > > Sanjaya: > > > > This seems like a straightforward application of > > draft-ietf-pkix-ac509prof-09.txt. > > > > Russ > > > > > > At 11:49 AM 12/31/2001 +1000, Sanjaya wrote: > > > > >Hi, > > >We are investigating the use of Attribute Certificate for IP address > > >allocation object. The idea is to bind the right to use certain IP blocks > > >to the organization that receives the allocation from an IP registry > > >(e.g APNIC/ARIN/RIPE). This certificate can be validated by > > >the service provider before inserting the block into the routing table. > > > > > >Is this topic within the scope of PKIX working group? Appreciate > > >any advise. Thanks! > > > > > >Happy New Year 2001! > > >Sanjaya > > >Senior Project Manager > > >APNIC (http://www.apnic.net) > > ============================================================================ ================ This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. ============================================================================ ================ From owner-ietf-pkix Wed Jan 2 06:37:35 2002 Received: by above.proper.com (8.11.6/8.11.3) id g02EbZf11641 for ietf-pkix-bks; Wed, 2 Jan 2002 06:37:35 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02EbY311637 for ; Wed, 2 Jan 2002 06:37:34 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA02625; Wed, 2 Jan 2002 09:37:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5.0.1.4.2.20020102082419.02ec2f70@exna07.securitydynamics.com> References: <5.0.1.4.2.20020102082419.02ec2f70@exna07.securitydynamics.com> Date: Wed, 2 Jan 2002 09:35:31 -0500 To: sanjaya@apnic.net From: Stephen Kent Subject: RE: Attribute Certificate for IP address allocation object Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: At 8:26 AM -0500 1/2/02, Housley, Russ wrote: >Sanjaya: > >Yes. You will need to define a new attribute. You may want to define two >attributes, one for IPv4 address blocks and another for IPv6 address blocks. > >I will be glad to review the syntax of your new attribute. > >Russ > Sanjaya, My colleagues developed syntax for representing this info, for v4 and v6 addresses, and for AS numbers, as part of the Secure BGP work BBN has been doing under DARPA sponsorship. We defined these as private extensions for X.509 certs, vs. ACs., but the syntax should be applicable. I'll forward a copy of the proposed syntax. Steve From owner-ietf-pkix Wed Jan 2 08:04:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02G4ha14922 for ietf-pkix-bks; Wed, 2 Jan 2002 08:04:43 -0800 (PST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02G4e314916 for ; Wed, 2 Jan 2002 08:04:41 -0800 (PST) Received: from tsg1 ([12.81.64.195]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102160430.MCJB941.mtiwmhc22.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 16:04:30 +0000 Message-ID: <003801c193a7$189194a0$020aff0c@tsg1> From: "todd glassey" To: "Denis Pinkas" , , , , , , , , Cc: "pkix" References: <3C32F55C.F5EF2C43@bull.net> Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Date: Wed, 2 Jan 2002 08:03:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis - do you have any commercial users of the protocol or are the implementers Academic, and if they are academic what are they using the TSP for. Todd Glassey ----- Original Message ----- From: "Denis Pinkas" To: ; ; ; ; ; ; ; Cc: "pkix" Sent: Wednesday, January 02, 2002 3:56 AM Subject: Progression of RFC 3161 (TSP) to Draft Standard As advertised at the last IETF meeting in Salt Lake City, from information received on the mail list and directly, there exists at least seven experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP) available for individual testing: - four from Italy, - one from New-Zealand, - one from France, - one from Austria. The goal is to be able to perform interoperability testing among at least two of these implementations, so that we can report on these tests at the next IETF meeting in Minneapolis. This is a necessary step to be able to progress RFC 3161 from Proposed Standard to Draft Standard. [From section 6.2 of RFC 2026] A specification shall remain at the Proposed Standard level for at least six (6) months. [From section 4.1.2 of RFC 2026] A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used.(.). The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. Hereafter is information about the implementations I have been made aware of. If more exist, please let us know. ________________________ C&A experimental TSA service (http://www.com-and.com) Date: Fri, 24 Aug 2001 From: tho or If anyone would like another TSA to test here you can find ours: http://195.223.2.6:8080 It is a freebsd box with an apache module that acts as a front-end and translator to a socket based protocol backend. The backend is still directly reached at address 195.223.2.6 port 3318. Available interfaces are: http at url: http://195.223.2.6:8080/timestamp you have to POST a time stamp request wrapped into an application/timestamp-query MIME object. tcp at 195.223.2.6, port 3318 ________________________ Cryptographic Appliances (Peter Gutman) Date: Tue, 21 Aug 2001 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS 140-1 level 4 device (it's just a demo which runs single-threaded, so if you throw a huge number of concurrent requests at it you may get some refused connections, although I doubt it'll be a big issue for now). Date: Tue, 28 Aug 2001 I've now updated the TSA to conform to the latest draft (except for the TSA cert, because I'm using a shared generic cert which gets recycled for SSL, OCSP, CMP, and everything else). ________________________ SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A) Date: Thu, 8 Nov 2001 From: Taglialagamba Bianca We have developed a Time Stamping Authority according with the RFC 3161. If you would like to do some interoperability tests with it, the IP address is 193.203.230.166 and the port is 318 (using socket based protocol). The service can be available from 9.00 a.m. to 6.00 p.m. ________________________ Computer and Network Security Group (CNSG) from Politecnico di Torino Date: Mon, 03 Dec 2001 From: Cristian Marinescu Please take a look to http://security.polito.it/test/tsp/ Address: tsp.test.polito.it port:318. Pure TCP. Testing purposes only. Contact : tsp-dev@security.polito.it ________________________ EdelWeb Experimental Time Stamping Service Date: Mon, 03 Dec 2001 From: Peter Sylvester See the descriptions in: http://www.edelweb.fr/tsa.html This service uses a standard HTTP protocol to communicate. ________________________ Innovery True Time Date: Thu, 06 Dec 2001 From: Andrea Caccia on, 17 Dec 2001 23:36:18 +0100 Product name: Innovery True Time. Version: 1.1 Company name & address: Innovery srl Via Faravelli 8 20149 Milano - Italy Contact person: Andrea Caccia ________________________ Graz University of Technology (IAIK -Austria) Contact person: stefan.kraxberger@iaik.at ________________________ I encourage "contact persons" to contact themselves. :-) Denis. TSP lead editor. From owner-ietf-pkix Wed Jan 2 08:13:52 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02GDql15364 for ietf-pkix-bks; Wed, 2 Jan 2002 08:13:52 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02GDn315356 for ; Wed, 2 Jan 2002 08:13:50 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA12058; Wed, 2 Jan 2002 17:14:43 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA05818; Wed, 2 Jan 2002 17:13:16 +0100 Message-ID: <3C3331C0.B060FA97@bull.net> Date: Wed, 02 Jan 2002 17:13:52 +0100 From: Denis Pinkas Organization: Integris. A Bull Company X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: todd glassey CC: stefan.kraxberger@iaik.at, a.caccia@innovery.net, Peter.Sylvester@edelweb.fr, cristian.marinescu@omicron.at, bianca.taglialagamba@sia.it, pgut001@cs.auckland.ac.nz, tho@andxor.com, tho@com-and.com, pkix Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard References: <3C32F55C.F5EF2C43@bull.net> <003801c193a7$189194a0$020aff0c@tsg1> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g02GDp315360 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Todd, This is not a question to mee. So I let other people respond. Thank you for your interest in TSP. Regards, Denis > Denis - do you have any commercial users of the protocol or are the > implementers Academic, and if they are academic what are they using the TSP > for. > > Todd Glassey > > ----- Original Message ----- > From: "Denis Pinkas" > To: ; ; > ; ; > ; ; > ; > Cc: "pkix" > Sent: Wednesday, January 02, 2002 3:56 AM > Subject: Progression of RFC 3161 (TSP) to Draft Standard > > As advertised at the last IETF meeting in Salt Lake City, from information > received on the mail list and directly, there exists at least seven > experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP) > available for individual testing: > > - four from Italy, > - one from New-Zealand, > - one from France, > - one from Austria. > > The goal is to be able to perform interoperability testing among at least > two of these implementations, so that we can report on these tests at the > next IETF meeting in Minneapolis. This is a necessary step to be able to > progress RFC 3161 from Proposed Standard to Draft Standard. > > [From section 6.2 of RFC 2026] > > A specification shall remain at the Proposed Standard level for at > least six (6) months. > > [From section 4.1.2 of RFC 2026] > > A specification from which at least two independent and interoperable > implementations from different code bases have been developed, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. For the > purposes of this section, "interoperable" means to be functionally > equivalent or interchangeable components of the system or process in > which they are used.(.). > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. In cases in which one or more options or features > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft Standard > level only if those options or features are removed. > > Hereafter is information about the implementations I have been made > aware of. If more exist, please let us know. > > ________________________ > > C&A experimental TSA service (http://www.com-and.com) > Date: Fri, 24 Aug 2001 > From: tho or > > If anyone would like another TSA to test here you can find ours: > http://195.223.2.6:8080 > > It is a freebsd box with an apache module that acts as a front-end and > translator to a socket based protocol backend. The backend is still directly > reached at address 195.223.2.6 port 3318. > > Available interfaces are: > http at url: http://195.223.2.6:8080/timestamp > you have to POST a time stamp request wrapped into an > application/timestamp-query MIME object. > tcp at 195.223.2.6, port 3318 > > ________________________ > > Cryptographic Appliances (Peter Gutman) > Date: Tue, 21 Aug 2001 > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS > 140-1 level 4 device (it's just a demo which runs single-threaded, so if you > throw a huge number of concurrent requests at it you may get some refused > connections, although I doubt it'll be a big issue for now). > Date: Tue, 28 Aug 2001 > > I've now updated the TSA to conform to the latest draft (except for the TSA > cert, because I'm using a shared generic cert which gets recycled for SSL, > OCSP, CMP, and everything else). > > ________________________ > > SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A) > Date: Thu, 8 Nov 2001 > > From: Taglialagamba Bianca > > We have developed a Time Stamping Authority according with the RFC 3161. > If you would like to do some interoperability tests with it, the IP address > is 193.203.230.166 and the port is 318 (using socket based protocol). The > service can be available from 9.00 a.m. to 6.00 p.m. > > ________________________ > > Computer and Network Security Group (CNSG) > from Politecnico di Torino > Date: Mon, 03 Dec 2001 > > From: Cristian Marinescu > > Please take a look to http://security.polito.it/test/tsp/ > > Address: tsp.test.polito.it port:318. Pure TCP. > Testing purposes only. > > Contact : tsp-dev@security.polito.it > > ________________________ > > EdelWeb Experimental > Time Stamping Service > Date: Mon, 03 Dec 2001 > > From: Peter Sylvester > > See the descriptions in: http://www.edelweb.fr/tsa.html > > This service uses a standard HTTP protocol to communicate. > > ________________________ > > Innovery True Time > Date: Thu, 06 Dec 2001 > From: Andrea Caccia > on, 17 Dec 2001 23:36:18 +0100 > Product name: Innovery True Time. Version: 1.1 > > Company name & address: > Innovery srl > Via Faravelli 8 > 20149 Milano - Italy > > Contact person: Andrea Caccia > > ________________________ > > Graz University of Technology (IAIK -Austria) > Contact person: stefan.kraxberger@iaik.at > > ________________________ > > I encourage "contact persons" to contact themselves. :-) > > Denis. > TSP lead editor. From owner-ietf-pkix Wed Jan 2 08:43:37 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02Ghbj16440 for ietf-pkix-bks; Wed, 2 Jan 2002 08:43:37 -0800 (PST) Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02GhZ316434 for ; Wed, 2 Jan 2002 08:43:35 -0800 (PST) Received: from tsg1 ([12.81.64.195]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102164329.DVAT13117.mtiwmhc24.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 16:43:29 +0000 Message-ID: <002a01c193ac$8a3128a0$020aff0c@tsg1> From: "todd glassey" To: "Denis Pinkas" Cc: , , , , , , , , "pkix" References: <3C32F55C.F5EF2C43@bull.net> <003801c193a7$189194a0$020aff0c@tsg1> <3C3331C0.B060FA97@bull.net> Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Date: Wed, 2 Jan 2002 08:42:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis, I am sorry you are not tracking what the people who are implementing your protocol are doing with it. Personally if I were pushing my baby-protocol towards Standardization, I would know every use of it while its on its way to becoming a standard. I have no opposition to this protocol becoming a standard as long as it does not likewise rule out NTP's use as a time stamping protocol since NTP has had a standards number reserved for it from a time from before when the original TSP I-D was published, oh and NTP has at least twenty thousand commercial implementers. Also - I don't count Academic systems as commercially viable until they migrate their warez into the private sector as there is no real financial commitment to what a grad-student does by the university. This is an important key to realizing anything in the commercial world, especially in the defining of a security model in which there is a need for a TTP based TSP as an evidentiary model and getting it approved for roll out. This last thing is the real "ticker of value" for any core protocols that are to compete with ANXI X.9.ANSI efforts. Todd ----- Original Message ----- From: "Denis Pinkas" To: "todd glassey" Cc: ; ; ; ; ; ; ; ; "pkix" Sent: Wednesday, January 02, 2002 8:13 AM Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Todd, This is not a question to mee. So I let other people respond. Thank you for your interest in TSP. Regards, Denis > Denis - do you have any commercial users of the protocol or are the > implementers Academic, and if they are academic what are they using the TSP > for. > > Todd Glassey > > ----- Original Message ----- > From: "Denis Pinkas" > To: ; ; > ; ; > ; ; > ; > Cc: "pkix" > Sent: Wednesday, January 02, 2002 3:56 AM > Subject: Progression of RFC 3161 (TSP) to Draft Standard > > As advertised at the last IETF meeting in Salt Lake City, from information > received on the mail list and directly, there exists at least seven > experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP) > available for individual testing: > > - four from Italy, > - one from New-Zealand, > - one from France, > - one from Austria. > > The goal is to be able to perform interoperability testing among at least > two of these implementations, so that we can report on these tests at the > next IETF meeting in Minneapolis. This is a necessary step to be able to > progress RFC 3161 from Proposed Standard to Draft Standard. > > [From section 6.2 of RFC 2026] > > A specification shall remain at the Proposed Standard level for at > least six (6) months. > > [From section 4.1.2 of RFC 2026] > > A specification from which at least two independent and interoperable > implementations from different code bases have been developed, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. For the > purposes of this section, "interoperable" means to be functionally > equivalent or interchangeable components of the system or process in > which they are used.(.). > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. In cases in which one or more options or features > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft Standard > level only if those options or features are removed. > > Hereafter is information about the implementations I have been made > aware of. If more exist, please let us know. > > ________________________ > > C&A experimental TSA service (http://www.com-and.com) > Date: Fri, 24 Aug 2001 > From: tho or > > If anyone would like another TSA to test here you can find ours: > http://195.223.2.6:8080 > > It is a freebsd box with an apache module that acts as a front-end and > translator to a socket based protocol backend. The backend is still directly > reached at address 195.223.2.6 port 3318. > > Available interfaces are: > http at url: http://195.223.2.6:8080/timestamp > you have to POST a time stamp request wrapped into an > application/timestamp-query MIME object. > tcp at 195.223.2.6, port 3318 > > ________________________ > > Cryptographic Appliances (Peter Gutman) > Date: Tue, 21 Aug 2001 > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS > 140-1 level 4 device (it's just a demo which runs single-threaded, so if you > throw a huge number of concurrent requests at it you may get some refused > connections, although I doubt it'll be a big issue for now). > Date: Tue, 28 Aug 2001 > > I've now updated the TSA to conform to the latest draft (except for the TSA > cert, because I'm using a shared generic cert which gets recycled for SSL, > OCSP, CMP, and everything else). > > ________________________ > > SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A) > Date: Thu, 8 Nov 2001 > > From: Taglialagamba Bianca > > We have developed a Time Stamping Authority according with the RFC 3161. > If you would like to do some interoperability tests with it, the IP address > is 193.203.230.166 and the port is 318 (using socket based protocol). The > service can be available from 9.00 a.m. to 6.00 p.m. > > ________________________ > > Computer and Network Security Group (CNSG) > from Politecnico di Torino > Date: Mon, 03 Dec 2001 > > From: Cristian Marinescu > > Please take a look to http://security.polito.it/test/tsp/ > > Address: tsp.test.polito.it port:318. Pure TCP. > Testing purposes only. > > Contact : tsp-dev@security.polito.it > > ________________________ > > EdelWeb Experimental > Time Stamping Service > Date: Mon, 03 Dec 2001 > > From: Peter Sylvester > > See the descriptions in: http://www.edelweb.fr/tsa.html > > This service uses a standard HTTP protocol to communicate. > > ________________________ > > Innovery True Time > Date: Thu, 06 Dec 2001 > From: Andrea Caccia > on, 17 Dec 2001 23:36:18 +0100 > Product name: Innovery True Time. Version: 1.1 > > Company name & address: > Innovery srl > Via Faravelli 8 > 20149 Milano - Italy > > Contact person: Andrea Caccia > > ________________________ > > Graz University of Technology (IAIK -Austria) > Contact person: stefan.kraxberger@iaik.at > > ________________________ > > I encourage "contact persons" to contact themselves. :-) > > Denis. > TSP lead editor. From owner-ietf-pkix Wed Jan 2 09:49:40 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02HneE18388 for ietf-pkix-bks; Wed, 2 Jan 2002 09:49:40 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02Hnd318384 for ; Wed, 2 Jan 2002 09:49:39 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA04212; Wed, 2 Jan 2002 12:46:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <002a01c193ac$8a3128a0$020aff0c@tsg1> References: <3C32F55C.F5EF2C43@bull.net> <003801c193a7$189194a0$020aff0c@tsg1> <3C3331C0.B060FA97@bull.net> <002a01c193ac$8a3128a0$020aff0c@tsg1> Date: Wed, 2 Jan 2002 12:45:07 -0500 To: "todd glassey" From: Stephen Kent Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: "Denis Pinkas" , , , , , , , , , "pkix" , kent@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: At 8:42 AM -0800 1/2/02, todd glassey wrote: >Denis, I am sorry you are not tracking what the people who are implementing >your protocol are doing with it. Personally if I were pushing my >baby-protocol towards Standardization, I would know every use of it while >its on its way to becoming a standard. > >I have no opposition to this protocol becoming a standard as long as it does >not likewise rule out NTP's use as a time stamping protocol since NTP has >had a standards number reserved for it from a time from before when the >original TSP I-D was published, oh and NTP has at least twenty thousand >commercial implementers. > >Also - I don't count Academic systems as commercially viable until they >migrate their warez into the private sector as there is no real financial >commitment to what a grad-student does by the university. This is an >important key to realizing anything in the commercial world, especially in >the defining of a security model in which there is a need for a TTP based >TSP as an evidentiary model and getting it approved for roll out. This last >thing is the real "ticker of value" for any core protocols that are to >compete with ANXI X.9.ANSI efforts. Todd, The IETF requirement for multiple interoperable implementations of a protocol, as a prerequisite for progression, does not differentiate between product vs. academic implementations. NTP is an IETF standard for distribution of time information, but is not a time stamping protocol in the sense of TSP, so it is not a "competitor" for TSP. The value of the NTP protocol number is irrelevant to this discussion. Steve From owner-ietf-pkix Wed Jan 2 12:06:10 2002 Received: by above.proper.com (8.11.6/8.11.3) id g02K6AK21998 for ietf-pkix-bks; Wed, 2 Jan 2002 12:06:10 -0800 (PST) Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02K68321994 for ; Wed, 2 Jan 2002 12:06:08 -0800 (PST) Received: from foobar.andxor.it (foobar.andxor.it [195.223.2.236]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id VAA06533; Wed, 2 Jan 2002 21:06:08 +0100 (CET) (envelope-from adg@foobar.andxor.it) Received: by foobar.andxor.it (Postfix, from userid 1000) id 0C796F92A; Wed, 2 Jan 2002 23:05:00 +0100 (CET) Date: Wed, 2 Jan 2002 23:05:00 +0100 From: Alfonso De Gregorio To: todd glassey Cc: pkix Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Message-ID: <20020102230500.A3816@foobar.andxor.it> Reply-To: agregorio@acm.org References: <20020102204837.A22784@server.speedcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020102204837.A22784@server.speedcom.it>; from agregorio@acm.org on Wed, Jan 02, 2002 at 08:48:37PM +0100 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > I have no opposition to this protocol becoming a standard as long as it does > not likewise rule out NTP's use as a time stamping protocol since NTP has > had a standards number reserved for it from a time from before when the > original TSP I-D was published, oh and NTP has at least twenty thousand > commercial implementers. NTP is not a time stamping protocol in the sense of 3161. > Also - I don't count Academic systems as commercially viable until they > migrate their warez into the private sector as there is no real financial > commitment to what a grad-student does by the university. This is an > important key to realizing anything in the commercial world, especially in > the defining of a security model in which there is a need for a TTP based > TSP as an evidentiary model and getting it approved for roll out. This last AFAIK, there are 3161 commercial users, at least in Italy. Sincerely, alfonso From owner-ietf-pkix Wed Jan 2 14:08:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02M8Dv24729 for ietf-pkix-bks; Wed, 2 Jan 2002 14:08:13 -0800 (PST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02M8B324725 for ; Wed, 2 Jan 2002 14:08:11 -0800 (PST) Received: from tsg1 ([12.81.109.137]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102220807.LJKN15547.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 22:08:07 +0000 Message-ID: <001d01c193d9$e37b4ee0$020aff0c@tsg1> From: "todd glassey" To: Cc: "pkix" References: <20020102204837.A22784@server.speedcom.it> <20020102230500.A3816@foobar.andxor.it> Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Date: Wed, 2 Jan 2002 14:07:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Alfonso De Gregorio" To: "todd glassey" Cc: "pkix" Sent: Wednesday, January 02, 2002 2:05 PM Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard > > > I have no opposition to this protocol becoming a standard as long as it does > > not likewise rule out NTP's use as a time stamping protocol since NTP has > > had a standards number reserved for it from a time from before when the > > original TSP I-D was published, oh and NTP has at least twenty thousand > > commercial implementers. > > NTP is not a time stamping protocol in the sense of 3161. yes it is - it is exactly the same - The TST is easily encapsulated as an optional payload in the NTP service model. The NTP protocol is then exactly as capable of being used as a time stamp generator as the TSP. In fact the NTP Solution from a trst standpoint is orders of magnitude better than the PKIX effort which is totally arbitrary in its operations. There is no more commercial value in the PKIX TSP than looking at the micky mouse watch on your wrist and declaring this package to have arrived at some time point. The issue is that in a retrospective manner the only value the timestamp has is evidentiary in nature. Otherwise if the TS was just used to trigger some other digital event there would be no need to keep it. So no need for the token itself. That's the whole point - Time Stamping is supposed to be a method of enstantiating some more credibility than what was there from the testimony alone of the human representing the event. And it simply doesnt. > > > Also - I don't count Academic systems as commercially viable until they > > migrate their warez into the private sector as there is no real financial > > commitment to what a grad-student does by the university. This is an > > important key to realizing anything in the commercial world, especially in > > the defining of a security model in which there is a need for a TTP based > > TSP as an evidentiary model and getting it approved for roll out. This last > > AFAIK, there are 3161 commercial users, at least in Italy. Who are they and what is the operations model - what type of services are they using and providing and has an auditor ever looked at the system. > > Sincerely, > alfonso From owner-ietf-pkix Wed Jan 2 16:06:29 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0306T227319 for ietf-pkix-bks; Wed, 2 Jan 2002 16:06:29 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0306R327315 for ; Wed, 2 Jan 2002 16:06:27 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA26813; Wed, 2 Jan 2002 19:05:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <001d01c193d9$e37b4ee0$020aff0c@tsg1> References: <20020102204837.A22784@server.speedcom.it> <20020102230500.A3816@foobar.andxor.it> <001d01c193d9$e37b4ee0$020aff0c@tsg1> Date: Wed, 2 Jan 2002 18:58:36 -0500 To: From: Stephen Kent Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: "pkix" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Alfonso, >----- Original Message ----- >From: "Alfonso De Gregorio" >To: "todd glassey" >Cc: "pkix" >Sent: Wednesday, January 02, 2002 2:05 PM >Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard > > >> >> > I have no opposition to this protocol becoming a standard as long as it >does >> > not likewise rule out NTP's use as a time stamping protocol since NTP >has >> > had a standards number reserved for it from a time from before when the >> > original TSP I-D was published, oh and NTP has at least twenty thousand >> > commercial implementers. >> >> NTP is not a time stamping protocol in the sense of 3161. > >yes it is - it is exactly the same - The TST is easily encapsulated as an >optional payload in the NTP service model. The NTP protocol is then exactly >as capable of being used as a time stamp generator as the TSP. In fact the >NTP Solution from a trst standpoint is orders of magnitude better than the >PKIX effort which is totally arbitrary in its operations. There is no more >commercial value in the PKIX TSP than looking at the micky mouse watch on >your wrist and declaring this package to have arrived at some time point. >The issue is that in a retrospective manner the only value the timestamp has >is evidentiary in nature. Otherwise if the TS was just used to trigger some >other digital event there would be no need to keep it. So no need for the >token itself. You are right about the mismatch between the semantics for NTP vs. TSP; I noted the same thing a private exchange with Todd earlier today. TSP is a request/response protocol specifically designed to allow a client to request a time stamp for a hash value corresponding to some data of interest. NTP is a time distribution protocol that has security features designed to ensure authenticity and integrity for the time values it distributes, but it is not engineered to satisfy the sort of operation that TSP does. Todd has in mind a model for time stamping that has not been accepted by this WG, and which also is not consistent with the models employed by other protocol standards bodies (e.g., ETSI) working in the area. His comments have to be interpreted relative to that model. We have discussed this difference of opinion on this list many times in the past. See the archives to Todd's description of his model. Steve From owner-ietf-pkix Wed Jan 2 16:14:18 2002 Received: by above.proper.com (8.11.6/8.11.3) id g030EIa27575 for ietf-pkix-bks; Wed, 2 Jan 2002 16:14:18 -0800 (PST) Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g030EG327571 for ; Wed, 2 Jan 2002 16:14:16 -0800 (PST) Received: from SANJAYA (as-sanjaya.apnic.net [202.12.29.217]) by cumin.apnic.net (8.12.1/8.12.1) with SMTP id g030A6Tl012165 for ; Thu, 3 Jan 2002 10:10:06 +1000 Message-ID: <00ab01c193eb$981cdab0$d91d0cca@SANJAYA> From: "Sanjaya" To: References: <5.0.1.4.2.20020102082419.02ec2f70@exna07.securitydynamics.com> Subject: Re: Attribute Certificate for IP address allocation object Date: Thu, 3 Jan 2002 10:14:21 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Russ, Stephen, Thanks for the offer and pointers! I am aware of the draft by Clynn/BBN about PKC extension which have the same objective as what we have in mind. What is the current status of that draft? I'd be happy to discuss that draft further and combine our efforts. Also what would be the advantage/disadvantage of using X509 ID certs compared to using ACs? Cheers, Sanjaya ----- Original Message ----- From: "Stephen Kent" To: Cc: Sent: Thursday, January 03, 2002 12:35 AM Subject: RE: Attribute Certificate for IP address allocation object > At 8:26 AM -0500 1/2/02, Housley, Russ wrote: > >Sanjaya: > > > >Yes. You will need to define a new attribute. You may want to define two > >attributes, one for IPv4 address blocks and another for IPv6 address blocks. > > > >I will be glad to review the syntax of your new attribute. > > > >Russ > > > > Sanjaya, > > My colleagues developed syntax for representing this info, for v4 and > v6 addresses, and for AS numbers, as part of the Secure BGP work BBN > has been doing under DARPA sponsorship. We defined these as private > extensions for X.509 certs, vs. ACs., but the syntax should be > applicable. I'll forward a copy of the proposed syntax. > > Steve > From owner-ietf-pkix Wed Jan 2 16:59:27 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g030xRd28392 for ietf-pkix-bks; Wed, 2 Jan 2002 16:59:27 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g030xC328387 for ; Wed, 2 Jan 2002 16:59:12 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id NAA24594; Thu, 3 Jan 2002 13:58:02 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA501772; Thu, 3 Jan 2002 13:58:01 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Thu, 3 Jan 2002 13:58:01 +1300 (NZDT) Message-ID: <200201030058.NAA501772@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, Peter.Sylvester@edelweb.fr, a.caccia@innovery.net, bianca.taglialagamba@sia.it, cristian.marinescu@omicron.at, pgut001@cs.auckland.ac.nz, stefan.kraxberger@iaik.at, tho@andxor.com, tho@com-and.com Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis Pinkas writes: >The goal is to be able to perform interoperability testing among at least two >of these implementations, so that we can report on these tests at the next >IETF meeting in Minneapolis. This is a necessary step to be able to progress >RFC 3161 from Proposed Standard to Draft Standard. I've interoperated with Peter Sylvester's TSA and the timeproof.de one. I've never seen the IAIK one running, and there was one at 203.238.37.132:3318 which I've got question marks next to so I assume that one was never active either. Peter. From owner-ietf-pkix Wed Jan 2 18:15:57 2002 Received: by above.proper.com (8.11.6/8.11.3) id g032Fv429773 for ietf-pkix-bks; Wed, 2 Jan 2002 18:15:57 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g032Fs329769 for ; Wed, 2 Jan 2002 18:15:55 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA24371; Thu, 3 Jan 2002 15:14:53 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA502886; Thu, 3 Jan 2002 15:14:53 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Thu, 3 Jan 2002 15:14:53 +1300 (NZDT) Message-ID: <200201030214.PAA502886@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, Peter.Sylvester@edelweb.fr, a.caccia@innovery.net, bianca.taglialagamba@sia.it, cristian.marinescu@omicron.at, pgut001@cs.auckland.ac.nz, stefan.kraxberger@iaik.at, tho@andxor.com, tho@com-and.com, todd.glassey@worldnet.att.net Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: "todd glassey" writes: >Denis - do you have any commercial users of the protocol or are the >implementers Academic, and if they are academic what are they using the TSP >for. Does it matter? The requirement is for two interoperable implementations, which we certainly have. (Just out of interest, it'd be interesting to see who *is* using TSP commercially. From the list which Denis posted, I'd guess this is only happening in Italy, which has laws requiring it. The other three are academic/experimental. My code is available under the Sleepycat license (dual-license, GPL-style or commercial) and I'm not aware of any commercial users of TSP... actually I'm not aware of any open-source users either, but since anyone can grab it I can't really tell who's doing what with it, there may be hordes of people secretly running TSAs in their basements). Peter. From owner-ietf-pkix Wed Jan 2 18:59:38 2002 Received: by above.proper.com (8.11.6/8.11.3) id g032xcV00503 for ietf-pkix-bks; Wed, 2 Jan 2002 18:59:38 -0800 (PST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g032xa300498 for ; Wed, 2 Jan 2002 18:59:36 -0800 (PST) Received: from tsg1 ([12.81.109.137]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020103025934.QLLL15547.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 3 Jan 2002 02:59:34 +0000 Message-ID: <004b01c19402$991db170$020aff0c@tsg1> From: "todd glassey" To: "Peter Gutmann" , , , , , , , , Cc: References: <200201030214.PAA502886@ruru.cs.auckland.ac.nz> Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Date: Wed, 2 Jan 2002 18:58:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: yes it does, and for what should be obvious reasons Todd ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; ; ; ; ; ; ; Cc: Sent: Wednesday, January 02, 2002 6:14 PM Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard > "todd glassey" writes: > > >Denis - do you have any commercial users of the protocol or are the > >implementers Academic, and if they are academic what are they using the TSP > >for. > > Does it matter? The requirement is for two interoperable implementations, > which we certainly have. > > (Just out of interest, it'd be interesting to see who *is* using TSP > commercially. From the list which Denis posted, I'd guess this is only > happening in Italy, which has laws requiring it. The other three are > academic/experimental. My code is available under the Sleepycat license > (dual-license, GPL-style or commercial) and I'm not aware of any commercial > users of TSP... actually I'm not aware of any open-source users either, but > since anyone can grab it I can't really tell who's doing what with it, there > may be hordes of people secretly running TSAs in their basements). > > Peter. From owner-ietf-pkix Thu Jan 3 14:05:03 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g03M53m23638 for ietf-pkix-bks; Thu, 3 Jan 2002 14:05:03 -0800 (PST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03M51323634; Thu, 3 Jan 2002 14:05:02 -0800 (PST) Received: from cspa06.nist.gov (cspa06.ncsl.nist.gov [129.6.54.23]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA10325; Thu, 3 Jan 2002 17:05:02 -0500 (EST) Message-Id: <5.0.0.25.2.20020103155424.01ddbd10@email.nist.gov> X-Sender: chernick@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 03 Jan 2002 17:06:30 -0500 To: ietf-smime@imc.org, ietf-pkix@imc.org From: Michael Chernick Subject: Updated Draft of NIST S/MIME V3 Client Profile Now Available Cc: Michael Chernick , Tim Polk Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17140984==_.ALT" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: --=====================_17140984==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed FYI, I have posted a new version of the draft S/MIME V3 Client Profile on the web. You can find it at: http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf (See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for previous message with background on the NIST S/MIME V3 Client profile.) There is also a description of our work at: http://csrc.nist.gov/pki/smime/welcome.htm NIST has solicited comments from you and we have incorporated almost all changes requested into the new document. Most comments received were editorial in nature, or asked for clarification. The new draft has these major changes from the previous (May, 2001) draft: An Executive Summary for Procurement Officials, Implementers, Vendors, and Others interested in S/MIME Technology from a less technical perspective; A clarification (in Clause 2.4.4) that the path building requirements are intended to require that all S/MIME clients be able to transverse non-hierarchical (e.g., bridge PKIs) as well as hierarchical PKIs; Relaxation of the requirement (in Clause 2.3.2) to always require user notification when an incoming S/MIME message is signed by a certificate that contains an email address that does not match the email address used as "From" address. (This change was prompted by NIST's observation that many new certificates will not contain email addresses.) The major unresolved comment on the May draft is the issue of mandating signed receipt processing support. (See Clauses 2.2., 2.3, and 3.1.) NIST received a comment requesting that this mandate be dropped. The comment argued that including a requirement for signed receipt support would add cost and complexity to S/MIME products, and that the cost of this additional functionality should be bourne by the agencies that require this service, enabling other agencies that do not require the service to obtain less complex and less costly S/MIME v3 client systems. Agencies that do not want/need signed receipts should not be required to request it in their purchases of messaging systems. NIST has felt that the additional cost and complexity were justified by ubiquity of signed receipt support among U.S. Federal Agencies. We intend to resolve this issue very soon and then publish the S/MIME V3 Client Profile. We have almost completed the process of soliciting U.S. Federal Agencies on this issue. I will be pleased to receive any further comments on the new draft until the end of January 2002. (Note: The old draft and updated information on the NIST S/MIME program are available at: http://csrc.nist.gov/pki/smime/welcome.htm). The NIST S/MIME V3 Test Facility (see http://csrc.nist.gov/pki/smime/smtest.htm) is not yet operational, but it is expected to become operational (with limited test cases at first) during the first quarter of 2002. Thanks, Mike Chernick ---------------------------------------------------------------------------------- C. Michael Chernick +1-301-975-3610 chernick@nist.gov Computer Security Division National Institute of Standards and Technology (NIST) ---------------------------------------------------------------------------------- --=====================_17140984==_.ALT Content-Type: text/html; charset="us-ascii" FYI,

I have posted a new version of the draft S/MIME V3 Client Profile on the web.
You can find it at: http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf

(See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for previous
message with background on the NIST S/MIME V3 Client profile.)

There is also a description of our work at: http://csrc.nist.gov/pki/smime/welcome.htm

NIST has solicited comments from you and we have incorporated almost
all changes requested into the new document.  Most comments received were
editorial in nature, or asked for clarification.

The new draft has these major changes from the previous (May, 2001) draft:

     An Executive Summary for Procurement Officials, Implementers, Vendors, and
     Others interested in S/MIME Technology from a less technical perspective;

     A clarification (in Clause 2.4.4) that the path building requirements are intended to
     require that all S/MIME clients be able to transverse non-hierarchical (e.g., bridge
     PKIs) as well as hierarchical PKIs;

     Relaxation of the requirement (in Clause 2.3.2) to always require user notification
     when an incoming S/MIME message is signed by a certificate that contains an email
     address that does not match the email address used as "From" address. (This
     change was prompted by NIST's observation that many new certificates will not
     contain email addresses.)

The major unresolved comment on the May draft is the issue of mandating
signed receipt processing support.  (See Clauses 2.2., 2.3, and 3.1.)  NIST received
a comment requesting that this mandate be dropped.

The comment argued that including a requirement for signed receipt support would add
cost and complexity to S/MIME products, and that the cost of this additional functionality
should be bourne by the agencies that require this service, enabling other agencies that do
not require the service to obtain less complex and less costly S/MIME v3 client systems.
Agencies that do not want/need signed receipts should not be required to request it in their
purchases of messaging systems.

NIST has felt that the additional cost and complexity were justified by ubiquity of signed
receipt support among U.S. Federal Agencies.  We intend to resolve this issue very soon
and then publish the S/MIME V3 Client Profile. We have almost completed the process
of soliciting U.S. Federal Agencies on this issue.

I will be pleased to receive any further comments on the new draft until the
end of January 2002.

(Note:  The old draft and updated information on the NIST S/MIME program are
available at: http://csrc.nist.gov/pki/smime/welcome.htm).

The NIST S/MIME V3 Test Facility (see http://csrc.nist.gov/pki/smime/smtest.htm) is
not yet operational, but it is expected to become operational (with limited test
cases at first) during the first quarter of 2002.


Thanks,
   Mike Chernick

----------------------------------------------------------------------------------
C. Michael Chernick
+1-301-975-3610   chernick@nist.gov
Computer Security Division
National Institute of Standards and Technology (NIST)
----------------------------------------------------------------------------------

--=====================_17140984==_.ALT-- From owner-ietf-pkix Fri Jan 4 06:55:48 2002 Received: by above.proper.com (8.11.6/8.11.3) id g04Etm510651 for ietf-pkix-bks; Fri, 4 Jan 2002 06:55:48 -0800 (PST) Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04Etf310643 for ; Fri, 4 Jan 2002 06:55:41 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA24145; Fri, 4 Jan 2002 15:51:24 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 4 Jan 2002 15:51:24 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA12146; Fri, 4 Jan 2002 15:51:24 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA29651; Fri, 4 Jan 2002 15:51:34 +0100 (MET) Date: Fri, 4 Jan 2002 15:51:34 +0100 (MET) Message-Id: <200201041451.PAA29651@emeriau.edelweb.fr> To: Denis.Pinkas@bull.net, Peter.Sylvester@edelweb.fr, a.caccia@innovery.net, bianca.taglialagamba@sia.it, cristian.marinescu@omicron.at, pgut001@cs.auckland.ac.nz, stefan.kraxberger@iaik.at, tho@andxor.com, tho@com-and.com Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > >The goal is to be able to perform interoperability testing among at least two > >of these implementations, so that we can report on these tests at the next > >IETF meeting in Minneapolis. This is a necessary step to be able to progress > >RFC 3161 from Proposed Standard to Draft Standard. > > I've interoperated with Peter Sylvester's TSA and the timeproof.de one. I've > never seen the IAIK one running, and there was one at 203.238.37.132:3318 which > I've got question marks next to so I assume that one was never active either. The IAIK TSA was riunning from time to time, I have made a few tests with them. Anyway: I am not sure whether it is sufficient to just test sending 'correct' data. I have spend some time sending almost arbitrary data as requests, both on the TCP socket layer level and as request PDUs *IN A CLIENT*. I am not sure whether there are client or server implementations that voluntarily send back *wrong* data in order to validate whether the different MUSTs in the text are respected. I would like to invite the editor of the text to review the archive to see whether comments for changes or enhancements had been rejected with a reason like 'not now, we can do this in the next round,', 'we can do this later, we need a stable text now'. I think there are quite a few of them. Some questions that come out of my limited memory: - alignment of the socket based protocol with the CMP socket transport? - How can one indicate a scket protocol transport with a non default port in a certificate. - How can one correctly create a TSA certificate respecting the rules set in TSP. How to do POP of the key. - Can two time stamps be compared? From owner-ietf-pkix Fri Jan 4 08:07:26 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04G7QD12238 for ietf-pkix-bks; Fri, 4 Jan 2002 08:07:26 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04G7K312231 for ; Fri, 4 Jan 2002 08:07:21 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA27119; Sat, 5 Jan 2002 05:06:17 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA22477; Sat, 5 Jan 2002 05:06:10 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Sat, 5 Jan 2002 05:06:10 +1300 (NZDT) Message-ID: <200201041606.FAA22477@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, Peter.Sylvester@edelweb.fr, a.caccia@innovery.net, bianca.taglialagamba@sia.it, cristian.marinescu@omicron.at, pgut001@cs.auckland.ac.nz, stefan.kraxberger@iaik.at, tho@andxor.com, tho@com-and.com Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Peter Sylvester writes: >Anyway: I am not sure whether it is sufficient to just test sending 'correct' >data. I have spend some time sending almost arbitrary data as requests, both >on the TCP socket layer level and as request PDUs *IN A CLIENT*. Oh, so you were the one causing all the "Bad data format" entries in the error log :-). >I am not sure whether there are client or server implementations that >voluntarily send back *wrong* data in order to validate whether the different >MUSTs in the text are respected. My TSA did that once. Definitely a deliberate error to test clients, and not me mis-reading the spec :-). >- How can one indicate a scket protocol transport with a non default port in a > certificate. I've been using cmp://fqdn:port. Peter. From owner-ietf-pkix Fri Jan 4 08:25:57 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04GPvI12814 for ietf-pkix-bks; Fri, 4 Jan 2002 08:25:57 -0800 (PST) Received: from smtp3.access.net.id ([202.180.4.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04GPp312808 for ; Fri, 4 Jan 2002 08:25:51 -0800 (PST) Received: from MAHATEL.mii.or.id (pteredon99.access.net.id [202.180.2.99]) by smtp3.access.net.id (8.9.3+Sun/8.9.3) with ESMTP id XAA12597; Fri, 4 Jan 2002 23:25:26 -0700 (GMT) Message-Id: <5.1.0.14.0.20020105111559.05150400@pop3.access.net.id> X-Sender: teddyap@pop3.access.net.id X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Jan 2002 11:19:43 +0700 To: "Sanjaya" From: Teddy A Purwadi Subject: Re: Attribute Certificate for IP address allocation object Cc: In-Reply-To: <00ab01c193eb$981cdab0$d91d0cca@SANJAYA> References: <5.0.1.4.2.20020102082419.02ec2f70@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Sanjaya: How long will you go with the draft related to the object to IP indexes? Or no correlations?. -teddy At 10:14 AM 1/3/02 +1000, Sanjaya wrote: >Russ, Stephen, >Thanks for the offer and pointers! >I am aware of the draft by Clynn/BBN about PKC extension >which have the same objective as what we have in mind. >What is the current status of that draft? I'd be happy to >discuss that draft further and combine our efforts. >Also what would be the advantage/disadvantage of using >X509 ID certs compared to using ACs? > >Cheers, >Sanjaya > >----- Original Message ----- >From: "Stephen Kent" >To: >Cc: >Sent: Thursday, January 03, 2002 12:35 AM >Subject: RE: Attribute Certificate for IP address allocation object > > > > At 8:26 AM -0500 1/2/02, Housley, Russ wrote: > > >Sanjaya: > > > > > >Yes. You will need to define a new attribute. You may want to define >two > > >attributes, one for IPv4 address blocks and another for IPv6 address >blocks. > > > > > >I will be glad to review the syntax of your new attribute. > > > > > >Russ > > > > > > > Sanjaya, > > > > My colleagues developed syntax for representing this info, for v4 and > > v6 addresses, and for AS numbers, as part of the Secure BGP work BBN > > has been doing under DARPA sponsorship. We defined these as private > > extensions for X.509 certs, vs. ACs., but the syntax should be > > applicable. I'll forward a copy of the proposed syntax. > > > > Steve > > From owner-ietf-pkix Fri Jan 4 12:46:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04KkoU21572 for ietf-pkix-bks; Fri, 4 Jan 2002 12:46:50 -0800 (PST) Received: from mail.tiscalinet.it (mail-7.tiscalinet.it [195.130.225.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04Kkm321567 for ; Fri, 4 Jan 2002 12:46:48 -0800 (PST) Received: from polito.it (62.10.37.164) by mail.tiscalinet.it (5.5.053) id 3C0343CC00F4F2EC; Fri, 4 Jan 2002 21:45:58 +0100 Message-ID: <3C361481.1F64836F@polito.it> Date: Fri, 04 Jan 2002 21:45:53 +0100 From: Antonio Lioy Organization: Politecnico di Torino X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: pkix Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard References: <3C32F55C.F5EF2C43@bull.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8C35EFC32CA2BD6B2CAAC7AD" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms8C35EFC32CA2BD6B2CAAC7AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > > As advertised at the last IETF meeting in Salt Lake City, from information > received on the mail list and directly, there exists at least seven > experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP) > available for individual testing: > > - four from Italy, > - one from New-Zealand, > - one from France, > - one from Austria. > > The goal is to be able to perform interoperability testing among at least > two of these implementations, so that we can report on these tests at the > next IETF meeting in Minneapolis. This is a necessary step to be able to > progress RFC 3161 from Proposed Standard to Draft Standard. Here at the Politecnico di Torino we have been testing our implementation against the following ones: - SIA - C&A - IAIK - Peter Guttman We have not been able to test against the Edelweb TSA as it is HTTP based and not socket based. We are in the process of writing a report about these tests. Is there any standard IETF format to officially report these results to progress an RFC to Draft Standard? > Computer and Network Security Group (CNSG) > from Politecnico di Torino > Date: Mon, 03 Dec 2001 > > From: Cristian Marinescu > > Please take a look to http://security.polito.it/test/tsp/ > > Address: tsp.test.polito.it port:318. Pure TCP. > Testing purposes only. > > Contact : tsp-dev@security.polito.it Some more information about this implementation: - it consists of a server, a client and a library that implements a TS API - everything is available for Win32 and Unix (tried under Solaris and Linux) - current version is pure socket based - HTTP and SMTP versions are in progress - the code is based on the cryptographic part of OpenSSL, with some modifications - the contact address tsp-dev@security.polito.it is not yet active (it will be in a week or so); for the moment, please address everything related to our TSA to {lioy,ramunno}@polito.it In reply to Todd Glassey's request for info about application field: our TSA code is being tested for application in e-government environments (by some Italian municipalities as well as by partners of the EuroPKI and NASTEC projects), although other applications are surely possible. Cheers, Antonio Lioy Gianluca Ramunno Cristian Marinescu --------------ms8C35EFC32CA2BD6B2CAAC7AD 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 MIIRRwYJKoZIhvcNAQcCoIIRODCCETQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D0owggV9MIIEZaADAgECAgIA0DANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJJVDEeMBwG A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDExMjIxMTUwMDAwWhcNMDMxMjMx MDkwMDAwWjB4MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5v MTEwLwYDVQQLEyhEaXBhcnRpbWVudG8gZGkgQXV0b21hdGljYSBlIEluZm9ybWF0aWNhMRYw FAYDVQQDEw1BbnRvbmlvICBMaW95MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkq3Ub EN2iW/2K3GUpgnSEg61e+aVAWWg+62zyROqLFpTglPUxw7JakWgzjuwpwPl9gPZSlMqsV8dP g6Do0/zs3zAPKpZ8m8mxxY5apkBj0genz+ufqBWYBsfTqKmNATmWKQmGF1bxdHSOB1RcDArF byJdX3A9+IyIw2BuI9BaswIDAQABo4ICpjCCAqIwgZUGCWCGSAGG+EIBDQSBhxaBhElzc3Vl ZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMv MS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2Nh LnBvbGl0by5pdC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBV MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAC hh1odHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vY2EucG9saXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADAxBgNVHREEKjAo gQ5saW95QHBvbGl0by5pdKAWBgorBgEEAZViAgEBoAgWBjAwMTg0NzCBzQYDVR0gBIHFMIHC MEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9j YS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL3d3 dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzA4BgorBgEEAZViAQIBMCowKAYIKwYBBQUH AgEWHGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wCwYDVR0PBAQDAgTwMB0GA1UdDgQW BBSQXcYutVN1s83taHXQY4e0ltUt3DAfBgNVHSMEGDAWgBT0DG1tnl9MYlY5geDe+Y8vN6CE xTANBgkqhkiG9w0BAQUFAAOCAQEAfJmaMcqwiOSzRcDx6Yby30oHm32+qn6idN6fTpzrKMDP 8fgjD+LQSxxPQzUheVTK2qpOPT4SHfNMZ2iZeplKegDdJc/nrPNfUYdvQHwiEhKhWHvAfsfN SBtpGeSEr8cBWeD/gjmAylGY2h17WHg/TNd0w3qfUZmfFGvBHVAbxC/Ar2zfvTX+8spF2vNR CBPmE0o8O2ZQrenZXqeeFPWkqwf94MJ4f3SnKL+TyI6lXCIUwPGmLqC1NHGl4TpXd2xKChra uR+NTwz6oJBYv0H0UhZdqc7S/JwRetFbO7+eAEx+OGgyBeeNTgddT2ZL4zIBQQSCvQBx9asn H6Tb7WbRvTCCBT4wggQmoAMCAQICAgFoMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNVBAYTAklU MRAwDgYDVQQKEwdFdXJvUEtJMTAwLgYDVQQDEydFdXJvUEtJIEl0YWxpYW4gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDExMjE0MTAwMDAwWhcNMDYxMjMxMDkwMDAwWjBlMQswCQYD VQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xp dGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQD2x9x9Ywb+ZLw7r1ps9+dRZyLpN9SdxKV+zxLOnACyhbX8 4mkZW3GrXIpCs/xaqKLERxlZK+eU5zJGP8LS3PcktApIDKscoZIOSfkx3gcK574vUkdDcFrX h5A6PusC6AWAT7ot6dMC+C45CXvj+30L3ct2bU1j63UWzfqg+E8lDmKetnoPw/2iXiz95zI+ GFBpTW2KipDLV3TWBdOuYjZ4fpSLQCTJ7FVzEWldHuqe89XuG4T5lMNTvu32PHbiyaYm5LGU DwdBLwj6oLK0OE5iwqbrvqfVrjCkT1W6ehUCb/7u1qObfVlhrFOeNfz3WR8UagWL8ne0hFzr u+HwmjL7AgMBAAGjggIKMIICBjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVuZGVyIHBvbGlj aWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvCiBodHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMFwGCCsGAQUFBwEBBFAwTjAoBggrBgEF BQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAyNjAiBggrBgEFBQcwAoYWaHR0cDov L3d3dy5ldXJvcGtpLm9yZzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2ku b3JnL2NhL2l0L2NybDAyL2NybC5kZXIwgZMGA1UdIASBizCBiDBDBgorBgEEAakHAQEBMDUw MwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBB BgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev aXQvY3BzLzEuMS8wHwYDVR0jBBgwFoAUqjwTyUkLXM240yDgxZWXMzNdJBMwDwYDVR0TAQH/ BAUwAwEB/zALBgNVHQ8EBAMCAfYwHQYDVR0OBBYEFPQMbW2eX0xiVjmB4N75jy83oITFMA0G CSqGSIb3DQEBBQUAA4IBAQBfHbqCmb+iIbu2Lb57UvCaeqfqOTSKHEjFxxrOhMCNbOrrTH4y EgmwiBF8a2/lTZfMRZzXlRmu7qyuTxOpy1PoRupExMK3HqbE93pGkqneN6mKAY6TCcmyeONQ 8L+0eZ8kc1yWXdGTprg4i9rOXA6gK5DwPQ32wAa3Hfn5P60DKmE1T3Ie0Ld2m9Ci0uYkWjY+ vqxPLaKMKpCcfEnaxlQQCU0S6coU/zLe49/C8TQUQLuU42RTH5Tv3ICXA+8G8BJSikhA/LsF D0gy6mSP/UOZS+aX/Tl/4Ni/bHtRuJSWnWSxBfOz5YvEHY0AN+cJo82+qmFHPkqEkY5Mmlzw Jn5QMIIEgzCCA2ugAwIBAgIBCzANBgkqhkiG9w0BAQUFADBBMRAwDgYDVQQKEwdFdXJvUEtJ MS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDEx MjEyMTAwMDAwWhcNMDYxMjMxMTAwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVy b1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/trLUTLGC/t9bWWmRFPhuWNLcJ/t nmb8ppelASwxB+KEFe+hxUZWpgJNteXW772tvJVXwy2hpkUTYRv7y0pMDoPZQmlWWfYaKceL UKz7AhXpLPnnApo3e0rMYzDcv8fcAM2Jii20//+B7dLU/qPRtwaFD+n/E4bOYAu3wIHsoK2f 35UdXwO9yY6qaZBVzKZTP0wI3rxnN8u958CdTNagg3vZ/EkNEbyzMuPUhjEc4+ygtUgPbTIY N3Kmke1WvXFRjisajmM8K4jv39DE2FB4PJZCjbHaOozedWZVcMVEkiazWPsFam6ISGzRklaR pBd3b2CYF5mim8wrIBc7dcMO/wIDAQABo4IBdDCCAXAwTAYJYIZIAYb4QgENBD8WPUlzc3Vl ZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEu MS8wOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9y Zzo4MDI2MDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9v dC9jcmwvY3JsLmRlcjBOBgNVHSAERzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYn aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFIzc i7GlSpDnTohzGDyd1V5+5LLNMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQW BBSqPBPJSQtczbjTIODFlZczM10kEzANBgkqhkiG9w0BAQUFAAOCAQEAa6mGMlATRFDbx64p I5ntDhu8aA947xaAaJQeulnq8jb7+SdKqorQBDuPn7i+IYwmCbbHwmdir1ljLWLTAWtgjET8 bZ/DxxbU//ywI3OpOP5I7T/YqknQGS+5NIbavU1N6DprmvrVriNSqni6krG7OC7q6ezD/5GR TYrOU2bTnck5ywzzZ0g3c0Gv6Fmz/QgWIxbUYkHY/vbblZYMXTU61ByYtiymiJ99Q/LaD6Dg UPkjEcUcq8IbVv3MeZ8mhoOfnL6RBCkez9khl5TI171QuJ+7caAZAqn2yPpulsZ+NbcsCGEb ot2F/z4DOLq82bNDAJt6BTbo0VrMSuEtLmoNdDGCAcUwggHBAgEBMGswZTELMAkGA1UEBhMC SVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25p Y28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgIA0DAJBgUrDgMCGgUAoIGx MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDEwNDIwNDU1 M1owIwYJKoZIhvcNAQkEMRYEFIRw15B5Xetnl1Xptz+zKWjYJeZRMFIGCSqGSIb3DQEJDzFF MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAg7GAwxzk5DeGKTVJzgaaRrIBoVhr LrqtiQxRNzfg/DPQKcxmi9lPCA/zWPrhuB23T5+GLq4NDm2Sg6ha8kZAXRJjAbAkmgFwQgQb IvMfCBSWtcxrISgzvMHpeS/wxlFuB3p20phuVYS5sAe5MhQxTospfnvnSVF3XJoJk6T0XSk= --------------ms8C35EFC32CA2BD6B2CAAC7AD-- From owner-ietf-pkix Mon Jan 7 02:07:37 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07A7bt08222 for ietf-pkix-bks; Mon, 7 Jan 2002 02:07:37 -0800 (PST) Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07A7Z308212 for ; Mon, 7 Jan 2002 02:07:36 -0800 (PST) Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 2617BB6E6; Mon, 7 Jan 2002 11:08:04 +0100 (CET) Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVB5F; Mon, 7 Jan 2002 11:08:03 +0100 Message-ID: <3C3973C8.8EB2242B@secude.com> Date: Mon, 07 Jan 2002 11:09:12 +0100 From: Petra Barzin X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT (Win95; U) X-Accept-Language: de MIME-Version: 1.0 To: Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org Subject: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt] Content-Type: multipart/mixed; boundary="------------E5FF020258A5E3ED0FA6FBC3" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --------------E5FF020258A5E3ED0FA6FBC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Denis, I never received an answer to my mail. Here it is once again! I guess my timing of the mail wasn't very good since I posted it during the last IETF meeting. With the wrap up of the meeting and the christmas season you probably had enough to do. Could you please answer or comment my questions / remarks now! Thanks - Petra --------------E5FF020258A5E3ED0FA6FBC3 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from gateway.secude.com (gateway.intranet.secude.com [192.168.1.1]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YN33V841; Sun, 9 Dec 2001 16:22:51 +0100 Received: by gateway.secude.com (Postfix) id 420C11710E; Sun, 9 Dec 2001 16:22:51 +0100 (CET) Received: from above.proper.com (above.proper.com [208.184.76.39]) by gateway.secude.com (Postfix) with ESMTP id B79DE17108; Sun, 9 Dec 2001 16:22:49 +0100 (CET) Received: by above.proper.com (8.11.6/8.11.3) id fB9DrCV27715 for ietf-pkix-bks; Sun, 9 Dec 2001 05:53:12 -0800 (PST) Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9DrA227711 for ; Sun, 9 Dec 2001 05:53:11 -0800 (PST) Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D9D65B745; Sun, 9 Dec 2001 14:54:35 +0100 (CET) Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YN33V8TW; Sun, 9 Dec 2001 14:54:35 +0100 Delivered-To: barzin@secude.com Message-ID: <3C136D14.4F427161@secude.com> Date: Sun, 09 Dec 2001 14:54:28 +0100 From: Petra Barzin X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT (Win95; U) X-Accept-Language: de MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt References: <200111301102.GAA02928@ietf.org> <3C077425.3448DCC3@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis, I have three questions/comments regarding your DPV / DPD document: - I would like to see the signature to be only optional in a DPV response. You require the DPV response to be integrity protected. But you could authenticate the server using other means, for example SSL server authentication. - A DPV or DPD request can only contain one certificate. Shouldn't it be possible to include more than one certifiacte in a request? - Why do I need the optional requestor name in the DPV request and response? And why is this requestor name not included in the DPD protocol? Bye - Petra Denis Pinkas schrieb: > I have been asked by the co-chairs to prepare a requirements document for > DPV/DPD. While doing that task, requirements slighly different have been > identified for DSV. As a result of this request, you will find: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-00.txt > > a document which describes a protocol for the validation of CERTIFICATES > (and for the discovery of certification paths), and > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-req-00.txt > > a separate document which describes a protocol for the validation of > DIGITAL SIGNATURES. > > Both documents, which share several common points, will be presented > at the next IETF meeting. > > Denis --------------E5FF020258A5E3ED0FA6FBC3-- From owner-ietf-pkix Mon Jan 7 05:13:41 2002 Received: by above.proper.com (8.11.6/8.11.3) id g07DDfd19611 for ietf-pkix-bks; Mon, 7 Jan 2002 05:13:41 -0800 (PST) Received: from fep23-svc.tin.it (mta23-acc.tin.it [212.216.176.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07DDc319603 for ; Mon, 7 Jan 2002 05:13:39 -0800 (PST) Received: from skossa.andxor.it ([62.211.207.74]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <20020107131322.FGJS15319.fep23-svc.tin.it@skossa.andxor.it>; Mon, 7 Jan 2002 14:13:22 +0100 Received: (from tho@localhost) by skossa.andxor.it (8.11.3/8.11.3) id g07DCmK01073; Mon, 7 Jan 2002 14:12:48 +0100 (CET) (envelope-from tho) Date: Mon, 7 Jan 2002 14:12:48 +0100 From: tho To: Denis Pinkas , Peter Sylvester , Peter Gutmann , Taglialagamba Bianca , Andrea Caccia , Antonio Lioy Cc: ietf-pkix@imc.org, r.pedro@com-and.com, r.galli@com-and.com Subject: tsp interop test vector (proposal) Message-ID: <20020107141247.A865@skossa.andxor.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: hello everybody, in trying to organize some interop testing between all the publicly available rfc3161 implementations I have begun sketching down a set of test vectors and I'd like to discuss the matter with you ;-) the first (TSRQ-G_i) is made up of correctly formatted TimeStampReqs which we expect to be fulfilled by the TSA. Starting from a very basic request, we make vary some parameters: o TSRQ-G_001 -> basic request (none of the optional fields) o TSRQ-G_002 -> TSRQ-G_001 + nonce o TSRQ-G_003 -> TSRQ-G_001 + reqPolicy{=one supported by the actual TSA} o TSRQ-G_004 -> TSRQ-G_001 + certReq=TRUE ... other for all these TimeStampReqs we expect to get the signed receipt of the TSTInfo back from the TSA (which must be then verified in the many ways stated by the rfc) the second (TSRQ-E_i) is a vector of malformed (in a number of ways) TimeStampReqs: o TSRQ-E_001 -> bad asn.1 encoding (expected badDataFormat) o TSRQ-E_002 -> policy id not recognized (expected unacceptedPolicy) o TSRQ-E_003 -> weak or unknown hash algorithm (expected badAlg) o TSRQ-E_004 -> wrong protocol version (expected badRequest or badDataFormat) o TSRQ-E_005 -> length mismatch in messageImprint (expected badDataFormat) o TSRQ-E_006 -> unrecognized extension (expected unacceptedExtension) ... other the third (SBP-E_i) is `Socket Based Protocol' specific (really there should be one of these vectors for each of the transport protocols including HTTP, SMTP, etc. but for now we can start with `Socket Based Protocol' which seems to be the most widely deployed) and consists of the following: o SBP-E_001 -> packet with pollRep flag set o SBP-E_002 -> packet with pollReq flag set o SBP-E_003 -> packet with negPollRep flag set o SBP-E_004 -> packet with partialMsgRep flag set o SBP-E_005 -> packet with finalMsgRep flag set o SBP-E_006 -> packet with errorMsgRep flag set for all those above we expect a rejection with failInfo=badRequest o SBP-E_007 -> packet with length discrepancy (or a similar trick to test if there is a time-out mechanism on I/O) ... other I have just tried to use this framework for testing against my own implementation, the one from SIA and Peter Sylvester's (no SBP-E_i for him since the exposed interface is HTTP) and I've found it quite useful as it offers an _unified_ approach and the possibility to automate the procedure. Surely we can go more in-depth than this, and in fact this is just a starting point. tho -- From owner-ietf-pkix Mon Jan 7 06:08:10 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07E8AF21219 for ietf-pkix-bks; Mon, 7 Jan 2002 06:08:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07E89321215 for ; Mon, 7 Jan 2002 06:08:09 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14678; Mon, 7 Jan 2002 09:08:07 -0500 (EST) Message-Id: <200201071408.JAA14678@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Date: Mon, 07 Jan 2002 09:08:07 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: 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 Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP Author(s) : P. Gutmann Filename : draft-ietf-pkix-certstore-http-01.txt Pages : Date : 04-Jan-02 The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pkix-certstore-http-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certstore-http-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020104143711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certstore-http-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certstore-http-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020104143711.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Mon Jan 7 05:52:50 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07Dqoe20863 for ietf-pkix-bks; Mon, 7 Jan 2002 05:52:50 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Dqm320859 for ; Mon, 7 Jan 2002 05:52:48 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25610; Mon, 7 Jan 2002 14:53:47 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17480; Mon, 7 Jan 2002 14:52:16 +0100 Message-ID: <3C39A815.A66F7C30@bull.net> Date: Mon, 07 Jan 2002 14:52:21 +0100 From: Denis Pinkas Organization: Integris. A Bull Company X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Petra Barzin CC: ietf-pkix@imc.org Subject: Re: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt] References: <3C3973C8.8EB2242B@secude.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g07Dqn320860 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Petra, A new version has been posted last Friday to the web master. It should be published "soon". While waiting for the publication, here is an answer to your comments. > Denis, > > I never received an answer to my mail. Here it is once again! > > I guess my timing of the mail wasn't very good since I posted > it during the last IETF meeting. With the wrap up of the meeting > and the christmas season you probably had enough to do. You guessed very well. :-) > Could you please answer or comment my questions / remarks now! > > Thanks - Petra > > ---------------------------------------------------------------------------- > > Objet: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt > Date: Sun, 09 Dec 2001 14:54:28 +0100 > De: Petra Barzin > A: Denis Pinkas > Copies à: pkix > Références: <200111301102.GAA02928@ietf.org> <3C077425.3448DCC3@bull.net> > > Denis, > > I have three questions/comments regarding your DPV / DPD document: > > - I would like to see the signature to be only optional in a DPV response. > You require the DPV response to be integrity protected. But you could > authenticate the server using other means, for example SSL server > authentication. The text I have been preparing after the meeting, cares about your concern. "In order to be able to be confident that the validation of the certificate has correctly been done, the client only requires an authenticated response. In order for the client to prove to another party that trusts the same DPV server that the certificate validation was correct, the client requires a signed response." > - A DPV or DPD request can only contain one certificate. Shouldn't it be > possible to include more than one certifiacte in a request? This has been corrected. The new text is: "The Delegated Path Validation (DPV) protocol allows a server to validate one or more certificates according to a validation policy. " > - Why do I need the optional requestor name in the DPV request and > response? You do not need an optional requestor name in the DPV request. The new text is: "The server may require client authentication. The authentication method to be used may be dependant upon the transport used, and thus the client authentication mechanism need not be an integral part of the DPV request." > And why is this requestor name not included in the DPD protocol? The requestor name will need to be included in the DPD protocol. The new text is: "Policy definition requests SHALL be able to be authenticated so that only authorized clients can register policies." Regards, Denis > Bye - Petra > > Denis Pinkas schrieb: > > > I have been asked by the co-chairs to prepare a requirements document for > > DPV/DPD. While doing that task, requirements slighly different have been > > identified for DSV. As a result of this request, you will find: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-00.txt > > > > a document which describes a protocol for the validation of CERTIFICATES > > (and for the discovery of certification paths), and > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-req-00.txt > > > > a separate document which describes a protocol for the validation of > > DIGITAL SIGNATURES. > > > > Both documents, which share several common points, will be presented > > at the next IETF meeting. > > > > Denis From owner-ietf-pkix Mon Jan 7 08:42:59 2002 Received: by above.proper.com (8.11.6/8.11.3) id g07Ggxi28793 for ietf-pkix-bks; Mon, 7 Jan 2002 08:42:59 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ggw328785 for ; Mon, 7 Jan 2002 08:42:58 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18175; Mon, 7 Jan 2002 11:48:13 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018137; Mon, 7 Jan 02 11:47:51 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07GgaM29988 for ietf-pkix@imc.org; Mon, 7 Jan 2002 11:42:36 -0500 (EST) Date: Mon, 7 Jan 2002 11:42:36 -0500 (EST) Message-Id: <200201071642.g07GgaM29988@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-pkix@imc.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From owner-ietf-pkix Mon Jan 7 11:17:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07JHTK03063 for ietf-pkix-bks; Mon, 7 Jan 2002 11:17:29 -0800 (PST) Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07JHR303058 for ; Mon, 7 Jan 2002 11:17:27 -0800 (PST) Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com with ESMTP id g07JGm515930; Mon, 7 Jan 2002 12:16:48 -0700 (MST) Received: from trustdst.com (host192-35-174-247.digsigtrust.com [192.35.174.247]) by smtp.digsigtrust.com with ESMTP id g07JEx028945; Mon, 7 Jan 2002 12:14:59 -0700 (MST) Message-ID: <3C39F410.D37577EC@trustdst.com> Date: Mon, 07 Jan 2002 12:16:33 -0700 From: Russel F Weiser Reply-To: rweiser@trustdst.com Organization: Digital Signature Trust Co. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org CC: Peter Gutmann Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201071408.JAA14678@ietf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms98A47B4AC9B8F65D9B370C80" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms98A47B4AC9B8F65D9B370C80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter, Several comments regarding your new draft. 1. Within the section 2.2 examples the difference from the fetch of the CA certificate and the fetch of the CRL is only the URI base. You might want to note this difference in the examples just to clarify. 2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would be another approperiate certificate extension for also encoding the Certificate retrieval URI as discussed in 2.2 . I believe that going forward this should be the primarily used to access the certificats. 3. I don't understand why the CRLDP extension could not be leveraged to support URI based queries you discribe in your draft? To me this seems like the logical location to place the CRL query uri. It would seem that use the AIA Extension to get the Authority certificate, SIA extension to get the subject extension and then use CRLDP to get the CRLS would be the best overall approach. If the certificate doesn't populate the SIA then the Client should utilize the AIA extension to query for the Subjects certificate. I still believe the CRLDP should be used for CRL retrieval. Unless you are also thinking of additionally supporting the concept of allowing queries for a CRL form a particular CA with an added parameter of asofDATE/TIME which could be a useful way of obtaining archived CRLs for use in attempting to valid signed data etc.. cheers RFW --------------ms98A47B4AC9B8F65D9B370C80 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 MIIUKgYJKoZIhvcNAQcCoIIUGzCCFBcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EiYwggdPMIIGN6ADAgECAhEA0B5HQQAAAnwAAAALAAACQjANBgkqhkiG9w0BAQUFADBdMQsw CQYDVQQGEwJVUzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRAwDgYD VQQLEwdUcnVzdElEMRYwFAYDVQQDEw1UcnVzdElEIENBIEExMB4XDTAxMDYxNTAwMDc1MloX DTAyMDYxNTAwMDc1MlowgeoxCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwRVdGFoMRcwFQYDVQQH Ew5TYWx0IExha2UgQ2l0eTEgMB4GA1UEChMXRElHSVRBTCBTSUdOQVRVUkUgVFJVU1QxIDAe BgNVBAsTF0RJR0lUQUwgU0lHTkFUVVJFIFRSVVNUMRgwFgYDVQQDEw9SdXNzZWwgRiBXZWlz ZXIxIzAhBgkqhkiG9w0BCQEWFHJ3ZWlzZXJAdHJ1c3Rkc3QuY29tMTAwLgYKCZImiZPyLGQB ARMgRDAxRTQ3NDEwMDAwMDBFNzE5Njc4NUIyMDAwMDAyNDQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKHHyOSdcBO3q3jEfX6uvJweZNUlICehukslfQPQZ8nWKDHrzPKGQ590X9e7 4Ors0Z907ZgbjkWbbe9FyRNjSzzy+JvopT9eQQDe2xI50/4TFQx7aApT/7Mice5FcBXRM9Bu X/7we5AmEmYjYuxPY++eFwUF0VMgDllSycRk5jQBAgMBAAGjggP+MIID+jAOBgNVHQ8BAf8E BAMCBPAwHwYDVR0jBBgwFoAUKqXwfvTw7zTVnacomA8j05+7cwQwggFCBgNVHSAEggE5MIIB NTCCATEGCmCGSAGG+S8ABgIwggEhMEcGCCsGAQUFBwIBFjtodHRwOi8vd3d3LmRpZ3NpZ3Ry dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDCB1QYIKwYBBQUHAgIw gcgagcVUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24g YnkgQXV0aG9yaXplZCBSZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBU cnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwOi8vd3d3LmRpZ3NpZ3Ry dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDCBjwYDVR0fBIGHMIGE MIGBoH+gfYZ7bGRhcDovL2xkYXAuZGlnc2lndHJ1c3QuY29tL2NuPVRydXN0SUQgQ0EgQTEs b3U9VHJ1c3RJRCxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLixjPVVTP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MIHWBglghkgBhvhCAQ0EgcgWgcVUaGlzIFRydXN0 SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgQXV0aG9yaXplZCBS ZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwOi8vd3d3LmRpZ3NpZ3RydXN0LmNvbS9jZXJ0aWZp Y2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDAfBgNVHREEGDAWgRRyd2Vpc2VyQHRydXN0ZHN0 LmNvbTAdBgNVHQ4EFgQUclmKR82awQP3Rhrn59Zyz6mYyhowgbYGCCsGAQUFBwEBBIGpMIGm MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5kaWdzaWd0cnVzdC5jb20wewYIKwYBBQUHMAKG b2xkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0LmNvbS9jbj1UcnVzdElEIENBIEExLG91PVRydXN0 SUQsbz1EaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4sYz11cz9jQWNlcnRpZmljYXRlO2Jp bmFyeTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEFBQADggEB AEGFIP1YTvY/sDMMQGKPuq7fBjyRjblAUV9rKhwM3Lm5FcW1L2sciA8NIqRIpacm5jp8M7Wi LFPfJMzSlRKqbETRUy2faYeXueGYlpSv2oSWVRxUQhqJK4oQa3k7NqERYChR1K6raLLwGgdn UgfjIa0djWTlXBXXnOfSUohGBetMwOhugCanJT/VmLsSftwzk6oNpx5xK09ZgjBXQJjggudh Uov5AnmlR9cWN3KsDfp6jH2xo9pLpd+V4Wb3SkUNkmjA5PsF9SY5J5bKy1zbXYMEGZqsEVV3 yE6LGCNCh5yuIyhSIFyORluAdR3krWJbbAXMLJIagG+B9Xkl9PRH/9EwggclMIIGDaADAgEC AhEA0B5HOAAAAnwAAAACAAAACDANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQKExtEaWdpdGFs IFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4XDTAwMTAw MTAwMDAwNFoXDTA1MTAwMTAwMDAwNFowXTELMAkGA1UEBhMCVVMxJDAiBgNVBAoTG0RpZ2l0 YWwgU2lnbmF0dXJlIFRydXN0IENvLjEQMA4GA1UECxMHVHJ1c3RJRDEWMBQGA1UEAxMNVHJ1 c3RJRCBDQSBBMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnPcD1Ny0/gmEg PkAq5olccaeuuFNWeKWbwJU3iTON3D6wjKQ8/iW0SJbxhnvYFlqR8DlvsoiU0Lu9jIO/sGGf Xh8n86hSsoe8yazGaQ6Ml73Tgntm7/LLTm+Y7soTzvbbH67lajmIxUhsUZv6GMDKjHFzaQR6 uj5Fmkb2hhuqbN/JUN5NhE/B4iEgOkO45RX/tSa0nWvwgoIwLTvUIgLeSzHA+Zv6YFFbUSFr NKxAKSfb4IVEBBKeaA06Hnjvmz0A5uiKdyhc6VVT4ul//xp2HvELvKx/TbXbKVleyiLnWQDQ DmgJV2kb0vajFIJeiXBV/Mj2NiJ1UTbXdBGxjJUCAwEAAaOCA/wwggP4MA8GA1UdEwEB/wQF MAMBAf8wDgYDVR0PAQH/BAQDAgHGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAf BgNVHSMEGDAWgBTEp7Gkeyxx+tvhS5B1/8QVYIWJEDCCAncGA1UdIASCAm4wggJqMIIBMQYK YIZIAYb5LwAGATCCASEwRwYIKwYBBQUHAgEWO2h0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29t L2NlcnRpZmljYXRlcy9wb2xpY3kvdHNpbmRleC5odG1sMIHVBggrBgEFBQcCAjCByBqBxVRo aXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBBdXRo b3JpemVkIFJlbHlpbmcgUGFydGllcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIFRydXN0SUQg Q2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29t L2NlcnRpZmljYXRlcy9wb2xpY3kvdHNpbmRleC5odG1sMIIBMQYKYIZIAYb5LwAGAjCCASEw RwYIKwYBBQUHAgEWO2h0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHNpbmRleC5odG1sMIHVBggrBgEFBQcCAjCByBqBxVRoaXMgVHJ1c3RJRCBDZXJ0 aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBBdXRob3JpemVkIFJlbHlpbmcg UGFydGllcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9s aWN5IGZvdW5kIGF0IGh0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w b2xpY3kvdHNpbmRleC5odG1sMH0GA1UdHwR2MHQwcqBwoG6GbGxkYXA6Ly9sZGFwLmRpZ3Np Z3RydXN0LmNvbS9jbj1EU1QgUm9vdCBDQSBYMyxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0 IENvLj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTB8BggrBgEFBQcBAQRwMG4w bAYIKwYBBQUHMAKGYGxkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0LmNvbS9jbj1EU1QgUm9vdCBD QSBYMyxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLj9jQUNlcnRpZmljYXRlO2JpbmFy eTAdBgNVHQ4EFgQUKqXwfvTw7zTVnacomA8j05+7cwQwDQYJKoZIhvcNAQEFBQADggEBAKP6 Q5KgNXM9H/ER5y5TncMvmLatjSaNV7ig983MXKfixbSKX77KUUoSL39378RVpNSVeiWvplNL UDcuvuGMGRgDBXSmokdIjYhhMnaLXdcvqZ2J3SeCz6Muu2z8Ve9IGnNHApReJ82+iKXaxcxo knk3ObfRtBjwIewELpLbjDiPdCsWuAcnbmcbm8e1dHrOfIwg3n97zLZbX8vRA1+xYCdElbLv kOf2wIdDzYx2zRkmTHo/HQzXjZN/xF7Xnp8cwGENKtlt0Tgr0ddL7MohJtzzo3Dwe+uOuJV/ YVD57v7kYvVeZ0N7BKWCHQzGlYf5J5GWsSspofuDaZi/Ymr5N00wggOmMIICjqADAgECAhEA 0B5HGgAAAnwAAAAWAAAAAjANBgkqhkiG9w0BAQUFADCBqTELMAkGA1UEBhMCdXMxDTALBgNV BAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQwIgYDVQQKExtEaWdpdGFsIFNp Z25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgxMRYwFAYDVQQDEw1EU1QgUm9v dENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVzdC5jb20wHhcNMDAxMDMwMjMy OTU0WhcNMDgwODI5MjMyOTU0WjA/MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVz dCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA36/pl1AIg1e0zGJl9pCC7MfTLGswylvs2cN9x0DBGBSL4Ogzdkkq4z8hSZOs Tg6vPkjLZe780yEPZdIq2TKPjOX3d7ASe7WVwImjqbrtcy56DAYyg6J+ihQwzRGg4So4uXkK Mf1QvYBl37dRY4PI4ohh6kthgexSa7mi4ksaKJ9Io54M2gmOPhcuHt0g31vGKoqrLr1wrcUL GiWQdHLFe2qrNNYwif/laBN7VAvI1q7sWpySHj1ks4zG37/JQXDsFnLVJuw4VTlD0Pz9GFxA 8Zfr1ZqbjR262iW5xtjfwRUCOqvabvE+LvVcCJw81oNp5BCbGSq2KVfj5T2bn/ACXQIDAQAB ozIwMDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTEp7Gkeyxx+tvhS5B1/8QVYIWJEDAN BgkqhkiG9w0BAQUFAAOCAQEAIph/TRYnCkJBg7jSj1iqB1rzjl67pxzAZRmN7hpOyX8bXipC dMN5NMGOnUlSunXGUjw2OP3ickjrHGfYJgzN1G2HCZ8SR9tgBpzgGUywu5XA7KOPa8iCDNDH 28jXeCCUBC5qkIIRcEVMzYH+cpBFxkcwnrbEz2zcYQRmSxXAyVDh8VOyE7p8LxD6DgP9APtQ JOgpN1UYSryAoZkOzzXwTJDBJpsng1/jSkecD4XHFKWR1fQFdxIf2uVmLlTjs69h91cAptIr YyQyznHeWPDRoGc0b5Ka3GAHQplYrE32mfxHluW9io6+TNVK6t0PJnLaXymtpGWEdPxKqPSa cRDD8DGCAcwwggHIAgEBMHIwXTELMAkGA1UEBhMCVVMxJDAiBgNVBAoTG0RpZ2l0YWwgU2ln bmF0dXJlIFRydXN0IENvLjEQMA4GA1UECxMHVHJ1c3RJRDEWMBQGA1UEAxMNVHJ1c3RJRCBD QSBBMQIRANAeR0EAAAJ8AAAACwAAAkIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDcxOTE2MzVaMCMGCSqGSIb3DQEJBDEW BBQ+pgZjw/LW8ZfjpqQpZ7ZQJXyJtjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASBgISL+4Fu3zo7xJaKLZNVdzMiBkYcsm2YP9PtI+mZKgQ9g224jSu8 GGvlSAPyVzc4fWujvHPrHMKT4Kkhl6VnITaGGQZUGj6hVWXcj4wvES8ybiLO65bfPGIVPSLm pwcYerttjzDr4CnEEwQx0oCulGTUQ4n9GRFzMVkLtmc3F8EF --------------ms98A47B4AC9B8F65D9B370C80-- From owner-ietf-pkix Mon Jan 7 21:05:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0855mD12920 for ietf-pkix-bks; Mon, 7 Jan 2002 21:05:48 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0855e312915 for ; Mon, 7 Jan 2002 21:05:46 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA26901; Tue, 8 Jan 2002 18:04:50 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA119848; Tue, 8 Jan 2002 18:04:49 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Tue, 8 Jan 2002 18:04:49 +1300 (NZDT) Message-ID: <200201080504.SAA119848@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, Peter.Sylvester@edelweb.fr, a.caccia@innovery.net, bianca.taglialagamba@sia.it, lioy@polito.it, pgut001@cs.auckland.ac.nz, thomas.fossati@tin.it Subject: Re: tsp interop test vector (proposal) Cc: ietf-pkix@imc.org, r.galli@com-and.com, r.pedro@com-and.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: tho writes: >in trying to organize some interop testing between all the publicly available >rfc3161 implementations I have begun sketching down a set of test vectors and >I'd like to discuss the matter with you ;-) I don't know how well some of the negative-response testing will work. For example most of the policies I've seen are either unknown or just randomly- invented OIDs, so my implementation ignores policies because otherwise it couldn't interop with anything at all. Based on the incredible number of bugs in related stuff like certs (see for example the X.509 style guide) I'm also extremely flexible with message contents, for example if the field looks more or less right or doesn't affect the entire operation I just skip it and move on. In particular I ignore most of the stream-protocol flags based on the confusion I saw in CMP interop testing when, no matter what flags were (presumably erroneously) set, the other side usually just wanted the most basic request-response operation. Trying to fiddle with polling when the other side has lost interest and gone home doesn't make your software look very functional to the user. (Aside: I have probably spent about an order of magnitude more time adding workarounds for bugs to my cert-handling code than in writing the original code itself. Over time, I've also removed more and more checks on (non- security-related) items in order to get it to work with broken certs coming from other software. There are still (security-related) checks in there which are rejecting certs which result in people sending me "bug" reports, but I'm not going to remove those... as a non-commercial vendor I can afford to lose a few users if they think it's a problem). I would expect that other implementors are also writing code which tries to DTRT in the face of broken requests and implementations. This means that a lot of the negative-response tests you're proposing would fail, because the other side would look at the problem, decide it's irrelevant to the operation of the protocol, and continue. For example my policy OID is: /* Dummy policy OID for the TSA ('snooze policy, "Anything that arrives, we sign") */ and I've never found an implementation which has any problems with this. Peter. From owner-ietf-pkix Mon Jan 7 23:43:19 2002 Received: by above.proper.com (8.11.6/8.11.3) id g087hJY24343 for ietf-pkix-bks; Mon, 7 Jan 2002 23:43:19 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g087hH324333 for ; Mon, 7 Jan 2002 23:43:17 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id UAA29681; Tue, 8 Jan 2002 20:42:56 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA123185; Tue, 8 Jan 2002 20:42:55 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Tue, 8 Jan 2002 20:42:55 +1300 (NZDT) Message-ID: <200201080742.UAA123185@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, rweiser@trustdst.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: pgut001@cs.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Russel F Weiser writes: >1. Within the section 2.2 examples the difference from the fetch of the CA >certificate and the fetch of the CRL is only the URI base. You might want to >note this difference in the examples just to clarify. OK. >2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would be >another approperiate certificate extension for also encoding the Certificate >retrieval URI as discussed in 2.2 . I believe that going forward this should >be the primarily used to access the certificats. Good idea, I'll mention it in the next draft. >3. I don't understand why the CRLDP extension could not be leveraged to >support URI based queries you discribe in your draft? To me this seems like >the logical location to place the CRL query uri. It won't work, the rationale in 3.4 explains why. Peter. From owner-ietf-pkix Tue Jan 8 04:19:05 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08CJ5U26166 for ietf-pkix-bks; Tue, 8 Jan 2002 04:19:05 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08CJ3326161 for ; Tue, 8 Jan 2002 04:19:03 -0800 (PST) Received: from fwd03.sul.t-online.de by mailout09.sul.t-online.de with smtp id 16NvDV-0003oW-02; Tue, 08 Jan 2002 13:18:57 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.20.8]) by fmrl03.sul.t-online.com with esmtp id 16NvDF-100np2C; Tue, 8 Jan 2002 13:18:41 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B1F58157CE2 for ; Tue, 8 Jan 2002 13:19:29 +0100 (CET) Message-ID: <3C3AE3D1.B7AB99CB@stroeder.com> Date: Tue, 08 Jan 2002 13:19:29 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Reply-To: michael@stroeder.com Organization: stroeder.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201071408.JAA14678@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 520010731148-0001@t-dialin.net Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Internet-Drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-01.txt I have some problems with section 2.1: Maybe it's me (I'm not a native english speaker) but I read it like all search values have to be hashed and base64-encoded except subjectKeyIdentifier. How about e.g. search attribute email? To avoid misinterpretation I'd prefer having a table which states exactly how to treat each search attribute on the client side if necessary before submitting the query. Or at least starting section 2.1 with "The fields [complete binary attribute list]...are of" instead of "Some of the fields...are of". IMHO for a low-tech use-case with wide-spread acceptance ;-) it should be possible to create a simple HTML form with the

's attribute action= pointing to the URL of the "HTTP Certificate Store Interface". For this simple scenario pre-processing (hashing) of search values at the client side is unfeasible (except when using Javascript or similar beasty things). I'd also suggest that it should be possible to pass a subject DN in RFC2253 string representation as (x-www-form-urlencoded) search value. Maybe your could