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 provide a separate search attribute rfc2253Name? Even though the length is theoretically unlimited the usual string length of DNs shouldn't be an issue with today's web servers. E.g. for security reasons I'm limiting string repr. of DNs to 1024 bytes in web2ldap and - guess what - never hit the limit. As long as you don't impose a hard limit in the draft there shouldn't be a problem with it. Now off course the really interesting part is "3. Locating HTTP Certificate Stores": IMHO locating a cert store in the Internet falls into two different steps: 1. Locating a server name or IP address *and* port of a cert store 2. Some well-defined addressing rules once the IP address is known One should not mix these two levels. The rules in section 3.2 for forming the URIs more or less sufficiently addresses 2. by defining the well-known PATH_INFO /search.cgi but fall short for 1. Your example already shows the problem: --------------- snip --------------- certificates./search.cgi crls./search.cgi Service providers SHOULD use these URIs in preference to other alternatives. For example if a CA with the domain kiwisign.com were to make its certificates available via an HTTP certificate store interface, the "well-known" query URIs for certificates and CRLs would be: certificates.kiwisign.com/search.cgi crls.kiwisign.com/search.cgi" --------------- snip --------------- Now what's our use-case here? Most times a user has an e-mail address of a recipient and wants to obtain the matching certificate for the recipient's e-mail address. The sender does not know the issuer of the certificate in advance => the in the example above is unknown. Or maybe I misunderstood something? Maybe it's not clear enough what the term "service provider" means in this context. And that's exactly the same case where LDAP-based cert stores fall short today. My suggestion would be to run certificate stores holding e-mail certs associated to e-mail domains. Like there are DNS MX RRs for each e-mail domain there could be DNS SRV RRs for the e-mail domains pointing to the certificate stores' DNS A or CNAME RR and port number. In this case "service provider" would be the domain name hoster for the recipient's e-mail address. IMHO draft-ietf-pkix-pkixrep-00 went in that direction but expired silently. :-( I cannot really comment on UPNP and determining net_loc but is net_loc really solely an IP address or a DNS name as you described or a host:port location? I think URI generation for both cases should be unified. Ciao, Michael. From owner-ietf-pkix Tue Jan 8 04:41:40 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08CfeW26744 for ietf-pkix-bks; Tue, 8 Jan 2002 04:41:40 -0800 (PST) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Cfd326740 for ; Tue, 8 Jan 2002 04:41:39 -0800 (PST) Received: from fwd09.sul.t-online.de by mailout11.sul.t-online.de with smtp id 16NvZT-0008B6-01; Tue, 08 Jan 2002 13:41:39 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.169.127]) by fmrl09.sul.t-online.com with esmtp id 16NvZ9-1TaezAC; Tue, 8 Jan 2002 13:41:19 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 997C4157CE2 for ; Tue, 8 Jan 2002 13:42:56 +0100 (CET) Message-ID: <3C3AE950.1F809CB1@stroeder.com> Date: Tue, 08 Jan 2002 13:42:56 +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> <3C39F410.D37577EC@trustdst.com> 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: Russel F Weiser wrote: > > 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. While I understand the rationale in section 3.4 that AIA and CRLDP extensions are different in semantics I think the CRL could be retrieved via CRLDistributionPoint as long as the HTTP certificate store interface behaves as expected for CRLDistributionPoint. IMHO this mainly depends on what search attributes/values are used for forming the URI. An additional note could state that the issuer MAY use the URI of the issuer's HTTP certificate store interface for generating a URI for extension CRLDistributionPoint.distributionPoint.fullName but is certainly responsible for generating a URI which works as expected for semantics of CRLDistributionPoint. But I don't understand this sentence in section 3.4: "In addition CRLDP associates other attribute information with a query which is incompatible with the simple query mechanisms presented in this document." > I still believe the CRLDP should be used for CRL retrieval. Me too. ;-) Ciao, Michael. From owner-ietf-pkix Tue Jan 8 07:18:35 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08FIZc06021 for ietf-pkix-bks; Tue, 8 Jan 2002 07:18:35 -0800 (PST) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08FIY306015 for ; Tue, 8 Jan 2002 07:18:34 -0800 (PST) Received: from fwd03.sul.t-online.de by mailout02.sul.t-online.de with smtp id 16Ny1F-000509-09; Tue, 08 Jan 2002 16:18:29 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.20.12]) by fmrl03.sul.t-online.com with esmtp id 16Ny0z-0N1yyWC; Tue, 8 Jan 2002 16:18:13 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 5C3C0157CE2 for ; Tue, 8 Jan 2002 16:19:50 +0100 (CET) Message-ID: <3C3B0E15.E34E6EF4@stroeder.com> Date: Tue, 08 Jan 2002 16:19:49 +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> <3C3AE3D1.B7AB99CB@stroeder.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Sender: 520010731148-0001@t-dialin.net Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Michael Ströder wrote: > > IMHO locating a cert store in the Internet falls into two different > steps: > 1. Locating a server name or IP address *and* port of a cert store > 2. Some well-defined addressing rules once the IP address is known BTW: Although not necessary for security a service provider running a HTTP cert store might want to provide this service with SSL for privacy reasons. Therefore the URL scheme is part of the 1. step. => Section 3.2 has to define rules for deriving URL scheme, host name/IP address and port number. Ciao, Michael. From owner-ietf-pkix Tue Jan 8 09:44:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g08HiqK11175 for ietf-pkix-bks; Tue, 8 Jan 2002 09:44:52 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Hip311169 for ; Tue, 8 Jan 2002 09:44:51 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g08HhEU09251 for ; Tue, 8 Jan 2002 12:43:14 -0500 (EST) Message-ID: <200201081743.g08HhD509247@stingray.missi.ncsc.mil> Date: Tue, 08 Jan 2002 12:43:06 -0500 From: "David P. Kemp" X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: 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> <3C39F410.D37577EC@trustdst.com> <3C3AE950.1F809CB1@stroeder.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-H-S-Loop-Check-Ejzfr: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: CRLDP is, IMHO, fundamentally flawed because it combines two unrelated functions: 1. cryptographically binding a certificate to the specific partitioned CRL that applies to that certificate, and 2. facilitating retrieval of the CRL from a repository. PKIX Part 1 Section 6.3.3: CRL Processing gives the algorithm for determining if a certificate is revoked. Step 1 is: "(1) locate the corresponding CRL in CRL cache, and ..." The "corresponding CRL" is determined by comparing the CRLDP extension in the certificate with the IDP extension in the cached CRLs, using an algorithm that is not completely specified. For example, if CRLDP and IDP each contain a DistributionPointName:fullName with two GeneralName's: a directoryName that matches and a URI that does not match, does the CRL correspond to the certificate or not? I believe that the CRL partitioning algorithm should say that URI forms of DistributionPointName are *not* compared when determining if a CRL applies to a particular certificate, and that other forms of DPN *are* compared. But since that would be a butt-ugly special-case hack of a rule, I agree with Peter that AIA should be used to hold retrieval information, and CRLDP/IDP should be used to hold only partitioning information. The next-to-last sentence of Section 6.3.3 is: "The verifier must repeat the process above with the additional CRLs not specified in a distribution point." How are those additional CRLs retrieved? AIA. Regards, Dave Michael Ströder wrote: > > Russel F Weiser wrote: > > > > 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. > > While I understand the rationale in section 3.4 that AIA and CRLDP > extensions are different in semantics I think the CRL could be > retrieved via CRLDistributionPoint as long as the HTTP certificate > store interface behaves as expected for CRLDistributionPoint. IMHO > this mainly depends on what search attributes/values are used for > forming the URI. > > An additional note could state that the issuer MAY use the URI of > the issuer's HTTP certificate store interface for generating a URI > for extension CRLDistributionPoint.distributionPoint.fullName but is > certainly responsible for generating a URI which works as expected > for semantics of CRLDistributionPoint. > > But I don't understand this sentence in section 3.4: > "In addition CRLDP associates other attribute information with a > query which is > incompatible with the simple query mechanisms presented in this > document." > > > I still believe the CRLDP should be used for CRL retrieval. > > Me too. ;-) > > Ciao, Michael. From owner-ietf-pkix Tue Jan 8 10:59:31 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08IxVT14130 for ietf-pkix-bks; Tue, 8 Jan 2002 10:59:31 -0800 (PST) Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08IxU314126 for ; Tue, 8 Jan 2002 10:59:30 -0800 (PST) Received: from [64.24.208.197] (helo=salford.ac.uk) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 16O1T0-0002BU-00 for ietf-pkix@imc.org; Tue, 08 Jan 2002 18:59:23 +0000 Message-ID: <3C3B4002.8B089757@salford.ac.uk> Date: Tue, 08 Jan 2002 18:52:51 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX Subject: SLides for SLC Content-Type: multipart/mixed; boundary="------------9C2352FA257A15290F380C89" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------9C2352FA257A15290F380C89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve I tried to send my slides to you, but the message was bounced from your site. Perhaps the roving ISP I am using is banned by your administrator as a perveyor of SPAM? Should I send them to the list? David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------9C2352FA257A15290F380C89 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------9C2352FA257A15290F380C89-- From owner-ietf-pkix Tue Jan 8 11:47:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08JlCp15679 for ietf-pkix-bks; Tue, 8 Jan 2002 11:47:12 -0800 (PST) Received: from tiznit.digitaldelivery.com (wks99.digitaldelivery.com [64.241.183.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08JlA315675 for ; Tue, 8 Jan 2002 11:47:11 -0800 (PST) Received: by TIZNIT with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 14:47:07 -0500 Message-ID: From: Scott Mustard To: "PKIX (E-mail)" Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard Date: Tue, 8 Jan 2002 14:46:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Datum's StampServer is available for test at 64.241.183.87. If your request includes the certReq field set to true, the time-stamp token will include an attribute certificate in addition to the required TSA certificate. Some decoders cannot handle attribute certificates in the certificate list. If you have a problem decoding our response, we can supply the ASN.1 definition for attribute certificates and for our timing-metrics attribute. Regards, Scott Mustard Datum - Trusted Time Division http://www.datum.com/tt/ 10 Maguire Road Suite 120 Lexington, MA 02421-3110 From owner-ietf-pkix Tue Jan 8 13:45:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LjC319965 for ietf-pkix-bks; Tue, 8 Jan 2002 13:45:12 -0800 (PST) Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g08Lj9319960 for ; Tue, 8 Jan 2002 13:45:10 -0800 (PST) Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 08 Jan 2002 21:44:43 -0000 X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71 Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Jan 2002 21:41:44 -0000 Message-ID: <608D67882786D211B1070090271E4CB976722F@bjex1.bj.co.uk> From: "Piers Chivers" To: "'ietf-pkix@imc.org'" Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Date: Tue, 8 Jan 2002 21:41:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1025B7C166111-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1988D.442A8032" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1988D.442A8032 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter, This may be off-topic but have you considered a SOAP version of this protocol. SOAP messages can be transported over http, hence meeting this requirement, but can also be transported over SMTP etc. This seems to me to be a more general approach than the one described here. Section 2. email "Email address contained in the certificate..." What does this mean? I think you should be more explicit. Will the search be against an email attribute in the subject DN, or an attribute in the subject alternative name... Section 2.1 "The one exception to this process is the subjectKeyIdentifier..." I hate exceptions to rules;) Why bother with this proviso? OK, it stops one needless hash but it introduces additional coding at both the client and server. Why not just hash the hash? Section 2.2 Although earlier text indicates why, the examples for retrieving a CA cert and a CRL are identical in this section. I think this should be clarified (by indicating a query URI appropriately) Section 2.2 Rational Typo - should be Section 2.3 I appreciate your rationale but, as a client implementer, I don't want to care what technology the CA is using to store the certs (RDBMS, LDAP, whatever). But, as an LDAP zealot, I think there is a requirement to support cert lookup by a textual representation of the subject DN. Maybe the LDAP server vendors can comment? Regards, Piers 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 Piers Chivers Product Architect Protek Network Security +44 (0)1270 507800 www.protek.com -------------------------------------------------------------------------------- This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. ------_=_NextPart_001_01C1988D.442A8032 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Peter,

This may be off-topic but have you considered a SOAP version of this = protocol.  SOAP messages can be = transported over http, hence meeting this requirement, but can also be transported over SMTP = etc.  This seems to me to be a more = general approach than the one described here.

 

Section 2.

email       = "Email address contained in the certificate..."

What does this mean? I think you should be more explicit. Will the search be = against an email attribute in the subject DN, or an attribute in the subject alternative name...

 

Section 2.1

"The one exception to this process is the subjectKeyIdentifier..."

I hate exceptions to rules;)  Why bother with this = proviso?  OK, it stops one needless hash = but it introduces additional coding at both the client and server.  Why not just hash the = hash?

 

Section 2.2

Although earlier text indicates why, the examples for retrieving a CA cert and a = CRL are identical in this section.  = I think this should be clarified (by indicating a query URI = appropriately)

 

Section 2.2 Rational

Typo - should be Section 2.3

I appreciate your rationale but, as a client implementer, I don't want to = care what technology the CA is using to store the certs (RDBMS, LDAP, whatever). But, as an LDAP zealot, I think there is a = requirement to support cert lookup by a textual representation of the subject = DN.  Maybe the LDAP server vendors = can comment?

 

Regards,

Piers

 

 

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 

       &nb= sp;           &nb= sp;      Protocols: Certificate Store Access via HTTP

      = Author(s)   : P. Gutmann

      = Filename    = : draft-ietf-pkix-certstore-http-01.txt

      = Pages       :

      = Date        = : 04-Jan-02

      =

 

 

 

Pier= s Chivers

Prod= uct Architect

Prot= ek Network Security

+44 = (0)1270 507800

www.protek.com

 

--------------------------------------------------------------------------------
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.


------_=_NextPart_001_01C1988D.442A8032-- From owner-ietf-pkix Tue Jan 8 19:55:34 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g093tYe00906 for ietf-pkix-bks; Tue, 8 Jan 2002 19:55:34 -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 g093tW300902 for ; Tue, 8 Jan 2002 19:55:32 -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 QAA25589; Wed, 9 Jan 2002 16:55:28 +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 QAA146976; Wed, 9 Jan 2002 16:55:27 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 16:55:27 +1300 (NZDT) Message-ID: <200201090355.QAA146976@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, smustard@datum.com Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Scott Mustard writes: >Datum's StampServer is available for test at 64.241.183.87, Which port, and which protocol? Peter. From owner-ietf-pkix Tue Jan 8 20:20:49 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g094KnO01588 for ietf-pkix-bks; Tue, 8 Jan 2002 20:20:49 -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 g094Kk301584 for ; Tue, 8 Jan 2002 20:20:47 -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 RAA26319; Wed, 9 Jan 2002 17:20:35 +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 RAA147993; Wed, 9 Jan 2002 17:20:29 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 17:20:29 +1300 (NZDT) Message-ID: <200201090420.RAA147993@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, pchivers@protek.com Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: "Piers Chivers" writes: >This may be off-topic but have you considered a SOAP version of this protocol. >SOAP messages can be transported over http, hence meeting this requirement, >but can also be transported over SMTP etc. This seems to me to be a more >general approach than the one described here. I've had comments from people about XML versions ages ago (the certs-over-http stuff has been in use privately for awhile, which is why some of the stuff in the draft is based on implementation experience), but I'll leave that to someone else. I just wanted to create a lowest-common-denominator gimme-a-cert mechanism which is as plug-and-play as possible, if anyone wants something more complex they can profile it or whatever. (I'm also not too sure what SOAP would add, apart from making it a lot less general). >email "Email address contained in the certificate..." What does this >mean? I think you should be more explicit. Will the search be against an email >attribute in the subject DN, or an attribute in the subject alternative name... It doesn't matter. An email address is an email address, they can stuff it in the keyUsage for all I care. >"The one exception to this process is the subjectKeyIdentifier..." I hate >exceptions to rules;) Why bother with this proviso? OK, it stops one >needless hash but it introduces additional coding at both the client and >server. Why not just hash the hash? Actually where it's being used at the moment the hash is hashed, mostly because sKIDs can have arbitrary lengths and you need a way to make them uniform. I didn't do the hash-of-hash because I thought there'd be complaints, but I agree with you that it's a better way to do it. I'll fix it in the next draft. >Although earlier text indicates why, the examples for retrieving a CA cert and >a CRL are identical in this section. I think this should be clarified (by >indicating a query URI appropriately) Done. Peter. From owner-ietf-pkix Tue Jan 8 21:08:19 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0958JG02841 for ietf-pkix-bks; Tue, 8 Jan 2002 21:08: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 g0958I302837 for ; Tue, 8 Jan 2002 21:08:18 -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 SAA27187; Wed, 9 Jan 2002 18:08:12 +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 SAA148750; Wed, 9 Jan 2002 18:08:12 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 18:08:12 +1300 (NZDT) Message-ID: <200201090508.SAA148750@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, michael@stroeder.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Michael StrM-vder writes: >While I understand the rationale in section 3.4 that AIA and CRLDP extensions >are different in semantics I think the CRL could be retrieved via >CRLDistributionPoint as long as the HTTP certificate store interface behaves >as expected for CRLDistributionPoint. But it doesn't behave that way. As the rationale points out, CRLDP points at a static CRL while the draft uses a general CRL query mechanism. To put it another way, let's say you get a cert with a CRLDP containing a URI: foo.bar.com/qwertyuiop What are you supposed to do with this? If you follow CRLDP semantics, you go to foo.bar.com and do a GET /qwertyuiop HTTP/1.0. If you follow the draft semantics you go to foo.bar.com and do a GET /qwertyuiop/search-cgi?iHash= HTTP/1.0 (or whatever key you're using). Unless you completely redefine the semantics of CRLDP to constrain it to follow the functionality in the draft, you can't do this. >But I don't understand this sentence in section 3.4: "In addition CRLDP >associates other attribute information with a query which is incompatible with >the simple query mechanisms presented in this document." You can specify all sorts of stuff like reason flags which can't be accomodated by a key-and-value lookup mechanism. Peter. From owner-ietf-pkix Tue Jan 8 20:59:48 2002 Received: by above.proper.com (8.11.6/8.11.3) id g094xmd02569 for ietf-pkix-bks; Tue, 8 Jan 2002 20:59: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 g094xj302561 for ; Tue, 8 Jan 2002 20:59: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 RAA26095; Wed, 9 Jan 2002 17:59:39 +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 RAA148615; Wed, 9 Jan 2002 17:59:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 17:59:39 +1300 (NZDT) Message-ID: <200201090459.RAA148615@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, michael@stroeder.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Michael StrM-vder writes: >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". Done. >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). The human-usable forms are all text-only. I doubt a user will ever want to construct an issuerAndSerialNumber from a hex dump of a cert just to fetch it from a directory. In fact users aren't meant to use the interface at this level at all. This interface really isn't meant for use by humans, it's a universal interface to a cert store which happens to use HTTP to achieve universality. >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. Web-to-LDAP interface issues are already covered in various RFCs, I didn't want to wander into other people's territory. It's also a pretty LDAP-specific mechanism, you can't just grab a binary string from a cert, hash it, and do a lookup, you have to follow fairly complex LDAP name-representation rules. I'd rather leave this to other RFCs which seem to cover it adequately. >My suggestion would be to run certificate stores holding e-mail certs >associated to e-mail domains. That's pretty much how it's meant to work. If I know your email address is @hotmail.com, I'd go to certificates.hotmail.com and ask for your cert. If you work for a certain government agency, I'd ask at ...agencysite.gov. That's also why the draft specifically mentions support for redirects, if you're outsourcing the cert-storage task you can point to where the certs really are (at worst you need to add a single static page pointing to the real server) - did I mention in a previous message that there's a bit of practical experience in using this? :-). It's not perfect, but it's good enough, and pretty transparent. (I've added another paragraph to the rationale to cover this). >I cannot really comment on UPNP and determining net_loc but is net_loc really >solely an IP address or a DNS name as you described or a host:port location? It's an IP address or DNS name. Port is always 80. Peter. From owner-ietf-pkix Tue Jan 8 23:04:40 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0974eb06645 for ietf-pkix-bks; Tue, 8 Jan 2002 23:04:40 -0800 (PST) Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0974c306635 for ; Tue, 8 Jan 2002 23:04:39 -0800 (PST) Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 15:04:42 +0800 Message-ID: From: Jason Yeung To: "'pgut001@cs.auckland.ac.nz'" , ietf-pkix@imc.org, smustard@datum.com Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard Date: Wed, 9 Jan 2002 15:04:40 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I have tried it successfully, port 318 thru tcp socket. Rgds, Jason -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Wednesday, January 09, 2002 11:55 AM To: ietf-pkix@imc.org; smustard@datum.com Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard Scott Mustard writes: >Datum's StampServer is available for test at 64.241.183.87, Which port, and which protocol? Peter. From owner-ietf-pkix Wed Jan 9 03:48:06 2002 Received: by above.proper.com (8.11.6/8.11.3) id g09Bm6t11445 for ietf-pkix-bks; Wed, 9 Jan 2002 03:48:06 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Bm4311441 for ; Wed, 9 Jan 2002 03:48:05 -0800 (PST) Received: from fwd10.sul.t-online.de by mailout01.sul.t-online.de with smtp id 16OHDA-0002x1-07; Wed, 09 Jan 2002 12:48:04 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.24.28]) by fmrl10.sul.t-online.com with esmtp id 16OHD1-2HC3xwC; Wed, 9 Jan 2002 12:47:55 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B803A157D03 for ; Wed, 9 Jan 2002 12:47:48 +0100 (CET) Message-ID: <3C3C2DE4.558BFFE@stroeder.com> Date: Wed, 09 Jan 2002 12:47:48 +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: URL schemes in draft-ietf-pkix-new-part1-11 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: HI! draft-ietf-pkix-new-part1-11 references RFC 1778 for ldap URL scheme which is LDAPv2. It was decided that LDAPv2 RFCs are shifted to historic soon => RFC 2255 should be referenced for LDAP URLs instead. Ciao, Michael. From owner-ietf-pkix Wed Jan 9 04:45:05 2002 Received: by above.proper.com (8.11.6/8.11.3) id g09Cj5x13158 for ietf-pkix-bks; Wed, 9 Jan 2002 04:45:05 -0800 (PST) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Cj3313154 for ; Wed, 9 Jan 2002 04:45:03 -0800 (PST) Received: from fwd05.sul.t-online.de by mailout10.sul.t-online.de with smtp id 16OI6J-0003In-05; Wed, 09 Jan 2002 13:45:03 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.21.165]) by fmrl05.sul.t-online.com with esmtp id 16OI6F-1YpxqKC; Wed, 9 Jan 2002 13:44:59 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 8B2C1157D03 for ; Wed, 9 Jan 2002 13:41:52 +0100 (CET) Message-ID: <3C3C3A8F.85CE8113@stroeder.com> Date: Wed, 09 Jan 2002 13:41:51 +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: URL schemes in draft-ietf-pkix-new-part1-11 References: <3C3C2DE4.558BFFE@stroeder.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Sender: 520010731148-0001@t-dialin.net Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Michael Ströder wrote: > > draft-ietf-pkix-new-part1-11 references RFC 1778 for ldap URL scheme > which is LDAPv2. It was decided that LDAPv2 RFCs are shifted to > historic soon => RFC 2255 should be referenced for LDAP URLs > instead. Additionally RFC 1738 (describing URL schemes ftp and http) was updated by RFC1808, RFC2368, RFC2396. Ciao, Michael. From owner-ietf-pkix Wed Jan 9 04:59:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09CxDY13484 for ietf-pkix-bks; Wed, 9 Jan 2002 04:59:13 -0800 (PST) Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09CxB313480 for ; Wed, 9 Jan 2002 04:59:11 -0800 (PST) Received: from zolera.com (pool-141-154-58-48.bos.east.verizon.net [141.154.58.48]) by zolera.com (8.11.6/8.11.6) with ESMTP id g09CwHK25040; Wed, 9 Jan 2002 07:58:22 -0500 Message-ID: <3C3C3EA6.82C14F71@zolera.com> Date: Wed, 09 Jan 2002 07:59:18 -0500 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Gutmann CC: ietf-pkix@imc.org, pchivers@protek.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201090420.RAA147993@ruru.cs.auckland.ac.nz> 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: > >This may be off-topic but have you considered a SOAP version of this protocol. Check out XKMS, a W3C Note and new standards Activity. It addresses similar problems (and then some), in a purely XML environment. Better to use XKMS than to let the XML nose under the PKIX tent. :) /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com From owner-ietf-pkix Wed Jan 9 08:03:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09G3mN20572 for ietf-pkix-bks; Wed, 9 Jan 2002 08:03:48 -0800 (PST) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09G3k320568 for ; Wed, 9 Jan 2002 08:03:47 -0800 (PST) Received: from fwd10.sul.t-online.de by mailout04.sul.t-online.de with smtp id 16OLCY-0006mD-08; Wed, 09 Jan 2002 17:03:42 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.165.97]) by fmrl10.sul.t-online.com with esmtp id 16OLCQ-1KkLSqC; Wed, 9 Jan 2002 17:03:34 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 3687D157D03; Wed, 9 Jan 2002 16:58:26 +0100 (CET) Message-ID: <3C3C68A1.B36897F3@stroeder.com> Date: Wed, 09 Jan 2002 16:58:25 +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: Peter Gutmann Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201090459.RAA148615@ruru.cs.auckland.ac.nz> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Sender: 520010731148-0001@t-dialin.net Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Peter Gutmann wrote: > > Michael Ströder writes: > > >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). > > The human-usable forms are all text-only. I doubt a user will ever want to > construct an issuerAndSerialNumber from a hex dump of a cert just to fetch it > from a directory. Agreed. > In fact users aren't meant to use the interface at this > level at all. This interface really isn't meant for use by humans, it's a > universal interface to a cert store which happens to use HTTP to achieve > universality. I already understood that you don't have usage by end-users through web forms in mind. But the specification is pretty close to enable it. So why prevent us from querying the cert store with a simple web form for searching certificates associated to an e-mail address? > >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. > > [..] It's also a pretty LDAP-specific > mechanism, you can't just grab a binary string from a cert, hash it, and do a > lookup, you have to follow fairly complex LDAP name-representation rules. I'd > rather leave this to other RFCs which seem to cover it adequately. We had this discussion about RFC2253 string representation here. It was not LDAP-specific at all. AFAIR it was triggered by XML-DSIG specs. Remember? E.g. OpenSSL already implements getting a RFC2253-compliant representation of subject and issued DNs. Properly implementing the DN string matching is a matter of the cert store's implementation not your specification. I know that you personally don't like LDAP. But this shouldn't hold you back from relying on usable parts of the LDAP standard. > >My suggestion would be to run certificate stores holding e-mail certs > >associated to e-mail domains. > > That's pretty much how it's meant to work. If I know your email address is > @hotmail.com, I'd go to certificates.hotmail.com and ask for your cert. Ok, understood. You should specify the term "service provider" a little bit more in detail. > That's > also why the draft specifically mentions support for redirects, if you're > outsourcing the cert-storage task you can point to where the certs really are Well, I don't object against HTTP redirects but IMHO setting DNS CNAME RRs are a more practical and efficient solution for out-sourced installations. > did I mention in a previous message that there's a bit of practical experience > in using this? :-). I know. That's why I'm reading and commenting the draft. Did I mention that I have also some practical experience using those kind of things? ;-) > It's not perfect, but it's good enough, and pretty transparent. I don't impose that such a thing has to be "perfect" since I don't know what "perfect" might be. Unfortunately you did not comment on my inquiry to run such a service with URL scheme https and port number!=80. From my practical experience it's sometimes crucial to be flexible in this regard. Ciao, Michael. From owner-ietf-pkix Wed Jan 9 08:03:39 2002 Received: by above.proper.com (8.11.6/8.11.3) id g09G3dj20564 for ietf-pkix-bks; Wed, 9 Jan 2002 08:03:39 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09G3c320560 for ; Wed, 9 Jan 2002 08:03:38 -0800 (PST) Received: from fwd05.sul.t-online.de by mailout01.sul.t-online.de with smtp id 16OLCV-0007T8-00; Wed, 09 Jan 2002 17:03:39 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.165.97]) by fmrl05.sul.t-online.com with esmtp id 16OLCS-0guB84C; Wed, 9 Jan 2002 17:03:36 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 3735F157D04; Wed, 9 Jan 2002 17:05:11 +0100 (CET) Message-ID: <3C3C6A36.F0695AA2@stroeder.com> Date: Wed, 09 Jan 2002 17:05:10 +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: Peter Gutmann Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201090508.SAA148750@ruru.cs.auckland.ac.nz> 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: Peter Gutmann wrote: > > Michael StrM-vder writes: > > >While I understand the rationale in section 3.4 that AIA and CRLDP extensions > >are different in semantics I think the CRL could be retrieved via > >CRLDistributionPoint as long as the HTTP certificate store interface behaves > >as expected for CRLDistributionPoint. > > But it doesn't behave that way. As the rationale points out, CRLDP points at a > static CRL while the draft uses a general CRL query mechanism. To put it > another way, let's say you get a cert with a CRLDP containing a URI: > > foo.bar.com/qwertyuiop > > What are you supposed to do with this? If you follow CRLDP semantics, you go > to foo.bar.com and do a GET /qwertyuiop HTTP/1.0. If you follow the draft > semantics you go to foo.bar.com and do a GET /qwertyuiop/search-cgi?iHash= > HTTP/1.0 (or whatever key you're using). Unless you completely > redefine the semantics of CRLDP to constrain it to follow the functionality in > the draft, you can't do this. I still can't see the difference. Even (outdated) RFC 1738 referenced in RFC 2459 allows a query string being part of an URI. While glancing over RFC 2459 and draft-ietf-pkix-new-part1-11 I could not find a hint which prevents me from using a query string in CRLDistributionPoint.distributionPoint.fullName. Therefore I can use GET /qwertyuiop/search-cgi?iHash= with being a constant uniquely identifying the CRL. BTW: The "static" URI form foo.bar.com/qwertyuiop doesn't mean that the web server serves a static file. Could be also a web application acting different for path info /qwertyuiop and /poiuytrewq. Ciao, Michael. From owner-ietf-pkix Wed Jan 9 14:40:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09MeGv02079 for ietf-pkix-bks; Wed, 9 Jan 2002 14:40:16 -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 g09MeF302075 for ; Wed, 9 Jan 2002 14:40:15 -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 RAA18494; Wed, 9 Jan 2002 17:40:14 -0500 (EST) Message-Id: <200201092240.RAA18494@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-ipki-new-rfc2527-01.txt Date: Wed, 09 Jan 2002 17:40:13 -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 Certificate Policy and Certification Practices Framework Author(s) : S. Chokhani et al. Filename : draft-ietf-pkix-ipki-new-rfc2527-01.txt Pages : 55 Date : 08-Jan-02 This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document is being submitted to the RFC Editor with a request for publication as an Informational RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-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-ipki-new-rfc2527-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-ipki-new-rfc2527-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: <20020108151007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki-new-rfc2527-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108151007.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Thu Jan 10 04:56:41 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0ACufH17623 for ietf-pkix-bks; Thu, 10 Jan 2002 04:56:41 -0800 (PST) Received: from svart.tajt.se (svart.tajt.se [195.178.183.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ACub317619 for ; Thu, 10 Jan 2002 04:56:39 -0800 (PST) Received: from svart.tajt.se. (svart.tajt.se [195.178.183.135]) by svart.tajt.se (8.11.2/8.11.2) with ESMTP id g0ACuKO13383 for ; Thu, 10 Jan 2002 13:56:20 +0100 Message-Id: <200201101256.g0ACuKO13383@svart.tajt.se> Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt MIME-Version: 1.0 From: Tomas Gustavsson To: ietf-pkix@imc.org User-Agent: CAMAS/1.0.6-STABLE1 (CAudium Mail Access System) In-Reply-To: <3C3C68A1.B36897F3@stroeder.com> Content-Transfer-Encoding: 8bit Date: Fri, 10 Jan 2002 13:56:19 +0100 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: How much space is saved by only using 128 bits from the SHA1 hash? I expect many databases already contain certificates indexed by a full SHA1 hash, and only using the first 128 bits requires an almost duplicate field (alt. using SQL 'like' things). Is the added chance of collision insignificant when truncating the hash? Regards, Tomas From owner-ietf-pkix Thu Jan 10 07:57:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0AFvhF23809 for ietf-pkix-bks; Thu, 10 Jan 2002 07:57:43 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AFvg323805 for ; Thu, 10 Jan 2002 07:57:42 -0800 (PST) Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06663; Thu, 10 Jan 2002 08:57:04 -0700 (MST) Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id PAA12476; Thu, 10 Jan 2002 15:57:21 GMT Message-ID: <3C3DB9E0.6020104@sun.com> Date: Thu, 10 Jan 2002 15:57:20 +0000 From: Andreas Sterbenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-pkix@imc.org CC: pgut001@cs.auckland.ac.nz Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201071408.JAA14678@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Peter, some comments, partially overlapping with other people's feedback. . the draft only deals with HTTP, HTTPS may also be useful in some cases and should be permitted. . "Arbitrary-length binary values are converted into a search key by the process described in section 2.1." This seems a bit to vague, please clarify. In particular, the certHash is not an arbitrary length binary value, does that imply the full 160 bits are used or is it still truncated to 128? . you might want to explicitly state that both the attribute name and value are case sensitive . the value description says "as it appears in the certificate" even if it could also refer to a CRL. . "If more than one certificate matches a query, it MUST be returned as a multipart response." I assume you mean multipart/mixed? I would definitely prefer a SEQUENCE of certificates. . Server response in case no certificate/ CRL matches a query is undefined. . Server error behavior is undefined (invalid request, database temporarily unavailable, etc.) . key truncation to 128 bit: if we want to truncate search keys to save space, we might as well truncate them to 80 or 96 bits. . I believe the draft should be explicit wrt to attribute certs, even if it is only saying that they are not covered by the specification. . is a client required to implement full HTTP/1.1 and MIME, i.e. is the server allowed to send responses that make use of all the funky features? . the security considerations mention the Cache-Control header, but the main document does not say if client and servers MUST/ SHOULD/ MAY send that header. . security consideration should state that the server should be considered untrusted, e.g. don't use the certificate returned for a email=pgut001@cs.auckland.ac.nz query to send S/MIME encrypted mail without verifiying the contents of the certificate. . some examples with full requests and responses may be helpful. . server behavior in case of more complex queries should be defined (ignore what you don't understand) to allow evolution of the protocol. Andreas. From owner-ietf-pkix Thu Jan 10 10:17:45 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0AIHjc27403 for ietf-pkix-bks; Thu, 10 Jan 2002 10:17:45 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AIHi327398 for ; Thu, 10 Jan 2002 10:17:44 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 10 Jan 2002 10:17:40 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 10 Jan 2002 10:17:40 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 10:17:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 10:17:39 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 10 Jan 2002 10:15:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Name constraints Date: Thu, 10 Jan 2002 10:15:40 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD02F95601@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Name constraints thread-index: AcGJfbKx5JbOW5ExRTO4dmtLMV91swQhLmSQ From: "Trevor Freeman" To: , "Housley, Russ" Cc: X-OriginalArrivalTime: 10 Jan 2002 18:15:40.0792 (UTC) FILETIME=[CFAD0780:01C19A02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0AIHi327399 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: IE uses the OS for certificate validation. The first MS OS to support Name Constraints is Window XP. If you repeat the test using IE 6 on XP, you will get different results to IE6 on down-level MS OS's. FYI, Windows XP also fully implements Certificate policy, policy constraints and policy mapping. Trevor -----Original Message----- From: Michael Helm [mailto:helm@fionn.es.net] Sent: Thursday, December 20, 2001 9:36 AM To: Housley, Russ Cc: ietf-pkix@imc.org Subject: Re: Name constraints "Housley, Russ" writes: > Part of the slow implementation may be related to the fact that CAs > are not > required to support name constraints. I think that this is appropriate Curiously, the ca software I was using for this test is from one of those browser implementors. Support decisions are probably done on completely different bases! > Son-of-2459 continues to include name constraints. It says: > > At a minimum, applications conforming to this profile MUST recognize > 4.2.1.7), basic constraints (section 4.2.1.10), name constraints > (section 4.2.1.11), policy constraints (section 4.2.1.12), > extended It does seem to be safe to say that at least some of the browser revs can't meet this profile spec. From owner-ietf-pkix Thu Jan 10 10:47:55 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0AIltX28175 for ietf-pkix-bks; Thu, 10 Jan 2002 10:47:55 -0800 (PST) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AIlq328169 for ; Thu, 10 Jan 2002 10:47:52 -0800 (PST) Received: from fwd11.sul.t-online.de by mailout11.sul.t-online.de with smtp id 16OkEp-00035o-03; Thu, 10 Jan 2002 19:47:43 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.168.14]) by fmrl11.sul.t-online.com with esmtp id 16OkEb-20evdgC; Thu, 10 Jan 2002 19:47:29 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 88C0E157117; Thu, 10 Jan 2002 19:47:16 +0100 (CET) Message-ID: <3C3DE1B4.C52387EE@stroeder.com> Date: Thu, 10 Jan 2002 19:47:16 +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: Andreas Sterbenz Cc: ietf-pkix@imc.org, pgut001@cs.auckland.ac.nz Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201071408.JAA14678@ietf.org> <3C3DB9E0.6020104@sun.com> 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: Andreas Sterbenz wrote: > > . "Arbitrary-length binary values are converted into a search key by > the process described in section 2.1." This seems a bit to vague, please > clarify. In particular, the certHash is not an arbitrary length binary > value, does that imply the full 160 bits are used or is it still > truncated to 128? I also agree that all sort of hashes should be taken as-is because they are most times already calculated before the HTTP cert store is queried. > . Server response in case no certificate/ CRL matches a query is > undefined. > > . Server error behavior is undefined (invalid request, database > temporarily unavailable, etc.) I'd suggest to explore the possibility to just use HTTP response error code as defined RFC2616, section 6.1.1. Otherwise a message format for queries and response would have to be defined. Ciao, Michael. From owner-ietf-pkix Thu Jan 10 19:38:20 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B3cKH11518 for ietf-pkix-bks; Thu, 10 Jan 2002 19:38:20 -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 g0B3cI311514 for ; Thu, 10 Jan 2002 19:38:19 -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 QAA24173; Fri, 11 Jan 2002 16:38: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 QAA202214; Fri, 11 Jan 2002 16:38:02 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 11 Jan 2002 16:38:02 +1300 (NZDT) Message-ID: <200201110338.QAA202214@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, tomasg@tajt.se Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Tomas Gustavsson writes: >How much space is saved by only using 128 bits from the SHA1 hash? The short answer is: It's quite significant (even 128 bits is far larger than is optimal, but I figured that was the lower bound of what I could get away with. 64 bits would be better). The space saving on disk is irrelevant, what's significant is the space in indices. The less keys you can fit per page, the more pages the index consumes, and the worse performance gets. That's still not the full answer, for that I'd recommend any book on database design, or the paper I reference in the draft which looks at this in some detail. >Is the added chance of collision insignificant when truncating the hash? Yes. I doubt there are more than about 2^20 certs in the whole world, let alone 2^64. Peter. From owner-ietf-pkix Thu Jan 10 21:33:37 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B5Xbm13038 for ietf-pkix-bks; Thu, 10 Jan 2002 21:33:37 -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 g0B5XZ313034 for ; Thu, 10 Jan 2002 21:33:36 -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 SAA26158; Fri, 11 Jan 2002 18:33:25 +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 SAA204689; Fri, 11 Jan 2002 18:33:24 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 11 Jan 2002 18:33:24 +1300 (NZDT) Message-ID: <200201110533.SAA204689@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: michael@stroeder.com, pgut001@cs.auckland.ac.nz Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This has since been sorted out in private mail, Michael has suggested a whole range of useful things which you can do with pre-constructed URIs which I've added to the draft: Note that a single server can handle both CRLDP and AIA/SIA queries provided the CRLDP form uses an HTTP URI. Since CRLDP points to a single static location for a CRL, a query can be pre-constructed and stored in the CRLDP extension. Software which uses the CRLDP will retrieve the single CRL which applies to the certificate from the server, and software which uses the AIA/SIA can retrieve any CRL from the server. Similar pre-constructed URIs may also be useful in other circumstances, for example for links on web pages, to place in appropriate locations like the issuerAltName, or even for tech support staff to email to users who can't find the certificate themselves. Peter. From owner-ietf-pkix Thu Jan 10 21:20:11 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B5KB412813 for ietf-pkix-bks; Thu, 10 Jan 2002 21:20:11 -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 g0B5K8312809 for ; Thu, 10 Jan 2002 21:20:08 -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 SAA26412; Fri, 11 Jan 2002 18:20:05 +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 SAA204211; Fri, 11 Jan 2002 18:20:05 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 11 Jan 2002 18:20:05 +1300 (NZDT) Message-ID: <200201110520.SAA204211@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Andreas.Sterbenz@sun.com, ietf-pkix@imc.org 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: Some of these have already been fixed as a result of other feedback or are straightforward changes which I've applied, I'll coment on what's left... > . the draft only deals with HTTP, HTTPS may also be useful in some cases and >should be permitted. I meant "HTTP" as a generic "HTTP or HTTPS", but I've made it more explicit in the text. >. you might want to explicitly state that both the attribute name and value >are case sensitive The attribute name isn't case sensitive (unless someone can present a strong reason for this), but the value is, I've commented on this in the text. >. the value description says "as it appears in the certificate" even if it >could also refer to a CRL. Fixed. >. "If more than one certificate matches a query, it MUST be returned as a >multipart response." I assume you mean multipart/mixed? I would definitely >prefer a SEQUENCE of certificates. Does anyone else have any thoughts on this? The comments in the draft on SEQUENCE OF are: This has the advantage that it takes a lot less code to parse, OTOH it may be harder to produce if what you're using is a web-enabled database, which is what most of them are. >. Server response in case no certificate/ CRL matches a query is undefined. > >. Server error behavior is undefined (invalid request, database temporarily >unavailable, etc.) > > . server behavior in case of more complex queries should be defined (ignore >what you don't understand) to allow evolution of the protocol. This is standard HTTP stuff: Responses to unsuccessful queries (for example to indicate a non-match or an error conditions) are handled in the standard manner as per [RFC2068]. Clients should in particular be aware that in some instances servers may return HTTP type 3xx redirection requests to redirect queries to another server. Clients receiving this response SHOULD use the returned URI to replace their existing one and resubmit the query to the new server. >. key truncation to 128 bit: if we want to truncate search keys to save space, >we might as well truncate them to 80 or 96 bits. See my other reply on this. I felt that 128 bits is the least I could get away with without someone somewhere complaining. The smaller the key, the more efficient the B-tree indices become, so smaller would definitely be better. I've added text to say that: Although clients MUST submit a fixed 128-bit value, servers are free to utilise as many bits of this value as they require, for example a server may choose to use only the first 40 or 64 or 80 bits for efficiency in searching and maintaining indices. That should keep everyone happy. >. I believe the draft should be explicit wrt to attribute certs, even if it is >only saying that they are not covered by the specification. All it really needs is another AIA... is there any demand for an attribute- cert-specific AIA? If not, I think the boilerplate IANA considerations will cover it. >. is a client required to implement full HTTP/1.1 and MIME, i.e. is the server >allowed to send responses that make use of all the funky features? I'd prefer to avoid profiling HTTP with anything more than a reference to RFC 2068... it's really up to clients as to how much they want to implement beyond handling "worked"/"didn't work" responses. >. the security considerations mention the Cache-Control header, but the main >document does not say if client and servers MUST/ SHOULD/ MAY send that >header. I'd consider it up to the client, the reason I added it in the security considerations is to let people know the issue exists. It doesn't affect interoperability, and I don't know if a MAY would add much. >. security consideration should state that the server should be considered >untrusted, e.g. don't use the certificate returned for a email= >pgut001@cs.auckland.ac.nz query to send S/MIME encrypted mail without >verifiying the contents of the certificate. Again, I consider that to be a client issue. It's the same as any cert you get via any mechanism, you can choose to trust it or not. Peter. From owner-ietf-pkix Fri Jan 11 00:51:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B8phF29977 for ietf-pkix-bks; Fri, 11 Jan 2002 00:51:43 -0800 (PST) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0B8pg329973 for ; Fri, 11 Jan 2002 00:51:42 -0800 (PST) Received: from fwd03.sul.t-online.de by mailout07.sul.t-online.de with smtp id 16OxPU-0005si-01; Fri, 11 Jan 2002 09:51:36 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.170.12]) by fmrl03.sul.t-online.com with esmtp id 16OxPR-0y2R3gC; Fri, 11 Jan 2002 09:51:33 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B0882157117; Fri, 11 Jan 2002 09:51:31 +0100 (CET) Message-ID: <3C3EA792.68180F97@stroeder.com> Date: Fri, 11 Jan 2002 09:51:30 +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: Peter Gutmann Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201110338.QAA202214@ruru.cs.auckland.ac.nz> 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: Peter Gutmann wrote: > > Tomas Gustavsson writes: > > >How much space is saved by only using 128 bits from the SHA1 hash? > > The short answer is: It's quite significant (even 128 bits is far larger than > is optimal, but I figured that was the lower bound of what I could get away > with. 64 bits would be better). The space saving on disk is irrelevant, > what's significant is the space in indices. The less keys you can fit per > page, the more pages the index consumes, and the worse performance gets. > That's still not the full answer, for that I'd recommend any book on database > design, or the paper I reference in the draft which looks at this in some > detail. Hmm, I think the cert store implementation itself should deal with these kind of index optimization issues. I vote for just submitting search values as is and let the certificate store backend do the bit reducing at the server-side if necessary at all. That makes client implementations simpler and leaves up decisions about how to deal with possible collisions to the server-side cert store implementation. Peter, as I understand your draft it's only an interface definition. There shouldn't be e.g. database-specific limits in this draft because they are dependent on the DB backend used by an implementation. Only limitations imposed by the protocols used for the interface (HTTP in this case) should be considered. BTW: I'm not an DB expert but IMHO index generation with hashes of appropriate size and collision handling is made internally by DB servers anyway. > >Is the added chance of collision insignificant when truncating the hash? > > Yes. I doubt there are more than about 2^20 certs in the whole world, let > alone 2^64. You know this famous sentence about "640kByte on DOS systems is enough"... ;-) Ciao, Michael. From owner-ietf-pkix Fri Jan 11 04:30:45 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BCUj820029 for ietf-pkix-bks; Fri, 11 Jan 2002 04:30:45 -0800 (PST) Received: from svart.tajt.se (svart.tajt.se [195.178.183.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BCUg320025 for ; Fri, 11 Jan 2002 04:30:42 -0800 (PST) Received: from svart.tajt.se. (svart.tajt.se [195.178.183.135]) by svart.tajt.se (8.11.2/8.11.2) with ESMTP id g0BCUaK01624 for ; Fri, 11 Jan 2002 13:30:36 +0100 Message-Id: <200201111230.g0BCUaK01624@svart.tajt.se> In-Reply-To: <3C3EA792.68180F97@stroeder.com> Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt MIME-Version: 1.0 User-Agent: CAMAS/1.0.6-STABLE1 (CAudium Mail Access System) From: Tomas Gustavsson To: ietf-pkix@imc.org Content-Transfer-Encoding: 8bit Date: Sat, 11 Jan 2002 13:30:36 +0100 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > Hmm, I think the cert store implementation itself should deal with > these kind of index optimization issues. I vote for just submitting > search values as is and let the certificate store backend do the bit > reducing at the server-side if necessary at all. That makes client > implementations simpler and leaves up decisions about how to deal > with possible collisions to the server-side cert store > implementation. I would agree with this. It simplifies things to use 'real' values and let the backend/middleware do the optimization. From owner-ietf-pkix Fri Jan 11 05:29:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDTx022253 for ietf-pkix-bks; Fri, 11 Jan 2002 05:29:59 -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 g0BDTv322249 for ; Fri, 11 Jan 2002 05:29:58 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 13:29:35 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 IAA01969 for ; Fri, 11 Jan 2002 08:29:52 -0500 (EST) Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BDTp416936 for ; Fri, 11 Jan 2002 08:29:51 -0500 (EST) Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 13:29:59 -0000 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHY7G5; Fri, 11 Jan 2002 08:29:43 -0500 Message-Id: <5.0.1.4.2.20020110145333.025521c0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 10 Jan 2002 15:10:21 -0500 To: ietf-pkix@imc.org From: "Housley, Russ" Subject: Cautionary Period 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: The updated Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) Protocol Requirements document was recently posted. You may notice that I am a co-author with Denis on this document. Denis invited me to be a co-author because I submitted many comments. There were many, many editorial ones. There were also technical ones. Denis and I were able to resolve the vast bulk of the technical issues; however, we have not been able to reach a compromise on one open issue. That issue is the subject of this note. I encourage everyone to read DPV and DPD requirements document, and post their view on this subject. I believe that the document expresses Denis' view on the issue. My view is that cautionary period is a not a requirement for DPV or DPD. However, cautionary periods might be used as part of an application-specific risk mitigation mechanism when trying to determine the validity of a particular signature. For example, waiting for cautionary period before considering a signature to be valid on a high-value electronic contract may be prudent. Therefore, cautionary periods might be supported in DSV (delegated signature validation). Since Denis and I were unable to resolve this issue in an author-to-author dialogue, I am bring this issue to the whole mail list. As far as I know, this is the only open issue with the DPV and DPD Protocol Requirements document. I hope that this issue can be quickly resolved so that we can get on with the protocol development. Russ From owner-ietf-pkix Fri Jan 11 05:10:01 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDA1I21083 for ietf-pkix-bks; Fri, 11 Jan 2002 05:10:01 -0800 (PST) Received: from mail.motus.qc.ca (mail.motus.qc.ca [207.236.155.221]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BD9w321070 for ; Fri, 11 Jan 2002 05:09:59 -0800 (PST) Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_I-D_ACTION=3Adraft-ietf-pkix-certstore?= =?us-ascii?Q?-http?= =?us-ascii?Q?-01?= =?us-ascii?Q?=2E?= =?us-ascii?Q?txt?= To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: spouliot@motus.com Date: Fri, 11 Jan 2002 08:10:48 -0500 X-MIMETrack: Serialize by Router on motus1/Motus Technologies Inc.(Release 5.0.8 |June 18, 2001) at 2002-01-11 08:11:01 MIME-Version: 1.0 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 g0BD9x321072 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: >. key truncation to 128 bit: if we want to truncate search keys to save space, >we might as well truncate them to 80 or 96 bits. See my other reply on this. I felt that 128 bits is the least I could get away with without someone somewhere complaining. The smaller the key, the more efficient the B-tree indices become, so smaller would definitely be better. I've added text to say that: Although clients MUST submit a fixed 128-bit value, servers are free to utilise as many bits of this value as they require, for example a server may choose to use only the first 40 or 64 or 80 bits for efficiency in searching and maintaining indices. That should keep everyone happy. In this case why not send the whole 160 bits hash in the client query and let the server use some part of it (64, 80, 96, 128 or 160 bits) ? This would simplify both the client (albeit not much) and the current specification (which, from my implementer point of view, are both good things). Then the specification could include an "implementation comment" saying that "servers MAY use only part of hash supplied by the client query to retrieve a certificate or CRL". -------------------------------------------------------------- Sébastien Pouliot Architecte Sécurité / Security Architect Motus Technologies tel: 418 521 2100 ext 307 courriel / email: spouliot@motus.com pgut001@cs.aucklan d.ac.nz (Peter Pour : Andreas.Sterbenz@sun.com, ietf-pkix@imc.org Gutmann) cc : pgut001@cs.auckland.ac.nz Envoyé par : Objet : Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt owner-ietf-pkix@ma il.imc.org 11/01/02 13:20 Some of these have already been fixed as a result of other feedback or are straightforward changes which I've applied, I'll coment on what's left... > . the draft only deals with HTTP, HTTPS may also be useful in some cases and >should be permitted. I meant "HTTP" as a generic "HTTP or HTTPS", but I've made it more explicit in the text. >. you might want to explicitly state that both the attribute name and value >are case sensitive The attribute name isn't case sensitive (unless someone can present a strong reason for this), but the value is, I've commented on this in the text. >. the value description says "as it appears in the certificate" even if it >could also refer to a CRL. Fixed. >. "If more than one certificate matches a query, it MUST be returned as a >multipart response." I assume you mean multipart/mixed? I would definitely >prefer a SEQUENCE of certificates. Does anyone else have any thoughts on this? The comments in the draft on SEQUENCE OF are: This has the advantage that it takes a lot less code to parse, OTOH it may be harder to produce if what you're using is a web-enabled database, which is what most of them are. >. Server response in case no certificate/ CRL matches a query is undefined. > >. Server error behavior is undefined (invalid request, database temporarily >unavailable, etc.) > > . server behavior in case of more complex queries should be defined (ignore >what you don't understand) to allow evolution of the protocol. This is standard HTTP stuff: Responses to unsuccessful queries (for example to indicate a non-match or an error conditions) are handled in the standard manner as per [RFC2068]. Clients should in particular be aware that in some instances servers may return HTTP type 3xx redirection requests to redirect queries to another server. Clients receiving this response SHOULD use the returned URI to replace their existing one and resubmit the query to the new server. >. key truncation to 128 bit: if we want to truncate search keys to save space, >we might as well truncate them to 80 or 96 bits. See my other reply on this. I felt that 128 bits is the least I could get away with without someone somewhere complaining. The smaller the key, the more efficient the B-tree indices become, so smaller would definitely be better. I've added text to say that: Although clients MUST submit a fixed 128-bit value, servers are free to utilise as many bits of this value as they require, for example a server may choose to use only the first 40 or 64 or 80 bits for efficiency in searching and maintaining indices. That should keep everyone happy. >. I believe the draft should be explicit wrt to attribute certs, even if it is >only saying that they are not covered by the specification. All it really needs is another AIA... is there any demand for an attribute- cert-specific AIA? If not, I think the boilerplate IANA considerations will cover it. >. is a client required to implement full HTTP/1.1 and MIME, i.e. is the server >allowed to send responses that make use of all the funky features? I'd prefer to avoid profiling HTTP with anything more than a reference to RFC 2068... it's really up to clients as to how much they want to implement beyond handling "worked"/"didn't work" responses. >. the security considerations mention the Cache-Control header, but the main >document does not say if client and servers MUST/ SHOULD/ MAY send that >header. I'd consider it up to the client, the reason I added it in the security considerations is to let people know the issue exists. It doesn't affect interoperability, and I don't know if a MAY would add much. >. security consideration should state that the server should be considered >untrusted, e.g. don't use the certificate returned for a email= >pgut001@cs.auckland.ac.nz query to send S/MIME encrypted mail without >verifiying the contents of the certificate. Again, I consider that to be a client issue. It's the same as any cert you get via any mechanism, you can choose to trust it or not. Peter. From owner-ietf-pkix Fri Jan 11 05:56:57 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BDuvK24112 for ietf-pkix-bks; Fri, 11 Jan 2002 05:56:57 -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 g0BDuu324108 for ; Fri, 11 Jan 2002 05:56:56 -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 IAA14856; Fri, 11 Jan 2002 08:56:54 -0500 (EST) Message-Id: <200201111356.IAA14856@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-dpv-dpd-req-01.txt Date: Fri, 11 Jan 2002 08:56:54 -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 : Delegated Path Validation and Delegated Path Discovery Protocol Requirements (DPV&DPD-REQ) Author(s) : D. Pinkas Filename : draft-ietf-pkix-dpv-dpd-req-01.txt Pages : 14 Date : 10-Jan-02 This document specifies requirements for two main request/response pairs. The first one, called Delegated Path Validation (DPV), can be used to fully delegate a path validation processing to an DPV server, according to a set of rules, called a validation policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-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-dpv-dpd-req-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-dpv-dpd-req-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: <20020110150711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-dpv-dpd-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020110150711.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Jan 11 07:08:12 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BF8Cs26373 for ietf-pkix-bks; Fri, 11 Jan 2002 07:08:12 -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 g0BF8A326369 for ; Fri, 11 Jan 2002 07:08:11 -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 QAA59715; Fri, 11 Jan 2002 16:08:07 +0100 (CET) (envelope-from adg@foobar.andxor.it) Received: by foobar.andxor.it (Postfix, from userid 1000) id F11DCF92C; Fri, 11 Jan 2002 18:06:26 +0100 (CET) Date: Fri, 11 Jan 2002 18:06:26 +0100 From: Alfonso De Gregorio To: Denis.Pinkas@bull.net, "Housley, Russ" Cc: ietf-pkix@imc.org Subject: Re: Cautionary Period Message-ID: <20020111180626.A15675@foobar.andxor.it> Reply-To: Alfonso De Gregorio References: <20020111152114.A32635@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: <20020111152114.A32635@server.speedcom.it>; from agregorio@acm.org on Fri, Jan 11, 2002 at 03:21:14PM +0100 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Hi Russ, hi Denis, hi Everyone, > I encourage everyone to read DPV and DPD requirements document, and post > their view on this subject. I believe that the document expresses Denis' > view on the issue. My view is that cautionary period is a not a > requirement for DPV or DPD. However, cautionary periods might be used as > part of an application-specific risk mitigation mechanism when trying to > determine the validity of a particular signature. For example, waiting for > cautionary period before considering a signature to be valid on a > high-value electronic contract may be prudent. Therefore, cautionary > periods might be supported in DSV (delegated signature validation). In order to observe the cautionary-period-delay at application level the execution environment must be current-time-aware. DPV target execution environments are assumed to be constrained, at least by a processing and/or communication point of view. Constrained execution environments, such as telephones and PDA, are not necessarily current-time-aware (or have time-sources not necessarily trusted). Delegating a path validation to a TTP allows execution environments to be unaware of the current-time. So, IMHO, cautionary periods should be a requirement for DPV. alfonso From owner-ietf-pkix Fri Jan 11 08:31:35 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGVZg29187 for ietf-pkix-bks; Fri, 11 Jan 2002 08:31:35 -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 g0BGVT329179 for ; Fri, 11 Jan 2002 08:31:29 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 16:31:07 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 LAA18616; Fri, 11 Jan 2002 11:31:30 -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 g0BGVEE05940; Fri, 11 Jan 2002 11:31:15 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 11:31:12 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.112]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHY01S; Fri, 11 Jan 2002 11:31:06 -0500 Message-ID: <5.0.1.4.2.20020111101327.02db4b48@exna07.securitydynamics.com> From: "Housley, Russ" To: pgut001@cs.auckland.ac.nz Cc: Andreas.Sterbenz@sun.com, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Date: Fri, 11 Jan 2002 10:16:25 -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: Peter Gutmann: I would prefer to maintain alignment with RFC 2585. The use of SEQUENCE OF would be fewer bit on the wire, but it would also require the specification of another MIME type for the transfer of certificates. Russ > >. "If more than one certificate matches a query, it MUST be returned as a > >multipart response." I assume you mean multipart/mixed? I would definitely > >prefer a SEQUENCE of certificates. > >Does anyone else have any thoughts on this? The comments in the draft on >SEQUENCE OF are: > > This has the advantage that it takes a lot less code to parse, OTOH it > may be > harder to produce if what you're using is a web-enabled database, which is > what most of them are. ============================================================================ ================ 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 Fri Jan 11 08:34:34 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGYYP29354 for ietf-pkix-bks; Fri, 11 Jan 2002 08:34:34 -0800 (PST) Received: from slack.lne.com (dns.lne.com [209.157.136.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BGYW329346 for ; Fri, 11 Jan 2002 08:34:33 -0800 (PST) Received: (from ericm@localhost) by slack.lne.com (8.11.0/8.11.0) id g0BGYMh00683; Fri, 11 Jan 2002 08:34:22 -0800 Date: Fri, 11 Jan 2002 08:34:22 -0800 From: Eric Murray To: Peter Gutmann Cc: Andreas.Sterbenz@sun.com, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Message-ID: <20020111083422.C32746@slack.lne.com> References: <200201110520.SAA204211@ruru.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <200201110520.SAA204211@ruru.cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Fri, Jan 11, 2002 at 06:20:05PM +1300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: On Fri, Jan 11, 2002 at 06:20:05PM +1300, Peter Gutmann wrote: > > >. "If more than one certificate matches a query, it MUST be returned as a > >multipart response." I assume you mean multipart/mixed? I would definitely > >prefer a SEQUENCE of certificates. > > Does anyone else have any thoughts on this? The comments in the draft on > SEQUENCE OF are: > > This has the advantage that it takes a lot less code to parse, OTOH it may be > harder to produce if what you're using is a web-enabled database, which is > what most of them are. I think that it's best put in a SEQUENCE, the main reason being that since we're talking X.509 certs, the recipient is guaranteed to have ASN.1 parsing capability, but might not have MIME. You should specify that it's in DER so it matches X.509. If it's a web-enabled database that's producing the list, wrapping the list of certs in a SEQUENCE is a very simple bit of code. Eric From owner-ietf-pkix Fri Jan 11 08:27:39 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGRdo29071 for ietf-pkix-bks; Fri, 11 Jan 2002 08:27:39 -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 g0BGRb329067 for ; Fri, 11 Jan 2002 08:27:37 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27238 for ; Fri, 11 Jan 2002 17:27:37 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 17:27:37 +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 RAA09237 for ; Fri, 11 Jan 2002 17:27:36 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA02423 for ietf-pkix@imc.org; Fri, 11 Jan 2002 17:27:35 +0100 (MET) Date: Fri, 11 Jan 2002 17:27:35 +0100 (MET) Message-Id: <200201111627.RAA02423@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: Re: Cautionary Period ... Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > view on the issue. My view is that cautionary period is a not a > requirement for DPV or DPD. However, cautionary periods might be used as > part of an application-specific risk mitigation mechanism when trying to > determine the validity of a particular signature. For example, waiting for > cautionary period before considering a signature to be valid on a > high-value electronic contract may be prudent. Therefore, cautionary > periods might be supported in DSV (delegated signature validation). I agree with this point of view. > > Since Denis and I were unable to resolve this issue in an author-to-author > dialogue, I am bring this issue to the whole mail list. As far as I know, > this is the only open issue with the DPV and DPD Protocol Requirements No. See later. A great deal of the list of requirements for DPV that I have send in December has not been adressed at all. I don't know whether there is consensus that what I have send does not contain necessary/optional/useful requirements at all. If so, so be it. > document. I hope that this issue can be quickly resolved so that we can > get on with the protocol development. Or 'protocols development'. Here are some editorial comments. The abstract says: "This document specifies requirements for two main request/response pairs." followed by actually five, with two of them 'optional'. what means 'optional' in this case? In fact there five different services, all of them are independant, thus optional. I don't think that 'request/response pairs' is a good wording. All occurences should be replaced by 'services' or something like that. And a sentence added like: "All services are initiated by a client sending a request to a server; the server answers by one or more responses." ( There can be more than one response to a request. Just one example would be a request to determine the validity of a very old cert which requires some offline action, thus an initial response could indicate that another answer will be send by mail or else. ) > Because validation software is controlled by many parameters which, > if incorrectly set, may result in insecure behavior, it is useful ------------ > to rely on pre-defined policies that are already known by the servers, --------------------------------------------------------------------- > where system security administrators carefully manage them. ----------------------------------------------------------- This and the next paragraph sounds ok. But: > Alternatively, system security administrators MAY also define policies. What 'alternative' ? What means 'MAY also define policies'? > However, such policy definition may be quite complex and only some > forms of policies can be defined in this way, otherwise testing all > the possible variations would lead to non-interoperable implementations > or would increase the time necessary to ensure that two implementations > are interoperable. How does "testing all the possible variations would lead to non-interoperable implementations" ? I would rather think the contrary ??? > Since policy definitions can be quite long and complex, all the > parameters SHOULD NOT be passed with each individual request; rather, 'individual DPV or DPD request' > they SHOULD be defined using a separate policy definition > request/response pair. In response to a successful policy definition > request, the server SHALL return a policy reference (e.g. an OID). Why SHOULD they be defined using another management protocol? They MAY be defined in that way. > The certificate to be validated MUST either be directly provided in certificates > The client MUST be able to provide to the validation server, associated > with each certificate to be validated, "useful certificates", as well I don't know whether my German understanding of the English language hits me here. Does the sentence mean: "The protocol MUST provide a means to a client to provide ..." > "The Delegated Path Validation (DPV) protocol allows a server to > validate one or more certificates according to a validation policy." I suggest: "The Delegated Path Validation (DPV) protocol allows a client to ask a server to validate one or more certificates and to provide a status to the client. The validation is made according to a validation policy." > The validation policy SHALL be known by the DPV server. > The validation policy MAY be defined using an additional request/ > response pair (see section 10) prior to the DPV request. In this way > clients only need to be aware of the reference of the validation > policy to be used by a given application. Could one try and avoid turning around phrases three times. 'in this way' refers to what? I propose: "The validation policy SHALL be known by the DPV server and identifed by unambiguous reference usable by the client." And maybe : "In this way clients only need to be aware of the reference of the validation policy to be used by a given application. The definition of policies and the allocation of a reference is outside the scope of DPV. Section 10 proposes a policy management protocol/service." although this seems to be a repetition of text elsewhere. From owner-ietf-pkix Fri Jan 11 08:59:12 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BGxC300230 for ietf-pkix-bks; Fri, 11 Jan 2002 08:59:12 -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 g0BGx9300226 for ; Fri, 11 Jan 2002 08:59:09 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27453; Fri, 11 Jan 2002 17:59:10 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 17:59:10 +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 RAA09479; Fri, 11 Jan 2002 17:59:09 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA02430; Fri, 11 Jan 2002 17:59:08 +0100 (MET) Date: Fri, 11 Jan 2002 17:59:08 +0100 (MET) Message-Id: <200201111659.RAA02430@emeriau.edelweb.fr> To: ietf-pkix@imc.org, rhousley@rsasecurity.com Subject: draft-ietf-pkix-dpv-dpd-req-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Another one: > If the DPV request does not specify a validation policy, the server > response MUST indicate the one that was used. In such a case, the > client must verify that the one selected by the server is appropriate. I propose: "A server response MUST indicate the validation policy that has been used, and a client MUST verify that it is acceptable." From owner-ietf-pkix Fri Jan 11 08:52:22 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BGqM529944 for ietf-pkix-bks; Fri, 11 Jan 2002 08:52:22 -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 g0BGqL329940 for ; Fri, 11 Jan 2002 08:52:21 -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 RAA27732; Fri, 11 Jan 2002 17:53:25 +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 RAA19424; Fri, 11 Jan 2002 17:51:46 +0100 Message-ID: <3C3F1820.BEFA97B6@bull.net> Date: Fri, 11 Jan 2002 17:51:44 +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: Alfonso De Gregorio CC: "Housley, Russ" , ietf-pkix@imc.org Subject: Re: Cautionary Period References: <20020111152114.A32635@server.speedcom.it> <20020111180626.A15675@foobar.andxor.it> 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: Alfonso, Very good point. It is true that some thin clients may not have a time reference available but may simply support a nonce mechanism. So you are quite right to say that delegating a path validation to a TTP allows execution environments to be unaware of the current-time. Another argument is that some thin clients may not be aware of the value or even the existence of a cautionary period associated with some policy. That cautionary period may even change. So it is required to manage that value at the policy level (which means the server level) rather than locally at the client level. Denis > Hi Russ, hi Denis, hi Everyone, > > > I encourage everyone to read DPV and DPD requirements document, and post > > their view on this subject. I believe that the document expresses Denis' > > view on the issue. My view is that cautionary period is a not a > > requirement for DPV or DPD. However, cautionary periods might be used as > > part of an application-specific risk mitigation mechanism when trying to > > determine the validity of a particular signature. For example, waiting for > > cautionary period before considering a signature to be valid on a > > high-value electronic contract may be prudent. Therefore, cautionary > > periods might be supported in DSV (delegated signature validation). > > In order to observe the cautionary-period-delay at application level > the execution environment must be current-time-aware. > DPV target execution environments are assumed to be constrained, at > least by a processing and/or communication point of view. > Constrained execution environments, such as telephones and PDA, > are not necessarily current-time-aware (or have time-sources not > necessarily trusted). > Delegating a path validation to a TTP allows execution environments > to be unaware of the current-time. > So, IMHO, cautionary periods should be a requirement for DPV. > > alfonso From owner-ietf-pkix Fri Jan 11 09:27:32 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BHRWr01188 for ietf-pkix-bks; Fri, 11 Jan 2002 09:27:32 -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 g0BHRT301184 for ; Fri, 11 Jan 2002 09:27:30 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA27681; Fri, 11 Jan 2002 18:27:18 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 18:27:18 +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 SAA09718; Fri, 11 Jan 2002 18:27:17 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA02444; Fri, 11 Jan 2002 18:27:17 +0100 (MET) Date: Fri, 11 Jan 2002 18:27:17 +0100 (MET) Message-Id: <200201111727.SAA02444@emeriau.edelweb.fr> To: pgut001@cs.auckland.ac.nz, rhousley@rsasecurity.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: Andreas.Sterbenz@sun.com, ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > Peter Gutmann: > > I would prefer to maintain alignment with RFC 2585. The use of SEQUENCE OF > would be fewer bit on the wire, but it would also require the specification > of another MIME type for the transfer of certificates. > > Russ > And what about using a cert-only cms message? From owner-ietf-pkix Fri Jan 11 09:43:49 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BHhnF01870 for ietf-pkix-bks; Fri, 11 Jan 2002 09:43:49 -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 g0BHhk301866 for ; Fri, 11 Jan 2002 09:43:46 -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 SAA61530; Fri, 11 Jan 2002 18:43:41 +0100 (CET) (envelope-from adg@foobar.andxor.it) Received: by foobar.andxor.it (Postfix, from userid 1000) id 3FDE5F92C; Fri, 11 Jan 2002 20:42:01 +0100 (CET) Date: Fri, 11 Jan 2002 20:42:01 +0100 From: Alfonso De Gregorio To: Denis Pinkas Cc: ietf-pkix@imc.org Subject: Re: Cautionary Period Message-ID: <20020111204201.A15917@foobar.andxor.it> Reply-To: Alfonso De Gregorio References: <20020111182250.C883@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: <20020111182250.C883@server.speedcom.it>; from agregorio@acm.org on Fri, Jan 11, 2002 at 06:22:50PM +0100 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis, > Another argument is that some thin clients may not be aware of the value or > even the existence of a cautionary period associated with some policy. That > cautionary period may even change. So it is required to manage that value at > the policy level (which means the server level) rather than locally at the > client level. Agreed. Thanks, alfonso From owner-ietf-pkix Fri Jan 11 09:48:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BHmTF02030 for ietf-pkix-bks; Fri, 11 Jan 2002 09:48:29 -0800 (PST) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BHmS302026 for ; Fri, 11 Jan 2002 09:48:28 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0GPS00F01C4O3W@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 11 Jan 2002 09:48:24 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0GPS00F2TC4O28@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 11 Jan 2002 09:48:24 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 09:48:23 -0800 Content-return: allowed Date: Fri, 11 Jan 2002 09:48:22 -0800 From: Ambarish Malpani Subject: RE: Cautionary Period To: ietf-pkix@imc.org Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E028E4FC3@exchange.valicert.com> 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: Hi Alfonso, Denis, I disagree with the need for cautionary period in the DPV protocol. Here is my reasoning: The rationale for cautionary period, is the argument that a CRL/ OCSP response is necessarily out of date, because it takes some time to discover, report and process a revocation request. This means that a certificate should not be trusted for some time after you have received it - to ensure that the revocation information is current. In most practical systems that I have seen, people are more than willing to accept the risk of using a certificate if it is not currently revoked - most people don't want to wait till the next CRL is published, or wait till a CA has been given enough of a margin to be able to process revocation requests. For example, in the credit card world, we use our cards and get our mechandise immediately, even though it would take some time to report the loss of a credit card. I think adding cautionary period to this protocol would just add unnecessary complexity. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Alfonso De Gregorio [mailto:agregorio@acm.org] > Sent: Friday, January 11, 2002 9:06 AM > To: Denis.Pinkas@bull.net; Housley, Russ > Cc: ietf-pkix@imc.org > Subject: Re: Cautionary Period > > > > Hi Russ, hi Denis, hi Everyone, > > > I encourage everyone to read DPV and DPD requirements > document, and post > > their view on this subject. I believe that the document > expresses Denis' > > view on the issue. My view is that cautionary period is a not a > > requirement for DPV or DPD. However, cautionary periods > might be used as > > part of an application-specific risk mitigation mechanism > when trying to > > determine the validity of a particular signature. For > example, waiting for > > cautionary period before considering a signature to be valid on a > > high-value electronic contract may be prudent. Therefore, > cautionary > > periods might be supported in DSV (delegated signature validation). > > In order to observe the cautionary-period-delay at application level > the execution environment must be current-time-aware. > DPV target execution environments are assumed to be constrained, at > least by a processing and/or communication point of view. > Constrained execution environments, such as telephones and PDA, > are not necessarily current-time-aware (or have time-sources not > necessarily trusted). > Delegating a path validation to a TTP allows execution environments > to be unaware of the current-time. > So, IMHO, cautionary periods should be a requirement for DPV. > > alfonso > From owner-ietf-pkix Fri Jan 11 10:54:32 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BIsWH04115 for ietf-pkix-bks; Fri, 11 Jan 2002 10:54:32 -0800 (PST) Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BIsU304111 for ; Fri, 11 Jan 2002 10:54:30 -0800 (PST) Received: from phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id g0BIsWL47430 for ; Fri, 11 Jan 2002 11:54:32 -0700 (MST) Message-ID: <3C3F3486.DB6FF3CF@phaos.com> Date: Fri, 11 Jan 2002 13:52:54 -0500 From: Joe Morgan X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-GB MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: TSP interop Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0628B9E204A178C2FD023D44" 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. --------------ms0628B9E204A178C2FD023D44 Content-Type: multipart/alternative; boundary="------------D7578175CBB0B815C0811901" --------------D7578175CBB0B815C0811901 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, Below are the results the interoperability tests we've conducted with our new TSP implementation against some of the test TSAs mentioned previously on this mailing list. Cheers, Joe -- Joe Morgan Senior Software Engineer Phaos Technology Corp. http://www.phaos.com/ SERVER | HTTP | TCP | | | | | | | Peter Gutmann | | | host = tsa.cryptoapps.com | | | port = 3318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | n/a | | | | | | | IAIK | | | host = bais.iaik.at | | | port = 318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | SUCCESS | | | | | | | Datum | | | host = 64.241.183.87 | | | port = 318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | SUCCESS | | | | | | | SIA | | | host = 193.203.230.166 | | | port = 318 | | | policy id = 1.3.135.1.2.0 | n/s | SUCCESS | | | | | | | EdelWeb | | | url = | | | http://www.edelweb.fr/ | | | cgi-bin/service-tsp | | | policy id = 1.2.3.4.5.6 | SUCCESS | n/s | | | | | | | CNSG | | | host = tsp.test.polito.it | | | port = 318 | | | policy id = 0.4.0.1.1.1 | n/s | SUCCESS | | | | | | | C&A | | | host = 195.223.2.6 | | | port = 3318 | | | policy id = 0.4.0.1.1.1 | | | url = | | | http://195.223.2.6:8080/ | | | timestamp | SUCCESS | SUCCESS | n/s = Not supported. n/a = Not available. --------------D7578175CBB0B815C0811901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all,

Below are the results the interoperability tests we've
conducted with our new TSP implementation against some of the test TSAs
mentioned previously on this mailing list.

Cheers,
Joe

--
Joe Morgan
Senior Software Engineer
Phaos Technology Corp.
http://www.phaos.com/

SERVER                           |   HTTP     |   TCP     |
                                 |            |           |
                                 |            |           |
Peter Gutmann                    |            |           |
host = tsa.cryptoapps.com        |            |           |
port = 3318                      |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   n/a     |
                                 |            |           |
                                 |            |           |
IAIK                             |            |           |
host = bais.iaik.at              |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
Datum                            |            |           |
host = 64.241.183.87             |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
SIA                              |            |           |
host = 193.203.230.166           |            |           |
port = 318                       |            |           |
policy id = 1.3.135.1.2.0        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
EdelWeb                          |            |           |
url =                            |            |           |
http://www.edelweb.fr/           |            |           |
   cgi-bin/service-tsp           |            |           |
policy id = 1.2.3.4.5.6          |   SUCCESS  |   n/s     |
                                 |            |           |
                                 |            |           |
CNSG                             |            |           |
host = tsp.test.polito.it        |            |           |
port = 318                       |            |           |
policy id = 0.4.0.1.1.1          |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
C&A                              |            |           |
host = 195.223.2.6               |            |           |
port = 3318                      |            |           |
policy id = 0.4.0.1.1.1          |            |           |
url =                            |            |           |
http://195.223.2.6:8080/         |            |           |
   timestamp                     |   SUCCESS  |  SUCCESS  |
 
 

n/s = Not supported.
n/a = Not available.
 
 
  --------------D7578175CBB0B815C0811901-- --------------ms0628B9E204A178C2FD023D44 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 MIIJRAYJKoZIhvcNAQcCoIIJNTCCCTECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BvIwggbuMIIF1qADAgECAhEA0B5HMgAAAnwAAAAnAAAeGDANBgkqhkiG9w0BAQUFADCBqTEL MAkGA1UEBhMCdXMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQw IgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgx MRYwFAYDVQQDEw1EU1QgUm9vdENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVz dC5jb20wHhcNMDEwMjA1MjAyOTMyWhcNMDIwMjA1MjAyOTMyWjCByzELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEZMBcGA1UEChMQUEhBT1Mg VEVDSE5PTE9HWTEZMBcGA1UECxMQUEhBT1MgVEVDSE5PTE9HWTEYMBYGA1UEAxMPSm9zZXBo IE0gTW9yZ2FuMSAwHgYJKoZIhvcNAQkBFhFqbW9yZ2FuQHBoYW9zLmNvbTEkMCIGCgmSJomT 8ixkAQETFEQwMUU0NzMyLjI3Qy4yNy4xRTE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCvgpFidXcUh+hajHg9EP8GlSxB6MOwOKbRxcdaBdZlkPvDCcezbRx8rS/BIQuI4TJfZgY1 Kh4TV1XLi0x2GWOrEnF6U6+BbjCqI1gDxct4lyjIkbegqOyH/RqYQu0LyqLJhXRYtye5O/uV 26PpUkaKjw+SO562JkmVTtMMBR8c1wIDAQABo4IDbzCCA2swggGiBgNVHSAEggGZMIIBlTCC AZEGCWCGSAGG+S8AADCCAYIwUgYIKwYBBQUHAgEWRmh0dHBzOi8vc2VjdXJlLmRpZ3NpZ3Ry dXN0LmNvbS9kb2NzL3BvbGljaWVzL3RzL2RzdC1jcHMtdjE5OTkwODI0Lmh0bWwwggEqBggr BgEFBQcCAjCCARwaggEYVGhlIHZhbHVlIG9mIHRoaXMgVHJ1c3QgSUQgQ2VydGlmaWNhdGUs IGl0cyByZWxpYW5jZSBsaW1pdCwgYW5kIHRoZSBsaWFiaWxpdHkgb2YgdGhlIGlzc3VlciBh cmUgZXN0YWJsaXNoZWQgYnkgY29udHJhY3QgYW5kIGxpbWl0ZWQgYnkgVXRhaCBsYXcuICBU byByZWFzb25hYmx5IHJlbHkgb24gdGhpcyBjZXJ0aWZpY2F0ZSwgeW91IG11c3QgYmUgYW4g YXV0aG9yaXplZCByZWx5aW5nIHBhcnR5IGFuZCB2YWxpZGF0ZSBpdCBhdDogIGh0dHBzOi8v c2VjdXJlLmRpZ3NpZ3RydXN0LmNvbS90czB8BgNVHR8EdTBzMHGgb6BthmtsZGFwOi8vbGRh cC5kaWdzaWd0cnVzdC5jb20vb3U9RFNUQ0EgWDEsbz1EaWdpdGFsIFNpZ25hdHVyZSBUcnVz dCBDby4sYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCCASsGCWCGSAGG +EIBDQSCARwWggEYVGhlIHZhbHVlIG9mIHRoaXMgVHJ1c3QgSUQgQ2VydGlmaWNhdGUsIGl0 cyByZWxpYW5jZSBsaW1pdCwgYW5kIHRoZSBsaWFiaWxpdHkgb2YgdGhlIGlzc3VlciBhcmUg ZXN0YWJsaXNoZWQgYnkgY29udHJhY3QgYW5kIGxpbWl0ZWQgYnkgVXRhaCBsYXcuICBUbyBy ZWFzb25hYmx5IHJlbHkgb24gdGhpcyBjZXJ0aWZpY2F0ZSwgeW91IG11c3QgYmUgYW4gYXV0 aG9yaXplZCByZWx5aW5nIHBhcnR5IGFuZCB2YWxpZGF0ZSBpdCBhdDogIGh0dHBzOi8vc2Vj dXJlLmRpZ3NpZ3RydXN0LmNvbS90czAJBgNVHRMEAjAAMAsGA1UdDwQEAwID+DANBgkqhkiG 9w0BAQUFAAOCAQEAHb1tvm6pDfxHPE80Ebv20BEO5e0/+8BUtxe9HgMhpkemGXmsH5ZY7F7w 73DT8vsCi6UcAOTFxnPNm0cpT+PuiNPKLbrTcktow7wLFUcJzHpPREtPCuDtCsDOrdjzW9Xc HZx3FZyoMOU2JOn8UB4YgPwKUGImD+is7lxpBaB9uulJKPedzmQeMkWb6vn29/2KQR8iFL36 F8ktjl1+Z1Vm+A5jwhDC6msLRNtXC6wisjiDJnRT4vrf74o74GmNYcuANTa+QJpLdvpEAUhE LEpNQNIfW73C/At8dGy2wVUFdr/kFqFlJ8/dcShOQSMP92XFB759aHG21Z801rXCVy3atjGC AhowggIWAgEBMIG/MIGpMQswCQYDVQQGEwJ1czENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLjER MA8GA1UECxMIRFNUQ0EgWDExFjAUBgNVBAMTDURTVCBSb290Q0EgWDExITAfBgkqhkiG9w0B CQEWEmNhQGRpZ3NpZ3RydXN0LmNvbQIRANAeRzIAAAJ8AAAAJwAAHhgwCQYFKw4DAhoFAKCB sTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTExODUy NTRaMCMGCSqGSIb3DQEJBDEWBBQF9L5O6D4vZDPCLPQjJKzvrb4o+TBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgGb4DN7tW1AFZSeCfcWmibMKC9L4 jzCDhyfdSCubU1Vm3GZn9hOqUPyi4qWl6imAg6qeLBwNBILsMITbGZ24PG7QU+UjS3vCU8+O CBTPPIxhuI8c533PvIjYeh7Oir6Hf15VEUTxoWhzeOwxJKzhM/1EYZtl44BdRTFRsZSiOvIy --------------ms0628B9E204A178C2FD023D44-- From owner-ietf-pkix Fri Jan 11 11:12:23 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJCNc04697 for ietf-pkix-bks; Fri, 11 Jan 2002 11:12:23 -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 g0BJCL304693 for ; Fri, 11 Jan 2002 11:12:21 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:12:00 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 OAA02388 for ; Fri, 11 Jan 2002 14:12:23 -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 g0BJCLe21363 for ; Fri, 11 Jan 2002 14:12:21 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 14:12:20 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.67]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZBWT; Fri, 11 Jan 2002 14:12:05 -0500 Message-ID: <5.0.1.4.2.20020111135539.02580278@exna07.securitydynamics.com> From: "Housley, Russ" To: Alfonso De Gregorio Cc: ietf-pkix@imc.org Subject: Re: Cautionary Period Date: Fri, 11 Jan 2002 14:09:35 -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: Alfonso: > > I encourage everyone to read DPV and DPD requirements document, and post > > their view on this subject. I believe that the document expresses Denis' > > view on the issue. My view is that cautionary period is a not a > > requirement for DPV or DPD. However, cautionary periods might be used as > > part of an application-specific risk mitigation mechanism when trying to > > determine the validity of a particular signature. For example, waiting > for > > cautionary period before considering a signature to be valid on a > > high-value electronic contract may be prudent. Therefore, cautionary > > periods might be supported in DSV (delegated signature validation). > >In order to observe the cautionary-period-delay at application level >the execution environment must be current-time-aware. >DPV target execution environments are assumed to be constrained, at >least by a processing and/or communication point of view. >Constrained execution environments, such as telephones and PDA, >are not necessarily current-time-aware (or have time-sources not >necessarily trusted). >Delegating a path validation to a TTP allows execution environments >to be unaware of the current-time. >So, IMHO, cautionary periods should be a requirement for DPV. There are many application contexts where the concept of a cautionary period is irrelevant. For example: TLS. The client will either accept the server's certificate for establishment of the TLS-protected session, or it will reject it. So, when does it matter? Non-repudiation of a high-value transaction. In such a context, it is very important to know when a transaction take place. The PKIX working group has done a lot of work on TSP to fill this requirement. Let's assume that the constrained client wants to validate such a transaction. The TSP timestamp provides the date/time of interest. It can ask the DPV server if the signer's path was valid at the time that the signature was generated. In my view, the cautionary period only impacts the signature on the transaction. The DPV server does not validate this signature. Has adequate time passed since the signature was applied to ensure that recent compromise of the end-entity private key has been reported? I submit that this a signature validation question, not a certification path validation question. Russ ============================================================================ ================ 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 Fri Jan 11 11:47:19 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJlJh05807 for ietf-pkix-bks; Fri, 11 Jan 2002 11:47:19 -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 g0BJlH305802 for ; Fri, 11 Jan 2002 11:47:17 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:46:56 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 OAA05544 for ; Fri, 11 Jan 2002 14:47:19 -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 g0BJlHR24981 for ; Fri, 11 Jan 2002 14:47:17 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 14:47:15 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.77]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZCMV; Fri, 11 Jan 2002 14:47:02 -0500 Message-ID: <5.0.1.4.2.20020111144333.02e12a98@exna07.securitydynamics.com> From: "Housley, Russ" To: Peter Sylvester Cc: ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt Date: Fri, 11 Jan 2002 14:45:24 -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: Peter: >Another one: > > > If the DPV request does not specify a validation policy, the server > > response MUST indicate the one that was used. In such a case, the > > client must verify that the one selected by the server is appropriate. > >I propose: > >"A server response MUST indicate the validation policy that has been used, > and a client MUST verify that it is acceptable." I would prefer to change the second MUST to SHOULD. If a client is configured to work with one or more organizational DPV servers, then that client must accept the response, regardless of the policy indicated. Russ ============================================================================ ================ 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 Fri Jan 11 11:47:18 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJlI705804 for ietf-pkix-bks; Fri, 11 Jan 2002 11:47:18 -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 g0BJlG305791 for ; Fri, 11 Jan 2002 11:47:16 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:46:55 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 OAA05536 for ; Fri, 11 Jan 2002 14:47:17 -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 g0BJlGR24971 for ; Fri, 11 Jan 2002 14:47:16 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 14:47:15 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.77]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZCMT; Fri, 11 Jan 2002 14:47:00 -0500 Message-ID: <5.0.1.4.2.20020111144004.02dffbf0@exna07.securitydynamics.com> From: "Housley, Russ" To: Peter Sylvester Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Date: Fri, 11 Jan 2002 14:41:15 -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: Peter: > > I would prefer to maintain alignment with RFC 2585. The use of > SEQUENCE OF > > would be fewer bit on the wire, but it would also require the > specification > > of another MIME type for the transfer of certificates. > >And what about using a cert-only cms message? This is acceptable, but I prefer one that is more straightforward to implement with web server tools. Russ ============================================================================ ================ 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 Fri Jan 11 14:32:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0BMWhp10468 for ietf-pkix-bks; Fri, 11 Jan 2002 14:32:43 -0800 (PST) Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BMWg310464 for ; Fri, 11 Jan 2002 14:32:42 -0800 (PST) Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g0BMWhL07962 for ; Fri, 11 Jan 2002 14:32:44 -0800 (PST) From: "Michael Myers" To: Subject: RE: Cautionary Period Date: Fri, 11 Jan 2002 14:30:33 -0800 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.2911.0) Importance: Normal In-Reply-To: <5.0.1.4.2.20020110145333.025521c0@exna07.securitydynamics.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I agree with Russ. Simpler is better. Consider IKE vs. JFK. Mike > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of > Housley, Russ > Sent: Thursday, January 10, 2002 12:10 PM > To: ietf-pkix@imc.org > Subject: Cautionary Period > > > > The updated Delegated Path Validation (DPV) and > Delegated Path Discovery > (DPD) Protocol Requirements document > > was recently posted. You may notice that I am a > co-author with Denis on > this document. Denis invited me to be a co-author > because I submitted many > comments. There were many, many editorial ones. > There were also technical > ones. Denis and I were able to resolve the vast bulk > of the technical > issues; however, we have not been able to reach a > compromise on one open > issue. That issue is the subject of this note. > > I encourage everyone to read DPV and DPD requirements > document, and post > their view on this subject. I believe that the > document expresses Denis' > view on the issue. My view is that cautionary period > is a not a > requirement for DPV or DPD. However, cautionary > periods might be used as > part of an application-specific risk mitigation > mechanism when trying to > determine the validity of a particular signature. > For example, waiting for > cautionary period before considering a signature to > be valid on a > high-value electronic contract may be prudent. > Therefore, cautionary > periods might be supported in DSV (delegated > signature validation). > > Since Denis and I were unable to resolve this issue > in an author-to-author > dialogue, I am bring this issue to the whole mail > list. As far as I know, > this is the only open issue with the DPV and DPD > Protocol Requirements > document. I hope that this issue can be quickly > resolved so that we can > get on with the protocol development. > > Russ > From owner-ietf-pkix Fri Jan 11 18:27:44 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0C2Rip19293 for ietf-pkix-bks; Fri, 11 Jan 2002 18:27:44 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C2Rh319289 for ; Fri, 11 Jan 2002 18:27:43 -0800 (PST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0C2OMR08817; Fri, 11 Jan 2002 18:24:22 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 18:28:33 -0800 Message-ID: From: "Deacon, Alex" To: "'Housley, Russ'" , Alfonso De Gregorio Cc: ietf-pkix@imc.org Subject: RE: Cautionary Period Date: Fri, 11 Jan 2002 18:26:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Right, it seems pretty clear to me from the paragraph in section 4.1 copied below that the cautionary period only impacts the status of the signature that was created by the certificate at some point in the recent past....not the status of the certificate itself. So I agree that this is a DSV concept, not a DPV concept. "When the public key within the certificate is used to verify some usage from the recent past, it is possible to apply a cautionary period to further reduce the risk. In such a case, the policy MAY indicate a minimum delay to be observed between the time T in the past, i.e. when the use of the private key took was supposed to take place, and the time of the current verification." BTW, I think the word "took" in that last sentence is stray and should be removed. Regards, Alex > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Friday, January 11, 2002 11:10 AM > To: Alfonso De Gregorio > Cc: ietf-pkix@imc.org > Subject: Re: Cautionary Period > > > > Alfonso: > > > > I encourage everyone to read DPV and DPD requirements > document, and post > > > their view on this subject. I believe that the document expresses > Denis' > > > view on the issue. My view is that cautionary period is a not a > > > requirement for DPV or DPD. However, cautionary periods > might be used > as > > > part of an application-specific risk mitigation mechanism > when trying to > > > determine the validity of a particular signature. For > example, waiting > > for > > > cautionary period before considering a signature to be valid on a > > > high-value electronic contract may be prudent. > Therefore, cautionary > > > periods might be supported in DSV (delegated signature > validation). > > > >In order to observe the cautionary-period-delay at application level > >the execution environment must be current-time-aware. > >DPV target execution environments are assumed to be constrained, at > >least by a processing and/or communication point of view. > >Constrained execution environments, such as telephones and PDA, > >are not necessarily current-time-aware (or have time-sources not > >necessarily trusted). > >Delegating a path validation to a TTP allows execution environments > >to be unaware of the current-time. > >So, IMHO, cautionary periods should be a requirement for DPV. > > There are many application contexts where the concept of a cautionary > period is irrelevant. For example: TLS. The client will > either accept the > server's certificate for establishment of the TLS-protected > session, or it > will reject it. > > So, when does it matter? Non-repudiation of a high-value > transaction. In > such a context, it is very important to know when a transaction take > place. The PKIX working group has done a lot of work on TSP > to fill this > requirement. > > Let's assume that the constrained client wants to validate such a > transaction. The TSP timestamp provides the date/time of > interest. It can > ask the DPV server if the signer's path was valid at the time > that the > signature was generated. > > In my view, the cautionary period only impacts the signature on the > transaction. The DPV server does not validate this signature. Has > adequate time passed since the signature was applied to > ensure that recent > compromise of the end-entity private key has been reported? > I submit that > this a signature validation question, not a certification > path validation > question. > > Russ > > > > > ============================================================== > ============== > ================ > 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 Fri Jan 11 20:21:48 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0C4Lma21184 for ietf-pkix-bks; Fri, 11 Jan 2002 20:21: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 g0C4Lk321179 for ; Fri, 11 Jan 2002 20:21: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 RAA20053; Sat, 12 Jan 2002 17:20: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 RAA229582; Sat, 12 Jan 2002 17:20:15 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Sat, 12 Jan 2002 17:20:15 +1300 (NZDT) Message-ID: <200201120420.RAA229582@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, jmorgan@phaos.com Subject: Re: TSP interop Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Joe Morgan writes: >policy id = 1.3.6.1.4.1.3029.56.36.54 In case anyone's wondering what that value is, that's the 'snooze policy, "Anything that arrives, we sign" (based on the Fido 'snooze editorial policy, "Anything that arrives, we print"). >tsa.cryptoapps.com It'll be back after the weekend when I rebuild it on the new machine. Anyone can also get the full code (client + server) from http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ if they want it. Peter. From owner-ietf-pkix Fri Jan 11 20:40:13 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0C4eDw21478 for ietf-pkix-bks; Fri, 11 Jan 2002 20:40:13 -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 g0C4e8321473 for ; Fri, 11 Jan 2002 20:40:11 -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 RAA20850; Sat, 12 Jan 2002 17:39:49 +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 RAA229729; Sat, 12 Jan 2002 17:39:45 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Sat, 12 Jan 2002 17:39:45 +1300 (NZDT) Message-ID: <200201120439.RAA229729@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: michael@stroeder.com, pgut001@cs.auckland.ac.nz Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Michael StrM-vder writes: >Hmm, I think the cert store implementation itself should deal with these kind >of index optimization issues. I vote for just submitting search values as is >and let the certificate store backend do the bit reducing at the server-side >if necessary at all. That makes client implementations simpler and leaves up >decisions about how to deal with possible collisions to the server-side cert >store implementation. Fair enough, if no-one has any objections to the full 160 bits I'll leave it at that. Peter. From owner-ietf-pkix Fri Jan 11 21:13:32 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0C5DWJ22288 for ietf-pkix-bks; Fri, 11 Jan 2002 21:13:32 -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 g0C5DT322282 for ; Fri, 11 Jan 2002 21:13:30 -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 SAA21685; Sat, 12 Jan 2002 18:13:18 +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 SAA230488; Sat, 12 Jan 2002 18:13:17 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Sat, 12 Jan 2002 18:13:17 +1300 (NZDT) Message-ID: <200201120513.SAA230488@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Peter.Sylvester@edelweb.fr, rhousley@rsasecurity.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: "Housley, Russ" writes: >This is acceptable, but I prefer one that is more straightforward to implement >with web server tools. That's probably the best argument for choosing MIME multipart/RFC 2585 rather than a SEQUENCE OF, the server shouldn't need to do anything more specialised than "fetch value based on key, via HTTP". Any special-case processing can be done by the client. Peter. From owner-ietf-pkix Fri Jan 11 22:39:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0C6dGk24128 for ietf-pkix-bks; Fri, 11 Jan 2002 22:39:16 -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 g0C6dA324121 for ; Fri, 11 Jan 2002 22:39:14 -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 TAA23608 for ; Sat, 12 Jan 2002 19:39:09 +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 TAA232072 for ietf-pkix@imc.org; Sat, 12 Jan 2002 19:39:09 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Sat, 12 Jan 2002 19:39:09 +1300 (NZDT) Message-ID: <200201120639.TAA232072@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I wrote: >That's probably the best argument for choosing MIME multipart/RFC 2585 rather >than a SEQUENCE OF, the server shouldn't need to do anything more specialised >than "fetch value based on key, via HTTP". Any special-case processing can be >done by the client. There's another reason which I just realised while I was adding the IANA considerations: Requiring a DER-encoded response is rather ugly if you're processing something which isn't a DER-encoded certificate. While I shall reserve my opinion on the value of (say) XML certificates, I wouldn't want to implicitly exclude them through a particular data-encoding requirement. Peter. From owner-ietf-pkix Sat Jan 12 04:09:49 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0CC9ns29922 for ietf-pkix-bks; Sat, 12 Jan 2002 04:09:49 -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 g0CC9l329918 for ; Sat, 12 Jan 2002 04:09:47 -0800 (PST) Received: from fwd07.sul.t-online.de by mailout09.sul.t-online.com with smtp id 16PMyg-0006fN-00; Sat, 12 Jan 2002 13:09:38 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.20.98]) by fmrl07.sul.t-online.com with esmtp id 16PMyQ-15oTnEC; Sat, 12 Jan 2002 13:09:22 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id E32451572B5 for ; Sat, 12 Jan 2002 13:09:24 +0100 (CET) Message-ID: <3C402774.38AD0F67@stroeder.com> Date: Sat, 12 Jan 2002 13:09:24 +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: <200201120513.SAA230488@ruru.cs.auckland.ac.nz> 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: Peter Gutmann wrote: > > "Housley, Russ" writes: > > >This is acceptable, but I prefer one that is more straightforward to implement > >with web server tools. > > That's probably the best argument for choosing MIME multipart/RFC 2585 rather > than a SEQUENCE OF, the server shouldn't need to do anything more specialised > than "fetch value based on key, via HTTP". Any special-case processing can be > done by the client. +1 Ciao, Michael. From owner-ietf-pkix Sat Jan 12 11:49:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0CJnD408961 for ietf-pkix-bks; Sat, 12 Jan 2002 11:49:13 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0CJn9308957; Sat, 12 Jan 2002 11:49:10 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.0.1.4.2.20020110145333.025521c0@exna07.securitydynamics.com> References: <5.0.1.4.2.20020110145333.025521c0@exna07.securitydynamics.com> Date: Sat, 12 Jan 2002 11:49:06 -0800 To: "Housley, Russ" , ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: Re: Cautionary Period 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 3:10 PM -0500 1/10/02, Housley, Russ wrote: >My view is that cautionary period is a not a requirement for DPV or >DPD. ... Therefore, cautionary periods might be supported in DSV >(delegated signature validation). Agree. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Sun Jan 13 05:38:07 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0DDc7601333 for ietf-pkix-bks; Sun, 13 Jan 2002 05:38:07 -0800 (PST) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0DDc5301324 for ; Sun, 13 Jan 2002 05:38:05 -0800 (PST) Received: from fwd02.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16Pkpa-0004Cq-04; Sun, 13 Jan 2002 14:37:50 +0100 Received: from junker.stroeder.com (520010731148-0001@[62.224.170.110]) by fmrl02.sul.t-online.com with esmtp id 16PkpY-0h0ECmC; Sun, 13 Jan 2002 14:37:48 +0100 Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 4722E157117 for ; Sun, 13 Jan 2002 14:36:48 +0100 (CET) Message-ID: <3C418D6F.7FE562@stroeder.com> Date: Sun, 13 Jan 2002 14:36:47 +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: <200201111230.g0BCUaK01624@svart.tajt.se> 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: Tomas Gustavsson wrote: > > > Hmm, I think the cert store implementation itself should deal with > > these kind of index optimization issues. I vote for just submitting > > search values as is and let the certificate store backend do the bit > > reducing at the server-side if necessary at all. That makes client > > implementations simpler and leaves up decisions about how to deal > > with possible collisions to the server-side cert store > > implementation. > > I would agree with this. It simplifies things to use 'real' > values and let the backend/middleware do the optimization. While we're at it: It could also be useful to simply use a string hex-encoding of e.g. SHA-1 fingerprint as search value instead base64-encoding the binary SHA-1 value. I'd also like to suggest that a cert store implementation simply strips colons or spaces used as hex-byte separator to determine the search value. This would enable the cert store to search for values which the user can cut&paste from another software's output. (Off course the search value is assumed to be URL-encoded as already stated in the draft.) Example of typically used representations of SHA-1 fingerprint used as search value treated as equal: C1:50:FF:EF:93:5A:FA:8C:15:49:AE:74:C1:A0:8E:FA:CC:10:99:1F C150 FFEF 935A FA8C 1549 AE74 C1A0 8EFA CC10 991F  C150FFEF935AFA8C1549AE74C1A08EFACC10991F c150ffef935afa8c1549ae74c1a08efacc10991f This can all be implemented very easily with typical programming languages used for web apps today. Ciao, Michael. From owner-ietf-pkix Mon Jan 14 01:06:37 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E96b912335 for ietf-pkix-bks; Mon, 14 Jan 2002 01:06:37 -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 g0E96a312327 for ; Mon, 14 Jan 2002 01:06:36 -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 KAA21608; Mon, 14 Jan 2002 10:07:41 +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 KAA16170; Mon, 14 Jan 2002 10:06:01 +0100 Message-ID: <3C429F81.1CF6110F@bull.net> Date: Mon, 14 Jan 2002 10:06:09 +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: Ambarish Malpani CC: ietf-pkix@imc.org Subject: Re: Cautionary Period References: <613B3C619C9AD4118C4E00B0D03E7C3E028E4FC3@exchange.valicert.com> 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: > Hi Alfonso, Denis, > I disagree with the need for cautionary period in the DPV > protocol. Here is my reasoning: > The rationale for cautionary period, is the argument that a CRL/ > OCSP response is necessarily out of date, because it takes some > time to discover, report and process a revocation request. This > means that a certificate should not be trusted for some time > after you have received it - to ensure that the revocation > information is current. > In most practical systems that I have seen, people are more than > willing to accept the risk of using a certificate if it is not. Most people are "accepting the risk", just because most of them ignore the risk. I do agree that it is not always possible to apply a cautionnary period. In such a case, a risk is necessarilly taken. However, there are cases where, it is possible to lower the risk. This is possible for two security services: - non repudiation and - data origin authentication with integrity. For these cases, the support of a cautionary period allows to lower the risk. > currently revoked - most people don't want to wait till the next > CRL is published, or wait till a CA has been given enough of a > margin to be able to process revocation requests. For example, in > the credit card world, we use our cards and get our mechandise > immediately, even though it would take some time to report the > loss of a credit card. > > I think adding cautionary period to this protocol would just add > unnecessary complexity. This complexity argument does not stand. It is the reverse: simplicity ! Clients just ignore whether the policy includes or not a cautionary period. This is simplicity. There is no obligation for a policy to include a cautionary period, this is only one possibility. Clients need to be able to process an additional status. If they do not want to take advantage of that status, they can even consider it as equivalent to "not valid". This is certainly not adding complexity. Regards, Denis > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > -----Original Message----- > > From: Alfonso De Gregorio [mailto:agregorio@acm.org] > > Sent: Friday, January 11, 2002 9:06 AM > > To: Denis.Pinkas@bull.net; Housley, Russ > > Cc: ietf-pkix@imc.org > > Subject: Re: Cautionary Period > > > > > > > > Hi Russ, hi Denis, hi Everyone, > > > > > I encourage everyone to read DPV and DPD requirements > > document, and post > > > their view on this subject. I believe that the document > > expresses Denis' > > > view on the issue. My view is that cautionary period is a not a > > > requirement for DPV or DPD. However, cautionary periods > > might be used as > > > part of an application-specific risk mitigation mechanism > > when trying to > > > determine the validity of a particular signature. For > > example, waiting for > > > cautionary period before considering a signature to be valid on a > > > high-value electronic contract may be prudent. Therefore, > > cautionary > > > periods might be supported in DSV (delegated signature validation). > > > > In order to observe the cautionary-period-delay at application level > > the execution environment must be current-time-aware. > > DPV target execution environments are assumed to be constrained, at > > least by a processing and/or communication point of view. > > Constrained execution environments, such as telephones and PDA, > > are not necessarily current-time-aware (or have time-sources not > > necessarily trusted). > > Delegating a path validation to a TTP allows execution environments > > to be unaware of the current-time. > > So, IMHO, cautionary periods should be a requirement for DPV. > > > > alfonso > > From owner-ietf-pkix Mon Jan 14 01:20:36 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E9Kar13630 for ietf-pkix-bks; Mon, 14 Jan 2002 01:20:36 -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 g0E9KZ313626 for ; Mon, 14 Jan 2002 01:20:35 -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 KAA32096; Mon, 14 Jan 2002 10:21:37 +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 KAA15026; Mon, 14 Jan 2002 10:19:58 +0100 Message-ID: <3C42A2C6.51AC05CB@bull.net> Date: Mon, 14 Jan 2002 10:20:06 +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: "Housley, Russ" CC: Alfonso De Gregorio , ietf-pkix@imc.org Subject: Re: Cautionary Period References: <5.0.1.4.2.20020111135539.02580278@exna07.securitydynamics.com> 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: Russ, (text deleted) > There are many application contexts where the concept of a cautionary > period is irrelevant. For example: TLS. The client will either accept the > server's certificate for establishment of the TLS-protected session, or it > will reject it. True, but the reverse sentence is also true: "There are application contexts where the concept of a cautionary period is relevant". > So, when does it matter? Non-repudiation of a high-value transaction. In > such a context, it is very important to know when a transaction take > place. The PKIX working group has done a lot of work on TSP to fill this > requirement. Non-repudiation is not the single security service where a cautionary period is relevant. It is also relevant for data origin authentication with integrity. > Let's assume that the constrained client wants to validate such a > transaction. The TSP timestamp provides the date/time of interest. It can > ask the DPV server if the signer's path was valid at the time that the > signature was generated. Since it is not possible to know when the signature was generated, an upper limit of that time is use instead: the date of the time-stamp applied over the digital signature or the date included in an audit record See the DPV requirements document at: http://www.imc.org/draft-ietf-pkix-dsv-req. The correct sentence is thus: "It can ask the DPV server if the signer's path was valid at the time that the time-stamp was applied over the digital signature". > In my view, the cautionary period only impacts the signature on the > transaction. Since a cautionary period cannot be applied in the context of a confidentiality service or an authentication service, the right wording would be : "the cautionary period only impacts the use of a certificate in the context of a non-repudiation service or a data-origin-authentication-with-integrity service". > The DPV server does not validate this signature. Has > adequate time passed since the signature was applied to ensure that recent > compromise of the end-entity private key has been reported? I submit that > this a signature validation question, not a certification path validation > question. The basic question is how clients can take advantage of a DPV server in the case where a cautionary period exists and in the context of a non-repudiation service or a data-origin-authentication-with-integrity service ? There are two options whether : 1) the cautionary period has to be known by the client (which is what your arguments mandate). 2) the cautionary period is known by the server (which is what my arguments mandate). In the context of a non repudiation service, clients must necessarilly know either the date of the time-stamp or the date of the audit record. In the context of a data-origin-authentication-with-integrity service, clients must necessarilly know the purported date of the digital signature. With option 1, clients must locally manage the cautionary period for each supported policy and locally compare it either with the date of the time-stamp or the date of the audit record, or the the purported date of the digital signature. This makes management actions more difficult (and makes also thin clients fater) since if that period changes, local tables need to be updated in each client application. With option 2, clients do not need to manage that information locally since it is part of the policy supported by the server. They simply need to send to the server either the date of the time-stamp or the date of the audit record, or the purported date of the digital signature. The goal of these protocols is to delegate as much as possible all the validation conditions to a server. The cautionary period does not make an exception. Denis > Russ From owner-ietf-pkix Mon Jan 14 01:49:06 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E9n6p18699 for ietf-pkix-bks; Mon, 14 Jan 2002 01:49:06 -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 g0E9n4318695 for ; Mon, 14 Jan 2002 01:49:04 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA04471; Mon, 14 Jan 2002 10:49:02 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 10:49:03 +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 KAA17274; Mon, 14 Jan 2002 10:49:01 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA03347; Mon, 14 Jan 2002 10:49:00 +0100 (MET) Date: Mon, 14 Jan 2002 10:49:00 +0100 (MET) Message-Id: <200201140949.KAA03347@emeriau.edelweb.fr> To: ietf-pkix@imc.org, jmorgan@phaos.com Subject: Re: TSP interop Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > | | | > | | | > EdelWeb | | | > url = | | | > http://www.edelweb.fr/ | | | > cgi-bin/service-tsp | | | > policy id = 1.2.3.4.5.6 | SUCCESS | n/s | > | | | > | | | Does You client test whether the returned policy is the same as the one that You send ? From owner-ietf-pkix Mon Jan 14 02:22:53 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0EAMrc23372 for ietf-pkix-bks; Mon, 14 Jan 2002 02:22:53 -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 g0EAMo323357 for ; Mon, 14 Jan 2002 02:22:51 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA04574; Mon, 14 Jan 2002 11:22:46 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 11:22:46 +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 LAA17375; Mon, 14 Jan 2002 11:22:45 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA03356; Mon, 14 Jan 2002 11:22:44 +0100 (MET) Date: Mon, 14 Jan 2002 11:22:44 +0100 (MET) Message-Id: <200201141022.LAA03356@emeriau.edelweb.fr> To: Peter.Sylvester@edelweb.fr, rhousley@rsasecurity.com Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > > I would prefer to change the second MUST to SHOULD. If a client is > configured to work with one or more organizational DPV servers, then that > client must accept the response, regardless of the policy indicated. > . Russ, I can live with that but it might be useful to explain somehow the difference between 'MUST check whether it it is acceptable' and 'SHOULD check whether it it is acceptable' TIA Peter From owner-ietf-pkix Mon Jan 14 02:24:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EAOxj23628 for ietf-pkix-bks; Mon, 14 Jan 2002 02:24:59 -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 g0EAOw323624 for ; Mon, 14 Jan 2002 02:24:58 -0800 (PST) Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D9773CD1E for ; Mon, 14 Jan 2002 11:24:46 +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 ZKPQVG5X; Mon, 14 Jan 2002 11:24:46 +0100 Message-ID: <3C42B261.A9E97B0D@secude.com> Date: Mon, 14 Jan 2002 11:26:41 +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: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> Content-Type: text/html; 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,

is there also a new version of the document "Delegated Path
Validation and Delegated Path Discovery Protocols" or just
a new requirement document?

- Petra 

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.

Internet-Drafts@ietf.org schrieb:

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           : Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
        Author(s)       : D. Pinkas
        Filename        : draft-ietf-pkix-dpv-dpd-req-01.txt
        Pages           : 14
        Date            : 10-Jan-02

This document specifies requirements for two main request/response
pairs.
The first one, called Delegated Path Validation (DPV), can be used to
fully delegate a path validation processing to an DPV server,
according to a set of rules, called a validation policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-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-dpv-dpd-req-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-dpv-dpd-req-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.

  ------------------------------------------------------------------------

From owner-ietf-pkix Mon Jan 14 03:56:52 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EBuqs00430 for ietf-pkix-bks; Mon, 14 Jan 2002 03:56: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 g0EBuo300421 for ; Mon, 14 Jan 2002 03:56: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 MAA22820; Mon, 14 Jan 2002 12:57:57 +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 MAA19578; Mon, 14 Jan 2002 12:56:18 +0100 Message-ID: <3C42C767.605157D@bull.net> Date: Mon, 14 Jan 2002 12:56:23 +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: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> <3C42B261.A9E97B0D@secude.com> 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: Petra, > Denis, > is there also a new version of the document "Delegated Path > Validation and Delegated Path Discovery Protocols" Not at this time. Currently we need first to agree on the DPV / DPD requirements, then we will discuss the solutions to these requirements. The so-called "Delegated Path Validation and Delegated Path Discovery Protocols" document could be a candidate to fulfill these requirements. It is too early to say and this will only be discussed once the requirements document is adopted. > or just a new requirement document? Correct. It is a new document for both the DPV and DPD requirements. There is also a companion document for the DSV requirements. We will only discuss the DSV requirements document in detail when the DPV / DPD requirements document has completed the WG last call. Denis > - Petra > > > 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. > > > Internet-Drafts@ietf.org schrieb: > > > 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 : Delegated Path Validation and Delegated Path > > Discovery > > Protocol Requirements (DPV&DPD-REQ) > > Author(s) : D. Pinkas > > Filename : draft-ietf-pkix-dpv-dpd-req-01.txt > > Pages : 14 > > Date : 10-Jan-02 > > > > This document specifies requirements for two main request/response > > pairs. > > The first one, called Delegated Path Validation (DPV), can be used to > > fully delegate a path validation processing to an DPV server, > > according to a set of rules, called a validation policy. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-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-dpv-dpd-req-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-dpv-dpd-req-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. > > > > > > ------------------------------------------------------------------------ From owner-ietf-pkix Mon Jan 14 05:33:45 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0EDXjI05166 for ietf-pkix-bks; Mon, 14 Jan 2002 05:33:45 -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 g0EDXh305157 for ; Mon, 14 Jan 2002 05:33:43 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA05373; Mon, 14 Jan 2002 14:33:28 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 14:33:29 +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 OAA17936; Mon, 14 Jan 2002 14:33:27 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA03403; Mon, 14 Jan 2002 14:33:27 +0100 (MET) Date: Mon, 14 Jan 2002 14:33:27 +0100 (MET) Message-Id: <200201141333.OAA03403@emeriau.edelweb.fr> To: rhousley@rsasecurity.com, Denis.Pinkas@bull.net Subject: Re: Cautionary Period Cc: agregorio@acm.org, ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: It seems possible to me that a server indicates in a response a date in the past for which the 'ok'-status is definitive, or example the earliest date in CRLs etc., in order to avoids the client to check these details. If one wants to make statements about the future, i.e. to respond to a a 'now' request, the answer would always be, 'so far, ok, but (You have to check later|I'll send another answer later)'. I don't think it is necessary for a server to indicate: "not sure, come back in one day". From owner-ietf-pkix Mon Jan 14 06:14:52 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0EEEq507353 for ietf-pkix-bks; Mon, 14 Jan 2002 06:14:52 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EEEp307349 for ; Mon, 14 Jan 2002 06:14:51 -0800 (PST) Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09874; Mon, 14 Jan 2002 07:14:46 -0700 (MST) Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id OAA10546; Mon, 14 Jan 2002 14:14:45 GMT Message-ID: <3C42E7D0.8060409@sun.com> Date: Mon, 14 Jan 2002 14:14:40 +0000 From: Andreas Sterbenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Peter Gutmann CC: Peter.Sylvester@edelweb.fr, rhousley@rsasecurity.com, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <200201120513.SAA230488@ruru.cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Peter Gutmann wrote: > "Housley, Russ" writes: > >>This is acceptable, but I prefer one that is more straightforward to implement >>with web server tools. > > That's probably the best argument for choosing MIME multipart/RFC 2585 rather > than a SEQUENCE OF, the server shouldn't need to do anything more specialised > than "fetch value based on key, via HTTP". Any special-case processing can be > done by the client. I don't agree. Complexity should be put in the server, not the client. Reason being that there are typically more client than server implementations and that clients may have to operate with limited resources. I do agree that a non-standard SEQUENCE OF is suboptimal, but that argument does not apply for a CMS certs only message. [Did I mention that I do not feel like implementing multipart MIME messages this year? ;-) ] Andreas. From owner-ietf-pkix Mon Jan 14 07:00:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EF0hL08503 for ietf-pkix-bks; Mon, 14 Jan 2002 07:00:43 -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 g0EF0f308498 for ; Mon, 14 Jan 2002 07:00:42 -0800 (PST) Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 47DF7B44F; Mon, 14 Jan 2002 16:00:32 +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 ZKPQVH1J; Mon, 14 Jan 2002 16:00:31 +0100 Message-ID: <3C42F301.D5D3DEC@secude.com> Date: Mon, 14 Jan 2002 16:02:25 +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: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> <3C42B261.A9E97B0D@secude.com> <3C42C767.605157D@bull.net> Content-Type: text/html; 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,

may I still ask some questions concerning the document "Delegated
Path Validation and Delegated Path Discovery Protocols" ? 

PathValues :: = SEQUENCE {
       certificateValues      CertificateValues,
       revocationValues       RevocationValues }
I'm missing some ASN.1 definitions. You refer to "CertificateValues"
and "RevocationValues" but I couldn't find these definitions.

By the way, you should move this definition of "PathValues" from
the chapter "5.2.1. Request" to the chapter "5.2.2.  Response Syntax"
where it is used.

Another ASN.1 question: 

UsefulRevoc ::= CHOICE {
       certificateRevocationLists     CertificateRevocationLists,
       completeRevocationRefs         CompleteRevocationRefs }
A DPV request may contain useful revocation information provided
by the client. Maybe it's because I don't know the element
"CompleteRevocationRefs" but where do I store OCSP answers?

Could you please send the definition of "CompleteRevocationRefs"
and "completeCertificateRefs"? I guess they are imported from [ES-F],
"Electronic Signature Formats for long term electronic signatures", aren't they? 

   CertOrCertRef ::=  CHOICE {
       certificate          [1]  Certificate,
       certRef              [2]  OtherCertID }
I'm also missing the definition of OtherCertID used in a DPV and DPD request.

Thanks, Petra

Denis Pinkas schrieb:

Petra,

> Denis,

> is there also a new version of the document "Delegated Path
> Validation and Delegated Path Discovery Protocols"

Not at this time. Currently we need first to agree on the DPV / DPD
requirements, then we will discuss the solutions to these requirements.

The so-called "Delegated Path Validation and Delegated Path Discovery
Protocols" document could be a candidate to fulfill these requirements.
It is too early to say and this will only be discussed once the requirements
document is adopted.

> or just a new requirement document?

Correct. It is a new document for both the DPV and DPD requirements.

There is also a companion document for the DSV requirements.
We will only discuss the DSV requirements document in detail when
the DPV / DPD requirements document has completed the WG last call.

Denis

From owner-ietf-pkix Mon Jan 14 07:40:32 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EFeWc09902 for ietf-pkix-bks; Mon, 14 Jan 2002 07:40:32 -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 g0EFeT309896 for ; Mon, 14 Jan 2002 07:40:29 -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 KAA04657; Mon, 14 Jan 2002 10:40:28 -0500 (EST) Message-Id: <200201141540.KAA04657@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-ldap-v3-05.txt Date: Mon, 14 Jan 2002 10:40:27 -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 - LDAPv3 Author(s) : D. Chadwick Filename : draft-ietf-pkix-ldap-v3-05.txt Pages : Date : 11-Jan-02 This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-05.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-ldap-v3-05.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-ldap-v3-05.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: <20020111152557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-v3-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-v3-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020111152557.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Mon Jan 14 09:41:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EHfDV13255 for ietf-pkix-bks; Mon, 14 Jan 2002 09:41:13 -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 g0EHfC313248 for ; Mon, 14 Jan 2002 09:41:12 -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 SAA38354; Mon, 14 Jan 2002 18:42:20 +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 SAA20094; Mon, 14 Jan 2002 18:40:41 +0100 Message-ID: <3C431487.F188B469@bull.net> Date: Mon, 14 Jan 2002 18:25:27 +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: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> <3C42B261.A9E97B0D@secude.com> <3C42C767.605157D@bull.net> <3C42F301.D5D3DEC@secude.com> 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: Petra, Please take a look at RFC 3126, where many of the ASN.1 structures were imported from and are thus defined there. This should answer all your questions. Regards, Denis > Denis, > > may I still ask some questions concerning the document "Delegated > Path Validation and Delegated Path Discovery Protocols" ? > > > PathValues :: = SEQUENCE { > > certificateValues CertificateValues, > > revocationValues RevocationValues } > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues" > and "RevocationValues" but I couldn't find these definitions. > > By the way, you should move this definition of "PathValues" from > the chapter "5.2.1. Request" to the chapter "5.2.2. Response Syntax" > where it is used. > > Another ASN.1 question: > > > UsefulRevoc ::= CHOICE { > > certificateRevocationLists CertificateRevocationLists, > > completeRevocationRefs CompleteRevocationRefs } > > > A DPV request may contain useful revocation information provided > by the client. Maybe it's because I don't know the element > "CompleteRevocationRefs" but where do I store OCSP answers? > > Could you please send the definition of "CompleteRevocationRefs" > and "completeCertificateRefs"? I guess they are imported from [ES-F], > "Electronic Signature Formats for long term electronic signatures", aren't > they? > > > CertOrCertRef ::= CHOICE { > > certificate [1] Certificate, > > certRef [2] OtherCertID } > > > I'm also missing the definition of OtherCertID used in a DPV and DPD > request. > > Thanks, Petra > > Denis Pinkas schrieb: > > > Petra, > > > > > Denis, > > > > > is there also a new version of the document "Delegated Path > > > Validation and Delegated Path Discovery Protocols" > > > > Not at this time. Currently we need first to agree on the DPV / DPD > > requirements, then we will discuss the solutions to these requirements. > > > > The so-called "Delegated Path Validation and Delegated Path Discovery > > Protocols" document could be a candidate to fulfill these requirements. > > It is too early to say and this will only be discussed once the > > requirements > > document is adopted. > > > > > or just a new requirement document? > > > > Correct. It is a new document for both the DPV and DPD requirements. > > > > There is also a companion document for the DSV requirements. > > We will only discuss the DSV requirements document in detail when > > the DPV / DPD requirements document has completed the WG last call. > > > > Denis From owner-ietf-pkix Mon Jan 14 11:30:20 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EJUK916565 for ietf-pkix-bks; Mon, 14 Jan 2002 11:30:20 -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 g0EJUI316561 for ; Mon, 14 Jan 2002 11:30:18 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA07884; Mon, 14 Jan 2002 20:30:08 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 20:30:08 +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 UAA20352; Mon, 14 Jan 2002 20:30:07 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA03532; Mon, 14 Jan 2002 20:30:06 +0100 (MET) Date: Mon, 14 Jan 2002 20:30:06 +0100 (MET) Message-Id: <200201141930.UAA03532@emeriau.edelweb.fr> To: pgut001@cs.auckland.ac.nz, Andreas.Sterbenz@sun.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt Cc: Peter.Sylvester@edelweb.fr, rhousley@rsasecurity.com, ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: > >>This is acceptable, but I prefer one that is more straightforward to implement > >>with web server tools. > > > > That's probably the best argument for choosing MIME multipart/RFC 2585 rather > > than a SEQUENCE OF, the server shouldn't need to do anything more specialised > > than "fetch value based on key, via HTTP". Any special-case processing can be > > done by the client. > > > I don't agree. Complexity should be put in the server, not the client. Another argument may be that using a 'simple' standard developement kit for a server to create unnecessary overhead for a client (and useless data) instead of having a small and fast logic may result in having all kinds of possible and undesirable errors and protocol messages above HTTP/MIME to escape at some point. From owner-ietf-pkix Mon Jan 14 11:31:44 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0EJVih16598 for ietf-pkix-bks; Mon, 14 Jan 2002 11:31:44 -0800 (PST) Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EJVg316593 for ; Mon, 14 Jan 2002 11:31:42 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 16QCpa-000Iab-0C for ietf-pkix@imc.org; Mon, 14 Jan 2002 19:31:43 +0000 Message-ID: <3C4332D1.9E82B45A@gemplus.com> Date: Mon, 14 Jan 2002 19:34:41 +0000 From: Dr S N Henson X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt References: <5.0.1.4.2.20020111144004.02dffbf0@exna07.securitydynamics.com> 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: "Housley, Russ" wrote: > > Peter: > > > > I would prefer to maintain alignment with RFC 2585. The use of > > SEQUENCE OF > > > would be fewer bit on the wire, but it would also require the > > specification > > > of another MIME type for the transfer of certificates. > > > >And what about using a cert-only cms message? > > This is acceptable, but I prefer one that is more straightforward to > implement with web server tools. > Couldn't a valid indefinite length encoded certs only cms message be generated just using cut and paste? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: stephen.henson@gemplus.com PGP key: via homepage. From owner-ietf-pkix Mon Jan 14 15:33:52 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ENXqZ22930 for ietf-pkix-bks; Mon, 14 Jan 2002 15:33:52 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ENXo322925 for ; Mon, 14 Jan 2002 15:33:50 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA405034; Mon, 14 Jan 2002 18:30:46 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0ENXi7109694; Mon, 14 Jan 2002 18:33:44 -0500 Importance: Normal Sensitivity: Subject: Re: Cautionary Period To: Denis Pinkas Cc: "Housley, Russ" , Alfonso De Gregorio , ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Mon, 14 Jan 2002 18:33:24 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/14/2002 06:33:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis: You are correct that there are other services than NR for which cautionary period is useful. However, don't they all involve the validation of signed data (and data to be kept for a considerable time, at that)? If they do, then cautionary period should go into DSV. Tom Gindin Denis Pinkas @mail.imc.org on 01/14/2002 04:20:06 AM Sent by: owner-ietf-pkix@mail.imc.org To: "Housley, Russ" cc: Alfonso De Gregorio , ietf-pkix@imc.org Subject: Re: Cautionary Period Russ, (text deleted) > There are many application contexts where the concept of a cautionary > period is irrelevant. For example: TLS. The client will either accept the > server's certificate for establishment of the TLS-protected session, or it > will reject it. True, but the reverse sentence is also true: "There are application contexts where the concept of a cautionary period is relevant". > So, when does it matter? Non-repudiation of a high-value transaction. In > such a context, it is very important to know when a transaction take > place. The PKIX working group has done a lot of work on TSP to fill this > requirement. Non-repudiation is not the single security service where a cautionary period is relevant. It is also relevant for data origin authentication with integrity. > Let's assume that the constrained client wants to validate such a > transaction. The TSP timestamp provides the date/time of interest. It can > ask the DPV server if the signer's path was valid at the time that the > signature was generated. Since it is not possible to know when the signature was generated, an upper limit of that time is use instead: the date of the time-stamp applied over the digital signature or the date included in an audit record See the DPV requirements document at: http://www.imc.org/draft-ietf-pkix-dsv-req. The correct sentence is thus: "It can ask the DPV server if the signer's path was valid at the time that the time-stamp was applied over the digital signature". > In my view, the cautionary period only impacts the signature on the > transaction. Since a cautionary period cannot be applied in the context of a confidentiality service or an authentication service, the right wording would be : "the cautionary period only impacts the use of a certificate in the context of a non-repudiation service or a data-origin-authentication-with-integrity service". > The DPV server does not validate this signature. Has > adequate time passed since the signature was applied to ensure that recent > compromise of the end-entity private key has been reported? I submit that > this a signature validation question, not a certification path validation > question. The basic question is how clients can take advantage of a DPV server in the case where a cautionary period exists and in the context of a non-repudiation service or a data-origin-authentication-with-integrity service ? There are two options whether : 1) the cautionary period has to be known by the client (which is what your arguments mandate). 2) the cautionary period is known by the server (which is what my arguments mandate). In the context of a non repudiation service, clients must necessarilly know either the date of the time-stamp or the date of the audit record. In the context of a data-origin-authentication-with-integrity service, clients must necessarilly know the purported date of the digital signature. With option 1, clients must locally manage the cautionary period for each supported policy and locally compare it either with the date of the time-stamp or the date of the audit record, or the the purported date of the digital signature. This makes management actions more difficult (and makes also thin clients fater) since if that period changes, local tables need to be updated in each client application. With option 2, clients do not need to manage that information locally since it is part of the policy supported by the server. They simply need to send to the server either the date of the time-stamp or the date of the audit record, or the purported date of the digital signature. The goal of these protocols is to delegate as much as possible all the validation conditions to a server. The cautionary period does not make an exception. Denis > Russ From owner-ietf-pkix Tue Jan 15 03:29:38 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0FBTc216654 for ietf-pkix-bks; Tue, 15 Jan 2002 03:29:38 -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 g0FBTb316650 for ; Tue, 15 Jan 2002 03:29:37 -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 GAA18054; Tue, 15 Jan 2002 06:29:36 -0500 (EST) Message-Id: <200201151129.GAA18054@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-roadmap-07.txt Date: Tue, 15 Jan 2002 06:29:36 -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: Roadmap Author(s) : A. Arsenault, S. Turner Filename : draft-ietf-pkix-roadmap-07.txt Pages : 53 Date : 14-Jan-02 This document provides an overview or 'roadmap' of the work done by the IETF PKIX working group. It describes some of the terminology used in the working group's documents, and the theory behind an X.509-based Public Key Infrastructure, Privilege Management Infrastructure (PMI), and Time Stamping and Data Certification Infrastructures. It identifies each document developed by the PKIX working group, and describes the relationships among the various documents. It also provides advice to would-be PKIX implementors about some of the issues discussed at length during PKIX development, in hopes of making it easier to build implementations that will actually interoperate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-07.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-roadmap-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-roadmap-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020114175629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-roadmap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-roadmap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020114175629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 15 08:41:48 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0FGfmx02005 for ietf-pkix-bks; Tue, 15 Jan 2002 08:41:48 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FGfk302000 for ; Tue, 15 Jan 2002 08:41:46 -0800 (PST) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g0FGflZ04272 for ; Tue, 15 Jan 2002 11:41:47 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g0FGfko74340 for ; Tue, 15 Jan 2002 11:41:46 -0500 (EST) Received: from torrentnet.com (cristall.torrentnet.com [4.18.161.46]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id LAA22139; Tue, 15 Jan 2002 11:41:44 -0500 (EST) Message-ID: <3C445BC7.C5DFD0BB@torrentnet.com> Date: Tue, 15 Jan 2002 11:41:43 -0500 From: James Comen X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Question about encoding of RSA public Exponent 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: Hello, I looked through the archives and couldn't find the answer to this question. There was info about two's complement form for integers but nothing about the public exponents. If this is not the appropriate forum for this question - I apologize - feel free to point me to the proper forum. I've spent some time trying to decode the RSA public key which is part of the X.509 certificate. More specifically, it is the key used to exchange with a Cisco router when doing IKE with encrypted nonces. I want to know what information a cisco router expects and what I shoud expect when copying the RSA key from a cisco router For the RSA public key, there is a modulus and a public exponent. I generated a 1024 bit RSA key. The modulus is 0241 00C8934A 22BE0C99 ... 02 means it's an integer 41 is the length of the modulus - it's 41 rather than 40 due to the leading 00 to prevent it from being interpreted as a negative value 00C8... is the modulus The public exponent is 020301 0001 02 means it's an integer 03 is the length of the public exponent 010001 is the public exponent. The public exponent is what confuses me - it doesn't seem to be in two's complement form. The exponent value is 65537 Hex is 010001 Binary is 0000 0001 0000 0000 0000 0001 Two's complement is 1111 1110 1111 1111 1111 1110 + 1 hex is F E F F F F I would have thought this would have to be encoded as 020400FEFFFF Could you tell me what I'm overlooking in this case? Oh, one other quick question - Is the modulus encoded as a string of bytes or a multiprecision integer? Thank you very much, Jim Comen From owner-ietf-pkix Tue Jan 15 09:36:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FHahn03969 for ietf-pkix-bks; Tue, 15 Jan 2002 09:36:43 -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 g0FHaf303965 for ; Tue, 15 Jan 2002 09:36:41 -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 SAA25334; Tue, 15 Jan 2002 18:37:50 +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 SAA16526; Tue, 15 Jan 2002 18:35:49 +0100 Message-ID: <3C446864.30B43CEC@bull.net> Date: Tue, 15 Jan 2002 18:35:32 +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: Tom Gindin CC: "Housley, Russ" , Alfonso De Gregorio , ietf-pkix@imc.org Subject: Re: Cautionary Period References: 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: Tom, > Denis: > You are correct that there are other services than NR for which > cautionary period is useful. However, don't they all involve the > validation of signed data (and data to be kept for a considerable time, Is a week-end period a "considerable time" ? I do not think so. An e-mail sent on the friday may only be opened on the monday. Applying a cautionary period increases the confidence and reduces the risk. > at that)? If they do, then cautionary period should go into DSV. Everybody agrees that a cautionary period certainly applies to DSV. However, some thin clients would still like to use DPV to verify digital signatures in particular in the context of data origin authentication with integrity. I do not think it would be appropriate to say that it is not possible and that the cautionary period, when it exists, shall only be applied *locally* by the client. Denis > Tom Gindin > > Denis Pinkas @mail.imc.org on 01/14/2002 04:20:06 AM > > Sent by: owner-ietf-pkix@mail.imc.org > > To: "Housley, Russ" > cc: Alfonso De Gregorio , ietf-pkix@imc.org > Subject: Re: Cautionary Period > > Russ, > > (text deleted) > > > There are many application contexts where the concept of a cautionary > > period is irrelevant. For example: TLS. The client will either accept > the > > server's certificate for establishment of the TLS-protected session, or > it > > will reject it. > > True, but the reverse sentence is also true: "There are application > contexts > where the concept of a cautionary period is relevant". > > > So, when does it matter? Non-repudiation of a high-value transaction. In > > such a context, it is very important to know when a transaction take > > place. The PKIX working group has done a lot of work on TSP to fill this > > requirement. > > Non-repudiation is not the single security service where a cautionary > period > is relevant. It is also relevant for data origin authentication with > integrity. > > > Let's assume that the constrained client wants to validate such a > > transaction. The TSP timestamp provides the date/time of interest. It > can > > ask the DPV server if the signer's path was valid at the time that the > > signature was generated. > > Since it is not possible to know when the signature was generated, > an upper limit of that time is use instead: the date of the time-stamp > applied over the digital signature or the date included in an audit record > See the DPV requirements document at: > http://www.imc.org/draft-ietf-pkix-dsv-req. > > The correct sentence is thus: "It can ask the DPV server if the signer's > path was valid at the time that the time-stamp was applied over the digital > signature". > > > In my view, the cautionary period only impacts the signature on the > > transaction. > > Since a cautionary period cannot be applied in the context of a > confidentiality service or an authentication service, the right wording > would be : "the cautionary period only impacts the use of a certificate > in the context of a non-repudiation service or a > data-origin-authentication-with-integrity service". > > > The DPV server does not validate this signature. Has > > adequate time passed since the signature was applied to ensure that > recent > > compromise of the end-entity private key has been reported? I submit > that > > this a signature validation question, not a certification path validation > > question. > > The basic question is how clients can take advantage of a DPV server in the > case where a cautionary period exists and in the context of a > non-repudiation service or a data-origin-authentication-with-integrity > service ? > > There are two options whether : > > 1) the cautionary period has to be known by the client > (which is what your arguments mandate). > > 2) the cautionary period is known by the server > (which is what my arguments mandate). > > In the context of a non repudiation service, clients must necessarilly know > either the date of the time-stamp or the date of the audit record. > > In the context of a data-origin-authentication-with-integrity service, > clients must necessarilly know the purported date of the digital signature. > > With option 1, clients must locally manage the cautionary period for each > supported policy and locally compare it either with the date of the > time-stamp or the date of the audit record, or the the purported date of > the > digital signature. This makes management actions more difficult > (and makes also thin clients fater) since if that period changes, > local tables need to be updated in each client application. > > With option 2, clients do not need to manage that information locally since > it is part of the policy supported by the server. They simply need to send > to the server either the date of the time-stamp or the date of the audit > record, or the purported date of the digital signature. > > The goal of these protocols is to delegate as much as possible all the > validation conditions to a server. The cautionary period does not > make an exception. > > Denis > > > Russ From owner-ietf-pkix Tue Jan 15 10:32:09 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0FIW9N05481 for ietf-pkix-bks; Tue, 15 Jan 2002 10:32:09 -0800 (PST) Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FIW7305476 for ; Tue, 15 Jan 2002 10:32:07 -0800 (PST) Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g0FIW2i18183 for ; Tue, 15 Jan 2002 10:32:02 -0800 (PST) Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g0FIW2w23102 for ; Tue, 15 Jan 2002 10:32:02 -0800 (PST) Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:34:30 -0800 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH5DM8; Tue, 15 Jan 2002 13:31:55 -0500 Message-Id: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 15 Jan 2002 13:05:22 -0500 To: ietf-pkix@imc.org From: "Housley, Russ" Subject: Cautionary Period Straw Poll 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: From the previous thread (which seems to have died down), I think that everyone understands the Cautionary Period concept. I am trying to determine whether there is a constituency for Cautionary Period in DPV. I would like people that have an opinion to vote by sending a message to the list. The message should be structured as follows: To: ietf-pkix@imc.org Subject: RE: Cautionary Period Straw Poll I believe that DPV protocols developed by the PKIX working group [ought to | ought not] include support for a cautionary period. [I belive this because ...] If you feel the need to reply to the rationale posted by someone, please make that posting on the other thread. Please do not clutter the straw poll voting with a debate. Thanks for your assistance and cooperation, Russ From owner-ietf-pkix Tue Jan 15 11:05:04 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FJ54c06070 for ietf-pkix-bks; Tue, 15 Jan 2002 11:05:04 -0800 (PST) Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FJ53306066 for ; Tue, 15 Jan 2002 11:05:03 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 14:04:50 -0500 Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01> From: Santosh Chokhani To: "Housley, Russ" , ietf-pkix@imc.org Subject: RE: Cautionary Period Straw Poll Date: Tue, 15 Jan 2002 14:03:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DF7.56A74410" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19DF7.56A74410 Content-Type: text/plain I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. I believe this because I am. -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Tuesday, January 15, 2002 1:05 PM To: ietf-pkix@imc.org Subject: Cautionary Period Straw Poll From the previous thread (which seems to have died down), I think that everyone understands the Cautionary Period concept. I am trying to determine whether there is a constituency for Cautionary Period in DPV. I would like people that have an opinion to vote by sending a message to the list. The message should be structured as follows: To: ietf-pkix@imc.org Subject: RE: Cautionary Period Straw Poll I believe that DPV protocols developed by the PKIX working group [ought to | ought not] include support for a cautionary period. [I belive this because ...] If you feel the need to reply to the rationale posted by someone, please make that posting on the other thread. Please do not clutter the straw poll voting with a debate. Thanks for your assistance and cooperation, Russ ------_=_NextPart_001_01C19DF7.56A74410 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cautionary Period Straw Poll

I believe that DPV protocols developed by the PKIX = working group ought not include support for a cautionary period.

I believe this because I am.

-----Original Message-----
From: Housley, Russ [mailto:rhousley@rsasecurity.com= ]
Sent: Tuesday, January 15, 2002 1:05 PM
To: ietf-pkix@imc.org
Subject: Cautionary Period Straw Poll



 From the previous thread (which seems to have = died down), I think that
everyone understands the Cautionary Period = concept.  I am trying to
determine whether there is a constituency for = Cautionary Period in DPV.

I would like people that have an opinion to vote by = sending a message to
the list.  The message should be structured as = follows:

           = To: ietf-pkix@imc.org
           = Subject: RE: Cautionary Period Straw Poll

           I = believe that DPV protocols developed by the PKIX working group
           = [ought to | ought not] include support for a cautionary period.

           = [I belive this because ...]

If you feel the need to reply to the rationale posted = by  someone, please
make that posting on the other thread.  Please = do not clutter the straw
poll voting with a debate.

Thanks for your assistance and cooperation,
   Russ

------_=_NextPart_001_01C19DF7.56A74410-- From owner-ietf-pkix Tue Jan 15 11:06:51 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FJ6pP06110 for ietf-pkix-bks; Tue, 15 Jan 2002 11:06:51 -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 g0FJ6m306106 for ; Tue, 15 Jan 2002 11:06:48 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Jan 2002 19:06:25 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 OAA14974 for ; Tue, 15 Jan 2002 14:06:41 -0500 (EST) Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0FIWD417925 for ; Tue, 15 Jan 2002 13:32:13 -0500 (EST) Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:32:00 +0100 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH5DM9; Tue, 15 Jan 2002 13:31:56 -0500 Message-Id: <5.0.1.4.2.20020115130532.0308c5f8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 15 Jan 2002 13:07:04 -0500 To: ietf-pkix@imc.org From: "Housley, Russ" Subject: Re: Cautionary Period Straw Poll 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: I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. Russ From owner-ietf-pkix Tue Jan 15 13:02:15 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0FL2Fm09057 for ietf-pkix-bks; Tue, 15 Jan 2002 13:02:15 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FL2D309052 for ; Tue, 15 Jan 2002 13:02:13 -0800 (PST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Jan 2002 14:03:42 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Tue, 15 Jan 2002 14:03:35 -0700 From: "Tolga Acar" To: , Subject: Re: Question about encoding of RSA public Exponent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Jim, > >The public exponent is what confuses me - it doesn't seem to be in two's >complement form. No, it is not supposed to be. >The exponent value is 65537 >Hex is 010001 >Binary is 0000 0001 0000 0000 0000 >0001 which is correct. >I would have thought this would have to be encoded as >020400FEFFFF Nope. >Could you tell me what I'm overlooking in this case? Check with PKCS#1 downloadable from RSA, or it is also RFC 2437. - Tolga From owner-ietf-pkix Tue Jan 15 16:42:48 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G0gm413625 for ietf-pkix-bks; Tue, 15 Jan 2002 16:42:48 -0800 (PST) Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G0gl313620 for ; Tue, 15 Jan 2002 16:42:47 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:42:45 -0500 Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B544@SCYGMXS01> From: Santosh Chokhani To: ietf-pkix@imc.org Subject: OCSP RFC and OCSP version 2 ID Date: Tue, 15 Jan 2002 19:41:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19E26.8BBF23F0" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19E26.8BBF23F0 Content-Type: text/plain; charset="iso-8859-1" Folks: I am looking at both the RFC and version 2 ID for OCSP. Each document contains statements that seem contradictory to me. This relates to the meaning of nextUpdate field in the OCSP SingleResponse. Some places each document states that: "If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time" Other places each document states that: "Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate" Now, this appear contradictory to me since I do not interpret X.509 to imply that absence of nextUpdate field in CRL means near real-time CRL generation. I assume that the above is editorial oversight and the authors of both the RFC and ID mean that for OCSP, absence of nextUpdate means newer revocation information is available all the time. Raccoon Eyes Santosh Chokhani CygnaCom Solutions, Inc. 7927 Jones Branch Drive, Suite 100 West McLean, VA 22102 chokhani@cygnacom.com (703) 270-3520 (703) 848-0960 (fax) www.cygnacom.com Entrust CygnaCom ------_=_NextPart_001_01C19E26.8BBF23F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OCSP RFC and OCSP version 2 ID

Folks:

I am looking at both the RFC and = version 2 ID for OCSP.  Each document contains statements that = seem contradictory to me.  This relates to the meaning of = nextUpdate field in the OCSP SingleResponse.  Some places each = document states that:

"If nextUpdate is not set, the = responder is indicating that newer revocation information is available = all the time"

Other places each document states = that:

"Responses where the nextUpdate = value is not set are equivalent to a CRL with no time for = nextUpdate"

Now, this appear contradictory to me = since I do not interpret X.509 to imply that absence of nextUpdate = field in CRL means near real-time CRL generation.

I assume that the above is editorial = oversight and the authors of both the RFC and ID mean that for OCSP, = absence of nextUpdate means newer revocation information is available = all the time.


Raccoon Eyes

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 = West
McLean, VA 22102
chokhani@cygnacom.com
(703) 270-3520  (703) 848-0960 = (fax)
www.cygnacom.com

Entrust CygnaCom



------_=_NextPart_001_01C19E26.8BBF23F0-- From owner-ietf-pkix Tue Jan 15 18:28:18 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0G2SIx15525 for ietf-pkix-bks; Tue, 15 Jan 2002 18:28:18 -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 g0G2SG315521 for ; Tue, 15 Jan 2002 18:28:16 -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 PAA21760; Wed, 16 Jan 2002 15:28:13 +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 PAA385397; Wed, 16 Jan 2002 15:28:12 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 16 Jan 2002 15:28:12 +1300 (NZDT) Message-ID: <200201160228.PAA385397@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: chokhani@cygnacom.com, ietf-pkix@imc.org Subject: Re: OCSP RFC and OCSP version 2 ID Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Santosh Chokhani writes: >I am looking at both the RFC and version 2 ID for OCSP. Each document >contains statements that seem contradictory to me. This relates to the >meaning of nextUpdate field in the OCSP SingleResponse. Some places each >document states that: > >"If nextUpdate is not set, the responder is indicating that newer revocation >information is available all the time" > >Other places each document states that: > >"Responses where the nextUpdate value is not set are equivalent to a CRL >with no time for nextUpdate" > >Now, this appear contradictory to me since I do not interpret X.509 to imply >that absence of nextUpdate field in CRL means near real-time CRL generation. > >I assume that the above is editorial oversight and the authors of both the RFC >and ID mean that for OCSP, absence of nextUpdate means newer revocation >information is available all the time. There appears to be quite a bit of confusion over these fields among implementors because the RFC is so vague over how they're handled. I've seen responses where nextUpdate isn't set, where it's set to a value later than thisUpdate, and where it's set to a value equal to thisUpdate (which seems bogus since it auto-invalidates itself, but I haven't heard any complaints about this so I guess no-one notices). Other responders just copy the info across from the CRL, which leads to funny results if the CRL doesn't contain a notAfter (== nextUpdate), since the client is supposed to think that new info is always available even though it's coming from a CRL which may only be updated once a day (a truth-in-advertising problem). My solution has been to ignore the fields and let users decide, which I suspect means they just check whenever they feel like it, because I doubt anyone's going to try and handle all the weird special cases which crop up. I seem to remember something on the OpenSSL list where someone was grumbling about having to implement variable- configuration options to handle this as well, so others have run into this problem too. Peter. From owner-ietf-pkix Tue Jan 15 20:59:51 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0G4xpf17900 for ietf-pkix-bks; Tue, 15 Jan 2002 20:59:51 -0800 (PST) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G4xo317895 for ; Tue, 15 Jan 2002 20:59:50 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0GQ000B01LVPKU@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 15 Jan 2002 20:59:49 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0GQ000B7KLVOH2@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 15 Jan 2002 20:59:48 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 20:59:48 -0800 Content-return: allowed Date: Tue, 15 Jan 2002 20:59:45 -0800 From: Ambarish Malpani Subject: RE: Cautionary Period Straw Poll To: ietf-pkix@imc.org Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E028E4FEE@exchange.valicert.com> 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: I belive that DPV shouldn't include support for cautionary period. Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, January 15, 2002 10:07 AM > To: ietf-pkix@imc.org > Subject: Re: Cautionary Period Straw Poll > > > > I believe that DPV protocols developed by the PKIX working group > ought not include support for a cautionary period. > > Russ > From owner-ietf-pkix Tue Jan 15 23:43:24 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G7hOL27286 for ietf-pkix-bks; Tue, 15 Jan 2002 23:43:24 -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 g0G7hM327278 for ; Tue, 15 Jan 2002 23:43:22 -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 IAA27416; Wed, 16 Jan 2002 08:44:29 +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 IAA22136; Wed, 16 Jan 2002 08:42:47 +0100 Message-ID: <3C452EF9.1C64B460@bull.net> Date: Wed, 16 Jan 2002 08:42:49 +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: "Housley, Russ" CC: ietf-pkix@imc.org Subject: Re: Cautionary Period Straw Poll References: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> 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: Russ, Before lauching a straw poll, I would appreciate that you answer to the e-mail that I sent you on Monday 14. You have not refuted the arguments. That e-mail is copied below. If there is a straw poll, then it is between option 1) and option 2). Regards, Denis ========================================================================= Russ, (text deleted) > There are many application contexts where the concept of a cautionary > period is irrelevant. For example: TLS. The client will either accept the > server's certificate for establishment of the TLS-protected session, or it > will reject it. True, but the reverse sentence is also true: "There are application contexts where the concept of a cautionary period is relevant". > So, when does it matter? Non-repudiation of a high-value transaction. In > such a context, it is very important to know when a transaction take > place. The PKIX working group has done a lot of work on TSP to fill this > requirement. Non-repudiation is not the single security service where a cautionary period is relevant. It is also relevant for data origin authentication with integrity. > Let's assume that the constrained client wants to validate such a > transaction. The TSP timestamp provides the date/time of interest. It can > ask the DPV server if the signer's path was valid at the time that the > signature was generated. Since it is not possible to know when the signature was generated, an upper limit of that time is use instead: the date of the time-stamp applied over the digital signature or the date included in an audit record See the DPV requirements document at: http://www.imc.org/draft-ietf-pkix-dsv-req. The correct sentence is thus: "It can ask the DPV server if the signer's path was valid at the time that the time-stamp was applied over the digital signature". > In my view, the cautionary period only impacts the signature on the > transaction. Since a cautionary period cannot be applied in the context of a confidentiality service or an authentication service, the right wording would be : "the cautionary period only impacts the use of a certificate in the context of a non-repudiation service or a data-origin-authentication-with-integrity service". > The DPV server does not validate this signature. Has > adequate time passed since the signature was applied to ensure that recent > compromise of the end-entity private key has been reported? I submit that > this a signature validation question, not a certification path validation > question. The basic question is how clients can take advantage of a DPV server in the case where a cautionary period exists and in the context of a non-repudiation service or a data-origin-authentication-with-integrity service ? There are two options whether : 1) the cautionary period has to be known by the client (which is what your arguments mandate). 2) the cautionary period is known by the server (which is what my arguments mandate). In the context of a non repudiation service, clients must necessarilly know either the date of the time-stamp or the date of the audit record. In the context of a data-origin-authentication-with-integrity service, clients must necessarilly know the purported date of the digital signature. With option 1, clients must locally manage the cautionary period for each supported policy and locally compare it either with the date of the time-stamp or the date of the audit record, or the the purported date of the digital signature. This makes management actions more difficult (and makes also thin clients fater) since if that period changes, local tables need to be updated in each client application. With option 2, clients do not need to manage that information locally since it is part of the policy supported by the server. They simply need to send to the server either the date of the time-stamp or the date of the audit record, or the purported date of the digital signature. The goal of these protocols is to delegate as much as possible all the validation conditions to a server. The cautionary period does not make an exception. Denis =========================================================================== > From the previous thread (which seems to have died down), I think that > everyone understands the Cautionary Period concept. I am trying to > determine whether there is a constituency for Cautionary Period in DPV. > > I would like people that have an opinion to vote by sending a message to > the list. The message should be structured as follows: > > To: ietf-pkix@imc.org > Subject: RE: Cautionary Period Straw Poll > > I believe that DPV protocols developed by the PKIX working group > [ought to | ought not] include support for a cautionary period. > > [I belive this because ...] > > If you feel the need to reply to the rationale posted by someone, please > make that posting on the other thread. Please do not clutter the straw > poll voting with a debate. > > Thanks for your assistance and cooperation, > Russ From owner-ietf-pkix Wed Jan 16 00:05:16 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0G85Ge00320 for ietf-pkix-bks; Wed, 16 Jan 2002 00:05:16 -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 g0G85F300313 for ; Wed, 16 Jan 2002 00:05:15 -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 JAA22690; Wed, 16 Jan 2002 09:06:22 +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 JAA14706; Wed, 16 Jan 2002 09:04:40 +0100 Message-ID: <3C45341A.5DE23D0A@bull.net> Date: Wed, 16 Jan 2002 09:04:42 +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: Santosh Chokhani CC: ietf-pkix@imc.org Subject: Re: OCSP RFC and OCSP version 2 ID References: <8D7EC1912E25D411A32100D0B7695397E1B544@SCYGMXS01> 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: Santosh, > Folks: > > I am looking at both the RFC and version 2 ID for OCSP. Each document > contains statements that seem contradictory to me. This relates to the > meaning of nextUpdate field in the OCSP SingleResponse. Some places each > document states that: > > "If nextUpdate is not set, the responder is indicating that newer > revocation information is available all the time" > > Other places each document states that: > > "Responses where the nextUpdate value is not set are equivalent to a CRL > with no time for nextUpdate" > > Now, this appear contradictory to me since I do not interpret X.509 to > imply that absence of nextUpdate field in CRL means near real-time CRL > generation. > > I assume that the above is editorial oversight and the authors of both the > RFC and ID mean that for OCSP, absence of nextUpdate means newer > revocation information is available all the time. The OCSP RFC advertises thisUpdate and nextUpdate as: - thisUpdate: The time at which the status being indicated is known to be correct - nextUpdate: The time at or before which newer information will be available about the status of the certificate At the time the document was written, the main mechanism to feed the information to the OCSP server was to use CRLs. So it seems sensible to think that these fields are copied from a CRL. So I would say that "responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate" is the correct interpretation. Now the text could be clarified to say what this really means ! Section 5.1.2.5 (Next Update) from PKIX Part 1 does not say a word in that case. The general response is the "certificate policy will tell", in the same way that when some extensions are absent, e.g. the CRL Distribution points, the certificate policy will tell. So I would certainly not interpret it as: "If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time". Denis > Santosh Chokhani > CygnaCom Solutions, Inc. > 7927 Jones Branch Drive, Suite 100 West > McLean, VA 22102 > chokhani@cygnacom.com > (703) 270-3520 (703) 848-0960 (fax) > www.cygnacom.com > > Entrust CygnaCom From owner-ietf-pkix Wed Jan 16 00:31:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G8Vls04000 for ietf-pkix-bks; Wed, 16 Jan 2002 00:31:47 -0800 (PST) Received: from webmail.wipro.co.in (host130-22.wipro.net.in [202.177.130.22] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G8Va303966 for ; Wed, 16 Jan 2002 00:31:37 -0800 (PST) Received: from galaxy.wipro.co.in (GALAXY [10.100.8.6]) by webmail.wipro.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DADWY83P; Wed, 16 Jan 2002 13:52:49 +0530 Received: by galaxy.wipro.co.in with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 13:56:53 +0530 Message-ID: <52200AE97D18D511B6C1009027E036911BF33A@jupiter.wipro.co.in> From: "Sanjeev Shukla (SSD-DELRO-ESCR)" To: ietf-pkix@imc.org Subject: Date: Wed, 16 Jan 2002 14:03:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I believe that DPV protocols should not include support for a cautionary period. Sanjeev Shukla Consultant Wipro Limited 2nd Floor, Thapar House, 124 Janpath, New Delhi-110 001. India E mail:sanjeevshukla@wipro.co.in > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, January 15, 2002 10:07 AM > To: ietf-pkix@imc.org > Subject: Re: Cautionary Period Straw Poll > > > > I believe that DPV protocols developed by the PKIX working group > ought not include support for a cautionary period. > > Russ Disclaimer Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.co.in From owner-ietf-pkix Wed Jan 16 00:25:27 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G8PR402843 for ietf-pkix-bks; Wed, 16 Jan 2002 00:25:27 -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 g0G8PQ302836 for ; Wed, 16 Jan 2002 00:25:26 -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 JAA24810; Wed, 16 Jan 2002 09:26:30 +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 JAA14758; Wed, 16 Jan 2002 09:24:52 +0100 Message-ID: <3C4538D6.8A81358A@bull.net> Date: Wed, 16 Jan 2002 09:24:54 +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: Santosh Chokhani CC: "Housley, Russ" , ietf-pkix@imc.org Subject: Re: Cautionary Period Straw Poll References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01> 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: Santosh, > I believe that DPV protocols developed by the PKIX working group ought not > include support for a cautionary period. > I believe this because I am. Quite an interresting technical argument. :-) Denis > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, January 15, 2002 1:05 PM > To: ietf-pkix@imc.org > Subject: Cautionary Period Straw Poll > > From the previous thread (which seems to have died down), I think that > everyone understands the Cautionary Period concept. I am trying to > determine whether there is a constituency for Cautionary Period in DPV. > > I would like people that have an opinion to vote by sending a message to > the list. The message should be structured as follows: > > To: ietf-pkix@imc.org > Subject: RE: Cautionary Period Straw Poll > > I believe that DPV protocols developed by the PKIX working > group > [ought to | ought not] include support for a cautionary period. > > [I belive this because ...] > > If you feel the need to reply to the rationale posted by someone, please > make that posting on the other thread. Please do not clutter the straw > poll voting with a debate. > > Thanks for your assistance and cooperation, > Russ From owner-ietf-pkix Wed Jan 16 01:06:21 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0G96LW07399 for ietf-pkix-bks; Wed, 16 Jan 2002 01:06:21 -0800 (PST) Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G96I307388 for ; Wed, 16 Jan 2002 01:06:19 -0800 (PST) Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id KAA22225; Wed, 16 Jan 2002 10:06:19 +0100 Date: Wed, 16 Jan 2002 10:06:19 +0100 From: Alfonso De Gregorio To: Denis Pinkas Cc: Tom Gindin , "Housley, Russ" , ietf-pkix@imc.org Subject: Re: Cautionary Period Message-ID: <20020116100619.A22065@server.speedcom.it> Reply-To: agregorio@acm.org References: <3C446864.30B43CEC@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3C446864.30B43CEC@bull.net> User-Agent: mymua Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: On Tue, Jan 15, 2002 at 06:35:32PM +0100, Denis Pinkas wrote: I agree with Denis point of view. In certain contexts (eg. data origin authentication with integrity) some clients would still like to observe a cautionary period and use DPV. Performing the cautionary-period observation at server-side makes the life easier to clients and makes the set of target execution environments larger (since let them to be unconscious of the current-time). Consider cautionary-periods a requirement for DPV does not make necessarily the protocol more complex. Validation policies MAY support cautionary periods. Finally... we should delegate as much as possible all the validation conditions to DPV servers. alfonso > > You are correct that there are other services than NR for which > > cautionary period is useful. However, don't they all involve the > > validation of signed data (and data to be kept for a considerable time, > > Is a week-end period a "considerable time" ? I do not think so. > An e-mail sent on the friday may only be opened on the monday. > Applying a cautionary period increases the confidence and reduces the risk. > > > at that)? If they do, then cautionary period should go into DSV. > > Everybody agrees that a cautionary period certainly applies to DSV. > > However, some thin clients would still like to use DPV to verify digital > signatures in particular in the context of data origin authentication with > integrity. I do not think it would be appropriate to say that it is not > possible and that the cautionary period, when it exists, shall only be > applied *locally* by the client. > > Denis From owner-ietf-pkix Wed Jan 16 01:07:55 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0G97tn07644 for ietf-pkix-bks; Wed, 16 Jan 2002 01:07:55 -0800 (PST) Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G97r307636 for ; Wed, 16 Jan 2002 01:07:53 -0800 (PST) Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id KAA22234; Wed, 16 Jan 2002 10:08:48 +0100 Date: Wed, 16 Jan 2002 10:08:48 +0100 From: Alfonso De Gregorio To: "Housley, Russ" Cc: ietf-pkix@imc.org Subject: Re: Cautionary Period Straw Poll Message-ID: <20020116100848.B22065@server.speedcom.it> Reply-To: agregorio@acm.org References: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> User-Agent: mymua Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I believe that DPV protocols developed by the PKIX working group ought to include support for a cautionary period. alfonso On Tue, Jan 15, 2002 at 01:05:22PM -0500, Housley, Russ wrote: > > From the previous thread (which seems to have died down), I think that > everyone understands the Cautionary Period concept. I am trying to > determine whether there is a constituency for Cautionary Period in DPV. > > I would like people that have an opinion to vote by sending a message to > the list. The message should be structured as follows: > > To: ietf-pkix@imc.org > Subject: RE: Cautionary Period Straw Poll > > I believe that DPV protocols developed by the PKIX working group > [ought to | ought not] include support for a cautionary period. > > [I belive this because ...] > > If you feel the need to reply to the rationale posted by someone, please > make that posting on the other thread. Please do not clutter the straw > poll voting with a debate. > > Thanks for your assistance and cooperation, > Russ From owner-ietf-pkix Wed Jan 16 02:49:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GAnhN19292 for ietf-pkix-bks; Wed, 16 Jan 2002 02:49:43 -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 g0GAng319288 for ; Wed, 16 Jan 2002 02:49:42 -0800 (PST) Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 98D9D6787; Wed, 16 Jan 2002 11:49: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.2655.55) id ZKPQV2N7; Wed, 16 Jan 2002 11:49:35 +0100 Message-ID: <3C455B2F.8833F787@secude.com> Date: Wed, 16 Jan 2002 11:51:27 +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: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> <3C42B261.A9E97B0D@secude.com> <3C42C767.605157D@bull.net> <3C42F301.D5D3DEC@secude.com> <3C431487.F188B469@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: Yes, thanks for the pointer. I found the ASN.1 definitions there. One more question turned up: Is DPV restricted to X.509 public key certificates or is it possible to use it for X.509 attribute certificates as well? - Petra Denis Pinkas schrieb: > Petra, > > Please take a look at RFC 3126, where many of the ASN.1 structures were > imported from and are thus defined there. This should answer all your > questions. > > Regards, > > Denis > > > Denis, > > > > may I still ask some questions concerning the document "Delegated > > Path Validation and Delegated Path Discovery Protocols" ? > > > > > PathValues :: = SEQUENCE { > > > certificateValues CertificateValues, > > > revocationValues RevocationValues } > > > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues" > > and "RevocationValues" but I couldn't find these definitions. > > > > By the way, you should move this definition of "PathValues" from > > the chapter "5.2.1. Request" to the chapter "5.2.2. Response Syntax" > > where it is used. > > > > Another ASN.1 question: > > > > > UsefulRevoc ::= CHOICE { > > > certificateRevocationLists CertificateRevocationLists, > > > completeRevocationRefs CompleteRevocationRefs } > > > > > A DPV request may contain useful revocation information provided > > by the client. Maybe it's because I don't know the element > > "CompleteRevocationRefs" but where do I store OCSP answers? > > > > Could you please send the definition of "CompleteRevocationRefs" > > and "completeCertificateRefs"? I guess they are imported from [ES-F], > > "Electronic Signature Formats for long term electronic signatures", aren't > > they? > > > > > CertOrCertRef ::= CHOICE { > > > certificate [1] Certificate, > > > certRef [2] OtherCertID } > > > > > I'm also missing the definition of OtherCertID used in a DPV and DPD > > request. > > > > Thanks, Petra > > > > Denis Pinkas schrieb: > > > > > Petra, > > > > > > > Denis, > > > > > > > is there also a new version of the document "Delegated Path > > > > Validation and Delegated Path Discovery Protocols" > > > > > > Not at this time. Currently we need first to agree on the DPV / DPD > > > requirements, then we will discuss the solutions to these requirements. > > > > > > The so-called "Delegated Path Validation and Delegated Path Discovery > > > Protocols" document could be a candidate to fulfill these requirements. > > > It is too early to say and this will only be discussed once the > > > requirements > > > document is adopted. > > > > > > > or just a new requirement document? > > > > > > Correct. It is a new document for both the DPV and DPD requirements. > > > > > > There is also a companion document for the DSV requirements. > > > We will only discuss the DSV requirements document in detail when > > > the DPV / DPD requirements document has completed the WG last call. > > > > > > Denis From owner-ietf-pkix Wed Jan 16 03:37:30 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GBbUs22705 for ietf-pkix-bks; Wed, 16 Jan 2002 03:37:30 -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 g0GBbT322701 for ; Wed, 16 Jan 2002 03:37:29 -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 MAA25230; Wed, 16 Jan 2002 12:38:37 +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 MAA08902; Wed, 16 Jan 2002 12:36:56 +0100 Message-ID: <3C4565DA.4EEC2327@bull.net> Date: Wed, 16 Jan 2002 12:36:58 +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: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt References: <200201111356.IAA14856@ietf.org> <3C42B261.A9E97B0D@secude.com> <3C42C767.605157D@bull.net> <3C42F301.D5D3DEC@secude.com> <3C431487.F188B469@bull.net> <3C455B2F.8833F787@secude.com> 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: Petra, > Yes, thanks for the pointer. I found the ASN.1 definitions there. > > One more question turned up: > Is DPV restricted to X.509 public key certificates or is it possible > to use it for X.509 attribute certificates as well? Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft have been specifically written to support PKIX public key certificates. At the last IETF meeting a question has been raised to the audience: Who, in the room, has implemented Attribute Certificates ? No hand showed up. So it seems that there is no urgence to support PKIX attribute certificates. However, maybe by making some changes, PKIX attribute certificates could be supported, but this is an exercise that I have not undertaken. The basic question is thus whether to include the support of attribute certificates in the current DPV-DPD requirement draft. Unless you, or someone else, can rapidly provide arguments and demonstrate that it will not delay the support of PKIX public key certificates, I would rather think that it should not be included at this time. Regards, Denis > - Petra > > Denis Pinkas schrieb: > > > Petra, > > > > Please take a look at RFC 3126, where many of the ASN.1 structures were > > imported from and are thus defined there. This should answer all your > > questions. > > > > Regards, > > > > Denis > > > > > Denis, > > > > > > may I still ask some questions concerning the document "Delegated > > > Path Validation and Delegated Path Discovery Protocols" ? > > > > > > > PathValues :: = SEQUENCE { > > > > certificateValues CertificateValues, > > > > revocationValues RevocationValues } > > > > > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues" > > > and "RevocationValues" but I couldn't find these definitions. > > > > > > By the way, you should move this definition of "PathValues" from > > > the chapter "5.2.1. Request" to the chapter "5.2.2. Response Syntax" > > > where it is used. > > > > > > Another ASN.1 question: > > > > > > > UsefulRevoc ::= CHOICE { > > > > certificateRevocationLists CertificateRevocationLists, > > > > completeRevocationRefs CompleteRevocationRefs } > > > > > > > A DPV request may contain useful revocation information provided > > > by the client. Maybe it's because I don't know the element > > > "CompleteRevocationRefs" but where do I store OCSP answers? > > > > > > Could you please send the definition of "CompleteRevocationRefs" > > > and "completeCertificateRefs"? I guess they are imported from [ES-F], > > > "Electronic Signature Formats for long term electronic signatures", aren't > > > they? > > > > > > > CertOrCertRef ::= CHOICE { > > > > certificate [1] Certificate, > > > > certRef [2] OtherCertID } > > > > > > > I'm also missing the definition of OtherCertID used in a DPV and DPD > > > request. > > > > > > Thanks, Petra > > > > > > Denis Pinkas schrieb: > > > > > > > Petra, > > > > > > > > > Denis, > > > > > > > > > is there also a new version of the document "Delegated Path > > > > > Validation and Delegated Path Discovery Protocols" > > > > > > > > Not at this time. Currently we need first to agree on the DPV / DPD > > > > requirements, then we will discuss the solutions to these requirements. > > > > > > > > The so-called "Delegated Path Validation and Delegated Path Discovery > > > > Protocols" document could be a candidate to fulfill these requirements. > > > > It is too early to say and this will only be discussed once the > > > > requirements > > > > document is adopted. > > > > > > > > > or just a new requirement document? > > > > > > > > Correct. It is a new document for both the DPV and DPD requirements. > > > > > > > > There is also a companion document for the DSV requirements. > > > > We will only discuss the DSV requirements document in detail when > > > > the DPV / DPD requirements document has completed the WG last call. > > > > > > > > Denis From owner-ietf-pkix Wed Jan 16 06:28:04 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GES4203635 for ietf-pkix-bks; Wed, 16 Jan 2002 06:28:04 -0800 (PST) Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GERj303628 for ; Wed, 16 Jan 2002 06:27:45 -0800 (PST) Received: from iaik.tu-graz.ac.at (iaik.tu-graz.ac.at [129.27.152.30]) by mailrelay.tugraz.at (8.12.1/8.12.1) with ESMTP id g0GERcUQ029938; Wed, 16 Jan 2002 15:27:38 +0100 (MET) Received: from plato [129.27.152.123] by iaik.tu-graz.ac.at (SMTPD32-6.06) id ADC665190154; Wed, 16 Jan 2002 15:27:18 +0100 Received: from plato.iaik.at [127.0.0.1] by plato (IAIK S/MIME Mapper 2.01 18/May/2001); Wed, 16 Jan 2002 15:32:27 +0100 From: "Stefan Kraxberger" To: "Denis Pinkas" , "Todd Glassey" , "Tho" , "Stephen Kent" , "Peter Gutmann" , "Peter Sylvester" , "Joe Morgan" , "Cristian Marinescu" , "Bianca Taglialagamba" , "A. Caccia" Cc: "PKIX" Subject: IAIK TSA Date: Wed, 16 Jan 2002 15:32:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.D1DB3296--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.D1DB3296-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Now our TSA is online again.=20 Currently only the socket based service is available.=20 =20 The address is bias.iaik.at at port 318. =20 Regards,=20 Stefan=20 ----IAIK.SMIME.MAPPER.D1DB3296-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIgqTCCBNYwggO+oAMCAQICFQC3HWS4/i03mbnh7A3pagLKv3pQqTANBgkqhkiG 9w0BAQUFADCBxDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE CxMYSUFJSyBFdXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9Q S0kgVFUtR1JBWiBTSUcwHhcNMDExMTI5MTMyNzE2WhcNMDIxMjMwMjIwMDAwWjCB mjELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEaMBgGA1UEAxMRU3RlZmFu IEtyYXhiZXJnZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIfTFg1Y/7xJ Z3LWZc9hycGVAHTAWpyTIBUeEZKhx4x213MRRx9SFTzGbFuro5vGLIgLYy/GROKS N5T4ADhjB5+OTFJ3VgMSLROOhQ4TBDWB+5PXNqLHJ5NxL/40Vz/mG9qk5qT+vPWe 4U6RfmD+zF9nR6BUxYJ3y2b0FcrJvEqtAgMBAAGjggFpMIIBZTAMBgNVHRMBAf8E AjAAMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBR4tVWhM72DJX/q8+eMt6Of lXOqezBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBAjA5MDcGCCsGAQUFBwIBFito dHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjIvMEwGA1Ud HwRFMEMwQaA/oD2GO2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQv Y3JsL2lhaWtfZXVyb3BraV9zaWcuY3JsMBEGCWCGSAGG+EIBAQQEAwIAIDAoBglg hkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAkBgNVHREEHTAb gRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQWBBS3HWS4/i03mbnh 7A3pagHgRzEPEDANBgkqhkiG9w0BAQUFAAOCAQEAQxdjAsPNy6A3S6sj3DxWkfCS 6D2YRrUZwsM1fwe4Y08Du5jfIwWZ0+HJCAfysGWUm4wmApCxD9IhMzaufkfqgJMM cXkdoXX75V839/FbrzXwMY+Ve6ba7WrNZvEUcl+/Xyg7UaAl/D7+QODLHgacuFVH 7FiFnQuiC5JHAMxMDKcrKSw7fJ75zTspRsRM2RXTu3HAoLe0MNxeNmFsvynTtb8Y zSz5afUcvWFFDOe2Uf7B34sc+MszUz26p8xat8DGqdp11kI7IdZDMD83BRZlYJ47 sJMVQiglalwAZLZLkOp1dJOa7/Ob086p3elkDD6TVwTqeIEqEMX/ZJZtAsPZVzCC BTwwggQkoAMCAQICFHi1VaEzvYMlf+rz54y3pIMcl/owMA0GCSqGSIb3DQEBBQUA MIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcGA1UECRMQSW5mZmVs ZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xP R1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFBy b2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQDExhJQUlLIEV1cm9Q S0kgSW50cmFuZXQgQ0EwHhcNMDAxMjE5MTEyMTQ3WhcNMDIxMjMwMjI1OTMwWjCB xDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UECxMYSUFJSyBF dXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgVFUtR1JB WiBTSUcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDxWjtQORZimthv kSAAJlIL97tgPeJ8+151iGCyd44WFAyjHsP9oQrZHxazVAB+o8clYdPpp/ECognU 41o40iafdgkNIfsjyFMm3VvcWNx+F4vKYTHoLQascxRJUULgub+B4k4pb9A4URQn xkrMriQlISoFXeEY1l2Mv4DlXHF3qOEMiLW5B1vmZZaEpNvH/me8fuvJYLi9FWA+ Ojk/UybbrGybkeJY3RAq+FImnWkaB9BAoAhdROR+GXU8YvqZTzqUndKog1KccBKa FTBKwSz9RxOVPFORs1VLGItlnGRCn25uOiDTDfrU2D4D9cyFEVU+Qd55RzD6PfgP 8BbeUyTxAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2abEq0uxAz0jBUBgNVHSAE TTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIBFitodHRwOi8vZXVyb3Br aS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQvY3JsL2lhaWtfZXVy b3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1UdDgQWBBR4tVWhM72DJX/q 8+eMt6OflXOqezANBgkqhkiG9w0BAQUFAAOCAQEAscTGRuY2BJizRRfug1JU1qha LVOjZvYPOikXleQuPBPXFSoT9jwbzDkyN76QMnondlgf0F1Gr+w4LqljFKAdjqFG SXJxAzGjMFbjTjyv7mit0Ppk7wKohXM/c8ThDCEBnnAYcTgg504BtJhBmN0ThyL6 tAXYfRFqHsgn1rj58bS+6lAa6n9iepn/yznhnFWr24imSVvef8nbI2GwphBAhNXh +Jq+BWR1pr5uUJ9ilzL44elcZ+Omh4lsILiUf6YR1xR9+d3G4VQMMOmpfgf0GJVK NKcelVlK4PW/0VgvDxoyQQFVE2hiLd5r/jUzT4zlLy+5hk3FnxSUgnl14w/u3DCC BLMwggOboAMCAQICFQCEWAP+T9cNWn701+2abEuYPjyavTANBgkqhkiG9w0BAQUF ADBSMQswCQYDVQQGEwJBVDEQMA4GA1UEChMHRXVyb1BLSTExMC8GA1UEAxMoRXVy b1BLSSBBdXN0cmlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDEyMTgx NjUyMzFaFw0wMjEyMzAyMjU5MzBaMIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxME R3JhejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgSW50cmFuZXQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDPwrEj1RtzPWRZUGptWv2/KsgPQ0FyMHHYemhn /+QjUv51aD9fmcqqUU/CgroJE6sLtN6cZoQ91gnxIS/Gw95PNhUX6jZfN4PF5K/G Xz3ZUx/bcvcm4tjFGG12jxWT4IN9d3oT5SMMjh1Aw0BE35yySnlqBcfWHR7gtBps dAovw1Txy8Bt8vmBrhe27dY0d3bJitULO1CG19G0Q374rnJ/CY9ZEHsz0498Ej5+ eFnefSEilJ7kQNDNU2zCx7xuu0jdu0yrb5Y1+RBdgJHCoMldUbOA2HkNOz9YLyiY WPWRxT9fcPgXv9jSYu+t+DB0MMPz53ZcYILVsopsjhKduVO5AgMBAAGjggEEMIIB ADAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBQA emdURVCCrBm2toURUbtpOdgt1DBWBgNVHSAETzBNMEsGDCsGAQQBlRIBAgEBATA7 MDkGCCsGAQUFBwIBFi1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2V1cm9wa2kt YXQvY3BzLzEuMS8wRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2V1cm9wa2kuaWFp ay5hdC9jYS9ldXJvcGtpLWF0L2NybC9hdXN0cmlhLmNybDAdBgNVHQ4EFgQUhFgD /k/XDVp+9NftmmxKtLsQM9IwDQYJKoZIhvcNAQEFBQADggEBAC8BA5jJSByaJAeD xiEW4O8mJJdSsuO/KyoEJVjcAyyMx9lJdHNtgwabhFHR2cUZz++vKkJFpmA+A7jg jRO5IwQxiMTordze8X7rxmBlZvizFJfxUwalTAUbJ9iaLjJza42qTwjRRPSEji4b 9hcg+6PpK4pOdZ++SrIrE1qIvRqx3fFqEo8LHkkR8ZHKB/tT4GKQck/tUfeuotfQ I/XlprqctmgzmjRC0giMEurV2Ogf6kxz9BzmibwGBtCqG0GLN5XKCr6fNBAD3W+X t0FoujZfZlJqK3bt6re712rdZnztVlOaCc6gSB9WY7ZrNFhAm9+a2HzlTc7ZS+eP jC8yLW4wggRQMIIDOKADAgECAgEJMA0GCSqGSIb3DQEBBAUAMEExEDAOBgNVBAoT B0V1cm9QS0kxLTArBgNVBAMTJEV1cm9QS0kgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0wMDExMjMxNDI0NDVaFw0wMjEyMzExMjAwMDBaMFIxCzAJBgNV BAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1c3Ry aWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAoE5gWK44kT3O3Yenp0GT6+gkypmIAlhqYAcmokavl3WaQ4Bh BlAv4ORtBF/hVObG1ugPCep7cTNyoXZ+sNIbmlLzBxzrRpT4nYQIEu3IXR108c6A PycH+9vbYIUQrsCKx8Qs/csU5rdOxc15pHsZLJiiCYATB0GWyrcbVcoNgAj6crv7 Lx37SlENgMAssOoG4E3/2wrCQ2n/QiqBEosscpnEqQs6ABvdQiLKSpfVQJA77l9u jQ1C/ugtlYwAr5GrtSOhOTYvKB4tuVleqlHFzJoA6XaWQRpD4Oy4ymF0+5IAe9q+ lOQ6U57rWIZ0MMr8xAmf7VZtmk0KJYCkAl3DPwIDAQABo4IBQDCCATwwTAYJYIZI AYb4QgENBD8WPUlzc3VlZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9w a2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDov L3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMA8GA1UdEwEB/wQF MAMBAf8wTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0 dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAOBgNVHQ8BAf8E BAMCAf4wHQYDVR0OBBYEFAB6Z1RFUIKsGba2hRFRu2k52C3UMB8GA1UdIwQYMBaA FIzci7GlSpDnTohzGDyd1V5+5LLNMA0GCSqGSIb3DQEBBAUAA4IBAQD0VfvB2KWA /FyENfhXDK7/YQwRxdAJj/3VzpdvUPb9mHW9O1kry3ZeM9IfcYqbFPdP9ZvW/g2m WQI9k4vMKDtePnzQuy+ZUuvxuKlJ7taWAAHkiXTBbJoscHetWVlIINuPYCQF33DT d5otjcOxsE+U9xjqP5tCLMzQEmnmTaUdZYWZFIjfKzoLC2JEaeVjDUQrYYwL6OUY P6aWoML1gqUP2PFzRKQK/EMSjRQzTU9ZZLVvc+FS797ki6f8zRxPGqheV4EyjFXR bY03/4fjcZ5pwictxM97tFYmmlkmWmkEvI+7ToPZ/WtPyqXciKJ9ZT/OJWWWzfXg iz5ECXNBlO0DMIIDYDCCAkigAwIBAgIBADANBgkqhkiG9w0BAQQFADBBMRAwDgYD VQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwHhcNOTkxMjI5MTczMDM5WhcNMTAxMjMxMTIwMDAwWjBBMRAw DgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD/ L/zLh4UggkIiJA2Jmuwd6/TLOoToZz3Dr0FoCgehip+ZNrX1ehBw0esCK6Z18SfD OeyDB+ia3qWaltedQVttLUQnVPdXmzubIVapWFoHm1u3oLhBgSp1mHBmAsKmGvHV /IYF4t709tUQlpeZgjIzpbjzN799Xoa2X2yJqGGBADzHKiJn5p80LsMnx3VR/UyI XZJEq611UlADfJH1qhwUzNa0F80j0tk7/paLhnWrZDsfZNGkAugQLBDUi+nBKUu4 FicpfYL7HGX4fRmtg+oLuQ1vHlYe2YVs+UGI47e7jd4Yf1vbjinQ0OUrx2nx8z+x o47lgXwMbEJ7VwrECjS3AgMBAAGjYzBhMB8GA1UdIwQYMBaAFIzci7GlSpDnTohz GDyd1V5+5LLNMB0GA1UdDgQWBBSM3IuxpUqQ506Icxg8ndVefuSyzTAOBgNVHQ8B Af8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAW2j/ nnW9QhtCe1iQdV9KFy9rnOpKH43tHFjuUBlgpgvNv01/rXMXLn/W81nuLTmZwdhY cjldUZZR6WUGLtArOLQaUkTQMHjc/EkU/s0v8MuWNg5vhC3ZsFFNVtfR8iWa2a+g A4uBH17cXd6PuzqD0HMFA75P32kes3xblFWZ5qSYGQvy4aWoT/FDsbeJG/Upp8Fb Z2Z0pSqfi9cAWGqzRYlT0dgu8Z2RFwwd/vPvVpQldB1ScRkfpL6PCLvmmfMRHq8Z g0JMcqmIXYYg0PcPdJ+ECikSYd/7G50/uIfJDDZEOIkmpXVn3cQmcMDRauhvwsoR 6B2lCX/cEI0PEnMBaDCCBNkwggPBoAMCAQICFD9EDnR1EdQ3xFRjSEwGBggogBmx MA0GCSqGSIb3DQEBBQUAMIHGMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0ExIzAhBgNVBAMTGklB SUsgRXVyb1BLSSBUVS1HUkFaIENSWVBUMB4XDTAxMTEyOTEzMjUwMVoXDTAyMTIz MDIyMDAwMFowgZoxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGjAYBgNV BAMTEVN0ZWZhbiBLcmF4YmVyZ2VyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDEVxohomk0KckxKIduxV98fR68UbG7oAhiZas5KwNmw/eIWTWowzjNm7wEoIse tBq6fVNKHBIhIn47XqTk+N76hjoADWnNn1QAVztCxXDNZVfc7+1vUioJu1QYcWPZ NyAJskap8JOS9AKje5Hdnmnd5tWPxCigbo8QiEtLIcD8wQIDAQABo4IBazCCAWcw DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBDAwHwYDVR0jBBgwFoAUmikZ1hee wVHfzGeDobfkvw+4Qx0wVAYDVR0gBE0wSzBJBgwrBgEEAZUSAQICAQIwOTA3Bggr BgEFBQcCARYraHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcHMv MS4yLzBOBgNVHR8ERzBFMEOgQaA/hj1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2Nh L2ludHJhbmV0L2NybC9pYWlrX2V1cm9wa2lfY3J5cHQuY3JsMBEGCWCGSAGG+EIB AQQEAwIAIDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5F VDAkBgNVHREEHTAbgRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQW BBQ/RA50dRHUN8RUY0hMBgUdsDjWPjANBgkqhkiG9w0BAQUFAAOCAQEACK/LT4Q5 JodHhwc98Yuyv7wZfymxAOFyRJsO1sseOriRFPpp9WAjZORNRUTYRPMuhd9RS3BR /jTn79AlsHevONt06xO4eatRoU01qZXQjoDZBOYsPIeId2Egs/7IWqC4iY5RBS8X 6Y3Tne/OGhzMTNiiRh0J573yPNqTUO0JK6yeYq0nNb2W4An6z+VPOW2mDEJcEj3H /PjbR/sRbhi2DjkiN4JkjRDt4aRvT3yfnlqefoQqD4kakmdllaA98VasPjS9RLjh rXKNixXlu+zzIbs0tRsN+ewLsVAUgSWl6SFOgSzPa5vTXurFbLaLRkrus6k+J19J slSUkAIajSKpmTCCBT8wggQnoAMCAQICFQCaKRnWF57BUd/MZ4Oht+WilucS8TAN BgkqhkiG9w0BAQUFADCByzELMAkGA1UEBhMCQVQxDTALBgNVBAcTBEdyYXoxGTAX BgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE AxMYSUFJSyBFdXJvUEtJIEludHJhbmV0IENBMB4XDTAwMTIxOTExMzMxMVoXDTAy MTIzMDIyNTkzMFowgcYxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZF UlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxp ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxITAf BgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBDQTEjMCEGA1UEAxMaSUFJSyBF dXJvUEtJIFRVLUdSQVogQ1JZUFQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDWIkt24ac2iD1RZW0BzsolEcM7k6C5Pb8EHxVojWsjJsscBB32XS9H2h2/ XmjVOLtCPoNiEaqm8WrqFky29IdoktkLdV6bvW4gN32k17mvPUNCPmqO78idaqXC m//ocXRMwUHpMCv1NN+5KUMJ18BDchltI/Zj1btYA7cZy4Ax01k6Z2zHUJkoAc7/ +x95o8Cm/1D9JxxZ5o6tHdiAYgyUjCA6Q3L0DmNQgLPOMWU5ZfcANDWfMTAH71c3 oRJaKIum3yCKzThyX24X7iSU/SI1mA2uJnOerEweuLNhmu5kJzH+079B2Jyscr92 1fzcz6KEEjEoEtnF8VSUvhFWxb2bAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAG AQH/AgEAMA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2a bEq0uxAz0jBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIB FitodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgG A1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFu ZXQvY3JsL2lhaWtfZXVyb3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1Ud DgQWBBSaKRnWF57BUd/MZ4Oht+S/D7hDHTANBgkqhkiG9w0BAQUFAAOCAQEAQJx9 PjiaQ085JR96Xq1xrjg5YYZJZzOm39jim/QXlHhc2i9OOHl17kKql9mHUUHbDM+C eBz8oN7nkPXK0W3p9jrQbGij6v3MSPztnfkwbZl7askTeeyrmI3rC/jR6mWTL/AC Cxn7btTc8U/9IJIFv1OQM+I9o1L68CzxsbddTSgGn6hjzZO6TnkMW+I8aWQe+uOj tthe/1Erhl9YGSHv8EkqLOWfJroKc9mmKs2iYNcEbT8VFg7K5+/cCqqpp68vFLsY Jtmlyq7vU60XNFMSaA5mgzc4wrB8ObMO98roBRJsMfKSAirSXugiKkRRyoPdC+rx siaVKay2Xd7GDSu5pDGCAy0wggMpAgEBMIHeMIHEMQswCQYDVQQGEwJBVDEmMCQG A1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPklu c2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENv bW11bmljYXRpb25zMSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0Ex ITAfBgNVBAMTGElBSUsgRXVyb1BLSSBUVS1HUkFaIFNJRwIVALcdZLj+LTeZueHs DelqAsq/elCpMAkGBSsOAwIaBQCgggGkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDExNjE0MzIyN1owIwYJKoZIhvcNAQkEMRYE FK/KyRS/+J8HwQ9ARYuNyvb/xDSOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIHMIHwBgkrBgEEAYI3EAQxgeIwgd8wgcYxCzAJBgNVBAYTAkFUMSYw JAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+ SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg Q29tbXVuaWNhdGlvbnMxITAfBgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBD QTEjMCEGA1UEAxMaSUFJSyBFdXJvUEtJIFRVLUdSQVogQ1JZUFQCFD9EDnR1EdQ3 xFRjSEwGBggogBmxMA0GCSqGSIb3DQEBAQUABIGAAwNLnU9aW4oIulrYu+1fx1f1 PbK0gQDDvQT6zeY/C7EVzENwhTJI8Ls+1Rqr9WMBih2mdSB/02bbmLdleLtjJkvB W4yAUUu6OjRtOeYKJ3N5zDP3NTW57sQbVdD0ckg8jz8ZWLVbEs40qoQvYKxFeYfH 133+gFk+JzOC3JNz8+IAAAAAAAA= ----IAIK.SMIME.MAPPER.D1DB3296---- From owner-ietf-pkix Wed Jan 16 07:37:00 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GFb0305532 for ietf-pkix-bks; Wed, 16 Jan 2002 07:37:00 -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 g0GFar305528 for ; Wed, 16 Jan 2002 07:36:53 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 15:36:29 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 KAA27191 for ; Wed, 16 Jan 2002 10:36:54 -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 g0GEPtN28732 for ; Wed, 16 Jan 2002 09:25:55 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 09:25:54 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.27]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH532Z; Wed, 16 Jan 2002 09:25:49 -0500 Message-ID: <5.0.1.4.2.20020116090203.01d98800@exna07.securitydynamics.com> From: "Housley, Russ" To: Denis Pinkas Cc: ietf-pkix@imc.org Subject: Re: Cautionary Period Date: Wed, 16 Jan 2002 09:24:53 -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: Denis: > > There are many application contexts where the concept of a cautionary > > period is irrelevant. For example: TLS. The client will either accept the > > server's certificate for establishment of the TLS-protected session, or it > > will reject it. > >True, but the reverse sentence is also true: "There are application contexts >where the concept of a cautionary period is relevant". > > > So, when does it matter? Non-repudiation of a high-value transaction. In > > such a context, it is very important to know when a transaction take > > place. The PKIX working group has done a lot of work on TSP to fill this > > requirement. > >Non-repudiation is not the single security service where a cautionary period >is relevant. It is also relevant for data origin authentication with >integrity. It does not matter for key management (key transport or key agreement). It sometimes matters for signatures. It does not when actions are taken immediately after the signature validation, then the signature is never checked again. It is most relevant when the signature (and the signed data) are stored for an extended period of time. > > Let's assume that the constrained client wants to validate such a > > transaction. The TSP timestamp provides the date/time of interest. It can > > ask the DPV server if the signer's path was valid at the time that the > > signature was generated. > >Since it is not possible to know when the signature was generated, >an upper limit of that time is use instead: the date of the time-stamp >applied over the digital signature or the date included in an audit record >See the DPV requirements document at: >http://www.imc.org/draft-ietf-pkix-dsv-req. > >The correct sentence is thus: "It can ask the DPV server if the signer's >path was valid at the time that the time-stamp was applied over the digital >signature". I think we are trying to say the same thing. > > In my view, the cautionary period only impacts the signature on the > > transaction. > >Since a cautionary period cannot be applied in the context of a >confidentiality service or an authentication service, the right wording >would be : "the cautionary period only impacts the use of a certificate >in the context of a non-repudiation service or a >data-origin-authentication-with-integrity service". Again, I think we are trying to say the same thing. The signature validation is the central event. The certificate is being validated as a necessary condition to the signature validation. > > The DPV server does not validate this signature. Has > > adequate time passed since the signature was applied to ensure that recent > > compromise of the end-entity private key has been reported? I submit that > > this a signature validation question, not a certification path validation > > question. > >The basic question is how clients can take advantage of a DPV server in the >case where a cautionary period exists and in the context of a >non-repudiation service or a data-origin-authentication-with-integrity >service ? This is the crux of our disagreement. I argue that cautionary period is a concept that relates to a single signature, not to the certificate that contains the public key used to validate the signature. If there is any protocol that should include the cautionary period concept, it is the DSV protocol -- not the DPV protocol. >There are two options whether : > >1) the cautionary period has to be known by the client > (which is what your arguments mandate). > >2) the cautionary period is known by the server > (which is what my arguments mandate). > >In the context of a non repudiation service, clients must necessarilly know >either the date of the time-stamp or the date of the audit record. > >In the context of a data-origin-authentication-with-integrity service, >clients must necessarilly know the purported date of the digital signature. > >With option 1, clients must locally manage the cautionary period for each >supported policy and locally compare it either with the date of the >time-stamp or the date of the audit record, or the the purported date of the >digital signature. This makes management actions more difficult >(and makes also thin clients fater) since if that period changes, >local tables need to be updated in each client application. > >With option 2, clients do not need to manage that information locally since >it is part of the policy supported by the server. They simply need to send >to the server either the date of the time-stamp or the date of the audit >record, or the purported date of the digital signature. > >The goal of these protocols is to delegate as much as possible all the >validation conditions to a server. The cautionary period does not >make an exception. I disagree. The goal of these protocols is to delegate the certification path construction and validation to a server. The client is still responsible for all actions that use the public key in the server validated certificate. If one of those actions is signature validation in a context where cautionary period applies, then the client is responsible for observing the cautionary period. If the server were performing the public key operation (as it is in DSV), then the server would be responsible for observing the cautionary period. Russ ============================================================================ ================ 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 16 07:44:38 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GFicv05750 for ietf-pkix-bks; Wed, 16 Jan 2002 07:44:38 -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 g0GFiW305744 for ; Wed, 16 Jan 2002 07:44:32 -0800 (PST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 15:44:08 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 KAA29061; Wed, 16 Jan 2002 10:44:33 -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 g0GEmIN00511; Wed, 16 Jan 2002 09:48:18 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 09:48:17 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.12]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH53LP; Wed, 16 Jan 2002 09:48:02 -0500 Message-ID: <5.0.1.4.2.20020116093805.01f87998@exna07.securitydynamics.com> From: "Housley, Russ" To: Petra Barzin , Denis Pinkas Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt Date: Wed, 16 Jan 2002 09:39:48 -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: Petra and Denis: The structure of SCVP makes it very easy to add support of attribute certificates (or PGP certificates for that matter) at a later date. We need to make sure that there is a constituency for the protocols we develop for the standards track. Russ At 12:36 PM 1/16/2002 +0100, Denis Pinkas wrote: >Petra, > > > Yes, thanks for the pointer. I found the ASN.1 definitions there. > > > > One more question turned up: > > Is DPV restricted to X.509 public key certificates or is it possible > > to use it for X.509 attribute certificates as well? > >Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft >have been specifically written to support PKIX public key certificates. > >At the last IETF meeting a question has been raised to the audience: >Who, in the room, has implemented Attribute Certificates ? >No hand showed up. > >So it seems that there is no urgence to support PKIX attribute certificates. > >However, maybe by making some changes, PKIX attribute certificates could be >supported, but this is an exercise that I have not undertaken. > >The basic question is thus whether to include the support of attribute >certificates in the current DPV-DPD requirement draft. > >Unless you, or someone else, can rapidly provide arguments and demonstrate >that it will not delay the support of PKIX public key certificates, I would >rather think that it should not be included at this time. > >Regards, > >Denis > > > > - Petra > > > > Denis Pinkas schrieb: > > > > > Petra, > > > > > > Please take a look at RFC 3126, where many of the ASN.1 structures were > > > imported from and are thus defined there. This should answer all your > > > questions. > > > > > > Regards, > > > > > > Denis > > > > > > > Denis, > > > > > > > > may I still ask some questions concerning the document "Delegated > > > > Path Validation and Delegated Path Discovery Protocols" ? > > > > > > > > > PathValues :: = SEQUENCE { > > > > > certificateValues CertificateValues, > > > > > revocationValues RevocationValues } > > > > > > > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues" > > > > and "RevocationValues" but I couldn't find these definitions. > > > > > > > > By the way, you should move this definition of "PathValues" from > > > > the chapter "5.2.1. Request" to the chapter "5.2.2. Response Syntax" > > > > where it is used. > > > > > > > > Another ASN.1 question: > > > > > > > > > UsefulRevoc ::= CHOICE { > > > > > certificateRevocationLists CertificateRevocationLists, > > > > > completeRevocationRefs CompleteRevocationRefs } > > > > > > > > > A DPV request may contain useful revocation information provided > > > > by the client. Maybe it's because I don't know the element > > > > "CompleteRevocationRefs" but where do I store OCSP answers? > > > > > > > > Could you please send the definition of "CompleteRevocationRefs" > > > > and "completeCertificateRefs"? I guess they are imported from [ES-F], > > > > "Electronic Signature Formats for long term electronic signatures", > aren't > > > > they? > > > > > > > > > CertOrCertRef ::= CHOICE { > > > > > certificate [1] Certificate, > > > > > certRef [2] OtherCertID } > > > > > > > > > I'm also missing the definition of OtherCertID used in a DPV and DPD > > > > request. > > > > > > > > Thanks, Petra > > > > > > > > Denis Pinkas schrieb: > > > > > > > > > Petra, > > > > > > > > > > > Denis, > > > > > > > > > > > is there also a new version of the document "Delegated Path > > > > > > Validation and Delegated Path Discovery Protocols" > > > > > > > > > > Not at this time. Currently we need first to agree on the DPV / DPD > > > > > requirements, then we will discuss the solutions to these > requirements. > > > > > > > > > > The so-called "Delegated Path Validation and Delegated Path Discovery > > > > > Protocols" document could be a candidate to fulfill these > requirements. > > > > > It is too early to say and this will only be discussed once the > > > > > requirements > > > > > document is adopted. > > > > > > > > > > > or just a new requirement document? > > > > > > > > > > Correct. It is a new document for both the DPV and DPD requirements. > > > > > > > > > > There is also a companion document for the DSV requirements. > > > > > We will only discuss the DSV requirements document in detail when > > > > > the DPV / DPD requirements document has completed the WG last call. > > > > > > > > > > Denis ============================================================================ ================ 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 16 08:49:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GGnCn07296 for ietf-pkix-bks; Wed, 16 Jan 2002 08:49:12 -0800 (PST) Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GGnA307291 for ; Wed, 16 Jan 2002 08:49:10 -0800 (PST) Received: from phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id g0GGnBh82696 for ; Wed, 16 Jan 2002 09:49:11 -0700 (MST) Message-ID: <3C45AEA9.2AC5404F@phaos.com> Date: Wed, 16 Jan 2002 11:47:38 -0500 From: Joe Morgan X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-GB MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: TSP interop update Content-Type: multipart/alternative; boundary="------------9BE45895AB299668C9DCA245" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: --------------9BE45895AB299668C9DCA245 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just a quick update on our progress with TSP interop testing. Cheers, Joe SERVER | HTTP | TCP | | | | | | | Peter Gutmann | | | host = tsa.cryptoapps.com | | | port = 3318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | SUCCESS | | | | | | | IAIK | | | host = bais.iaik.at | | | port = 318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | SUCCESS | | | | | | | Datum | | | host = 64.241.183.87 | | | port = 318 | | | policy id = | | | 1.3.6.1.4.1.3029.56.36.54 | n/s | SUCCESS | | | | | | | SIA | | | host = 193.203.230.166 | | | port = 318 | | | policy id = 1.3.135.1.2.0 | n/s | SUCCESS | | | | | | | EdelWeb | | | url = | | | http://www.edelweb.fr/ | | | cgi-bin/service-tsp | | | policy id = | | | 1.3.6.1.4.1.5309.1.2.2 | SUCCESS | n/s | | | | | | | CNSG | | | host = tsp.test.polito.it | | | port = 318 | | | policy id = 0.4.0.1.1.1 | n/s | SUCCESS | | | | | | | C&A | | | host = 195.223.2.6 | | | port = 3318 | | | policy id = 0.4.0.1.1.1 | | | url = | | | http://195.223.2.6:8080/ | | | timestamp | SUCCESS | SUCCESS | n/s = Not supported. n/a = Not available. -- Joe Morgan jmorgan@phaos.com Software Engineer Phaos Technology Corp. http://www.phaos.com/ --------------9BE45895AB299668C9DCA245 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Just a quick update on our progress with TSP interop testing.

Cheers,
Joe
 

SERVER                           |   HTTP     |   TCP     |
                                 |            |           |
                                 |            |           |
Peter Gutmann                    |            |           |
host = tsa.cryptoapps.com        |            |           |
port = 3318                      |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
IAIK                             |            |           |
host = bais.iaik.at              |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
Datum                            |            |           |
host = 64.241.183.87             |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
SIA                              |            |           |
host = 193.203.230.166           |            |           |
port = 318                       |            |           |
policy id = 1.3.135.1.2.0        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
EdelWeb                          |            |           |
url =                            |            |           |
http://www.edelweb.fr/           |            |           |
   cgi-bin/service-tsp           |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.5309.1.2.2           |   SUCCESS  |   n/s     |
                                 |            |           |
                                 |            |           |
CNSG                             |            |           |
host = tsp.test.polito.it        |            |           |
port = 318                       |            |           |
policy id = 0.4.0.1.1.1          |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
C&A                              |            |           |
host = 195.223.2.6               |            |           |
port = 3318                      |            |           |
policy id = 0.4.0.1.1.1          |            |           |
url =                            |            |           |
http://195.223.2.6:8080/         |            |           |
   timestamp                     |   SUCCESS  |  SUCCESS  |
 
 

n/s = Not supported.
n/a = Not available.

--
Joe Morgan
jmorgan@phaos.com
Software Engineer
Phaos Technology Corp.
http://www.phaos.com/
  --------------9BE45895AB299668C9DCA245-- From owner-ietf-pkix Wed Jan 16 09:56:23 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0GHuNI09449 for ietf-pkix-bks; Wed, 16 Jan 2002 09:56:23 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GHuL309439 for ; Wed, 16 Jan 2002 09:56:21 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> References: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> Date: Wed, 16 Jan 2002 09:56:18 -0800 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: Re: Cautionary Period Straw Poll 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: I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. I belive this because the cautionary period is of no value, and will likely confuse, the principle users of DPV users, namely systems that need to decide immediately whether a signature in front of them should be allowed for identification. The cautionary period is of some value in DSV, although it is not clear whether or not it will be confusing there as well. Knowing what your trusted DSV server's cautionary period is may or may not useful; knowing what your own cautionary period is useful. DSV should either allow the user to give definitive inputs to the cautionary period calculation from the DSV server, or it should not include the cautionary period at all. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Wed Jan 16 10:36:38 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GIac410302 for ietf-pkix-bks; Wed, 16 Jan 2002 10:36:38 -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 g0GIaa310298 for ; Wed, 16 Jan 2002 10:36:36 -0800 (PST) Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com with ESMTP id g0GIaWY14737 for ; Wed, 16 Jan 2002 11:36:32 -0700 (MST) Received: from host66160 (slip-32-103-199-2.ga.us.prserv.net [32.103.199.2]) by smtp.digsigtrust.com with SMTP id g0GIYa020561 for ; Wed, 16 Jan 2002 11:34:37 -0700 (MST) Message-ID: <000001c19ebc$ab85d6c0$b20cb9d0@host66160> Reply-To: "Yuriy Dzambasow" From: "Yuriy Dzambasow" To: References: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> Subject: Re: Cautionary Period Straw Poll Date: Wed, 16 Jan 2002 10:13:04 -0500 Organization: Digital Signature Trust 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. I belive this because I believe that time stamps are more than adequate to support most applications in determining the validity of a certificate and/or signature, and adding a cautionary period just adds unnecessary complexity to the DPV protocols. Yuriy ----- Original Message ----- From: "Housley, Russ" To: Sent: Tuesday, January 15, 2002 1:05 PM Subject: Cautionary Period Straw Poll > > From the previous thread (which seems to have died down), I think that > everyone understands the Cautionary Period concept. I am trying to > determine whether there is a constituency for Cautionary Period in DPV. > > I would like people that have an opinion to vote by sending a message to > the list. The message should be structured as follows: > > To: ietf-pkix@imc.org > Subject: RE: Cautionary Period Straw Poll > > I believe that DPV protocols developed by the PKIX working group > [ought to | ought not] include support for a cautionary period. > > [I belive this because ...] > > If you feel the need to reply to the rationale posted by someone, please > make that posting on the other thread. Please do not clutter the straw > poll voting with a debate. > > Thanks for your assistance and cooperation, > Russ > From owner-ietf-pkix Wed Jan 16 11:31:55 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJVtx11595 for ietf-pkix-bks; Wed, 16 Jan 2002 11:31:55 -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 g0GJVr311591 for ; Wed, 16 Jan 2002 11:31:53 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 19:31:30 UT Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA29983 for ; Wed, 16 Jan 2002 14:31:54 -0500 (EST) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 11:06:27 -0800 Message-ID: From: "Yee, Peter" To: "'ietf-pkix@imc.org'" Subject: Re: Cautionary Period Straw Poll Date: Wed, 16 Jan 2002 11:06:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I feel that a cautionary period is NOT something for PKIX DPV protocols. -Peter Yee From owner-ietf-pkix Wed Jan 16 11:41:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJfTo11855 for ietf-pkix-bks; Wed, 16 Jan 2002 11:41:29 -0800 (PST) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GJfS311850 for ; Wed, 16 Jan 2002 11:41:28 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0GQ100F01QP584@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 16 Jan 2002 11:41:29 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0GQ100EEOQP5WC@ext-mail.valicert.com>; Wed, 16 Jan 2002 11:41:29 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 11:41:28 -0800 Content-return: allowed Date: Wed, 16 Jan 2002 11:41:27 -0800 From: Peter Williams Subject: RE: OCSP RFC and OCSP version 2 ID To: "'Denis Pinkas '" , "'Santosh Chokhani '" Cc: "'ietf-pkix@imc.org '" Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E01F4A48D@exchange.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain List-Unsubscribe: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: Denis, You refer to an assumed "main mechanism" in your note. Speaking factually, to hopefully guide you, sensibly:- The main [reference] mechanism(s) at, and shortly after, the time of writing OCSP IDs included:- (1) VeriSign, who used an oracle database-based repository to feed data to OCSP deamons acting in cached and interactive, direct-trust mode; CRLs were not involved. OCSP proxing/multiplexing interactive direct-trust mode was added, shortly after standarization, for a defense customer bridging multiple certification domains. (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP deamons. Indirect CRLs and CRLDPs support was added slightly after the architects had harmonized their work. Both mechanisms evolved further, outside of IETF and in vendor forums, particularly in the area of: application integration, CRLDPs and delta-CRL data sources, proxying transaction semantics and response resigning, data freshness signalling, and OCSP client interaction with X.509 and PKIX-style path processing and X.509 applications such as SSLv3/https and MTA-based automatic xmldsig signature verification on B2B and banking protocol XML streams. Historically, this work essentially re-designed the standardized features of the "distributed authentication model" of X.500 1988, for OCSP-borne queries. Currently, VeriSign's current work in W3C also reflects alot of the understanding on the required semantics of realtime trust models. Peter. -----Original Message----- From: Denis Pinkas To: Santosh Chokhani Cc: ietf-pkix@imc.org Sent: 1/16/02 12:04 AM Subject: Re: OCSP RFC and OCSP version 2 ID At the time the document was written, the main mechanism to feed the information to the OCSP server was to use CRLs. So it seems sensible to think that these fields are copied from a CRL. From owner-ietf-pkix Wed Jan 16 11:51:47 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJplE12089 for ietf-pkix-bks; Wed, 16 Jan 2002 11:51:47 -0800 (PST) Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GJpk312085 for ; Wed, 16 Jan 2002 11:51:46 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 14:51:38 -0500 Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B5A8@SCYGMXS01> From: Santosh Chokhani To: Peter Williams , "'Denis Pinkas '" , Santosh Chokhani Cc: "'ietf-pkix@imc.org '" Subject: RE: OCSP RFC and OCSP version 2 ID Date: Wed, 16 Jan 2002 14:50:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19EC7.0A9B3970" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19EC7.0A9B3970 Content-Type: text/plain Why aren't the authors responding to this contradiction in the RFC and carried out in the ID? -----Original Message----- From: Peter Williams [mailto:peterw@valicert.com] Sent: Wednesday, January 16, 2002 2:41 PM To: 'Denis Pinkas '; 'Santosh Chokhani ' Cc: 'ietf-pkix@imc.org ' Subject: RE: OCSP RFC and OCSP version 2 ID Denis, You refer to an assumed "main mechanism" in your note. Speaking factually, to hopefully guide you, sensibly:- The main [reference] mechanism(s) at, and shortly after, the time of writing OCSP IDs included:- (1) VeriSign, who used an oracle database-based repository to feed data to OCSP deamons acting in cached and interactive, direct-trust mode; CRLs were not involved. OCSP proxing/multiplexing interactive direct-trust mode was added, shortly after standarization, for a defense customer bridging multiple certification domains. (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP deamons. Indirect CRLs and CRLDPs support was added slightly after the architects had harmonized their work. Both mechanisms evolved further, outside of IETF and in vendor forums, particularly in the area of: application integration, CRLDPs and delta-CRL data sources, proxying transaction semantics and response resigning, data freshness signalling, and OCSP client interaction with X.509 and PKIX-style path processing and X.509 applications such as SSLv3/https and MTA-based automatic xmldsig signature verification on B2B and banking protocol XML streams. Historically, this work essentially re-designed the standardized features of the "distributed authentication model" of X.500 1988, for OCSP-borne queries. Currently, VeriSign's current work in W3C also reflects alot of the understanding on the required semantics of realtime trust models. Peter. -----Original Message----- From: Denis Pinkas To: Santosh Chokhani Cc: ietf-pkix@imc.org Sent: 1/16/02 12:04 AM Subject: Re: OCSP RFC and OCSP version 2 ID At the time the document was written, the main mechanism to feed the information to the OCSP server was to use CRLs. So it seems sensible to think that these fields are copied from a CRL. ------_=_NextPart_001_01C19EC7.0A9B3970 Content-Type: text/html RE: OCSP RFC and OCSP version 2 ID

Why aren't the authors responding to this contradiction in the RFC and carried out in the ID?

-----Original Message-----
From: Peter Williams [mailto:peterw@valicert.com]
Sent: Wednesday, January 16, 2002 2:41 PM
To: 'Denis Pinkas '; 'Santosh Chokhani '
Cc: 'ietf-pkix@imc.org '
Subject: RE: OCSP RFC and OCSP version 2 ID


Denis,

You refer to an assumed  "main mechanism" in your note. Speaking factually,
to hopefully guide you, sensibly:-

The main [reference] mechanism(s) at, and shortly after,
the time of writing OCSP IDs included:-

(1) VeriSign, who used an oracle database-based repository to feed data
to OCSP deamons acting in cached and interactive, direct-trust
mode; CRLs were not involved. OCSP proxing/multiplexing interactive
direct-trust mode was  added, shortly after standarization, for a
defense customer bridging multiple certification domains.

(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
deamons. Indirect CRLs and CRLDPs support was added slightly after
the architects had harmonized their work.

Both mechanisms evolved further, outside of IETF and
in vendor forums, particularly in the area of: application
integration, CRLDPs and delta-CRL data sources, proxying
transaction semantics and response resigning, data freshness
signalling, and OCSP client interaction with X.509 and
PKIX-style path processing and X.509 applications such as
SSLv3/https and MTA-based automatic xmldsig signature
verification on B2B and banking protocol XML streams.

Historically, this work essentially re-designed the standardized
features of the "distributed authentication model" of
X.500 1988, for OCSP-borne queries.

Currently, VeriSign's current work in W3C also
reflects alot of the understanding on the required
semantics of realtime trust models.

Peter.

-----Original Message-----
From: Denis Pinkas
To: Santosh Chokhani
Cc: ietf-pkix@imc.org
Sent: 1/16/02 12:04 AM
Subject: Re: OCSP RFC and OCSP version 2 ID

At the time the document was written, the main mechanism to feed the
information to the OCSP server was to use CRLs. So it seems sensible to
think that these fields are copied from a CRL.
 

------_=_NextPart_001_01C19EC7.0A9B3970-- From owner-ietf-pkix Wed Jan 16 12:10:34 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0GKAYK12450 for ietf-pkix-bks; Wed, 16 Jan 2002 12:10:34 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GKAT312441; Wed, 16 Jan 2002 12:10:30 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g0GKAVU02894; Wed, 16 Jan 2002 20:10:31 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Wed, 16 Jan 2002 20:06:06 +0000 Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA27756; Wed, 16 Jan 2002 20:10:26 GMT Message-ID: <3C45DD2C.6986D397@baltimore.ie> Date: Wed, 16 Jan 2002 20:06:04 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org CC: Paul Hoffman / IMC Subject: Re: Cautionary Period Straw Poll References: <5.0.1.4.2.20020115125653.030ac828@exna07.securitydynamics.com> 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: I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. I believe this for reasons already stated (e.g. by Paul Hoffman) and also because I believe we shouldn't make DPV even more dubious (there - I tried again:-). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-pkix Wed Jan 16 12:49:14 2002 Received: by above.proper.com (8.11.6/8.11.3) id g0GKnEt13330 for ietf-pkix-bks; Wed, 16 Jan 2002 12:49:14 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GKnD313326 for ; Wed, 16 Jan 2002 12:49:13 -0800 (PST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0GKjrR27430 for ; Wed, 16 Jan 2002 12:45:53 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 12:50:07 -0800 Message-ID: From: "Deacon, Alex" To: ietf-pkix@imc.org Subject: RE: Cautionary Period Straw Poll Date: Wed, 16 Jan 2002 12:48:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: List-ID: I believe that DPV protocols developed by the PKIX working group ought not include support for a cautionary period. Alex From owner-ietf-pkix Wed Jan 16 13:38:13 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GLcDS14908 for ietf-pkix-bks; Wed, 16 Jan 2002 13:38:13 -0800 (PST) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GLcC314899 for ; Wed, 16 Jan 2002 13:38:12 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0GQ100F01W3QZK@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 16 Jan 2002 13:38:15 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0GQ100FCEW3QKV@ext-mail.valicert.com>; Wed, 16 Jan 2002 13:38:14 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 13:38:14 -0800 Content-return: allowed Date: Wed, 16 Jan 2002 13:38:13 -0800 From: Ambarish Malpani Subject: RE: OCSP RFC and OCSP version 2 ID To: "'Santosh Chokhani'" Cc: "'ietf-pkix@imc.org '" Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E028E4FFB@exchange.valicert.com> 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: Hi Santosh, Give me some time.... :-) I agree with your first analysis: "If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time" Actually, they way I would prefer to state it would be something like: "If nextUpdate is not set, the responder is indicating that it doesn't know when newer information will be available and so, if a client wants status information on th