From owner-ietf-pkix@mail.imc.org Sun Apr 01 12:54:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3KV-0007MN-7r for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 12:54:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY3KT-0003At-Dn for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 12:54:59 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31FnW0A008757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 08:49:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31FnW6o008756; Sun, 1 Apr 2007 08:49:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l31FnBNh008739 for ; Sun, 1 Apr 2007 08:49:31 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704011549.l31FnBNh008739@balder-227.proper.com> Received: (qmail 4280 invoked by uid 0); 1 Apr 2007 15:49:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 1 Apr 2007 15:49:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Apr 2007 11:46:41 -0400 To: "Anders Rundgren" From: Russ Housley Subject: Re: netscape-cert-renewal-url & beyond Cc: ietf-pkix@imc.org In-Reply-To: <005901c7735e$56b522a0$82c5a8c0@arport2v> References: <005901c7735e$56b522a0$82c5a8c0@arport2v> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Such an extension is suitable for publication as an informational RFC, unless change control is released to the IETF, in which case a standards-track RFC is possible if there is sufficient interest. That said, it does nothing to help a relying party. It helps the subject of the certificate, but this same information could be provided to the subject when the certificate is issued without burdening all of the parties that make use of the certificate. Russ At 02:32 AM 3/31/2007, Anders Rundgren wrote: >Although the "netscape-cert-renewal-url" certificate extension does >not appear to be incorporated in any PKIX RFC, it is anyway >documented in vendor specs like: >http://msdn2.microsoft.com/en-us/library/aa378149.aspx > >I have two open questions regarding this particular extension: > >1. Is it supported by any PKI-clients and if so which ones? > >2. If it is not already supported on major scale wouldn't it be >worthwhile supporting such a facility? My personal experience >with certificates (I have had numerous), is that they tend to silently >expire, leaving you high and dry and concluding that "passwords are >better". When you have to "renew" from scratch you are thrown >into laborious processes which can take weeks to perform. > >If you have certificate and key in a connected device >like a web-server or mobile phone, you could very well >create something like we already have with Windows update, >JRE update, Adobe update, where the user in some instances >only would have to issue a PIN in order to get a credential >update. For commercial certificates the process would be >slightly more complex but of course an auto-renewal-process >must support this use-case as well. > >I do not propose making the Netscape extension a PKIX >standard but rather start discussing the road to a better >support of credential life-cycles. > >Comments? > >Anders Rundgren From owner-ietf-pkix@mail.imc.org Sun Apr 01 16:00:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY6EP-0007UI-Ql for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 16:00:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY6EN-0004zJ-EL for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 16:00:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31JGYqh018880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 12:16:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31JGYxT018879; Sun, 1 Apr 2007 12:16:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l31JGDhw018864 for ; Sun, 1 Apr 2007 12:16:33 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704011916.l31JGDhw018864@balder-227.proper.com> Received: (qmail 25935 invoked by uid 0); 1 Apr 2007 19:16:07 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 1 Apr 2007 19:16:07 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Apr 2007 15:16:11 -0400 To: "Anders Rundgren" From: Russ Housley Subject: Re: netscape-cert-renewal-url & beyond Cc: ietf-pkix@imc.org In-Reply-To: <00e001c77491$220ff6e0$82c5a8c0@arport2v> References: <005901c7735e$56b522a0$82c5a8c0@arport2v> <4561C2210415D081@pne-smtpin2-sn2.hy.skanova.net> <00e001c77491$220ff6e0$82c5a8c0@arport2v> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Anders: > >It helps the subject of the certificate, but this same information > >could be provided to the subject when the certificate is issued > >Ehh? When the certificate is "issued"? I think you need to >elaborate a bit on what you had in mind preferably fitting the 10M >and counting consumer/citizen certificate holders in the EU. At the time the CA provides the certificate to the subject, they could provide the URL for renewal. It does not need to be in the certificate itself. It just needs to be available to the subject when they want to renew. > >without burdening all of the parties that make use of the certificate. > >How could a relying party be "burdened" by a non-critical extension >it may not understand and definitely do not have to care for? It is information for the subject, it has no value to the relying party. The extension makes the certificate larger, so it takes more bandwidth, which remains an important consideration in some parts of the Internet. Russ From owner-ietf-pkix@mail.imc.org Sun Apr 01 16:01:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY6Ei-0007eg-8K for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 16:01:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY6Eg-00051k-Rj for pkix-archive@lists.ietf.org; Sun, 01 Apr 2007 16:01:12 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31J8srA018166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 12:08:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31J8sHC018164; Sun, 1 Apr 2007 12:08:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31J8VuD018018 for ; Sun, 1 Apr 2007 12:08:53 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.233.229.21) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) (authenticated as u18116613) id 45FFF5CB003111E8; Sun, 1 Apr 2007 21:08:28 +0200 Message-ID: <00e001c77491$220ff6e0$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Russ Housley" , References: <005901c7735e$56b522a0$82c5a8c0@arport2v> <4561C2210415D081@pne-smtpin2-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) Subject: Re: netscape-cert-renewal-url & beyond Date: Sun, 1 Apr 2007 21:08:25 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 >Russ Housley wrote: >It helps the subject of the certificate, but this same information >could be provided to the subject when the certificate is issued Ehh? When the certificate is "issued"? I think you need to elaborate a bit on what you had in mind preferably fitting the 10M and counting consumer/citizen certificate holders in the EU. >without burdening all of the parties that make use of the certificate. How could a relying party be "burdened" by a non-critical extension it may not understand and definitely do not have to care for? Anders At 02:32 AM 3/31/2007, Anders Rundgren wrote: >Although the "netscape-cert-renewal-url" certificate extension does >not appear to be incorporated in any PKIX RFC, it is anyway >documented in vendor specs like: >http://msdn2.microsoft.com/en-us/library/aa378149.aspx > >I have two open questions regarding this particular extension: > >1. Is it supported by any PKI-clients and if so which ones? > >2. If it is not already supported on major scale wouldn't it be >worthwhile supporting such a facility? My personal experience >with certificates (I have had numerous), is that they tend to silently >expire, leaving you high and dry and concluding that "passwords are >better". When you have to "renew" from scratch you are thrown >into laborious processes which can take weeks to perform. > >If you have certificate and key in a connected device >like a web-server or mobile phone, you could very well >create something like we already have with Windows update, >JRE update, Adobe update, where the user in some instances >only would have to issue a PIN in order to get a credential >update. For commercial certificates the process would be >slightly more complex but of course an auto-renewal-process >must support this use-case as well. > >I do not propose making the Netscape extension a PKIX >standard but rather start discussing the road to a better >support of credential life-cycles. > >Comments? > >Anders Rundgren From owner-ietf-pkix@mail.imc.org Thu Apr 05 21:15:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZd37-0008HY-Ss for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 21:15:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZd36-0000Pv-H7 for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 21:15:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l360IZ1l007097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l360IZHK007096; Thu, 5 Apr 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l360IDUo007061 for ; Thu, 5 Apr 2007 17:18:34 -0700 (MST) (envelope-from pg@futureware.at) Received: from linux.lan (authenticated user pg@futureware.at) by mailbox.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 12-md50000000057.tmp for ; Fri, 06 Apr 2007 02:18:08 +0200 From: Philipp =?iso-8859-1?q?G=FChring?= Organization: Futureware 2001 To: ietf-pkix@imc.org Subject: OCSP Problem Date: Fri, 6 Apr 2007 02:18:06 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200704060218.06836.pg@futureware.at> X-Authenticated-Sender: pg@futureware.at X-Spam-Processed: dns4.go-now.at, Fri, 06 Apr 2007 02:18:08 +0200 (not processed: spam filter disabled) X-Return-Path: pg@futureware.at X-MDaemon-Deliver-To: ietf-pkix@imc.org X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l360IYUo007091 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l360IZ1l007097 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi, The OCSP RFC says that a OCSP request can contain several queries for=20 different certificates.=20 Those queries can be for certificates from different CA=B4s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by = the=20 OCSP Server certificate that corresponds to the CA of the certificate tha= t=20 was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from= =20 different CA=B4s? Which corresponding OCSP server certificate should be u= sed to=20 sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can=B4t cover the other= =20 certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA=B4s i= n a=20 OCSP request? I couldn=B4t find anything in the RFC mentioning that issue. Best regards, Philipp G=FChring From owner-ietf-pkix@mail.imc.org Thu Apr 05 22:25:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZe8J-00072b-5C for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 22:25:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZe8H-0007W6-PT for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 22:24:59 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l361TaA4014460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l361Tag4014459; Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l361TGY0014435 for ; Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCSP Problem Date: Thu, 5 Apr 2007 18:29:10 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790748A865@EXVS01.ex.dslextreme.net> In-Reply-To: <200704060218.06836.pg@futureware.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Problem Thread-Index: Acd36lMlcTSD1u5xRgmBbF7/u1DubgAAIhlA References: <200704060218.06836.pg@futureware.at> From: "Santosh Chokhani" To: X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l361TaY0014453 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l361TaA4014460 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 The responder should have certificates signed by each of the CAs that it = services. The Responder should send all the certificates that are releva= nt to the request. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Philipp G=FChring Sent: Thursday, April 05, 2007 8:18 PM To: ietf-pkix@imc.org Subject: OCSP Problem Hi, The OCSP RFC says that a OCSP request can contain several queries for=20 different certificates.=20 Those queries can be for certificates from different CA=B4s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by = the=20 OCSP Server certificate that corresponds to the CA of the certificate tha= t=20 was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from= =20 different CA=B4s? Which corresponding OCSP server certificate should be u= sed to=20 sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can=B4t cover the other= =20 certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA=B4s i= n a=20 OCSP request? I couldn=B4t find anything in the RFC mentioning that issue. Best regards, Philipp G=FChring From owner-ietf-pkix@mail.imc.org Thu Apr 05 22:56:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZecP-0001sB-3a for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 22:56:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZecL-000581-Kh for pkix-archive@lists.ietf.org; Thu, 05 Apr 2007 22:56:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l362H84m019697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l362H8pP019696; Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l362GlZh019600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from Ryan.Hurst@microsoft.com) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 5 Apr 2007 19:16:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Thu, 5 Apr 2007 19:16:46 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Apr 2007 19:16:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCSP Problem Date: Thu, 5 Apr 2007 19:16:28 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82DD5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <200704060218.06836.pg@futureware.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Problem Thread-Index: Acd37K9aRKdvVWGXRiamd8+ck0eVIQABC2pQ References: <200704060218.06836.pg@futureware.at> From: Ryan Hurst To: =?iso-8859-1?Q?Philipp_G=FChring?= , X-OriginalArrivalTime: 06 Apr 2007 02:16:46.0731 (UTC) FILETIME=[A08605B0:01C777F1] X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l362H8Zg019691 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l362H84m019697 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 OCSP allows for several trust models (although not explicitly called out). I generally refer to them as: VA Direct - I trust the OCSP responder to sign for any CA. VA Delegated - I trust the OCSP responder to delegate its signing ability= to any of its sub-Vas. CA signed - Signed by the same ca/key that signed the certificate. CA delegated - Signed by a OCSP responder delegated by the CA to sign res= ponses on its behalf. The most common deployed trust model is the CA delegated trust model. In your case (a OCSP request for multiple certificates issued by multiple= CAs) the responder could have a certificate from each of the CAs its del= egated for where each of these certificates are bound to the same key pai= r therefore the signature would still be valid and the bag in the respons= e could contain each of these certificates. With that being said it is uncommon for a client to generate requests for= more than one certificate at a time. Ryan -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Philipp G=FChring Sent: Thursday, April 05, 2007 5:18 PM To: ietf-pkix@imc.org Subject: OCSP Problem Hi, The OCSP RFC says that a OCSP request can contain several queries for=20 different certificates.=20 Those queries can be for certificates from different CA=B4s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by = the=20 OCSP Server certificate that corresponds to the CA of the certificate tha= t=20 was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from= =20 different CA=B4s? Which corresponding OCSP server certificate should be u= sed to=20 sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can=B4t cover the other= =20 certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA=B4s i= n a=20 OCSP request? I couldn=B4t find anything in the RFC mentioning that issue. Best regards, Philipp G=FChring From owner-ietf-pkix@mail.imc.org Fri Apr 06 15:29:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZu80-0004FJ-EP for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 15:29:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZu7y-0007pa-10 for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 15:29:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU94x009906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36IU97j009905; Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU8Dj009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:08 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 6C6E65C02B; Fri, 6 Apr 2007 11:29:28 -0700 (PDT) Date: Fri, 06 Apr 2007 11:30:49 -0700 From: Eric Rescorla To: ietf-smime@imc.org Cc: ietf-pkix@imc.org Subject: AlgorithmIdentifier, SHA-1, etc. User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070406182928.6C6E65C02B@laser.networkresonance.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 I'm trying to get a handle on how one ought to encode AlgorithmIdentifier. As people will perhaps remember, the ASN.1 is: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } -- contains a value of the type -- registered for use with the -- algorithm object identifier value Present hash functions do not take any useful parameters, leaving us with two encoding options: - omit the parameter. - include a NULL To make things more complicated, there are (at least) two different contexts in which this production appears: - The S/MIME DigestAlgorithmIdentifier production. - Inside the DigestInfo of the S/MIME signature. RFC 3370's guidance is to omit the parameter for SHA-1 and include a NULL for MD5 (see S 2.1 and 2.2.). However, the current PKCS#1 errata (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) recommend that when one is encoding DigestInfo, one should encode it as NULL: Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 (see 9.2), the parameters field associated with id-sha1, id-sha256, id-sha384 and id-sha512 SHALL have a value of type NULL. This is to maintain compatibility with existing implementations and with the numeric information values already published for EMSA-PKCS1-V1.5 which are also reflected in IEEE 1363a-2004[27]. My understanding from discussions in Prague is that this reflects NIST's current guidance as well. Technically these don't conflict, but obviously, it's undesirable to have the encoding in the message not match that in the DigestInfo, since doing binary comparisons is common practice here. So, what's the right answer here? -Ekr From owner-ietf-pkix@mail.imc.org Fri Apr 06 16:48:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvMZ-00082v-Q9 for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:48:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvMY-0006Ar-E5 for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:48:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8mkm018485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K8mXB018484; Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8l7s018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:47 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 2B7F15C027; Fri, 6 Apr 2007 13:08:07 -0700 (PDT) Date: Fri, 06 Apr 2007 13:09:27 -0700 From: Eric Rescorla To: Blake Ramsdell Cc: Eric Rescorla , ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: <4616A772.5080704@sendmail.com> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <4616A772.5080704@sendmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070406200807.2B7F15C027@laser.networkresonance.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At Fri, 06 Apr 2007 13:02:58 -0700, Blake Ramsdell wrote: > > Eric Rescorla wrote: > > Technically these don't conflict, but obviously, it's undesirable to > > have the encoding in the message not match that in the DigestInfo, > > since doing binary comparisons is common practice here. So, what's the > > right answer here? > > In my case when I receive a digest AlgorithmIdentifier, I bust it open > and get the OID out and discard the wrapper (the outer > AlgorithmIdentifier). So I'm not affected by a mismatch if I do that. > > But yeah, short of normalizing the values in some way, you're pretty > much done. That is, there's no binary comparison, and you perform an > equivalence check by converting both values in such a way that the same > answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get > the same answer. Yeah, my thinking is that it would be better for these to match so that naive implementations work. -Ekr From owner-ietf-pkix@mail.imc.org Fri Apr 06 16:48:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvMb-000837-QM for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:48:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvMa-0006Ay-Dp for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:48:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K3NZa018236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K3N8g018234; Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K32Bw018210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2007 13:03:22 -0700 (MST) (envelope-from blake@sendmail.com) Received: from [192.168.0.4] (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l36K5jaW030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Apr 2007 13:05:46 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l36K5jaW030920 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175889948; bh=aVUBogemJPBCmvA6TmGQBDPKvVw=; h=X-DomainKeys: DomainKey-Signature:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=P8zcssmaxmJQn2uS2mduKb+pZqYph502du+Rhj oz4yZfQaArDkNt7AfRsfFo5FSvLAAC1CFH7rfPqj6sUMw4CObhoW2wsWI5GfPXIbLvC Gvuwm3xeBdUzwpvrgGrOBRWDRitcAzYrL0vH08tYsyv4+tiA0XtFvZFj2flnI2dT9o= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l36K5jaW030920 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=M7QxpsVFvlDXTcT5fBvQfqV4pzi8V2LciIPs1Mr4TkNwYbmHCLgP25WxWutq8Tfca UIJAoXLOcUuro2ug33LJ5hdBmAtdYg/0yQCgktOuYBdouWnS4c/noP3Slxw+cDB1u4b AlbcVO/fyzIZ9O5Zl69vGmDx2GwEh45JB7/V3WY= Message-ID: <4616A772.5080704@sendmail.com> Date: Fri, 06 Apr 2007 13:02:58 -0700 From: Blake Ramsdell User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Eric Rescorla wrote: > Technically these don't conflict, but obviously, it's undesirable to > have the encoding in the message not match that in the DigestInfo, > since doing binary comparisons is common practice here. So, what's the > right answer here? In my case when I receive a digest AlgorithmIdentifier, I bust it open and get the OID out and discard the wrapper (the outer AlgorithmIdentifier). So I'm not affected by a mismatch if I do that. But yeah, short of normalizing the values in some way, you're pretty much done. That is, there's no binary comparison, and you perform an equivalence check by converting both values in such a way that the same answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get the same answer. Blake -- Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com From owner-ietf-pkix@mail.imc.org Fri Apr 06 16:50:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvNk-0000vg-MU for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:50:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvNj-0006Hx-5b for pkix-archive@lists.ietf.org; Fri, 06 Apr 2007 16:50:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K9iSP018528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K9i2N018526; Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l36K9MLX018503 for ; Fri, 6 Apr 2007 13:09:43 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704062009.l36K9MLX018503@balder-227.proper.com> Received: (qmail 5038 invoked by uid 0); 6 Apr 2007 20:09:16 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 6 Apr 2007 20:09:16 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Apr 2007 16:09:19 -0400 To: Eric Rescorla , ietf-smime@imc.org From: Russ Housley Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> References: <20070406182928.6C6E65C02B@laser.networkresonance.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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Note that the DigestInfoValue is part of the structure that is "encrypted" with the RSA private key when generating a signature. It is recovered by "decrypting" the signature value with the RSA public key. An implementation should check that the expected digest algorithm was used. As Eric point out, this check is easier to perform if the two values are encoded in exactly the same manner. One needs to look deeper into signatures in certificates and CMS SignerInfo to see where these comparisons are really performed. The certificate signature has this structure: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } In practice, the signature algorithm tells the digest algorithm as well as the digital signature algorithm. The ones that are relevant to this question are: sha1WithRSAEncryption sha224WithRSAEncryption sha256WithRSAEncryption sha384WithRSAEncryption sha512WithRSAEncryption There is no filed that explicitly carries a digest algorithm identifier. So, the digest algorithm for comparison to the DigestInfoValue inside the signature value must be generated in some manner by the implementation. I believe than many implementations use a simple internal table. Adding entries to this table is part of the work needed to add support for additional RSA signature algorithms. So, the table should contain exactly the octet string that will appear in DigestInfoValue, including the NULL parameter required by PKCS#1. The CMS SignerInfo has this structure: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Again, the signature algorithm tells the digest algorithm. The same set of algorithm identifiers are used here. In each case, the digestAlgorithm must contain the digest algorithm identifier that is implicitly named by the signature algorithm, and the DigestInfoValue must contain the same digest algorithm identifier. As Eric has already explained, the parameter in DigestInfoValue must be NULL, but we are "forgiving" in the processing of the parameter for digestAlgorithm. The parameter can be NULL or absent. In order to use the same signature validation routines for CMS and certificates, I believe that most implementations use the same internal table as discussed above for the DigestInfoValue comparison. Then, in addition, the digest algorithm identifier is compared to the digestAlgorithm field in SignerInfo. The signature value must contain exactly the expected digest algorithm identifier with a NULL parameter. So, the only comparison that is not an exact match is the comparison from the internal table entry to the digestAlgorithm field. I suggest that the object identifiers must match, but one can ignore the parameters, after making sure they are either absent or NULL. That is, do not let the parameters carry some inappropriate value. Russ At 02:30 PM 4/6/2007, Eric Rescorla wrote: >I'm trying to get a handle on how one ought to encode AlgorithmIdentifier. > >As people will perhaps remember, the ASN.1 is: > > >AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > >Present hash functions do not take any useful parameters, leaving >us with two encoding options: > > - omit the parameter. > - include a NULL > >To make things more complicated, there are (at least) two different >contexts in which this production appears: > > - The S/MIME DigestAlgorithmIdentifier production. > - Inside the DigestInfo of the S/MIME signature. > >RFC 3370's guidance is to omit the parameter for SHA-1 and include >a NULL for MD5 (see S 2.1 and 2.2.). > >However, the current PKCS#1 errata >(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) >recommend that when one is encoding DigestInfo, one should >encode it as NULL: > > Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 > (see 9.2), the parameters field associated with id-sha1, id-sha256, > id-sha384 and id-sha512 SHALL have a value of type NULL. This is to > maintain compatibility with existing implementations and with the > numeric information values already published for EMSA-PKCS1-V1.5 > which are also reflected in IEEE 1363a-2004[27]. > >My understanding from discussions in Prague is that this reflects >NIST's current guidance as well. > >Technically these don't conflict, but obviously, it's undesirable to >have the encoding in the message not match that in the DigestInfo, >since doing binary comparisons is common practice here. So, what's the >right answer here? > >-Ekr From owner-ietf-pkix@mail.imc.org Sat Apr 07 03:55:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha5lG-0000d7-JA for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 03:55:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha5lF-0000gg-6l for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 03:55:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771kMA080871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3771kaf080870; Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.10.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771OZ1080808; Sat, 7 Apr 2007 00:01:45 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 045B09C671; Sat, 7 Apr 2007 19:01:24 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTmWuDzOKBYY; Sat, 7 Apr 2007 19:01:23 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D5BBE9C670; Sat, 7 Apr 2007 19:01:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E6298514010; Sat, 7 Apr 2007 19:01:20 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ha4vO-0002Z4-00; Sat, 07 Apr 2007 19:01:26 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, ietf-smime@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> Message-Id: Date: Sat, 07 Apr 2007 19:01:26 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Eric Rescorla writes: >So, what's the right answer here? Read the OID and hash value, toss the rest. Doing anything else is just asking for trouble. (There's really no question here: There are two ways to do this, knowing in advance what you'll encounter in the field isn't possible, so the only workable solution is to not compare the encoded value, or if you must, compare two pre-encoded alternatives for each possible hash algorithm. This still breaks though if someone gets the encoding slightly wrong... comparing a pre-built value is just asking for trouble). >My understanding from discussions in Prague is that this reflects NIST's >current guidance as well. This would put them in conflict with ISO, who (the last time I checked) say the parameter should be omitted. In any case though it doesn't really matter which side wants to hold their breath the longest, if you read the OID and hash and work with that you can't go wrong. Peter. From owner-ietf-pkix@mail.imc.org Sat Apr 07 08:30:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaA3Y-0007Rh-U1 for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 08:30:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaA3X-00049i-9P for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 08:30:12 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdcR0009496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37BdcSD009495; Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdGwY009477; Sat, 7 Apr 2007 04:39:37 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.222] (helo=[10.36.182.67]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1Ha9GF-0002s9-8U; Sat, 07 Apr 2007 12:39:15 +0100 Message-ID: <461782DB.6010502@drh-consultancy.demon.co.uk> Date: Sat, 07 Apr 2007 12:39:07 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ietf-smime@imc.org CC: ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> In-Reply-To: <200704062009.l36K9MMG018505@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 1.8 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Russ Housley wrote: > > Note that the DigestInfoValue is part of the structure that is > "encrypted" with the RSA private key when generating a signature. It is > recovered by "decrypting" the signature value with the RSA public key. > Note that care should be taken when handling the DigestInfo structure recovered from an RSA signature. As well as the original Bleichenbacher signature forgery attack (caused by ignoring trailing garbage after DigestInfo) there is a variant which inserts garbage in the middle of the recovered structure. Allowing arbitrary parameter values in the DigestAlgorithmIdentifier (for example large OCTET STRINGs) is one way to do this. Unlike the original attack this variant produces a "valid" DigestInfo structure. As a result in the specific case of the recovered DigestInfo from an RSA signature OpenSSL now only tolerates a NULL or absent parameter field. This is OK for all existing digests. It is more liberal about DigestInfo structures in other contexts. Steve. From owner-ietf-pkix@mail.imc.org Sat Apr 07 11:17:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaCfu-0006D4-Tc for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 11:17:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaCft-00013p-HR for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 11:17:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWahu030748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EWaM7030746; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from randymail-a2.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWGNA030720; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 7353EEEBB8; Sat, 7 Apr 2007 07:32:15 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B2CC1CC3D; Sat, 7 Apr 2007 07:30:42 -0700 (PDT) Date: Sat, 07 Apr 2007 07:30:42 -0700 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ekr@networkresonance.com, ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: References: <20070406182928.6C6E65C02B@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070407143042.7B2CC1CC3D@delta.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At Sat, 07 Apr 2007 19:01:26 +1200, Peter Gutmann wrote: > > > Eric Rescorla writes: > > >So, what's the right answer here? > > Read the OID and hash value, toss the rest. Doing anything else is just > asking for trouble. > > (There's really no question here: There are two ways to do this, knowing in > advance what you'll encounter in the field isn't possible, so the only > workable solution is to not compare the encoded value, or if you must, > compare two pre-encoded alternatives for each possible hash algorithm. This > still breaks though if someone gets the encoding slightly wrong... comparing > a pre-built value is just asking for trouble). Totally agree. My question was more what we ought to recommend. -Ekr From owner-ietf-pkix@mail.imc.org Sat Apr 07 11:17:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaCfu-0006D5-Tv for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 11:17:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaCft-00013q-HR for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 11:17:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVxiE030702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EVx1I030701; Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from randymail-a3.g.dreamhost.com (sd-green-bigip-145.dreamhost.com [208.97.132.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVcNY030681; Sat, 7 Apr 2007 07:31:58 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a3.g.dreamhost.com (Postfix) with ESMTP id B0A06185976; Sat, 7 Apr 2007 07:31:36 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 73D811CC3D; Sat, 7 Apr 2007 07:30:03 -0700 (PDT) Date: Sat, 07 Apr 2007 07:30:03 -0700 From: Eric Rescorla To: Dr Stephen Henson Cc: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: <461782DB.6010502@drh-consultancy.demon.co.uk> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070407143003.73D811CC3D@delta.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 At Sat, 07 Apr 2007 12:39:07 +0100, Dr Stephen Henson wrote: > > > Russ Housley wrote: > > > > Note that the DigestInfoValue is part of the structure that is > > "encrypted" with the RSA private key when generating a signature. It is > > recovered by "decrypting" the signature value with the RSA public key. > > > > Note that care should be taken when handling the DigestInfo structure > recovered from an RSA signature. > > As well as the original Bleichenbacher signature forgery attack (caused > by ignoring trailing garbage after DigestInfo) there is a variant which > inserts garbage in the middle of the recovered structure. Allowing > arbitrary parameter values in the DigestAlgorithmIdentifier (for example > large OCTET STRINGs) is one way to do this. Unlike the original attack > this variant produces a "valid" DigestInfo structure. > > As a result in the specific case of the recovered DigestInfo from an RSA > signature OpenSSL now only tolerates a NULL or absent parameter field. > This is OK for all existing digests. > > It is more liberal about DigestInfo structures in other contexts. Steven, As I recall OpenSSL puts the NULL in the digestAlgorithm encoding as well. Am I right about that? Thanks, -Ekr From owner-ietf-pkix@mail.imc.org Sat Apr 07 14:04:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaFGu-0006K9-JJ for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 14:04:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaFGt-00033t-6k for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 14:04:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7h91048306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 10:07:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37H7hQL048305; Sat, 7 Apr 2007 10:07:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7MVF048229; Sat, 7 Apr 2007 10:07:42 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.218] (helo=[10.33.180.177]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1HaENj-0004qT-AT; Sat, 07 Apr 2007 18:07:21 +0100 Message-ID: <4617CFBA.3050604@drh-consultancy.demon.co.uk> Date: Sat, 07 Apr 2007 18:07:06 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> <20070407143003.73D811CC3D@delta.rtfm.com> In-Reply-To: <20070407143003.73D811CC3D@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Eric Rescorla wrote: > At Sat, 07 Apr 2007 12:39:07 +0100, > Dr Stephen Henson wrote: >> >> Russ Housley wrote: >>> Note that the DigestInfoValue is part of the structure that is >>> "encrypted" with the RSA private key when generating a signature. It is >>> recovered by "decrypting" the signature value with the RSA public key. >>> >> Note that care should be taken when handling the DigestInfo structure >> recovered from an RSA signature. >> >> As well as the original Bleichenbacher signature forgery attack (caused >> by ignoring trailing garbage after DigestInfo) there is a variant which >> inserts garbage in the middle of the recovered structure. Allowing >> arbitrary parameter values in the DigestAlgorithmIdentifier (for example >> large OCTET STRINGs) is one way to do this. Unlike the original attack >> this variant produces a "valid" DigestInfo structure. >> >> As a result in the specific case of the recovered DigestInfo from an RSA >> signature OpenSSL now only tolerates a NULL or absent parameter field. >> This is OK for all existing digests. >> >> It is more liberal about DigestInfo structures in other contexts. > > Steven, > > As I recall OpenSSL puts the NULL in the digestAlgorithm encoding > as well. Am I right about that? > > Yes. It places the NULL in the DigestAlgortihmIdentifier for RSA signatures DigestInfo according to PKCS#1. It also includes it in other DigestAlgorithmIdentifier structures too. As I recall (I'd have to check some ancient email archives) the NULL was needed to pass an old S/MIME v2 compliance test some years back. Steve. From owner-ietf-pkix@mail.imc.org Sat Apr 07 19:47:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaKcm-0007wS-Vw for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 19:47:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaKcl-0000n6-3J for pkix-archive@lists.ietf.org; Sat, 07 Apr 2007 19:47:16 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37N0kfg083780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37N0kvo083779; Sat, 7 Apr 2007 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l37N0ijJ083766 for ; Sat, 7 Apr 2007 16:00:44 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704072300.l37N0ijJ083766@balder-227.proper.com> Received: (qmail 12222 invoked by uid 0); 7 Apr 2007 23:00:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 7 Apr 2007 23:00:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Apr 2007 18:49:14 -0400 To: Dr Stephen Henson , ietf-smime@imc.org From: Russ Housley Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <461782DB.6010502@drh-consultancy.demon.co.uk> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Thanks for pointing this out. I did say that you needed to make sure it was a valid parameter encoding, but I should have included this important additional information. Thanks. Russ At 07:39 AM 4/7/2007, Dr Stephen Henson wrote: >Russ Housley wrote: > > > > Note that the DigestInfoValue is part of the structure that is > > "encrypted" with the RSA private key when generating a signature. It is > > recovered by "decrypting" the signature value with the RSA public key. > > > >Note that care should be taken when handling the DigestInfo structure >recovered from an RSA signature. > >As well as the original Bleichenbacher signature forgery attack (caused >by ignoring trailing garbage after DigestInfo) there is a variant which >inserts garbage in the middle of the recovered structure. Allowing >arbitrary parameter values in the DigestAlgorithmIdentifier (for example >large OCTET STRINGs) is one way to do this. Unlike the original attack >this variant produces a "valid" DigestInfo structure. > >As a result in the specific case of the recovered DigestInfo from an RSA >signature OpenSSL now only tolerates a NULL or absent parameter field. >This is OK for all existing digests. > >It is more liberal about DigestInfo structures in other contexts. > >Steve. From necojp@citiz.net Sun Apr 08 04:48:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT4p-0000zo-Cd for PKIX-ARCHIVE@LISTS.IETF.ORG; Sun, 08 Apr 2007 04:48:47 -0400 Received: from [124.234.233.176] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaT4l-0000or-AN for PKIX-ARCHIVE@LISTS.IETF.ORG; Sun, 08 Apr 2007 04:48:47 -0400 Received: from lrrnujg1 (unknown [191.132.126.255]) by smtp18 (Coremail) with SMTP id svim4FSVQ3uwyMlA.1 for ; Mon, 31 Mar 2008 03:07:18 +0800 (CST) X-Originating-IP: [191.132.126.255] Subject: =?iso-2022-jp?B?GyRCPjVHJ0JUJEEkLCMxREwkIiRqJF4kOSEjGyhC?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A2_01C776E7.A3432CC0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a multi-part message in MIME format. ------=_NextPart_000_02A2_01C776E7.A3432CC0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B>7BT>u$,FO$$$F$*$j$^$9!#2<5-$h$j;22C$/$@$5$$!#(B http://cb402.ath.cx/pure/?h232 $B"((BPC$B%W%m%P%$%@!
=1B$B>7BT>u$,FO$$$F$*$j$^$9!#2<5-$h$j;22C$/$@$5$$!#=1B(B
http://cb402.ath.cx/pure/?h232
=1B$B"(=1B(BPC=1B$B%W%m%P%$%@!=1B$B$4MxMQ$OL5NA$G$9$N$G!"0B?4$7$F;H$&$3$H$,$G$-$^$9!#=1B(= B
=1B$B$*;n$7HG$H$J$C$F$*$j$^$9!"$^$:$O$*;n$7$/$@$5$$!#=1B(B=20
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$BG[?.ITMW=1B(B
saki_honda19@yahoo.fr
------=_NextPart_000_02A2_01C776E7.A3432CC0-- From owner-ietf-pkix@mail.imc.org Mon Apr 09 08:21:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HassR-0005vy-Jt for pkix-archive@lists.ietf.org; Mon, 09 Apr 2007 08:21:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HassQ-0002zz-6f for pkix-archive@lists.ietf.org; Mon, 09 Apr 2007 08:21:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBvXh086161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 04:11:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l39BBvuu086160; Mon, 9 Apr 2007 04:11:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBWWt086104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 04:11:54 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l39BB7gw012799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 13:11:07 +0200 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ekr@networkresonance.com, ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070409:ekr@networkresonance.com::3QoFEDKqVNPqTq5Q:MsX X-Hashcash: 1:22:070409:ietf-smime@imc.org::tQBP8tX8HMZykdCj:6/O+ X-Hashcash: 1:22:070409:ietf-pkix@imc.org::ZPi90spiQd3Aos3c:DKnD X-Hashcash: 1:22:070409:pgut001@cs.auckland.ac.nz::Nnw/iCZnyUzfe4w7:LBLl Date: Mon, 09 Apr 2007 14:11:04 +0200 In-Reply-To: (Peter Gutmann's message of "Sat\, 07 Apr 2007 19\:01\:26 +1200") Message-ID: <87lkh1eoiv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Eric Rescorla writes: > >>So, what's the right answer here? > > Read the OID and hash value, toss the rest. Doing anything else is just > asking for trouble. > > (There's really no question here: There are two ways to do this, knowing in > advance what you'll encounter in the field isn't possible, so the only > workable solution is to not compare the encoded value, or if you must, > compare two pre-encoded alternatives for each possible hash algorithm. This > still breaks though if someone gets the encoding slightly wrong... comparing > a pre-built value is just asking for trouble). That approach, to not validate the parameters field, is what led to the variant of Bleichenbacher's attack in several TLS implementations. I'm strongly opposed to permit this in conforming implementations. Even if we restrict it to either absent parameters or NULL parameters, that would enable a side-channel: you can "leak" one bit of information by deciding which of NULL or absent you use. It is not clear to me how important that threat is. There are other ways to leak information in the TLS protocol (packet ordering, random values, etc). However, there may be some value in not expanding the ways to leak information further. I could live with MUST generate NULL parameters fields on encoding, and MUST accept both NULL and absent fields on decoding. /Simon From owner-ietf-pkix@mail.imc.org Wed Apr 11 04:12:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXwS-0000BG-D2 for pkix-archive@lists.ietf.org; Wed, 11 Apr 2007 04:12:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXwM-0005ii-N1 for pkix-archive@lists.ietf.org; Wed, 11 Apr 2007 04:12:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B72q7g042207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3B72qIX042206; Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gateway.baea.com.au (gateway.baea.com.au [202.20.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B72p7I042196 for ; Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from ian.brumby@baesystems.com) Received: from unknown (HELO sbuxscan.baea.com.au) ([150.207.31.25]) by gateway.baea.com.au with ESMTP; 11 Apr 2007 16:32:51 +0930 Received: from bunya.baea.com.au (bunya [150.207.1.63]) by sbuxscan.baea.com.au (8.13.6/8.12.10) with ESMTP id l3B72oEt022198 for ; Wed, 11 Apr 2007 16:32:50 +0930 (CST) Received: from SBW3OWEX1.au.baesystems.com (exchange [150.207.4.37]) by bunya.baea.com.au (8.13.6+Sun/8.13.6) with ESMTP id l3B72ojp028985 for ; Wed, 11 Apr 2007 16:32:50 +0930 (CST) Received: from brdw3ex1.au.baesystems.com ([150.207.68.10]) by SBW3OWEX1.au.baesystems.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:32:49 +0930 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-pkix-lightweight-ocsp-profile-08.txt Date: Wed, 11 Apr 2007 17:02:49 +1000 Message-ID: <0D88367CF035304ABCB1022D82AF0753673F7D@brdw3ex1.au.baesystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile-08.txt Thread-Index: Acd8B2+oUOqz45a1RP60+P4LmQ++NA== From: "BRUMBY, Ian" To: X-OriginalArrivalTime: 11 Apr 2007 07:02:50.0070 (UTC) FILETIME=[6ABC7760:01C77C07] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3B72q7I042200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Under Signed OCSPResponses (1.2.2), the extension is referred to as id-ocsp-nocheck instead of id-pkix-ocsp-nocheck. Under Transport Profile (4), there is some ambiguity as to whether a request that is exactly 255 bytes should be a GET or POST. Should this be worded something like "less than or equal to 255 bytes in total" rather than "smaller than 255 bytes in total"? Immediately following that is a typo - OCSPReqeust. Regards, Ian Brumby BAE Systems From aya@so-net.ne.jp Wed Apr 11 11:32:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbenu-0007aD-Bn for PKIX-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Apr 2007 11:32:14 -0400 Received: from [222.171.222.170] (helo=excite.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hbenq-00024K-AI for PKIX-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Apr 2007 11:32:14 -0400 Received: from juwry1 (unknown [241.199.218.85]) by smtp67 (Coremail) with SMTP id l25NTL1mm7XaYiVY.1 for ; Fri, 11 Apr 2008 23:31:59 +0800 (CST) X-Originating-IP: [241.199.218.85] Subject: =?iso-2022-jp?B?GyRCJWElQyU7ITwlOCMxN28bKEI=?= From: =?shift-jis?B?bWFzYWtv?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C77B7E.6F725C90" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C77B7E.6F725C90 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BH"F~$j$@$C$?$N$G!"$s$G$$$^$9!#$4O"(B $BMm$/$@$5$$!#(Bhttp://cb405.iptime.org/serebu/?aa221 $B5.H~9a!!(BID344215 ------=_NextPart_000_0008_01C77B7E.6F725C90 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$BH"F~$j$@$C$?$N$G!"$s$G$$$^$9!#$4O"Mm$/$@$5$$!#=1B(Bhttp://cb405.iptime.org/se= rebu/?aa221  = =1B$B5.H~9a!!=1B(BID344215
 
------=_NextPart_000_0008_01C77B7E.6F725C90-- From xaviarx8uhx@hotmail.com Sat Apr 14 07:40:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcgck-0005mv-Cz; Sat, 14 Apr 2007 07:40:59 -0400 Received: from c-24-7-93-129.hsd1.ca.comcast.net ([24.7.93.129] helo=JOEY-FGWUEHFZOL) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcgcj-0004XB-4q; Sat, 14 Apr 2007 07:40:58 -0400 Message-ID: <24704212062714.CE5A0D92C8@U4E5> From: "xaviarx8uhx" To: Subject: N4XAVN Date: Sat, 14 Apr 2007 04:37:40 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: uoVcjaKqIVQBYz5QYZh5mtrdiqTUWyz3t99O Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Hillo8 2e0 From question@reply3.ebay.com Mon Apr 16 15:30:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWuF-0006S8-05 for pkix-archive@megatron.ietf.org; Mon, 16 Apr 2007 15:30:31 -0400 Received: from datamatixsrv02.datamatix-dubai.com ([208.21.175.52] helo=datamatixSRV02) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWuE-0000kT-CJ for pkix-archive@megatron.ietf.org; Mon, 16 Apr 2007 15:30:30 -0400 Received: from User ([67.80.56.131]) (authenticated user jon@datamatixgroup.com) by datamatixSRV02 (Kerio MailServer 6.0.10); Mon, 16 Apr 2007 23:24:08 +0400 From: "eBay Question" Subject: Message from eBay Member Regarding Item #250062602827 Date: Mon, 16 Apr 2007 15:26:35 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" 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 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Untitled Document
eBay eBay sent this message.
Your registered name is included to show this message originated from eBay. Learn more.

Question about Item -- Respond Now

eBay sent this message on behalf of an eBay member through My Messages. Responses sent using email will go to the eBay member directly and will include your email address.
 Question from eBay Member
 
Item: Sony Playstation 3 60GB 220V HK version- ps3 + 3 games (320065367687)
This message was sent after the listing closed.
veronicag76 is the winner.
Let me know the UPS Tracking number ASAP. I should have it before XMAS.
Respond to this question
Respond Now
Responses in My Messages will not include your email address.
Thank you,
eBay
Details for item number: 320065367687
Item title: Sony Playstation 3 60GB 220V HK version- ps3 + 3 games
Item URL: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320065367687&sspagename=ADME:B:AAQ:US:1
End date: Monday, Dec 18, 2006 08:32:28 PST
Marketplace Safety Tip Marketplace Safety Tip
Always remember to complete your transactions on eBay - it's the safer way to trade.

Is this message an offer to buy your item directly through email without winning the item on eBay? If so, please help make the eBay marketplace safer by reporting it to us. These "outside of eBay" transactions may be unsafe and are against eBay policy. Learn more about trading safely.
Is this email inappropriate? Does it violate eBay policy? Help protect the Community by reporting it.
Learn how you can protect yourself from spoof (fake) emails at:
http://pages.ebay.com/education/spooftutorial

This eBay notice was sent on behalf of another eBay member through the eBay platform and in accordance with our Privacy Policy. If you would like to receive this email in text format, change your notification preferences.

See our Privacy Policy and User Agreement if you have questions about eBay's communication policies.
Privacy Policy: http://pages.ebay.com/help/policies/privacy-policy.html
User Agreement: http://pages.ebay.com/help/policies/user-agreement.html

Copyright © 2006 eBay, Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc.
eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125.


From owner-ietf-pkix@mail.imc.org Mon Apr 16 16:59:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYIn-0004gu-RU for pkix-archive@lists.ietf.org; Mon, 16 Apr 2007 16:59:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYIn-0005Rm-8v for pkix-archive@lists.ietf.org; Mon, 16 Apr 2007 16:59:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJoP56089312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJoPPN089311; Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJo4UB089227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7C640328F3; Mon, 16 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HdXD8-0000Kh-CB; Mon, 16 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-09.txt Message-Id: Date: Mon, 16 Apr 2007 15:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : Lightweight OCSP Profile for High Volume Environments Author(s) : R. Hurst, A. Deacon Filename : draft-ietf-pkix-lightweight-ocsp-profile-09.txt Pages : 20 Date : 2007-4-16 This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client side processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-lightweight-ocsp-profile-09.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-lightweight-ocsp-profile-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-16144445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-lightweight-ocsp-profile-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-16144445.I-D@ietf.org> --OtherAccess-- --NextPart-- From MaxwellTemoney@abacooutback.com Tue Apr 17 18:33:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdwEX-0004wH-UO for pkix-archive@lists.ietf.org; Tue, 17 Apr 2007 18:33:09 -0400 Received: from catv-506201fb.catv.broadband.hu ([80.98.1.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdwET-00070U-Sm for pkix-archive@lists.ietf.org; Tue, 17 Apr 2007 18:33:09 -0400 Received: from nf by abacooutback.com with ASMTP id 41CE7E83 for ; Wed, 18 Apr 2007 00:35:36 +0200 Received: from nf ([182.181.95.131]) by abacooutback.com with ESMTP id 6AE8D9E2941B for ; Wed, 18 Apr 2007 00:35:36 +0200 Message-ID: <000d01c78140$a7204b30$fb016250@nf> From: "Maxwell Temoney" To: pkix-archive@lists.ietf.org Subject: But we need to distract the people from the shivers, from alcohol, from sexual pastimes. Date: Wed, 18 Apr 2007 00:35:08 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C78151.6AA91B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0cc6ce33a3e165c84359672fc0328059 ------=_NextPart_000_0009_01C78151.6AA91B30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C78151.6AA91B30" ------=_NextPart_001_000A_01C78151.6AA91B30 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Oscar was extending me his notebook with the diagrams. Why don't you give him one. Aranow Periodic behavior in charged membranes and its physical and = biological implications. But we now noted a further and unexpected = phenomenon. If your application supports collation, be sure to check that it is = turned off before stapling print jobs. I'm Peter Johnson - a hobbyist programmer living in Ceredigion in West = Wales, UK. By configuring WTE to send requests for content inside the firewall = directly to the content server, you can reduce the load on your firewall = server. This adds another 140 feet to the length. So setting this large may lock out low bandwidth clients unless you also = increase the Timeout. Talbot asked simply, bending forward. Developer's license includes = standard-code license and allows you to distribute the descendants of = Software components for free or for sale as Delphi components or ActiveX = controls. ATmega8535-16JI 8bit AVR Ind. She's always going on about how I should = be upholding the family honor. Spotting Aviendha, standing on the bottom step of the Roof, she guided = Mist around to the other side of the crowd near Rand. ------=_NextPart_001_000A_01C78151.6AA91B30 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
Oscar was extending me his notebook = with the diagrams.
Why don't you give him = one.
Aranow Periodic behavior in charged = membranes and=20 its physical and biological implications. But we now noted a further and = unexpected phenomenon.
If your application supports collation, = be sure to=20 check that it is turned off before stapling print jobs.
I'm Peter Johnson - a hobbyist = programmer living in=20 Ceredigion in West Wales, UK.
By configuring WTE to send requests for = content=20 inside the firewall directly to the content server, you can reduce the = load on=20 your firewall server.
This adds another 140 feet to the = length.
So setting this large may lock out low = bandwidth=20 clients unless you also increase the Timeout.
Talbot asked simply, bending forward. = Developer's=20 license includes standard-code license and allows you to distribute the=20 descendants of Software components for free or for sale as Delphi = components or=20 ActiveX controls.
ATmega8535-16JI 8bit AVR Ind. She's = always going on=20 about how I should be upholding the family honor.
Spotting Aviendha, standing on the = bottom step of=20 the Roof, she guided Mist around to the other side of the crowd near=20 Rand.
 
------=_NextPart_001_000A_01C78151.6AA91B30-- ------=_NextPart_000_0009_01C78151.6AA91B30 Content-Type: image/jpeg; name="renege mandate.jpg" Content-Transfer-Encoding: base64 Content-ID: <000801c78140$a7204b30$fb016250@nf> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyck JDUzMzM1Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUg Ix4eHiMgKCglJSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgCFALTAwEiAAIRAQMRAf/EAMYAAQAC AwEBAAAAAAAAAAAAAAABAgMEBQYHAQEBAQEBAQEBAAAAAAAAAAAAAQIDBAUGBxAAAQMDAQQE CAgKBgkCBwEBAQACAxESBAUhMRMGQVEiFGFx0TJSkhUHgZGhsSMzVNTBQnJTc5MkNFUWYrJ0 ZTYX4YKiwrPTlCU1Q4Pw0mOjw0S0JjcRAAIBAgMEBwQIBgICAwAAAAABAhEDITESQVETBGFx kSIyUhSB0ZJT8KGxwULSBRbxYnIjMxXhQ6LCgrIk/9oADAMBAAIRAxEAPwD5kiItnEIilAER EBKIpQgUqFKpApRShAiKUIFKKVSCilFKEIU0SitRUhFFKUUoQiimikBTRARRSpopogIRTRTR CEAKaIpoqCKIpRAQpopRARRKKaKUBFEopSiEIoilEBCUU0RARRKKyiiAiiKaJRAQimiUQEUS ilEBCiitRRRARRFKUQEKFaiICtEU0RARRQrUUUQEKKK1FFEBCKaIgKpRSiAqilQhQoUogIUK VChSEUqEBCKVCFIUKVChQoUohSFClQhSEUqEBCKVChQiIgCIoQEooRCmNFv91g9H5T5U7tB6 Pynyrz+phuZ9X/T8x57fbL3GgpW/3WD0flPlUjFx/R+U+VPUw3SL/peYf47fbL8pz1K6IxMf 0PlPlUjDxvQ+U+VT1UN0ir9C5p/jtfFL8pzVK6fc8b0PlPlUjDxvQ+U+VPV290vq95r9v82/ x2vil+U5ildPueN6Hynyqe543ofKfKnrLe6X1e8ft3m/PZ+KX5TmIun3PG9D5T5U7njeh8p8 qest7pdi94/bnOfMs/FL8pzVK6Pc8f0PlPlU90x/Q+U+VPW290uxe8n7c5z5ln4pflOcpC6H dcf0flPlTusHo/KfKr623ul2L3j9t858yz8Uvymgi3+6wej8p8qd2g9H5Snrbe6XYveT9t85 8yz8UvymkFK3e7w+j8pTu8Po/KU9bb3S7F7yftrnPmWfil+U0lIW53eH0flKcCL0flKett7p di94/bXOfMs/FL8pqUU0W1wYvR+UqeDF1fKU9bb3S7F7x+2uc+ZZ+KX5TVopWzwY+r504UfV 86ett7pdi94/bXOfMs/FL8prKaLY4UfV86cNnUnrbe6XYveT9tc58yz8UvymCiLPw2dScNnU r623ul2L3j9tc58yz8UvymBKLPw2dScNnUnrbe6XYveP21znzLPxS/KYUos1jOpLG9Sett7p di95P21znzLPxS/KYkWWxvUlrepPW290uxe8ftvnPmWfil+UxIslrepLW9Sett7pdi95P23z nzLPxS/KY6JRZLWpaE9bb3S7F7x+3Oc+ZZ+KX5THRSr0CWhPW290uxe8ftznPmWfil+UooWS 0JaE9bb3S7F7x+2+c+ZZ+KX5Siiisi9R8QqisoQEURSiAhFKICFCsoQEJRTREBFFFFaihAQo orURAVSimiICqKUQFaIpRAVooVqJRAVUKyhAQoos0ePPL9Wwuruos3szLG17bPHXyLDuQWbR 1jZuyyg/sNNQtv2fLTzm1+FYpcaaLa5tR1jaEVyDyZZWLsVVxf2mFQVKFaOZVQpUIUhFKhQp BUKyhCkKFKIUhQpUKFCIoQpKhEQBERAb6KEXzT9lUsFYKgVgozUWXCsFQKwWWdossFZVCkLL O0WdjG5bzsjQp9dZJEMXHcWPYS7iEgtGwWW/jdapoGgZmv5j8PDfHHJHGZSZS4NtDmt/Fa7b 2l7LlTDgzuQczFyMlmHFLO4PyZKWsoYjU3OaOim9bfJfLul6XqkuRh6zBqUjoHRmCGy4NL43 X9mWTYLabuldlZq4bmscT5tz9ScIcym/7luco2+42qYZvI8PpPLGfqsmbHjyRMOnis3ELgDQ uHYtY70elaOm4E2pZ0ODAWtlyHWMc8kNBPXQE/Iva8i/vfMX5J+eVeZ5P/xNp36YfMVjQu5/ M2n2npXM3G+aWH9mEJQw2uGp/WZcfk/U8jXcjQmSwDKxmcR7y5/DIow9k2XfjjoWlrmh5mh5 3cswsdIWCRroyS0tdUbLmtO8dS97pX//AE3VP7P/ALuOseo6d/MOVoecBdw8ubFyj02QvfI0 H/Vjd8a27KcXTxaml1J0PNH9RuRuw4lOE7MJyw/HKDl9x5jVeRtY0rS3anlSQGFgYXRsc8yC 8hoFDGBsLtu1ZtO93etajgwZ0E+K2LIYHsa98gcAeukRHyr1HNOf3/kzU5q1azLMTD0Wx5DW Np8AWCfSMHVeTdFizNRi0xkbA5sk1tHG0i0XyRrTtQ1OiqtOrOm3ec48/wAw7UXOatyd+VqU lb10SjXwrPE83rHIOsaRp02o5M2M+GC25sbnlxvc1goHRtG93Wtz/K3mD7Rh+vJ/yVz9c5a0 nTMHvOJrePqMt7W93isuod7uzM87PEt33X/4il/sr/68awox1qLjSv8ANU73L99crK9bvqfD 1N1suFcqKknh1mnrfI2r6LgOz8qbHfExzWlsTnl1XGg86No+VcTBxJc7NgwoS1smTI2JhfUN BebRWgJosz8PJz9ZlxMRnEnmnkbGyobU3OO9xAXZ07lnXNH1vSsjUcbgRPzYY2uvjfVxddSk b3HcFjTWXdi1GtHt+s9HGdu21dvQlecXOCooPLDu1dTb/wAreYPtGH68n/JXCyeWtUxNYg0f JY2LIyXsZE8msbrzaHXAHZXwL23MfIur6rzDJqeNkwwQvMdri5/FbYxrSQGspWo2dpYOY9Sw svnDQMXGlbkPxJoxNM0hwLnyMo2o2VFtT411laiq4ONJJLHxHisc/ek40uRvarUpzUYaeFJR qqvbjgc3/K3mD7Rh+vJ/yVwNc5e1PQshsOewASAmKVhuY8A0Np2fEQvac08r6PqGuT5eVruP gSyBl2NJZc21jWit0zDtAruWn7wGTti0fT7XPwImtYzUHuDjK4hja9kn8UV27/gSdqKUqKml 4Ota+4vK89dncsqVyNzixbnHhu3ppGvdk/F7Dh6LyTruswDJgYyDHd5ks7i0O/JDWud8NKLH rvJ+taHGJstjJMckN48JLmAnrqGuHwhd/wB52RNjy4OlQuMeDHAHCFpo0kEsbUdNobsXkvbW q+zvZnepO5VrwK9noNOunZ3blicYRbjR1W3p6j0ctd5q9GF9Stq3N/43F1UP6vN7DSXQk0TL i0aPWZXMjx5pDFCxxPEeRWrmttpaKHpWgxpe9rG73EAeMr2XvIDcN+l6TFsgxMarWjYCSbK/ /bWYxTjKT2U7Wdr16Ub1m1H/ALHJyf8ALBY9rocHXOXc3Q24zst8TxmMMkfCLjQCnnXNb6S5 2NjT5WRHjY7DLNK4MjY3eSV7P3lfV6N/Z3fNGuFyZqGJp3MeJlZhDIQXMMh3NL2uYHHwbdqs oJXNOSqjnY5i5Pk+M1ruaZtJbXFui+o3sr3ccyY2Icq2GYtFzoInkyAdOwtDTTwFaPL3Kepc wMnfhyQxjHLWvEznNJLq0pYx/Uvf6VoGXhc15OsSZ8b8bULzBCHEvkDu2G02AiNu6hOxeA1H SMjO5szdN09l735UoY0bGtF5JJ6mtW521Gj0vNx01z3Hm5fnLl1XIcWCcYRu8XRhHzRcW9m8 6/8AlZzB9ow/Xk/5K8hLG6KV8TqF0bi0kbqg0XvNc1LE5P0kcv6Q67UZm3ZmUNjm3Df4HEea OgeFeAWbqimlFUf4sa+w78jcv3IynckpW2/7T06HJeamOD2HqtP93Ot6hgwZsM+K2LIYJGB7 5A4BwqK0iI+Vauu8k6poWLHl5s2O6KWVsI4bnkguDnVN0bdlGr12XpGFqvJmiw5moxaYyNkb 2yzW0ceGRaL5I+uq8TzFoen6R3fuWqQ6px77+Db9HZbS6ySTzrvkWpwjGNVHYsdW/oOHLc1d u3dMryXfnHh8F5Rr/wBmRq61ouZouZ3TLtc5zGyRyRklj2O3OaSG+LctBe15kjGdyJomqP2z wHu5cd5Z22bfhiC8UsTik8Mmk17T18redy3WXjhKVuVPNF0IREWDsERSgCIiFKopoi+0fzch QpRAQilEBFEU0SiAhQrKEBCKUogIoilEBVFNEogIooopolEBWiKaIgKorUUUQFUUoUBUrexM WJhEk7bzvDNwHjWDEgM84YNzQXu8TBcVv2utL6G1u808FfmC89+brpXtPfydlU4jVXsMrsmS lrKRt6mbPjO9YamtelbWg6PPrWbY5xixo6GZw30O5rfCV6vI5H0WRlIeJjv6HteXbfCH1+Re aU4xdGe+MJSVUjxdetQQCKHaCunqfKer6dWWH9sx27S5gNwHhZtPxVXHY+SZwjia50h3NaKk /AFpNPFOpl1WDVDVlx2ivQtVwFdi7mVoGsY2Gc/Ix3Mx20ucS2oBNAS2tRtK4Z3rvYda41oe HnEopYUbKqFYqF3PIVRSoUKQoVlCFIUKSoQpChSiFIUKVCgCIiFCIiA3lCIvnH6+pKsFUKQo zcWXCsFQKwWWdosuFYKgVgss7RZ67Ttc0uHkTN0mWe3PmkLo4bHmoJjPnBtv4p6Vh5B1jTtH 1ibJ1GbgQvxnRtda59XF8bgKRtcdzSvMKVriOsXh3FRHJ8pbcL0KypzEnKWVU3uw6D03LPM2 No2t5c87DLg5peyQtG0Auua600r4Quvhz+7fScwari5ORPPFV0OKWvIa4+jdGzd/SevBKUjd aVKJ0dVVZEuclCcnLXct64qE1CVFNLDvYHsOXOaMFvN2brWpv7rDlRvDey59Kujsb2GuPmt3 rb5V5w07TcHVIsqa17ppMjCaWPdc54OyrWmm0DfTevCIiuyVMsKvtJc/T7FxST1JSVuNE8lb yp956qPXdO/kPI0mSf8A7hJNe2IteajiMeTfbb0HpXSbqPJmp8uabpurahLjyYbAXNhY+odS 0gngvB+BeDUIrr3J93TjuEuRtutJzg+JK9WLVVKSo6YZHqNVwOQotPmk0zUsmfNaBwYpGkNc aita47OjwrHyHq+n6RrUmVqEvAhdjvjD7XP7RcwgUY1x6F5tFNfeUkkqbsjb5ZOzOzO5cuK5 nKTWpdWBtTZcjNQlysSV0buK98UrCWOFSaEEUI2Lf03Xs12rYEuqZ082Lj5Mcz+NJJKGhrtr g0l22nUFxkUUmn9Z1lahKNGvw6a7adZ2+ctRw9T5hyc3Bk4uPIIwx9rm1tja07HgHeFp6Fkw 4mtYOVkOshgyI5JH0Jo1rgSaNqVoIjk3LVtrUkbMY2VZTelQ4ddtKUPf6y/3c6zqEmoZWq5L JpQ0ObGx4b2WhgoHYzjuHWudzfzFpGVpmFomi3yYmGQ7jPBFS1pY0C+jvxiTsC8ii07raeCW rNo89vkIQlbbuXLis+CM5LSsKbEj3A5h5X5j07Hx+ZjLiZuI21uXECbhsr5rX+dTaC3xLQ1v M5Lx9KOnaLjuy8lxB7/MC1zfNqakMcd1KWgLyyI7raxSrSmqmJYclCEk4zuKEZalbU+4n1Z0 6KktcWODm7C01HjC9l7yHtzH6Vq0W2DMxqNPhab6f/cXjF0JNby5dGj0aVrH48EplhkIPEYT WrWuupaak0opGSUZRe2najd21KV6zdj/ANbkpL+Wax7HQ9pq+ocha7Bh+0NSmikxIrAIY5Bt IbdW6B/org5g5L0zLwsrSppdUYyWuXj5DeyY6dAdDGCV5lFZXW8dMa7zna5GNtKKu3XDHuOS 097PJV2n0GPXOQ9Iy5tb0viS50rC2PCawxxxlwFaAsa1u7btPgVOTuYuW8DGy8zUsngatnSv dLII5HuDXG4WkRvaO0a/OvAoqr0k00o4Vwpv2mZfptqUJQlcuPXpTk5Jy0xyjlke1nwvdtkT Pnn1rNkllcXyPc1xJcTUk/sq4TsblkaRlyty5jqjJi3EgobHw3tAc48LfZcfOHiXHRZc6/hi jrDlnD/uuyo4vvOP4dmCye09XzBrml5nKWk6djTcTLxbOPFa8W0jLT2nNDTt6ivJqUaQHAkB wBqWmtD4NlFJScnV7qG7NmNqLjGrTlKWO+Tqez5kl7lyLoemO2Sz/tJb0hlHP2/rQvFrf1rW szWswZeWGMLWNjjiiBbGxjdzWglx8O9aCs5JvDJJJewxytl27dJeOcpXJU3ydQiIsnegRFKC hClEQtCKIiL7R/NiEUogIoilEBCKUQEUUKyhAQilEBCKUQFUopolEBChWUUQEUUUVqKEBVFZ RRAQoorKEKb2iZMeNml8jQ5rmhhBFRRzgDX4F6HOycSTTnlwDKxskIb0mSslg8Js2nqXL5a5 fj1bjyTSujZEWtDWUBc4gu3kGg+BYNaxZsGQYpc98YNGhwAcC3oNDQ7HAgrw3dMrrSeKPrcv GUbEW1g0em5EkZ3CUUF4nJcekgtbT8K9avLcus9l4LIZcTJ4r3Xzlsd+07vMJ3BZ8vUZsufK 4WK+TGw4hLM3IfJjbNt1I3R0eNg3npXmcHOb0qtWezWoW46nSiPQhzS4tBBcN4rtCgRRNcXt Y0Od5zgBU+Mrx/A0zPxYskaVNiiW7gZeG1lwcwlrrTA64kEbrV3Rq+NFpsJw5m50/DYGB8gY 8ggDiS3dpo6XbElbccMa5NMRuqWOFM00ZOY4+JoGoM3/AED3eoL/APdXyJfT9Tyc4aJnSTTw SNfjytIYwhvbY5tGuvd19K+Yr2cl4ZLpPm/qWM4P+UqVCsVVeo8BChSVCFIQqVChSqKSoQpC hSVCFIUKUUKQiIhQiIgI4knpH4yp4knpH4yqKVnStyOnFueeXay3Ek9I/Gp4knpH4yqqU0rc hxbnnl8TLCST0z8ZVuJJ6bvjKoFKumO5E41zzy+JlxLL6bvjKniy+m74yqBSmmO5dhOPd+ZP 4mX4svpu+MpxZfTd8ZVUomiO5dhOPe+ZP4mXEsvpu+Mqwkk9N3xlUAUhXRHcuwce98yfxMuJ JPSPxlTfJ6R+MqoUhNEfKuwnHvfMn8TLXv8ASPxqQ9/pH4yoopATRHcuwce98yfxMm9/pH41 Nz/SPxqETRHcuwnHvfMn8TLXP6z8am53WVUKyaI+Vdg4975k/iZIc7rKmp6yoopTRHyrsHHv fMn8TFT1lTU9ahSroj5V2Dj3vmT+Jip61NSiJoj5V2E4975k/iYqVNSiJoj5V2Dj3vmT+Jja m1FKaI+Vdg4975k/iYRETRHyrsHHvfMn8TCKUTRHyrsHHvfMn8TCIiaI+VdhOPe+ZP4mEopR NEfKuwce98yfxMhFKJoj5V2Dj3vmT+JkIpRNEfKuwce98yfxMhFKJoj5V2D1F75k/iZCKUWj kQilEBCIiAIiICEUogIRSiAhQpRAQilEBChSiAhRRWooQEKFZQhSFFFZQgO1yplSx55xY5BE 6ejoi4VYZGBwDXbRsc1x+Gi2s9uXlanjZ+TA9kAyWslDhQNo5nZ2gGlo37qrzbXPY4PY4se0 hzXDYQRtBC+gaDlZWdhQPzZBM3JgcbbQBWOQxPr19C8XMx0S4ip3sGfV5C5xIcJt1hit1D0M HmHxrRytPyTNPLCWSsyKXRPc+MijOGQJGXbCOi1bUUlpodxWwvFFtZH0ZxTzOS6LPiwTiYuO YXBhZC7jB8MNRQva0kHZWuxu1a+fy3gjQ+BBisL428W1jAHvLRW0ObQ3O3Lq5jpwAGCsZ2PI 3rYE8cttlTs27Ny3rl4q7anPhx8NMKUPmuvY2Bg6VHDivifLNNdKSGtnaxrAGMLCxjmioJd4 V50bl7P3ga0yWVmjwG5sDuJkuG7iUIaz/VB2+HxLxq+lZcnBSlmz43N6VccYOqj9pBCqVdVK 6HnKlQrFVQEKFZQhSqhWUKGiFVWUIUhQpUKFIRSoQoREQFVKhSoUKQgUqkJUhQFIQySFKhSq QKwCgBWQAKUUhCEgKQgClATRSFAVlSBFKICQpUKUBKJRShApRSgCIpQEIpRAEUohAiKVQQil EARFKAhFKICEUogIRSiEIRSiAhFKICEUogIRSiAhERAEREAUKUQEIpRAQoUogIRSiFIUUUog KopRAVRSh2ICq9/okZg0LTJmgl0TJXyAbawyPukp4WktctHlbkxmdpGZrOoMc6JkUoxMcb3v a09t1Op2wDrXqH8GFuHLBQQNLYgW7W8OQWsp/r2Lxc3NNRit7Z9P9PtOLnN4OiVA1zXtDmkO a4Va4bQQekLM2PiwOYXOZXc5ho4U6QVoTY02A8vxGcTGcS52MNhaSakxV2f6vxeHbws3GniJ ieDaaOBqHNPU5p2tPgK8NKYo+o3VU2mk7P1OCV0NIMwsJ2B/ClI6Kto5tfiVNc16fTtHfmtg dDO8iGDiFppI8E3UYXCjWtJ8a690RcDsLhuPV8K8V7wNThlkg02Jwc6EmWem2jiLWN8dCSfG F2sR13IqnSzz81c4dmUq0dKLrZ497nve57yXPcS5ziakk7SSqKxUFfUPgkUVSrKCgKqpV6Kq AqilQhSpUKyhQpUqFYqEKiqhWUIaIUKVCgCIiFIClQpQBWUBShGSpUKwQyApCKVQArBQArBC BSECkBASFIRSEAopRSqQKQEUhAFKKUIFKIgClFKAIiIApREAUoiECIiAIpRAERSqCERSgIRS iAhFKICEUogIRSiAhFKIQhFKhAEREAREQBQpRAQilEBCIpa1znWtBc47gBUoUqiuIpSGkMcQ 82tIB2nqC2MrS9RxI45MnHkhZKbWFwpU9VN4PjWdUcqrE0oTabUXRZ4GooV3scxxa8FrhvBF CqEtG8gKmaPIKEBLvMa5/wCSNnx7llZjTO2vpGOobT5FHJLabjam9lOsxdNN5O4BbOHj3OMr xsaaNHhG8/ArcNsTHFgqQCesmi2YWBkTWg1AG/r8K5ym3gei3ZUcXiz3/u61Vr4JtJkP0kRM 8PhY6geB+S7b8K3NV5dnxopvZjTJhy1L8NtL4nHbxMatBsPasPT5vUvAabqGRpmdDnY+2SF1 bTsDhucw/lDYvr2n5+NqOFDm4rroZ23N6x1td4WnYVhxUlRneMnF1R5jAy49Qw2S+a/a2VhB BZI3svaWuoRQ9axT4UD5LpGfSAUEjatfTqD20dT4V6LUdCxsyQ5ULji51Kd4jFbgNzZWbnjx 7R0ELgZOVLiPnxs6EuyMZnEJxvpGuadxHSwn0X/GRtXju2JQdVij3WeYjNUlgzxvNkubg5jI 8TJyI4HRNLxxZCA5zn07RcT2gz5F5g1JqdpO0lfUNU5akyuTs7Lntkzp7M5nCcHtYyEEsiY8 bHfRl20b3ONNi+YvYWOoekVaegg7ivdy60wSaWqmLPlc5WU3NNuFcFuMZUKxULseUqoIVlBQ FCoKsoKAqoKsoQFSqqxUIUqoKsVUqGkQoUqEKQiIoUhFKIUgKQoClASFKBSEMsKwUBSFSEqQ ikIDLBiZORXgxOkpvLQSs/svUfs0nqlew91uPjz5GU2eJkrQwkB7Q4A1j27V9F9l6Z9kg/Vs 8i5SuNNqh3jYi4p1eKPhQ0vUfs8nqlW9mah9nk9Ur7n7L0z7JB+rZ5E9l6Z9kg/Vs8inFe41 6eO9nwz2bqH2eT1Sp9m5/wBnk9Ur7l7L0z7JB+rZ5E9l6Z9kg/Vs8icV7ienjvZ8O9nZ/wBn k9UqfZ2d9nk9Ur7h7L0z7JB+rZ5E9l6Z9kg/Vs8ivFe4enjvZ8P9n532eT1Sp9n532eT1Svu HsvTPskH6tnkT2Xpn2SD9WzyJxXuHp472fEO4Z35iT1Sp7hm/Z5PVK+3ey9M+yQfq2eRPZem fZIP1bPInFe4emjvZ8R7hm/mJPVPkU9xzfzEnqlfbfZemfZIP1bPInsvTPskH6tnkTivch6a O9nxLuOZ+Yk9U+RT3HM/MSeqfIvtnsvTPskH6tnkT2Xpn2SD9WzyJxnuQ9NDez4n3LM/MSeq fIncsz8xJ6p8i+2ey9M+yQfq2eRPZemfZIP1bPInGe5D00N7Pincsz8xJ6p8idyzPzEnqHyL 7Z7K0z7JB+rZ5E9l6Z9kg/Vs8icZ7kPTQ3s+J9yzPzEnqHyJ3LM/MSeo7yL7Z7L0z7JB+rZ5 E9l6Z9kg/Vs8icZ7kPTQ3s+J9zzPzEnqO8inueX+Yk9R3kX2v2Xpn2SD9WzyJ7L0z7HB+rZ5 E4z3IemhvZ8U7nl/mJPUd5E7nl/mJPUd5F9r9laZ9jg/Vs8ieytM+xwfq2eROM9yHpob2fFO 55f5iT1HeRO55f5iT1HeRfa/ZWmfY4P1bPInsrTPscH6tnkTjPch6aG9nxTueX+Yk9R3kTue X+Yk9R3kX2v2Vpn2OD9WzyKfZWmfY4P1bPInGe5E9LDez4n3PL/MSeo7yKe55f5iT1HeRfa/ ZWmfY4P1bPInsrTPscH6tnkTjPch6WG9nxTueX+Yk9R3kTueX+Yk9R3kX2v2Vpn2OD9WzyJ7 K0z7HB+rZ5E4z3IelhvZ8U7nl/mJPUd5E7nl/mJPUd5F9r9laZ9jg/Vs8ieytM+xwfq2eROM 9yHpYb2fFO55f5iT1HeRO55f5iT1HeRfbPZWmfY4P1bPInsrTPscH6tnkTjPch6WG9nxPueX +Yk9R3kUdzy/zEnqO8i+2+ytM+xwfq2eRPZWmfY4P1bPInGe5D0sN7PiXc8v8xJ6jvInc8v8 xJ6jvIvtvsrTPscH6tnkU+ytL+xwfqmeROM9yHpob2fEe55f5iT1HeRO55f5iT1HeRfbvZWl /Y4P1TPInsrS/scH6pnkTjPch6aG9nxHueX+Yk9R3kTueX+Yk9R3kX272Vpf2OD9UzyJ7K0v 7HB+qZ5E4z3IemhvZ8R7nl/mJPUd5E7nl/mJPUd5F9u9laX9jg/VM8ieytL+xwfqmeROK9yH pob2fEe55f5iT1HeRO55f5iT1HeRfbvZWl/Y4P1TPInsrS/scH6pnkTivch6aG9nxHueX+Yk 9R3kXo+SsJseVlZeQ0tkxoxYxwoaPuucAfyaL6X7K0v7HB+qZ5FV+j6U9jmHEhF7SwubG0Oo 7fQgVCzcm5wccqnSzahbuRnjLTsZw22xNhja0OcbpC1vTsJc4dG1zvlVBmQPy+A5rmzwsMhY W3EAm0Gsdwr4K1XUHLkUYdJBMWZB3PLGllDvBjbZWp2k1r8GxUi5bME0jocjszlrpnvZdKSG hpo6oHRUbKDqovJwJHv9TDq9h8950rm6lE7CaZWiJrHysBcAbnkg06W13LlR4DYx2cd5d0ud G4k/GF9nZpGmNbQ4sTz0vexrnE9bnEVKn2Vpf2OD9UzyL1RwjGPlR45Uc5T8zqfF33RUEjHs BNrS5rgD8iFex95mLi4zNO7vDHDc993DaG1o6KlbQOteOKpCpVGufG4cPbcfq+vwjqVyqwOa yQtf5zz2X9f9FUhtLuco8yz6NnjEmrLp2Walg2ujlA86MdNwG1vT0bdh4aq9pc2gJa4bWuG8 OG1rh4igPsOqaszF0eTUMS3Ic9rRiBpBbJJKQyEV6i5wXxjPmZIHTZbr8qZ10j5B2y+var0+ DwL6TylZrGHi5jZBG2CYvzsGlWd5a1zb4/Quc68jcTQ7DWvjObsKCDmjV+G3zntePA58bJpK eNz6rle8KbbweSPpfpMnxpW1GEncj4pqumnR0nq+R3ZOnYmJpmc4vw9Ux3ZOJduYSL3w+J0b rh4nL56/Box2K89uB1GPIobSA9hI8LXDYvqPLOLja1yjpgnLgccFjXMIDhwi/Hc2tNgdHVvX Q7F47nKBsPNWeGi1sghkAFKfVNZsp+SuiyR8+5jKSedXXceOkY5jyx+xzd4VVfMjkZO6/bcS 5rusf6FhD6ed8a6xnvPJOw1jHFbiygqyqVs4lSoKsqlAVUKygoUqVVXKqUBUqFJUKFRCgqVC GiFClQoUIiIApChWCBhSEUgKmSVKAKUAUhFICA9/7p/3rL/IPzxr6S91jHP32gmniXzf3Ufv eX+QfnjX0af6mT8k/MvPPxM9lvwR6keWZz6XxPnbpkzoIyBJK11Wtr6TrKBb+fzbiYuk42qQ xOniyXWBlQxzSAag7DuLaLxGFn6pi6Jmx48THYU7hHkTEVc1zhsA7XSOmi6WvYTMLk/TI2SC XiS8UvG4mRjnbK9Q2JRFqeg0/mzKzcuHHOlTwsmIHGdW1oPT5gWiz3hmSJ87NLmdDFTiytdV rK7rjZQV8K6PLv8AM98ftLg9x4I4dlLq0bZX4F4rQPbs2nZ+DpWK3Ijyg1k7yQC2ocBS5zRt 2pRFPa5fOml4+jQ6q0Ok7yS2KDYH3t88O30t61h0fnaPO1Fum52FJp2TKKwiQkh1RcAbmMIq N2zavJ6xo8+jt0XFyyCXvfJIBtaHOfHc2vTRobVdbnMkc5aMY/rPoKU3/XmiUQqdLO55kx9V yNMx9LmzJcYkO4TiSQKVda1jiBtUxc+Q5OlHOwsCbJnjmbDPiM2uZe17g+rWuq3sU3LzOTna rgc56tl6VCyeaJsrpGybQImhrnupeypFF3fdniU0/L1J0okkzZQ2Rg/EMVx7XhPEr4qJRUBG ne8V+oZTMeDSJ3AyMjke11wjvNtz6R7F7NeB91v7zrX5cPzzr36jCCIihQiIgC4Oia1zDrWl 4+qYum4bIMlpcxsubKHgBxb2g3CcOjrXeXJ5CxpMXk7SYpCC52O2UW1pbLWVu+m2j9q1FJmZ Ogbm8zOy5MQafg8SKOOVx77LbbK6RrafsO/6I1SfN5mglx4n6fgl2TIYmUzZaBwjfL2v2HdS MrvrVy8aSfIwpWEBuNOZX1rUtMM0XZ8NZAtaUTUzlZmbzNh4k+XLp+CY8eN8rw3NlLi1jS40 rgjbsWW/mr7Bgf8AXTfcF2kTShqZwMXN5myonSx6fghrZJIjdmy1uikdE7dgnZVmxGZvMzsu TEGn4PEijjlce+y22yuka2n7Dv8AojVdXTsaTFx3xSEFzp55RbWlss0krd9NtH7VtJpQ1M4E +bzNBLjxP0/BLsmQxMpmy0DhG+XtfsO6kZTMzeZsPEny5dPwTHjxvleG5spcWsaXGlcEbdi6 uXjST5GFKwgNxpzK+talphmi7PhrIFtJpQ1M43E5q/h+B/1033BYcXN5myonSx6fghrZJIjd my1uikdE7dgnZVmxd9aunY0mLjvikILnTzyi2tLZZpJW76baP2ppQ1M5Tc3mZ2XJiDT8HiRR xyuPfZbbZXSNbT9h3/RGqT53M0EuPE/TsEuyZDEymdLQOEb5e1+w7qRld9auXjST5GFKwgNx pzK+talphmi7PhrIE0oamcrMzuZsPEny5dOwTHjxvleG50pcWsaXGlcEbdizcTmr+H4H/XTf cF2UTShqZwMXO5myonSx6dghrZJIjdnS1uikdE7dgnZVmxG53MzsuTEGnYPEijjlce/S22yu ka2n7Dv+iNV1dOxpMXHfFIQXOnnlFtaWyzSSt3020ftW0mlDUzgzZ3M0EuPG/TsEuyZDEwjO loHCN8va/Yd1IymZnczYeJPly6dgmPHjdK8NzpbiGAuNK4I27F1MvGknyMKVhAbjTmV9a1LT DNF2fDWQLaTShqZxuLzV/D8D/rpvuCxYudzNlROlj07BDWySRG7OlrdFI6J27BOyrNi7y1dO xZMXHfHIQXOnnlFtaWyzSSt3020ftTShqZz8fUNVbqkWn6jiY8HHgmnjkx8h8/1D4GOa5r8a CleOKGp3LqLm5hB5p08V2jAzqj/3cBdNYaxNJ4BERAEREAREQBERAEREAUoiECIioCIiA8F7 1vqdO/Kl+eFeJa65od1gFe296/1Om/lS/PCvDQGsQ8ZHxEqoFisb2hwIO0FZCqFUhaCdwIil NSfMf1+A+FbK0XNDhQrLj5BqIpT2vxXel/pQHpeSdW9ma82F7qY2ogRPHQJW+Y74RUfEsfOD a806n4Xxf/zwBcV4cW9g2vaQ5jhva5pq0/AVnn1CTU8ibPlbZLO6sjR0Oa0Rn+quPMPue0+r +hxrzdfLCT+w9x7rskv0XKxHHtY2S6g6myNa4f7Vy8/z1T+ackg7eFCD6pP4Vn93ecMTmGfC caM1CKrB1yRVcB6peubzjltdzFqk582ORsbR+jijZT1gVu3KsIs8nP2na5q7F+ZyXVLE89qc rLRDQF9Q4n0R/pXNKyPc57i95q5xqVjK2eYmM72/ErlY4vPPiWQrrDI8d5JTdOsgqpVioK0Y KqFKFAUKhWKqUBUqCrFVKhSCqqygoVFUUqFChERChSEUhCAKwUBWCpCQpUBWQBSFCsEB773U fveX+QfnjX0h7b2OZWlwIr418391H73l/kH5419JXnn4mey34I9SPO4XJ8eNpGZpkmTxhmEE ScO2xzfNNt5rQjrWOfk2WfRYNJkz6jGlMkcvC/FIPYt4nW47ar06KVZqh5zTuVtVwsuCaTW5 8iGEgnHcHhjgBS3bM4U+BbHLHLXsBmQzvPee8FprZZS2v9N1d67aJUtDk8ycuY2v4jYJXmGW Il0MwF1pOwgt2VBXM0jkqTG1RmqannP1CeEAQhwIoQKAkuc4mnQF6lEqDgYfKjcfmLL1p2Tx W5bXsdjGOgAfb+Pea+b1Jyvyq/l5+UGZhyMbJIc2Ex2lhFaG691dhodi9AiVB5/lXlT+XpM1 /eu9d9LHU4fDtsMh9N9a3r0CIoAiIgClEQBaPKf+FdG/sGL/AMFi3lxeWNa0eDlvSYZs/Gil iwsdkkb5mNc1zYmBzXNLqggrcNpmWw9Eiw42ZiZkZlxJ48iMG0vie17Q4CtKtJ27VmWjIREQ BERAEREAREQBERAEREAREQBUlljhYZJDa0dP4AommjhZfIaCtABtJJ3ADpJWKKGSV4yMkUcN sUW8M8Phd1/IsyljpjjL6l0slTG3KlypOHjHhWNrMZG1c1xPZZbUbd5WTu2QfPypPE1rG/7p K2FqT6vpONK6HIzceGVlLo5JWNcKioq1zgdxUUPM230NpdgpvNCWCODmbT2srV2DnlziaucT NgbSV1lxjnYWbzPguw8iLJbFg5okML2vDS6XBtusJpW00XZUaSwWBuOQREQoREQBERAERSgF ERFSBERAERSgCIiA8D71/qdN/Kl+eFeExjWL4XfKSV7r3tOtxtPd1GU/LCvB4otYG9QCqBmK oVcqhVIVKo8AihVyqFCmfGyC48KTz/xXekPKskf0eQ5v4swuH5Q3/GFouFfB0gjeCs8c7pWW H6+Pts/pU8u4rM46otHo5LmHy/MW7uyL739LwZtHKmwczHzsd1s0Dg9h6KtNdvgPStLVc5+b O+d4o7JkfkyDqMrnPDfgqsueRJDHadkhpXwEVJ+Jc+R17i/dcagdQ6B8S58unp9p7v12UHzE VGldFW1ueRjKoVcqhXY+SWiG8/ArlGNowde8qSu0VRI8VyVZtlSqlWKgqmSqgqygoChUFWKq gKlQVYqpUKVKhWVShUQoUooUjYiIhSQrKArIZAVlAVgqAFKKUACsoCkID3vup/e8z8g/PGvp S+be6j98zP0Z+eNfSV55+Jntt+CPUgiIsmgiIgClEQBERAEREAUoiAIiIAtHlP8Awro39gxf +Cxby0eU/wDCujf2DF/4LFuG0zLYdZERaMhERAEREAREQBFCICUREARFBIaC5xoBtJPUgKGe ETCAuHFLbwzpt3VSeeOBlz6kk0YwbXOPU0LVZjuyIXZINk8rhJE4/ihuyMHwU3+MrNBjvD+P kEPnIps81g9Flfn6VzUpvZSuKfR09JKsiGCRzxkZNDLTsMG1sYPQOs9ZWyiLcYqKov4lSCIi oORmf4o07+wZ3/GwF0lzcz/FGnf2DO/42AuksSzNLIIiKFCIiAIilAERFSBERAERSgCIiAIi ID5/72yBi6eTtAdLX44V4WE9rxhe697bbsXT29ZlHywrwGC66Np6QKfEtLIhtFUKuVQoCpVC pkJDSRvAr8SgkEVG4oUoVQ1BBBo4GoPUVcrHIXgdgXOO4IC0kxeLTQUrRvVdtd83yrC5QC40 LhRwND8SlyiSWRZTlJ1k6uijjuiqIoVRgueAd1TX4FcqIRVxPV+ErUc0c7jpCT6DKoKlQux4 iCqqxUIUqoKsqlAVKgqxVSoCpUFWKqUKVKgqxVSgIUKVCGiEUooCwUhApQhIUhApVAUopQEh SoCkID3vup/fMz8g/PGvpK+be6n98zPyD88a+krzz8TPbb8EepBERZNBSiIAiIgCIiAKURAE REAREQBcXljAypOW9JkZqOTC1+FjubExuOWtBiYQ1t+O51B4SSu0tHlP/Cujf2DF/wCCxbht My2HQxoJYIyyXIkyXE1vlEYcBTzfomRinwLMiLRkIiIAiIgCIiAIiq97I2l73BrW7S47AEBZ V4kfE4dw4lLrKitOui1+JkZOyEGGH884dp35DTu8bviQ6fBa0MLmPaS7iNPbJIobnGpNVjXJ +FVW94V6iV3G0tXM+lsxB/631n6Nvnet5vwqfZ2FvdE156XP7Tj4y6pWSHFx4CTDG2MnYS0U RqclRpJPPGuHYMWZURFsoREQBac+FkyyukZqGRA00pFG2AtFBTZxIHu2+ErcRAcE48sHM+CJ cmXLL8HNLTMIwW0lwa28GOPfXbWu7Yuyubmf4p07+wZ3/GwF0liWZpZBERQoRTREAREVIERE ARSiAIiIAiIgCIiA8D72PqNO/Kl+eFfPcDY6RvU4r6F72PqNO/Kl+eFfPsMfSy+P8AW14faY r36fym0VQq5VCoaKnbsWGE1hb4BT4tizFYIdzx1Pd86FJKodu9XKqUBieKDZ1j51DlaTzSqu QFCkB3jp2FHblQG0g9XzKxdGYuR1RaM5UKVC7HjIKhSoQEKCpUFAVUFWKqVClSoKkqCgKlVV ioKAqilQhSERFCmQKQoCsFSBWCgKQgJRFIQEqVAUoD3nup/fMz8g/PGvpK+be6r99zPyD88a +lLzz8TPbb8EepBERZNBERAERSgCIiAIiIAiIgCIiALi8satiw8t6TE9mSXR4WO1xZi5D21b EwG17InNcPCDQrtLR5T/AMK6N/YMX/gsW4bTMth0MbKiyozJE2RrQbaSxyROrSvmytYabd6z IoWjJKLHLNFC26V4aOiu8nqA6Vh4mXP9U3gRn/1JB2z+Szo/1viWXNJ0ze5ZkqZpZooW3SuD R0V3k9QHSsPEy5weCzgM6JJBV5/JZ0f63xK8OJFE7ibZJTvlebnfB1eILOpSUs3pW6OfaMTF iSOlxYZHmrnxtc4+EgErKuXp5y5IboZAGxARNieOy60bdo2jetqmZkbHjusf4waQ57vE4bGj 5fEs27lYR7sm6dvtIngWlyg15hhbxphvYDQNr6bvxVDMUvcJcpwlkbta0CjGn+i3r8JWaKKO FlkbQ1o6B+FXWtLeM8ejZ/yWm8IiLZQiIgCIiAIiIAtOfVMbHldE9mQXNpUx408jdorsfHE5 p+ArcRAcE5kWXzPguibK0R4OaHcaKSE9qXBpaJmMu3babuneuyubmf4p07+wZ3/GwF0liWZp ZBSiKFCIipAiIgClEQBERAEREAREQBERAeB97H1GnflS/PCvn+GO1Ies/gC+ge9j6jTvypfn hXz3HfbX0g41HjNVteH2mPx//E2yqFA+u0kDwIVDRUrDH/6n5ZWYrEwbHHrcfnohSCqPrQ03 02K5VSgNekgDg5wdsJqFZys8VaR4FQmoBQFHbwVAALgDuJ2qzhUUVGuo5pO7yqrMzKul03Gw qlWVSux4gVClQgIKqVYqpUBBVSrFQUKVKqVYqCgKlVKsVCFKqCrFVKAhFKKFMgUhApCEJClQ FKoJUhQpQEqVClAe891X77mfoz88a+kr5t7qf33M/Rn5419JXnn4me234I9SCIiyaCIpQBER AEREAREQBERAERSgIWjyn/hbRh1YGMPihYt9cLkvKy83lLSXRNbjsbixxGQm8nhDg1a2gG2y u35VpOlcG+ozPYeglnihbfK4MHRXeT1AdKw8TLn+qbwIz/6kg7Z/JZ0f63xLJFiRROv2yS9M rzc7/R8Crk5XAmxYrbu9SmKtaW0ilmru2/V0Sknm9K3Rz7TGJMOJFE6/bJL0yvNzv9HiCzoi 0opKiVChFr4WV3uF0ttlss0VK1+plfDXcN9lVsKgxY2OzGi4TNoq51Tvq4l34VlWvk5XAmxY rbu9SmKtaW0ilmru2/V0WwokkklglgAiLXwsrvcLpbbLZZoqVr9TK+Gu4b7Kqg2ERa+TlcCb Fitu71KYq1pbSKWau7b9XRAbCIiAItfCyu9wultstlmipWv1Mr4a7hvsqthAEWvk5XAmxYrb u9SmKtaW0ilmru2/V0WwgCItfCyu9wultstlmipWv1Mr4a7hvsqgNDL/AMU6d/YM7/jYC6a5 mX/inTv7Bnf8bAXTWXmaWQREUAREQBSiIAiIgCIiAIiIAiIgCIiA8D72PqNO/Kl+eFfO4nAX D+kV9D97JAx9OJ3B0p+WFfOscG0OO81d6x/0LX4faZp3q9BtmWMbAD8SrxG9R+JVRCk3t8Px FVaRbsO3pUqshAaXEVoKoCCqlWoQ0A7TTaqlCmMubW2u3qVB5oUmNoNQKGtSVUbvhPzoCCsZ 80+BZCsZ3kIDYBqAetCqxmrG+L5lZdkeFqja3MhQpUIQgqFJUIUqVBViqoCCqlWKqUBUqFZQ hSpUKxVSgIREQGUKwUKQgJUqFKAKwUKUBKkKFIQHu/dV++5n6M/PGvpK+be6r99zP0Z+eNfS V55+Jntt+CPUgilFk0EREAREQBERAEREARFKAIiIAvOcuYfNGh6Ji6T3TByO6tLeN3yZl1XO d5vcnU39a9BKx0kT2MkdE57S1srLS5pIpc29rm1HhBC8vHG2LlY4zS50TtXdjvD3OeXxP1gx SMkc8uLw9ji11xNwJqqnQjR1Gz82Ny5JzhYRjkjjY2Hv01rXMdI5zx+w73XgHZ0KuS/miebF l7hgt7rKZad9mN1YpYafuOz6yq57XnB9oafp5kxme0m4+HjYccN4BwYMp8eOMgtx4tt8ji4U Pap23Aqul6rqms+zI4c12NFkxai6aZjIJJXtxMqHHheHgSQh5a7tFocw1No80ttWSiOrmTc2 ZGJPBFh4UEksb2MmbnTXMc5paHimCNrd+9Ze+80fw7B/66b7gufoOp6nky6ZJmTtlGr6e/Of ExgZHC5hxbWQ730IyDfe51SKi0bFsSY9nN+JOZJHmbBzAGOd2GNZLgUaxgoBUkkk9o130DQG piiJwnc0YkLou4YL7pZpa99mH10r5qfuJ3X0Vmzc2Ny5Jzh4RjkjjY2Hv01rXMdI5zx+w73X gHZ0LD3DDPMMUmBE1k+O6SbU81u2R5kYWxYcsh7TgeKJQ24hgYzsgOYuNj6/q7eX2Z5z25c+ XomXn8RscQZDkYjYGgRhgO26U8QPLu0NgaOylWKI7uS7miebFl7hgt7rKZad9mN1YpYafuOz 6yqtmTc2ZGJPBFh4UEksb2MmbnTXMc5paHimCNrd+9c3UcvXMH2p/wBw4nsvAbqf1MbeJK7v P7PuNuP+z7tsm363Yu7q8WmSYZOqsbLiRuDnRPBex7j2GMMIrxSXOFrLTV1KC6iVYojF3zmj +HYH/XTfcFr4TuaMSF0XcMB90s0te+zD66V81P3E7r6LnwN1LGm0fRzmey++wZs74GiJ8kbm ywTRYmO6QPZ+zslcwUaWljTRo2FuB2u61kYE2qMyW47cXRMXVjjMjaWvyJG5UjmF0lzhE7hA OA7W61zdt1qxRHZbNzY3LknOHhGOSONjYe/TWtcx0jnPH7DvdeAdnQq5LuaJ5sWXuGA3uspl p32Y3Vilhp+47PrKrLps2czVMvT8vI71woMfKEhY2Ojp35DHxsazdG3gC0OLnbTVzlyMXOkn 58a+ZuTH+zZmJjwvhmbEGQyYruNc5nDrI+/ttdQs4YNHbDKsUR1MybmzIxJ4IsPCgkljexkz c6a5jnNLQ8UwRtbv3rN3zmn+HYH/AF033Bebx9f1dvL7M86g3Lny9Ey8/iNjiDIcjEZA0CMM B23SniB5d2hsDB2Vu6jma7g+1P8AuHE9l4DdT+pjbxJXd5/Z9xtx/wBn83bJt+t2K1Yojfwj zTiQui7hgPulmlr32YfXSvmp+4ndfRWbLzY3LknOHhGOSONjYe/TWtcx0jnPH7DvdeAdnQsf NMUuT7Lw42RStys0xyw5IL4HNGLlSfSxj6wMcwPDdlXNG1vnDn4mXkvn0vScbLbpcUrdShe2 JrHF8mDkxwtGKMniiMUD3COjg2OrRuDmqsUR0sk80zzYsvcMBvdZTLTvsxurFLDT9x2fWVVs yXmzIxJ4IsPCgkljexkzc6a5jnNLQ8UwRtbv3rjO13W8jAm1RmS3Hbi6Ji6scZkbS1+RI3Kk cwukucIncIBwHa3Wubtu7umS5zNUy9Py8jvXCgx8oSFjY6OyH5DHxsazdG3gC0OLnbTVzkqx RFu980/w7A/66b7gsGEeacSF0XcMB90s0te+zD66V81P3A7r6LlYEdus4uZwo2941LOg9oNP 7VPwxm/s2Q20Uhj4XYPFd9WzsN/EwY+v6w3l5medQblz5eh5efxGxxBkORiMgaBGGA7bpTxA 8u7Q2Bg7KVZKI9Bj4+s5GswZ+fBjY0WNjZEDWwZEk7nOnkxn1N+NAAAID0neusvLajma7g+1 P+4cT2XgN1P6mNvEld3n9n3G3H/Z/N2y7frdi9SoyhEUoCFKIgCIiAIiIAiIgCIiAIiKgIiI DwHvabfjac3rdKPlhXz1zH17DrRQClK7l9D97FeBp1N90vzwr580SE0qD4h/pQgZA9w7Urq+ AAJ3Yj/1X/J5FlbG9pqSPErFUGuYp2+bIHeBw8ixSPktsewgkijhtG9bZVChShVSrFUe4NBJ 2AICpWIbvhPzq97XNLhuCoPMHiQEFY3b6rIVRyAvCeyR1FZFhhPbI6wsy6xyPJdVJvpxIUFS oVMEKFJUFAQVVSoKAgqpViqoUhQVZQUBUqpVlBQFUUogM1FICKUAUqFIQEgKaKArBAKKaIpQ h7n3Vfv2Z+jPzxr6Uvmvuq/fsz9GfnjX0TLyo8THfkSAljKVDaE7SG9JHWvNdko6pN0Uatvo R7rSbjBLFuiRmRYcnKjxmNc8Fxke2NjG0q5ztw2kD4ysTdQY+J0jInuEbnMmFWNsLN9xc8D4 iVzd2CelvFKtMzorcmqpYZVNtFqO1KFuB39zHiKgNpAD6F1oNK027962Inue2r43RGtLX2k+ PsOcFY3IyaSdapS9jyYcJJVapRuPtWZdFpDVYHScJjHvl4r4WsAaCTGLnkFzgKbetbME3GYX WPjIJaWSChqPjBHhBUjdhJ0i6iVuUVVqhkRabNUx34+PkBr7MmQRMFBUOJLe1t3dlVh1aGVk MnCkZFkP4ccjraFxqAKNeXbx1LPHtYd5YrUup7frNcG5j3Xg6e3d9RvIsU05iLGtiklc8kAR gbKCtXOcWtHwla3tnFdG18TZJKxOncGgAtY02uJvc3p6qqyvW4ukpUf095I25yVUqm+i0Y9Y xJXNLA8xPkELZqANLyLg2hN/+ysmNqEWQGWse0vNA11KgWCW82uPZo4fCUjftSolJOuCDtXF WsWqZm0ixZWTFiwPyJa2RipoKnbsAHjKxnNtbK6WCWLhRmU3BpBaK1o5jnNrs3ErTuQi6N40 r7PoiKEmqpYVobKxHExTBJjGGMwTX8WK0WP4pLpLm0oby4l1d9Vqs1rCcZG9pr44hNaQAXNL OJRu3eAsntOJwHBikncYxM9sYBLGuFWh1XDtHoA2rC5i08pp9WORp2bizi11k+ytL7j7N7nB 3D7JwmcHzuJ9XS3zu1u3rKzExY3iSOGNj28S1zWgEcZwkloQPx3gOd1naViGoh80kMMEsrog 0vIDG0vFzdkj2n5FsyOcxhc1hkI/EbSp9YtHyrcbkZJtOqVdj2Z03mXBppNUr95jjxMWLhcK GOPu8ZhgtaBZGbaxsoOy3sN2DqHUrmKIytmLGmVjXMZIQLg15aXNDt4DixtfEFqY+rw5D4Gt ikaMm/hPdbQ8PztzyR8Se1oTMIY4pHyGSSINFoq6IAu8542bVhcxaaT1ZtJdbpTtqjXBuVpp yVezP7CYtE0aLMOfFgY0eaXOeclsLGy3Pre7iBt1XVNdqrgaFpeBhdzix43sdBHizvkYwvnj hj4LBOQ0X9jZtW7G5z2BzmGMnex1Kj1S4fKtOHV4ZWQycKRkWQ/hxyOtoXGoAo15dvHUtyuw jTU6asVXd92ZlW5OtFWn0+42ZMTFl4vFhjk7xGIZ7mg3xi6kb6jtN7bth6z1qubp+BqEQhz8 aLLia69sc7GyNDgCLg14IrQlUw88ZjGSRQSCJ9aSOsA2VG4PLt46kj1COV44Ucj4i/hidrQY yR07DdbXZdSiivQai08JeHB49PV0h2pptU8OfR0dfQYH8u6M8wsOJF3WCKWBmEI2d3LZpIZ3 ExW0rfC0j4VuSYmLLxeLDHJ3iMQz3NBvjF1I31Hab23bD1nrWtJrGJFG6V4eGMnOM40Bo4Cp dsPm/Kom1vChe8PuLWOjaZGgFv0rS9rhQ7RQLL5mys7iXt+m4qsXHlB/T+JuiKISumDGiV7W sfIALi1hcWtLt5DS91PGUMURlbMWNMrGuYyQgXBry0uaHbwHFja+ILVdq+K2fggOceJFGHto WkzAuYQbt1Aqw63hTRRyR3HiSthsoLmufW0uFd2zoV9RZrTWq4/VgxwblK6HTD68hgaFpeDh dzix43sdBHizvkYwvnjhj4LBOQ0X9jZtW1JiYsvF4sMcneIxDPc0G+MXUjfUdpvbdsPWetYo 9QjleOFHI+Iv4YyGtBjJHTsN1tdl1KLJFlRy5M+O0EPx7LyaUN4uFNq0rsHSkvE6LpdK4exG Xbkq1WSq+jYTlYmLmQOxsyGPIgkpfDK0PY6hDhVrgQaEVWrkaFpeS+DjY8ckGPA/FjxHMYYO G90ElDEWkdk47bepRLrmHFityHh4ueYzF2eI1za3XNu2U/CFlOpQ957tCx2RJwxKeEWEBp3b XPb1grK5i08pp5YLF97LA07NzbF7c8u7mZ5MTFl4vFhjk7xGIZ7mg3xi6kb6jtN7bth6z1q4 iiErpgxole1rHyAC4tYXFrS7eQ0vdTxlS0lzQSC0kVLTSo8BpULTi1fFlGQWh1MZrn12dtjS 4F0fa7Qq3etyuQjRSdNVaV6MzEYSlWirTP2mVmn4EeZJnx40LM2VtkuU2Nolc0W9l0gFxHZH T0LBgaFpeBhdyix43sdBHizvkYwvnjhj4LBOQ0X9jZtU+2IGtY+SKSNssbpoi6w3tY280te6 ht66LPi5RyWteIZI43tD2PfZQg0I2Ne49PUpG9CTpF1e6j+vcWVqcVVqi6y0mJiy8Xiwxyd4 jEM9zQb4xdSN9R2m9t2w9Z61lWtLnCPKGIyKSWXh8WjLALa273vb0qJdSggmZDO18RfG6UOI q2jQXObVpPaaBVHdtqtZUo9LbyruqFbm6UVaqtFnTfQ20WhFq8czo2RY8znyR8YNoxpsuLKm 943pFrEE7o2Y8UkzpI+MA2wUbcWGt727Q4KLmLTpSVa5YPHq7SuzcVaxyz6Os30WtLmtjfHE I3vnkF3AZaXNaN5cS4NArs379yxy6m2JkL3QTUyC1jAQ1pD3VoxzXuaQdni8KrvW1Wryzwf0 2kVqbpRZ5G6i57tbxWQmaVkkbWz93eCAS14FSTa47B4Fd2rYjXTNqXGHhgW0dxDKLmNjoe0S p6iz519E39zLwbnlf0w+83UWKCcyl7XRSQuYQCJANtRWrXNLmn4CsUmc1uS7GiiknkY0Pfw7 KNu3Bxe9tD00W3ciknXN0WGNd1DKhJtqmSq+rrNpFpe1cfjcO19nG7txaC3i0rbvu8FbaKg1 vFLQ+yQRvbK+J9BR4h2vtF1Ru/GAWPUWvOvph95rg3PKzoIsGPmMncGtY5riHlwNOzY/h0da TvINOuhVM3UsfCkgjnuHeHFrXClraFoJcSRQdpad2Chrcko4Y9eRlW5uWlKsscOo2kWozVMV +ZNiAkOx2l8khpYAKXdqvRXakWpwyOiqySOOckQSvADHnoA21F29twFVFftPKSzcfanT7S8K 55XlX2PE20WhDrEErIZeFLHDkP4cUrrKFxqAKNe529vUsuHqAzGMliglEL60ldYBsqNweXbx 1JG/bk0oyq5YpJPLf1Y5iVmcU21SmDx27uvA8X71/qdN/Kl+eFeAXv8A3skNx9OJ2AOlr8cK +d95g9MLsczYa5x8NOhWKwMlYT2XAnqqs9aiqAqVQq5VChShWGbtUYN7vkA6VmcaePqWOgbV xO3pKAxTODQB1nd4AoBFKDdvHiWCR5e4no6FaN34p+AoDIVRyv4CsZ3oBGaSBbC1m+ePGFsr pDI81/xLqIUUVlBWjkVIUFSVCAghQpKg1QFSoIVjVVQpCgqVBQFSFBCsVBQFaIpRAZ0RTRAK KQFNFIQEUUgKQFNEIQrJREB7n3V/v2b+jPzxr3+p4smXgyY8ZAe+2hdUDY4O6AepeA91f79m /oz88a97q+RLjafLNC62RttrqA73NHTXrXj5rTou66uOmWqmdKY0Po8tqra001VjSuVdgyIc rJitkihDmva9ovedx20e1rCx3URVap0vJ7vwBY6OaZ82TG57tu0FjWyWE02C40qtTI1nNhGY xzgKSvZiy0FQWPbcylPRdvK62o5MsEUTYqNkyJWwteRWy+vat6aUXj12LuuT1NwilKqVe83h 7adVGerTet6IrSlN1ji6YLP2V66mLPxs/MxpIKQsbIwbLnEh4eHedaOzaOret2KGGFtsLGxt JqWsAaK9exc3LzZYMTN4WSZJscx0vjDXMucBQ9kNcD0bFaPOlZPk2vfkQY8HEfxWiN4k2kN8 xho5o6ltXrUbtXqc5RS1PS8E5bup1oZdu47dFRRTbpisWo7+tUqSNOnDJmPZDPHNkSSmN9w7 LxRpa8A2uHi+FbWFDkQxObO+9xe5zRUutaTsZe7a6nWVpOyM5mPizme45pbGW2NtYZhVjmdP Y6nE1Wm/XMt0UEkRH0MYkym1aS/6QRW+b2Sd/wAK58exZdWpxemtMMnTduqb4V64qJxarSuO ePuN2LTMpsOLiuLOFizcbigkucAXOAstoK3eksun6UzHx4W5H0ksJLh23lgdV1C1juzUA9S1 I8/LytRayOcsxpZZYmtYGO2RMa64Pc01uJSDU81+HgvcHB02Q1kkxDLXNLnC0AGo3eiFm3Pl lKqhOWhOEW0mqR0Zdqo2WcL7VHKK1NSaTadXq/5OplRzSNa1jIpYyfpYpq0I6KEB24/0Vzm6 RmRxtDZGSvOK7FfeXNpc4uBabXVArToW1rMs+PgvyIJTG+OmwBpBuc1u25p+Razs3Mhk1GIG ScY8bTHJSMWEsLqu8yu3wFdb7tcSk1PVTBxyxTf/AKMxZVzRWDjSuT6KL/2Ix9GyIGxY97HQ xZDcni7Q42tpbZSm/puWbJ02Uh5xLICTRgY4xANsIr9GPOvIJ6CGha+Pl6nkCRsb7iwYrnUD A4NkZdLZcLbifS2LfwJjLxAZnSFpbWOVgjljq2tH0DQfBs+NZtRsSShGM4qTelyp+Gqot+Rb kr0W5SlFtUqlX8VHV9pnyGyPgeyOwvcCAJAXMPgcB0FaLdPyQzJY2yGGaFzGY7XuewSOuN/a a2wbdzQtGfVs4Rd2ilHeopJxJMQ3tMhBf5lppd0eJZYtVyc3O4cHEbEIWvLITE43G0mrpQBs utUlzNi5NVU3LCFEtslivZt+8sbF6EXRx04yq9yeD9uwHQJnxy3SNZKY4mxPbXeyPhPa7YDa 7wf6Fs4+BmYdX45je+SGNkokLgA+JtjXNLWmresfKqzZGZ7QZjMdNb3YSOawQ33XWkuL+z46 K2bmZWNPgsja+Qyh4fF2bnODRbcRsFCdpGxFDl4apqM4uElHV/NKVMPiDlelSLlCWqNdPRFV /wDUg6dN3yfIkhx8oTCOnEJbaWNtdQFklKnwrqLlYmVmTOwZQ8yxZHFdkEMAa2g7LK0qA12z ftXVXo5bQ1JwTSbr3qY6u/VNZ+I439ScVJptKmFfw93LZkcnH0aRrMBk/DkZi8bitNXA8Ta2 gLdtPCqDRZmTNeGQyRMmmkELiQ2yQNaweY4bLepdpFPR2aJUeGnH+lJL/wCqHqrlW651/wDK rf2mPHZw4Ws4bIaV+jj2tG3o7LfmXKxNHyIWYrC2GN+PJxH5EZJke3tdjzG7DWnnLsotzsQn p1fgVF9Xu2GI3pR1U/E6v6/eczS9Okw2RMlggL2XVyGkmTbXrjHXTzlEWm5cIgx45Q3Hx5b2 yBzg90ZNxjewC07emu7oXURRctbUYxVe5gtmGGGHUuk07825N072L68cfrOS7SJntLXmNzXZ 3enNNSDGfxT2d6ws0CZkhbxGyw8eF44lS4xxB7SxwoRudQfgXcRZfJWW02nVdJVzV1JpNY9B xItCyIZqtlEkbZ4ZWF5N1kQcLTs3i4AfgUQ6BNEMN4kaJIJGunaK2PDXue1w2bXAOptXcRRc jYWx4VpjlV1K+bvPasaVw3KhzItNy4RBjxyhuPjy3tkD3B7oybjG9gFp7XTXd0Lbgx3MzMmY tYGzWWuaXXG1tDeD2fFRbCldYWIRpSvddV0UWlLsOcr0pVrtVH01dX9ZyBob3Z00kkn7K/iu Y0Hth87QySvZ3b6fAsGHoebDkGbJZj5Y4YjDHkgC0NDT9UdwbRd5FzfJWap0aak557X0PdsN rm7tGqqjSjlsRjtkbj2xNYyQMoxm2wOA2DYB2R4lymaHPDG1sUgcXY0mPMHnYC8XDh2tGy8n zuhdlF0uWIXKOVe6qKmH0yOcL04V007zqzkP0adsEQieHyCB0D2yue5jS9lpfETdafBTd1La 07DdjNY1+PBG5sYY6aM1e4im/wCjbvpXet1SpDlrcJKUVQsr85R0yxOdl6fJLqIyuFDkRiHh cOYkUdcXXeY9RnaZNm8KF5jhxI4yeGwEkS2lraeb2WV2fMukir5a29SdWpvVJb/voFfmtLWc FSL3HMi07Lky48nNeC5sHCeYXvYS4PLgezbst3+HoUSaSG5jJYYIJceOAQthlJFDcXXeY9dR FPS26UpV11anjKvS2X1Fyta4UppWCNF+HMzJizMdsYe2LgSQEkMDPOFjmt2UP9Hd1Jk4mVkx YnEdHxYZ2TS21DaNrUNrcenpW8i1wIUksaSzWyu/6jPFlVPCscn0fRnJdpEz2ljzG5rs7vTm mpBjP4p7O/wblii0CaEzFsweWyRS4rn1O2EODWyeChps/wBC7aLm+SstptOqyx3qhtc1dSaq qPo9pqYePkxzZEs79kxaY4Q90jWADbRzwPOJ3UWtnaVJPNK+JsTHTGMjJq4SxlhFS0dobh0F q6iLpLl4SholVqrfTWVa/aYjenGWtYOiXZl9hyvZWRxqXM4PfO+X1N27zLKU39NyjE0eaN2L HMY3QYYmAO0mQTbKOYWgN2HrK6yLK5S1WtHnv6VKnaka9TcpSq7OhqvYzmnTp2TRvgLYmiQl 7GOcxoYHsLAGtFD2GuqDsucSranpjs+aA1aI42ytfcKmsjbWuaOm07d66CLT5a24yi13ZOLa /pxMq/NSUk8YqST/AKjk42jSsme+d7XcfHfFkPYLXGSR5e53m03GlfkWRmn5T24kE7oxBhOa 9r2E3vMeyOrXCjdnnbSukpWY8raSok+nHPbj2FfMXG6unZl1HHxtGngxsWj2vnxnl5jc55hd UncD5rgDsIbvWXStNkw2RMlgxy+O6uS0kyba9cY66ecumisOUtQcXFU0Ki27t+3uoS5m5JSU sdTq/r97Pn/vbbfjae3dUyj5YV817i70x8S+me9f6nTfypfnhXz9eg4micKUbiCjZsnHNHVt 6nbR8a3kLQW0cKg7wUKVhyGTDZscN7SrFcsOLH3NNCDsW+3IY6LiONOgjwoC1KAn4ytPImu7 DfN6T1qJsh0mwbG9XWsKAIiIDI2Tod8a+ncl43KcXLcEmqY+Nk5c7pHvugGRK1txY0OsY9zd jahfLV9J5acH6HhkehT4Q4hYuT0KqVTpatqbabphU1Oc9N5PGEcrS4JsPMuaGAMe2F5J2tcH +b2akWrxq+k6xo78/Rp4w2s9BJC3puZtp/rDYvm61y9zWnvTPPztpwlHytYMhQVKhdzyEFQp KhClSoVlCAqVUqxUFClVCsqoCCFBCsoKAqimiIDYAU0U0U0QlSKKaKVNEBFFKmiUQhCmimim ioPbe6v9/wA39GfnjX0WfHiyYnQzNujdS5tSNxr0U6l8791n7/m/o/wxr6QvLcSbkmqp1TTP fabUYtOjSTTNZ+nYT4pInxBzJXmV4JPnne4GtR8CzTQxTxOilaHxvFHNKuiwrcFWkViqPDNb jprk6d54Oqx2msdOw3RSROYXNmIMpc5xc62ltXk3bKdayux4nTtyC36VgLQ8EjsnoNN48ayI itwWUYrLZuxX1hzk85Pt34GvFgYkMgkjjo5t1gq4tbeausaTRtfAFLMDEZx7Y6d6rx9ru1Wt enZ5x3LYRRWrapSEcMu6tqp9g4k/M8en2mvHgYkXB4cdO7XcHa423+dvO2vhRuBiNhihEdI4 HiSJtXbHAk13+FbCIrVtZQju8K6PcuwcSfmfb9N7MeRjw5MLoZm3xvpc2pG416KdSqcTHLp3 Fm3JAbNtPaAFo6dmzqWZFXCLdXFN72uv3silJKibS6/puNUaZggECKleHtudUcIWxlprUEDp CywYsMBeY2m6Qgve4lzjQUFXPJOxZkUVq2nVQimtqSK7k2qOTfWzC3Dx2ZT8trKTyC176naN nRWn4oWCLRtPhddDG6NxFC5kkjTTq2PW6iOzaecIujb8Kzeb9pVcuLKclVJZvJZI134GM+Rs pDxI1gjD2yPa60GtCWuFfhVziwmSGRzSX44IicSSRcLTWp27OtZUV4cPLHFp5bVkTXLzPdnv Ndmn4jJhM2Okge+QOq7zpBR5pXpotlEVjGMa6Uo1xdFQkpSlm26bwiItGQiIgCIiAIiIApol EQBERUgREQBSiIAiIgCIiAIiIAiIgCIiAIiKgIiIAiKUIEREAREQHgfev9Tpv5Uvzwr5+voH vY+p038qX54V4FrOkqggDpKFXKoUKcl+xxHhKhS41cT1kqEAREoaV6EAREQBezwNam0jkyHJ x2NdkOmMMbnioaHGR9af6pXjF6CHOjdy/jYJxu8BkzpZL7g3Ze0BpYQ6vb3/ADrFyOrSqVxN wmoanWndpU9bp3O+kzaaJsqYMzI46zQULS54H/p12G47tq8HkzHIyJZy0MMz3SFrdwvcXUHg FVr57cZs1caN8MZH1cjxIQentBrNnwLI0UY0eBbsWlByaTx37Djzd53IwVU0q5bekghQVeiq u54yFBUkKFAVUEKyhClVBVqKKIChUFXIVaICqhWooKAqisiA2qKaK1EoqZqQApopopogqVop orUSiCpFFNFNFNEJU9n7rf8AyGb+j/DGvoOfn4em4cudnStgxYG3Syu3AbujaSTsAG0nYF8/ 913/AJHN/R/8te15j0SLXtFytJlkdC3JaAJWgEtcxzZGGh3i5oqOkdIXmn4n1n0Lfgj1Irg6 +zJvOVhZelsZAMoy5rGsj4RrddJG+RjHMp2mPLXDq3rL/MGg91757SxO68Tg9448fD4lL+Hf dbdbtouNrOi80cwaHmaXqDsHE40EQjMBmluyI5Gyuc5z2x8OM2BttryK1qaUOlkcm6zmau7W Jn40Ms2qafmyYzJHyNbDgRPjdbKYmFz3l+6wAdamBrE9Ni8waDmTtxsTUsTInfWyGKeN73UB caNa4k0Aqr4WtaNqEphwM/Gy5WtvdHBMyRwaCBcWscTSpC8z/JmqfnYP8Se2/Of+7+h9X9Z4 N3hXL5Y5S1vN0fRe+Mj01mmwalGxszHSzOfml8Q4uLNGxjWtrdQudcKbNuxRCrPcR8waDLBN kxaliPgx7ePM2eMsjvNrL3B1G3HYK71bC1vRtQlMOBn42XK1t7o4JmSODQQLi1jiaVIXh9S5 C5m1PvcuTNjDKytPiw3yOyZ5g+dmVDlSS0fABExwY6kbBa07gtfmzlLV5+bMrP09nGytTsx4 AWS8CLGlw5sTKlyJuGI2ubQFgDyf6JqAlFvFWfQ8HVdL1G/2fmQZnCpxOBKyW26tt1hNK0NF yp+c9Lg0rVNVfFOYNHy3YOS0NZe6Rj44yYxxKFtZBvI8S2ND0iXSpsiERYzcJkWLBiTxtIy5 WwRcInMfa1riKdi3oXm873dy5eka7CY8J2qanqEmXhZj2kujhfLHJY6XhF7TRrtjajamAxO5 PznpcGlapqr4pzBo+W7ByWhrL3SMfHGTGOJQtrIN5HiVxzjow5hyuXpnOx8rDi48k0xYyEtD GTODXl9SWsfcezuBPQuNncm6zNp+taLE/G7lrWoHOOY6R4libJJDK9ndxE5ry3hkD6UV8Cpr nIOo6nq+rahBlQYr8+TGGPMWcSRsAxpMLMjdc0W3slqKHbQebvDAYm7p3vG0rUxiDAws2eXO lngghDYGuLsaOOaQkyZDWgWyCna610tY5mbo2lDVc7TstsDfr2tOO58NXtjZeBkUN5cKWF3h ovMs932fBqEWQ3H0/LwoNQ1DLbp8znMiMOXHDHAynd5Ggx8OtLaDZTwdzXuXcrVOTZ9DxMfE 02eayyCJx7sy2dsxo5sLD2g2v1e8/CmAxN3UuY49Mw8PIy8LJbLn5LMOHEbwXSiWS+y4ibhA Os339K0p+edPx5H402Hltz48vHwXYNITIJMtjpYDeJ+Da8NI8/Z0gJzFyvnat3Nrc6SWOHUo M2SOZzYuHDFxL2Y78WJkl1Hihc6uzzgVg1/kiHJx8ZulwxSSt1DHzs7v0sshyGQMfHwpJpW5 DyKOtAOwCvwsBibh5z0uJmc3KinxszT5IoZMB7WPnkkyG348cAgkkZI6TbQB2yhrQbV09O1J 2a6eOTDycGXHc1rmZLGgODm3B0csT5InjoNryQd9F5X+Rs94zMmN2Np8ozcXUdL07HLn4cU2 JHZ9JSOA0mJ7djARQGrty9Vpx1lzp36o3GiaXNGNDjOfIWtDe0ZJpGx3FztwEYoOkpgDize8 Pl+GHVpHcUy6JKYcrGDWcVwErcfixAvAcy93XUdIFRXdyubNLxeYIdBkEhnmsa7IFnAjklbI +KGV5eC2SQRm1tNtRReT1f3YZ+fjalJDlRY+oZeoZGTGWlwjlxMh8UjYclwjuqx0d7R2mg+O o39Q5I1bLzM/WW5MTdUfqGPmYMFx7oWYdseP3j6Iy38MvuDHUJKuBMT1Woavh6fLiQTFz8jP lbDjY8YvkeSRe+0fiRt7T3bgPDQHX0zmTTtR5fHMLOJBgcOWV5lb22sgc9ryWxl/oE7KrX1v S5Ztf0HV2XOj06WeKZjWlxty4TE2Ts7aNkDQdm51xoGkrT5Y0PXtJ5fh5fzIMCWBkc7H5PFk mB4rpJBdiux4w9tX2ubxRUKFM+HznBmyx4+Ppua7Knxo86DHPdg5+LKS0TBxybAAaAtc4O2j Zvp0NA13H13DfmY0MsMTJXwgzBlHmOgc+J8L5GPZWoua6lQV5B3Iuv2vfjd2xZJcKHS5Yhl5 E7DiFz35QhflQSuhLqMZG2jmtF3TQr1Wnwa5jDT8VmPhYmnYzXQzwsmmyJBEyNrcbgyPii23 Ah94Ozpqq6EKaJzM3XMH2hhadljEfG98Ekhx28V0biwxsaMguDi4GlwDfCulgZ+HqWHFnYMr Z8Wdt0UrdxG7p2gg7CDtB2FcPlDlmDljQohlwQO1KCOXvOXixF8kjDI6UNDhGJX9m0W06NnQ trkzR59E5YwNNyTXIhjLphs7L5XumczsucDYX21B20qoU7SlEQBERUgREQBSiIAiIgCIiAIi IAiIgCIiAIiKgIiIAiKUIEREAREQBEUqg8D71fq9M/Lk+eFeEK9371fq9M/Lk+eFeEKAqVhy H2ROd002eMrMVpZ76NazrNT8CFNJERAFnawOhAPjCwLbaKNA8CA1CKGhRZJm7Q7rWNAF39K1 B0GFHEWB7KuND4SVwF1cYUxmeJANQjdmZPFaY420taza2g8O9b+PpMMsIvyGOl/oVA+XyLRc sZc5pq0kHwIm1kZcU81U35dCyWbWEOH/AMf/ABuWnLg5Uex0ZUx6lmweZIaDoO0Lbi5kkApk RB46SPItKb6zDsQeVUctzSNjgQfCqkL0WLl6XqLzEGWPpcQdgAWTK0TTGRcYy7NlBGK1r4dg WuItqOb5d7H2nmCoos0rWtle1lbQ4htd9AdlVjIWziUooV1BCEqUUUVyFFELUpRRRXIUUQVK URWoiCpu2qbVehShVoYqUtU2q9qm1KEqUtSiyWpalBUpRTRXtU0VoKnrvdf/AOSzv0f/ACl7 LmjWvYWgZuqht78eP6JtKgyPcI47hc3s3uF23cvHe7H/AMnnfo/+UvfZ+G3Ow5cR0ssAmbbx seR0UrDvDmPZtBB+DrqF5Z+J9Z9K1/jj/Sjm8t6rk6gyduXlQTZWPw25GNDjT4r4XvbfR7Mt 5kc1wPYdY2tD8HLZz33vVdIZg40nsnUe+k5Ukdz5W4bHG7GjhkdJ5zTsfHcdlAupj8paQ2TL mzme1Z8+SOTIlzmRSVMLOFFSNkbI22tJ2htdpqVpxe7/AEaN2MwzZMmFhNyo8bBc5nCZHmte yeO9sbZiCH7C6QkdazgaxKTe8TRcabIgyoZ4ZMOx2U0GCbhMdL3dz3nGnlpw5C0OZ5+0UaRW na0zWsXVJ86LFbIWadOcWWdwAY6ZgBkYwXX9ioBJaB1VXnc/kMNw5WYcrtQyJNP9kwt1B8bI occduJ7e74hLnxyNaW1+OtF3+X9Ei0PTGYLJHZEpc6XJypABJNNIbpJZDvJJ2CpJpQVKOgxO Hj8y63DrOrYecYMjG0bgcTu2O6J8gnhfOXGTIzOFA2MMqXPNDu3kLYx+f9KzHYkWDjZOXkZs uRjsgi4FWyYjWySB0jp2xEFjw5rmPcCOmqz5vJml5mdlag+WePKyp8XKbIxzPoZsJpZC+Jro 3N81xuDw4Kun8kabg6hBqQycmfKgycrMuldHR8ubGyKa8RxMFKMqA2m1MBiYofeBo0jsZ7oc mPCzW5UmNnOazhPjwWvfPJY2R0wADNgdGCepc3UPelp40rKydNxpJcyGCPIjjldC5gjleIRJ KceaSlj3NDozR+0bAKuaweQsrv2E3M4cWjYEeayPAbkHI7Oc0sfEyTuuLI1tHuNznvduApvX X/knAk0yXSszMzczEfjR4cUcsrWtijhIdG6NkEcbC8Fre09rjspuqDcBidXC1J2Xk5GM/Dyc V2M2JznzsaI3mZl9sUjHva8x+a+hoD1rzH856p36/hQdw9u+weBa/jebTvHH4lvnbbOHu2Xd K9Phaa7EycjJfmZOU7JbE1zJ3tMbDCyy6KNjGNYZPOfQUJ6lzf5M0vv3euLPwe/e1e5XM4Pf LbeNdw+Lv7VvEtr0U2KYDExc680ZWgabNNp8Mc+VDG2aTi1MccbpY4G3hhDrpHPNgqK2vNez Q6Gvc56pp2Vrb8aKA4nL3ceNFI17pMjvhF1krZGtita6gqx/X4F0s3kbRtQ0gabnuly5Wtsb qk5ZJnBolM1oyHxk0qS3d5qZ3I2jZkuSbpcfFzm4zM3CgLGwytwz9A01jc+MAAN+jc3YEVBi eiREQBERAEREAREQBERAFKIhAiIqAiIgClEQBERAEREAREQBERAEREAREVAREQBSiIQIiIAi IgCIpVAREQHgfer9Xpn5cnzwrwhXu/er9Xpn5cnzwrwhQFSuZmurOR6IA/CumVyso1yH+P8A AhTEiIgJYLnAdZW2Vgx21fXqCzlAYpBVpWBbDvNPiWugC68QpBGP6I+ZcgCpoF2qUAHVsQGN yxOWVyxOQGJyxOWVyxOQG1pTazvd1Np8ZXpM88PFYzqoPgAXC0SO57v6Tmt/+PjXZ1h9IwOp rim0jdE3uPOuFST1qtFkIUUXoPnVMZCiiyUUEIKmOiiiyWqC1BUx0UUWS1RalBUpRFe1EoKm /aptWS1TatUOdTFaptWS1TYlCVMdqWrJaptSgqY7VNqyWhLQlBU9R7shTVc/9H/yl3Ped/gb Uv8A2P8A+iJcT3aCmrZ/6P8A5S9/lTSQQOligkyntpSCIsD3VIGwzPjZs37XLyT8b6z6tr/F D+lfYcDXeadPbpwm0zUY5AZ4oJ8jEfDKIONeInzyv4jIIy9oDpHRv2VAbWhHlhzlzG/S2yDN gIg1LKw3TtkijdOyJjHwtZmTYzsNux7nXOYy9rRaK1XrtG5ww9Y7m6DEngh1Hi91lnfjMv4N 3EtiGS6V1pbQ0Yfi2rLqHN+g4elZWqxZUefBhcPjtwpI5nt4rxGzYHgCpPSVn2G/aeZ5cztQ zubdLzs7MyTDmaRI7GGRDHjNmeJg17WQgyCro2MmdY+p2HYyjRiy9Fl1jmrm/FhwcLKlfFiR R5GY4tdjukxS1skNMeY1rtO1u4fB7ubVdLg7xx8yCLudner5WN4XF+r4tT2L/wAWu9YpOYNB ighyZdSxI4Mi7gTOnjDJLDa+xxdR1p2Gm5Kih5E5OsxjmjT8jUZMmHl/TYWxRyRQuZM+TBeZ Hz8WOR7rntuoX+A1C19M5k1AhkGVqjdHbj4Wku03HZixyNyjkRtM1uMxnFkF/wBHSAtDfgX0 DHy8XJ4ndpo5uDI6GbhuDrJG+dG+0mjhXaCtDTOZNO1HQBzCziQYHDlleZW9trIHPa8lsZf6 BOyqV6BTpPLY/MfMUvM0mLJmQY7Y9Wdht0yQEyPxAyokZjx4r5u0z6QTOmEfWA1dqDMys3kT JycPUJNWypMTK7vnwwnGkkkHFazhwsAc1zXC0U30qsuBzhjZ7+DBg5YypMSPUMbFdwA+bGld YJGO45jFCdoe5p6gVtaLzBDq8+bBHiz479PkbDOZuE5hkILnRskx5ZWFzNl4r2aiqewHh+V9 U0fSdQg1COWOHSoeXsT2rJjNLoxmumaxveGwB303aPnC7f4Vi5y/8pzPxP8Ayv8A2r+X7v3j zxxO4V7fn3V4fTVe75e5jj1/GZm4uFkwYUrXOiyZ+CGuLH8MtDY55JAag7202LsK1xFD5jj5 T281yS5cMGTqT+YXQRwBjodQjxRDZFkNlhka447YgKtdGWuFSTtqsvJr48XW8KGRuBqupahJ nz6lmQwPZmYkzHULpjNa9jX3GOzhRip2V/G+kolRQIiKAIiIAiIgCIpogFEREIERFQERSgCI iAIiIAiIgCIiAIiIAiIqAiIgCIiAKURCBERAERFQEUogCIiAIiIDwPvV+r0z8uT54V4Qr3nv W+r0z8uT54V4MoCpXHlddI93WSutK6xjndQJXHQoV3xlrGOP44JHwGioASaDeVv6nDwmY7Op pFfFRVLBvcYlOkoR81fqRhxhRhPWfmVykdGxtHX+HahUNmN/mnxLXWd/mlYEBkx23zsb/SHy bV1nLn6c2uRX0Wk/gXQcgMblicsrlicgMTlicsrlicgOzoEfmHreXfEP9C29ZdVxb1NA+Wqr oMdGR+Bhd8Z/0qupuunf46fEKKwVZI53nS3J9BzbVBastoUFoXpofNqYbVFqzWqpalBqMVqi 1ZbVBalBqMVEoslqWpQajFaiyWolBqOnaUtWW1LVqhy1GK1TastqWpQajFaptWW0JalCajFa ptWW1LUoNR6D3bimsah+jH/4l9DXz73cimtah+jHzRL2ms5sun6ZkZ8Ya4YjRPM11TWGMh84 ZQjt8IOsqaXUrsXiueOXWfasf4of0x+w8fB7vtU9l6Jp8+RAz2dBqkGVIwvf/wCQY9kbomlj Lrb+0CWrLncn69qHLj9Jlj02CePBxcGDJaZJJX8CWOR5fOYmFkZEeyMMd2jW5dqfmfuuXmuy If8AtuLHkGOdm0ySYccU0rGOcQxznXyNDa9kwvqTtspoev5+osiw5jje1Ipchmouiu4LG4s7 oXNia917nuFvT2A4OdvY18qzeByJ+RNUGK/BgyY5sTG1LH1TDfNI+PKmcA7vTcnKgja5rnOd VkgDnDd1U2NO5NzsXV9L1IjGgbi5Ofk5cUcuRM4nLiZDGeLk3ulf2KvcbB1N6+1ja3K7WcvT 8mJrIG5IxcKdhJLpBixZj45W9Btc4tcNhAINDS/PoOoT6lpGHm5EXCkyIIZXUpY4yxMlcYxc 5waHOLe1t2dVCZViiGkYmVjd97zDiQ8bLlmh7m0tvjdbbJkXAVmNO2QuNyxoevaVoEPL+XBg ywMjnY/I4skwPFdJILsV2PGHtq+1zeKKhdLH1uWXWpMJ0TW4RdLDj5NTR82O2F8jQ7zXE8WR to2tML9+0MxY2sZ8mZjvk4XcszNycCKFrHCWN2L3n6V0xkLXh/dT2eG2l2829oDi4PKOv4Jy M/BONh6o3T4tOwWnJyMrHZSS+aT9pjc+MABvCYC5o6arq6PpmuaRpmFpeBjYWNj4ssbZL8ib Jc/HcXvyXA93gpKXEFv4u07hRaWJztlZGk6VL3aMalmz48ebBcbIoZX4wdO0/jXMy4S1t1W8 TbW1y3ZeaZcfUNXwpsdrnYjo2aYGuLTkyPjxqwuNHBhE2VE287KP/ouKuIwHJXKsXL2j48OR BjHVGNkZkZkDBc9r5XSNaZXMY9wAt39S9EvN5HMWUzQtD1B+RiYD9V4PecjJaTBHxMWXJNBx ot72Boq/p6Uj5nmjixpJTHmQSZ7sM5mFDLKyePukmVxceKF07uzI3huo5/mu3fiwHpEXK03W xqOqZeLEyRkGNBjyNM0E2PIXzPyGv7OQ1hLaRNoQ3r29XVQBERAEREARFKAIiKkCIiAIilAE REAREQBERAEREAREQBERUBERAERSgIUoiECIiAIiKgKURAEREAREQBERUh4L3rfV6Z+XJ88K 8GV7z3rfV6Z+XJ88K8GVCmpnvtht6XmnwBc5bOfJdNb0MFPhK1kKbel45my27OzH23fBu+Vb euM+o8JcP6q3tLwu7YwLxSWTtP8AB1D4Fqa6Q1+Oeq8/1V2cdNt9J4Vd181GmUapdho1uloN zB8pUlYoXbOtzz8gWUrie4xSeYVgWaXzfhWFAb+mN+sd4h8623LX0wfQvP8AS/AthyEMblic srlichTE5YnLK5Ua257W+kQPjQHqNHZbGf6LWtWlkm+Vx6yT8ZXRwexiyP8ACT8QXOcKlbtK sjzc3Klp9LSMFqgtWYtUFq9ND5uow2qLVlLVFqUGoxFqqWrNaotSg1GK1Rastqi1KDUYrUWW 1EoNR1bEsWa1LVqhx1GG1TastqWJQajFalqy2KbVaDUYrVNqyWKbEoTUdj3eCmt6iP8A6Y+a Je+lhimifDMxssUrSySN4Dmua4Uc1zTsIIXgvd8Ka7qQ/wDpj5oV6vmv/C+sf2HJ/wCC9fPu eOXWz7/L/wCG3/RH7C7tAwH6ZBpkgdJFjuY/iPtdJI4GsrpXFtHGcFzZdnbD3A+crDRcUYhx mukaRPNlwzgjixTTSSTOfG62mwyubQggt7LrgTXz3MZ0zG1DKyZG4WoZxaHQ4OW4wZwcI22e zcgNfIQS3sNjZ9aXEPDuysvMMTZtTzYnlwbI3QmuLHOY6h1Kcdl7CHNPhBqsnQ750jDcM1sg dI3UJWzygmlr2RxRMMbmWuYW8FrgQah20HcraZp7NNwosKKWSWHHjjih4ltWsijZEBVjW1rb ca9JPRQDhifJZzFg42ozOhnx8bKa3LoxrJ435eAIKOc3h3yCkcjQGm4m0AFhPQ1+WLGn0jLy HthxcbNc/InkIbHG12JlRNdI91A0F72tFekgdKAQ8q6NA2B8UDWZsDo3nUWtYMuR0bmue6Wc MucZqES+kHO61mh0LHhzG5AmldFFLJkwYjizhRzz8TiytIYJSXcaTY55b2tg2NpwtT9nallZ WpOy4G6U6PEhjy52cfT5ZYTmueycXsY+NvHbR14bxbRUubar4mRky6NJHo+ntjx3ZrYn+ysh j4Tj2RyzSYb5e6MAeawu4Zba8ueO0CgN+Dk7ScdsIjMtcduM1ji4VriuxnBx7NKyDDha/oo3 s2kuJ2JeW9OmznZ0nEdM6cZLhdRtWtxgGUA82/Dik67m77SWny2oS6lJ7uMCOHFnGJ7Je7Mf G+Jrg2LFthD/AKZjuG9x4psJda2xze0QN/mgYr8qHNzhiSyRYl2Lomo44lklkcS+SHFkE3Dd NIWMjNrZLdlBR/aoO/BouLBjaXjMfIWaPb3YkirrIJMQcTs7exITsptWxk4UWTNiTSFwdhSm eINpQudFLj0dUHZbKfhXndWl1P8AmzS3S4s5w48sRYjmPi4TrsPKM0rm8Zr7u1SjmdlsZLTV 9pxYHdfbGLw+H7a9pZ3tG2neu5Uze794p9JwfqLLuz5lPxVAenZhRMz5s8F3Fniige00tDYX TPaRsrWszq7epbC8XyrGx+UxuPNGyebAk767Fa1uTjzkwWt1NzuIJsoEvte9jNok7BuIbsRx Nh5SkiBccePVJW5Bkc5/7M3VnDI4z5CS5nBu4hefNrdsqlAesReRDNLdpGqd3xcTN0858Uei xPjZLhCSeLFxmPja3s8MZMr7zH03/jVWXM03QdJfpGm6g2BuhYuJkRjvojEByQ7G4T33hsZm c3iurSp7dOlKA9Si0OXhlewdN77xO9d0g7xxq8TicNt/Ev7V12+u1dBAERFSBERAEUogCIiA IiIAiIgCIiAIiIAiIqAiIgCIpQgREQBERAERFQFKIgCIiAIiIAiIqQIiIDwXvW+r0z8uT54V 4JxABJ3DaV733rfV6Z+XJ88K+ezZEAcYZDSo29W1Qpy3F0khO9zjWnjW7pOK2XUGMftEYL3D oqNw+NUkkhb9HitFzt7+oeMrc5ajuzZHbw2Mj4yFqCrJLpOfMS02ptYYHetXn+YnftMTPRZX 4yfIvS2ryWtGU6lKJBQggMH9Gmxd72Eetnz+RVbtfKm/uMGM3e49GwLKVLGWMDfjUFeY+qYJ twCxK8pq6nUqIDpab+7u/LPzBbDls6Rgs7g10je1IS8ddDsHzLPJprT5jyPGKrpwZ0TW08z5 yypOLbWl0rTA5blict+XTslvmgP8R8q05YpY/PYW+MUWHGSzTR1hdtz8Mk+pmu5TituyYx/S r8W1Q5ZdPbXJB9EE/g/CodD0jexppPWD8potIN2Ldyuxgxs67R8lVr2rty6xbPB+oSpGC3tv sMJaoLVmLVBavRQ+dqMBaotWYtUWpQajDaotWa1RalCajDRRas1qi1Wg1GKgRZaIlBqOtalq y2patUOOoxWpastqWpQajFaVNqyWpalBqMdqWrJapACUGo6XIApr+pfox80K9tqGbFp+Bk58 wc6LEifPI1lC4tjaXuDakCtB1rxXIf8AiHU/0bf6sK9hreFLqGjZ+BCWtly8aaCNz6hodIxz Gl1ATSp6l867/kl1s/R8t/gtf0R+wxHmHTDNpUMb3SO1trpMEtaQHRsi47pHXUtFtNm+p3b6 bTNQwJMyTAjyYn5sTb5cVr2mVrTb2nRg3AdodHSuHi8r5WPrDM/jRujZlvmt2hxjeNSl6qXC TULaei26tTaEXLmoM13GzjJH3bGy58l1JZu23IjyGgNxRTHidGZQC4Auk2vLmmodjA6nV9u6 Xx2RNyI3sdBLlOyGvYYWRwiB7i992yrMhjx/R29Vbs1vRpHSMjz8Z7oou8ytbMwlsJa1/FdR 2xlrgbt1CuAeSGzafo+DNwmM0zCdFKxgcYn5PExJrpIRYJonvgcZGupdWux20bGlcu5mPqMe VlMjpHPPmB4y8qUCTJ4rnRx4rhHAyzjubxNtwFbQXdlgMTr6TrGBq+HDl4UrXtniZPw7ml7G yXAB7WOdQhzHNPhaR0LE3WXyahNhQafkztxpWQT5TTAImufHHNWkk7ZCGslaTRniqnL+Jn4G k4en5rIg7DxooL4ZHSBzowYyaPijoLWtPjJHRU0w9CxYtXztVnx4JMvInbJjZNgMzIxjQ45Z xC25vaY/YDuPhKA2J9b0bGaX5OfjQta6xzpJmNAddIy03OG26J48bT1FWyNV0vGyo8LJzIIc ue3g48krGSPvNjbGOIcauFBRcN/K+W1gOOYmSvyc6WZ7JJcd37ZPxY5jNi8OWQxxta10VzWv 2doWNKRcsZ7NGysAyRcWfRMbSmOBdaJoWZLHOPYrZWZtDSu/YmAOlncy6Xp+NqGTmScFmmyG F4eWNMsnAZliOC54uc5j6AbNtVsYmrYmRh97kc3GaIhkyMlkicWQuvsle6GSSOxwYSHXUp8K 4GscnZGZkarnwGJ2bmtmhxmzufwmRZGJj4j3ijXcKVroibmtNzOyd4LN3X9F1TN9ojT3wD2r gDBkdOXjhcPvBa5rWNN/E7wWnaLKXUf5qYA6GZrul4eXi4c+RGJ8yc4sbL2VbJw+NR4LgRUF o8b2+kt9cB+g5TdYOpwMgc9+pR5UjnOLHnGbgnBtLhG6rmPe57W7vCKrvoApoiIAiIqQIiIA pREAREQBERAEREAREQBERAERFQEREARFKECIiAIiIAiKVQQpREAREQBERAERFSBERAFKIgPA +9b6vTPy5PnhXznIwuLKZL7a0qKV3L6N71vq9M/Lk+eFfO5syKMuaal7ejrUKjWyRHjs4Mfn O893TRdblSKveZPyGj/aJXAe9z3l7tpO9er5Uippz39L5D8QAC6WVWa6Dzc9KliXS0vrOpav I6pkNy9Vc5u1kXYaR029Pxr1GrZBxNPnnbsc1tG/lONo+deMxBtcfEunMSyj7Tz/AKbbrquP Z3V95nK18gbAepbBWN1KGu7pXnPpGotvS8RuXmxwvNGGpd1kAVotRZ8KWWLLhki+sDxb4a7K fCrGlVXKpi5XRLS6So6PpPZiNrWhrQAAKADqCWrMWqLV76H57UYS1VLKrPaq2pQajSl0/Fl8 6JtesbD8iwxaXBBIXsLqEUIJ3fIukWqC1ZduLzSOkeZuxwU5dpikLpAA7aBuCoWLKW2+JQWr SilkqHOd2UnWUnLrdTEWqpasxaoLSrQzqMJaoLVlIUEJQmow2qLVmIUUSg1GG1Ras1FFEoTU YrUWWiK0Go61qWq1ClFTBW1LVaiUQFbUoFaiUQFaKaBWolEBvcif4i1P9G3+rCveLwfIo/8A 9Hqf6Nv9WFe9XzLv+SXWz9Py3+C1/RD7CFKIsHUIiIAiIgCIiAIiIApREAREVIEREAUoiAIi IAiIgCIiAIiIAiIgCIioCIiAIpRCBERAEREARFKoCIiAIiIAiIhAiIqAiKUBClEQBERAeB96 31emflyfPCvlUzr5Xu63Gi+pe9t1mNpzvRMp+WFfKlCoL3XL8PD0fHHS4F/rOLl4VfScSDgY sMP5uNrPVAC78uu830Hg/U5f24R3yr2fxOVzSCNJd+W3515XEHZcfCvXc0sLtGlPoOYf9oN/ CvI4n1Z8anMeP2Gv03/A/wCt/cZSsMxow+HYsxWvkHYAuJ7jAt7Q4eNquO3oa6/1AXfgWiu3 ynFfqL3ndHEfjJAW7arOK6TjzMtNm4/5X9Z6qighZKKLV7z87UxFqgtWUhQQlCVMJaFBaspa FUtShKmItCpS3Z0dCzlqqWgq0JqMZaqlqvShod3QUIShHIxlqqWrKQqkK0JqMZaooslFFEoT UY7fAooslEolBqMdEV6IlCajpopRZOxCKVFEIEU0SiAhFKIU3eRf8R6n+jb/AFYV3uev8K53 /tf8aNcHkb/Emqfo2/1YV7bLy8bCxpMrKkEUEQue924D8JPQOlfLvqsrirSurE/Vfp03BcrN R1uHCkorOVKOntOHzFl6bqGnxGDOx5IsfLx35DL74HtuNIsh0QkEbHH8Z7bahcNs2PDo8kM0 WHx87PyhpDp+HLiww3NEr2PkAa2NpBt2do07JXq2643gTz5GFl4rYMc5VJY2i5gBJAcx7mh4 p5jiCsmFqkmbAMiPByGRSRcaFzzB9ICA5rWhsziC4H8ag6yuLipOtcWtx9K3elZt6eFWEJ6q yuxzpllj09GB5vmCbRMXlGbRtNnEojgjnjtJkDo+8sY+TiN7BJkrUA/AvUaZg9xgdFbjsueX 0xYe7s2gDay+Srtm+qw6VrLNTknZFizwtxZHwSvl4VoljIuj+jleSdu+lPCseRzFiQyZAZDP kQYRDczKha10UTie0HdoOcYxtfY11o3qrSnqqstKwpkc7sr04uwoS1a5XbjlJTblc0pVdFu9 tTzDIcV5zJMjIihdHrGcYYsxhfhSvMYAbPua1w/EJPXQFel5ZmxZtPkOJj91ibkTNDGPMkDi Hdp+M40HCcd1rQK12KH816O3Ky8W8mXDg7yKWls0fD454DrqONh8HxVWfK1zExdEbrcjJDjO jjlDGhvEtmLQ3YXAV7e3apFRTb1LCtTfMTvXYRg7M4ubhw6yw72KSVFWtdp4zRYeDpWh5r4I sPHZll8+rxmslrXysEU9GNLWSE2XXloG/qWbAkjdofL2nNcDn4+qNdPiAgzRtZLO55fH5zQ0 bTUL2epanBpsUUkzXyOnlZjwRRgFz5JDRrRcWtHjcQFrRa/FNjSZEOLO9uNJLDltrCwwvhpe JHSzMZShrVriFnhpYatlMur3HV87cup3ODhK45RfEwr36V1f19C3UPCaV7ShxNCjkvl07K1C CeCQ+bDJHNLFJCN57Yo/oG+g3lNK9pQ4mgxyXy6dlahBPBIfNhkjmlikhG89sUf0DfQbyvdv 5ixI9BGuyQzsxiGuETmtEtrniNptLqUNajbuVf5q0biU430PdO/d52cPh8Tg277r7tltta7N +xRW4qnf2HWXPX566cpWtySlTzR1YYLxLUsdvtPGSw50+r2adKYc0apqr8d7aVL444ZAztEC j7bTXZt2rY0yaTIAn1GIwaRLq+U/U4ZK2MkcyJ2OyfYDa2XYbhbXzuhetZzDCXGOfEycad0D sjHx5WN4kzWgucyIMe6sg6WGjtu5YJ+ctFgbp7nvJbqYDmEGOkTSQ2s/b7IBJB3+aepXRFY6 /pgZfNX5pQXLVpHSpRlWX4m2pJfDuaL8rTwTYM5xsUYkDMmVkbY5HSwvoRdJA5zWgRl1aBoo uXqGnx/zbk9yxou9+yn5GP2I/wB74xsl7Ytvu/GK9Fh6nBmZeXjQNee4vbHJNQcNz3C5zGOB NXM3OHQVzMnnTScXTYtQmbKOLK+A4tGDIY+Ot4kjMgttoK7ekda21HSk5LDb1HltSv8AHuSt 2pN3Eo6NTl41qjqbxeCORhd0/wCyeyf/ADfFHtaleNw//wB7vd+36ylL9tfMXR5xw8SWTSJZ YI3yP1LGhe9zGlzoiXkxkkbWnq3LrQ63gZGqey4H8WYY4yjIwtdHY4gNFwdW4hwdu3Gq0Rzh phxMTL4U/DzY8mWIWsuDcRrnSXdvebez+BKRUWnJY/dga4nMSvQuRtTrFSeMu81c1SXeosKJ 06jy+ZDPHy1zE2B0UWFHqcjDjiI3bJYQ2x4kDWtGzZYfJv6GzAOrag6ebT2ZA1abhx5MTX5J 7bbeDIZmFtT5vZO1elytdxMXRG63IyQ4zo4pQxobxLZi0N2FwFe3t2rZxcmae7i4kuLbSnGM RurXdwZZN3hUVtaljXBbOs1PnbnBmnb0qU5LVqinWkE1RrvUpj1mpzLjwT6Dn8eNkvCx5pI7 2h1r2xvte2u5w615zDx8CB+je044otGl09kjOI1rcd2e5rbnzfil5i3GT4Nq9Dkcw48EuoRN x55naUGPyizhgBkkbpr23yMqGhu3p6qpJzDjw6I7W58eePGAY9rDwzI5kpYGPaGyOFDf0kFW Si3WuS3bmc7Er9u2rfDbVyXdpOkq3I93TubrU8nDDPPnaNE6BmVhuyNQ9mQZZIY7DEcZhqXs kfaNpbc2u7oovTcsxMw+/ac6VjsiHIdPJixB3DxmZH0kUMbnNYC2gr2QNp3LYn12OPLysTHx cjMlwWMfk8AR9jiAva0CSRjnuLRXsg/GsmZm6fpmFkazMHtY5jHyOLXcQjY2OMMfQt2u83YA SSaVJSMVFt1rTPqpT7i8xfuXoRtu0460lBRdXKUp64trpU91XnlgeFyMDOzciblKFjxDp0uZ lRQgxgCNzA7CHEcS49uTtVNaO27tmlJqOZq2ot1LIJdGcDJxmPcGNJkhwXOn7LOi+UuHj+Af R2apM50kZ07LZNGxsjY3CKjwXWm2VspiubvLXPBpuqufh85admMkkZBkMbHiSZwLxH2oonGN 1tsju1c0ihosO3HDvtY1y3ZL2Hrt89epJrloz0x0OUZquq7VznXHxv7DkarqGBP7vhjQZMUu RFiYnEhY9rnttfA11zQaih2L12JqGBm3dzyYsnh0v4L2vtrWlbSaVotbK13ExdEbrcjJDiuj ilDGhvEtmLQ3YXAV7e3auiusVR5p92OzrofOv3NVujtyh/duyUnKvelo1Ry2UXaeV7i/23/L PEZ7Hs9qcDhMrTj17rXzeFxe15tadnctTN7p/wB79r/+b4p9k1rxuH/+j3Szb9ZWvD2189df J5wxsXvnHwctns/hd7+oNnG+r3Tm66v4tVuw65juy5cPKikwZ4YO9ObkGO3ghxY598UkjQGk bakLNIvBS7V7KHo4t+FJytYaYtuE4qUpJxlKWFa6lp1ew8v3h+J/MbNXlZBm5en41GyuYwyy DFeyThjYHfSVHZ2VW7r8ckXu6bFK0skZjYjXscCHNcHQggg7iF0I+cNMk0nJ1ThTsjxDGJYH tYJrZbOG8Mv811+w127VfJ5pwsODKkzIZ8ebDDHyYrwziujkc2NskdshY9tzqEh2w71KRo+/ nGWPXU0533ctS9O1K3dtNxUs5W4wioxWxZb8zx+uNx2Raq3DfjzY5wccvk05gixQ/vbaNkjY +UGWnmm4bK7F1NcZgM5U1Xuc2nzV7vf7OibFT6ZtOJZNLX+ju6V35uaNKx87OwJS9uTgRGdz CB9I0R8Zwi7W1wb0GnxVQcy4sjWHExsjNecduXLFA1jnRRyND2NkukaL3A7GNJcepNEe93li nHLLM16nmKWXwJUhOF6rkkpruNVenCunNbzga5pubgw5U2PHj6e7UootMx8DENzJpZZSXPeX RQsa7h3NBI+ELRmDmYkOjPhAdh67CIcCYgtbj5DXywxySM4oIdV1drivoUb2yRtkaCGvAcA5 pa6hFdrXAEHwFcrC5mw8+TJhw4ZZpcbaxo4Q47OI6Iy47nyhr2Bzdrqj41ZW418VK7PrZzs8 7dcH/Z18JqUpatOmWEY1b2UrnjjmcDumO3G5lx8vHixZWxHIxtMADooxHA6MZeObWNN7t5a0 FpFDtXb0nHfBylD7LiZFly4LZI7GsbdkOhba91eyXF1NrvhW5o2sR6xiDMgglhx3/VPm4Yvo XMdQRyPIoW/jUWPSuYcDVcrIxsYPa7HqWufaGzMD3xGWAtc69gcylysYxVHXxJ02Pec7929J Ti7b/syhK4tWqKcYqGlr2b67zzmD3T/snsj/AM3xR7WpXjcL/wDe73ft+spTiba+Ytz3f4Nm jY2dbjjislZc2C3INJXefPebm9ndaOjqXXztejxM86ezFyMvIbjnLc2ARn6IOLDQPkYS6o3A VWvPzhosIc+98sIxBmtmjaHNcwycAMG0OvvNKECnSQoowjKrku7hu3e46XLvMXbTtwsy/vOM tWrXJqsqRyyerDqME+Pj5PO7oMmJk0L9JF0cjQ5ppk1FWuqN4XH0jE0qHkeDVMjHx3TRcR1+ QHmJzzNJAx07ImvMlgf2atNOi3evUnW4YWzP1DHn0+PHjErpZ2tMZaTbRskD5W3V/Frca7AV Vmv47YpJ87HyNOhiibOZMpgDSxxpS6N0gD607Bo7buVcY1bqvxZrKv8AAzG/fUIwVuWlSs+C 54tCacY0z1alWlaGxpGn+zNNx8DjPyO7ss4sm89PwNG5o6BsW4ubia3DkZMeJPjz4M88fFx4 8lrWmRo84Mse/tM3uaaOHUsMXM+BLp+BqDY5RDqWQ3FgaQ24Pc57AXi+gbVh3EropRSSTy+4 8k7N+U5SlFuUpVbVKNyq8KYfhfYdhFwsTnPR8vGx8iDiOORlR4fBIaJI5JbrDI27zTbvBPx1 VcnnDGxe+cfAy2ezuF3v6g2cb6vdObrq/i1TiQpWpfRcxqceG1JOlHg89O3paR30RFs8wRFK AIiIAiIgCIiA+ee9/wDc8Dxy/PCvli+p+9/9zwPHL88K+WKFRs6ZB3jUMaHeHyNB8VdvyL6R ReI5Rx+LrDX0qIGOf8JFg/rL3NF6eXXdb3s+V+pSrcjHyx+05+uQ8XSMtvVGXep2vwLw2J9W fGvo0sQlifG7c9pafERRfOsdpYHsdsc1xBHhCzzCxizt+mS7s47mn2/wMhWtkbwtkrWyfxfh XA+gYV6fk2HsZUx6S1gPiqT84XmF7XlOGzSQ/wDOyOd8VGf7q62F310Hj/UJU5drzNL7/uOs QoIV1BC9h8ShjooIVyFBCpmhjIUEK5CghCNGMhVIWQqpVMmMiooq7th+ArKaKjmgihVIypVV YVBtO/oKEKmSihXKiiEKqFZQhCqK1EVB0VFURcz0BFCICUUJVASiiqmqA3eRv8Sap+jb/VhX rta0uPVtMn0+R5ibOBSRoBIc1we00O8VbtC8hyKa8x6mR+bb/VhXquZNTn0rRcjUMdrHyw2W tkBLe1IxhqGlp3O618y/TVcrlWVT9T+nqbXLK26XHwtD/mw0/WaT9I1zLdnSZc0cRysB2K3G jllkgM7xQz2yNbwxsAo0Hp29exoGkyadHFHLg4cEkcDYn5eO4mWRzQ0G6sEex1KntHatXN5m n0eTMx9SjZkS4+O3Lgfjgxtex7249j2yPeWuEh3gns+HYWdrmraSRFnjHmlyMSebHdA17Wsm xozK9kjXvJcwilHAg+BcKwTrjVZ+0+k4czOGhKGi5jBRbWpRjV6eqLq9Rv6Hpk+n+0OM5ju9 5s2VHYSaMkttDqgdrYtKXQ9Sij1PCwnwHD1aR8sksxfxYnTiye1jG2yC3aztNod9VraTzhPq OXpWIYWQy5XGGbG6twshbNFJELqhkgdUXDxdau3VOaGZWl4eYMTGyNS7xezhPfwuALhtbk0f ePFRKwaVK0y7f4ldrmoXJObtxnKOtxljVW9T1JLdw2/4mtlciyS9+4M4ic6PHj0+ap4gbDAc aSOYhgo2QHbb8XQunqOh5eVykzRI3xjJbBBEXuLuHdCYy7aGk07GzYtn2nP/ADL7JtZ3fuXe rqG+/i8Kla0tp4Foy67qB1rUNPY5kUWFweG5uHkZbncWO83d3kAbQ7qjb8CaYKv81Yv7QrvO XHbbknwVDmI4Voo6YRyq3swNvPw9T1DF4c+NiNfFLFLG3jTOrYauLZY44XwvH4rgHdVFzHcs aiNP7i3hSY+Xly5epQSTyVfVzXQxMyDC59vZF5Lbienauhqeoatj61gafjyY4h1HjWukhe90 fAjDzUtnYHXHwCnhV+aNSz9K0qTUcMxHgW3xzMc6697IxRzZGW0u6jVVqL1N17uD+0xanfi7 Nu24LjtTtx71K1cF1PUs9413Tc/WOX58GkUGXPZsvc+MWSNf5/Da7zW+jvXJl5Evzs8NybNO zMd0cMY86B5mZkhjGUs4Qe0mgI30/pJPzfnY+lanLJGx+bgZbsaJzYJu7uax8bLnvDnNa43H YX9Xw7eXr2rN1DUsTEx2StwpcNgkax8jmR5DS6WV0THXSW02NZQ9PQo3bk6urdKfadbUedsx cbbjbhqlLorW2qrVurGntNmLTdTy9Uw9R1TgRO0+N4hjxnPeHyzNsle8yMba2g7LRU/0lxYO Q8kY+oY8+QHRugONplHbWx8Y5TeP9ENt4bWld58C9FoudNnQyTOyMbLgq3gT4tzTQtDnMlie X2ObX0vGAtaDU9W1GfMdprcdmPg5HdTHkB98r4yOMeJGSI20PY7LvDRVxg6N1da+05wv8zbc 4wcLat6NlFGktUaVxTrJ9rM3Lek5Ol4MjMyQTZuVPJk5T2eYZJD+J2WUFGjo3rlDk2WTWsue ef8A7ZN3mSGNhHFbLmRtinLqx0tpW3b0DwquXzhlQadq0wiBycHMfj4/0MzoTG17GVlkb2A6 jj+MOjYtnM5mnx+Ym6e2Nhwo5cfFyHEHi8bKZI+Ixm+2wWi6orv3qN22orytfR9hqMOejO7c ikpXYz1dUdNdPxpI0OX+Ss3G1J+VrndM6E47YGMpxKGPhsjNr4mt2MZSu9WbyfqY0zTcTiwc TCgz4pTc+0uy2PbHb2Nwu7X4Vjy+esvGbq0ToI2z4c748GRwdwpWxzMifGReCZGtfd2Tu6BT b2YNT1bUZ8x2mtx2Y+Dkd1MeQH3yvjI4x4kZIjbQ9jsu8NFIq1kqv7c6/cdbtzn4vi3NEIul PJhHQqLqufShq5ei61l8snQnsxo3MghiZOJpHBzoXR+c3u7bQQw9JXW0rC7rxf2DEwL7f3R1 19K+f9BDurs3rl6dr2oZmflQvcyOLHzZMVrGYeRLcxjgAXZDJOGxxB6Rs37lucyatPpUGJJA 6KPvOXHjSSzgljGPDi55o+Pzba71taV38cFTYea5G/Jrlmop3JO5RaktUqN9eXSYZdCy35HM EofHbq8EcWOKuq1zIXQnidnYKu6KpqOhZeVykzRI3xjJbBjxF7i7h3QmMu2hpNOxs2LSfzVn huRBB3fKm73jYeDnRtcMWR+Q29weBI8/RgGtrzvGxZRzLmzaPpupQxCKDJEhz8p0T5mQGJrr jwYX32ue00dd2Rv3qVt4rHFOvteJ04fORduXd7k7bh1wtpwwzxjHLOuGZsa1pGoZs8kkEOMZ BHbh5nElxsmB5a9pq+Jr+I3t1Aq0dBB3roz4+a7S3YzXxZGWYgxz8iOsUrqUfxI2EUa/bu3V 6dy0JtT1ZmlMycduPmvfkCPvOIHzRjHL7TPwWG9zm7ixrzt216FsaTnZWfizSsycTJYad1yc dr6AlgdbNA55LXNJ3cSpHorS01efeRwmrvDi3o02ZaVtxVOzqw30MOj6Vm4WbLJSPEwHx0Zp 8Mr5oxKXukdK3iMj4Q7VLGCh+BcjTuT9Txcd8UksBc7S8jAFrn04s00kzXbWDs0ft6fAunha 9l5s+NgRwGLPhI9sNkjdZA1rTUNdeATK6nDILuztO5a38z5/sr+YuHF7J4tvdqO7zwb+BxOJ fZfftstpT8ZZ/t0WeFf+ew7xfOKUktCdx21R4uUu8rartcsWm8+wtl6LrWXyydCezGjcyCGJ k4mkcHOhdH5ze7ttBDD0ld3Ffnvu75DFDSlnBldLXfWt8MVPlXKl13LZkcwRBkdukQRy45o6 rnPhdMeJ2toq3ooseocwZuPoukZ0TYxNqUmNHLWN8rWieMvcWRxvD3EHcKqpxVXV4Knwuhyn bv3FGDhBa5640bwldhGb27YpGHVuWM/N9u8KSJvtbund7i4W93pfxKMNK02Uqrahy3qDZM12 lyRzDUMburznySyPhbXbwZDxHFrg4ktP41Du2LD/ADTqLchuMWRP/wC4YuGZTHJA4x5DC937 NK8yMc0jsudsd0DYtifmLPg1jPifGx2maY+AZLo43OmbFPE55lrxPNjeBdRhNu3oWf7bxxxd Ptb+87L1saR7jUYKai8pJK3COG/CFEaeZyZmjHz8PAnY/HzsfGjvyT9IJMV7QwfRRBtnCFNx NVsa1y1n6xHl5Ehix82fHjxIomyOfEGMnbkOe95iY640oAG7Ph2ZM7mLPh0LP1vHiYMdj4xp zZo3NMkZdGx0rxxK2vLjZsaaUPSvRrShB1Srivqdf+TnPmuat6JycdUZtKVMdUFDVF9kU+o8 rq/J2RqOZquWJmQTZXBOFK2twshdBLHKbahkgdQ2nx9SlnLWq4ePKzBljMubhwY+Q4yyQuin xoxFHLDJEwkt62kCvXQ0XqUWuFGtdr+85L9Q5jTGDacIqKUWtkEqL/xT6zVjhy8fTG48Uonz IYAxk011r5WstD5KEuo5207ariaLytk6Pl4GRFMJWx4r8bNbIa2hzuOO72Rs2cYu887l6VFX BNp+XI4w5m5CM4qlLtdeGeDX1VwORoWl5+k8ux6eHRPzoWS8N1XGK9z3vZcaNdb2hXYtLROV snR8vT8iKYStjxX42a2Q1tDnccd3sjZs4xd553L0qJw493+XBGvWXf7uX9+UpXMM3Kv2anQ4 uVp2pt5iGsYjIJo+590Mcsr4nXcUy3VbDLsWhicpZenSg4UsE0cemuwmjKa5zXyvnM7742U+ jdcR5xI8PT6lEduLdfpiWPO3Yx0qlKRi8M1Hw16qs8w7lXKyoc3DkezT9Oyog2PDx5H5DGzi Uz8ZvFZGI212FjBQ+DYtvM0zV9Z0/I0/VXY+NDNExodil8jjM1wfxKyBgDKtHYoT/SXcRFbj 2qj6g+dutp4VjJTg6VcZYd6rzb0rOpxodM1PL1TD1HVeBE7To3iGPGc94fLM2yV7zIxtraDs tFT/AElz8XlnU4sPTNLkdB3XS8wZYyWveZJGsfJI1vBMYDSb6H6Q08K9SicOPT09P0oFzl1K i0qKppVMI01Up8cs954vE5Ey8ZmkytnjbPhzskzo2l3ClbHM+VkgNgJka19vaG7pFNvRzuXM zIl1yQNx5m6p3TgRTOlDf2cAP4vCtcOttp8a9GiKzBKiX0pQ1L9R5iU9cpJy6qfjVz7YoIil dDxhERAEREAREQBERAfPPe/+54Hjl+eFfLF9T97/AO54Hjl+eFfLWtLnBrRUk0A8JUKj1/JG JbjZGW4bZHCNviaKn5XL0tFr6XhDB0+DFG+Nov8AC47XH41s0XtgtMUj4fMT4l2UtjeHUsit F8/y2CPU81g3CZ9PEXFfQqL55qMjRq+ca7OK/wCMOIXPmMl1np/TfHP+kxE7adKwZG4eNZmg 0q7zjv8AIsGQdoC8x9Qwr6DokXC0nFZ1xh3r9v8ACvny+mwRcKCOP0Gtb8Qou/LrGT6D536m +5CO9t9n8SSqlXooIXqPlFCoKuQqkIRlCqlXIVSFTLKlVKsVUqmWVKgqSoKpllHAEUVQeg7/ AJ1cqrhUfMhlkKEBrsO9FSEIiICEREIdBQiiqwdyVCiqVVBNUqq1SqCpeqrW/wDJ+dUJLjQb ukq4ohK1OhyL/iPU/wBG3+rCvY6tpkGrafLp+Q57IprbnRkB3Zc14pcHDe3qXjuRP8R6n+jb /VhXvF8y8qzmntbP1HJylC1YnF0lGMJJ7mlgc46FhTNm79XPkyIxBJLOGB3CBvEbeCyMNAcb qgVr07BTCeW8WRrxl5GRmPOO7FilncxzomSNLHmO1jRe4Ha9wJK66LlpjuPSuYvLKbXVs6t3 sORByvpcGdhZ8Qe3JwIhA14I+kaI+C0y9na4N6RT4qLcydMgydQw897niXA4vCa0i08Ztjrq gncNlCttSqordtr7SS5i7JqUpttRcE35ZVqvrZzsnRWTakNTiyp8XJEHdiYuEWmO/ibpopNt VjZoPCzMjNgz8mKfLEQyHNEBDzCzhtdR8DqHpNF1UTSvvKuYuJUqqadGMU+7WtHVZVRqZOmQ ZOoYeoSOeJsDi8JrSLTxm2OuBBO4bKFNW0yDVtPl0/Ic9kM1tzoyA7sua8ULg4b29S20Vosc M8zCuzTg1J1teD+Wj1Ye1nIl5ZwJdPz9PdJKIdSyHZUzgW3B7nMeQw2UDasG8FZJNBgdl5eZ HkZEGRmPgke+J4baccWttFpDmuB7TX3ArpqVNEd30+jN+pvY9945/wDj+Vdho6fpMODPk5PE kyMnMLDPPLbcRG2xjbYmsYAB/RWKTQYDPNLBkZGIzKe2TJgx3iNkj2mpfW29jn7nljm3dK6a K6VSlDPHuanLVi0k+qPhVOimG45EvLOBLp+fp7pJRDqWQ7KmcC24Pc5jyGGygbVg3gqs/Kum TtyXSGQ5OVP3gZtWd4icCxzWwyllWNbZQDoC7KKaI7jS5q+srkljq9uH5UcLK5N0fLxsjHn4 jjkZMmZxqtEkcktt4jNvmm3cQfjotqTQYDPNLBkZGIzKe2TJgx3iNkj2mpfW29jn7nljm3dK 6aJojuD5q+0k7kmlWieKxp7kczE0MYU80uNmZEbMnIdlTQfQljnvILhV0JeGmlNjln1HTINR 7rx3Pb3PIjyo7CBV8dbQ6oPZ2rcRXSqU2GXeuOSnq7y/FRJ7jR1DSMTUZ8aXLrLHil7hjOtd C9z22Vkjc03Fv4vUsEPL0ONHw8PLycVrZ5J42xPbYwSjtRNicx0fDB2tBaaHcV1UTSq1piVX 7qioqT0rKOa27PazmQ6BBBiPggyMiKWXIOXJlMeGyOmcbnFwDeGWkbLbLadFdqzafpMODPk5 PFkyMnMLDPPLbcRG2xjbYmsYAB/RW6iKKVMMiSv3JKScq6/F07adWCwNTG0zHxtQzdQjc8zZ /C4rXEWjgtsbYAAdx21K0/5YwPqeJL7P4vH9m1b3a/fS2y6y7t2XW16F10TTHd9GFfup1U3W kY/AqR9qWTOVmcvY+TPmTMyJ8Y6jG2LMZFwy2RrWujH1schabXU7JHxrJm6FiZWJh4jXyY0e nyRS4piLS5roWlsf1rZKgV6V0VKaI44Zl9Rd7vffc8PsWldeGBxn8rYUjpZpZp5MyWeHJ74S wSNkxxbFa1sYio0V3s6fEs0egYrY9QbJLLNNqrOHlZDywPLRHwmhojY1gtaT+L4100TRHcHz V5qjm9nYqUS6FpWGWBov0qM6SzSop58eOKOOJk8LwyYNitpR4G827di3kRaSSOcpylm64uXt lmERFTIUoiAIiIAiIgCIipAiIgCKUQBERAEREAREQBERAEREB8897/7ngeOX54V4TlXB73q8 bnCseP8ATO8bfN/2iF7v3v8A7ngeOX54V5/kfHa3CyMmnakks+BgB+dy1bVZrtOPMz0WZNZv ur2npVClF6z4xUkAEnYBtJK+aH6fLlyD5r3ueD+USV63nDUXY2C3FjNJMokOPUxvnfHWi8v2 WNArQDZtXnvyq1HcfT/T7bUZTf48F1IgrVyPP+BbDXX1tBI6+hYMkUIPWuJ7iuO2+eNvpPaP jK+mr5e1xa4OG8GoX0rCyo8zEiyY/NlaDTqPSPgK9HLvxLqPm/qcX/bls7yMpUFSVUr0HzCC qlWKqVTLIKqVJVSqZZBVSFYqpVMsqQqkKxVTRDLKlVKsaKDRUhRwr4CNxUB1d+8b1Y0VXNrt GwhUywigGvgPSEogCJREIbqiqglRVZO1SSUqq1QlCVJqqlxcbRu6SqlxJtG/pPUpbQCiDMuK AUCmqpVTVC0J0LWfYms52RJjSTMma1rS1r6ebH+MyN/or0H+YcP2GX1Zvu68/VTVeeXLRlJu rxdT6Nv9TnCEYKCeiKjnuO//AJhQ/YJvVm+7p/mFD9gm9Wb7uuCCpBKz6SPmZv8A2tz5ce07 j/ePjRi6TCkYN1XCYCvwwJH7x8aQXR4UjwDQlomIr8EC8rrTv2Rv6QfM5NCP7I/9If6rVz4C 4miryqen1svTcbSq6tND1v8AmFF/D5vVm+7p/mDH/D5vVm+7rigq1V09LHezh/tJ+SPadj/M GP8Ah83qzfd0/wAwGfw6f1Zvu65AcrAqemjvZf8AZz8i7Trf5gM/h0/qTfd0/wAwGfw6f1Jv u65QKsCnpo72P9lPyLtOn/mA3+HT+pN93T/MBv8ADp/Un+7rmgqap6eO9l/2M/Iu06P8/t/h 0/qT/d0/n8fw2f1J/u659ym5T08d7L/sZ+Rdp0P5/H8Nn9Sf7un8/D+Gz+pP93WhVTcnp1vY /wBhPyLtN7+fh/DZ/Un+7p/Pw/huR6k/3daVVNU9Ot7L/sJ+Rdpufz8P4bP6k/3dP5+/u3I9 Sf7utEGrz4FeqenW9j/YT8i7Tb/n7+7cj1J/u6fz9/duR6k/3dalVNU4C3sevn5F2m1/P392 5HqT/d0/n7+7cj1J/u61apVOAt7Hr5eRdpt/z9/dmR6k/wB3T+fv7syPUn+7rUqlU4C3sevl 5F2m3/P392ZHqT/d0/n7+7Mj1J/u61KpVOAt7Hr5eRdpt/z9/dmR6k/3dP5+/uzI9Sf7utSq VTgLey+vl5F2m3/P392ZHqT/AHdP5/8A7syPUn+7rUuS5OAt7J66XkXabf8AP/8AdmR6k/3d P5//ALsyPUn+7rUqlU4C3seul5F2m3/P/wDdmR6k/wB3T+f/AO7Mj1J/u61KpVOAt7Hr5eRd pt/z/wD3ZkepP93T+f8A+7Mj1J/u61KqKpwFvY9dLyLtNz+f/wC7Mj1J/u6fz/8A3ZkepP8A d1p1SqcBb2PXy8i7Tc/n8fwzI9Sf7un+YA/hmR6k/wB3WnVKpwFvY9fLyLtNz/MAfwzI9Sf7 un+YA/hmR6k/3daVUqrwF5mPXS8i7Td/zAH8MyPUn+7p/mAP4bkepP8Ad1pVUVTgLzMevl5F 2m3L7yMeGnGwZY7t14mbWnVXHUx+8SKVgfHp8z2Hc5rZiDTZvGOvK81O2Y3/ALn+4t7QD/2m D/X/AK7lhW6zca5I7S5lqxG7pVZOlO33He/zAH8Nn9Sf7un+YA/hs/qT/d1o1Sq3wF5mcPXy 8i7Te/zAH8Nn9Sf7usUnvKxYn2S4UjH0ra4Sg0OytDj+BakkrI2OkkcGsYCXOOwADeSvI6pq Az8tuXELcaNhY0u854rW+nQOpYuW1FeLE78vzE7sqaEorNnt/wDM/A+yv/8Au/8AIVX+9PTG Uvxy2u6pkH/4F4CadkTQ9/mONLhtAqufqj2vbE5hDm9raPgXI9R6XnrnDA5ixsdmOLHQF+yr jW8s9KNnoLJyRX2TL/aHU9SNeHX0XlyCLH0bGEZrxG8R563P2n4ty62F3q9B5efaVpLfJHTR RVRVek+VQ4PN2NgzYbXyyiPKir3dtdr7iAW29K823ToWbXEyHw7AutzHhFusw5btsczKDwPY N3xbVpvXluus3hQ+vycaWY97VXHq6DXeABQCgG4LVmY13nCtNy25FrSLmek1hC6SRscTS57y GtaNpJK93oOnTadpzYZnVkc4yObWobWnZHxLx+mS4kWowy5hc2FjriW12OHm7ttKr6Ax7ZGN kYbmPAc1w3EHaCvRy8Vi9p839SuSpGFO68W6bd1QVBUlVK9B8xkFVKsVUqmWVKqVYqpVMsqV UqSqlUyyCqlSVUqmWCqlSVUoZYUIoVIVcOkb0DqqVUjpG9CFkVbwiA3CVWqFQSodKk1VHOO5 u8/Ioc6mwbSdyAUHh6ShKlgABRDsUVS5KFUqC5TcqHwKLll4HWNHkZLlNyx1SqlTWkyhysHL CCrByVLpNTWnfsjf0g+ZyaC79kf+lP8AVasetu/ZG/pB8zlGgu/ZH/pT/VauH/d7D30//DT+ c7FysHLCHKQ5danj0mYOVg5YblIclS6TOHKblgDla5SpdJmuU3LCHKblKmqGYOU3LBcrXJUt DNcpuWC5TclS0M9yXrDcoc/YoKGZjtlevarXLCHUFEvSpdJnuS5Yb0vQUM1yXLDel6VLQz3J csN6XoKGa5LlhvS9BQzXJcsN6XoKGa5RcsVyXIKGW5LlhvS9BQzXJcsN6XIKGa5LlhuS9Kih muUXLFelyEoZbkuWK5RegoZr0uWG5L0FDNeouWK5LkqKHG5qdsxv/c/3FvaA7/tMH+v/AF3L mc1O2Y3/ALn+4t3QHf8AaYP9f+u5c1/ll1Hqmv8A8tv+r3nWuS5YbkuXSp5aHP5oc86S9jCQ JHxteR6JcF49r8/jSMiZsrQtI7OzYN/gXs9Zmjj02YPaH8QcNjD0vebW/Edq8jMZqiNz3F3S Ae0fCadlg+VcL3iXUfQ5L/G1T8RWePNfFZK+JjfRrTd8C0JIyzZc1w/ouBW2Y3jbVreujQ4+ s+pWnJS80+QU+Zcj1lV7nlF03sccWtvEdwa+hs/3qrx2n4jszMixm7OI6hPU0bXH4l9EhjbH G2GJtrGANa0dAC7WVi37Dx89NaVDa+91Ge5Rcgjed+xUfVrqLufOwPOaxmNzs1rYjWHEubd0 OkOx1PA0LRetrUsYYWcGRj6DKukYPRePPHi21WjJI57iyEXOGxzj5o8a8k66nU+xYUVajoyp /EpJuWrI9npD41tHCa7bM4yHq3N+IJwIW+axo+BZOpz2Oh4zONUw3DiBvnW120X0PDmx34sR x6cCwCKnogUAXinADcFu6XrTsEDHyAX4w8x42uZ4KdLV1szUW67Tyc7YldinGrcdh68qpWnB lwZLL8eRsjetprTx9SuXFepSPku206PAzlVKwlxVS53hV1GHbe8zFVKoy4mpOwKxVRzkqOhB VSpKqStGGQVUqSVUlUyyCqlSSoJQyyCqqSVFVTJCJVKqkIoiVRAbJKo51PCTuClzrR4egKgB G0+cVDbZIFNp2k7ypqoqoqgJSqhQhC1VBAKVRKFTadUVNQgKtvS1qw4PYd43lTFY9BFVNVIa 1YcuOV7AyJtQfO2gfOsSTim6V6EdrU4TmouWhP8AFLBI09VmZPCIozUhwcT0bAR+FY9Jy4cW J0MzrS55cHdG0AfgUv0/NO6P/ab5VryaTqTt0Nf9Zv8A8y8393Vq0OvUz6tOV4XC40dNa11x rU74cCAQag7QQrVXP0XHzoGPhy4iGChiNzTv3jY5dURsPQV6I1aTpToZ8244Qm4pqaWUo0aZ jBVgVkETOpWEUfUrpZnix6TECpBWYQx9SkRR9Smll4sekw3K1VmEMfUrCGLqTSy8SPSa9VIK 2BDF1KRBF1KaWXiR6TXqlVtcCL0VPAi9FNLLxI9Jq3ITUjwLbEEXoqGwREk2pRl4i6TWuU3L a4EXoqeBF6KlBxEalyXLb4EXoqeBF6KULxEadym5bfAi9EJwIvRCUGtGpcly3OBF6ITgReiE oNaNO5LlucCL0QnAi9EJQa0adyXLc4EXohOBF6ISg1o06pVbnBi9EJwYvRCULrW406pVbnBi 9EJwYvRCUGtbjTqly3ODF6IThReiEoTWtxp3KKrd4UXohODF6ISg1rcaVyXLd4MXohODF6I+ JKDWtxpVSq3eFF6I+JOFF6I+JKDWtxpVSq3eFH6I+JRwovRHxJQcRbjTqodI1jS5xDWjeSt3 hR+iPiXK1nDzshzY8aKsTRUkFoq74SNykqpVSqbtOM5KLagtrbONr2RFmGIQmvCuqSKA3W7v iWxouo4sOJFhyvskbdtOxpq4u3/CsL9C1c7oP9tn/wAy1pOXdbduxv8Abj/+dcE56tWl49B7 mrDtq3xI0WK7yPUVSqw6Bj58WFwNRiDHxGkbiWuJZ0eaTuWXWM6PTcUTCNrnyPEcd2xtzgT2 vBQLv+GrwPDTv6I951omngzmcwvZ3JsQNJnPa6Ib9rTcSfAAuAIwwEDaTtc47yesrvRYQmcM rKcZpngGu5oG8NAHQtPWieK1twIpUCgqF5py1Op9Ozb4cNLdXmzh5by1mze40WitrOcKtb07 Sq4OBlZ84x8Vl7ztPQABvJKylU6NpKrdEjr8nY/EzpZQKmKOg8Bcf9C9rFFZtO9czl3RPZMM gkeJJ5iOIW+aA2tAK+Nddeu3HTFVzPj81eVy43F1jkmCtWaMt23V8B3raWGWG/bWhW2cYujP PcwCMvwzK8RsMjmvdWhALdtPiWX/ALfFiOZDYG2m0ClTsWbWdEmzY2WWv4d1YybSbqbQ7rFF 51+jZOObXOmgHhaaes3sleW7F6q0Pq8pcg7ajqVVXDaZXLVly4GGhdUjoG1SNMdNsEk05PQx rn/NVbUHK08guMUjR0cRzW1+AVKwoyeSbO0rtuPiml1s0BkwybA6h6jsVmRSTSCOMXPd5oqB 8625tB4ZtfjzMPpNBePjbcFrHSrT9HOW020I/wBIRprNNGozjLGMk+pm7i6Bkh/Fll7sRudG e3XxhZ5s/V9LZfLkR5EVaMZMKSEdfZ2/Kub3eZ1L81zgD2QCSajq7SyxaQ6d9whnyHH8eSrW +s+1WLmn3a+wxdjZa/uqNP5veek0vUY9SxBkNYWEOLHtO2jhQ7D071tEBaelYDsHHdG6gL3X 2N81uwNoD07luFe6FdK1Z7T4F7Qrklbfcr3eoqVUqxVStHFlSqFWKqVTLKlVKsVUqmWVKgqS oKpkqVCkqEIQiIqQhERAZRWtzt/zKaoVBUNBQoKVQhKhRVSqCUUIoKllIVVIQpYKwVVIQpYK wVQrBQ0i4KsCqBWChpFwrBUCsCoaRcKwVAVYKGkWCsFUKwUNIkKwVQpCGiwKmqhSoUkmgJRu wAKrugdaugJUqqlQ0SpVVKAlFCIUsihEBKKEQEpVQiAmqVUIgJUIiAIiIAiIgCJVQgJSqhEA REQBERAEREIFyOZNNm1DGibG29sTy57AaOPZIBb4l10Ukqpp7TdubhJTWcd58/diZeKeG3Kk gpujkq35CR8ywvx8h3n5bdvTsX0aqhcfT/zfUez/AGL22/8Ay/4PnsGhTTuq3izV6WMNPXPZ XqtC0Z2BWSQBhc21sYNSASCS47q7Auwi3C0outas43ucnci40UYvPeVds7XVvUoqt2dnq3Lq eUsoUqEAKqVKhCEKFKhCEFQVJUFUhUqCpKgoZZUqpViqlUyypVSrFUKpllSqlWKqVTLKlVKu VUqmWUKgqxVSqZIKqrFQhCFClFSEIiIDKVUqxVSoaZChSVCpAoUqEITVTVQiAspVQpChSwVg qgqwQ0iwVgqhSFDSLBWCqFYKGkWCsFAVgoaRIVgqhWChpFgpCgKQhUWBVgVUKQoaRYFSqqVC gbXnwBXVGbq9asEKiylVUoUlSqqaqFJRRVTVAFKiqICUUIgJRQiFJRQiAmqVUIgJUIiAIiIA iIgCIiECIiAIiVQBFCICaqERAEREARFCECq7rG8KyhUCtdqhQNhp8SlCBQpUICFClQUIQoKl QqQgqpViqlDLKlVKsVUqmWVKqVYqpVIypVSrlVKpllCqlXKqVTLKlVKuVUoZZUqFYqFSFVCt RQhCEU0RAWKjaiIUhQiKkCIiECIiAlSiKFJCsERDSLCquERQ0iwUhEUNIsFYIihUWCsERQ2i wUhEUKWCkIiGiQjtxRFClm7gpREKiVKIhQpRFAEREKFKIgCIiAIiIAiIhQiIgCIiAIiIAiIh AiIgCIiAhERAEREAREQBERAQiIhAoRFQVd0dfQpREIFCIgIUIiEBVSiKkIKqURDLKlQURUjK lVKIqZZUqpRFTLIKqURDLKlQURUhCgoipCFCIhAiIhD/2Q== ------=_NextPart_000_0009_01C78151.6AA91B30-- From owner-ietf-pkix@mail.imc.org Fri Apr 20 09:24:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Het6a-0003nh-7C for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 09:24:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Het6Y-0008SF-Os for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 09:24:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KCJhXh096155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 05:19:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KCJhtq096154; Fri, 20 Apr 2007 05:19:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KCJJ8K096133 for ; Fri, 20 Apr 2007 05:19:41 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA12650 for ; Fri, 20 Apr 2007 14:24:14 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042014195376:99046 ; Fri, 20 Apr 2007 14:19:53 +0200 Date: Fri, 20 Apr 2007 14:19:14 +0200 From: "Denis Pinkas" To: "pkix" Subject: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/04/2007 14:19:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/04/2007 14:19:56, Serialize complete at 20/04/2007 14:19:56 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis From owner-ietf-pkix@mail.imc.org Fri Apr 20 11:22:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heuwg-0007V5-Hb for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 11:22:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heuwf-0007J2-S0 for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 11:22:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEQJVu011115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 07:26:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KEQJU0011114; Fri, 20 Apr 2007 07:26:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEPvvX011081 for ; Fri, 20 Apr 2007 07:26:18 -0700 (MST) (envelope-from dengberg@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 20 Apr 2007 10:25:58 -0400 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_001F_01C78336.49661D10" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQ From: "Dave Engberg" To: "Denis Pinkas" , "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C78336.49661D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis ------=_NextPart_000_001F_01C78336.49661D10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1zCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA40wggL2oAMCAQICAgCfMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNjEzMjUwNVoXDTA3 MDgxMjEzMjUwNVowZzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEWMBQG A1UEAxMNRGF2aWQgRW5nYmVyZzEmMCQGCSqGSIb3DQEJARYXZGVuZ2JlcmdAY29yZXN0cmVldC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9g2Z9TBa7wYqlyhCoriYfugKX5mwz j1wVuDKEZ7ZsgoC0zT2Pm43BMkWwOL8GDXYMqbAt/1YelpCYMv8stgRDLj6N3DDyCNk4ihZONITf o7F+RxnaH782KvJ5YwrIXDKMXWb6oqThFVDM05QKgC994W6Zp555F7NFEvPA/4rqK/1Ba0k2p8A3 yZazUimG3tt7x0tz6K7Z043ezRSUBB8VwgNSr4tQyElyuACrU3IA90yYZRm1maDe6jWylqDOXU/P A22IC/Ma1sJ42k17Nhl3i/37SLOsHSLcyJk7bKgJPSgSqI+OBzYaDX6YGdoV6O/wih9f9YrovAH8 zF2pOXcHAgMBAAGjgdgwgdUwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6 Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwIgYDVR0RBBswGYEXZGVuZ2Jl cmdAY29yZXN0cmVldC5jb20wHwYDVR0jBBgwFoAU2Ox/kxjFZgPDEGw8BPZ3hT7/C7YwQAYIKwYB BQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vZ2VvdHJ1c3Qtb2NzcC5jb3Jlc3RyZWV0LmNv bS8wDQYJKoZIhvcNAQEFBQADgYEAqMfvLi9brJBbTKdWcwUJAWPHgex9/KhvW8nherc7imLZdFXH jp0NTTtgDK+aO/EJV/97JIyStyhfIH5vrZpb+ToFXz4O0Yb78KTHFdHjzlWei/Guo+kuUXouP8ZC Tqkr0mFlqeRGFbq7w2SJhwhXEcO1K5Y8g0jf+kXr1ejYw9ExggMdMIIDGQIBATBYMFIxCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5AgIAnzAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA0MjAxNDI1NThaMCMGCSqGSIb3DQEJBDEWBBTuoWN5 Q/DUyBp432F7QNJZ6+1CFDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq hkiG9w0CBTBnBgkrBgEEAYI3EAQxWjBYMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3Ry ZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgIAnzBp BgsqhkiG9w0BCRACCzFaoFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRk LjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCfMA0GCSqGSIb3 DQEBAQUABIIBAG4fBSksN4eFtjOtFBpY6m8miiNT5YMojtJX5EWeHyVYXnUSE+ftNudCgU0R/kLG 0Ji0TpmjlrRjSn3djXMB8LjZsBoXSi767LC1nJJJvgnmBWJxi7vTZxVkAOg4BlpPoJ8NQkW72aVl H4p7rTorKWmfSFG5L0Zq+3wj2Wy5bQnTk+ghrjmdCQJzfrahl7jAmI+b6hEVzzRsVNf53my/3GvE Zo5CMSp/A3/FUIW+8OgUxwHQ5WjMS+/7/igGbvIAgVV4G6aymtuOedOXIDu8mfX9NV0Cw8DdpssX 2fJjP3ftkiZMZWV4oXZ0lZQkC2R1Ir2aHpdFNaHGRJgMkkzhheIAAAAAAAA= ------=_NextPart_000_001F_01C78336.49661D10-- From owner-ietf-pkix@mail.imc.org Fri Apr 20 11:35:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev9N-0001W2-H8 for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 11:35:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hev9N-0001eT-3a for pkix-archive@lists.ietf.org; Fri, 20 Apr 2007 11:35:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEoPg8013366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KEoPE5013365; Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEo2jF013304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 924CA1773A; Fri, 20 Apr 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HeuR0-0000Ci-Bm; Fri, 20 Apr 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-10.txt Message-Id: Date: Fri, 20 Apr 2007 10:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : Lightweight OCSP Profile for High Volume Environments Author(s) : R. Hurst, A. Deacon Filename : draft-ietf-pkix-lightweight-ocsp-profile-10.txt Pages : 20 Date : 2007-4-20 This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client side processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-lightweight-ocsp-profile-10.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-lightweight-ocsp-profile-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-20091812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-lightweight-ocsp-profile-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20091812.I-D@ietf.org> --OtherAccess-- --NextPart-- From harmonyHulcoop@artsofts.com Sat Apr 21 04:34:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfB3R-0001QN-Py for pkix-archive@lists.ietf.org; Sat, 21 Apr 2007 04:34:49 -0400 Received: from xplr-ts-v10-208-114-180-225.barrettxplore.com ([208.114.180.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HfB3P-0008Sq-LB for pkix-archive@lists.ietf.org; Sat, 21 Apr 2007 04:34:49 -0400 Received: from MAINOFFICE ([144.179.162.60] helo=MAINOFFICE) by xplr-ts-v10-208-114-180-225.barrettxplore.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1cLOcx-000XJV-nr for pkix-archive@lists.ietf.org; Sat, 21 Apr 2007 02:35:15 -0600 Date: Sat, 21 Apr 2007 02:34:58 -0600 From: "harmony Hulcoop" Reply-To: "harmony Hulcoop" Message-ID: <258672687303.554462348894@artsofts.com> To: Subject: youre Avid MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Description The single attribute N= provides the next available identifier for use by automatic hypertext editors. AN ALLE FINANZINVESTOREN! DIESE AKTIE WIRD DURCHSTARTEN! FREITAG 20. APRIL STARTET DIE HAUSSE! REALISIERTER KURSGEWINN VON 400%+ IN 5 TAGEN! Symbol: G7Q.F Company: COUNTY LINE ENERGY 5 Tages Kursziel: 0.95 Schlusskurs: 0.21 WKN: A0J3B0 ISIN: US2224791077 Markt: Frankfurt LASSEN SIE SICH DIESE CHANCE NICHT ENTGEHEN! G7Q WIRD WIE EINE RAKETE DURCHSTARTEN! UNSERE ERWARTUNGEN WIRD G7Q.F UBERTREFFEN! The Color Table command lets you make changes to the color table of an indexed-color image. From owner-ietf-pkix@mail.imc.org Sun Apr 22 13:34:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HffxU-000601-VM for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 13:34:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HffxS-0000WN-Dt for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 13:34:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MGbDHj077522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MGbDLY077521; Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MGaqKe077475 for ; Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 09:36:10 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) thread-index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQAGlMiuA= References: From: "Santosh Chokhani" To: "pkix" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3MGbDKe077514 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 I agree with Dave Engberg. Prior to PKIX taking this on as a Standards Track or Experimental RFC or other work item, an attempt must be made to profile SCVP for lightweight operations that meet most community needs. I have not done an analysis as to how this would turn out, but got curious and looked at the signature aspects of validation responses. My reading of the draft SCVP I-D is that it requires signed data or authenticated data for valid responses. In addition, the Server must be capable of generating signed data. It seems that Denis wants unprotected valid responses since the channel protects the responses. I think either the SCVP or the lightweight version can be revised to accommodate this. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Friday, April 20, 2007 10:26 AM To: Denis Pinkas; pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis From cbHarrah@HAHC-HMC.COM Sun Apr 22 16:30:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfih7-0006Bo-Du for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 16:30:01 -0400 Received: from [213.172.56.34] (helo=[213.172.56.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfih5-0005tg-Ut for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 16:30:01 -0400 Received: from acer-a9ce03bbc6 ([115.122.83.56] helo=acer-a9ce03bbc6) by [213.172.56.34] ( sendmail 8.13.3/8.13.1) with esmtpa id 1PPEnJ-000KJA-Lk for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 22:30:10 +0200 Message-ID: <000901c7851c$ff2bfd80$2238acd5@acera9ce03bbc6> From: "cb Harrah" To: pkix-archive@lists.ietf.org Subject: I am planning to emit object code directly in version 2. Date: Sun, 22 Apr 2007 22:29:59 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C7852D.C2B4CD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.7 (+++) X-Scan-Signature: cadb9ba0ba1c1ba4f99ac017158fabc3 ------=_NextPart_000_0005_01C7852D.C2B4CD80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C7852D.C2B4CD80" ------=_NextPart_001_0006_01C7852D.C2B4CD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The white spot behind the translucent plastic would not even waver. One = day he's dancing in the corps de ballet, the next he's reading the = weather forecast. These young men both excelled in computer science, and were rumored to = be skilled in the art of finding holes within systems. Selecting = programs used during installation. Indignant social scientists tie into highly nonconventional beliefs = about the past. When overridden in a derived class, writes a value to = the stream already attached to the formatter. The 8259A provided support for the 80x86 and some other features. The white of her dress seemed brighter than all the walls together. This data structure is filled with the function's return status. = Rectangles typically are described by upper-left and lower-right = corners. The coming of Maud Brewster into my life seemed to have transformed me. Add the URL of your src=3D"" page for the "main" frame 4. The white spot behind the translucent plastic would not even waver. ------=_NextPart_001_0006_01C7852D.C2B4CD80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"even"
The white spot behind the translucent = plastic would=20 not even waver. One day he's dancing in the corps de ballet, the next = he's=20 reading the weather forecast.
These young men both excelled in = computer science,=20 and were rumored to be skilled in the art of finding holes within = systems.=20 Selecting programs used during installation.
Indignant social scientists tie into = highly=20 nonconventional beliefs about the past. When overridden in a derived = class,=20 writes a value to the stream already attached to the = formatter.
The 8259A provided support for the = 80x86 and some=20 other features.
The white of her dress seemed brighter = than all the=20 walls together.
This data structure is filled with the = function's=20 return status. Rectangles typically are described by upper-left and = lower-right corners.
The coming of Maud Brewster into my = life seemed to=20 have transformed me.
Add the URL of your src=3D"" page for = the "main"=20 frame 4.
The white spot behind the translucent = plastic would=20 not even waver.
 
 
------=_NextPart_001_0006_01C7852D.C2B4CD80-- ------=_NextPart_000_0005_01C7852D.C2B4CD80 Content-Type: image/gif; name="usually.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c7851c$ff2bfd80$2238acd5@acera9ce03bbc6> R0lGODlhdgLgAeYAAG/I/uf5/8jZr5CirqrQcbnq/4uwVdr2/8bt/le7/f///9PkuZfZ/rLRhafd +9Tt+nWaRNzrw7rLpKzl/mmOOZS2YorU/8cAANrp7wAAAMnT0s7z/15nbrXJ032OmuLv0Ojq637P /6i1vZ/EZ/H8/5fAWePx9lp8MPHz9dTd4Wp5hJ/g/1r/WsjolOj04WPC/jen78nn9KK9faPMY7/a l4n/ifT3+oGjUi7/LrvdhojL8rT/tIWecJ/O4vH36rPZd4CqRPL+8ENOV5LR9KDG2Xvk/CkqLLn6 /vn7/Z30/6DV8UhpJuD1xbni9r7lf+7v8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAAAAAAALAAAAAB2AuABAAf/gAqCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMIEzYaYqGhQwYPI0KcSLGi xYsYM0rcyLFjiI8gQ4oEQLKkyRcoU6pcmaCly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNI k7r85FGj06dQozadOrLqyasssyrdyrWr169gw2oVS7asWaFMdahdy7at27dw/xnKnUu3rt24ePPq xTq279m/gAMLHky4sOG/aaUqXsyYqmOrfCP7PUy5suXLmDNrHpq4sefPoCE/Fj259ObTqFOrXs06 Z+e9d2PLnk0btm3JuFvr3s27t+/Vr0MLHz66eO7jv5MrZw1yufOfwYlLn26cNHLTz7Nrx8495sjt 4G9Gv127vPnz5K+rD8++vfv3gMdTn0/fuv3u+OHrz+6wb/P1+50mX30EVmcggAgGqGB+Z/3nn4MJ RrjgYAOmh96FGFqoIYMTdvicWh4uWGGBJB5oooQcpqhiiOFBiOKLK7K41Ygl1njifTDGqOOOMvLo 4485AtmjUjRqmOGRSG64l/+QTDY5JG8gOinlk2h5YuOVWOIY5JZTUtnlTy6uFOaYX3o500dIFZnl mjdqyeWbcJZp5oNi1hmnnO2heaaeR6mZ5J+ABqrknYTiOWeDhRrKHp8wRZmmlWxGyiZublZqKaWJ Kqrppoxmuql+FmTFAJN+SmrqpJemiumqnh5KJ6t2tirrh6O+5ECTpQqqhK689gqrkaoGO6urnxY7 5K0tIctVrqc64OwKz0Ib7bTUVmvtqfa1ma2wwxrrbayv/tplmF7GgEQMTSTKLH3Xtiutu/C+Gy+2 qHLb7bf43iuuvsk1gcS/CnSa1Lq97mrwwQgnrPDCDDc878NNRCzxxBRXbPH/xfXam++H/G4MngM2 hPyEyF8RzC7E8qKMMQIXs/zAyzDHbMLMNAdgs8g350zCzjz37LPOQMssdAErl7hvxx4jrfTRAfqL M87KCmmyyqBR3TLRLmc9dNBc/+z11wCHLTbYZHetNdZoY9wY00svRy6Z4LYtd7FOo2D33U9oMMDb RE1dsMNWoyv44FvXbPjhiOOt+OJPN+7445BHjjjhasOL1ZFxJ12Zo2yPm/nchtUNwuIiqDQEqZAC XnXKgU9wNeWFH5C42ZLXXvbYuOeu++63n+27xZhrrDmn4c4q8OWfDy+l6CM3j4IIAzR6PGepr269 yr/HLvv23NNu++28hy9+/yexV+7utp0rP+XbwqfvfvLq58e88zboXXzf1f+tOvaw94+B9rMLoPe+ R8DxGfCAk8se8NbWvvh5jnPGgx/ovjU/xZXufjHyG+ui8roOAvCDA+wa+BDYi/L9znXn6091HLi+ 97nwhRM0VAXxBj1FaZCD/FMgCLsnQBGO8IcktIUJzacYGLIwgkZMYqX6xTv7aeqG+4ui/6a4wx5a sYBYDKIWtyg5HaJwgcGL4QOVuCcJmq40DTyimGY4urxdcFNQzKEHdVhFH9oxi0DkIi2GmLYULpGM avQU3KaHPBVeJVTfCWRp2Hi3GhYrjnKkYx2veEc86lEZfOyjH9MoSAyiEf+Qf0ykntDHEU8GkpF2 c6KxICnFOVJxkpS0pCz/JThammtsMLukKTIJxvKYUYyKjFB6frmbWzKOhvli5ReX6UpJxvKZefxa LcP2AB20ZHbJsllJGpcSmkmPJLvaIw9PyEyNHC2UiDpnJ0mpLVDKkJptpJ8j8aXMeL0SltCM5sso cojTJYABP1vKIRDQzYBlcxDVvKYCCEoTHRiCoeBkiMSARj7akZNa7FQVmEwpRkMKCyKHDOkKgZkV Y8azcR2Insfqac9mJjCfXRScXMZi0nMVlJrbfNxBVSK6nMbAJdY8CcgK8dOGJrSmunycF3vpEZG6 KUSDLORHR0pSntouBSr/TRpLXepMoR2TomAFWMRCEDXX9CyoFczpQwt6kgcIIqEJsFm6/vm0iRIV qN4xgVrfCs5ZwtNsF01ZRp/6yXVKVUqDtYo5OWkspJ60kVltYXe2ylWvjrOSYHUWN5NFqYMd1KYK HVtJHAtXbdrqZgVF1hDGN1cdZM1g6CqJEgjxAIGqFrY8hIRlA7vYxBoWiRz1bVUu4lTCxhCVb1Xl 8ChrrXvu9quzk2gAlPDZkFH3n6eT6HXp+rSUzHa61Q3baHFXVADM7JAL9alLKBbd8CL0JYbbqVbU AlOu8XZawk3k5oh32EEN97+l1C/dvqfcMU42f82NZGXr6zPVgre6Djac/z/nV96IuZeWaB2oQEtq g9TOZIattatYTyuICPvzwz9lCwLCisvL3pe4TQ0wYtX52/4qViQg9WhxYOzR4O6ItIybp4/Xx9wF 5zaAa3Frz8p73vXyrLWHm7Djysrdfn7kyAcogpZllwQtj8rLXd5yerUsVESc2HRKnquTkVCroaIV XbsaLZXpq1sXv7acMcYxZIjZOUQO+c/FNYmM89zOHtf4KsgFWEoLO+P53pQTrYy0kZ+55px1s7Yk VnOUL4yCukQOTVh2snfnbNo6KdkQKyAzjkvcKFZz99FydWtQ80rCwjGVx3reM3AdLaeoAlg0Ow4j oLmT6FS+cdieYgoRW/866eeaoLUoWS1qwwtXf6EX03EVW7rEjEsSaxgGMFgBecENA7eSG6AvIDe5 tQluh7KYrx8usaqjjQQPhxbV2dxuleWN2xbb984YxTWhDy0mPzdaqhGRbcJzvfD57BrIQY4snw1M EmW3LsHNtrRWnJZhnWV41qK+coOLgJIN5M4B695dAtrtNQSkfOXhXqi6wb2zdMecES4HN2m7WZIw i1nNQB3CitN776C6m+iNQuWKlw5wPAtcx/qqlVAJfmNBQz3YvaUqshFdwAJTndd8sXgUx15ZEc/5 tNd1bV3zHe2eq1rcSyZ3AU4ud5Wz/GcFqHvd2Txzdt+8bDkv97fLjXL/cJ/2CPOWLbxfALWDnjkm IMvu0P/ddOncq6xnP7jVGf7rQrd981cnVLGNPXG5iX3ZRTPy478raJmqpH4Czdm2i/BsMhfAJeo2 LzUND2KYT76fhgczmF+uc4ABQN1+f4HPk3CEI6yV5i33vQJgTu5sh8DwK5k70o3p5KgJHeiMx/TR Kf/iIuqaxp0d7dcVzvn2a/38oA+0CyFOv38Jef1M+wTq9+/SxytUWcyjaRA1TiT3AiyzbkMwczAQ fiNWfNHngGamgLknfdJHS9Tnd9i3cvfGau3GfM23PU2QciGYezZ1d9s2VMt3FaWme2JlTW62gbG2 VE6XdfBHKBZQADeI/39VB2zuh341eCf/Y0vQZX8Sp4N8pn9kl4SvA3KKV22IY3Qb4BDO13g6V3iC pwMKyEPnRncQiDsJKIHtpnddOILZBoYpR1szF3TMx3uCYHMsF3intnsZ+Hbb91B1E2FP1oRDc2vm 94Ngdxwp0EYGJ1nyxyqxUXqGKHpY5HVGmCBImHoYp3pBV1MdN3JeFioL2GC+V1t394Vs2IB/J1pd ODZKsIDe0RbnRWeEEGchYxISiHdmGHOfyIlveIZ3hX3Vp2SXKD7VBVcsuIeaNIP4FXp+iCDf1XiN GH/KyIPF6INsgwFCWH9BxoTO6E6U8ojMBolzZBKWVYlLpoEx4IlAI/+Gf+eJgideozhinPZWmiUz lzA41NJt1DdzDJB3mTgIWFiL4OaB3WOF/wJzcDeADdaOxhdaaqZ2dlZ5wvh0Dbcl0mhdhISI1biM FDmRQOhvX3V/FrmRv5JURKWEkgY7lSZhXvY4cueJzBcyiFd3NveL4thgd0deueSRNIlQMlUtMSlz +8h3c1iSE2B4M+OPJDCC58hXqnYzDnaQPbSEm9SDAoYgQfhYzROOmidKHJmMrYczgSiV2rY3EnmV 74ON5aSNC+ZPCAk0aBICR3aS1cd8BciSQHlWo0g40yBiJVZ8+QiGzReX9baTgTcBq5iB3CNbQIVl /Vh+Czlw6VNsUrf/dRUJlpCJfnHIlbikkZF5mVghlmMZiZu5hL0oe3snl8U3j/N4c9cHfdQ0etFU k6mALhZohqkWk4WXbTDHeC1Ymzjjdi8gdIAHggrZmQz0lMkzEVr5VeDHaJiZnJEJjcU5hM/jlcoZ nSehmSDJmZTzZbQ3kzWTizezkiYIm2n2fX41nqxZnokQM0HVbgD5XjuZl9nJV114fIWpVC/Ff33Y jJGhQkp3NxH5h1gpnYdEf7nDiACqnNTZTNbZP6lWcqHWlmGmbkM1lKV5lua5mhXaCjBzXXFYipn4 Uw7qnUU5lNzZmwkJnBv0fsO5ecxJmfG0oI5ZoDDKjc35kFp5bDEq/50HqmBztIU8lJ2xeI+YZaFC eqHBAJcTeIGiaZu9U5/BaKIMaWjIWRU0KpU4+JU3eqUryqLSuGhXWqA5Wp0JSpThNoUb0GULSDTg SZ7vtqZqSqRuinPUxXFm+IskgJvSxKQx06QPg6LFExIRKo1b2aJWao1dOl54RKCFeplfiqBll3te Rn3uRpoAoJpDWqlvSgweqoDMw6N4lKe/mZj32acARqkTkKimGhlZqqVjY6OnmpyLqqNU5IZg+Kd2 yaaWequXiqkqVggWMIt3WqKeun+el4gSIaAnBVGtmqip6pw0BJ3JaqAIBqZhmqGlOaIMdq3M2qa5 uq261JLZWkXCGv+cwtQUyzql59KY/ymd5WquU+msz1qIPviqTppx1lR9FYettpqvuMqtyOCtJAqs iHmioQqlnbcR+QRtj/muNLau7Boy7qqwrlo9ZMmoabM1IaadQZqx+rqv/HoMUPar5Besn9qUT0qw CVus34o3+AmxhmisumOZ8MqyxHqvnXBx2ehczoavOruzPNuxPhuywCiyekqyimmyTvkQ+0mloiqz +emyj4OoK8u0FSmvE5txOauxPXu1Mji0XWVnHPuz+oSnW0u0NMiMBdsRSVt/CCu1iciwDQsCD2u2 Ucu2LAhpVTuvVpu1FiW2gcW1Npu3Gwu2/8q3fYu3A9uQZzsVk6n/qoJKt4XIuJIDsyc7uY5LtTc7 rVpLuJobtPAYrn/7uYCrraILrmNLtogrtztIaFGZsnaDro6blbPEpRpDjDFrY7Mbf5ZLsTiLT16b uUwntH4LujgEq10buF8LtABbuHx4uKh7tCj7tmo7t10KUH8FvW60JM3LWNp7frnbQZ1ZscXru5tb ulYjsOW7p5cbvsZ7vOMLvsvLvKebuI6Rtg85iDKrBG47PpKbX86bn5QrvaTRvekLuLtbwJ3ruegr rdcTkqG7vgkJvAc8sqBattmbumdLv0p7v/krPrLLvxV8ux6sawLsvQQsvl1LwkNrviqcwCvMwsPb wFgLTeQrweIa/78WjHVOmzePhQD2C8D/O1wbzK5Y5V8fbMM+XMQUOcIoXHYWy7kn7L7K+8JS3MJU vMAbBMXqG8MPPMPvW8M/fMMGG42Q27imGsS1s79f3L9IvMbCpcSYy8QGvMRy3MUKbMV2PMUGjLxO HMeoN6xs3L9jHE+BCpG1C8K8mUqppAGBfL1/bMRqfMSNHFJuPMdY/MRcHLyYXI8uXMWcfMdWXMm/ 27tbfMnaiHWR7Mgx9qeLLMg9nMZyW66KvMisesqoTMu2vIyTTMl8TMoX1csp3MnA7MnCnBG67Dvt 68t9bHm0C8byu2rW+1VGO7uJM8jfg8a3fM0hPFi5fLe6q6ARzP/NxTzMddwstPG97LXL3wzOggW/ 2fzIZEVLrHtSrezKOLausQy9TlTL7qzP2IzN21zMlozMmSzBAbvJBi3OCP3GAT3QB73P7czMN4iR Mxq9zYy69nzPjDvE/ezQG/3QIPHPAC3QIh3SoEzHwdzQKH0yxDzAI63L62zKHV3EGItFOUbPIUGZ GJ2t87TMFV20PM3PPV3EIO3SRK3ORl3K45zU9DK/K63QRX3SMW3ToBfPipNjRHDVPXDV/yvIzpMC GvDV1PyyzjoxEA3UZs3RP+3QQ03SJc3Qbt3Wv3zQcp3QMD0V5/vUhluyUV3Iy6jKiwjWXt0BX51S RGC2XC3IgN3/sPnsEPKc1meN1nvtvGvN1nD91pbd0ic915m91J981FD92FINwJSKyIKtN9Bz2oNd 2IrltonNrDWkn4xTqo4N2X4M2rU82Xid256t23jc1JrtK4XW2Xf90rbN18q5uItQ2oF92gOA2oKt oosTqK3Nrq8tEm7Lw3Vd3Nod07hN2X5rBOAd3uI93uRd3uZ93uid3uq93uzd3u793vAN3naNtr49 3MpsyAiXxpQUiIpM2Mzd3AD+1c4c1oMN1rWz2PUMqFMZLUG93dnd4HLb3d79OkagAolg4YiA4Yeg 4YbA4YXg4YQA4oMg4oJA4gpg4ih+4Sqe4Su+4YpgBI/d23lt/7qRHdoj4dd2yN8pJQH/DeAB3h8c oNxtVOA5PaAioNqna0WuQ9sPPts+7eQSztstU+Et3uFV/uFXHuJZPuJbXuJdfuJfnuIsnggwzuQy ntJlDcn5XcQ4bpMgkNpHHuc+/uMD4AEqkAFBPuQ7LuRvBc8iU93M2ObHyuD3GdwO/uQiEeUTfjFU PuYu7uhWDulYLulaTulcbulejulgjggU4AOargBl7rx0vclMbuOnrH0DldocsOoq4AEiwOM93uqy ngGuvtx8Djn2w8+Mqdei3uRODtqKvugV2+iRYOKKYOxffuyTgOyfnuzJHuoxPt/1Hcyl7tGRjNxe rQJCIOvbvv/tHOABps3jsi7rRpABgv3qr07gOh7Ya1xsVdrrvs7rhq5nwS7lFEPskMDsj17sy97v kqDvkc7viMACS5Dm2Y3mtW3qtxw02s7qdu7tDu/j427nGWAEe47u557xWc0rTlvT8V7oEG7W5qKW EmvO3nzZuozvjwDwky7wLp/v/v7yKx8EiMAE0A7v0k7fCJ/wNQ5/cCcIGsDq3v7wQh/rdk7xeB7n WA3cuWbGtYfzOQ/y0Q7E/FnvmB28Ku8ILF/pMq/1MQ/z/77sTKAATFADLIADODAINz/1oy71PX/N WEP0rP7tRe/qRu8BFR+3Bl/Wgk6lHq/SxM32SV7V5Um89t7/QVnfCFt/6V2v+F8/82Hv6Y+wA2aP 9iywA2Ov9lHd9tX+9h8s93OvAhF/93YO9cOqmnB28AH38R/sWCRfs7uN8pU9OEagEJOwA2hfA5iP CGsv+I9B6m5/6JsfEaIf+kMf8Udf53aO5MPvfhj87jqP0KavZ0BmAVav21pT+7YPCSzAAi7ACL0f 8r8f9V6M6M3/+cYf+g4f+s2dAn9//lQf3VNK6Jxv/k0v/8Z3/dgvMdoPCAqCg4SFhoeIiYqLjI2O j5CQOzg1QY1GFpmaIZydm56gn6KjpAymSqepqqulraGvsLGys7S1nBy4uboqvLu4HgMiTay2rsa2 MTbKIE/M/83P0CYPDq3U1sTX2Q4T2yvdx8SwDhgo5c7myzYhkY7c7t3D8RPT9Aj29wX5+vvy/P7/ APEZYUewoMGDCBMaqoFjxyNM4IpFrIat4sSLEjNqnNXLl8ddwIRhHLmxEzl00VKa02YRnsuX3mCy DCfuQTqVSFbmVEjonc+f+IIGHEq06L2BPJMqXcpUERMWLCw9JEmVYsurVUtq3fpqwMevHUMO45qV 1jicKFNilRlzZllQJ9PuTLuOKdu7Mfrp3cu3r195SJsKHkxYUg0WDdlBfMt4bWOykCOH6AiWcq9g A8ZKfmxSmtxzN3P+1PTNMWmaET2jDd3MQlOgMOsJzTvbqP/tgIEL694teMdhHDhYVJIaaTHn46aR b17uyavlymGDaWb+ONnn1dJQW92uXVNc7HN31l0Ku3zt87fT78vNu737SL4RB6/hMKFx5VnddsdP vfFzYP9dxotY/FV3HXbT7KfgSN+BBp4GIrhmF16o0PaXhRdmeCF773XooSBM+AYcJTswEZ59BeaX HHcp9keLc7mI8IQGNIoAHYEtQmYTgg4qw404Lp51oFMiEKGDhOSZ19YG6DWp3m0cfiglYfEBJ5yJ g92Xo4oLntbllo9R5gyNGnjgkZkD4gimVkKyxuOXK3qXFo09qtSBkZ28pqR5Tvb55HpTBtqbfFcS V5iWa8b/qSicQbrYi4NlBpimmolu1IRqQ9a5KJCpNAheWkWComeFqJRqKoaopqrqqhrqFaWgsBqU 2Im7IVopi5u2dWuLXslYiI1nCgigSC5Sd2mmc/rIiX5wtnkOnZ/e+cqoe8rm57XYChTrtggdJqWt u3qZq7iMhjuSB3KhKemk0plrKbKfxeRJacl5CgK0D0ZICrV8Zuvvv69yK/AiOLjw7bjuNktuwgtf dMiN7ALzI5vyNszZjp9Gk8+y8tT7Gb4HphBqKfyaajKrKKes8qUsAzbwy47sENXB5TKsMLM2n1tn sOpG3K6lugY9GsJywptOPGSS2cMQFmeCMWggHzhyKyX//7njv1jbEzDMXAcx64fg1pxzKdOJPbYF 6BoC7HNCCDHp2yl4A7TQd61SntyuHEtryEl30HdF9t4b9d7SHlN1XwdcrXjWjG/d9cAyBxr22Tgv 6BPlTbeSwiEw6tK2EUYIO6kGN9NtelGmW6x3I3T6XeTrwhTe6ccp1F7nXBAunTmSSrVq7crAB6+P 449zy0J9NKdONJfLX262zXub2fb0oFf/NoCUcmr39nXfPbTyTu9diO2u3wl7kaTP/uyMSd+ek8h4 pjahhokvbhPjWYf1y4DFb/uU+EvR3y5M1jzmFbBumFNQARDBgc99rnqgEx320qc98J3ue96z4CoO AMBn9P9NAueTzliIoAJItc9NypDdRA5ntfv9zoX401b/HiccQU3ugLvDIfcSCCcSHCIFDTTCAyEY uusBiIJk0yD3MgiQC9LLEwHooPlCiBlgQMhMoSMfhAYXHvjl8BMsdAkMXyg8MgaPeDOc0v9s+MTK GRBXOnwewxBhIyESEYIgwZ4HOlBBJTpxiRj0Y/h+CIKeYYaKaTKCjLboN+xMrYfzo98YY5g1NKbx QzUYjuQEGcdOAtJ5PKSJDznnQDve0Yi84GMShTYv1f2xiX8k2ygHIbLOdQSRvABd+RrZOqWpkCRh bOEkzVjJS8KsYLC6oSfheMCNyTFciQjiHU9pRFW2kpP/rvwkP7TZxk04qwMcqKJlxIk9IWRABef7 JQG/KIpgwkM1ZYynyixpzKYEx1CCiFwyEbjM5XmzYUwMJSuiiIjplXKaRXybNQFquR0uKaCxlGXi nKPHGB1SBMPiwDnjxzR/gjGSkhwmJbFFz3oqhRLHM0RK94lNj7qUmxAVKAMSkYIHCgGheDSkvhha MXa+UigwxZu4nBkDdQVjQL+46AD06FOxuZMb9WMSMUU6VX+V1KQKqeEaCYFMlnbvpWANKixZmUAO 0rGUN70pTsN5S6G2lKdifWhEAblUtqJTjxhlV9nCuomnKqGq8mwcVhGCpUZQYhDeGoQ+vdrNt/J1 Uf3a/yYomfnGnirCA2mFoEEbOEQhqoujc22qNhMUSMm+0qh2fRtbRQjXZ/IuKaXdBlVHCrDB7qaG hFipAnDLWMc+FrIU8lNPRVtZUzzNENJs2/48N70MgM5tZjJSbMkK3LF+dbJ2q2vEPpI9h8rRr1IN L22LaVvC8FaxXe1qb3372+rKNaZu/WQ/Z/mwzYakI8oNYgacC12RwHe4K0LddLG7zdT2LDppIlZj /QnewDq4SVctLySggghvMUG9bLzugtubnAEL2LTepa4BFaEB+4ozF/k1p2Yzo2Hshni0ELWuTCha 0QAtVcHEXSFILzjb8fopwhI2rCYP0ZBMcgsTHmYvh/9b/KdXivifkFVEXj0bks6l+Kb79eyRkvzk Lovxwy0mFwkPjGCjdhesDfZxDIEcZEWc9xAy0+16uaxkKLs3rmCmc9CYZ1YGGimpJ+as24LotmN1 zMl77nBk8dGp9+pHH2hbao3ziD30Adi1pigZMQD7YKu2OSlvRgRiBIbkMLtxw4qWL6IdLVxT31kV 9EXuKa6I0byieNAc6IE90BFaVK+lyU3ykmTHbKbM1K4DkiZzsf0WX49qOjbiVXNtP50QCseM1Hqm l6tfPVc6B3vVl7YzVmJdCBXEhNa2vnUuNHATImQ70b9uYXAdSlEJvI9Gxc43u/wb1mcLjdPSrg2b qT3/CGtjtdTv1vaLU63kauUZ3MsjsQfOXesiqWt66zbHnRTea8cs+uGMDnFIfqVsPe5RMxwX97jn 19F1/jXggiV4QQx+8ITX2eNMzjmwt63yL0qZxeULNMZxsUh389zFV3kHYFn9320QYQAOoiigI9aB 7+WYNP7WVbRhTlKZE4TmNY9xw+ENcZszET1lJ3vPN31Zo9cIdhfPbzg3fvOkw2bp80iP06xB1Jgg F6lmvuuA+O1slqdu64jn+hgFeJkOfhrsXWN8L8Suc37avfIEvvvOO752wCki1+6o5evint+Jjz3e QEk8yCH9VSKoZH8m1/ewJsbgCbV804qfttcdkVgJ/xvB7EdfOOaHr3fgd36Dlz236DHD3FyYvu5q Z/rmH54KqP8K9khdbaVZfGqfG57Hqu+xmgce5N77/uxpD3761z99zouW3LTkftAt3vxcnF6D9nio +CnJPU/ZkhfKFXvRhXJXlwpZp3/hl3uyQX7lZX7nJ2OUp36qRnw/lX/ot35W4RPwJwis9Xajh19y d38wlndQJVVngXbtB2uGID1uY1AJlWyShkTAZYC253Klsn84mIOswoCD5YAPeIERKIEU6G2hR30D hnO6knzKV3HpJmj2122+ZYFSSFoJKG8k+A0mUF8GRT3ah1fd5xhppoNiqIM8aFI++IOrN4TRp4ZB CP+Bbmh5reUOSrgjEAJ3IIhrIgh+VhhDQUNuQGRTDgRdVPeFa3GA71SFY0heu1dhM0Nwv/eGrdJ0 SCeEbAiEeSiHiZA2HsSEVhaCl5h6iIiCVnOFMXFcHChoLhiAgziDyJckNniDiRiL4leGl8QQBiNz jxiJutiGE4iBlgiJR3h5SkdTvjImIVR/DbSGyghsUaWAfUdQv5JWLlg9guiFLhWGspiNY0SLM3SG bZaLogiMwZh5lMh+42h1y2g60Kg2HRANdXhIzJVfrHh22ihMJTiMWriFdoRxsrdT85hpO0Y3oViP OMiNCTEJQ6YUcXaLXgeOKSiO59iLEfmLkiiMfZj/iZvjQe9If+r2hHc2hUaRHc6ogQy0hYDIjwl2 e0hIDIbINAT5knlhkAcBFQi5FIchZw3Jh7tYjunYUsYXSBaJiYigiShAJpx4hx75kaAIk6PID4SD itRDPdbTVtdYg3jBlPUokzOnSV/TLcGBPIuoAA6ZhhDJixIpfOYYhEHpAACkiVXnga8Tj7ggBANQ gAgYks2Yl1w3D2eVWR9hSoLoj2hpES25AgCHlYmnlfBxWIrViAbBEI4ZloIwlk25kxBJWmvpkz+p jJ9EjDOia/FwlHJJl3Z5l/ogDbt2mnvZJOIzAEMndPpFZXXJmWBolTaImJ2mmI9wGGApCN7YCDeJ /0+SKZad5nAU+W8ac5aaWYFl2VqmSAjBYHTccGwXlX0p9nyl6Q+oiZuME02cNXdNOGhG4FxCFE4r 2RKFyZ2yqJuNAHkFl5CPgGHDOQiUWZlkCZRPcxIWOJhp2ZzNNlpDgp36MEVxCSBOiAvZWYT5sJ2s uZpTmInfWWuk10D7xV+zyQpwSDfpOZDq6UIG2ZuJcGHwWQhdGTOROZ+T6aAfx3psAU/nAJS06Uf+ GaN8+SnPF3obaXEGOnTmhqE+ClN6OZJOsoHIpgNE94FzOWhp5QEAsGXKCT4b2qGHGQPcKB8gWggy c6VYipOMEGooWp86OaMtGjgs+qT4J6Y/qoIZU/9IQEGgOrqjLdijaTqnpzAbUWSneOqgmeh0Gzmh uZZDh9Z9UcqhHUqLWnVPe4MYhbUIkyCcbraoKJqiKvqQdXo7+ymjPbmijkan+ZkpIiNXOSqhAOKJ dMpT++CiQbqgeTqlqqp6e7oNfQqCCMqpMJo6gyqlBZlVjnkYCVmTkPCbRBaphgCmk+qfgeMjtbqc e5KsyLmmg3ByDxWqMPids1qqqkaoQnoPr7pL4ZmUmcqst5qtIsWDXgoVwYEYJ+oIXgpn6fqlrNp+ rMJJrRov8tqfl5mFzvqsdCOtyQaAk2etQMqgqYqtI4UIKfB8y9eJRDeCgcpN4YqrPSZ54eR4Iqr/ G1x6CEYWlhLLAe9arCm3JJkyiVC4rJJoNEMJqvw6aX9Ko/+WdwN7p61qn/5CR26XsLJqnpt6nCTp isoDsWRoEE+hpUxRoodwse5KsHvpkyHLrPaas6UIL8JgsNy3JG56RQZKGSoJsO/1sj67qjRLcUhK rTi7mT/xsF07TGx2YULLFIuVCPIprMQqrmXKtN7wnGlBtxPpZJ1KOO62AV8LEzlqtVcrPVrbmWf7 L60JDzmKjGUJrrYpkIfbY0A2CWvbFMDatsIqqR2btHhbt46XOCwLYm1oHfnytJxDQAPKhLVUUXWV taGrmpt7qtL2qrRxPjcrpwrauGX7fZCLtLgZ/2FZ6iHrqgAZm7n0GbsBV6/N2kFMgmdpCS9eJJQr KBMiA0LoI7hmJgT8WafD6Kq+O15Siw+L25HmBkugC5IXaLaR66GLyZAdQrSCYLRHK7fh2Lkg+7nn y5wtW1p7+zHS6XcnCxsb+Xas6xVmupSpibwxS0kGW3X3ML5JmpStBoTqu742UVKHAanvEbRF66iR Grf0y5M1ir8Cqb/qaDS5IzThi7IVR501tlRO+rqr+r2zewjM9sC2S74tU4VfZr5QxbvNSsMwSU+2 KCiNuqXGWwhGYMH1q7xa12eMcKlzK4796yaPlIQ2/L8+MUVG2a+Dh05ODLszzMS7Rkc7DMFiK/+7 PAyJFWzBlgSs7+GAvpHEhLDEIUxMmPpTkABVJozA97IadDc0CBDAAlxrLuzFs3fAA7vAa8x1hEwP ORzBvCDGTUw/jwttZJyXaOSeU3Je8ju/mRxyomu/nrvHeohBN2E7bpLCF/TIStcEXCw4iHxXF3qm uautHkvJ57GBxobDdijJ5auDhpkebby+xMPJgaJb7Qq3Qpy8pOxEftsO/DvFqZyRVoy6y/srrDZF sjzLtba98zrGzjhVP9S3vmy9twuai3yfxRy5joPMgXJht/i2mWvHCsyUz6y3Gzg+W3yICHC/7mjN oLI0tQp/ZaJ51stuh3y132zLaszI+dvMeAn/inwrFJH8nQMYADhIsk4JxC8RyprsZiO6LY06x3R8 vCA9Sb4IzdHMCEapNM1Lgp2qynLBygWdxeZhPlrkzZMMbhJdyTJrxuJbvR/Igo3XyOLYzocbMIzZ Nbw60sz80wSplnksvYTESK9TOwA9JlyUE4QXUK7sDzotOMj2whLTs36sei4Lr6+cLWFN1HcieKpI 0wm8zreBv5HwiqeS0vfDHlgyvAKjqCeN0nydz+lHpB8UO/wm0Md2O0WybYRcyMX4joMracqT1iYI 0eOMvtoaPVtnu5LmfEWC1L+IjVwLsRxSsWkE1VFd2Lp72d4DxbS0fK4TnciGCxnpNwo9PjZN/3mR /Q93Ai34hsiWDc11W9d5utaZzdZuXc5qfL2iiibRKdX/gNemjJ+nnd3aLblbWrmD3TX2TN312LQs /cPXB2jWm2xZtEVQQw6BHIEtTQgQwicgZDsLHXgehtzn68wyu0A4bdFUpF1ZrdacrXkdzbOv6NoY kBuU+92DFd4pTdWwLX2mqwCRslx7lFcAoki67UsNe47rOAiPPRS6zdXTOiklrJ2kDdTGaTWcUxsJ TaBVNtphChDW/QjXxdeoGRgN7uAHp+PLTbY+TQLapVMargIcXom7O730LdyrW8DlK30EHuT8jbgv Phvoo9hKJUIrftcBORrbHaQCK+Zkvo359P/JPv44EB7hQm7cQCF7R1pF0em0Omve5VYUJc4MBFzZ uGvgdt3WBX6fVj4+5jzUWZ1OyIZRU26PSn22A3HEaf7jQC7hhr1Nszy4DkzeS67NTW7fT87nKwpU qQnomkqRgX6atPKpWB4798KJY63LQe3RPTzmZV7rti7mRiAzGhzpabTmIF3nPp2zazNpYvEXz8uO /QIytXPpMOznpw2Kt0zqVOyGV/7cIiABCg3d167oiz6Kpn3r4B7uUWUEEOC+jlBC7IDukaDukMDu j+Du504Q8N4I807YbP7awAdpgadscZPvqXe6GUQmer7sPK3FJbjR0V7q/wztZQl/wqDiwU3/nXBJ 4/1dG43etaEj7xqf7hu/7h3f7h8/rJNu7HmbdkeOSlaE7+bxMDLm6d2MPUkFxnt4jxFd402EgiHO gRDP3kUp8bCDxzF049LcPeJe9EZ/ABnP8Urv8UsP8k3/7iGvxOJ99M0I7Jq+fTRWaRRk9Tt758lO 19h7GTfG8HkmyoIu7W/oh+osu3mOAcdW1jLy8FVvj4z27VR/982Y9Ey/907P91D/9PEO+HWM94T/ 52aZ73VVjMOu9aOsln44tV//8nwu9xNM9mjP3BQ+yMi+89bcxVm+w3Rf3ZeMurTOxHrf96j/934f +KtP71E/+CPP9f6+AsCQDrYm3cVO56tG/yvvndOdH/ZfzH2cy+KXf3a8L1vaCSHQoNuuvpd2D5Ma Le6nX27RlInWP5TiU+8KoP3cX/3Y//0P4/3hD/6H4OuFj/ccffiZryvs9qwCmPsqb+f6So+eDvyp dNZUvvCmfvMKDwgTggWEK4OHiIMKi4wKIk2FkSYpGhqMlB0impsDMRsIkaGio6Cloo2oqaqrComu EwexsrO0tba3uLlGHKy8q76qwKnCqMSNxozIi8oKzM690L/RwawKRrnY2Q/at6/e3+CG4Yg9SJcq 6B7qA+rpnaTj4oiqHvLflCkgT/oamuvtKvyZgkewoMGBB+MluvWIFL9LmTahy+SJEMKLFv8zatwI q5pHVkpCihw5cpvJkyhTqlzJEkPLXdOGxUTlYeYxm4xqSttJj5XOnjxlrvqpSkjLo0iTTgpAS6FT e1CddmjUgUM6dFbZ/XvwFFwqDPXG5RvLTyvAiQETchS7FmPbt/GYosJApK2+uzZScFpHES6kv34B //1IOFVcpdwSYzPCuLHjx5AjS55MubLly5gza97MmbHiz6BndR0ddRwJqkKsClkt5J9WrqSjfn1X +hBZFGXNAhQYO7BvcG5rL0xVaSFKiBHTRfzNPGPh54sOh55Ovbr169iza9/O/TNwtcLDe6PJurxr dbC/h5NLta545/z06nanTj14t8Gbv5//R7wkfEvI6SaCB+7hp59G0D1H0oIiIVaRSw5GCOGDFE5o YYUYZnihhhxu6GGHH4Yo4YgkltjdUrXYd99+XpFXnhGpnVeRiuOlMgCL+NyFyXz09UbjgSu+choq DdllTl50sTOgkgQaCOQhCRYm3YlUVmnllVhmqaVcP/ro1JGLaMBBeea5JliXUNqI4207/kOfCmjG +WRvqhRpHF557bXVmfnpFyVhU24p6KCEFmpod3J6WSNqZJbJl6KCgJmTQmy6tKSbAbGT6KZOKvpV gXe2xyRafM7J0Z8fMcigiSK2CuKrsMbqqqy0zmorq7jmiiWnLH7pYqNCwNjOAKD6SNyN//FUKh+P WjUIKa+m2tbfPTaAuaxZA2oQbYuognSQroeiGO645Jbr3bbPRjoMjKxZNWawralTrJw2zuvNbbhd e1az0Pab7rQO4YmbP9gSWyq03VYTaLkZ0JLBw9k1PMvDEltHsXYVV3fxdRubS52/ns71LgdmuQuv vEEG3EhYyUJYraU8ZpoWyDSnzB4jdo6CWyP69piybwmD1MPQqg4Nbq0ZQlxRxRkjjYHSnjDt9NIQ Nn3rhFBffZLUJnJ99KA19+oKcawRKwFWqjUGJ6Q3L8Lyd/jqQ/C+SoZtt0JDrgyXpJPM7XO6ggW9 ysLhNpyx1x0bLnHWsRh+C9NQK9641f8TN35A5JcvTnnmskhuudKMX16L56KDbjXXpHseerl3d2VL JhPBPvKYJNsLZN6TUupyvsmVTOzMgLeu1qdvmcSz3zI7gO5agqtiH3ufjHt455ZXb3r1Dj+OveaT Yw+96JyDfz34lUNuPffkf26++Og3jfri3Ye/+aHLP9s2Eg110A87qlllO71E+p8rdoekiJQMLcgS ngIRNBcBboNvyPtdD+q3keYZhmgYzOAEtcZBWU0vahWCHwhdQrkSYkiET6uahxBHQhW20EKOe+ED UOi1bYDOhiahYQ5TkrgdztCHP/yadQ5GQV8RCRbLQpv/gqemL+VjZ/sw4HyW9LPgFe//dkcs3ssg wqwmFXEwFmwE4aRXue1tjIWjs8Xhzkg975WRfDp0YxzF18b0wXF7eJRjG1FXx/nR74uxwZ0CyLK/ AdFuif5qoooEliRmUdGKC9RiFiXJRd9lC5CECKMYv+Ux7/HRen1UYxpDeUc3enKPpOwcxeKIRlJ+ spSuRGUeOxnJ7/CNEiSIQSGVSDIm0oRGjARBIS1ZH0zWsoIQvOKnRoWWDQJSk4zQoDSd2cFqcuiD KczmDWVoQqzBkIRzPB0MRdjKb4ITh0FMp/t8uM1yqtOG5ASiH4WojWMChziyMCAv38Y2nvETbgIb poCKacyCUjJMDkTAFo8UwbphEprR/wFaJ92XNYiFU5SqTFwM3blK+GFuEjV8Y+pSmVHqfRSWJVVf KudpKHsu6hIZkUj/0EHBtvXleYwU6G4IatCeMrA9TqrW8bpIzSJCtBWc7KRSNYaxpkZsqdxw6b2a iA/ZHTKB/dQbMPfBs561A3Y+reKTFHnQPF2KPh244pyOOk0NWvOtU4OrXGfFUlvVVSl3TUpelyrV ATbQIhQx5CHXhrBfbtUEDWSmvDQVVrE2R6GTLKsJGurFZ0JUolDNrGY3y9fHGtOmyiNEPyTQAQ+Y jKb/MuwioVjJKTK2sY7FKVVsKUjKplWtni3AUYfH2d769rdayu1DIyvFmRJWuKGYC/9Wk8papuiJ L69FbmylyzygKlOoi2jkQHPWKeawta0YnKt44zre8pqXnuhNL3b6OpzZina0gqXdP00VwPtAtrna PStvqMveU0mKu9XNW37pQ5vuHlaTmAWughfM4I/xd3lkhS9AYpRQ77o3qfdN7HP94awHexi5bSuw ZIv7NwPjNhvdSnCDV8ziFm/xw9v6K2D1dMiigli1Fr6fFAtWWdjCGJkXluwTdjyR6JrYLtHTLUTB G97zOvnJUI6yeqcsrirv6sdj5Rs1dzyAGhdWq2oBhSCzS2R5lbbCPqaujP2CXTI7cr4e3q2Kv+fi Otu5s1jObWR1+Vx3ifjGl1iuevj/Fk1OXIrDROyvcPc8YtseGcnHuWxg6HznSlualnl+7J4jok8/ x9m6zSE0Qjd85kybms1gRrWAyyzBR1cQI99lso2lTOta2/rWVLayrq986jnnDL6l9d2nc6fpVXAZ ugDuda8ZbaRVv3nWIK6InFV96Wpb+4/KnvTxNDLaSkzxy27Ts7E5fWj5ZDvMav7vb9psDlZfMtor EXXQ5nxtStf73vbOt73P/RZUaIvbmqDEtx+M4xz3hwh6eoSRFZ1uiKy7uTpN3olfneSUyDthsjYa rjfO8Y57fNcgJ1eiXb3oIIs24Pv7B5qp7YiV//TgCTc3v9EtbpyFVtvQS/lAoT1x/5SkCZr01je+ hy70ol975hZh9GiHLKBkPxp3Tmf58ci9DrBEHekEN7mQI95qePsX6DgnutiNPvZ99zzPSn8EClKu nKwTu9jO6wfCEV71AWH91Mxu9lBde9uziwbWS844eT9O+MIbPtchR6yD7550a9m4H7lRud+/Hm6S s4IuVGfHAwLOeLRrvd+Kd7NiB+TyDrUXwWEnu+pXX3bWt57XJB82QjcC+Tzt5uoPzy6cU9/VzHfC 7p3HMqjVil+vEqjHsQ8w6qUePdc7//XPj770p99ivH++EmEaePIz6XDLDw4TdK9baUcefLgvAvcv Fz3fyV9xn7sl1kyO1QXmT//6P/+o/hcAEf0rNP8M9b9V//d/ExKA+Xch/Yd/9jeACYgBCLiALoF/ 99eAGAKBCoh4iXeBwTUj7Od5NocQ2Ld2TbeBByVoJnZ5TaA/RNADl5IkIlh+nQJ1N8d7IHhWCNSC Grg3ksZ8lNaA+xcAPFiAOyiAciGE7EGEQRgLPSgLAkiEBCiBQ4iASPiDSsiDTCGFRQiFTwh9qsd4 zAYgttdlVTd5pnAzu/eCq8AVKChFAmeDLgh6HZh7e7ddbNhd04aDn2GETAiEtXCAengARhiF2tCE eriEfUiAzbeHg5iHh1iFhViAeQiEQpiEf0h9lFiJW7h9mNh4ZFZBXphEKNNwlef/fd9HNCs4fm3o doNUemNmfI+UiQgBfykYixmENIpogH0IIXxoIUQ4Fru4IYaYiLjYiNvQi8GIErVYgSmRi8YIicI4 jLd4eBgYelQ2czeDD7Q3JJ6IfKI4SH9WgmfIZygofgZzimKoiakYatIYRV1UhqaXaHVoIAsViM0I PZOojFkoFycxibTwi8w4C4Q4hbnggIg4kAP5iFNYj8+Ijwq5kAzZkA75kBAJe65ofo5AebmkX934 dDhTegOhMCc4NKU4juRYjsNnhqzFigs3ke8IaRGJj8foks/4j/dIkBBpiH7oiMDIiAeJhVEokDqp kH/Ih074hAKpj1pYjhOZYRV5/xF4kY0iGXup5moemYYO9ZRI6YKfB4+hN2rMhGhJaY5hJItiKZYc 9JIV0YsymQ/ESIy6iJOeYJPFGIlU2JZJWIxtqRJC6ZNn6YBsaYHRmI5VMocwBoNMeSTalSk8Z2BR qZHfSJXsoC1WOZJHdjPol34vQ4MlJpilspLKlxhm+ZP7yJM3eQtGeY//qIhyuYgB+ZlBmX+EmJAH CZAtOZu0WZu2eZsMeZWu6G8WeZgORZJvJ5Um6JgGE5lfeZxueI6TuZUz2JUpuZs5qJV3OI8wiYhD iZDyCIhDOJrVmZoOaZZ4GJOumYg5OZOliZtHh5zvF00HYy0YyZEvpxfbN5Ugqf8kU2Gc6pmfpbBq fodfyCNxuglkmjSWBFoXWrOLn5kCx7iWsImMcomgCRqMzEiddmmXLymJ5wmNgLmhHIqbmpmUWVkL foOfislQiWmScUecdcF5+tmiY/iG3piOh2ZaAPqhfMKZhTmd1imaM6mdN4mFcwmUbgmTt1iXPyqa QymboemEBkmUfNmg6BmlUoooLooflLme6oeY8wmj2/gVH6k/9jlZGVmlx5k377CcJ/mfx9d3X4mj r4hiQkqaeumD4tmTFBik1UmnS7qQRmqFTlqnDUmBoEmU/liUUDqliJqot4mVIeps/POYSGmm7RdU Lzqc4agkYkqmVbqYlOqfz6b/nrBYoAaqoYNHqqb6l34JNuXHnzmapZCafNg4qlBpqfVJLJmqqS3a fWgah/xTg8jpph2phYo6rMRarMZ6rIu6qjCFpecXgrB6GtY4qSXamJeqeSyKq79aaMLJnGr6m20a nVaKrOI6ruRaruZ6ruaqrOcXrq5Kop16GmzaqWO4ARenSyOhFSJwq9iareu6rbw6LK34rdAkqmR5 qgZ7sAiLqh1KpVzIpZWKMwO1pQcQr13aQMT5e2e6r2UairtqmN2KHsIHrswqrOhasiZ7slMaoM/K niOrT8dno6oprw+bolzGghq7sf1Kkeo3UOw4q2D3rigbtEI7tERbtAupstsY/62t+oVFBrPS6q9e erHyQbE3K7HyqWcY8K8E1o5Qa0EEK4sJG7ZiO7aqWrWzQLX7CXVz85wy+7RtW69pGH4Yi7Zmy5j4 EyfBVGY1irTAOq8t2aSm+ZpJSqd1GZ6ruYB4Srj6mLg9OqiNq6dGG7keWrd5I6tLy3Yvu5ygSqty 6210S6l1m7ZL2bUXGTMBC6IiC3h/24jNiKFB+rpFmpBWCLs8+qdG+ritSZOSu7u0ibR2+7m1sEuZ C7puW7zGK2aciy1yF7qYyB4Z27E7C4Z7q5KBlwngdSuC66DjaYsTSJ4PGLseArh7GYEUgpaH+r3c W2UQmqoK274L+77wq5C+6/+vJ+pvowJ8zEuvyWufpUa8+Rusykm6vokVp0u9Pyudq5uFMmmPuMuE Sqp4ucunuhvBoZehkJuncZrBvLvBvXu8AqtL7BpoBeO00HmG1htz7vq/0qk/K9taxAS8Fds8Hlyb p9mPemq4GsyQOJzDD+mdPMydEbnDGPy4HFzETBG6LBvCpYuv2ui/Tuy2cDt3cqtwz6u5M5yf7QZv XWW6ryqwA/q1KXg1QhkD+weXrNmgPwioIpKgECqo6YuMdxnH7jvHdFzH8XvHR0y5Oau6IszEMGzF V6yaFjt3yqt5gXzIKqxFWeuxM4pW86uUFkSHNLy9OmnGFHrBgJnGOkyePuz/o0PMiG78wxRMxEZc yk+ciZUbVHGopYjcysWrMORWboacyK7cwoz8qTi7fMcrYD1MyTeMk6EsxHwKvsNMpJ2MyQ0Mp8Ls uEBsyrwsuY8cyJv4yu7prMwbxYS8FbNcy7QslS6xxW9WmdJcvV97oK4LzEgau4VYoezczm85oXSJ vrfbl3DszgxIzGSLx/q8z1xitrFqvBBkzafMzTMLcyhcxd2Mq+B8QMNC0NwGyTKMorPZp3DpyaPc g8vsuBhqCxh9u83szCCdrg6NyAylyo5qJiPdvJcXy9rcsyn90gOtxNFLwAXs0H0ryKvLuhpdnsaM uPgspEnamunMzIH608kc/9JGHM0oarnSGtAjDNOujM3EohsyN0RQHdNRvcgzvbVQHapxa73mrNPm a8/fW7hGTZfrG75lbMP07M5jLcf5zM9yDb9KvdQm3cfQ9b9jFiASAV0eQBZHkNBXvbR5oXN089fz e9M4jdR5fK4WzNiQLdJYHMBQfNJNO9jQ62+EvLZghdWY/dmE3W6N7KteHEbjDKeRndqqjdR1DdCD BCtOzcR6vdKGBrCkB9q43bw4bdg0enyI7bfAPcPkfMJuFdfGfdx2nNxzTdf+fLe7bNnDG9y5vdhc 2deL1cTTnd3PrdWFHTPTC7OKrb+rPd7kXd7S/dkl/dytddnXLDS17dd/rP/d8p223N03XPzbnl3Q Ee3apfzM/W2J/x3guXne6B0mQNuutjrfk7rX1f07X0VFGajgV7zQBwThpe21X02gyL3hHK7cy/3h 8su1G3uCwr3eayrhb7rXUzt6Fi7Y2u14o/3dNhreAl7jNn7j5EpxXf3a6m3it43i1M3XI9riQF7k AiPa9/1vL03jON7kTv7kEXkq+e3aTP20sS15Ri7ezvPe7kDkWQ7k9pvkOz6wGf7VHX7maO7hIN7B pcqY4ow7h8nKSEzbikUgXv7lEm4txiczVf6hTA7gUB7ogg7NVz0kfb7g0I2pBB6zY27QrgWyeD7l JP1EW+3IMP3n9wPog77/6Zwepa1t5Uig5D2eivebwi/OnA3edJAe6Siu2feN0Nzs1Rme5rRe62q+ 5iHu4sibc6Wer18+SFvO5QERbIGz6Ky+5IbJ21jR0Be+39Ss6Z0e7dKerMfe1G22YbCu4HRe58Qe 4dV+5M3J0Hce66mL6NN+7uhO6HgO5y6r6FkO7I4+HxrAU99+6tm15769HZAg62Np6/7+742N69T+ 6VNOFb1e7HmO6kvM7Z/o7d8OUzGe780uOIzefgz+PR3l3xB5V/OU8R21RhAjSB8P5xqf7tBe8uru 8KB+7Wu7ze++TH3m2/Fd7yPNVVrL1ch+wJXdkhlDAj3P8xefNz8v9PgY//JMMT1D8vNDf/JMb/LI quPHbvAR+/IKry/y3sUq/+uUjuTh3OZJxu9xa1ffJDWqQ/YU9Uou5E1pL05qD/AE9Pa3HvcCf7S6 vtjtjr9GDu8WyyQ8O/M0T9DC1HvePe6nrC2YHvRDzzQ+3z5Hf1E+r/FLf/TsofQ3E/lBf/lOn/kV v/mXLo0khvecX+D1Hb29audpUX2Ar2strxyrXvOSFvAWT5sZL/nwcxqKHwC3//i2L/mUBjkh3/OU X/SrpPkoT/ySPt1S/9TvPvoL3/V/n91XXvpL4veGUgmyVk0exU0u1EoodCFsv046kk1p7/ZyX/5z H+Vef/zWjl2fj99UP/91fH8VBBP6z5/6aTr4DQ8ur0//lw8IGQGDJAGChoiJioeHi4SMhYSRJI02 g4KVl5EZmJKKnpOgoqGko6anqKmqpautrq+wrBuztLW2t7gHubu8uiaTHQPCHsQiHh2+vcrJy7sK z9CFRCLUw8QqxwPYzM3d3t/gzUjRKcHW1yrGx9zhtdHv8PHyz+KykpmN+Y/7jpr+mZ4qcfrEzxBA gLESKlzIsKHDh4MQtJtI8dc4FOasGUNWsWOyeOWqncNmzaPJkxMvjgs5kqQ2jifnyZypYFqHmzhz 3sTAs6fPnxg4CfWpj2dRofgGGl0KNChSpkCHBmWKsKnVq1izat1qkWv/169gw4odS7as2bOoCkhc y7at27conZnIeG1j3JQYVEYT2bKairuAA+eix7LvyxhwESte/KAx4yYpNtCcDK8ew6oQM2vezLmz 58+eEgvGa0maSJciRntTkLcy3ZElVcuOSe41umGpUVLeTZjd4FhK7YEeTry48ePIZ/82fU5YbuXL XPPVhi2duse+oWt3p0EvBtvVccflvVuneZwgvKpfz769+/fw46OVP7++/fui1Irev731IA2nFTNA f8tJ5xxs1xGoIC+R1dZceNoMyB92FEpG3mSWJSechhx2uKGHIC7YTYDOicidXvSAF14wf5nook8O toTaeBfSlGGIH+Ko/+OOPPaoW2kA+iXgi7/4F+OBt7HYHZEuHolgOjTWKNN559Fn5ZVYppfllkVy 2eWXYIYp5phklrmQfhOmqSZphUVITYXbscbKTbhR51IxTDZ5UZvNJejYn4AGWqGUM92YilQ5aojo PYjiU1AhmCA1kKOP/hPQI5IKlKk/m0C6KSWSBvQUpJcmaqqPIu5pkzolMgmSiiQpmWeqTvZJTHa4 9kLoPIaeUtSpxf3KKSWk3oOpsZUKSxCxBiG7rLOiIlsVpZ8EpyyqwM6qZSEh2TSkqwYiuSKe2ipY a5K3/rhrPFSa5xW1TumjlLVO/dRovT3lA+9UUOXLr79LCUvtvvx2Av8VZv/aa8JRYlJ6UJHXminx xGfCuaagsuXkXDCRNdngO99Nhy6UuZZ715KqsorOnTBh7PJjH69bWckfoYLZUYxA0mw/icxb0MOj PDwwz8saPAnQRkdcaacMi+Kwzc9iGxrNVCuX8qrVWFz11gWCDCs2LErItcljc3PubcR0XDY7MoO0 Nis38/Orzs/SLVDdpghdas/DIuQ3KDrb/eklnwbuaagGjbrIolH76N3btJrQrUgAqg355XnFvJfI aKeLOdmrbS5jNut8jljb8LSr07asR3VV0//aTZRUAicMcFN6E3W70bb3ezvA8v7uOu4QL/zLtMUn 3yXBFDfvfGlpaS3/vdUxT14NeqZj/irn1YWd/ff9oWwJn3aS3vLL6CuGOsjaJ/szp7DPDb+xfzub e6fz3w240/s7ovSw9uMb/963NwBm64BSU47GqIE98L0tXDKixjYcSMEK1uxsLPve+tinq0TVrljy A1Wxeia7o8lCWfojmqZM2L8CWupYBoQWCwkXw2rNUIQydFz0QBcR6FmPgc+xINXkBEHDeI5mGmCM EJfIje5gUEADSKIGN1gT1TWQK4yL1+6Ah698GQyFvktPFuOVlH2lUHdRCRXdDjY4MtLuSzlDHLwQ t7zn2fGOO0yfHq2GgvHpRBiV22M5LKcbzUGDTuKC0BFzdUUmQseJ/0AKEmzMJ0g9UpEeQ0QOwnK0 SQTq0JOg/GQoefiR6v0RiK2Q4h65RkSvcS9WE1xGIx3pSM2FDEm4oZMqP3dJOUVHk54MziiHKUpi GvOYyCzX1RAZSCQqUYOGHAcicQMhP5UMMtikZS2fYEtJ4jKKHJsiFa04Sy+Z85ytQ6c68cjOdroT evmZ3irnSc90BqlKvGyfK19pjV0yMpuk9AYk+3hLIPLFHJKrJJx6mclkOrSYEH2oRCcaUFMusJxT SyIhp3Y5dr3SOmm75uoC+sD0XHRj4RTnBn9J0Za69KUwjalME/VMbTZUdYLUKH6QiCJpfjSKYBOp OjjiT5s6sJvnQf9pFOuJq16ScydYVJxVBLHR17URPlRN6LakapRF0XGdWn2nWMdK1p3CrKZMjZLk TonRjBZ1ON40IskYCUhsvsmojzzpxuoaVoUuhqENFU4n+RFNXx0TefgbIbMWG1GGFLaxNMXrW6/5 hGW6axVVhUhh4/qkuTKSCNgcJFrxqk/C3HOaBi0rYEMLGbMd6kOTIui9FKvYoYzji7yz7VDmeMM1 zjSmmf3tS0drurayzZ4GRSVmYVQczpaPkrJUwp+gStp8sk4lP6QcQlWKOpxoZFXNzMpXt9rVg5lX Yef1WRezStWsoldy7o1vV8co2nTaF6x3DK5q9wtPgsJTnoLSKT3/JXk+ZVg0ufV1LUeRiQQjPRFs eCpwE1uLGAlXF5o8Sepel+rXs642I0G8YN66Ur+iMa0U9QvhYn2bWMbqq7YMjjFkPWnLyG4tvOwQ sC/oxIMeT7apK0GtcjV7XWDtk3th04AMfqwLCl/2wqzMaH+zSzlAcrdtMeAxBXosAibLIgKtiZT8 IqM43rV4VCqWI9xuCCoz01YrPTWynA+o3znbGUflaIAMlvxMlvgTQD3ecohvmtwuWzghC0j0TuNM 5bqErQI84DPNppGNNB3aupo5rZCtfOV1BYMHKjgBB0TNg9QmuCkC0ECqU+DeLXYgAxplb+9YvcXY 1RqNwwuj8MKo/2odVxa/Yu21r/k7Mf0Sssb+7Strhc0WAMmgx5GmbpZFAG1wTpcCJ9gyD94q7bUm W2SGRvaCmfsfMK/aBWFhdn8Z3WhAqgPSFZB0jhdjTVylVKTAJneGF6gRTneY3p+hNgSwXWoKKybV 5/bEAmC9ar9BgtZdZCy3bI1DnCWWxTC++JlLceo7e3zOw/64Qnr9a+wqu8jxVLUERLDnlbf84Cy/ gcxl3nJkfDrbJ+AyvUGtbQkc2ya7PPBBu5wWRRvdSJFB+NF9UG51J5vdovXu9cyx53jL+zvwlkDV 6QRaJBI9fcHoNmiQekoolu5yyGCokgOdbQ5nWeUrT7i5U83VD/+kINGj0kBsWxwRiHuKWfHNrbXc XObDhYKrIk+8jTn+WMXTtOMJJfnd9R2KCj8b2gbIPM3jPoBAD3zmm382zkkNzpXzANvaroDPAcXM HfsQxHsVn8KFrXS50z7RuO9Y7pX+dHmgOifd0nPVhZHhZ1fd6pEmPvqk7mUGdkzsxtH0OczhZaql /ZKdPz3qs83lzhea9nEPf9zvjnDxj//YrSZ/yH3CbL/nG0zrv1L7+3pfbtL//e2UMFSBz+TLg/7z ADhzojZ6AQgB2ncCS4CA3Id52weAzrdzMDFQ5BNFbtd35ld+tQd3Gbh7tzd5YFYoWuKBGjWCGqh1 5tdyx4eCq5f/H9NxaDgGfWWlb9nVOc8Bg2dVYcFwAL3EgKhngJjncibocxgoABcIfkR4hEP4a8L0 HSGRcIzHakIheYvmeFRYJFJYhR7idLPXTWuFgZulfQWYegBIgAvYg9tHhgMXamdYHVx2buawekLH KgykcEFYhEh4hxvIgR1Ycr4Xgn4ogurXgXo4iF8mAXc4CuT3JaumhZlBdpxDgaWDY7dAcslAJzp4 ST4IBANnhpt4gYb4iXdoUHgIini4WaU4FqrGfhvoYFhoZB6YLRoog3woCgJAeVUYf9i1cg+YitxC iZVXgoaIcgKwiWEohpuIhpw4egmojGc4gMsIbSOoc0UGewJy/z7D1wCkmI1DKIjciHJu84evaH/g aHdgRo7leI7hSAqAWGO69zHcWH2x4IiJREkLEIQYc0+2sHaXSEVmOHqjhnO6WGgnWIfaWJDBuI5H aGo9YYTqF5BAtI5cgYvxgYRXwYuq+GSqiBWfmHToZFwLKZD7d35WuG8OuYKqSIzFuGUqqYDO2IBn KATLSIbOOGo0SQGhtm0dAIbhBg0TmDVJp3XXSJAb2C5DuYfrRg7jqDYI6YHmyJRNaXdM50NPaZEm NXdLaZTyN4sTWBdukoLS1gH+Z23kR237uEH/d5ZWl5CjGIoGuZZ5OJWnSI7aSJLbGHRwOZVQGZV6 WWx5qZcc2P+XkeeE/hWXVkiRTIeOtVd/6IhujJlsgHmVeDl3JRl+kil3gakTbrh78aZ5mwlvaNmM mfh/LbmS2xdqNYl50aaT5fB6iSQSS6aCNUcDtod7pfiXWLmX35iUutmYj8mbT7mbvxmcGTaIqpSO fDl597eVZid8XvmJ/gdt2SgDZbk+sFmdBECb2JmddMcJxGmViPmd4MlwuJcp2imeB8kEvbmYF7Ce F+CbH8Ce7Wl38Cmc7bme5Gif8GmfEXCH7MmY81mL/RkBF5CdIKCf2lmO/0mb+XmY94mf8SmfA7qg 7xmcwLiIi3mhtrmfv5kDsomNzMmhBPCcoXmAoVmamZiCqNn/YyjqmTK3mjxJjebjoW5JoOiWocLp nr3HQcBZPTjaozeKoeKYnj/qlERKocSJEVMGo4o0ADL6odbZch3qodOJOiz6nJ2Zh3UpnuZ5oFja pQi3pWDqpWJae/ppoIlWphE6oAKqptjpoLjnpmfKpiunpnBapgtAp2OqnWiKgXuqoGgKoWuqoXBq o91IqOCpoYj6pMw5Ap25omOIlim4qFUnqYwaoowab4P0okYEpW1Zmww6pDcKgjv6h59aqj4KqqMK pEX6jlzqqcnmXEnCAR6gqJNaq7Yqnb3UpB7qpIjaq08Ja+i5n8AaAcMKrLB2rMQqrNxZjsdqrMuK d73KcMha/6zP+gFSkaxQ+afBWacPao7xaaCDaqZm+p50SqcT2q2556bjiqjjCq5sqq7lSq4Xyqaq iqr16qvnKHwguqtRqq/8Gqm3+q/+6qQCO6kumiKbOrACO6OniqpHuSepipsNO7H2SrGRuard6Zxw iHQFJVcK+7H9+q9T2jaWWrICa69UdaHFCmbL2rLMqqEui63jGa3KyrI2C63WSo7Deo7a2pQB2rMI +q0PGq7dKqHaGqECiq+B2p/rGqe96q6CmqZg9p8JCqhKK6RXW7G4R6kLW7BcC7JeC7Yme7DMYSu0 yq8M+wESO7GiGrEW+7Zwq7b3upCH2qpzOVC9+CBLerZi2/+hIyszjRq4m2m3tLmlSqelOLtwM0t3 iysA0rp75Mm4kmu4K5udQLt73NqrAtCndyq1Tvum8dqn7Nm57eq5TWumqQa1Tqu6cRqggWqoWQu7 rRoBJhuwfIuCtou7tfu1lbpnmRpkEaQCudu3/WqYa/ubrTQzbhu3zKu1c5uxwCipIQerHFC96DC8 2Gupf7suPxC2MoqqO4uOKdteL8uyTyGsMIu+cpuzmiuzxrqYoaKeQkuf9Tm/PhuvU1u/VSuv8nq5 SEuvS4u/ftq+qlvAALyml+u867vAz0u7xOu9u/vAENy7I9AAZAsC4DEM2atnxdvBB8qb7NO2y9u8 JKzAsuv/lgR5aiq3Miz8bhP8tSC6vbvCwd27r2hrpIgavuNbvpXLvk1ZuSmrtkGcw4sbvjK7rfb7 m5m7wD07qPILqP57rk9bv/mLjqgbtQ0KoUaLrkGrtk2Lww38vC/ctTRcxmYcwWM8AyF6wRmsDRtc wSHqwWjboYcot3GWm/jHwCXMqg2psQSpuy/XAUInINUBYcKbxmeMjTJMKIIbaY2ap5KruI37uImL uJH8vkRcnl96yZxsuQJMtaZ7wE3suXoaugK8uWd6p20aygOch6MMup/bubAsy+07u7Ycu7vHu4Cc yGILx2j8y7X7u5agIsZgdb5Mwcgcx2NMx8ysaDUCkZGh/8d77J5hXKhjCYS7fLZJJMivqjIrI6vU kc3AbKuLLCUvXLe/ea1ye747rLPVCsRBbMSVDLPv/KxDXLUO6q7rim5DO5/8C57+TK7t6sWly7/i mp9T7LoFfdAKDaq7B8ZhbHc2LMET3QIVvcznLEUI+yRvPM41fMzK7MELkLx9mKOPc7zTHNH2lJDi 3NJ/XIvXZ1p6u7cXzcw17QQ/UM41MsdzjMtAGqzSHNR6nHtAPdQXS9To7NM0+tMMvM9M/dRCbdRS rdRTTdXsesC3bNVJ7cAhy8s3bdNd7dUffdNsHLwA69FqPM4lsNYgza8k/aLzF83eGAR3jNImXX9T Bpdhff/WK8rXBsuESPlTGszTYH3TOn0hyGfMKJrVSM3YtezYkA3JhDujjI3VDx3ZJ4zZmh3Zlr3Z jz27vazLFO3SIb2wwtyxnVOybJ3WIL3au+valwrbKigASMDN7NOCzXFaiQnVjlnV2vnVLc2ZoGd8 nmmlXnnaGdY5KmC94dzRX3vY5JHRJjzdW13dn33dWt3Yvr3dDm3d2e3d3+3Z4D3eH0DYYf3V6J3e pW3DgL3RxbDcpPPRyTzf9M21sq3MNQECPaWc3dPcu6ze5z3R9R3b952CbC3cit3XjgylGKzfuTjT dxJpBGveFQ3dvEHh36vdUK3h3L3hRU3e4r3UHd7dHl7/4hAd3iie4ib+0/xawwD+4oUt1i1e1gnL 2vRd4G1t4wTu2t2h0ftkdvANUrPa1y0e4GOdyDh+4Ep+40vOmdmc4HwW03kL4axS5FZ+5TRg4btR 3FWqeSH+5ZId5pQt5m8J5mZ+5mie5tjN4Wgt40aO5evt1adNzMSg2kze5ARu32ocuIrs4zzJ33dy yH4N5x+r43t+6Pft5Em+44p+qwnuc7ZNUOQT5OngAbJK6K+tglpOGWCreti44iI+4qHO4Wv+5XdJ 6qJO3SQO4ioO2asO6k+J6TE+628O4yBK45M05HaO6HeO1rJN25H+YIEOm7au1rye6Ive2ngO5ZRq cxxL/yKWDt/WAME0oOd7tumTEecJrtQ6LL5DbDDmJs+1TK3VWsRRiHeSMp5DgequftSwnuqs/u7t Lu8q7uImy6EWje/5vu/Vru/+nt78HvATDZg2EFfS3nm7zujHnuzKvtoSkN8c91HD3u//XvHynekJ v+wan+cK35mNnvFR7uAyTeURksaJfXzYThMIPqKZl9XmiazQurPS+vKT7bg2T/O1B/OGSMlHqPM2 T+ZAP++XreZEH/TxDtUgH+eYLs4Af97N1GB0ruu9juwM7/GqV9vRBOiGzKn2/uKGnvGZR/VhX/Wa uPHM3t6/NunLzdyX7uhPTs65esyNaqkevrI73MMw7/++rTqthZudlBvJMX+4u93qjEnvqs7uhC/0 hn/0xU7xAM7aFi/wAk/wBn/wDW/2mA/2Vgfxtw3hE6/0j5/0mT/6HT/2OM7BMP3snj/tuzrbkW+y KT8TCW/G3W33L0u+6dvDP02tfY+d4onuiRv4wSruiV/8i4/4xq/4Ub34r9/1ze/1Li75Fj/n3nwn br/wXz/gBn58Dx/shPGIa2/ITBr6R971ci/22K/9mm/6t5r6v7j6Lmztjj//Ob2DK0/ckMbYPA/z zQoIAoICGYKFC4eDioqJGYmEi5CGjoOOlpSPjwubnJ2ekaCfoaKkpaano6iqqasfra8RsbEjtAQy tbf/Dba7vLq+Ob+5wcPExb0pHSk2y08aIgMe0B4qKtIVuDPZ2iXc29jf4LnXvCUSSMkoSArrASDI 0tHx1PMi1AM/v8DG+vi9/d7dAgocSDAcOVwGgCRcOK5hLgwilKVr9g6ePA7VrIm7xYOjOBogfQk7 wK6kyZMoT/pb2UCWq5cuXWb4MNPVzJqUEHFqFKFmTE+XLHXSpBPoJk2FfBaFdQqm059Po0KVSnVq U6ZXrWqtyrVrhH/8wIrtFzJsPrJm06rl9wEdO2cW7UHbCLCu3YJ0EY4w59ZkxbjzMk67d3YfWpZg 8SpefLAgQ7waQPQlgQLiM3nTAtdTISyvsBZlQesj/5mytGl2IlPn8yrr5kvXPYcebR17q9KlRX0S PYQUN9GtWYELH86auPHgyIsfZwL18NjnzkWvjQ5duhPQyECUhBtX413G4B0KFKFg8tvLgDUPRsy+ euPvjsMb0Evrsf2R5i2nlzvN8+fQ1gFD2mkEnnTNgQhuBEtvhiySFCO/OShhJQ02mEmFFF7IigQb dogVKx+GCKKIyS1HikHtoWhYiu1lN5EJ3MHDgXfwwTdfgvTdeAND50i03V+YBYaZc3u9pyJ78sVH kEI6IsjkjhDsiKAELr4I5EX0UNMRjqoVVtaABYapQGdetiTLiLfxBFSatP1021FC7ZQTIXHSeUkl df9CNWKJzJnop3KA6snnn30G2ieRiIIzHXVpKUpAWG1hsB16FtXjn41J2sfDfOTlByOlQdIjzaKM lvlPfUcqGc59DEHpqpQHUplfB6Bmxh9n7QEoCphiEthAgIWdOaiwwwpK4p7HElussoS6YOizIULb rHunPupNqdhSexhEkp6XnqXWGhneSk62mlCnPk5aq623ahvuu9nCq2qNqDZp76uwdsNXt2/FiCV/ ZGLrkmi89mpagptWkLDCBnjo8CoP78lhxBQja/HFGBsL8cYcR7ssJ6l+ExZe1corLktVLuOvreCS Wy94vph7r8Iy2BCRCcyog8GV/wqGa8m/XucovIn/0kvyywzLjG/Sj8kamZW0DiY1RhhtdmnAutJQ sMEpYQ3vx812LLbHYJcdNqGfSIv22rIQfa3bQAsNd3XA+hPBZDwLRpjJIde1sNLj9Ijzj+uy67Op jSYW78njluv4jao6TVm/hYv689yPpsXJ1lyrlDgvaWvMduikMzt2xqUXmvrqoqs9euusv7425ixC RzvRThwEVsrtFH4Z37pj+vfwCe7L7+R5S0M1enklmvvzimsDtNF+P87qkuXKenxlUe83ZK7XrcV5 5yVZX3yyFYcysfrps98+6hKfLv/89KMf+wJ9D/12/i6P5Uy6K8vS3va3Km4ALl8IlJ7NnqYzGCVP /0jKax74oicyxlXPgAc0nwbLwS3tPOGDD1zeeipYmAqOj3zryFyLVCco3dxpNrWhUOjYBKc6vRAR NszTTmIRFJzoMIY9iVMPeRgU2bnOiEhMoidsN0EmOvF20LsbAH0XDelNr2QYZJoWuaQN402OMjur nHqo8R8VkuqJV3zXvHCURaRtcUqSSRfOuhcq/nQEjeJD4cHAVxzeGKU2cwLiH9vUmwsZUjZD2Q0M F4nDNvEwJm8SpBInCbtK3o+SeDRjJjW5SUjhrVZVqyIUdzEzhKHKSHxhYANDaLnLOe+VtRsIFtlo QCtiD3AB0d4X5yhGvWHjjKo5IQoRODOI+ZERFf96UDIjwSAGIXNCz7QQMzEkCUioiZrVjGb9tgk/ bnrzkrNQI/9smcZxvut/UPuWKI2WwaWhiIM3s1IYe3m4US4ueKrS1PU0uDRiSg6E89xPKGfERRoU qUsJEib53lkfV0QiKsf8BE5iGCHc5AYVb5oJNHXiTA3tkJFKiWQkWXg2SpoUnGyDnkrteU8rdpJ3 eRMMQgHSzvvQS3A5Uxkd6+izAWbSOi6dZT4h18Zb9lNm+opjTgPKU3j8sm4zbYBCO0fKHNHifi60 IQwjKlFoFnGj2PQNSBHZyGh6NBGFQutJj2i6taL0T0UDnrtW2kmVwhSUMhXeG4lJS/rULJ6rZOX/ rbwWVHxAlYlDzcY+S3lUpGZDl4SrFLsGYDV/HDZgU+VaY6O0I/dpQIaffWZElQkKZ250N+vD5jE5 VIj1CaW1oD1raePXzW/W1rO3PRZDd1tYclKvt+hkRkxp5MbNvqqWbhxPEAArXMH21Ld3+Zw4+7rB NnJ2i9fNbmPhqUqmGk6EZESuy/qaWYMlN19YfaRMtrpDjYoCtsskq3tBS187CdEUHUXkIVQ3X0u6 1Wy2JRtwkNRblhoYuJ9UpwdukUVYGfdxVSXZArfn3aZuxqdyvZ1fkVvdBtOspg5OGjkgu8peUja8 Be6SYQWkx9JQF0HB0SgNuRrIaWKomW6ycSiu/3njrqqXvcTa73+H7N+HvnV0dU1xkjP8qAUkGDAn 9og+h3fdvlpwLxNuR4m7Y7jvQVfJQmXckzzs2E1VmcpvzKUJmAtGE1e2nOzRcosNhNS/IasRN+Sq JODr2hp/dYiADkpqJQDb3czJtRCa028qmtsjB/jRkMZfAXn7ZQJa+jvBrcxwrQFiV50SZuDIcs6Q sdOeeVl/Gv7IpKfcaeIRz6r/BGipu8xpxR7tqTkob684SQwil67RvwYwSR1dZF8Tu9hrXbKy0UhO J8sRr1Gm5ZY+fCA4425bbOYlPU8dS1SCedXSpraUGUzuk5G4gW7uT6Ur7QRdiwmYww72sSNN7/94 z9vY8s73vX0NS2unmoLrnoEAniwjwbia3ERddrVwukvncjvM5rSsuEyZ5r8hfF6pXGpMx8jghIuX gO4OU5k7DmzcmvzkKB90yktO25Wz/OUwP13jOLxGWSZ2IBJg7qZV4OomjRef1RIPlikrR1Jz2XDM s+XNb63XvR7wzDS37rlI7UF3OHwwT2ISmbWuo5AXyKAyWBSy9W2/mLe13mdHu7DTPnayI4dFNv9t UJO0jYF3d10zqse0HdttuYsajA48OgRHdekIW3nEAT8vP0UcdaKWQOtPyPbGB1tUrnOdw1731eFt sXZ6m33fni8720MPercnfu6FT33NuWH3Xc7/Wi4zY/LpC3iOWb0e6cRFfS/ivnvgOZ4jrLYXOGw6 g/usueg8U54df//4y5M586eREme1GyWXW1/l2M++9q/P/e1nn/Qt7/7nzT78oi7d4+cnSM7dUmEe aAkaIZZ7+ZMrkMizX9PJp3Wtdf9L5tO/uCEWgBW3dYt1IxDRXZMHXgNQZ1mnRZwFfXvkfw21J4sW bIxWX3JyQ9+3Yw5SY7M1fqMXgqXndiRYgmYjThCHaqo3XfCxfulkEe63YB6QL0q3grZGUwXxd80l eGO0YFdWg+y0eNLnacHXeLfEXQ2nHxY2QkoyhPkCgS5GAAIIOXemVh6oY6kQIUSRNanAWmBV/wpb CIImOIIiCH5jSCxuw3tAOHuI5VsNo3OzBgHRYHFGuHp12Hx/hTeBx4OUZxf+thhOt13S938NOGbO h4TqgG6SNVmE93FCKGdzVj7TRwE7cgKT6H0TQwmZuGeaaE3V1FpCwVqY8IWEVoqE1olJAV+FZgmm uGfWdGigsIHiF4tdKIa0OIuhZ36fRoiA6IhydwMyQFkC4A4Dhx6bMg3ut3i6eIg+V4hNggIicH9W d3uDh2I/WGlPh2ZOCHXBl3XUh1RUJ2sBhHsYUS/4MonHxQNQ2DWDKIXAmDSlMGik9SCFNglAdk1h uIU5UY904oX+CIr+yIk7IYti2CdGVoZtl/+Qthg7QGdpuTN7ash/dRd2kdE2cwF8m6ILEriMd2hr uKSD+MeHVfNm34aCADiFD/Zizjh9eMh8x/ciOrNtnJaNdbaOKMGAtXRnn2hRo7WTiyRkiaZoH8iP pciPaqKK7WOQLGdvZKiQ7xNpa1iSBOaQf/gLZxKMG7F3R2guHsmMXckwxccj0Yh840hr1nhtEimE 23iONBhulseNzad1+PCSidgO+deDGMlYAmiTJwEBlkiJbAkBmLhMAGlfAcmKk4CYrQhNiJaJiEmU ilmYrriJg3mLKGeGmEmQ4KeLMyd/ECleEqAaWjl/lQc57+iVZFZU0CiNFbaE1dA/KdaSgaj/NN9Y gCsZJbRAAe7IlXsRjrImk1piXNOHL3xpErkJAbtpHwfpY8o0jz02mX8kjx/Yij35j7NRitfpUWrX lPhWkIMSlcxmFlLZhm9TFuWmkSnImR4ZlkGnnqlEliL5XP02cdWljQ3xGJjii1JYHwrxA+MQa4rY HVRjcOOGS1tUnJKoD7JZH8v5R/fFG9VZnRaFgdiZG5J5lNkpQ9p5hgODkAqplB4aoph5SbMUnn3n nwDHhpTmmRGpGL6wmvApkif2mrw2Mm7peCgJYb14g2K2nrtAl+oioK0kAzlaZ7SAoOxgPtNnmWal oc0ZW4kJIdmEnaFJIY6JnZC5iauoiarI/2ejl1ojupC1OKZiCjIvtqJ2yKPg5qI7ep+dyZ6qB6M7 g39Xd2EWtHc912rVlqZMd6YykAIDgIBlOaCYkRCAOZyB2XxImkL/iYeQ4glP0aCQKqlfan1hCqIc Oqmip6mcmqnb6V9M0JCiiqb0koIlCqc2mJbgWXf9AJI7U5aMiIwllJUDKHyjuXl9WhAK2numaQtA CnjAyXNEGpjbGBCLOiaGpy+sJzqU2qyZ6am1xZTc2anQ+qnOSoJVmartuaraapIt+q3FF65s2kWu epexSqM4SHF0WKtc9JlqKnS18JD0kXENR423Ymb4iqhg2WDHSqwMwaQAC6YCG7CVWaUFS/+wB2uG momwZUqmC3mHG9lhABiuyLlh4DpU9oGiaxixvmh/ggqrhGqnSoqnDliy5iOvvLqgtTBy4poDjvOj geojKWB0XRay1ECJOJuzN4CztAkB/bphLst51Rp+AHupFiOtDsWs1Dq0S6u0Tfu01voVpZqsInGx UYeWdKWxjqex3ap0HNuxMTs4OPOqM8pT1NABmTGsCEeyByexUtmLW3sjaSQgkmevPKd3h5qvO4sN QBCWC/GzHhe0/okcRUu0T3m4Igq1ijsIBom0i6u4kcq0DcscLAqbqjof/lkCK7a5Z6S5AZG5fDqu LOi5VlSuIIuXbMuuadZxWMS1JmmjoCv/rrJLDihrLfQapEESg3nnfsh5q+j3eAbUr/qKqAxbvAdr sMa7sJZquM/asJdZuNB7MW57eBL7uyrmrcq6i22qn5VbCyBAdDJLtvF5GZyRunnattconij6tdp7 hMEIqNIIqxSQJTxXm4Z4n8AIuPzptzcSvZugvP8bjwQ5wAGsckYLudPanQdcOm/6udgrcWhxWNKl uelJuq7bt/3phxZMtQ6chzEqoxphvuIWfw4RNyoocLX7uhv8rjT3vTOrZa9qtzK4rgtheGZxrLKL uZfnvw6Li8vbw0XruJLLuImrwAt8IipqEAXFuVl7Wf+2wqnakR/3Hqa7bc8lwrMZdiuS/6LxOi4X /H/7+ad1C4PyEIPH+I7miJ+ZYx3Cq7PDSYnHm7xxjLxzXMcGLMdAnMcDG7mPq8d4bMf+26ssa5tt FDTLhqvNCLcJwb/Ay7528b1jaXXTSL5S813ke760+WHoWbWK5brtu69hvLIYKxBvCRdUEsM5J1By WL9mhkHDixjCuw2HGLAFzMMDS8C3bMtfQcS8HMCqgKl9HMwJLMyRdsfXuglenL4QrL6dm71xlasO HLuZ68lyGw5VPL4zmZdZDHcrRsEF1jApTEqCy7fivLLV4gwTo2kcYoxnjIxy2HGpqcOPFSD6i0u5 rMs+TMv3HK0IfMRFPMze+WtquKtv2/9E3sxJHVzBt5bBUHxpmNuQNjPGZPwvM4rFdHi9iRfO3PzA LdCiGtART5O0IqAwnAZ/xwjPOBrKJNTGUeLGfkkBgPzHf6zFMY19tfy8+azPzmvMPC3TNw0xvLmn a6qyVuum+Pm1zijF2guMyQqvkAPJIT2NpwtewmrRwpeuTyXUKfvJNzDO5+XVCCMAGRlaDZBzJD2D 7czKL9u799vIqCK83Vi8vuzH/0vHdc3DQzyMedy4vbyUx+zPUfsJF7utTS093bCtNSzK8kzN9MkN Gj0Dj31KoPvQWv3U4CtPsHquCDOFo1sBXi17vicaOZnDG8nBuSAAZT0IwcgDCyhleQr/vIwslxk8 l5HYl7FtLj+8zzgtwE6217n914Qb2EdLzMKtMQ1NFht7jV1c2LCd0JoEap3c0Oi3vo7swRSW2bpL WclospUdtM79xJLtBDrsstU8cfspzZ5b3jTNIa6trhhsqDXsjbXUu57L0jzb0i2N2j5d03LN3znd 3/uNuMz723gdyImsrmpLyD4ny7ZK1G862aPM3Fu5yFD9wjEsv9WIXRe9F6UN1p+Mh0F4ICxJ3yNQ pOEKdsN60q2cryVuAPcNmBVAATLegDxb4nDdyJZXAbyt2+/D48tJJc7q43NNLHv8z5LL18PNx3m9 qabzyYw9aTZI2S0+zYG7uZBt2N+9/9WFbL2KHNFRPbbYnRnaXb6arNUqjNHxOlONquVTrtgxjt4v O8VafEeCXOL7+d7AC+N4vr/kjcOFyMgA20N5lop4opixqGgaWOiChoqpmOg5tKXwFUSvJeiJJCf9 CCeJieh3MkRBJAh9ggmIzsuhzulftSaPSemGmUhC5F41lrSTOqpIAwz4a0GwOzKoJDdYLsq5ntB4 PtvirSOmTXEVPraTPNHu/H7bTTObDLsljDnj0NGPktIqBOzfsOcM8cWY29FCN85Su9nAC+0NkblA oJtt3TB9+6O1bRI7i99radd0fKWTUKWgLorwzt5mTe/9iO/v3omnuM7zjn2haCf4zv/oePK//G7w +wXqoAihmJ7vBW+PdILwTpZDzIRnEd+B8S6lGb/xl07w9riPFyjYCI4jaDy94eKmIiHbLc7QKg2x tjpmJU6JpAyWFVvN5mPKn3XhMozs9Zs/v+fhBUrybXmad27zIg7ftnCa6g1hKF70+K3rdh7zr7zU fs54AaEQQw4Sva3xFx/xXOql2QfyRcvvow72NdTohC5FX9/XgfTpLoRDoN7wne5nCS9jdT/3DL8m lt72ZdX1fo/xcu/1i3YTIf8Uzx31BJ3mVD63iLPr+zsCkc3cqPn4RIWbi7zIKTvuCgO/OU+nqWzs vPuarQ35WEv6GB0SpM8ll8/CSS//mJff1ZnP1JxnRfgD7ZzczQxmwvNH3uFuEFXPjFiv9VsP8BZP 718Pi4cOociv33fj8F3/7+/Fips+XyDP963e6UQk6Wlf9nrf8Nwv9t3fSNa/iqreX3IfSHEv6jcE tbfvyc5uzr2XrUYSu73feCrPdf6pmxeE+Z4NCDOCBAQGg4YyPBEDIhIdESApkgKNAzyWlx6JHio8 npoyI6KiLRUNIzmmhKunoagtOa2lo6qohBW4JQapN7SFJYW9uaSDp4i/P6+3sK6hsYbHyc3JTrpA 17eH1rQGwrbSz4MHCuTl5ufo6eU3FBTd7PDxAvP0jvb1EhkZ9vr9+vn7HPkLSOke/z+CAw0a/Edv 4D+H+B4u2PeQoAB9CzIOzDgPI76JCClCvLhPo0h/JFFyxOiRZUCG9WBWRAmwYcmD/SKGjCnyY0qP Pjl+7MZtmNGjSIn6WloU1zVoUJVGdToCyC9sRJ/6sspVFIStTyF4exctV69gii7JcDSJkaNMHj7J 7eSpFVW706bxcJbXKF5TXavqDdvrK9VaFb5+NTaMMTt3NAB7yxb52Lt2TeORFSt4W9XCFcapG016 HSLCgrgKrbfapuuOPXkCbQ1ytUras2XGxk3xIskPuTPYzsmkNsfixmu7bCkcdvIIxoNHcLlS+GyT 1Z87x876p1Cg0q+btN6cHnTayP+LrrIMjFo2pqyqgXu/vj4y+Lra13o/VVv+/35BJY1VnUmTmoHG aLAXWx8scM8mcVkSCiZ7ORPLffHBR8OFDaRCnyob7qIeLgY2xhh+k3lYyyzwrGXWCR6Gwww1uGCW GVZ8sQIMNAeKVtqP6HCmlH8lmHcebRLQoJtr4v2G5HQWvZbkcOaBt9tHMwEEXHnaQWelkdxBqRxx X17HXHnUOUTecWFSZ+SXSEoX5m9NMgcmehwBWIyGTWWoI4J+7inogTvqWeJperLXH4+eseiof/KN koIrGnxUCSYSuJhpXGudoiKJFnpKyowcFlKqLyHyB+qIs6BiWCmVuffeLLy0WMv/YsrESqshJ7jT mKGfFupZfj4CaawCYrWjbLI3NHsDPlNGW1BNSS7J0JLSRnvtTtMmWa1F1kbpLUkArUktnNRqt2G4 sDVnJ7k8SZmSg2VyuR25ML1mJrffalsStviiae+d9Thr1mFZJSUgisAm3BmiwqamX6KoYUVYWF71 hyGfo+DlrSmZZgohYCIkcleOk+VFX6w6rnpfwilL5XIzoRiGnzEdJraZzpCJWPOqPNu6s1hjGXxx syUUe+yPnz08FcFHxutcv7oR96SVOXX3Gr07jTTPll7ee9sCLmyEHEbIHWc2nGb/5CZIAq+ptprV ZT3SRt3hvfV49q4tMJt4ZpRo/8eDEz6o4S2bGujiif931QwyW+ywxoh/GF81IP5Aa8jjdppIZDSH 2mGJfp5qelmF8uL0zZnnPHrruzIxw+azmiL7fqdn9ovjBK4ns35PKb00afmdtbtiEJANtdbjmidt 1F8HdWTaGzLvPHTNZ/v8ai5AnTb0yoMPOPdPBi7++Mujn7755V+/PvvwT6/+ag+30vjN9x8S6ez8 k56/E4caHI4gh5ptYANyLYPVN75RKliIiFTVi6AAPKeyDa2HVruLBaxgsT9bRIwYpFOYA8GBiwW0 7nLxedYCOSjBCFRAcCvazwO1ohVVKcozgSHW8IzlLKItq1e9yh60hsg5IRLxiP9G7JwSk1jEJTLR fUh6ovWcJ8UpWvGKVJReFbeIRCx20YtZpMfOEGY0shysaYUjIMRWF5gaqtGMn6nY0aJCtMLFbHdL uePo7CeyCiHGY0SqHGD6xMbVOa2MJsNf6LQxltAZb42HRGDQnIVH5FkDY+6oI7OEt8N0HMZ3hYER /LSXRPaV8otVdFBQotWgVh6ne/OLnvxmGcta2vJ9smxfGMHIy/jlUpXeG2VxRkRINNqQdZI83DFT 90aYUYwsx9PFgHYUrPx5MJmK22Pp+Pgn+VxIP9VsVRp5Zx+g+U+DOaIBE4wnKwIWo3euaw/oZnRN ZDxyYdDEHA0ZRcevcLKT54j/Y42O5std9pKLCDWo1jLiSgF8z6G0JB9Dbxk16k2Uor9cKC43qlEo dvR8uuRo4IZkzkEexZrYdBwCAzgxQxXPgJckJ6SEBc8ErnBjK2sn7rTZMRrVR5y+q8o3BejSBYKw LNRQ4OVeaD/NnTNDPoMqUiHWApsVKlmqYuQckwbQ0igLiGBdwmMSSlYpeq5bTUwrKT8qgpA2SKQK fdJaUXnQjpZ1lXjNK1v1alfm2QxpfzVZ0QTKTzK+dFGF3SqzzLhPpyjmV2epEUsRZ6IPZpMv0fgL NVtaTjgixTGedUUjVRHZz2lWFhRsKT4BaVW7aDKRcDTMD4/mK3hghlnK+mdX/8lxGds26wRIW95c oxjX8NH1lK2ZkkQrelGyufKhFP0eLD/a3ORWF6LYgytG+QrS6xbUrd89aWX/pMhfSRN13XQqHoc1 lQJOlrMoJO82lSkrzHmTAEq9Dwbxq8GhmpdRP1Mph6iKwg3Gt7+5Y6bP9ovOZOSQGZu95sVi2sZ9 WlK3u00MZsS62MQIN7tjgxPX1JQ1b5UYW/Xy2plyQmKwkc0jTMhajMkzNof2I20OKc5IzraRFFtN xSgh8duCY7Xz6A1u2VkS3wbWXBc0yHKZZVyBHhhhZp6Tgx6knECDsV4A4jS9rnpqpGJkVP/tVMpY Tqp6w5EVUSFzZvJtp+aiWv8MDsqOhfxlMDHkOef/jTCQ+bmtg1/rWMOgBsNdhcAJlhDWH1KArtsy 8bsyla8vSTokL8l0v6i1aXhZ+jkwrpoq36a1G4/6JhVJIlA6nWqu3UtKAFtOm/4Ga1SneNMA+2hs FWbYXlOY1+I1ZmBvlLFgj5ackPwm6PjMnmgq84zhINQyF9UAFRo2qJ98c5SrtyL8lpamTBHhDxo7 UMLcthuZZEcwlgWEdrSbq7tVxw85LKRmUTddtSmXuV6NNjHZODZB/pfc8j216NBaTDzG7nLcBGPs YkfEpH7TwBhO636/mkoPZ7G7mDynKslt4f5uUjAdVGVBvhm/lqVvfTs7ZQD/A+rZKQW0SuscIy93 EFI+bZyX+dzgnKPO5fD1LzFRquY04/mcU5WVgDAnMUla+IBXkRy5Z4BogFaF3To7DRalo2948Vs4 Tg71xzXern7LydMH77eLmVC2NVEcuhnPTtzRUyeIb5w1Ik8OyNGWd5G/PeB8Cy9ly8wxKEMZdzwa qn1QOnObJ/M041btzHku5Zn6fPJ1hnlPq5nGNa836O5kdq5mxASbAzVRwaKh4Z8J9faSO3jxlvei gevDHirCieOqdKYTYhMhg4s83+I979124t2XGN/BqUmrveYcrNlt+GUXNasFDvgwhgtv20Lx89FO fEyv2q6MBaxoQwvs159x/+gy7J2va4tsOp6XwrXHmMnNr/rB6kzmucrGtw15/g+Sv9c1hCsfcn+H 5VmP5UwGNGFR0StcYXuZ5G6P0W6ZVHWdVG+PtQyKAEzdcmq5p2k08XVeknZu93wAxyVKNmlKUhKu xlBpAnxdMms6dnf+xhu/JGNAJnHeVS/e4SQwyCQq2IJw0zdFNlLqMR/hNnlM937FNDFIZ2YpVHKW RSBPMWauFxWRF2234DBNBzz+B4Weh39HBU6oEiBcRmftVT+XJShu5FJSV3+pUVMAIn86o084cjEU uEPmVkclJEGqZoIeeHy6Nx5L1oKR5iTJtx3ZVz3fV1HFd3CyRDdoN3Ctkf8vzSeDjyiEOfg3IOd1 eueH3UcnNMZkFrc8SzhNCmZyjIcgMjRgIaRsBZKF6sdZU6eAWsY7rvd4Soh52PRyp3dm9ZSLkqdS vwMx+ydz71ZY7+V0m+VGgyaH9WZYdzg8XwVWELgXKaAQS1SI56J7HagvXbNxAidpnMZp2phrlNiI 4lhq3KKDzHOO36iOylVwShYwwVdr3Ug173gm8shxQxF/BuhY/Wd/wjCQaBGHAdJsJiUZTpEqT4dJ x5iADyiBtFiAD6lYDlaQXRiMSYFtpUV/oKGHhbYZhoZItDVHtQeRxfN6ROOQPWQyDDhbEBiNS/OS WBdZkPBFQehxcrcuN0H/jh84YhWniTcBlPyyfemoiFiDlB84ikPWYiCWEOw4HLdxZGLXibJBiUEo id5RlUsGXluhbaySkLClPyxHdJo1XolVgFkoMQfIK79GbOZXPzfUihk5ZZx3IsAolmVYbMr4f/5h ku4XWFL4hur3jJBTjZGXbr51GTJ5LGEBVgEIUfFIXNmSXaxUV8VlmdujgZn5XZzpRRYVXZOpXZ1J XdvlUeYzmiEFV7aIhpUTeUDTbPVBUppHkBb0lYozOTzSgFJBAYfgm3+Vbp9nkIBZVHkJdBFzl/L0 RwPElx2DNKOgGKBEIrtJnCt5jG44IK3FXpiUHz+gmM2YdRDZmDzEaI32/0PYiHt3pZ7ryZ7u+ZkK 1Z7wOZ84KZ/2eVxohZ+YiVzdMZAkiUa6CU3XOYwCaZ2gMZbuNaDwV5JZAZxyBJF5GKG7VmimmG3H BqDUdjD+SViKaYEYqZAw06G4JZGaUQK19VuJqUkKSHtfQZPuMHsd5kMUQJ5AwjOMdg0dqp99dZ/0 KQFvxZ9Aup/8aZlCEZoj16PcZZpKKpn3tqNLWprsg1g9FW4XuZE3FGwrtZDJtoTohoBxpKJKaJiJ EXpDo6Bt2YCHEilraDikpTrDICRC5Zy0CVNw6ozRWW3/YYHsdqYN6jR06IZvWqUROQLV6CvNtAGx lw64BUQkugs6Cp93Jf9XRPSjlcmH2kNc3gWpT1qk1rWaQtqkGeWkorqpULpRpUiGFFMrS/GnutOq 7ISnk8Oqs0iLOHqGUtqlAwqoXXFAjPUyA0g41iYVLKKFxAiQtqoUqUemisag0mmBIlKrYuoVzcQZ NlKoUjejiRok5+loavWe7klB7VlEGtAI3XqfyLUW+RmuPqqp6hqkqdSu5uqu5jFG4Wes4ldGBmOg ubpGgLWhyHOdiVCTzmitBhCRDoirvfVu7vaiBYuRwOmg/ZqrqSKtGsozXwqdniA0+Wqv+MqnGqYZ vvKiDEt7MlCoJcuiJ7qni+GsI6osGsaoBYujX0WjPwKTtZcM3tp1l3b/fNMXfDzrs/7wATobFMIH iMTRgf8yRU2ptAwBXejYe93nez0GfaMZYkfmo1SLZA23cI6YqQwljN6JbcM5p2BRsacYnXM6khMq pr1DrW8UsgpbnZGlogY7pmnpTNg5pr04tvXqIlt2oYbltgcKATlgM+P2jHV7oez3rxHpm3+2myy5 r4+pGDTrVQursmLhnrhma+ppabnWOTDRdpQmLm9lcYVYiA4CHBNBL9Gzrj4IdljpLyoIJjbYtPMi Lz3rcVMSu1MjYp+Juu2CiLvBd/yIHgR6hMAmpwv6WX0rnsEZUzQQo6oXaO0huYv5kE0jf4RrsRSb ZQW5r96GvGYLR8MK/6KxOX6A+ZGmpZYexr12yw3f27iO23ruK5GCUY2XtLCVSxqzt61AZFbcOI7g qn1H2UTmSLruuLmdVi2+ESWTeBKxkY0RrBMz8Y4LnLtHSYkFDLxUFGs9EWmxq8HsCrIdy7F9mrAt aXsf67wNar0tWxcui7DMK5HT+FXL6o8s+zPR2rE3vJiEVa/hd6ISEKMBW0wte7kurLZzKySLC1iz xQ7mCbENiMQiK6OLesPtsL+joWiOtqi4FwEbrGneQq4ZLMbjiHf88hvNk5UKvI3NYx2ry6nAtHek O3cPXME+WMD7qBO4uzccLLQQ5cGRCI6YyFGRg5D916qfN7h4m70m3P+delsXJkxNSiyzVBy3FiuF 3fAMxGpSSfxIuIgwBvkZIeIz1DksArDEEWqyOXxJoIOxqUMUIvqlwAWL+Uunk3t1IhmzWix7XZwx j+ZE39GT2ZcT6Dq61YHBedMca5cuygXCYrwtGqhxfgfBP5vHTgvHLjgmfex8FSzCBZdvzIfBrebM eoOVXkuRhyOet3IaMfO+6BugsAzEZnSbBEmtvQmtJHrJQdyw11kZ9baXMVuiRuNT7melcGpBfsSx 8YzCBovPHgtN9oozCXtu4BmLLbqSwPwULEqvuNDL6cCo5nmjBRtEY3zS8yACMCEDkUbGbiEQ60i1 oJvGKy1EqebGZ2z/YvngG0NEiOKizEyy0+VoxvY4xtqY0mF8wW8c0+mowTQBzkc0SfNsvSFppip8 1Q5IsDjcYUOcsVYMgYR6xDbLxS8ZgSmbdSUKWzJM0AkpvR85NKDi1XKdt9f7wiiLuWfdQ8AlyqHU uCArGLV619dJe2XtLNQoFiAdJFwsge4WvZl7RSvd0ulJwMLsL1+zajUNLTd9uj+9ur0BPj5NtONc iWOHfUO5x/coY0utu5z4wN5YtO1YvOCnhWt5fh2Zhq51yMn7vIFZRxNrt9p7y4w7uYwd0ZxBpofC w7qZ3OXGzu9sISZ1uLX6pv18sHgd1jNgqIH6m/iK1nDKlt493dP9/5wXS7IQkNjnUMUQewrtAGl3 B9Mh87tMDcAq6GKLqMDSzH0d3BE7Ld8zFrzqyIIDo3wU543LvDde933P/N6tzcfpcoJFGY5yrFEN 00yATbawGmCVXH4dqb6y7Nuxssvpu89r3cRM3MgrRdXnl3r0LM/ouuHP2MLhDdwr/K/QYKgAm+LK bazTydE1DtcqTG8TmK3pbcOL1sPPgtJGRBNr8Q8lM64DzOROXq6wEY9MLsFV83tTHhH1KMEJ7sCt 7dQvgY8zndNZftPlcqk7qNRIO+Xfh+b6lsaoVNUiLrkBZha5KqJGE8NZTYDq9o97vpKFyoC+tde/ lbhgnecg+eOPYf/R/SToeq4xlCRYEevQERizDJsL55Z1eD2iZgSBVOySj17DWCyhi93F2Erk5SC/ 7vYzOhqPZPzqc6Xm7MpLrlvr7GqkrYtX0LWZnUqZkerrDifrSFqqqomkZ5mSE63Ias3Xzd7iRnyl drrLuqzRJtql3r2gi+7ON26Fd34j4selwdoM1u7cYBrulpTtlb7tfKkVjU0IK+tOkI7twi1aIiqy 6G0OKSu9xE7ru3TMVG7r8SmvqHma3fXrlVrwwl7sWjSqx+4TBH/rpJpc4B6gsJltxGRsbX0ZoMXt FKnbdV5bmMub/myiFo4ohhaF4b7xWwWrlDTP0d7QzBKwy0rp30v/qCbvr4OU8j/M6eBtydNt3nRd 50eT76ueLKQ+VlQO8Cft0unZ9Esf8Onqo5or9f0u61UPr1mv9Vx/RAwPLX2+1euO1UBe3dY90G5t 7UgO0Wgfw0bewvduDTmK9jIOt8qN9O1W11q9seBLt3rPsMNtxZpO0Fad6Q/d6Iwt0r/1sulmrS6K 9EZPDvtep8G8xlivn7H+rpaK1LX+8Js/7BEV+g0/XAOv8A6Pkwgv8KW/617L+lQEi4iLMQF4q6SF ts/kqrYdU64C7abO5xCN4zFLmGF6WI59SIQbdXkty3jO19DZ8RsauCU78wlY8hpdbXWIl0RR/Cnf bg72skSvh45O/24ifw2RjyxVKBmVnfCklPlbn/Vg/MWnRPXWZUQGb1yXGaoQP6rzP0SdDwgCgoMS hAuGhYiKi4yHiYeOiB+Pg5ORhgY/mRCcBp6foJ8zFaSjJaWnBCOkojerr5mwoaKnQJ23oaqgFLgV vbgUIxC1ocHDJZ3Etsu1P8HEI5qsnsbD0ry8zMmus9Pdusvc3eG+MsPH1A2uxqy8rwQ3zKs3Oc/z 0dzZz9br+v7AyIAoO7eP3DkDBxQoXMiwocOHC/2dwHbrRCIZFzMmkoBxo8ePHENq/NixI0hCIS+d XMnyo0pDkCihbEmzpkuRNnPO1HmTZyOYLxPFizexIrChRyt6G/93kBM7X0mdNv0l1RxSclB3ab2h jxrBpV6ZzqM4S+o/rlGlXl3r1Cq6oWB5wDUarpfbtXGFUSyKlMLEon4D7yXrFDDfwL74JoTIuPHC VgW97mSZoXJlj5YzUNZc6HJny4MyZ/Z4yHNo0agrx6QhIDXoCAtUt87gYvbrSphBf2ZNwzPq1YJ+ n+YcfHQi0aQlmI5gOjPs2adRWhIuOzbt6rY11wY6WUBcgd+SgYMmrvw7WeThpgLPPuwxdXXf4X3r Sd2PBvZuaRpfAt5AeDmMk1V87UxF4HfuoZKLgqBY5Y19+MlQIBABwvceeuDRIGBX8lBzQoIGZDNg LRwSZks1JSz/5tiKDhUDVUE8+UacbKbhpJyMu92Y23MbPVcjdJBAIttNsFVnJGeqHckIjZpZ1ySO MhFyWWlN2hZdjlNC99GUzWVAZXHRBSmkl2BmyeSX2HWnkjcobmUeecIIiGE5AYm1jZsNjGVLnua9 54ou6FVjkJztFVqXXYUKiidVE24yIJ95KSjhNIrWpx6DS1nIFkFVLfOhiHsCVieI7pilFhAqsqiq AoPJtcSrgdnYkmciXFYjrRmNZitxOh7Hq40//pijml1emeSvUfbK0a67LossTsXqCGVuNEF5q2bR IlKsmUh2q2NQ3UmA1mFnmXjWgIz2BQyoRJkrV6dotXWniZu+/3gqqeq6R6+55Krlbr7vzvWig/XK ha667NorIbulFmZWYoKN6/Bf2FDsMAQWd0LxxpykuuqKb2IcLwXJJgems0CeDCxozfoqJZk8VjIk mGKmvBMT32pp3W7GmawzdLqSKSy1WHopY7C6decczWjCnOaVQFd55JnhThZnwW7+MlDI/s13KS0N fgMWRhVACt6k8xS6taMLHmqov+FR6vZc9FFDKdoPSmh2fXiHTQqH+M0SIN0UblViVPYSVrHIjHcF mKcBUeDxx43ZvcthMc6ILcxabvnbtRtleUmRnGdXLHACMOHIkKnRjFyyMzNrnHBEa3msr0nfmDtu Odt8+5dAUf8ndZU5Pw1ukF57zTC+raTtaMKT1mtO9Iimk+f1fuvZ39r+fZhLm80fQ++on5ybtb0C HxQ9nWTfI46F6x0MoPfygB/LVH6V5ZXiUS2xbuOmCsanOkY5VXHFYieAVaxGspJt8QpXIpGdsiY4 M89dooLD8lm2ppWdm2RJBs2aHZlk5SwRumw4v+qZ50L3wM1BrXa/+1m2dCLAwewrRAE81176chf6 seNfDcPGXeTVt+fd60ScipMP/8e/i3ltiEdEC/rIojCAGYx601MKQIS4jv0RZWSIkcjj1lWBBOYv Yw/b2F8UaBgzsnFyBXwI+iCGlKrNxIEvm4wEQXcaS+CGSn7/3Jl0jFcJQeqMSyNcHa9ikqUb7Wxp Q8sjSlo3ySrxKJKGdKQgPnCsMXFHSUpS5E+kU8hDiC+IfiNc+dQmMFJUSFMhsk95nuIg6vFAHbXU m4ZwOSexlW97bFrFEplCxVQe7E4hGhsOBZe3stGAbNxYn+Wa18ywyIB+yZwXxriovzJOJHFzQ6LD StCvAcajAXCMY0NwyMVvZuN4L6Hat552Qt3g6JKlM0SaZuYj4sVEdaTzpOuMpjneCRSRn/FWuDDI LWUhVGX/tBmQ5Cm6IIHSaZxjnT99hgkedhFhe1plMtyhTFbsrRT0kBt9sHhLabqvbJjqENvaE40i Ou+jINXa/zSXiVMpqhIqC9Ml2/pWIcigtBz8aBD2MDRSL5Zrp5zy3jVf5EYmfsqdepGXQNKpzohw jAcfUiBJNrM7FWpkg7uboOeC1rPlGDRltLKWWdda0KLNtXcSPVbuXneSRiZ0hLqLZGA1Wta68oQs RZlqxRAoxrbIr4xavRcUEVXMX2DTivFZXvqAmsN2Ccac/1OXYk3l2W0GjBMLO21i6IRZDtGNYFDN Xw7X6L9tNjYbtb2mbRPIRtqysbTfBOtEuNpVBbBTqgHzBSNKZkfmNncl24EndzY53VJGNGYRcC5H b0ZdNfkEdc/dbsyiJN3x1gy71u0ReGdSM3Ets4ilnaaISv/lH7Sd9JbJnZ4tQ2ZSaMJPfTdFRjOy 2QpbxC+2CHZtF00xX/iSVj3Qa59+s3g/QqFDFhfWnioarMSwKo58S5ywVBQoTgPU1sRT0QtHdHsC 4nYVjCqFQHjFa6PsStcm41Vv6tarJvS+hMc3BjJ7e9KSIGmXvN5Nr45zXN0/OvfHwBGBjqNUmKDy 9IAE/pPBRkbU1EJAlkAV6ogQ1FJURObAbgvw2/6GzHhRil4nulpdLELmNCflvrns2mbdbCltsPmc WkHuGTkV2XAk0Mq4IHGc8bNYvzhoInzChovV+dnD1NYiRS6EScZKQg34ZNNE3i4Jvyvqknha06NG tZQ/rWr/Vou61bB2Nal90hLannaHIz7nUysF1lu4d8uoVe2tt6hrxhHucJ2N2FO/yJcQPW6Mtw0j oWH8KaomV7PqezAAjQ23D4us2Z/tdbgb7Zff7tYwpvVmpSU2X/9NOo4Swy+6gkxqJhs50zvubpOP nOQpj67T4IJuqPn9733fm7v+VvJyX23wfAO8ZItNJmzZ4kqAyVlvjzKbfXk5KVCBqn1l/lrWEOcp bV4uzM4emUdLjmVaNoVNwD4VpGwKU5Eec1NkFIU7xWHGxf15xIFho566nQ0JLPbEKOo4L95dQI2R tObxsDEpaR3k9rL3vE0O+MAloe/prtrGH/Axvu2o9YK//xXrQoZyvtNOcCOrPSVWf0m5qz3Lm3/Z cpWlsFU4fg9QO/iKGI/UTbVtVft9JdjwAHeF3+ZECP/9Lnh7PDCv7NMjejgd9QEfgDCWW9SmVs7n tvxxD+hotfgvsVxBKlGYTrmg+y8rsp1xqgWw6lTvta1Ly41rSshXs/IxsCecKF95j7S4Imf3qPkr C2GYVodqzvghSdpdqT51j6gx2t/+Cx2fzWU4KzhTMd9Gg/lsQ3KjcdwlLr+zx6gv7O+61/D/eVOH nZQ2lmtx3C7/GGF1g86HFlanh3TlxnnntgTbxzGIFRis9zHvgnrNI3uzB2S1EjtCU4FMI0qsgUEQ 1Sv8xP8k9WSBu2FIFKhpGlU0UPN7IdhQkiRPY6JQcoU7uJNP1bdwCpc6hYBreJdTkRFFItdN+LVU gJc9gWd3ledmN3RhkMNOg5IWPkgYE2c4NBdTyoNzonc2XjQi7gBadpJVazRf8TUYC4N+OriAq1IY HxJp9wCBzyV10aGC0oJRYjJDkhSCGfRQ2NEywhcmdOiBLoNWy/dCHPSGc1gct9NIHnh8LuRk+5Ys 10UJ+TdFJEd4yeNSwsY3lRhNdYY4oNVENpcPBkYXyYNEqueJXuZt4TdhmTiFLMeDBGIg6YYVn5hl +TMwoWcuYdhE5UeGBsRbAuhrs5dqoHZqsdYyE0iCiZj/Sc7XVy2EasVnWIJogiqTjBSUiNJYh8uo VnjYOcqXjTgSQtQYa1qHY5rWc/qHgB4HbeZHf/LifYN2bKqFazpkfhEXQD/HWPA4TmbYgEx0L+wX fvp4j6TnL+WohPwijwIpipyXQKSHgL2lbD13erVoRjygiyzSf7z1Z+9AawKnQceIR6RDCSUYJSMY fIAIWHiISL43PNEoOyP5V7lnOyl0jNiYfKLTjS6UjYwYjjSYCNJmWUT3Z9DGFniGcsCGketgS/u1 So0yIf3SbVeWVenHiu0yWaqUFEd1d1IkTXX3cx0XleEUZ4BWcsimL950gAKJfxVzi+gGjxJCkSBD MdXk/xI6OXabFJLcIoKJ1DkVRZIjGQkUyEjUaIeLlHwrmYgtOY1+qVCi1JdlwjIZZYHe2BuAZYNX N5dA1pPi521ZKInbAEutJCBVeUVUWDeGoyjYlkSEJoZz4w9c2Yl4USBP6FNGmWXLxJr6oVXmhFRo qWDGNkDupHjm6FhrWYvCoA5u6Ri81SpDgWnAKGUlUXudRlf2VFAheYLEw4zXiDLQkp1R84ElFEHP gistoxsgxJ18hDTTSC1BQ3vDQp7Np5HgGGvJiZlzd31AV2nKpo5RtJvr+I5BmXIOyZ/DmY8JuJbk mH3kMqBnGTFY848+uW0Cum68wH/rYqDcF4BmaI/16f9bv3l9DTkMLVZcjPGK76J0DAdq0BUUKihX wPOH2piYlZRBvIE0wBMtpxONfzgt0GeM+qSY6JmHMao7A8VCzyejameZ4WJb3TeAqgmQMteV6UKE pAh7lZWDgYZaTho53OZUjXYoiqdyOohZbOZlfBZMY6YWUBmPYQUZCypbSASc5mZiHgqXkJUxaJR5 x1k5mwVN9AB38LlQk8mSKJSX2vmiL5SB7/kjTtJC0jdCjdpAj5pQhUkaKkSTw6OBN5qSRSqZZOdw v5ikCEQ3CWiE+eeFlgiKFBeKRaltsDmaXlmF+VCg7uKkaKqfCbOVSroUDROmTLhDsJCfu+WlSjp3 RGf/nxDpmyfyVfmQpyNqQ/8InbGGop86rdH6p9Yan1Ujrc25rdxKrd76rdharbE2rte6aq6Hnw0J gPaJrk6nfu3UeKPqKmLIoLOloQEabgvJrvZ3r/zqrm2qoPxYrxEanOsXgLzIWAbLoWqkrgebrhs6 n8LFrBAhqvKWDjPGhuDaqTtJl+XKG0jasdeqhpW5hh4rsrzBEh87GfgoXBG6oABapvF6m6HpWP7I hLQ4W/+6bfuzrlSKi03xn6woTbyZLvvos26aenU6p686MTU0nwh0rB4yoHxxTUsgsQ9Bj9RDMikb nSGLZBHIbw1AfdnKcGRrslzbtWhbtougrezJCO/3/4r0WpDDem2sKouSRbG8RnlXcY/392172yr9 CmPiNLSSOHhfynh/i7NMq4UpB5HDGlzt2rfoF3TklqEWSRG6ZbUOYZ8s6xeEwLaypq2iC7LdSkKj u2KmC4HQ+pzk+ot+17qwC7o5wbrjerrA2B3BubDJeawI24UJ6rvjhp/8WYvJJrzAu6+Ua6HH60TI a6fGe6/AdX7A+rzLq7vK27C2thcfSr0He64Ky7ARK6IT+0V1Nwx0ibFpO7tqG7qoFi6ru3Xpa7Yh O5fxK44zYbSKC0Bperj+mrjeZ20/JH/4G7z9W73tRriDy5mciDC7qpYKjH/JqqSX9qa9RWLaV4+/ Gf+QOGvBB7mhEqO569SDn4iyEbW+9WvCsJux4Uq/J9zCCcexpIu6crkTHbzBY7nAj/vAybZKdBds OfwPo0qrBBxfrcmrb6vATgV5O2wWUrtDzuumEAsE/HugGtyyTHzFDgvCDBGUyqbCrivDpWu6ImC7 YPy6Ydy6unTGXqzGZHy7X8zGcPzGqtavTGrA++qwxsq9F6N/4pahydtG2zungGy97MbB16vHA0uh 5Zi7efyQD3u84HtpguxhC5uQTutG1vuwWhwRreSFQzbDKKu+LrzGbizKMXzKpjzK7YvKRofFkQvB QISDETm3xdum0zbAYERawzu5F9w46GjLCVzDrnz/y0GMy0d3rwLouNx7yC87ocj7pgOIdFUrvlc7 f7u6yj0Gv6psNdicyqU8ttvszd0czuQ8avl7zsA5wMJbywFLrw7KzgJLvbR8tF+4yMZcvE0ZrNMr q348y/vXjkTxKhGMxb0MxHecrMBbGJusEM/moaQszqX8nG080XFcxrErrmIM0RJd0e/70Bm90Sk8 apP8yIN8zAltx/ZqjrrrzwfavCO9uyr9y+SY0jMtz/ZcgDYd0zCNvd17rqZVFBVcVd+70iTN07S1 0KxiKKOitaJ2cIt4slBdslHNwuFlb1GNwl6bk0n2dk89yinL1Vcd1lI91p/MG0odiSQiU7BYmqvp 4Wcl5jY+J6xUgZVLmNaJ4lp2LRAntTZvHcyJEovQLMXDBGfkAA9rLddSjNiHfYVfudjWJJbsEart Qc2UXdmWfdmYndmavdmc3dme/dmgHdqiPdqkXdqmfdqondqqvdqs3dqu/dqwHduyPdu0Xdu2fdu4 ndu6vdu83du+/dvAHdzCPdzEXdzGfdzIndzKvdzM3dzO/dzQHd3SPd3UXd3Wfd3Ynd3avd3c3d3e /d3gHd7iPd7kXd7mfd7ond7qvd7s3d7u/d7wHd/yPd/0Xd/2fd/4nd/6vd/83d/+/d8AXt2BAAA7 ------=_NextPart_000_0005_01C7852D.C2B4CD80-- From owner-ietf-pkix@mail.imc.org Sun Apr 22 16:31:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfii4-0006aY-2N for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 16:31:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfii3-000666-F3 for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 16:31:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJhAr7009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 12:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MJhAl2009699; Sun, 22 Apr 2007 12:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJgmJc009616 for ; Sun, 22 Apr 2007 12:43:09 -0700 (MST) (envelope-from shitchings@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 15:42:46 -0400 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0024_01C784DB.BA59CCA0" Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQAGlMiuAABnca8A== References: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> From: "Seth Hitchings" To: "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C784DB.BA59CCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh and Denis, My reading of the current SCVP draft (31) is that it allows unprotected responses to DPV queries when the transport mechanism is protected. Section 3.2.5.3, protectResponse, reads: SCVP clients that support delegated path validation (DPV) as defined in [RQMTS] require an authenticated response. Unless a protected transport mechanism (such a TLS) is used, such clients MUST always set this value to TRUE or omit the responseFlags item entirely, which requires the server to return a protected response. And section 4, Validation Response, begins: There are a number of forms of an SCVP response: 1. A success response to a request that has protectResponse set to FALSE. These responses SHOULD NOT be protected by the server. 2. The server MUST protect all other success responses. If the server is unable to return a protected success response due to local policy, then it MUST return an error response. It seems to me that a client can make a very simple DPV request over TLS by setting protectResponse to false, asserting only the id-stc-build-status-checked-pkc-path check, and omitting the wantBack item. Seth -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Sunday, April 22, 2007 9:36 AM To: pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I agree with Dave Engberg. Prior to PKIX taking this on as a Standards Track or Experimental RFC or other work item, an attempt must be made to profile SCVP for lightweight operations that meet most community needs. I have not done an analysis as to how this would turn out, but got curious and looked at the signature aspects of validation responses. My reading of the draft SCVP I-D is that it requires signed data or authenticated data for valid responses. In addition, the Server must be capable of generating signed data. It seems that Denis wants unprotected valid responses since the channel protects the responses. I think either the SCVP or the lightweight version can be revised to accommodate this. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Friday, April 20, 2007 10:26 AM To: Denis Pinkas; pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis ------=_NextPart_000_0024_01C784DB.BA59CCA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3DCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA5IwggL7oAMCAQICAgCiMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNzE0NDgzNloXDTA3 MDkyNjE0NDgzNlowajELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEXMBUG A1UEAxMOU2V0aCBIaXRjaGluZ3MxKDAmBgkqhkiG9w0BCQEWGXNoaXRjaGluZ3NAY29yZXN0cmVl dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDULuw99zAAo0bVVJO8Muclrezh TKZpRgvLmNtEMSgZQHezFesdIs3MM1V4dT7rmf8JIm9ugAZrYrpOK79402QQvFhY4gVaBkPQflR3 u/yKvVO8BWcKeaCZAu9SiHW9MqMMSkh+qX8b3Var9T/6clbxMeCx37wByra6uvAPKfZUmnTERMqF IybXd5rkejV6Sn3Madu4iYh3FWd8sQEWV2Pqpz9IBjMRzXOKfFEPbopvGOCiXtnyzTiz00yh8JDe UZWf9K0jhBG7u8KeebWyxfANPbgnn89lCFZjkAz0aEhJpXxwsWqnjH1S6IfvnWxu59J5pecAAizr +iKDhaiwaBPZAgMBAAGjgdowgdcwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0 dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwJAYDVR0RBB0wG4EZc2hp dGNoaW5nc0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBA BggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJl ZXQuY29tLzANBgkqhkiG9w0BAQUFAAOBgQB0vJkV8SBdmz9K5S+Tw+0o1G08vfYQRDYcOzyoriV7 gZi8/vmnaUL7GMYRaEv3ei7LyLDXIm2FJSH5bZACEIR5Jhl5QWByV6F8EdlOYRUKn/PQgNhqWH9q B6I+Sn/Tqfgtm3ssboe6yJFBIQnk9S3WmIxHhGCPptQ0fvM8jy9BwzGCAx0wggMZAgEBMFgwUjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVl dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCiMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyMjE5NDI0NlowIwYJKoZIhvcNAQkEMRYE FDP98I/3yFHoeMN4zO45tstZPRDYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMGcGCSsGAQQBgjcQBDFaMFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0Nv cmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkC AgCiMGkGCyqGSIb3DQEJEAILMVqgWDBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVl dCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICAKIwDQYJ KoZIhvcNAQEBBQAEggEAJDcXEbSNbQAK+X7HzKpR2OqHe/VJNLqFz5fkyPQ/a6IIzjEmUdmre9yz RzEfphqXbA8inQJc0dwxlZWx3mRXmBe2E2WoH10rwxw/WmFG8KnxG9XK57uk4UwYQ3qQZQuaTj7K /RCePY/qAyFpEjwXQdMN5hG76KgwG8pR1fsm4srTxt9Gayk2oS2hbgi7MRUVq+rnGhlXc3Dj58oX QAWV40N6UmnLtJPuAqjSLL1vNb+w3hXUFkg5+KCuaVbe1rp9RAQ1ij+ceQ/br/hfdXpAhFd25Chl wraRNmQERts7q/oeF53i+DP0BSKnzvBP1ZeEwUiL97Zh3DL1MSMNYoJEQAAAAAAAAA== ------=_NextPart_000_0024_01C784DB.BA59CCA0-- From owner-ietf-pkix@mail.imc.org Sun Apr 22 18:10:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfkGY-0002u3-Fl for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 18:10:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HfkGW-0000uR-NT for pkix-archive@lists.ietf.org; Sun, 22 Apr 2007 18:10:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MLOkHm027767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 14:24:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MLOkeJ027766; Sun, 22 Apr 2007 14:24:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MLONM2027727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Apr 2007 14:24:44 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [129.6.222.17] ([129.6.222.17]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3MLNr74018026; Sun, 22 Apr 2007 17:23:53 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> Cc: pkix , Sam Hartman , Russ Housley , Stephen Kent , Stefan Santesson Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 17:23:52 -0400 To: Denis Pinkas X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Denis, I finally found some time this weekend to review the LCVP specification. I thought it was important to avoid snap judgements. After reviewing the specification, I do not see a justification for pursuing this document. If we consider this specification from a DPV client viewpoint, there are very few differences between an LCVP client and the minimal SCVP client. You identify the following differences (my numbering for clarity): (1) the protocol only supports DPV, i.e. it includes no provision to support Delegated Path Discovery (DPD); (2) requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; (3) validation is only for one certificate at a time; (4) there is no specific parameter in the request to add any parameter to a validation policy known by the server. However, this overstates the differences. (1) SCVP implementations are not required to implement both DPD and DPV. (2) SCVP clients and servers MUST support protected (e.g., signed) responses, but the client may choose to use TLS as a protected transport to protect the responses. (3) Clients are not only permitted to submit requests one certificate at a time, conforming client implementations are not required to support multi-certificate requests. (4) As in 3, modifying the validation policy need not be supported by conforming clients. In short, LCVP does not provide functionality that is unavailable in SCVP. While LCVP's ASN.1 appears less complicated, the data structures generated by minimally conforming SCVP DPV-only client implementations appear to have similar levels of complexity. I cannot see any reason to pursue a new DPV protocol that ignores the requirements established in 3379 within the IETF. I can see the rationale for a lightweight client profile for SCVP, as suggested by others on this list, to demonstrate how simple an SCVP client can actually be. Thanks, Tim Polk On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > > > I needed a simple protocol to delegate the validation of a > certificate to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does > not mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows > simplification > of client implementations and only uses of a set of validation > policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet > been implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and > comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > > From owner-ietf-pkix@mail.imc.org Mon Apr 23 11:24:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0Ov-0003Vv-81 for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 11:24:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0Ot-00017R-II for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 11:24:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NELTQU051774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 07:21:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NELTgN051773; Mon, 23 Apr 2007 07:21:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NEL62r051726 for ; Mon, 23 Apr 2007 07:21:28 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l3NEKk1i025250; Mon, 23 Apr 2007 10:20:46 -0400 (EDT) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 23 Apr 2007 10:20:46 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 10:20:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Mon, 23 Apr 2007 10:20:45 -0400 Message-ID: In-Reply-To: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceFK11UoDZ3DDp/SY+AIcU4LSAFUwAgru8Q References: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> From: "Kemp, David P." To: "Tim Polk" , "Denis Pinkas" Cc: "pkix" , "Sam Hartman" , "Russ Housley" , "Stephen Kent" , "Stefan Santesson" X-OriginalArrivalTime: 23 Apr 2007 14:20:46.0422 (UTC) FILETIME=[959E9760:01C785B2] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15128001 X-TM-AS-Result: : Yes--20.682000-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xNTEy?= =?us-ascii?B?NjAtNzA3NDEwLTcxMDM3NS03MDA4NjktNzAwODA3LTEyMTE1NS03?= =?us-ascii?B?MDIzNTgtNzAwNDc2LTcwMjI2MC03MDE1NzYtMTIxNzAxLTcwNzE2?= =?us-ascii?B?My03MDI2NDMtNzA0NDQ1LTcwNjI0Ny03MDcxMTQtNzA2ODIzLTcw?= =?us-ascii?B?MjcyNi03MDIxMzEtMTM5NzA0LTcwNzU0NS03MDAyNzItMTM5MDA2?= =?us-ascii?B?LTcwNDI4Ny03MDM4MjktNzEwNTU2LTcwMTAwNy03MDA3OTItMTIx?= =?us-ascii?B?NjQ4LTcwNDQzMC0xMTM2NjAtNzAzMjc3LTcwNTQ0MS03MDk1ODQt?= =?us-ascii?B?NzA0MzExLTcwMTQ1NS03MTE0MDItNzAxOTM3LTcwNTk2OS03MDM1?= =?us-ascii?B?NDMtNzA0NDIxLTcwMjc2Mi0xMjExMjQtNzAyNDg1LTcwMzg1MS0x?= =?us-ascii?B?ODYxMDItNzAwODMzLTcwNTkwNi03MDI2MjYtNzA3OTk3LTcwNDc4?= =?us-ascii?B?Mi03MDM5OTgtNzAwMTA0LTcwMTEwNy03MDQ0MjUtNzAyMzY3LTcw?= =?us-ascii?B?MTg1My03MDgxNzktNzA0OTgwLTcwMDEwNy03MDAwNzUtMTM5MDEw?= =?us-ascii?B?LTcwMjEyNi03MDU0MjQtNzA2NTYxLTcwMDYxNy03MTA4MDctNzA2?= =?us-ascii?B?NTY0LTcwOTQxNS03MDIwOTctNzAzNTg5LTcwMjkyMC03MDAyOTMt?= =?us-ascii?B?NzA2MTU3LTcwMTYxOC03MDIzNzYtNzA1NTI2LTcwMTQ0Ni03MDUw?= =?us-ascii?B?OTAtMTg2MDM1LTcwODE5Ni03MDQzNDItMTQ4MDUwLTIwMDQz?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3NELS2r051767 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Tim, Santosh indicates that SCVP could be "revised" (not profiled) to meet the needs of (2) transport-only protection. Does the working group support modifying SCVP so that clients SHOULD (vice MUST) support signed responses? On the surface that sounds reasonable, but a truly lightweight validation protocol would use message protection (signed or authenticated) and a UDP request/response like DNS, rather than a TCP handshake plus a TLS handshake. Just because everyone has a TLS library does not mean that TLS treads lightly on the network. See http://www3.ietf.org/proceedings/07mar/slides/isms-1.pdf Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tim Polk Sent: Sunday, April 22, 2007 5:24 PM To: Denis Pinkas Cc: pkix; Sam Hartman; Russ Housley; Stephen Kent; Stefan Santesson Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Denis, I finally found some time this weekend to review the LCVP specification. I thought it was important to avoid snap judgements. After reviewing the specification, I do not see a justification for pursuing this document. If we consider this specification from a DPV client viewpoint, there are very few differences between an LCVP client and the minimal SCVP client. You identify the following differences (my numbering for clarity): (1) the protocol only supports DPV, i.e. it includes no provision to support Delegated Path Discovery (DPD); (2) requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; (3) validation is only for one certificate at a time; (4) there is no specific parameter in the request to add any parameter to a validation policy known by the server. However, this overstates the differences. (1) SCVP implementations are not required to implement both DPD and DPV. (2) SCVP clients and servers MUST support protected (e.g., signed) responses, but the client may choose to use TLS as a protected transport to protect the responses. (3) Clients are not only permitted to submit requests one certificate at a time, conforming client implementations are not required to support multi-certificate requests. (4) As in 3, modifying the validation policy need not be supported by conforming clients. In short, LCVP does not provide functionality that is unavailable in SCVP. While LCVP's ASN.1 appears less complicated, the data structures generated by minimally conforming SCVP DPV-only client implementations appear to have similar levels of complexity. I cannot see any reason to pursue a new DPV protocol that ignores the requirements established in 3379 within the IETF. I can see the rationale for a lightweight client profile for SCVP, as suggested by others on this list, to demonstrate how simple an SCVP client can actually be. Thanks, Tim Polk On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > > > I needed a simple protocol to delegate the validation of a > certificate to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does > not mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows > simplification > of client implementations and only uses of a set of validation > policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet > been implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and > comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > > From owner-ietf-pkix@mail.imc.org Mon Apr 23 12:36:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1Wf-0004ec-8I for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 12:36:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1WV-000886-DU for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 12:36:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NFjLGj058912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NFjLEY058911; Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NFj0d9058869 for ; Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 47BCC41097 for ; Mon, 23 Apr 2007 17:44:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 1325544293 for ; Mon, 23 Apr 2007 17:44:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL6CcpqFNqlj for ; Mon, 23 Apr 2007 17:44:47 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 974F944160 for ; Mon, 23 Apr 2007 17:44:46 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Mon, 23 Apr 2007 17:44:46 +0200 From: "Julien Stern" Date: Mon, 23 Apr 2007 17:44:46 +0200 To: ietf-pkix@imc.org Subject: SCVP Question regarding Trust Anchors Message-ID: <20070423154446.GF1691@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Folks, sorry to ask this fairly late in the process, but it did not catch my eye before: The ValidationPolicy structure defines - userPolicySet - inhibitPolicyMapping - requireExplicitPolicy - inhibitAnyPolicy globally and not on a per trust-anchor basis. Wouldn't it be more logical and less limiting to define it for each trust anchor (like in RFC3125)... ? Regards, -- Julien From owner-ietf-pkix@mail.imc.org Mon Apr 23 16:11:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4sZ-0002Pf-Ft for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 16:11:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4sV-00036P-Uo for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 16:11:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJGA7R090016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJGA6a090015; Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJFkUf089980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 12:16:09 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3NJFcKs026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2007 15:15:39 -0400 Message-ID: <462D05DA.5060002@cs.dartmouth.edu> Date: Mon, 23 Apr 2007 15:15:38 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: pkix Subject: PKI Resource Discovery - Proposal for a new Working Item References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703040300000409040303" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a cryptographically signed message in MIME format. --------------ms030703040300000409040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello PKI-ers, I was looking at all the different possibilities we have now for `discovering' PKI related resources, where by resources I include repositories and services provided by a CA. For example an LDAP server, a CRL repository or an OCSP service. Actually the `standard' way to do so is to embed pointers into certificates via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, as it is quite static (e.g., CA certs have usually quite long life period). Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but none of them seems to be supported widely across apps and systems. My take is because possible solutions are many and they can be difficult to implement (and some of them do not really provide an efficient solution, for example the DNS approach requires that the application knows which is the right domain to query for a service---which might not be trivial if the DC format is not used). I am working on a proposal for developing a protocol to provide a specific solution to the problem, and I really would like the WG to discuss the problem and the proposed solution. I have a brief description of the work done so far here: http://www.openca.org/projects/libprqp Main goals of this work are: * to make it easy for developers to discover PKI resources * to provide a method to dynamically update PKI resources information * to split pki-services management from certificates contents. For example it would help in painless rollover between services, e.g. switching from CRLs to OCSP without the need to re-issuing all the certificates (an example could be taken from the DoD PKI) We might say that this protocol would provide a way to map X509 certificates to network resources by providing pointers (URLs) to applications. I hope this idea could have some consent here and some help also in writing a first draft. We might also setup a slot to discuss this idea at the next IETF Meeting... Thanks for your attention in reading this email, I hope to receive many useful comments and suggestions and, hopefully, also some help in this task. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms030703040300000409040303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIzMTkxNTM4WjAjBgkqhkiG9w0B CQQxFgQUhnkTyRknjTYw6D8fjJZSAAsN8x4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB2B7Qc0TIzw/3ElG/NFU2U HGsqz0JgbFqQGQ+OGOLU0F7thGYFSWMUxBIY7lezT56FUOwJM1litafdlrnwrrHJWwz1Xs74 rryZcy/O7Ih6kyGRYADznuQbCF6Mys3iBc2cjDKYF+U6QBB6E6InOuKR52NV/lTvMXVAh5HD /9R3AAAAAAAAAA== --------------ms030703040300000409040303-- From owner-ietf-pkix@mail.imc.org Mon Apr 23 16:33:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5Dm-0004VI-2x for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 16:33:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5Dk-0003Ei-Mo for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 16:33:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJrA2q095237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJrAGe095236; Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3NJr9VR095229 for ; Mon, 23 Apr 2007 12:53:09 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704231953.l3NJr9VR095229@balder-227.proper.com> Received: (qmail 21940 invoked by uid 0); 23 Apr 2007 19:53:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Apr 2007 19:53:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 15:44:28 -0400 To: "Julien Stern" , ietf-pkix@imc.org From: Russ Housley Subject: Re: SCVP Question regarding Trust Anchors In-Reply-To: <20070423154446.GF1691@mars.cry.pto> References: <20070423154446.GF1691@mars.cry.pto> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien From hanako789@sina.com Mon Apr 23 16:37:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5Hb-000292-6C for pkix-archive@megatron.ietf.org; Mon, 23 Apr 2007 16:37:11 -0400 Received: from [122.43.127.43] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5HZ-0004Aq-OC for pkix-archive@megatron.ietf.org; Mon, 23 Apr 2007 16:37:11 -0400 Received: by mail (Postfix, from userid 48) id A785B4F55B8; Mon, 23 Apr 2007 17:40:09 +0900 (KST) To: pkix-archive@megatron.ietf.org Subject: =?ISO-2022-JP?B?km6Ms4LMg0mDb4NUg5OC8JX4gquCvYKigsWCt4KpgUiDjIN4g4uCzZLhgqKCxYK3gqqKbY7AgsmV+IKvgtyCt4LmISE==?= From: Resent-Sender: hanako789@sina.com Message-ID: <20070423174008.64256@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Resent-Message-Id: <20070423121442.A785B4F55B8@mail> Resent-Date: Mon, 23 Apr 2007 17:40:09 +0900 (KST) Resent-From: hanako789@sina.com (Apache) X-Spam-Score: 3.4 (+++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 **************************************************** “–ƒTƒCƒg‚Í40‘ã`50‘ã‚Ì“÷‘ÌŠÖŒW‚ð‹‚ß‚Ä‚¢‚élÈEn— ‚ªW‚Ü‚é“ú–{Å‘å‚Ì•s—σRƒ~ƒ…ƒjƒeƒB[ƒTƒCƒg‚Å‚·B **************************************************** s‚²—˜—p‚ÉŠÖ‚µ‚Ä‚Ì‚²’ˆÓt------------------------------- ‡T@‚²—˜—p‚Í’j—‹¤‚É•s—Ï‚ðŠó–]‚³‚ê‚é•û‚Ì‚Ý‚Æ‚³‚¹‚Ä’¸‚«‚Ü‚·B ‡U@’j—‹¤‚É‚¨‘ŠŽè‚É—v‹‚·‚鎖‚Í•s—ÏË“÷‘ÌŠÖŒW‚Ì‚Ý‚Å‚·B ‡V@ƒzƒeƒ‹‘ã‚ÉŠÖ‚µ‚Ä‚Í‚¨ŒÝ‚¢‚ÅŒˆ‚߂ĉº‚³‚¢B s‚²—˜—p•û–@‚ɂ‚¢‚Ät----------------------------------- ‡T@‚²Šó–]‚Ì’nˆæEƒ[ƒ‹ƒAƒhƒŒƒXEƒpƒXƒ[ƒh‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡U@ŽŸ‚ÉŠÈ’P‚ÈŽ©ŒÈPR‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡V@•s—ÏË“÷‘ÌŠÖŒW‚ðŠó–]‚·‚邨‘ŠŽè‚ðŒŸõ‚µ‚Ä’¸‚«‚Ü‚·B ‡W@‚²—˜—p‚³‚ê‚Ä‚¢‚élÈ‚³‚ñ‚Í‘S‚ÄŽ©ŒÈPR“à‚ÉŒg‘єԆ–”‚Í @@’¼ƒAƒhƒŒƒX‚ª•\Ž¦‚³‚ê‚Ä‚¨‚è‚Ü‚·‚Ì‚Å‚»‚ÌŽž“_‚Å’¼Ú‚²˜A—‚ð @@‚µ‚Ä’¸‚¢‚Ä‚àŒ‹\‚Å‚·‚µAƒTƒCƒg“à‚©‚çƒ[ƒ‹‚ɂĘA—‚ðŽæ‚é @@Ž–‚à‰Â”\‚Å‚·‚Ì‚Å‚¨D‚«‚ȘA—•û–@‚ÅŒð‚µ‚ĉº‚³‚¢B y’ˆÓzŽ©ŒÈPR“à‚ɘA—æ‚Ì•\Ž¦‚ª–³‚¢lÈ‚³‚ñ‚Í @@@@Œð‚ª¬—§‚µ“÷‘ÌŠÖŒW’†‚Å‚·‚̂ŘA—æ‚Ì•\Ž¦‚ª @@@@•œŠˆŒãAÄ“xŒðÂ‚ð‚¨Šè‚¢’v‚µ‚Ü‚·B ************************************************************** œ–{“úAŠ®‘S–³—¿‚Ån‚ꂽlÈ‚Æ“÷‘ÌŠÖŒW‚ðŠó–]‚³‚ê‚é’j«‚Í @http://cjbjj.com:112/ddd/hito-5/ œ–{“úAŠ®‘S–³—¿‚ʼnÎÆ‚Á‚½‘Ì‚ð–ž‚½‚µ‚Ä—~‚µ‚¢—«‚Í @http://cjbjj.com:112/ddd/hito-5/ ************************************************************** š‘Ò‡‚킹‚ÌêŠ‚ðƒŠƒAƒ‹ƒ^ƒCƒ€‚Å‚â‚èŽæ‚èŠm”F‚³‚ꂽ‚¢•û‚Í @ƒ‚ƒoƒCƒ‹iŒg‘Ñ“d˜bj‚Å‚ÌÝ’è‚ðƒIƒXƒXƒ’v‚µ‚Ü‚·B ************************************************************** From owner-ietf-pkix@mail.imc.org Mon Apr 23 18:43:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg7GB-0003LF-ES for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 18:43:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg7GA-00034X-0V for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 18:43:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqYCK009746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NLqYuk009745; Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqC3E009615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 14:52:33 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3NLplol010753; Mon, 23 Apr 2007 17:51:47 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l3NLp2fg027606; Mon, 23 Apr 2007 17:51:03 -0400 (EDT) Message-ID: <462D2A85.1070307@nist.gov> Date: Mon, 23 Apr 2007 17:52:05 -0400 From: "David A. Cooper" User-Agent: Thunderbird 1.5.0.10 (X11/20070305) MIME-Version: 1.0 To: Russ Housley CC: Julien Stern , pkix Subject: Re: SCVP Question regarding Trust Anchors References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Russ, Julien, This was discussed on the list in early 2005 and the consensus was against making this change. It was simply a trade off between flexibility and complexity. In almost every case, the same set of inputs (e.g., userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc.) are appropriate for each trust anchor. Allowing different values to be specified for each trust anchor would complicate things for all clients (and servers) for the benefit of the few that would need this level of granularity in specifying validation requirements and we already have enough complaints that SCVP is too complicated. The few clients that need this degree of flexibility can simply send multiple requests, with each request specifying a different set of trust anchors along with the appropriate input values for that set of trust anchors. (Note that in theory a validation policy could be defined in which values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc. were different for each trust anchor. The easiest way to do this would be to only allow the client to specify the validation policy by OID and to only include the validation policy by reference in the response. That way the request would simply say "validate certificate X under policy Y" and the response would say "the result of validating certificate X under policy Y was ...". Since neither the request nor the response would include any explicit information about the meaning of policy Y, there would be no limitations on the complexity of the definition of policy Y. Not that I would recommend defining overly complicated validation policies, but I think it can be done with certain limitations on what can be included in the request and in the response.) Dave Russ Housley wrote: > > You are right, in my personal opinion, that would be a better > structure. Can you propose text? > > Russ > > > At 11:44 AM 4/23/2007, Julien Stern wrote: > >> Folks, >> >> sorry to ask this fairly late in the process, but it did not catch >> my eye before: >> >> The ValidationPolicy structure defines >> - userPolicySet >> - inhibitPolicyMapping >> - requireExplicitPolicy >> - inhibitAnyPolicy >> >> globally and not on a per trust-anchor basis. >> >> Wouldn't it be more logical and less limiting to define it for each >> trust anchor (like in RFC3125)... ? >> >> Regards, >> >> -- >> Julien From owner-ietf-pkix@mail.imc.org Mon Apr 23 20:07:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8ZA-0006fS-0V for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:07:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg8Z5-00078Y-7m for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:07:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMXBa024560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:22:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNMXK1024559; Mon, 23 Apr 2007 16:22:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx2.ttu.edu (phorphyrion.net.ttu.edu [129.118.1.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMCW9024481 for ; Mon, 23 Apr 2007 16:22:32 -0700 (MST) (envelope-from housley@vigilsec.com) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx2.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:22:05 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:21:43 -0500 Received: from mxin1.ttu.edu ([129.118.1.173]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 15:59:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:53:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJrA2q095237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJrAGe095236; Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3NJr9VR095229 for ; Mon, 23 Apr 2007 12:53:09 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704231953.l3NJr9VR095229@balder-227.proper.com> Received: (qmail 21940 invoked by uid 0); 23 Apr 2007 19:53:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Apr 2007 19:53:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 15:44:28 -0400 To: "Julien Stern" , ietf-pkix@imc.org From: Russ Housley Subject: Re: SCVP Question regarding Trust Anchors In-Reply-To: <20070423154446.GF1691@mars.cry.pto> References: <20070423154446.GF1691@mars.cry.pto> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 20:53:33.0210 (UTC) FILETIME=[74850FA0:01C785E9] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien From owner-ietf-pkix@mail.imc.org Mon Apr 23 20:07:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8ZJ-0006gX-BM for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:07:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg8ZI-0007Cn-Nr for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:07:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNNfHu024802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNNfp1024801; Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.ttu.edu (echion.net.ttu.edu [129.118.1.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNNflD024795 for ; Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:23:40 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:23:19 -0500 Received: from mxin2.ttu.edu ([129.118.1.191]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 18:10:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin2.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:10:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqYCK009746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NLqYuk009745; Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqC3E009615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 14:52:33 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3NLplol010753; Mon, 23 Apr 2007 17:51:47 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l3NLp2fg027606; Mon, 23 Apr 2007 17:51:03 -0400 (EDT) Message-ID: <462D2A85.1070307@nist.gov> Date: Mon, 23 Apr 2007 17:52:05 -0400 From: "David A. Cooper" User-Agent: Thunderbird 1.5.0.10 (X11/20070305) MIME-Version: 1.0 To: Russ Housley CC: Julien Stern , pkix Subject: Re: SCVP Question regarding Trust Anchors References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 23:10:11.0463 (UTC) FILETIME=[8B0F3170:01C785FC] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Russ, Julien, This was discussed on the list in early 2005 and the consensus was against making this change. It was simply a trade off between flexibility and complexity. In almost every case, the same set of inputs (e.g., userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc.) are appropriate for each trust anchor. Allowing different values to be specified for each trust anchor would complicate things for all clients (and servers) for the benefit of the few that would need this level of granularity in specifying validation requirements and we already have enough complaints that SCVP is too complicated. The few clients that need this degree of flexibility can simply send multiple requests, with each request specifying a different set of trust anchors along with the appropriate input values for that set of trust anchors. (Note that in theory a validation policy could be defined in which values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc. were different for each trust anchor. The easiest way to do this would be to only allow the client to specify the validation policy by OID and to only include the validation policy by reference in the response. That way the request would simply say "validate certificate X under policy Y" and the response would say "the result of validating certificate X under policy Y was ...". Since neither the request nor the response would include any explicit information about the meaning of policy Y, there would be no limitations on the complexity of the definition of policy Y. Not that I would recommend defining overly complicated validation policies, but I think it can be done with certain limitations on what can be included in the request and in the response.) Dave Russ Housley wrote: > > You are right, in my personal opinion, that would be a better > structure. Can you propose text? > > Russ > > > At 11:44 AM 4/23/2007, Julien Stern wrote: > >> Folks, >> >> sorry to ask this fairly late in the process, but it did not catch >> my eye before: >> >> The ValidationPolicy structure defines >> - userPolicySet >> - inhibitPolicyMapping >> - requireExplicitPolicy >> - inhibitAnyPolicy >> >> globally and not on a per trust-anchor basis. >> >> Wouldn't it be more logical and less limiting to define it for each >> trust anchor (like in RFC3125)... ? >> >> Regards, >> >> -- >> Julien From owner-ietf-pkix@mail.imc.org Mon Apr 23 20:08:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8Zs-0006zQ-Kk for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:08:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg8Zr-0008HZ-0s for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:08:16 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMems024604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:22:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNMexw024603; Mon, 23 Apr 2007 16:22:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.ttu.edu (echion.net.ttu.edu [129.118.1.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMJnk024518 for ; Mon, 23 Apr 2007 16:22:39 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:22:12 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:21:47 -0500 Received: from mxin4.ttu.edu ([129.118.1.167]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 15:59:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin4.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:34:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJGA7R090016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJGA6a090015; Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJFkUf089980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 12:16:09 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3NJFcKs026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2007 15:15:39 -0400 Message-ID: <462D05DA.5060002@cs.dartmouth.edu> Date: Mon, 23 Apr 2007 15:15:38 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: pkix Subject: PKI Resource Discovery - Proposal for a new Working Item References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703040300000409040303" List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 20:34:52.0458 (UTC) FILETIME=[D87FE0A0:01C785E6] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a cryptographically signed message in MIME format. --------------ms030703040300000409040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello PKI-ers, I was looking at all the different possibilities we have now for `discovering' PKI related resources, where by resources I include repositories and services provided by a CA. For example an LDAP server, a CRL repository or an OCSP service. Actually the `standard' way to do so is to embed pointers into certificates via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, as it is quite static (e.g., CA certs have usually quite long life period). Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but none of them seems to be supported widely across apps and systems. My take is because possible solutions are many and they can be difficult to implement (and some of them do not really provide an efficient solution, for example the DNS approach requires that the application knows which is the right domain to query for a service---which might not be trivial if the DC format is not used). I am working on a proposal for developing a protocol to provide a specific solution to the problem, and I really would like the WG to discuss the problem and the proposed solution. I have a brief description of the work done so far here: http://www.openca.org/projects/libprqp Main goals of this work are: * to make it easy for developers to discover PKI resources * to provide a method to dynamically update PKI resources information * to split pki-services management from certificates contents. For example it would help in painless rollover between services, e.g. switching from CRLs to OCSP without the need to re-issuing all the certificates (an example could be taken from the DoD PKI) We might say that this protocol would provide a way to map X509 certificates to network resources by providing pointers (URLs) to applications. I hope this idea could have some consent here and some help also in writing a first draft. We might also setup a slot to discuss this idea at the next IETF Meeting... Thanks for your attention in reading this email, I hope to receive many useful comments and suggestions and, hopefully, also some help in this task. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms030703040300000409040303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIzMTkxNTM4WjAjBgkqhkiG9w0B CQQxFgQUhnkTyRknjTYw6D8fjJZSAAsN8x4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB2B7Qc0TIzw/3ElG/NFU2U HGsqz0JgbFqQGQ+OGOLU0F7thGYFSWMUxBIY7lezT56FUOwJM1litafdlrnwrrHJWwz1Xs74 rryZcy/O7Ih6kyGRYADznuQbCF6Mys3iBc2cjDKYF+U6QBB6E6InOuKR52NV/lTvMXVAh5HD /9R3AAAAAAAAAA== --------------ms030703040300000409040303-- From owner-ietf-pkix@mail.imc.org Mon Apr 23 20:33:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg8yk-0005kA-F2 for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:33:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg8yj-0006QM-3D for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 20:33:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNpR87029293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNpRT5029292; Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNp6JY029218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3NNovVa083499; Mon, 23 Apr 2007 16:50:57 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Russ Housley" , "Julien Stern" , Subject: RE: SCVP Question regarding Trust Anchors Date: Mon, 23 Apr 2007 15:14:08 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Russ, Julien: To what benefit? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley Sent: Monday, April 23, 2007 11:44 AM To: Julien Stern; ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien From reina89652@yahoo.com.cn Mon Apr 23 21:35:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9wV-0007lE-FX for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 21:35:43 -0400 Received: from [122.43.127.43] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9wT-0008UZ-Vq for pkix-archive@lists.ietf.org; Mon, 23 Apr 2007 21:35:43 -0400 Received: by mail (Postfix, from userid 48) id 1586E4C3410; Mon, 23 Apr 2007 17:40:08 +0900 (KST) To: pkix-archive@lists.ietf.org Subject: =?ISO-2022-JP?B?km6Ms4LMg0mDb4NUg5OC8JX4gquCvYKigsWCt4KpgUiDjIN4g4uCzZLhgqKCxYK3gqqKbY7AgsmV+IKvgtyCt4LmISE==?= From: Resent-Sender: reina89652@yahoo.com.cn Message-ID: <20070423174008.96363@yahoo.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Resent-Message-Id: <20070423113738.1586E4C3410@mail> Resent-Date: Mon, 23 Apr 2007 17:40:08 +0900 (KST) Resent-From: reina89652@yahoo.com.cn (Apache) X-Spam-Score: 4.0 (++++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 **************************************************** “–ƒTƒCƒg‚Í40‘ã`50‘ã‚Ì“÷‘ÌŠÖŒW‚ð‹‚ß‚Ä‚¢‚élÈEn— ‚ªW‚Ü‚é“ú–{Å‘å‚Ì•s—σRƒ~ƒ…ƒjƒeƒB[ƒTƒCƒg‚Å‚·B **************************************************** s‚²—˜—p‚ÉŠÖ‚µ‚Ä‚Ì‚²’ˆÓt------------------------------- ‡T@‚²—˜—p‚Í’j—‹¤‚É•s—Ï‚ðŠó–]‚³‚ê‚é•û‚Ì‚Ý‚Æ‚³‚¹‚Ä’¸‚«‚Ü‚·B ‡U@’j—‹¤‚É‚¨‘ŠŽè‚É—v‹‚·‚鎖‚Í•s—ÏË“÷‘ÌŠÖŒW‚Ì‚Ý‚Å‚·B ‡V@ƒzƒeƒ‹‘ã‚ÉŠÖ‚µ‚Ä‚Í‚¨ŒÝ‚¢‚ÅŒˆ‚߂ĉº‚³‚¢B s‚²—˜—p•û–@‚ɂ‚¢‚Ät----------------------------------- ‡T@‚²Šó–]‚Ì’nˆæEƒ[ƒ‹ƒAƒhƒŒƒXEƒpƒXƒ[ƒh‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡U@ŽŸ‚ÉŠÈ’P‚ÈŽ©ŒÈPR‚ðݒ肵‚Ä’¸‚«‚Ü‚·B ‡V@•s—ÏË“÷‘ÌŠÖŒW‚ðŠó–]‚·‚邨‘ŠŽè‚ðŒŸõ‚µ‚Ä’¸‚«‚Ü‚·B ‡W@‚²—˜—p‚³‚ê‚Ä‚¢‚élÈ‚³‚ñ‚Í‘S‚ÄŽ©ŒÈPR“à‚ÉŒg‘єԆ–”‚Í @@’¼ƒAƒhƒŒƒX‚ª•\Ž¦‚³‚ê‚Ä‚¨‚è‚Ü‚·‚Ì‚Å‚»‚ÌŽž“_‚Å’¼Ú‚²˜A—‚ð @@‚µ‚Ä’¸‚¢‚Ä‚àŒ‹\‚Å‚·‚µAƒTƒCƒg“à‚©‚çƒ[ƒ‹‚ɂĘA—‚ðŽæ‚é @@Ž–‚à‰Â”\‚Å‚·‚Ì‚Å‚¨D‚«‚ȘA—•û–@‚ÅŒð‚µ‚ĉº‚³‚¢B y’ˆÓzŽ©ŒÈPR“à‚ɘA—æ‚Ì•\Ž¦‚ª–³‚¢lÈ‚³‚ñ‚Í @@@@Œð‚ª¬—§‚µ“÷‘ÌŠÖŒW’†‚Å‚·‚̂ŘA—æ‚Ì•\Ž¦‚ª @@@@•œŠˆŒãAÄ“xŒðÂ‚ð‚¨Šè‚¢’v‚µ‚Ü‚·B ************************************************************** œ–{“úAŠ®‘S–³—¿‚Ån‚ꂽlÈ‚Æ“÷‘ÌŠÖŒW‚ðŠó–]‚³‚ê‚é’j«‚Í @http://cjbjj.com:112/ddd/hito-5/ œ–{“úAŠ®‘S–³—¿‚ʼnÎÆ‚Á‚½‘Ì‚ð–ž‚½‚µ‚Ä—~‚µ‚¢—«‚Í @http://cjbjj.com:112/ddd/hito-5/ ************************************************************** š‘Ò‡‚킹‚ÌêŠ‚ðƒŠƒAƒ‹ƒ^ƒCƒ€‚Å‚â‚èŽæ‚èŠm”F‚³‚ꂽ‚¢•û‚Í @ƒ‚ƒoƒCƒ‹iŒg‘Ñ“d˜bj‚Å‚ÌÝ’è‚ðƒIƒXƒXƒ’v‚µ‚Ü‚·B ************************************************************** From owner-ietf-pkix@mail.imc.org Tue Apr 24 00:33:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgCiX-0006Wv-Au for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 00:33:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgCiV-0000RX-TJ for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 00:33:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O3iBPd063541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 20:44:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O3iBNS063540; Mon, 23 Apr 2007 20:44:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from auth0.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O3hoKk063450 for ; Mon, 23 Apr 2007 20:44:10 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from auth0.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 6D6382CC41B; Tue, 24 Apr 2007 11:43:47 +0800 (CST) Received: from wcwang (unknown [10.144.133.93]) by auth0.cht.com.tw (Postfix) with SMTP id 3BC9F2CC3EF; Tue, 24 Apr 2007 11:43:47 +0800 (CST) Message-ID: <002601c78622$c31e6e70$5d85900a@wcwang> From: "Wen-Cheng Wang" To: "Massimiliano Pala" , "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 11:43:41 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Dr. Massimiliano Pala, That is an interesting idea. However, one imaginable problem you might face is "how a relying party (the PRQP client) can find an authroized RQA?" One straightforward way is to let the CA issue a certificate first to delegate the authority to the RQA and then use AIA/SIA extnesions to provide the URL of the authroized RQA (the authroized PRQP server) to the PRQP client. If you are going to adopt this kind of straightforward solution, it will not be a painless rollover from traditional ways (embed various pointers via CDP, AIA or SIA extensions) to the new way (a single AIA/SIA extension comtaining the authroized PRQP access info). The reason why it will not be a painless rollover is that the goal can not be achieved without the need to re-issuing all the existing certificates to add the newly defined PRQP access info into the AIA/SIA extension. Wen-Cheng Wang ----- Original Message ----- From: "Massimiliano Pala" To: "pkix" Sent: Tuesday, April 24, 2007 3:15 AM Subject: PKI Resource Discovery - Proposal for a new Working Item > Hello PKI-ers, > > I was looking at all the different possibilities we have now for `discovering' > PKI related resources, where by resources I include repositories and services > provided by a CA. For example an LDAP server, a CRL repository or an OCSP > service. > > Actually the `standard' way to do so is to embed pointers into certificates > via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, > as it is quite static (e.g., CA certs have usually quite long life period). > Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but > none of them seems to be supported widely across apps and systems. My take > is because possible solutions are many and they can be difficult to implement > (and some of them do not really provide an efficient solution, for example > the DNS approach requires that the application knows which is the right domain > to query for a service---which might not be trivial if the DC format is not > used). > > I am working on a proposal for developing a protocol to provide a specific > solution to the problem, and I really would like the WG to discuss the > problem and the proposed solution. > > I have a brief description of the work done so far here: > > http://www.openca.org/projects/libprqp > > Main goals of this work are: > * to make it easy for developers to discover PKI resources > * to provide a method to dynamically update PKI resources information > * to split pki-services management from certificates contents. For example > it would help in painless rollover between services, e.g. switching from > CRLs to OCSP without the need to re-issuing all the certificates (an example > could be taken from the DoD PKI) > > We might say that this protocol would provide a way to map X509 certificates to > network resources by providing pointers (URLs) to applications. > > I hope this idea could have some consent here and some help also in writing > a first draft. We might also setup a slot to discuss this idea at the next > IETF Meeting... > > Thanks for your attention in reading this email, I hope to receive many > useful comments and suggestions and, hopefully, also some help in this > task. > > > -- > > Best Regards, > > Dr. Massimiliano Pala > > --o------------------------------------------------------------------------ > Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu > project.manager@openca.org > > Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 > PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 > --o------------------------------------------------------------------------ > From owner-ietf-pkix@mail.imc.org Tue Apr 24 04:04:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgG0c-0003fv-Of for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 04:04:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgG0b-0005Jl-Bs for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 04:04:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O7Dl9K098512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 00:13:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O7Dl1w098511; Tue, 24 Apr 2007 00:13:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O7DPXu098498 for ; Tue, 24 Apr 2007 00:13:46 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA44208; Tue, 24 Apr 2007 09:18:21 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042409131774:4519 ; Tue, 24 Apr 2007 09:13:17 +0200 Date: Tue, 24 Apr 2007 09:13:15 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Cc: "Julien Stern" Subject: Re: SCVP Question regarding Trust Anchors X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 09:13:17, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 09:13:24, Serialize complete at 24/04/2007 09:13:24 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 The comment from Julien is correct: multiple trust anchors with different conditions are not permittted, unless using a specific OID for the validation policy and have all the parameters known by the server. >You are right, in my personal opinion, that would be a better >structure. Can you propose text? In order to allow it, this would have required a small change in the ASN.1 structure. I made this remark to Tim, when he was editing the document, but it was not accepted. If a client wants to specify different parameters for each trust anchor, multiple calls will need to be made. Denis > >Russ > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > >>Folks, >> >>sorry to ask this fairly late in the process, but it did not catch >>my eye before: >> >>The ValidationPolicy structure defines >>- userPolicySet >>- inhibitPolicyMapping >>- requireExplicitPolicy >>- inhibitAnyPolicy >> >>globally and not on a per trust-anchor basis. >> >>Wouldn't it be more logical and less limiting to define it for each >>trust anchor (like in RFC3125)... ? >> >>Regards, >> >>-- >>Julien From owner-ietf-pkix@mail.imc.org Tue Apr 24 05:20:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHBr-0002eW-Rl for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 05:20:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHBr-0006Tb-70 for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 05:20:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8WFrP008146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 01:32:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O8WFW6008145; Tue, 24 Apr 2007 01:32:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8WDPZ008139 for ; Tue, 24 Apr 2007 01:32:14 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24682; Tue, 24 Apr 2007 10:37:09 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042410320868:6945 ; Tue, 24 Apr 2007 10:32:08 +0200 Date: Tue, 24 Apr 2007 10:32:06 +0200 From: "Denis Pinkas" To: "Tim Polk" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 10:32:08, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 10:32:09, Serialize complete at 24/04/2007 10:32:09 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Tim, Thank you for your time for reviewing LCVP. See my responses below. >Denis, > >I finally found some time this weekend to review the LCVP >specification. I thought it was important to avoid snap judgements. >After reviewing the specification, I do not see a justification for >pursuing this document. > >If we consider this specification from a DPV client viewpoint, there >are very few differences between an LCVP client and the minimal SCVP >client. You identify the following differences (my numbering for >clarity): > > (1) the protocol only supports DPV, i.e. it includes no provision >to support Delegated Path Discovery (DPD); > (2) requests and responses are not signed, since they are >protected by TLS, where clients are not authenticated; > (3) validation is only for one certificate at a time; > (4) there is no specific parameter in the request to add any >parameter to a validation policy known by the server. > >However, this overstates the differences. (1) SCVP implementations >are not required to implement both DPD and DPV. (2) SCVP clients and >servers MUST support protected (e.g., signed) responses, but the >client may choose to use TLS as a protected transport to protect the >responses. This single argument (i.e. SCVP clients and servers MUST support protected (e.g., signed) responses) illustrates why it not make sense to mandate such a support when only transport layer security is being used. This means it is not effective to profile SCVP to only fulfill the requirements addressed by LCVP. >(3) Clients are not only permitted to submit requests one >certificate at a time, conforming client implementations are not >required to support multi-certificate requests. (4) As in 3, >modifying the validation policy need not be supported by conforming >clients. > >In short, LCVP does not provide functionality that is unavailable in >SCVP. This is incorrect. Please take a look at: validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, The meaning of producedAt in SCVP is different from the meaning of validationTime in LCVP. LCVP with this parameter may support the validation of certificates used for non repudiation puroposes, whereas SCVP can't. See the explanations about the grace period fullSubjectName allows to handle unique names, whereas SCVP can't. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. Of course, using four new OIDs it would be possible to expand SCVP to support these parameters, but it wan't be as simple as in LCVP. >While LCVP's ASN.1 appears less complicated, I am glad you acknowlege the fact that LCVP is simpler than SCVP. > the data structures generated by minimally conforming SCVP DPV-only client >implementations appear to have similar levels of complexity. I do not think so. Beside the unneeded complexity of the response which results from the use of CMS: ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } there is a lot of OIDs to manage. Another example of overcomplexity is the mandatory use of the following OID { id-svp 1 } to specify the default validation policy, while LCVP may simply omit the parameter: valPolicyRef ValPolicyRef OPTIONAL, Furthermore, where LCVP allows any default validation policy, in SCVP : " The default validation policy MUST use the basic validation algorithm as its default validation algorithm". There is a French common saying, which states roughly the following: " Why keep it simple, when you can make it complicated ?" It would perfectly apply to an SCVP profile (if any was possible). >I cannot see any reason to pursue a new DPV protocol that ignores the >requirements established in 3379 within the IETF. It does not ignore them, but does not take all of them. > I can see the >rationale for a lightweight client profile for SCVP, as suggested by >others on this list, to demonstrate how simple an SCVP client can >actually be. A lightweight client profile for SCVP is not realistic without changing SCVP. SCVP is already in the hands of the RFC editor for publication as an RFC. Denis >Thanks, > >Tim Polk > >On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > >> >> >> I needed a simple protocol to delegate the validation of a >> certificate to a server, >> to be used in environments where a client does not need to demonstrate >> to somebody else that it got a given response from a server. This >> implies >> that the server is fully trusted by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does >> not mean "Simple", >> or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests >> is not needed, and the use of a subset of the various OIDs is not >> trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight >> Certificate Validation Protocol (LCVP), like LDAP is simpler than >> DAP. :-) >> >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to >> a trusted server. The path validation (e.g. making sure that none >> of the certificates in the path are revoked) is performed according >> to a set of rules called a validation policy. It allows >> simplification >> of client implementations and only uses of a set of validation >> policies >> known by the server. The document defines a protocol >> that can be used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet >> been implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be >> re-targeted to the standard track category. >> >> Denis >> >> > > Regards, Denis Pinkas From owner-ietf-pkix@mail.imc.org Tue Apr 24 05:20:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHBz-0002f1-Hr for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 05:20:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHBy-0006UH-2T for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 05:20:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8TBl9007833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 01:29:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O8TBAT007832; Tue, 24 Apr 2007 01:29:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8SoGe007779 for ; Tue, 24 Apr 2007 01:29:10 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 7AD8741294; Tue, 24 Apr 2007 10:28:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 3ED9944293; Tue, 24 Apr 2007 10:28:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmlGBcEQZtQ9; Tue, 24 Apr 2007 10:28:40 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id C563044021; Tue, 24 Apr 2007 10:28:39 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Tue, 24 Apr 2007 10:28:39 +0200 From: "Julien Stern" Date: Tue, 24 Apr 2007 10:28:39 +0200 To: "David A. Cooper" Cc: Russ Housley , pkix Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070424082839.GJ1691@mars.cry.pto> Mail-Followup-To: Julien Stern , "David A. Cooper" , Russ Housley , pkix References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> <462D2A85.1070307@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462D2A85.1070307@nist.gov> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 David, I agree that I can define my validation policy as I want and live with the ability to do this by only specifying an OID. Still, I believe the trade off has _really_ gone towards simplicity and not flexibility. Even the inhibitPolicyMapping, the requireExplicitPolicy and the inhibitAnyPolicy are booleans instead of integers. Also, I disagree that one can send multiple requests. The trust anchor for an OCSP response may not be the same as the one for the main certificate and may have conflicting parameters. Would it be complicated to leverage on RFC3125 which defines a Trust Anchor as: CertificateTrustPoint ::= SEQUENCE { trustpoint Certificate, -- self-signed certificate pathLenConstraint [0] PathLenConstraint OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, nameConstraints [2] NameConstraints OPTIONAL, policyConstraints [3] PolicyConstraints OPTIONAL } possibly replacing the Certificate by a PKCReference. -- Julien On Mon, Apr 23, 2007 at 05:52:05PM -0400, David A. Cooper wrote: > > > Russ, Julien, > > This was discussed on the list in early 2005 and the consensus was > against making this change. It was simply a trade off between > flexibility and complexity. In almost every case, the same set of > inputs (e.g., userPolicySet, inhibitPolicyMapping, > requireExplicitPolicy, etc.) are appropriate for each trust anchor. > Allowing different values to be specified for each trust anchor would > complicate things for all clients (and servers) for the benefit of the > few that would need this level of granularity in specifying validation > requirements and we already have enough complaints that SCVP is too > complicated. The few clients that need this degree of flexibility can > simply send multiple requests, with each request specifying a different > set of trust anchors along with the appropriate input values for that > set of trust anchors. > > (Note that in theory a validation policy could be defined in which > values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, > etc. were different for each trust anchor. The easiest way to do this > would be to only allow the client to specify the validation policy by > OID and to only include the validation policy by reference in the > response. That way the request would simply say "validate certificate X > under policy Y" and the response would say "the result of validating > certificate X under policy Y was ...". Since neither the request nor > the response would include any explicit information about the meaning of > policy Y, there would be no limitations on the complexity of the > definition of policy Y. Not that I would recommend defining overly > complicated validation policies, but I think it can be done with certain > limitations on what can be included in the request and in the response.) > > Dave > > Russ Housley wrote: > > > >You are right, in my personal opinion, that would be a better > >structure. Can you propose text? > > > >Russ > > > > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > > > >>Folks, > >> > >>sorry to ask this fairly late in the process, but it did not catch > >>my eye before: > >> > >>The ValidationPolicy structure defines > >>- userPolicySet > >>- inhibitPolicyMapping > >>- requireExplicitPolicy > >>- inhibitAnyPolicy > >> > >>globally and not on a per trust-anchor basis. > >> > >>Wouldn't it be more logical and less limiting to define it for each > >>trust anchor (like in RFC3125)... ? > >> > >>Regards, > >> > >>-- > >>Julien > From owner-ietf-pkix@mail.imc.org Tue Apr 24 06:05:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHtd-0002Yt-DS for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 06:05:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHta-00024L-Oc for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 06:05:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O9GJQq012433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 02:16:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O9GJCY012432; Tue, 24 Apr 2007 02:16:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O9GHvf012425 for ; Tue, 24 Apr 2007 02:16:18 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA29892 for ; Tue, 24 Apr 2007 11:21:16 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042411161537:8293 ; Tue, 24 Apr 2007 11:16:15 +0200 Date: Tue, 24 Apr 2007 11:16:12 +0200 From: "Denis Pinkas" To: "pkix" Subject: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 11:16:15, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 11:16:16, Serialize complete at 24/04/2007 11:16:16 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I need a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis From owner-ietf-pkix@mail.imc.org Tue Apr 24 07:33:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJGY-0005al-4X for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 07:33:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJGW-0002Jb-DF for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 07:33:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAVDG2018511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OAVDnG018510; Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAUqGR018468 for ; Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 25D9820; Tue, 24 Apr 2007 12:30:39 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20738-03; Tue, 24 Apr 2007 12:30:36 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id E08271F; Tue, 24 Apr 2007 12:30:31 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042412303017:218380 ; Tue, 24 Apr 2007 12:30:30 +0200 Message-ID: <462DDBC4.9030607@edelweb.fr> Date: Tue, 24 Apr 2007 12:28:20 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 12:30:30 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 12:30:31 PM, Serialize complete at 04/24/2007 12:30:31 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010405020002000500070205" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 This is a cryptographically signed message in MIME format. --------------ms010405020002000500070205 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit LCVP as well as SCVP allow two different ways to identify a certificate. Either by providing the certificate or by a reference. In the second case the server needs to access a repository to obtain a certificate. To which degree does a server trust the repository to deliver a valid certificate? Or, in other words, would it be equivalent or not that the client obtains by whatever means a certificate and provides it as input. If the server is provided with a certificate as input, what is the meaning of a successful response: - this is a valid certifcate that has in fact been issued by the CA and it is trusted etc - this certificate seems indeed to be signed by the CA etc. Peter --------------ms010405020002000500070205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTAyODIwWjAjBgkqhkiG9w0B CQQxFgQUXF077IR7r6ZcR4BqaljG2QvYMCwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAw10NSfk94iEYi+6P aLUgE7WF7/4mI0Nxzmtf9/xHBJziY/uQiQPIP9uXEb3YUMTUl1rYB4uqIkSn0ShqTJQScBf8 nFO3KCjjVj1iFXmQN2cwHoWHNSbEx7GRGcVEpXXk4Rx1egD5nniUGgYy5XiC+8Mao2DH8GAL iDfuQb0vPRAAAAAAAAA= --------------ms010405020002000500070205-- From owner-ietf-pkix@mail.imc.org Tue Apr 24 11:27:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMvm-000596-Tb for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:27:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMvl-0006Oj-EP for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:27:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OESewP038492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 07:28:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OESenu038491; Tue, 24 Apr 2007 07:28:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OESKd2038447 for ; Tue, 24 Apr 2007 07:28:40 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Tue, 24 Apr 2007 07:27:43 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879077B856B@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceGWX4V3S2YxoSISNqv5f2boxE9SAAItibQ References: From: "Santosh Chokhani" To: "pkix" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3OESed2038486 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 It may be better for LCVP to rely on signed objects and not change the SCVP. While I realize that most clients do SSL/TLS, if we want thin clients to differ the certification path discovery and validation to a Server, assuming that TLS or SSL client is there (which requires certification path validation), may not be the best assumption. Thus, leaving SCVP alone and processing signed CMS objects for LCVP may be a better choice. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, April 24, 2007 5:16 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I need a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis From owner-ietf-pkix@mail.imc.org Tue Apr 24 11:45:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNCq-0005Bt-HB for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:45:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNCq-0001vs-1D for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:45:28 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OEvjkl041253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 07:57:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OEvjq7041252; Tue, 24 Apr 2007 07:57:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OEvNx0041220 for ; Tue, 24 Apr 2007 07:57:44 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id B8CD368048; Tue, 24 Apr 2007 15:57:22 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07B08AD0C7; Tue, 24 Apr 2007 15:57:22 +0100 Received: from [134.226.36.174] (nanga.dsg.cs.tcd.ie [134.226.36.174]) by imx2.tcd.ie (Postfix) with ESMTP id 9042B68048; Tue, 24 Apr 2007 15:57:22 +0100 (IST) Message-ID: <462E1B2E.6050708@cs.tcd.ie> Date: Tue, 24 Apr 2007 15:58:54 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-AntiVirus-Status: MessageID = A17B08AD0C7 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.74.2) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3OEvix0041247 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l3OEvjkl041253 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Hi Denis, My =800.02: I don't believe there's a significant demand for this. At least I've not heard of someone who wants this protocol. If there is a demand, (not met by SCVP), then I further doubt that there's sufficient energy to fight all these fights all over again. (cf. Santosh's mail just now.) If there was sufficient energy, then I doubt that the outcome would be much different to SCVP. Finally, if I'm wrong about the above, then whoever it is that wants whatever it is that SCVP doesn't do and who has the energy to write new code should of course just use XKMS and be done with it in a few days rather than in ~2010. All-in-all I'm for the WG not taking this on, Cheers, Stephen. Denis Pinkas wrote: >=20 > I need a simple protocol to delegate the validation of a certificate to= a server,=20 > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This impli= es=20 > that the server is fully trusted by the client. >=20 > I considered using a profile of SCVP. Remember that the "S" does not me= an "Simple",=20 > or "Standard" anymore, but "Server-based". >=20 > However, the use of CMS to encapsulate everything and allowing to optio= nally sign requests > is not needed, and the use of a subset of the various OIDs is not trivi= al as well. >=20 > I looked at other alternatives, outside the IETF, but they do not provi= de an adequate answer.=20 >=20 > This proposal is for lightweight clients, hence why it is called Lightw= eight=20 > Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. = :-) >=20 > LCVP only supports a subset of the mandatory requirements described in=20 > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is=20 > not either a profile of SCVP. >=20 > The major differences with SCVP are the following: >=20 > - the protocol only supports DPV, i.e. it includes no provisions=20 > to support Delegated Path Discovery (DPD); >=20 > - requests and responses are not signed, since they are protected=20 > by TLS, where clients are not authenticated; >=20 > - validation is only for one certificate at a time; >=20 > - there is no specific parameter in the request to add any=20 > parameter to a validation policy known by the server.=20 > =20 > LCVP allows a client to delegate certificate path validation to=20 > a trusted server. The path validation (e.g. making sure that none=20 > of the certificates in the path are revoked) is performed according=20 > to a set of rules called a validation policy. It allows simplification= =20 > of client implementations and only uses of a set of validation policies= =20 > known by the server. The document defines a protocol=20 > that can be used to: >=20 > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server.=20 >=20 > At this time, the document is a strawman proposal and has not yet been = implemented. > There are certainly errors in it and it can certainly be improved - whi= le keeping it "light". >=20 > At this time, the document is an individual draft targeted for the expe= rimental category. >=20 > The document is available at:=20 > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >=20 > The document is proposed to the PKIX WG for consideration and comments. >=20 > If the WG, later on, finds this approach interresting, then the documen= t could be=20 > re-targeted to the standard track category. > =20 > Denis >=20 >=20 >=20 From owner-ietf-pkix@mail.imc.org Tue Apr 24 11:49:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNH0-0000DR-A5 for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:49:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNGy-0002yV-Qe for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:49:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF5IMj041934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 08:05:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OF5IMs041933; Tue, 24 Apr 2007 08:05:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF4tOl041893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2007 08:05:16 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3OF4ji2003654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2007 11:04:46 -0400 Message-ID: <462E1C8D.8090602@cs.dartmouth.edu> Date: Tue, 24 Apr 2007 11:04:45 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Wen-Cheng Wang CC: pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> In-Reply-To: <002601c78622$c31e6e70$5d85900a@wcwang> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070302040105090009000906" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a cryptographically signed message in MIME format. --------------ms070302040105090009000906 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms070302040105090009000906 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTUwNDQ1WjAjBgkqhkiG9w0B CQQxFgQU/7rh+Rl+1aG5TC9jtt5JVN7Du5UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYBlIl91nqt8o5ij0sHDpyns iFfoF43XG8dMvsUdAIJMxG74yoFdQ0NPBOsJQz1kuGDyOKacKw7jdUKOuTGbsbifm36GG/5B +w7GavBidNu1FMqVBprBkBFavYU8WM39y88ekev5P5nK4pYxBxr15Rlo0ftoYpN0H2+xVmWx IQGUoAAAAAAAAA== --------------ms070302040105090009000906-- From owner-ietf-pkix@mail.imc.org Tue Apr 24 11:50:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNHq-0001Ul-OO for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:50:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNHp-00034r-BX for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 11:50:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF8pQq042188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 08:08:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OF8pT8042187; Tue, 24 Apr 2007 08:08:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3OF8Uu9042167 for ; Tue, 24 Apr 2007 08:08:50 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704241508.l3OF8Uu9042167@balder-227.proper.com> Received: (qmail 3857 invoked by uid 0); 24 Apr 2007 15:08:26 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 24 Apr 2007 15:08:26 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Apr 2007 10:59:58 -0400 To: "Michael Myers" From: Russ Housley Subject: RE: SCVP Question regarding Trust Anchors Cc: ietf-pkix@imc.org In-Reply-To: References: <200704231953.l3NJr9VR095229@balder-227.proper.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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Mike: If a validation policy includes several trust anchors, then it is desirable for the path validation algorithm inputs for each of these might be different. I can live with the current structure, but it imposes the restriction that all of the trust anchors associated with the validation policy must be used with the same path validation algorithm inputs. Russ At 07:14 PM 4/23/2007, Michael Myers wrote: >Russ, Julien: > >To what benefit? > >Mike > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley >Sent: Monday, April 23, 2007 11:44 AM >To: Julien Stern; ietf-pkix@imc.org >Subject: Re: SCVP Question regarding Trust Anchors > > > >You are right, in my personal opinion, that would be a better >structure. Can you propose text? > >Russ > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > > >Folks, > > > >sorry to ask this fairly late in the process, but it did not catch > >my eye before: > > > >The ValidationPolicy structure defines > >- userPolicySet > >- inhibitPolicyMapping > >- requireExplicitPolicy > >- inhibitAnyPolicy > > > >globally and not on a per trust-anchor basis. > > > >Wouldn't it be more logical and less limiting to define it for each > >trust anchor (like in RFC3125)... ? > > > >Regards, > > > >-- > >Julien From owner-ietf-pkix@mail.imc.org Tue Apr 24 13:54:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPDs-0002no-OC for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 13:54:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPDr-0003Yo-21 for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 13:54:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OH0jPE055406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:00:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OH0jjW055405; Tue, 24 Apr 2007 10:00:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OH0NI0055378 for ; Tue, 24 Apr 2007 10:00:44 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 2EC251E; Tue, 24 Apr 2007 19:00:23 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11746-09; Tue, 24 Apr 2007 19:00:20 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id A75CF16; Tue, 24 Apr 2007 19:00:20 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042419001993:219829 ; Tue, 24 Apr 2007 19:00:19 +0200 Message-ID: <462E3721.6060808@edelweb.fr> Date: Tue, 24 Apr 2007 18:58:09 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Stephen Farrell Cc: Denis Pinkas , pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: <462E1B2E.6050708@cs.tcd.ie> In-Reply-To: <462E1B2E.6050708@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 07:00:20 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 07:00:20 PM, Serialize complete at 04/24/2007 07:00:20 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803050405090908050403" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a cryptographically signed message in MIME format. --------------ms060803050405090908050403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit One can say that SCVP has too moch of lower layer specific information. In fact, one can fold out the signeData or authenticateddata encapsulation as well as TLS transport layer security, http, and the contenttype encapsulation saying the the request and response structure need to be communicated to the partner. In a local unix environment, one could for example just exchange this via unix sockets/pipes as with some ldap, and you do not need any of the overhead, or one would use some IPSec authenticated channel etc. Or, one can replace all this lower layer bindings by some usage of WSS or secure WSS or beep, but that's another story. If one takes just the content of the queries, then it is a matter of taste how to encode certain details of the payload of the query. I don't see that there is a real need to define yet another payload format, as far as I see the Denis' essential argument is that the binding envelopes are too much overhead. I agree with Stpehen, that in case of, the appropriate subset of XKMS can be used, even if one doesn't like XML, then trasform XMKS into ASN.1 automatically and code in PER or use the fast doc encoding, etc. The still unclear question (at least to me) is about the service to be provided and whether there is a difference between the protocols. See my previous message. --------------ms060803050405090908050403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTY1ODA5WjAjBgkqhkiG9w0B CQQxFgQUlIE3/CQlfGf7OMSob8hI6Q2EslcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAoHY2hm9j6o/OV1dr rhfaYWy8D1qHdt1jFgJRmdaiI127AcJAgWgbxAI+RlC+NFEy/kX9jxTBd8dl1VimXLTHEl75 KfZyft82EAISPmbaw9oL21xq7hnaf5QA/YrG16LeBnIh8ktlIo/ABTlQaK3h6pEnDOs2j7bT T8pMHb7hntsAAAAAAAA= --------------ms060803050405090908050403-- From owner-ietf-pkix@mail.imc.org Tue Apr 24 14:34:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPqs-0001ot-Pi for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 14:34:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPqr-0002wr-Bh for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 14:34:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHigFS062328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OHigZ3062327; Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHiLhU062247 for ; Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.232.45.243) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) (authenticated as u18116613) id 46245DE10021B0F5; Tue, 24 Apr 2007 19:44:17 +0200 Message-ID: <001101c78698$2904cd40$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Massimiliano Pala" , "Wen-Cheng Wang" Cc: "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 19:44:04 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Max, Some time ago you proposed new PKI protocols but then you did not state any specific use-case. I'm happy to see such now :-) Regarding painful rollover, I believe a 5-year plan or so is realistic if it involves certificate changes. If the idea is really some kind of "mapping scheme" between existing certificates and services it may be faster but OTOH I don't really see how such a mapping utility would work given the huge variations out there. But maybe you are thinking of some kind of centralized discovery service? Personally I'm only interested in decentralized Internet-scale PKI solutions (the opposite to S/MIME...) and would due to this base a new scheme on the only Internet-scale "registry" there is: DNS. I would suggest a scheme based on DNS names which both can be obtained locally (from a config file) as well as being supplied in a new certificate extension. This would allow step-wise migration which has proved to be the fastest route to adoption. The following is one way of architecting this: In the repository/certificate extension: "example.com" Searched for by an enhanced PKI client: _thesuperduper-pki-lookup.example.com TXT "something" _other-pki-lookup-service.example.com TXT "something" Regarding applications, I would like to add automatic certificate renewal services support. regards Anders ----- Original Message ----- From: "Massimiliano Pala" To: "Wen-Cheng Wang" Cc: "pkix" Sent: Tuesday, April 24, 2007 17:04 Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ From owner-ietf-pkix@mail.imc.org Tue Apr 24 14:37:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPtg-0004QV-50 for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 14:37:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPte-0004Br-LF for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 14:37:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHvX3U064369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OHvX8w064368; Tue, 24 Apr 2007 10:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHvCQ2064322 for ; Tue, 24 Apr 2007 10:57:32 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.232.45.243) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) (authenticated as u18116613) id 461E4AF80031F10E; Tue, 24 Apr 2007 19:56:58 +0200 Message-ID: <000401c78699$ee787b20$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Massimiliano Pala" , "Wen-Cheng Wang" Cc: "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 19:44:04 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Max, Some time ago you proposed new PKI protocols but then you did not state any specific use-case. I'm happy to see such now :-) Regarding painful rollover, I believe a 5-year plan or so is realistic if it involves certificate changes. If the idea is really some kind of "mapping scheme" between existing certificates and services it may be faster but OTOH I don't really see how such a mapping utility would work given the huge variations out there. But maybe you are thinking of some kind of centralized discovery service? Personally I'm only interested in decentralized Internet-scale PKI solutions (the opposite to S/MIME...) and would due to this base a new scheme on the only Internet-scale "registry" there is: DNS. I would suggest a scheme based on DNS names which both can be obtained locally (from a config file) as well as being supplied in a new certificate extension. This would allow step-wise migration which has proved to be the fastest route to adoption. The following is one way of architecting this: In the repository/certificate extension: "example.com" Searched for by an enhanced PKI client: _thesuperduper-pki-lookup.example.com TXT "something" _other-pki-lookup-service.example.com TXT "something" Regarding applications, I would like to add automatic certificate renewal services support. regards Anders ----- Original Message ----- From: "Massimiliano Pala" To: "Wen-Cheng Wang" Cc: "pkix" Sent: Tuesday, April 24, 2007 17:04 Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ From owner-ietf-pkix@mail.imc.org Tue Apr 24 15:13:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQRx-0006yB-9S for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 15:13:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgQRv-0005GV-Pr for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 15:13:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OILL1E067495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 11:21:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OILLw2067494; Tue, 24 Apr 2007 11:21:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3OIL0RG067384 for ; Tue, 24 Apr 2007 11:21:20 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 34690 invoked from network); 24 Apr 2007 18:20:49 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2007 18:20:49 -0000 X-YMail-OSG: Oz8jPQIVM1l5uJe4NgxQmtMLWi9betHtB_CnzlupceXSMLWOxfMsxzSe0ESGkIWJiQ-- Message-ID: <462E4BFE.5060205@connotech.com> Date: Tue, 24 Apr 2007 14:27:10 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Massimiliano Pala CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> In-Reply-To: <462E1C8D.8090602@cs.dartmouth.edu> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Massimiliano Pala wrote: > Hello Wen-Cheng, > > thank you for the comment. Indeed the distribution of the RQA address > is something tricky, but the AIA/SIA extensions can be used to provide > that. Also the DHCP could be used for the same porpuse on a local > network. > Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? If you think of DHCP, a look at SLP is certainly deserved. I did the exercise with DNSSEC deployment, see http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com From owner-ietf-pkix@mail.imc.org Tue Apr 24 23:00:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXkG-0004cx-Es for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 23:00:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXkF-0004Sq-33 for pkix-archive@lists.ietf.org; Tue, 24 Apr 2007 23:00:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P25NgJ065643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 19:05:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3P25N4P065642; Tue, 24 Apr 2007 19:05:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P251lM065597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2007 19:05:22 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3P24wJb041450; Tue, 24 Apr 2007 19:04:58 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Russ Housley" Cc: Subject: RE: SCVP Question regarding Trust Anchors Date: Tue, 24 Apr 2007 17:28:09 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Importance: Normal In-Reply-To: <200704241508.l3OF8Uu9042167@balder-227.proper.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Russ, Your explanation suggests "equivalency". I fear for in-band negotiation of that state absent a use-case requirement. Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley Sent: Tuesday, April 24, 2007 7:00 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: SCVP Question regarding Trust Anchors Mike: If a validation policy includes several trust anchors, then it is desirable for the path validation algorithm inputs for each of these might be different. I can live with the current structure, but it imposes the restriction that all of the trust anchors associated with the validation policy must be used with the same path validation algorithm inputs. Russ At 07:14 PM 4/23/2007, Michael Myers wrote: >Russ, Julien: > >To what benefit? > >Mike From owner-ietf-pkix@mail.imc.org Wed Apr 25 05:43:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge2B-0006ng-Im for pkix-archive@lists.ietf.org; Wed, 25 Apr 2007 05:43:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hge2A-00068V-5o for pkix-archive@lists.ietf.org; Wed, 25 Apr 2007 05:43:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P8qj38027892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 01:52:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3P8qjOH027891; Wed, 25 Apr 2007 01:52:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P8qNHX027858 for ; Wed, 25 Apr 2007 01:52:44 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 7672240F59; Wed, 25 Apr 2007 10:52:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 21BD744293; Wed, 25 Apr 2007 10:52:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI2nNNgnNJLw; Wed, 25 Apr 2007 10:52:18 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id B0B3A44160; Wed, 25 Apr 2007 10:52:17 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 25 Apr 2007 10:52:17 +0200 From: "Julien Stern" Date: Wed, 25 Apr 2007 10:52:17 +0200 To: Michael Myers Cc: Russ Housley , ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070425085216.GL1691@mars.cry.pto> Mail-Followup-To: Julien Stern , Michael Myers , Russ Housley , ietf-pkix@imc.org References: <200704241508.l3OF8Uu9042167@balder-227.proper.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Mike, just check RFC3125 (part of PKIX). It defines a validation policy where several trust anchors are associated with different inputs. The benefit would be to be able to validate such a policy with SCVP. -- Julien On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > Russ, > > Your explanation suggests "equivalency". > I fear for in-band negotiation of that > state absent a use-case requirement. > > Mike > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > Sent: Tuesday, April 24, 2007 7:00 AM > To: Michael Myers > Cc: ietf-pkix@imc.org > Subject: RE: SCVP Question regarding Trust Anchors > > > > Mike: > > If a validation policy includes several trust anchors, then it is > desirable for the path validation algorithm inputs for each of these > might be different. I can live with the current structure, but it > imposes the restriction that all of the trust anchors associated with > the validation policy must be used with the same path validation > algorithm inputs. > > Russ > > At 07:14 PM 4/23/2007, Michael Myers wrote: > >Russ, Julien: > > > >To what benefit? > > > >Mike > From owner-ietf-pkix@mail.imc.org Wed Apr 25 10:09:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiBN-0000yi-Ey for pkix-archive@lists.ietf.org; Wed, 25 Apr 2007 10:09:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiBL-00018L-1f for pkix-archive@lists.ietf.org; Wed, 25 Apr 2007 10:09:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PD5t45055165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3PD5tBZ055164; Wed, 25 Apr 2007 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PD5YJ2055108 for ; Wed, 25 Apr 2007 06:05:54 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id B09D94F402; Wed, 25 Apr 2007 15:05:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D180544293; Wed, 25 Apr 2007 15:05:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQGVD-GryQCg; Wed, 25 Apr 2007 15:05:27 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 198D644160; Wed, 25 Apr 2007 15:05:26 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 25 Apr 2007 15:05:26 +0200 From: "Julien Stern" Date: Wed, 25 Apr 2007 15:05:26 +0200 To: Michael Myers , Russ Housley , ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070425130525.GN1691@mars.cry.pto> Mail-Followup-To: Julien Stern , Michael Myers , Russ Housley , ietf-pkix@imc.org References: <200704241508.l3OF8Uu9042167@balder-227.proper.com> <20070425085216.GL1691@mars.cry.pto> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425085216.GL1691@mars.cry.pto> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 On Wed, Apr 25, 2007 at 10:52:17AM +0200, Julien Stern wrote: > > Mike, > > just check RFC3125 (part of PKIX). > It defines a validation policy where several trust anchors > are associated with different inputs. > The benefit would be to be able to validate such a policy with SCVP. A few people let me know that 1) RFC3125 is part of S/MIME (not PKIX) 2) It is "Experimental" However, it is related to the ETSI technical reports 102038 and 102272, which define a broader notion of Trust Anchor than SCVP. Well, that's for the benefit: being in sync with these TRs and the Experimental RFC. That being said, as Russ, I can live with the current situation. It is always possible to define a local policy that has more complex Trust Anchors... -- Julien > -- > Julien > > On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > > > Russ, > > > > Your explanation suggests "equivalency". > > I fear for in-band negotiation of that > > state absent a use-case requirement. > > > > Mike > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > > Sent: Tuesday, April 24, 2007 7:00 AM > > To: Michael Myers > > Cc: ietf-pkix@imc.org > > Subject: RE: SCVP Question regarding Trust Anchors > > > > > > > > Mike: > > > > If a validation policy includes several trust anchors, then it is > > desirable for the path validation algorithm inputs for each of these > > might be different. I can live with the current structure, but it > > imposes the restriction that all of the trust anchors associated with > > the validation policy must be used with the same path validation > > algorithm inputs. > > > > Russ > > > > At 07:14 PM 4/23/2007, Michael Myers wrote: > > >Russ, Julien: > > > > > >To what benefit? > > > > > >Mike > > > From owner-ietf-pkix@mail.imc.org Thu Apr 26 19:05:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD1c-0001vV-RB for pkix-archive@lists.ietf.org; Thu, 26 Apr 2007 19:05:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhD1b-0003PV-7f for pkix-archive@lists.ietf.org; Thu, 26 Apr 2007 19:05:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QM0ImD004214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 15:00:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QM0IMD004213; Thu, 26 Apr 2007 15:00:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLxvge004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Apr 2007 15:00:17 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l3QLxmEm006099; Thu, 26 Apr 2007 14:59:50 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:59:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Thu, 26 Apr 2007 14:59:13 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD370124CE06@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <462E1B2E.6050708@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceGjJUTE9yZWLE4QjWXZ1z0DDtGgwBwRREQ From: "Hallam-Baker, Phillip" To: "Stephen Farrell" , "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 26 Apr 2007 21:59:47.0971 (UTC) FILETIME=[34E6B530:01C7884E] X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3QM0Hgd004202 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l3QM0ImD004214 X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c I heartily concur with Stephen here. If you want lighweight PKI then you don't want a certificate based PKI at= all. You want a key centric model where the only thing that a relying ap= plication needs to do is to ask an external service 'what key should I us= e to talk protocol X to party Y'. XKMS is not perfect, but it exists and meets this need. The backing infra= structure behind XKMS will probably involve certificates and SCVP but the= client is insulated from all that. I don't think that you get what you want here unless you abandon the fixa= tion with certificates. =20 > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org=20 > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Farrell > Sent: Tuesday, April 24, 2007 10:59 AM > To: Denis Pinkas > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) >=20 >=20 >=20 > Hi Denis, >=20 > My =800.02: >=20 > I don't believe there's a significant demand for this. At=20 > least I've not heard of someone who wants this protocol. >=20 > If there is a demand, (not met by SCVP), then I further doubt=20 > that there's sufficient energy to fight all these fights all=20 > over again. (cf. Santosh's mail just now.) >=20 > If there was sufficient energy, then I doubt that the outcome=20 > would be much different to SCVP. >=20 > Finally, if I'm wrong about the above, then whoever it is=20 > that wants whatever it is that SCVP doesn't do and who has=20 > the energy to write new code should of course just use XKMS=20 > and be done with it in a few days rather than in ~2010. >=20 > All-in-all I'm for the WG not taking this on, Cheers, Stephen. >=20 > Denis Pinkas wrote: > >=20 > > I need a simple protocol to delegate the validation of a=20 > certificate=20 > > to a server, to be used in environments where a client does=20 > not need=20 > > to demonstrate to somebody else that it got a given response from a=20 > > server. This implies that the server is fully trusted by the client. > >=20 > > I considered using a profile of SCVP. Remember that the "S"=20 > does not=20 > > mean "Simple", or "Standard" anymore, but "Server-based". > >=20 > > However, the use of CMS to encapsulate everything and allowing to=20 > > optionally sign requests is not needed, and the use of a=20 > subset of the various OIDs is not trivial as well. > >=20 > > I looked at other alternatives, outside the IETF, but they=20 > do not provide an adequate answer.=20 > >=20 > > This proposal is for lightweight clients, hence why it is called=20 > > Lightweight Certificate Validation Protocol (LCVP), like LDAP is=20 > > simpler than DAP. :-) > >=20 > > LCVP only supports a subset of the mandatory requirements=20 > described in=20 > > [RFC3379] for DPV, hence it does not conform to RFC 3379. =20 > LCVP is not=20 > > either a profile of SCVP. > >=20 > > The major differences with SCVP are the following: > >=20 > > - the protocol only supports DPV, i.e. it includes no provisions=20 > > to support Delegated Path Discovery (DPD); > >=20 > > - requests and responses are not signed, since they are=20 > protected=20 > > by TLS, where clients are not authenticated; > >=20 > > - validation is only for one certificate at a time; > >=20 > > - there is no specific parameter in the request to add any=20 > > parameter to a validation policy known by the server.=20 > > =20 > > LCVP allows a client to delegate certificate path validation to a=20 > > trusted server. The path validation (e.g. making sure that none of=20 > > the certificates in the path are revoked) is performed=20 > according to a=20 > > set of rules called a validation policy. It allows=20 > simplification of=20 > > client implementations and only uses of a set of validation=20 > policies=20 > > known by the server. The document defines a protocol that=20 > can be used=20 > > to: > >=20 > > (1) validate one certificate according to one=20 > validation policy, > > (2) query the validation policies supported by an=20 > LCVP server.=20 > >=20 > > At this time, the document is a strawman proposal and has=20 > not yet been implemented. > > There are certainly errors in it and it can certainly be=20 > improved - while keeping it "light". > >=20 > > At this time, the document is an individual draft targeted=20 > for the experimental category. > >=20 > > The document is available at:=20 > > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > >=20 > > The document is proposed to the PKIX WG for consideration=20 > and comments. > >=20 > > If the WG, later on, finds this approach interresting, then the=20 > > document could be re-targeted to the standard track category. > > =20 > > Denis > >=20 > >=20 > >=20 >=20 >=20 From owner-ietf-pkix@mail.imc.org Thu Apr 26 19:05:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD1d-0001wy-83 for pkix-archive@lists.ietf.org; Thu, 26 Apr 2007 19:05:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhD1b-0003Pc-OX for pkix-archive@lists.ietf.org; Thu, 26 Apr 2007 19:05:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLuXns003550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 14:56:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QLuXab003549; Thu, 26 Apr 2007 14:56:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLu9x5003511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Apr 2007 14:56:29 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l3QLu15O001397; Thu, 26 Apr 2007 14:56:01 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:56:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SCVP Question regarding Trust Anchors Date: Thu, 26 Apr 2007 14:55:26 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD370124CE05@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <20070425130525.GN1691@mars.cry.pto> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Question regarding Trust Anchors Thread-Index: AceHSPHrHaOxunSwSnaycKOxNOjpaQBA578Q From: "Hallam-Baker, Phillip" To: "Julien Stern" , "Michael Myers" , "Russ Housley" , X-OriginalArrivalTime: 26 Apr 2007 21:56:01.0669 (UTC) FILETIME=[AE03C350:01C7884D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3QLuTx4003523 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a A certificate can contain information that tells a relying party where to find information to verify the status of information provided by the issuer. The purpose of SCVP is to provide information on the trustworthyness of the information provided by the issuer. It does not make any sense for the issuer to be involved in supplying trust chain validation information and providing trust chain discovery information makes only limited sense. A more appropriate mechanism for this requirement would be to advertise the location of the SCVP server for a domain by means of a DNS SRV record. In practice two records are needed, one for path discovery (which may be asserted by the issuer) and the second for validation (which the relying party needs to choose). My machine knows that it is part of the verisign.com network. So why not deploy DNSSEC and then advertise the location of the local trust chain discovery and validation service via a DNSSEC secured SRV record? That server knows the trust criteria for the domain and can make a useful interrogation of the relying party path discovery server. Alternatively use the DNS to discover your XKMS servers for the same purposes. DNSSEC signed SRV is the way to cut through the Gordian knot of PKI deployment. > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, April 25, 2007 9:05 AM > To: Michael Myers; Russ Housley; ietf-pkix@imc.org > Subject: Re: SCVP Question regarding Trust Anchors > > > On Wed, Apr 25, 2007 at 10:52:17AM +0200, Julien Stern wrote: > > > > Mike, > > > > just check RFC3125 (part of PKIX). > > It defines a validation policy where several trust anchors are > > associated with different inputs. > > The benefit would be to be able to validate such a policy with SCVP. > > A few people let me know that > 1) RFC3125 is part of S/MIME (not PKIX) > 2) It is "Experimental" > > However, it is related to the ETSI technical reports 102038 > and 102272, which define a broader notion of Trust Anchor than SCVP. > > Well, that's for the benefit: being in sync with these TRs > and the Experimental RFC. That being said, as Russ, I can > live with the current situation. It is always possible to > define a local policy that has more complex Trust Anchors... > > -- > Julien > > > -- > > Julien > > > > On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > > > > > Russ, > > > > > > Your explanation suggests "equivalency". > > > I fear for in-band negotiation of that state absent a use-case > > > requirement. > > > > > > Mike > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > > > Sent: Tuesday, April 24, 2007 7:00 AM > > > To: Michael Myers > > > Cc: ietf-pkix@imc.org > > > Subject: RE: SCVP Question regarding Trust Anchors > > > > > > > > > > > > Mike: > > > > > > If a validation policy includes several trust anchors, then it is > > > desirable for the path validation algorithm inputs for > each of these > > > might be different. I can live with the current > structure, but it > > > imposes the restriction that all of the trust anchors associated > > > with the validation policy must be used with the same path > > > validation algorithm inputs. > > > > > > Russ > > > > > > At 07:14 PM 4/23/2007, Michael Myers wrote: > > > >Russ, Julien: > > > > > > > >To what benefit? > > > > > > > >Mike > > > > > > > From owner-ietf-pkix@mail.imc.org Fri Apr 27 08:20:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPRN-0001o6-84 for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 08:20:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPRM-0004OI-OD for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 08:20:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RBH6gk020544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 04:17:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RBH6Bj020543; Fri, 27 Apr 2007 04:17:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RBGdOw020499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 04:17:00 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 12:16:38 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 27 Apr 2007 12:16:37 +0100 From: Stefan Santesson To: Denis Pinkas , pkix Date: Fri, 27 Apr 2007 12:16:29 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDT7TY8P2UxqBGRVCTPzTAXpm0VgEty2mQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RBH1Ov020526 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Denis, > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. This by itself is highly problematic. As you state, this causes your draft to not be a profile of SCVP. Instead it would technically be a 3rd alternative protocol for on-line certificate status checking. It would take extreme reasons to justify creation of such new protocol. I have a hard time seeing this happen unless we actually change SCVP to allow your document to be a profile. But to take back SCVP at this stage to the working group and to re-shape the requirements would also be very hard to motivate and extremely hard to get consensus on. I think you need to focus a lot more on the justification for this work. Not only why it is useful, but why it is so extraordinary important that it motivates any of these measures. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > pkix@mail.imc.org] On Behalf Of Denis Pinkas > Sent: den 20 april 2007 14:19 > To: pkix > Subject: Lightweight Certificate Validation Protocol (LCVP) > > > > I needed a simple protocol to delegate the validation of a certificate > to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does not > mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. > :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows simplification > of client implementations and only uses of a set of validation policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet been > implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > From owner-ietf-pkix@mail.imc.org Fri Apr 27 09:12:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQFY-0008Pm-QO for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 09:12:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQFW-0005d5-50 for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 09:12:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCKAKL027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 05:20:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RCKAj2027776; Fri, 27 Apr 2007 05:20:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCJlJS027720 for ; Fri, 27 Apr 2007 05:20:08 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25656; Fri, 27 Apr 2007 14:24:43 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042714193935:121625 ; Fri, 27 Apr 2007 14:19:39 +0200 Date: Fri, 27 Apr 2007 14:19:37 +0200 From: "Denis Pinkas" To: "Stefan Santesson" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 14:19:39, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 14:19:39, Serialize complete at 27/04/2007 14:19:39 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Stefan, >Denis, > >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >This by itself is highly problematic. I fear that you stopped reading the document, after having read this sentence, otherwise you would have seen the benefits. :-) >As you state, this causes your draft to not be a profile of SCVP. Instead it would technically > be a 3rd alternative protocol for on-line certificate status checking. ??? It is not a third alternative, but a second one. The goal of LCVP is NOT "on-line certificate status checking", but on-line certificate validation. It is not intended to be used as an alternative to OCSP. >It would take extreme reasons to justify creation of such new protocol. The main arguments to use LCVP are: "It is simple and provides more benefits when compared to SCVP". The main argument to use SCVP is: " Why keep it simple, when you can make it complicated ?" >I have a hard time seeing this happen unless we actually change SCVP > to allow your document to be a profile. But to take back SCVP at this stage > to the working group and to re-shape the requirements would also be > very hard to motivate and extremely hard to get consensus on. A lightweight client profile for SCVP would not be realistic without changing SCVP. However, I am NOT in any way asking for any change to SCVP, which is already in the hands of the RFC editor. >I think you need to focus a lot more on the justification for this work. >Not only why it is useful, but why it is so extraordinary important >that it motivates any of these measures. Besides simplicity, the other arguments have already be given in an e-mail sent to Tim. Here there are again: LCVP supports additional parameters, whereas SCVP does not (please read the draft for the details): validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, validationTime allows to support the validation of signer's certificates used with electronic signatures as specified by ETSI, in the case where the signature policy includes a grace period. SCVP is unable to do it, unless adding "yet another" extension. fullSubjectName allows to handle unique names, and thus avoids intentional or deliberate DN collisions. SCVP is unable to do it, unless adding "yet another" extension or asking the client to interpret itself the CertBundle parameter. In the later case, the client is no more a thin client. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. It is for thin clients and allows them to know the intended key usage(s) of the certificate. SCVP is unable to return that information, unless adding "yet other" extensions. BTW, there is a syntax "error" in LCVP that needs to be corrected to make it effectively "lightweight". This error originated from the fact that I copied some of the ASN.1 structures from SCVP. Since SCVP is not lightweight anyway, this may not be a major problem, but the next version of SCVP could possibly take benefit of it. I let you discover it, unless someone else discovers it before you. :-) It will obviously be corrected in the next version to be published. Denis >Stefan Santesson >Senior Program Manager >Windows Security, Standards > > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- >> pkix@mail.imc.org] On Behalf Of Denis Pinkas >> Sent: den 20 april 2007 14:19 >> To: pkix >> Subject: Lightweight Certificate Validation Protocol (LCVP) >> >> >> >> I needed a simple protocol to delegate the validation of a certificate >> to a server, >> to be used in environments where a client does not need to demonstrate >> to somebody else that it got a given response from a server. This >> implies >> that the server is fully trusted by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does not >> mean "Simple", >> or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests >> is not needed, and the use of a subset of the various OIDs is not >> trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight >> Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. >> :-) >> >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to >> a trusted server. The path validation (e.g. making sure that none >> of the certificates in the path are revoked) is performed according >> to a set of rules called a validation policy. It allows simplification >> of client implementations and only uses of a set of validation policies >> known by the server. The document defines a protocol >> that can be used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet been >> implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be >> re-targeted to the standard track category. >> >> Denis >> Regards, Denis Pinkas From owner-ietf-pkix@mail.imc.org Fri Apr 27 09:37:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQdZ-0007E3-QL for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 09:37:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQdW-0004jp-Ie for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 09:37:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCbTpP030629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 05:37:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RCbTQX030628; Fri, 27 Apr 2007 05:37:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCb7TZ030608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 05:37:28 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 13:37:06 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 27 Apr 2007 13:37:06 +0100 From: Stefan Santesson To: Denis Pinkas CC: pkix Date: Fri, 27 Apr 2007 13:36:58 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceIxlncDPnNRRvaT1SZVDgCCzLKjgAAImFA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RCbSTY030623 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Denis, I'm trying to bring this discussion up above the technical details and features. Listing of technical features does not stand as a motivation for doing the job. You have to explain why these features are important to the industry and why solving the same problem can't be done without the rather extreme measure you propose. If you protocol was covering new areas of standardization, you would be required to do less of motivation than, as now is the case, your work overlaps with current standards. This would be the third alternative for on-line certificate status checking: - OCSP - SCVP - LCVP Quote: > LCVP supports additional parameters, whereas SCVP does not (please > read the draft for the details): So we would have a "Lightweight" version of a protocol that is richer than the standard protocol. Good or bad, that logic can also be a hard sell. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Sent: den 27 april 2007 14:20 > To: Stefan Santesson > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > > Stefan, > > >Denis, > > > >> LCVP only supports a subset of the mandatory requirements described > in > >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > >> not either a profile of SCVP. > > >This by itself is highly problematic. > > I fear that you stopped reading the document, after having read this > sentence, > otherwise you would have seen the benefits. :-) > > >As you state, this causes your draft to not be a profile of SCVP. > Instead it would technically > > be a 3rd alternative protocol for on-line certificate status > checking. > > ??? It is not a third alternative, but a second one. > > The goal of LCVP is NOT "on-line certificate status checking", but on- > line certificate validation. > It is not intended to be used as an alternative to OCSP. > > >It would take extreme reasons to justify creation of such new > protocol. > > The main arguments to use LCVP are: > "It is simple and provides more benefits when compared to SCVP". > > The main argument to use SCVP is: > " Why keep it simple, when you can make it complicated ?" > > >I have a hard time seeing this happen unless we actually change SCVP > > to allow your document to be a profile. But to take back SCVP at this > stage > > to the working group and to re-shape the requirements would also be > > very hard to motivate and extremely hard to get consensus on. > > A lightweight client profile for SCVP would not be realistic without > changing SCVP. > However, I am NOT in any way asking for any change to SCVP, which is > already > in the hands of the RFC editor. > > >I think you need to focus a lot more on the justification for this > work. > >Not only why it is useful, but why it is so extraordinary important > >that it motivates any of these measures. > > Besides simplicity, the other arguments have already be given in an e- > mail sent to Tim. > Here there are again: > > LCVP supports additional parameters, whereas SCVP does not (please > read the draft for the details): > > validationTime GeneralizedTime, > fullSubjectName FullSubjectName, > keyUsage KeyUsage OPTIONAL, > extKeyUsage ExtKeyUsageSyntax OPTIONAL, > > validationTime allows to support the validation of signer's > certificates used with electronic signatures > as specified by ETSI, in the case where the signature policy includes a > grace period. > > SCVP is unable to do it, unless adding "yet another" extension. > > fullSubjectName allows to handle unique names, and thus avoids > intentional or deliberate DN collisions. > > SCVP is unable to do it, unless adding "yet another" extension or > asking the client > to interpret itself the CertBundle parameter. In the later case, the > client is no more a thin client. > > keyUsage and extKeyUsage simply allow a application to know these > parameters > without the need to process the certificate. It is for thin clients and > allows them to know > the intended key usage(s) of the certificate. > > SCVP is unable to return that information, unless adding "yet other" > extensions. > > BTW, there is a syntax "error" in LCVP that needs to be corrected to > make it effectively "lightweight". > This error originated from the fact that I copied some of the ASN.1 > structures from SCVP. Since > SCVP is not lightweight anyway, this may not be a major problem, but > the next version of SCVP > could possibly take benefit of it. > > I let you discover it, unless someone else discovers it before you. :-) > > It will obviously be corrected in the next version to be published. > > Denis > > >Stefan Santesson > >Senior Program Manager > >Windows Security, Standards > > > > > >> -----Original Message----- > >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > >> pkix@mail.imc.org] On Behalf Of Denis Pinkas > >> Sent: den 20 april 2007 14:19 > >> To: pkix > >> Subject: Lightweight Certificate Validation Protocol (LCVP) > >> > >> > >> > >> I needed a simple protocol to delegate the validation of a > certificate > >> to a server, > >> to be used in environments where a client does not need to > demonstrate > >> to somebody else that it got a given response from a server. This > >> implies > >> that the server is fully trusted by the client. > >> > >> I considered using a profile of SCVP. Remember that the "S" does not > >> mean "Simple", > >> or "Standard" anymore, but "Server-based". > >> > >> However, the use of CMS to encapsulate everything and allowing to > >> optionally sign requests > >> is not needed, and the use of a subset of the various OIDs is not > >> trivial as well. > >> > >> I looked at other alternatives, outside the IETF, but they do not > >> provide an adequate answer. > >> > >> This proposal is for lightweight clients, hence why it is called > >> Lightweight > >> Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. > >> :-) > >> > >> LCVP only supports a subset of the mandatory requirements described > in > >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > >> not either a profile of SCVP. > >> > >> The major differences with SCVP are the following: > >> > >> - the protocol only supports DPV, i.e. it includes no provisions > >> to support Delegated Path Discovery (DPD); > >> > >> - requests and responses are not signed, since they are protected > >> by TLS, where clients are not authenticated; > >> > >> - validation is only for one certificate at a time; > >> > >> - there is no specific parameter in the request to add any > >> parameter to a validation policy known by the server. > >> > >> LCVP allows a client to delegate certificate path validation to > >> a trusted server. The path validation (e.g. making sure that none > >> of the certificates in the path are revoked) is performed according > >> to a set of rules called a validation policy. It allows > simplification > >> of client implementations and only uses of a set of validation > policies > >> known by the server. The document defines a protocol > >> that can be used to: > >> > >> (1) validate one certificate according to one validation > policy, > >> (2) query the validation policies supported by an LCVP server. > >> > >> At this time, the document is a strawman proposal and has not yet > been > >> implemented. > >> There are certainly errors in it and it can certainly be improved - > >> while keeping it "light". > >> > >> At this time, the document is an individual draft targeted for the > >> experimental category. > >> > >> The document is available at: > >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > >> > >> The document is proposed to the PKIX WG for consideration and > comments. > >> > >> If the WG, later on, finds this approach interresting, then the > >> document could be > >> re-targeted to the standard track category. > >> > >> Denis > >> > > Regards, > > Denis Pinkas > > From owner-ietf-pkix@mail.imc.org Fri Apr 27 10:07:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhR73-00047H-HK for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 10:07:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhR72-0004Hv-Rh for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 10:07:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RD7eTO033971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 06:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RD7e7c033970; Fri, 27 Apr 2007 06:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RD7abD033961 for ; Fri, 27 Apr 2007 06:07:38 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA40488; Fri, 27 Apr 2007 15:12:36 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042715073145:123445 ; Fri, 27 Apr 2007 15:07:31 +0200 Date: Fri, 27 Apr 2007 15:07:29 +0200 From: "Denis Pinkas" To: "Stefan Santesson" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 15:07:31, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 15:07:32, Serialize complete at 27/04/2007 15:07:32 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Stefan, >Denis, > >I'm trying to bring this discussion up above the technical details and features. Listing of technical features does not stand as a motivation for doing the job. >You have to explain why these features are important to the industry and why solving the same problem can't be done without the rather extreme measure you propose. If you protocol was covering new areas of standardization, you would be required to do less of motivation than, as now is the case, your work overlaps with current standards. > >This would be the third alternative for on-line certificate status checking: >- OCSP >- SCVP >- LCVP I fear you have not fully read my e-mail. Please re-read carefully. >Quote: >> LCVP supports additional parameters, whereas SCVP does not (please >> read the draft for the details): > >So we would have a "Lightweight" version of a protocol that is richer than the standard protocol. LCVP is a "Light" version of CVP, not a light version of a "Server-based Validation Certificate Protocol (alias SCVP)". >Good or bad, that logic can also be a hard sell. If you take the time to read the document, you will get the answers to most of your questions. If there are some points that are not well explained, I may help. Denis > > >Stefan Santesson >Senior Program Manager >Windows Security, Standards > > >> -----Original Message----- >> From: Denis Pinkas [mailto:denis.pinkas@bull.net] >> Sent: den 27 april 2007 14:20 >> To: Stefan Santesson >> Cc: pkix >> Subject: Re: Lightweight Certificate Validation Protocol (LCVP) >> >> Stefan, >> >> >Denis, >> > >> >> LCVP only supports a subset of the mandatory requirements described >> in >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> >> not either a profile of SCVP. >> >> >This by itself is highly problematic. >> >> I fear that you stopped reading the document, after having read this >> sentence, >> otherwise you would have seen the benefits. :-) >> >> >As you state, this causes your draft to not be a profile of SCVP. >> Instead it would technically >> > be a 3rd alternative protocol for on-line certificate status >> checking. >> >> ??? It is not a third alternative, but a second one. >> >> The goal of LCVP is NOT "on-line certificate status checking", but on- >> line certificate validation. >> It is not intended to be used as an alternative to OCSP. >> >> >It would take extreme reasons to justify creation of such new >> protocol. >> >> The main arguments to use LCVP are: >> "It is simple and provides more benefits when compared to SCVP". >> >> The main argument to use SCVP is: >> " Why keep it simple, when you can make it complicated ?" >> >> >I have a hard time seeing this happen unless we actually change SCVP >> > to allow your document to be a profile. But to take back SCVP at this >> stage >> > to the working group and to re-shape the requirements would also be >> > very hard to motivate and extremely hard to get consensus on. >> >> A lightweight client profile for SCVP would not be realistic without >> changing SCVP. >> However, I am NOT in any way asking for any change to SCVP, which is >> already >> in the hands of the RFC editor. >> >> >I think you need to focus a lot more on the justification for this >> work. >> >Not only why it is useful, but why it is so extraordinary important >> >that it motivates any of these measures. >> >> Besides simplicity, the other arguments have already be given in an e- >> mail sent to Tim. >> Here there are again: >> >> LCVP supports additional parameters, whereas SCVP does not (please >> read the draft for the details): >> >> validationTime GeneralizedTime, >> fullSubjectName FullSubjectName, >> keyUsage KeyUsage OPTIONAL, >> extKeyUsage ExtKeyUsageSyntax OPTIONAL, >> >> validationTime allows to support the validation of signer's >> certificates used with electronic signatures >> as specified by ETSI, in the case where the signature policy includes a >> grace period. >> >> SCVP is unable to do it, unless adding "yet another" extension. >> >> fullSubjectName allows to handle unique names, and thus avoids >> intentional or deliberate DN collisions. >> >> SCVP is unable to do it, unless adding "yet another" extension or >> asking the client >> to interpret itself the CertBundle parameter. In the later case, the >> client is no more a thin client. >> >> keyUsage and extKeyUsage simply allow a application to know these >> parameters >> without the need to process the certificate. It is for thin clients and >> allows them to know >> the intended key usage(s) of the certificate. >> >> SCVP is unable to return that information, unless adding "yet other" >> extensions. >> >> BTW, there is a syntax "error" in LCVP that needs to be corrected to >> make it effectively "lightweight". >> This error originated from the fact that I copied some of the ASN.1 >> structures from SCVP. Since >> SCVP is not lightweight anyway, this may not be a major problem, but >> the next version of SCVP >> could possibly take benefit of it. >> >> I let you discover it, unless someone else discovers it before you. :-) >> >> It will obviously be corrected in the next version to be published. >> >> Denis >> >> >Stefan Santesson >> >Senior Program Manager >> >Windows Security, Standards >> > >> > >> >> -----Original Message----- >> >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- >> >> pkix@mail.imc.org] On Behalf Of Denis Pinkas >> >> Sent: den 20 april 2007 14:19 >> >> To: pkix >> >> Subject: Lightweight Certificate Validation Protocol (LCVP) >> >> >> >> >> >> >> >> I needed a simple protocol to delegate the validation of a >> certificate >> >> to a server, >> >> to be used in environments where a client does not need to >> demonstrate >> >> to somebody else that it got a given response from a server. This >> >> implies >> >> that the server is fully trusted by the client. >> >> >> >> I considered using a profile of SCVP. Remember that the "S" does not >> >> mean "Simple", >> >> or "Standard" anymore, but "Server-based". >> >> >> >> However, the use of CMS to encapsulate everything and allowing to >> >> optionally sign requests >> >> is not needed, and the use of a subset of the various OIDs is not >> >> trivial as well. >> >> >> >> I looked at other alternatives, outside the IETF, but they do not >> >> provide an adequate answer. >> >> >> >> This proposal is for lightweight clients, hence why it is called >> >> Lightweight >> >> Certificate Validation Protocol (LCVP), like LDAP is simpler than >> DAP. >> >> :-) >> >> >> >> LCVP only supports a subset of the mandatory requirements described >> in >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> >> not either a profile of SCVP. >> >> >> >> The major differences with SCVP are the following: >> >> >> >> - the protocol only supports DPV, i.e. it includes no provisions >> >> to support Delegated Path Discovery (DPD); >> >> >> >> - requests and responses are not signed, since they are protected >> >> by TLS, where clients are not authenticated; >> >> >> >> - validation is only for one certificate at a time; >> >> >> >> - there is no specific parameter in the request to add any >> >> parameter to a validation policy known by the server. >> >> >> >> LCVP allows a client to delegate certificate path validation to >> >> a trusted server. The path validation (e.g. making sure that none >> >> of the certificates in the path are revoked) is performed according >> >> to a set of rules called a validation policy. It allows >> simplification >> >> of client implementations and only uses of a set of validation >> policies >> >> known by the server. The document defines a protocol >> >> that can be used to: >> >> >> >> (1) validate one certificate according to one validation >> policy, >> >> (2) query the validation policies supported by an LCVP server. >> >> >> >> At this time, the document is a strawman proposal and has not yet >> been >> >> implemented. >> >> There are certainly errors in it and it can certainly be improved - >> >> while keeping it "light". >> >> >> >> At this time, the document is an individual draft targeted for the >> >> experimental category. >> >> >> >> The document is available at: >> >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> >> >> If the WG, later on, finds this approach interresting, then the >> >> document could be >> >> re-targeted to the standard track category. >> >> >> >> Denis >> >> >> >> Regards, >> >> Denis Pinkas >> >> Regards, Denis Pinkas From owner-ietf-pkix@mail.imc.org Fri Apr 27 13:58:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUiM-0007JY-KK for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 13:58:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUiL-0006zi-Sv for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 13:58:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHBavi057932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:11:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHBauH057931; Fri, 27 Apr 2007 10:11:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHBB3P057899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 10:11:32 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 18:11:10 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 27 Apr 2007 18:11:10 +0100 From: Stefan Santesson To: Denis Pinkas CC: pkix Date: Fri, 27 Apr 2007 18:11:02 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceIzQgjVWKgQKasQMOJMRyoTS9KQQAHKnCQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RHBX3O057922 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Denis, I have read your e-mail and your draft, at least a majority of it. It does not provide the answers I need. I need you to motivate why we need yet another protocol for on-line status checking. A "Read the document" reply is not sufficient for me. I don't want a list of technical features you provide. I want an analysis of the impact of the industry. Personally I'm totally against writing yet another protocol for this, and you have so far not been able to convince me. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Sent: den 27 april 2007 15:07 > To: Stefan Santesson > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > > Stefan, > > >Denis, > > > >I'm trying to bring this discussion up above the technical details and > features. Listing of technical features does not stand as a motivation > for doing the job. > >You have to explain why these features are important to the industry > and why solving the same problem can't be done without the rather > extreme measure you propose. If you protocol was covering new areas of > standardization, you would be required to do less of motivation than, > as now is the case, your work overlaps with current standards. > > > >This would be the third alternative for on-line certificate status > checking: > >- OCSP > >- SCVP > >- LCVP > > I fear you have not fully read my e-mail. Please re-read carefully. > > >Quote: > >> LCVP supports additional parameters, whereas SCVP does not (please > >> read the draft for the details): > > > >So we would have a "Lightweight" version of a protocol that is richer > than the standard protocol. > > LCVP is a "Light" version of CVP, not a light version of a "Server- > based Validation Certificate Protocol > (alias SCVP)". > > >Good or bad, that logic can also be a hard sell. > > If you take the time to read the document, you will get the answers to > most of your questions. > If there are some points that are not well explained, I may help. > > Denis > > > > > > >Stefan Santesson > >Senior Program Manager > >Windows Security, Standards > > > > > >> -----Original Message----- > >> From: Denis Pinkas [mailto:denis.pinkas@bull.net] > >> Sent: den 27 april 2007 14:20 > >> To: Stefan Santesson > >> Cc: pkix > >> Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > >> > >> Stefan, > >> > >> >Denis, > >> > > >> >> LCVP only supports a subset of the mandatory requirements > described > >> in > >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP > is > >> >> not either a profile of SCVP. > >> > >> >This by itself is highly problematic. > >> > >> I fear that you stopped reading the document, after having read this > >> sentence, > >> otherwise you would have seen the benefits. :-) > >> > >> >As you state, this causes your draft to not be a profile of SCVP. > >> Instead it would technically > >> > be a 3rd alternative protocol for on-line certificate status > >> checking. > >> > >> ??? It is not a third alternative, but a second one. > >> > >> The goal of LCVP is NOT "on-line certificate status checking", but > on- > >> line certificate validation. > >> It is not intended to be used as an alternative to OCSP. > >> > >> >It would take extreme reasons to justify creation of such new > >> protocol. > >> > >> The main arguments to use LCVP are: > >> "It is simple and provides more benefits when compared to SCVP". > >> > >> The main argument to use SCVP is: > >> " Why keep it simple, when you can make it complicated ?" > >> > >> >I have a hard time seeing this happen unless we actually change > SCVP > >> > to allow your document to be a profile. But to take back SCVP at > this > >> stage > >> > to the working group and to re-shape the requirements would also > be > >> > very hard to motivate and extremely hard to get consensus on. > >> > >> A lightweight client profile for SCVP would not be realistic without > >> changing SCVP. > >> However, I am NOT in any way asking for any change to SCVP, which is > >> already > >> in the hands of the RFC editor. > >> > >> >I think you need to focus a lot more on the justification for this > >> work. > >> >Not only why it is useful, but why it is so extraordinary important > >> >that it motivates any of these measures. > >> > >> Besides simplicity, the other arguments have already be given in an > e- > >> mail sent to Tim. > >> Here there are again: > >> > >> LCVP supports additional parameters, whereas SCVP does not (please > >> read the draft for the details): > >> > >> validationTime GeneralizedTime, > >> fullSubjectName FullSubjectName, > >> keyUsage KeyUsage > OPTIONAL, > >> extKeyUsage ExtKeyUsageSyntax OPTIONAL, > >> > >> validationTime allows to support the validation of signer's > >> certificates used with electronic signatures > >> as specified by ETSI, in the case where the signature policy > includes a > >> grace period. > >> > >> SCVP is unable to do it, unless adding "yet another" extension. > >> > >> fullSubjectName allows to handle unique names, and thus avoids > >> intentional or deliberate DN collisions. > >> > >> SCVP is unable to do it, unless adding "yet another" extension or > >> asking the client > >> to interpret itself the CertBundle parameter. In the later case, the > >> client is no more a thin client. > >> > >> keyUsage and extKeyUsage simply allow a application to know these > >> parameters > >> without the need to process the certificate. It is for thin clients > and > >> allows them to know > >> the intended key usage(s) of the certificate. > >> > >> SCVP is unable to return that information, unless adding "yet other" > >> extensions. > >> > >> BTW, there is a syntax "error" in LCVP that needs to be corrected to > >> make it effectively "lightweight". > >> This error originated from the fact that I copied some of the ASN.1 > >> structures from SCVP. Since > >> SCVP is not lightweight anyway, this may not be a major problem, but > >> the next version of SCVP > >> could possibly take benefit of it. > >> > >> I let you discover it, unless someone else discovers it before you. > :-) > >> > >> It will obviously be corrected in the next version to be published. > >> > >> Denis > >> > >> >Stefan Santesson > >> >Senior Program Manager > >> >Windows Security, Standards > >> > > >> > > >> >> -----Original Message----- > >> >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > >> >> pkix@mail.imc.org] On Behalf Of Denis Pinkas > >> >> Sent: den 20 april 2007 14:19 > >> >> To: pkix > >> >> Subject: Lightweight Certificate Validation Protocol (LCVP) > >> >> > >> >> > >> >> > >> >> I needed a simple protocol to delegate the validation of a > >> certificate > >> >> to a server, > >> >> to be used in environments where a client does not need to > >> demonstrate > >> >> to somebody else that it got a given response from a server. This > >> >> implies > >> >> that the server is fully trusted by the client. > >> >> > >> >> I considered using a profile of SCVP. Remember that the "S" does > not > >> >> mean "Simple", > >> >> or "Standard" anymore, but "Server-based". > >> >> > >> >> However, the use of CMS to encapsulate everything and allowing to > >> >> optionally sign requests > >> >> is not needed, and the use of a subset of the various OIDs is not > >> >> trivial as well. > >> >> > >> >> I looked at other alternatives, outside the IETF, but they do not > >> >> provide an adequate answer. > >> >> > >> >> This proposal is for lightweight clients, hence why it is called > >> >> Lightweight > >> >> Certificate Validation Protocol (LCVP), like LDAP is simpler than > >> DAP. > >> >> :-) > >> >> > >> >> LCVP only supports a subset of the mandatory requirements > described > >> in > >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP > is > >> >> not either a profile of SCVP. > >> >> > >> >> The major differences with SCVP are the following: > >> >> > >> >> - the protocol only supports DPV, i.e. it includes no > provisions > >> >> to support Delegated Path Discovery (DPD); > >> >> > >> >> - requests and responses are not signed, since they are > protected > >> >> by TLS, where clients are not authenticated; > >> >> > >> >> - validation is only for one certificate at a time; > >> >> > >> >> - there is no specific parameter in the request to add any > >> >> parameter to a validation policy known by the server. > >> >> > >> >> LCVP allows a client to delegate certificate path validation to > >> >> a trusted server. The path validation (e.g. making sure that > none > >> >> of the certificates in the path are revoked) is performed > according > >> >> to a set of rules called a validation policy. It allows > >> simplification > >> >> of client implementations and only uses of a set of validation > >> policies > >> >> known by the server. The document defines a protocol > >> >> that can be used to: > >> >> > >> >> (1) validate one certificate according to one validation > >> policy, > >> >> (2) query the validation policies supported by an LCVP > server. > >> >> > >> >> At this time, the document is a strawman proposal and has not yet > >> been > >> >> implemented. > >> >> There are certainly errors in it and it can certainly be improved > - > >> >> while keeping it "light". > >> >> > >> >> At this time, the document is an individual draft targeted for > the > >> >> experimental category. > >> >> > >> >> The document is available at: > >> >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > >> >> > >> >> The document is proposed to the PKIX WG for consideration and > >> comments. > >> >> > >> >> If the WG, later on, finds this approach interresting, then the > >> >> document could be > >> >> re-targeted to the standard track category. > >> >> > >> >> Denis > >> >> > >> > >> Regards, > >> > >> Denis Pinkas > >> > >> > > Regards, > > Denis Pinkas > > From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:20:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhV3s-00088u-PO for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:20:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhV3q-0005eJ-3z for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:20:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHcvXR058927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:38:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHcuMY058926; Fri, 27 Apr 2007 10:38:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHcWnt058912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 10:38:55 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 18:38:32 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 27 Apr 2007 18:38:31 +0100 From: Stefan Santesson To: Stefan Santesson , Sam Hartman , Michael Myers CC: "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Date: Fri, 27 Apr 2007 18:38:23 +0100 Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Topic: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Index: AcdsXovylPq1PkzrQG66Ae6cnmfEuQAN2k7gBxcM2DA= Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RHcuns058920 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 The discussion about SRVSAN applicability statement is stuck. And I would like to unstuck it. Do you think it is reasonable for an alt name RFC to state that the name MUST not be used in any protocol unless specifically allowed? Please see my e-mail below for an example where I think it would be unreasonable to make such restriction. If such restriction would be imposed, how should it be formulated? I personally don't think it can be reasonably formulated. When we have this issue sorted, I will go ahead and post an updated draft. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson > Sent: den 23 mars 2007 01:18 > To: 'Sam Hartman'; Michael Myers > Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; 'Russ Housley' > Subject: SRV SAN applicability statement - Was RE: Requested changes to > SRV SAN > > After some discussions face to face, it is clear to me that I have not > been successful in explaining my point. > > From what I have understood, Sam wants us to do is to say something > like the following: > The srv subjectAltName name form MUST NOT be used to validate the > identity of any entity unless the protocol within which the > identification is done explicitly specifies and permits the use of this > name form. > > Sam has told me that it would not be sufficient to require the use of > SRV SAN to be consistent with the protocol. It MUST be explicitly > allowed. > > > The rest of this mail intends to explain why this is unreasonable and > doesn't work. > I will first explain the general use case and then make an explicit > example. > > General use case > > 1) Client seek a service based on service name and domain. > 2) Client makes a query to the DNS server and receives a list of > suitable host names and their address. > 3) The Client contact one of the hosts suggested by DNS > 4) The client receive the certificate of that host > 5) The client verifies the identity of the host and determine if this > is a valid host for the requested service. > > Note that the information from the certificate is NOT used to construct > any DNS query. It is only used to validate the service host. > Note also that for this to happen at all, the service type asked for > MUST be supported by the DNS or you would not reach beyond step 2. So > for us to even consider the certificate in this case, we have an > automatic guarantee that at least the DNS supports this service name as > basis for host lookup. Thus it should already have passed the > applicability statement of RFC 2782. > > > Lets now take a specific case. > > 1) Client seeks the LDAP server of example.com > 2) Client makes a dns query for _ldap._tcp.example.com > 3a) Client receives the following list of suitable hosts: > ldap1.example.com and ldap2.example.com > 3b) Client contact ldap://ldap1.example.com and initiates a TLS session > according to RFC 4513 > 4) Client receives the server certificate from the TLS initialization. > 5) Client verifies the server certificate according to RFC 4513. > > Now. This server certificate has a subject DN with a number of > attributes that does not mean anything to the client. > The server certificate contains the dnsName SAN with the value > ldap1.example.com > The server certificate contains a SRV SAN otherName with the value > _ldap.example.com > > Through the dnsName SAN, the client will be assured that it is in fact > talking to the host ldap1.example.com. But unless the client can fully > trust the DNS, the client still don't know if this host is authorized > to provide the ldap service for this domain. If the DNS was spoofed, > the client could be talking to the wrong server. > > But, here the CA has also bound the key to the srv name > (_ldap.example.com). Through this name the client has an assertion from > the CA that this host is actually an authorized ldap server for the > example.com domain. > > Must the client disregard from this information. YES according to Sam > (If I understand him right). > > Because RFC 4513 does not explicitly mention and approve use of the SRV > SAN name form (And how could it, this name form is not an RFC yet) > > RFC 4513 states: > > 3.1.3. Server Identity Check > > In order to prevent man-in-the-middle attacks, the client MUST > verify > the server's identity (as presented in the server's Certificate > message). In this section, the client's understanding of the > server's identity (typically the identity used to establish the > transport connection) is called the "reference identity". > > The client determines the type (e.g., DNS name or IP address) of the > reference identity and performs a comparison between the reference > identity and each subjectAltName value of the corresponding type > until a match is produced. Once a match is produced, the server's > identity has been verified, and the server identity check is > complete. > > > This text is 100% consistent with using srv san otherName even though > it is not explicitly mentioned. > > So we have a case where use of DNS lookup for a service type that > established and supported by DNS servers as well as having an IANA > registered service name. We have a security protocol that provides > freedom for clients to define what a "reference identity" is. Yet we > would not be allowed to use the only name in the certificate that gives > the client what it needs to verify the host. > > That does not make any sense to me at all. > > Why is it necessary to update RFC 4513 to make it legal to use this > name form when its use is already consistent with the standard? > What if I have a privately defined SAN otherName, can I use that? I > think RFC 4513 clearly allows that. > What if that privately defined otherName contains exactly the same info > as our SRV SAN, can I use it? > > Please clarify if I have understood you wrong Sam. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 22 mars 2007 09:46 > > To: Michael Myers > > Cc: Stefan Santesson; ietf-pkix@imc.org; Stephen Kent; Tim Polk > > Subject: Re: Requested changes to SRV SAN > > > > >>>>> "Michael" == Michael Myers writes: > > > > >> Sam Hartman has a discuss requiring this document to say that > > >> this name form MUST NOT be used unless explicitly allowed by > > >> the protocol being used. > > > > Michael> Because . . . ? > > > > Two reasons. first, the SRV DNS RR definition has a very strong > > applicability statement. SRV records cannot be used except when a > > protocol specifically defines their use. This increases > > interoperability. You don't want some domains using MX to find mail > > servers and others using _smtp._tcp.domain SRV records. We should be > > consistent with the SRV spec wehn definining name types for use with > > those records. > > > > Second, the underlying interoperability concerns for this name type > > apply the are the same as for SRV records. We've had enough trouble > > with interoperability concerns caused by CN and email address in the > > subject name vs subjectAltName choices. We don't want to introduce > > other situations where there are multiple ways of naming the same > > entity without need to do so. > > > > --Sam From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:20:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhV3s-00088y-QB for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:20:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhV3q-0005el-O6 for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:20:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHddHK058960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:39:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHddpO058959; Fri, 27 Apr 2007 10:39:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHdHDW058937 for ; Fri, 27 Apr 2007 10:39:38 -0700 (MST) (envelope-from shitchings@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Fri, 27 Apr 2007 13:38:58 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01B3_01C788B8.433C3E10" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) thread-index: AceGeUnya1PIh0LESQSwo2yFejxeEQCeQvpA References: From: "Seth Hitchings" To: "Denis Pinkas" , "Tim Polk" Cc: "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 This is a multi-part message in MIME format. ------=_NextPart_000_01B3_01C788B8.433C3E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Denis, If SCVP did not require clients to support protected responses, would you still find sufficient need to develop a new protocol? I think that there's some room for clarification as to whether a response received via a protected transport mechanism is in fact protected and therefore shouldn't require CMS encapsulation. I'm not advocating changing SCVP at this stage, mind you. Seth -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, April 24, 2007 1:32 AM To: Tim Polk Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Tim, Thank you for your time for reviewing LCVP. See my responses below. >Denis, > >I finally found some time this weekend to review the LCVP >specification. I thought it was important to avoid snap judgements. >After reviewing the specification, I do not see a justification for >pursuing this document. > >If we consider this specification from a DPV client viewpoint, there >are very few differences between an LCVP client and the minimal SCVP >client. You identify the following differences (my numbering for >clarity): > > (1) the protocol only supports DPV, i.e. it includes no provision >to support Delegated Path Discovery (DPD); > (2) requests and responses are not signed, since they are protected >by TLS, where clients are not authenticated; > (3) validation is only for one certificate at a time; > (4) there is no specific parameter in the request to add any >parameter to a validation policy known by the server. > >However, this overstates the differences. (1) SCVP implementations are >not required to implement both DPD and DPV. (2) SCVP clients and >servers MUST support protected (e.g., signed) responses, but the client >may choose to use TLS as a protected transport to protect the >responses. This single argument (i.e. SCVP clients and servers MUST support protected (e.g., signed) responses) illustrates why it not make sense to mandate such a support when only transport layer security is being used. This means it is not effective to profile SCVP to only fulfill the requirements addressed by LCVP. >(3) Clients are not only permitted to submit requests one certificate >at a time, conforming client implementations are not required to >support multi-certificate requests. (4) As in 3, modifying the >validation policy need not be supported by conforming clients. > >In short, LCVP does not provide functionality that is unavailable in >SCVP. This is incorrect. Please take a look at: validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, The meaning of producedAt in SCVP is different from the meaning of validationTime in LCVP. LCVP with this parameter may support the validation of certificates used for non repudiation puroposes, whereas SCVP can't. See the explanations about the grace period fullSubjectName allows to handle unique names, whereas SCVP can't. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. Of course, using four new OIDs it would be possible to expand SCVP to support these parameters, but it wan't be as simple as in LCVP. >While LCVP's ASN.1 appears less complicated, I am glad you acknowlege the fact that LCVP is simpler than SCVP. > the data structures generated by minimally conforming SCVP DPV-only >client implementations appear to have similar levels of complexity. I do not think so. Beside the unneeded complexity of the response which results from the use of CMS: ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } there is a lot of OIDs to manage. Another example of overcomplexity is the mandatory use of the following OID { id-svp 1 } to specify the default validation policy, while LCVP may simply omit the parameter: valPolicyRef ValPolicyRef OPTIONAL, Furthermore, where LCVP allows any default validation policy, in SCVP : " The default validation policy MUST use the basic validation algorithm as its default validation algorithm". There is a French common saying, which states roughly the following: " Why keep it simple, when you can make it complicated ?" It would perfectly apply to an SCVP profile (if any was possible). >I cannot see any reason to pursue a new DPV protocol that ignores the >requirements established in 3379 within the IETF. It does not ignore them, but does not take all of them. > I can see the >rationale for a lightweight client profile for SCVP, as suggested by >others on this list, to demonstrate how simple an SCVP client can >actually be. A lightweight client profile for SCVP is not realistic without changing SCVP. SCVP is already in the hands of the RFC editor for publication as an RFC. Denis >Thanks, > >Tim Polk > >On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > >> >> >> I needed a simple protocol to delegate the validation of a >> certificate to a server, to be used in environments where a client >> does not need to demonstrate to somebody else that it got a given >> response from a server. This implies that the server is fully trusted >> by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does not >> mean "Simple", or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests is not needed, and the use of a subset of >> the various OIDs is not trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight Certificate Validation Protocol (LCVP), like LDAP is >> simpler than DAP. :-) >> >> LCVP only supports a subset of the mandatory requirements described >> in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to a >> trusted server. The path validation (e.g. making sure that none of >> the certificates in the path are revoked) is performed according to a >> set of rules called a validation policy. It allows simplification of >> client implementations and only uses of a set of validation policies >> known by the server. The document defines a protocol that can be >> used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet >> been implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be re-targeted to the standard track category. >> >> Denis >> >> > > Regards, Denis Pinkas ------=_NextPart_000_01B3_01C788B8.433C3E10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3DCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA5IwggL7oAMCAQICAgCiMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNzE0NDgzNloXDTA3 MDkyNjE0NDgzNlowajELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEXMBUG A1UEAxMOU2V0aCBIaXRjaGluZ3MxKDAmBgkqhkiG9w0BCQEWGXNoaXRjaGluZ3NAY29yZXN0cmVl dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDULuw99zAAo0bVVJO8Muclrezh TKZpRgvLmNtEMSgZQHezFesdIs3MM1V4dT7rmf8JIm9ugAZrYrpOK79402QQvFhY4gVaBkPQflR3 u/yKvVO8BWcKeaCZAu9SiHW9MqMMSkh+qX8b3Var9T/6clbxMeCx37wByra6uvAPKfZUmnTERMqF IybXd5rkejV6Sn3Madu4iYh3FWd8sQEWV2Pqpz9IBjMRzXOKfFEPbopvGOCiXtnyzTiz00yh8JDe UZWf9K0jhBG7u8KeebWyxfANPbgnn89lCFZjkAz0aEhJpXxwsWqnjH1S6IfvnWxu59J5pecAAizr +iKDhaiwaBPZAgMBAAGjgdowgdcwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0 dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwJAYDVR0RBB0wG4EZc2hp dGNoaW5nc0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBA BggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJl ZXQuY29tLzANBgkqhkiG9w0BAQUFAAOBgQB0vJkV8SBdmz9K5S+Tw+0o1G08vfYQRDYcOzyoriV7 gZi8/vmnaUL7GMYRaEv3ei7LyLDXIm2FJSH5bZACEIR5Jhl5QWByV6F8EdlOYRUKn/PQgNhqWH9q B6I+Sn/Tqfgtm3ssboe6yJFBIQnk9S3WmIxHhGCPptQ0fvM8jy9BwzGCAx0wggMZAgEBMFgwUjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVl dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCiMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyNzE3Mzg1OFowIwYJKoZIhvcNAQkEMRYE FBLpOEElt/6LaSpte4DICeZDS7ohMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMGcGCSsGAQQBgjcQBDFaMFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0Nv cmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkC AgCiMGkGCyqGSIb3DQEJEAILMVqgWDBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVl dCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICAKIwDQYJ KoZIhvcNAQEBBQAEggEAFwiHUcb0nSQkiqHqqNo6VsbiCbl+4uYngx1pvaw80+PH3EBlZCqEDae6 6QLL7rMa7qRtSiwanKRbAjtXrByHQlYAA4fVXF+z7TN1iivDO3jC/4/D4uSueyJVfXCajsIpBORZ +y9a84SbI/wlPY//P4eDyrsyUzkDtTQAHTIPlR85/TCNfVO8djQfMBnv9vz6T+dcV6JQh021icMX K9ydNlMfkdYxW/gzYxdo1bCfAr/6LhZ9PfLb9KCeYKa0dx2CBZbtpFc7ezcMQpRVrEMnEpsXI0aZ Mdx99Wf+aVFl/sR6ChY3xes0UAmj42IaxwRR5BPAaSmwwtMRUaAlNxMrNgAAAAAAAA== ------=_NextPart_000_01B3_01C788B8.433C3E10-- From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:31:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVEE-00030u-M8 for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:31:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVEB-0007Jb-Mu for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:31:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHrrHH060142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:53:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHrrHE060141; Fri, 27 Apr 2007 10:53:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHrWN1060114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:53:53 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3RHrEki030813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2007 13:53:15 -0400 Message-ID: <4632388B.9070505@cs.dartmouth.edu> Date: Fri, 27 Apr 2007 13:53:15 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Anders Rundgren CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery Protocol - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <000401c78699$ee787b20$82c5a8c0@arport2v> In-Reply-To: <000401c78699$ee787b20$82c5a8c0@arport2v> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000508060103080108030401" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a cryptographically signed message in MIME format. --------------ms000508060103080108030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > Hi Max, Hi Anders, > Some time ago you proposed new PKI protocols but then you did > not state any specific use-case. I'm happy to see such now :-) Yep, I finally had time to work on a practical implementation of the idea and figure out what can really be implemented and how easy would this be in practice. > Regarding painful rollover, I believe a 5-year plan or so is realistic > if it involves certificate changes. If the idea is really some kind of > "mapping scheme" between existing certificates and services it may > be faster but OTOH I don't really see how such a mapping utility > would work given the huge variations out there. But maybe you > are thinking of some kind of centralized discovery service? Sort of. For the rollover idea, I was thinking about switching to one service to another. For example a CA that wants to switch from CRLs to OCSP, it would not have to reissue all the valid certificates to have the clients to discover the new available service and not use the old one. Thinking about the future, this would really give the possibility to add/remove/move offered services by providing an easy way for CA management to do so. In the future-future, if this protocol is adopted, we can also think about an authority who will manage a network of Registration Authorities like the DNS, but for now, we should stay focused on this first step. > Personally I'm only interested in decentralized Internet-scale PKI > solutions (the opposite to S/MIME...) and would due to this base > a new scheme on the only Internet-scale "registry" there is: DNS. My solution is like DNS, but it is not hierarchical-more P2P based. I will present the idea at EuroPKI---unfortunately because of grant rules I can not forward the paper, yet. > I would suggest a scheme based on DNS names which both can > be obtained locally (from a config file) as well as being supplied > in a new certificate extension. This would allow step-wise migration > which has proved to be the fastest route to adoption. The following > is one way of architecting this: > > In the repository/certificate extension: "example.com" > > Searched for by an enhanced PKI client: > _thesuperduper-pki-lookup.example.com TXT "something" > _other-pki-lookup-service.example.com TXT "something" I am not sure about what you are saying here. If the DNS is used to store addresses to services, you can use DNS SRV records. But actually it is quite difficult, when you have a certificate, figuring out which is the DNS that has the information you need because there is not (usually) a direct mapping between DNS and certificates contents (if no DC is used). A PRQP would allow to map services also for CAs using X500 names. Another aspect to consider is that CA management do not always have direct control over the DNS, which is usually in charge of the networking people (but this may vary across different environments...). My point here is that based on my experience, DNS is not really the simplest solution to solve the PKI Resource Discovery problem... > Regarding applications, I would like to add automatic certificate > renewal services support. In this respect the PRQP could provide the URL where the application could apply for renewal of a certificate. A simple message could then be exchanged and the certificate issued without a single configuration provided from the user... -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms000508060103080108030401 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1MzE1WjAjBgkqhkiG9w0B CQQxFgQUsogDQzIAH5BqBEZaqDGsDrmQcH4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYAA/HSu1hvRQub6pOVXT8zd Lxp+mkPdTX0kkYqvyCyc1SjcT//0Z5J8ubxuNizgh9W9b744RgmQ2Uu3CZDtROay0cAaN7fc Afu/y9tidCf7BU2zpKWFdC40ovPrfrQBJv69lheA7OPoD6SpRxuSWcSnsW7CiBNsAeg+yNe+ LUZNSwAAAAAAAA== --------------ms000508060103080108030401-- From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:35:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVHw-0004AB-No for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:35:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVHu-00084A-PA for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:35:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHw1U4060539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHw1KW060538; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHveCo060482 for ; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 61B5627; Fri, 27 Apr 2007 19:57:39 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11612-05; Fri, 27 Apr 2007 19:57:37 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id F3BFA22; Fri, 27 Apr 2007 19:57:36 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042719573526:225995 ; Fri, 27 Apr 2007 19:57:35 +0200 Message-ID: <4632390D.2020509@edelweb.fr> Date: Fri, 27 Apr 2007 19:55:25 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Stefan Santesson Cc: Denis Pinkas , pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/27/2007 07:57:35 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/27/2007 07:57:36 PM, Serialize complete at 04/27/2007 07:57:36 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050503030504010403090802" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 This is a cryptographically signed message in MIME format. --------------ms050503030504010403090802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > Denis, > > I have read your e-mail and your draft, at least a majority of it. It > does not provide the answers I need. > > I need you to motivate why we need yet another protocol for on-line > status checking. > A "Read the document" reply is not sufficient for me. > > I don't want a list of technical features you provide. I want an > analysis of the impact of the industry. > Personally I'm totally against writing yet another protocol for this, > and you have so far not been able to convince me. > > I have read the text, and I am waiting to at least a response to one question concerning the service (send some days ago). I also agree with all those who do not want yet another protocol just for certficate verification. As a detail, the definition of the initial verification, revalidation, the required inputs for both cases, their security feature, the requirements for external access to a repository or not, is very unclear, thus difficult to compare with SCVP, XKMS, OCSP, DVCS --------------ms050503030504010403090802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1NTI1WjAjBgkqhkiG9w0B CQQxFgQUxKSYzcAJwb5oHFGPbfbKkrDDerQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAnXx43cDBMLSe8awf 2N42X8s6SGw2dH+sT/xYR6rdTHGP5byesmAXUNcglxQxDqyG3NSW4rT4L3kQyNAFnP+h2uup h/RYb9Yb8IQVL00ctTSfy+uAaLfoDUJoBjPCxmivjAn6N63q1BQ/bMBi23fAcoAz7RuYVrHG JHYUthAvhuAAAAAAAAA= --------------ms050503030504010403090802-- From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:36:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVJ0-0004T1-GR for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:36:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVIz-0008JR-QW for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:36:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHwreA060638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHwrUD060637; Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHwW2p060606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3RHw144034571; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Stefan Santesson" , "Sam Hartman" Cc: , "Stephen Kent" , "Tim Polk" , "Russ Housley" Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Date: Fri, 27 Apr 2007 09:21:13 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Stefan, I will give this some thought and respond if I come up with something useful. Until then, I can say immediately that I do not favor negative requirements. They cannot be tested. Mike -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Friday, April 27, 2007 9:38 AM To: Stefan Santesson; Sam Hartman; Michael Myers Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; Russ Housley Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN The discussion about SRVSAN applicability statement is stuck. And I would like to unstuck it. Do you think it is reasonable for an alt name RFC to state that the name MUST not be used in any protocol unless specifically allowed? Please see my e-mail below for an example where I think it would be unreasonable to make such restriction. If such restriction would be imposed, how should it be formulated? I personally don't think it can be reasonably formulated. When we have this issue sorted, I will go ahead and post an updated draft. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson > Sent: den 23 mars 2007 01:18 > To: 'Sam Hartman'; Michael Myers > Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; 'Russ Housley' > Subject: SRV SAN applicability statement - Was RE: Requested changes to > SRV SAN > > After some discussions face to face, it is clear to me that I have not > been successful in explaining my point. > > From what I have understood, Sam wants us to do is to say something > like the following: > The srv subjectAltName name form MUST NOT be used to validate the > identity of any entity unless the protocol within which the > identification is done explicitly specifies and permits the use of this > name form. > > Sam has told me that it would not be sufficient to require the use of > SRV SAN to be consistent with the protocol. It MUST be explicitly > allowed. > > > The rest of this mail intends to explain why this is unreasonable and > doesn't work. > I will first explain the general use case and then make an explicit > example. > > General use case > > 1) Client seek a service based on service name and domain. > 2) Client makes a query to the DNS server and receives a list of > suitable host names and their address. > 3) The Client contact one of the hosts suggested by DNS > 4) The client receive the certificate of that host > 5) The client verifies the identity of the host and determine if this > is a valid host for the requested service. > > Note that the information from the certificate is NOT used to construct > any DNS query. It is only used to validate the service host. > Note also that for this to happen at all, the service type asked for > MUST be supported by the DNS or you would not reach beyond step 2. So > for us to even consider the certificate in this case, we have an > automatic guarantee that at least the DNS supports this service name as > basis for host lookup. Thus it should already have passed the > applicability statement of RFC 2782. > > > Lets now take a specific case. > > 1) Client seeks the LDAP server of example.com > 2) Client makes a dns query for _ldap._tcp.example.com > 3a) Client receives the following list of suitable hosts: > ldap1.example.com and ldap2.example.com > 3b) Client contact ldap://ldap1.example.com and initiates a TLS session > according to RFC 4513 > 4) Client receives the server certificate from the TLS initialization. > 5) Client verifies the server certificate according to RFC 4513. > > Now. This server certificate has a subject DN with a number of > attributes that does not mean anything to the client. > The server certificate contains the dnsName SAN with the value > ldap1.example.com > The server certificate contains a SRV SAN otherName with the value > _ldap.example.com > > Through the dnsName SAN, the client will be assured that it is in fact > talking to the host ldap1.example.com. But unless the client can fully > trust the DNS, the client still don't know if this host is authorized > to provide the ldap service for this domain. If the DNS was spoofed, > the client could be talking to the wrong server. > > But, here the CA has also bound the key to the srv name > (_ldap.example.com). Through this name the client has an assertion from > the CA that this host is actually an authorized ldap server for the > example.com domain. > > Must the client disregard from this information. YES according to Sam > (If I understand him right). > > Because RFC 4513 does not explicitly mention and approve use of the SRV > SAN name form (And how could it, this name form is not an RFC yet) > > RFC 4513 states: > > 3.1.3. Server Identity Check > > In order to prevent man-in-the-middle attacks, the client MUST > verify > the server's identity (as presented in the server's Certificate > message). In this section, the client's understanding of the > server's identity (typically the identity used to establish the > transport connection) is called the "reference identity". > > The client determines the type (e.g., DNS name or IP address) of the > reference identity and performs a comparison between the reference > identity and each subjectAltName value of the corresponding type > until a match is produced. Once a match is produced, the server's > identity has been verified, and the server identity check is > complete. > > > This text is 100% consistent with using srv san otherName even though > it is not explicitly mentioned. > > So we have a case where use of DNS lookup for a service type that > established and supported by DNS servers as well as having an IANA > registered service name. We have a security protocol that provides > freedom for clients to define what a "reference identity" is. Yet we > would not be allowed to use the only name in the certificate that gives > the client what it needs to verify the host. > > That does not make any sense to me at all. > > Why is it necessary to update RFC 4513 to make it legal to use this > name form when its use is already consistent with the standard? > What if I have a privately defined SAN otherName, can I use that? I > think RFC 4513 clearly allows that. > What if that privately defined otherName contains exactly the same info > as our SRV SAN, can I use it? > > Please clarify if I have understood you wrong Sam. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 22 mars 2007 09:46 > > To: Michael Myers > > Cc: Stefan Santesson; ietf-pkix@imc.org; Stephen Kent; Tim Polk > > Subject: Re: Requested changes to SRV SAN > > > > >>>>> "Michael" == Michael Myers writes: > > > > >> Sam Hartman has a discuss requiring this document to say that > > >> this name form MUST NOT be used unless explicitly allowed by > > >> the protocol being used. > > > > Michael> Because . . . ? > > > > Two reasons. first, the SRV DNS RR definition has a very strong > > applicability statement. SRV records cannot be used except when a > > protocol specifically defines their use. This increases > > interoperability. You don't want some domains using MX to find mail > > servers and others using _smtp._tcp.domain SRV records. We should be > > consistent with the SRV spec wehn definining name types for use with > > those records. > > > > Second, the underlying interoperability concerns for this name type > > apply the are the same as for SRV records. We've had enough trouble > > with interoperability concerns caused by CN and email address in the > > subject name vs subjectAltName choices. We don't want to introduce > > other situations where there are multiple ways of naming the same > > entity without need to do so. > > > > --Sam From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:36:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVJB-0004gA-Dc for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:36:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVJA-0008Ju-TK for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:36:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHvavI060480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:57:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHva1o060479; Fri, 27 Apr 2007 10:57:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHvYCr060473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:57:35 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3RHvRL7031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2007 13:57:30 -0400 Message-ID: <46323988.3000704@cs.dartmouth.edu> Date: Fri, 27 Apr 2007 13:57:28 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Thierry Moreau CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <462E4BFE.5060205@connotech.com> In-Reply-To: <462E4BFE.5060205@connotech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005020009010300070008" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a cryptographically signed message in MIME format. --------------ms090005020009010300070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thierry Moreau wrote: > > Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? > > If you think of DHCP, a look at SLP is certainly deserved. Oh, I looked at that.. and it is quite interesting, although it is a bit complicated, at a first glance. But it may be used in LANs to distribute Request Query Authorities addresses. > I did the exercise with DNSSEC deployment, see > http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt Interesting, but can you be more specific on how this is related to the problem I am trying to address ? Can you make an example ? Thanks, -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms090005020009010300070008 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1NzI4WjAjBgkqhkiG9w0B CQQxFgQUV9sjqEEqC+rNkkqyIRwsLFs3Po4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYCW0rrLBd6KtuLlCJ3Oq8xh e8WgvzbBxHgPFme00zJFXI2jyBTvHpHREwSFnU4Auii84nZr5tohtcax3MGE6W8Cv+X1a371 +auhwr9T3Ly4yWqwf+zBjFhA+SOsiheAIhrtOZzOq9xrWBupWLnhKyilNopLnpXLmoegg+/I C28kmwAAAAAAAA== --------------ms090005020009010300070008-- From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:43:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVPm-0002E8-9Z for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:43:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVPj-0001qr-5t for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:43:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RI8KpR061628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 11:08:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RI8KvS061627; Fri, 27 Apr 2007 11:08:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3RI7xmj061517 for ; Fri, 27 Apr 2007 11:08:19 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 67043 invoked from network); 27 Apr 2007 18:07:50 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 27 Apr 2007 18:07:50 -0000 X-YMail-OSG: zasEo1kVM1nyxlxsxChxFzaoE1UHaGbztpo.wYIT4sZosKya1oJCyC78RV2D8DaxVA-- Message-ID: <46323DA8.7080301@connotech.com> Date: Fri, 27 Apr 2007 14:15:04 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Massimiliano Pala CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <462E4BFE.5060205@connotech.com> <46323988.3000704@cs.dartmouth.edu> In-Reply-To: <46323988.3000704@cs.dartmouth.edu> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Massimiliano Pala wrote: > Thierry Moreau wrote: > >> >> Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? >> >> If you think of DHCP, a look at SLP is certainly deserved. > > > Oh, I looked at that.. and it is quite interesting, although it is a bit > complicated, at a first glance. But it may be used in LANs to distribute > Request Query Authorities addresses. > Perhaps not just addresses, SLP "service attributes", for whatever use you may have in PKI resource discovery. >> I did the exercise with DNSSEC deployment, see >> http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt >> > > > Interesting, but can you be more specific on how this is related to the > problem I am trying to address ? Can you make an example ? > Ooops, I didn't mean that the above draft is helping your problem. Just an example of first attempt to make good use of SLP. > Thanks, > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com From owner-ietf-pkix@mail.imc.org Fri Apr 27 14:53:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVZF-0001gn-9u for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:53:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVZD-0005Ic-Um for pkix-archive@lists.ietf.org; Fri, 27 Apr 2007 14:53:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RIBJsk061954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 11:11:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RIBJtM061953; Fri, 27 Apr 2007 11:11:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RIBILU061941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 11:11:18 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3RIBFrY035000; Fri, 27 Apr 2007 11:11:15 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Denis Pinkas" , "Stefan Santesson" Cc: "pkix" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Fri, 27 Apr 2007 09:34:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 I vote against this proposal as a PKIX standards-track work item. Should it be implemented and fielded in a scope that materially affects the Internet, then and only then publish an Informational. Mike From Kernbauer@akiramoriyama.com Sun Apr 29 09:57:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi9uS-000098-38 for pkix-archive@lists.ietf.org; Sun, 29 Apr 2007 09:57:52 -0400 Received: from adsl1-p1093.ras.network-i.net ([212.21.122.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hi9uO-0006EU-CI for pkix-archive@lists.ietf.org; Sun, 29 Apr 2007 09:57:51 -0400 Received: by 10.211.140.235 with SMTP id ImgqcAReSUgkO; Sun, 29 Apr 2007 14:55:51 +0100 (GMT) Received: by 192.168.233.162 with SMTP id UDkLSnOTtzOvNw.4366791871835; Sun, 29 Apr 2007 14:55:49 +0100 (GMT) Message-ID: <000b01c78a66$16511ba0$4d7a15d4@userst0ymi9ylk> From: "awad Kernbauer" To: pkix-archive@lists.ietf.org Subject: Then place those two sections in the relative files as mentioned above - simple. Date: Sun, 29 Apr 2007 14:55:46 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C78A6E.781583A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 ------=_NextPart_000_0007_01C78A6E.781583A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C78A6E.781583A0" ------=_NextPart_001_0008_01C78A6E.781583A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's not his now, but mine. It is the name given to the shock troops of = razvedka in which there are combined elements of espionage, terrorism = and large-scale partisan operations. The rabbit became a fast-disappearing cloud of sand. They are encouraged = to take into account the overall nature of the postings by an individual = and whether particular postings are an aberration or typical. It is the cause of wars and every kind of oppression, which fill the = earth with pain, sighs, and bitterness. It is time to go. Bei den Produkt- und Firmennamen, die hier verwendet werden, handelt es = sich um Marken oder Handelsnamen der jeweiligen Firmen. It is the living creature's mind, aided by the mechanism, that brings = the force to us. It is the divine judgment, the solemn holy doom of the righteous man, = the "Come, thou blessed," spoken to the individual. ------=_NextPart_001_0008_01C78A6E.781583A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
It's not his now, but mine. It is the = name given to=20 the shock troops of razvedka in which there are combined elements of = espionage,=20 terrorism and large-scale partisan operations.
The rabbit became a fast-disappearing = cloud of=20 sand. They are encouraged to take into account the overall nature of the = postings by an individual and whether particular postings are an = aberration or typical.
It is the cause of wars and every kind = of=20 oppression, which fill the earth with pain, sighs, and bitterness. It is = time to go.
Bei den Produkt- und Firmennamen, die = hier=20 verwendet werden, handelt es sich um Marken oder Handelsnamen der = jeweiligen Firmen.
It is the living creature's mind, aided = by the=20 mechanism, that brings the force to us.
It is the divine judgment, the solemn = holy doom of=20 the righteous man, the "Come, thou blessed," spoken to the=20 individual.
 
 
 
------=_NextPart_001_0008_01C78A6E.781583A0-- ------=_NextPart_000_0007_01C78A6E.781583A0 Content-Type: image/gif; name="our index.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c78a66$16511ba0$4d7a15d4@userst0ymi9ylk> R0lGODlhyAEAAodSAAAFAIYIAACNAHGCAAcFen4HcwaCebrJurbNtJrD9UUsAF4uAoMpAJshBsor AOYjAgBNBx5HAjxJDmA+AH9FAJw6ALw0AOpMAABrAB5kADNcAGFkAIxjB6lhALlnCtVtAAd7ACt3 ADmMAGSCDYV3AKSFArF9AOZ2AAqaABqfAE6cAF6iAHmYAKOiALqpAOiTAAG7AC69AD22AFe5BYO4 AprNCre0ANfEAAHSACniA0DdAGLdAIvjAKDkAMDVAOrnBgcAMhgASzQAR2wANnQASJcGQ78JOdoA OgAnPRofQzoSOFQfTYUXOpQVRcweRuAuMgU3NStLSzg1O1NFN3pNTZJGNL06Od86SQpfMSNVSUpe QGZqM3luCplZRLVYRO1VQQCDOxp9NT+LN16OMXKIM5J7TcZzQt51QQCqRhieQDefNl6dR3auQJmp SMCdM+2WRAy5Oh27Pja/O1S6PIC7Oq66Mbi7NNK+QQDkOy3oQT3VSGHqP4PdSZfgS87YRejcOQIA dCcAg0YNcVYAdocFjaMAdrYDidEAgQAiiyomczgniVgrf4wYjJsmhLsRftUmeAgxghJLdjZLdWQ3 gHo1ga1Ad8tMc+g1dgtYfSZZgEFdfWBTinVVf5lrg7ZRdeZngAuAdRxze0eEdViCc4Z2c6N8g7Vx f9x+gACteB+reDSYiVKXcYaYfJ+YirGUcdemfQPGjB60hETLd1bHgHKxh5TNeLfMdtWzdQDcixvh gEfki2nSi4jtcpzZirfuddLjdwMAzBMAzDYFs1MBxYEGuZcCu8gOxeALxAAeuRcmsz8nyVUiunIm uqkcuLsat9gZtAo8zho+zUdOvmJDzXZFzJQ4ubM8t9E/ygRYxy1muT9iwFtTu3VRwJhXyMtZzNZd yQB0yy2HvjKIxlt5xHWHvq10ubF7u+l9sgClziaYwzafvGORwHeuw5egzcKow9ylxQrIvCLOxTLA umrJtH/Kuq2xu/L68qqWo3p9evcABAD7BP/5AAIA+P8A/wD///3/8yH5BADA5nUALAAAAADIAQAC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnJjQnsWLGDNq3Mixo8ePIEOKHEmypMmTKFOqxEixpcuX MGPKnEmzps2bOHPq3Alxpc+fQIMKHUq0qNGjSJMqXcq0qdOnT3lKnUq1qtWrWLNq3cq1q9evYF9C HUu2rNOwaNOqXcu2rdu3cOPKnUu37lqzePPqXWm3r9+/gANT3Uu4sOHDHwUrnoq4sePHkCNL3ru4 stXJmDNr9mi5s+e+m0OLHo0SgOmMpgF0xMG6teuPAmLLni3AouvbCFMDMIiht2/fBmnTbgijeEIU yD8rjxk0NUbnF6FfBEIdSEbhtDPC2c4d9Wnvqo12/7dYHEbG8h3BqFcp/aJsjO81zpYfG359jOhP QtjfMb+9/RBgBKB72N0nkm7fXQTggvxtpJtG6kUYoUXxEVibPe2RptFMqRHU4UAfDlQdEAmFWFCE AqEoInUGVQcRgrspFKKJ/9BIkIst2ajiQDsKNCKLBPX4T484SiRbiaatSKKP1GE0YUpPPmmRlPZQ OV11Hz2JJUZbWqlhUVva8+OV1l1EwJlocpSmRmGK2aRFa2IUJ0hbtsnmm26WSWZHdpY0p0BoFhTo jT8WVKSSAwGjKEWHFhTioIMOFKlEJobYaKNoTiromQRFGmmjiwm1ZqYEwHkmeBlepCgwGq2akasW pf+aKkdt9mnmqRbxo2tGuvLTEaylJXhrqXLiSqadvWqUrEXAcoRkjAdZyiKoNjp0KZA1JumhtkqC Kimn2+5m4qqfCeXcuadluGqzXOI57EdzmkrsR7IK+1yCGc4qL6nzhhQvhsLm+117y2JU8LoIi/Rv dAn+qGex/ZKkL8PhUZwRv2oau2ebE2tIU4cgJ1mpttXaWG2n/JLakMncFtQriC1nC61BJ1uL7UC9 5qyrQS//07NALENb80LkIvSzw9HCGHNCRSd0aKM9/xxu0jQ2vRxMSCM9tcwHWQ300psSYJCmuS19 8owx10z2i2a3PLLSFf8b58IhTSyd0nc+LLG9eTv/rBF0qdINcMUWf6lUwsyuC3HKf/Pd8eCNE86n uxbZCnms9k4seN18N9tswfYUXG/cGu8t+db/BEq21w8NzTXMM8MdM+vfil0Q7VdPhCDsbvc+M5NL EuR100Gv3Da0OBZJY83etn68o9y+neiiwlP/9e/O78bR3QPbu7lHAlfsuaLtPtzm5o8bnpFNmrYP LqDvw0416sUzVP/r0l+P+toPkb28tmQbVP5qR5GaoU1ovstRAuFnOwIyEGUNfB1C+Jc7DqVtgajT 3/wkyEEN2g+D1wuabqCHQOwhZHuOy1z3JHc52UUObyCRXXi4V7H2pA98K7yX5ACXwhnyDTyRU59S /8KnwyAWEYUPOqISY5jDFwpRMx6UoAzZNsIM4u95MtsdCWkGNsE8cSkw+qIYx0jGMprxjGhMY2Yq yMY2uvGNcIyjHOdIxzraUTlqzKNQ7sjHPvoxLnoMpB7/SMhC3kWQiExkYgxZR0U68pGQhCQjJzmT oCjgkpjMpAIwx0IaouqHHNGkJi3SgFKa0pQceYAqH6ARVGLElfZYgCwxIssFXMQBuMylLi0SgF5m pJcBuMgqh6lKHcLNITAiiC6XicuCiDIh+YimNAsCTIJU84O/A+Y1KbmYXBoEk9+8pPwGskqBDLMh 3kRIOcmpSqphT5vW7OU4ObjNcCrAmeKMYsm6mP+QdOqSiya8ogmvWU9wCsSg2CRILQVSywVwUzHp VGYzCxLRbSL0Hxft50QPktGMMggC+EQoQhlAUoGQlAEhTUhH8/mPiArEpS/dqPFit7STHsSmA8Hp QC4q0nxmVCE65SlLHzoYogwIiEi1x0kvstSTNHUjT7VIVP/DoIxU1SJHVSpJtcoAjWRVI1N96lep GqCMUOCspgvJVC+nxLBu1SIciKs94soBkoi1QZGEzE0AZBDkoKCvyRHIkQayIIkAByF8JUhiCcug gnxUIIv9TW8OMtiDLBay+xlIZQUbG4NctiGzWYhfPZtZx5b2H4dNiHAictnCErUyNvroYwUyWoL/ +LW2DZHsbwZSHoL0liCHTe0/WjNc1hQXB7wtj3FIK9uB6OO5BXmuPhgLUuoeRLoEEclHOVIhBeHV u2Ul60dui5ySjHW7eU2jX42oxPVuZEEi8Y9GdOub+fbGIvW9SH33e19OJlFA381IfvXbX3vQt8AZ kW5KbvveANtDvuQpTuE6AkORtIYjr0lvYW6CW812tiCVxW5ChKvaD1v2tP+47G1wo8Fk0jY5Heas AJ61RYH81sbLJeFKLmxVB49VvFh1cEbW616RdFcjPNawXm6yWcxWV7GnvfFBSIyQGBNExALBcopR vNgDcou4xy0ImE/8ZCc7F7pnnm5wTEyRz/7D/8pN/kdlP7vYxLp5xJM9TmBf65cxD8TPAhlzaoVL ZTLjGQMFSe0AB71bMzs6iiA2EIUMdOQj28PSHumupSEcYfNcBMI2TNCAB0yvBMmX00oWIqdXLeFO H6tylOsIpoMcXlrbusdlPbV/svrVjvH6u0Q8T6u1e9Qfs1XYnkZ1fnTt6QcPmyUGufGIgMdnwNxv no2SkHoeIqQgbdvbYKC2oYAkpB31yNzfLvFwCBU8cbPbSOs2yI5eCMoqafs6kp51RuykbTCk+t8A D7jAB07wghv84AhPuMIXbpFqO/zhEI84URl+cIlbnCYUz7jGN87xjnucKBcPucj/8vGSM6XCn//s JL5UqHIEHUiGnGSvCx3k8qTGPOU77CETZz46iqGcwnDDyw05bpMDAhTSXrai0al49BpzsH7/+13U 59nBqssIi/Tj50IGGC4b+byHMBy6yVcS7Jubna01P3bZOddymbN8iaHOOeHK3vORXNuDrqOx0kkG tg9NvWwBHflAzKXzs5udhiuvYeFf3vak0n3xj2/8sQ2/IStWfemUuiBNN+/0p/Mz7yInPAvZO2HE N3HywZJ86d9OeU8qMX11ZzzpD1/vUst9wquXvN1qP/afwB7yiYec68kO9qCfPe5uvz3l6f1z2zM/ jP5Nu/NxH/v7GVDrghf91xWv++Cji/vbT6v/zWn/8+qzHu1pjz3bZ4/+0bMd+rgnf/LhL3aNfwzr 9zPlOF38j3oKxP8LAYACKE//R4AFGADxhIDUZID6RxAN2H8GOBDbNIAK6BALVRAPOBAPmIEQUU/1 lH+lVBD2AEu1BHTu13tAAUwaoYKtlyAs2H4JgkkaIYMjIU3sJx00aBE5aA87qIOXFH/S8YIX8YI9 yIM/OBJFmIRHaISbdBJCKIQ2mBFRaA+5pBFVyEu+hIJlIYT2IIQleBFfiIXBZBFh2FC2BIS890tZ +Eql1EptaHjtsYM7GIZkOEsX0YM5yIVduIYhoYd0WIdnuIdjaBJ4uIQvKIEGSIGIWIGCNxFE/wFL p5QRV3iFFwFLcliITciEmdiHfGgRq6QRnyiGajiIoiiIVohLt4SKoziEL0iJqegAJKGHU3gRU6iH srdEdPiHl7iJEwNLWmgPNyFNwhhN9vRTFRWBEMiIB6hNyLgQHHh53LJS9xRSP7WMAGiN8ARpVpcQ iriAFThFBjGDS+iDmxhLdviHgJiObNgAHWGLv/iO8PgRZhiI4phJ7BeP+GgYjbiP/NiP+fiP9teP AmkTAFmQBtkUA5mQCrmQDOlGB/mQCNmQEjmRFFmRoAGRGLk+FukSGdmRGrmREeGR+giSJFmSJjmR IilEJ7mSLNmSfZSSzuKSMjmTGwmTnEGTEf9nkzq5kzzZkx2Hk4fkk0I5lERZeUCZk0WZlPF4lD2h lE6Zj0wZlVI5lVRZlVZ5lViZlVoJF0/ZlQy3lWAZlmI5lmRZlmZ5lnBElGi5lv7olf/GlgzhlnkF l3RZl3bZEl15l3q5ly8pl4HElxXhl4IEmBwpmAx3b07ibxmxHrA2JnfymO1SFNJnmDBpEwgzbiuC MmPTQDdzM/DTIp3ZbjKBLTejNBMUQZ+5Kd0ybQyUKdlTRYSJFkNBPolzKxczL8iHOd6BEYpTPnry JqVjD8H5EbSpKqxiKsWyEcXJMI1jnB2xKxcBnSChMcaiQpC5OJpiPdNjENoZmy0RP6ljO93/aT0D BJ7xA5shBDOpqZnhaTzQo57bQkK/8zTYAp7s+S3uGZ//MJ7AwEWgSSj3iZ/v6Z0vwU/8yTvp+TX6 qaDZQhA7szM+ww/wyaBsM6ANuqCtGTYQNKHc2Z/VE5i6eS8hypzGtJsimivSGTopOjgnSJkfGRP8 BKE4I6EZGp7vY5oOSqMy+g9AMi3txncT4ZnY0jsD6jsxAps4SqFKmhDx8z5CKproeaEkqnYs16Iu ehE0YZ8ceqHt6Zo3GnjHtJ6u2XUFJHUlpEUzKhA7WkWwuaMWuqSnqTK8g6YXSqQcmjNqKjVAepeE 1xGlU52q8SArNzmROaL/NaUm8ae4mXPG/4kwxwkwLAqpI6oRiuovEZOcmBqiAYNySXSouDKcV2oU lWqoc+dDIwqqwYkrm6pyKmEsGmOdkzqogko6SPKmtVo2FhqmXEqhIhMycwp6BIqrS0qndXqkCCSs +nlB/mmrV/c/RYo9e7qnu/qm2LelGMqldjqt0SMuvqqk1TqWRDGZkpGGKZFCknqi3UOq9Ad/TAR0 Jmqu50qqmmqqJhqqRslH3+pHyjqtxbqs0WqsyxqsYGmv6UWTBGtyR3mwChuQAps7CwsUDasWQwF/ nbiHWLiCg8iMFWuGGWGHKsGMHbGE42iESORyEZuQQ5VPbXNQ00gQLBWBEbitBEGMLtFO5v/0AAhB s/+gswLBszObDwfxsBlHEynbsjBbgS4VUbKkUA5VgAuIiC6xtEx7EFKLUS3LsghRtSfLkEPlrzMj VC0rUxvlszrrs1jLEDbLTgehs13btRrYAA0htBVHE+fEURmVjdmYRSaitf9QtTIlEW17tTvVsmQL tAehscq4tXxkFEVIshlhj5qYihihilQIi5NruSPIjikxsiPrg5WouZ/LER4rtxunE257uveUSVY7 uC7bsoE7EH/LWmW2ZUnDuq2LEM0ogqQLkJsKVl1lVhRgD2eFVmgVZADGVL+LvN6lEm+lvMZLVct7 vFCVvLs7tDPBZbNLu6aFWdzbvd6LWoj/JhB59r0TsWd7pr0oZr5/hRBsFnIPWxMrdmJrxln0G0I2 Em9O5loothCNZVr7u2V09mT/uxDV+5aK2xkFnMAKvMAId8AOrBUMHMGR9MAntBT9tm+o4puW4xEb nJQUzCiFIiKGciOdUsI+8hINhJpUh5MS3HAzIZrBA604AyI0IxAe2hI3fMPCkygb+sFbKcM1UsOA QsMTlBA0unVEPMJCHMRs0cIb96iqwiyv8hzR8SuIQxK+kivKucVSbL0+LBHmghrbN3dVrCYrMS+X KiZuQsWx4sQpeX/oCcQ8msRLXEB0LKANJDRfTJFhTCtsEsWV88cYQnZlLMZtfMiD7MYe//kxJbLE MxNBeVygdzzElJw6krLHKNkcFOYgiOxfxnQ3t4jINVTIVloUmExHfTwaNlTIitzKh1F/fjmVrjzL jkGVtOxIpywTt3wSuZxdu/zLwJxGvYyXwVwSM8FMMJW4z/QQw0izyBy7w+ySRVGOGEHN+SCFp0i5 ncwRpFgSrriCkrhLxQyT1EyGsZQRoFuJr7TOYAgS3TwSGbsRs5jIXxTNRTWx20PPvATOOjiDQwgS 1JzOm7zNbHxL48yT9KjOpFTQnUy9zMfJK+HQ1fxL+BixRYG5GJG81CtKm4jRVgjQK1HOTJURJyXR BWfPNoFS/uta/6DSBOHSjLhNLt3ILf9BAfxbEC490yhdkTPmKD5NW31FWJ4l1DfdZgyRvQMRvpV0 0INkEz3NWwcBA0CzxOtrW5Mc1BPx1Aqh1NFmy26MAUO2EShAIRtxIfqcIORVXoYMHyHRbOCz1qU8 tzvNFaGl1TmBplUtvsw116/F1H6dFHwd2A/814T9JYIdl4Wd2BA7mkoswvu5w5V8yTVxxD1cx5Pi MO22LofNjzCsxHosoJJNEzpcySrsMzxsw1d9wo692SMndT99pD4dOzUhLj/NxI3tIaktx6w9R6kc qIXMKlAMJ8IpJyGhNx5RKhEzyn8D0fpM3AW5l71Nz4q3EWXym6JiJgU9esG9qtIR3EX/GZu0PdWy LcewzSF0nMLRkt5Trd7aCKKKLcyMrMeybdvrLd4WhKafXdu4Xd/6zd9x9N4bMdu2Hd71Pd/2LROu XeBJbEL53d/0vdshl+B03OD8asdCnN8YvuA0DadyAeBGUXT9neC6veEkvuCa13mBl0UPfkfvDeEE 7OEwThouPuM0XuNbGeM4HhJomeONwY/T1LqCa+NXIxQYvUxjIdAjeLnfzIW+OLm0+OQWcc1RTovD qBEJjXr9fIedy+NmQbc75Uxf3rMGYbgxEeQtC7cOKIFqruD4RE5ubhBNi1FgzrKC6wCwG7BxHudB y+URieBr/ucViIyJ2xJm/uf/F+a1/51N/afhBvGNdSy4OGtOBeFQcU7hQm4XLavTaS4QcIvmnN4Q Qc5R35RTJf5Sd47b0BLoTzsQes5QBBHppG5Sk963jM4TfN4UpKiHybtJmyjSTgVW1dy5wdSJS77P UjXSwJ7ldyiJJI3sFmG5mPu7zauSu63p2ivreo1aST0TNl0Q3e7t346+tS7Asd7SNzUQwzu8dfwP 3/7tHDAQ785YKXbpgMHVtf1kVb2+ef0S9q7tVTYQ+U7U8y5jJhbwwSHwiFUQBg/AA4zUXHHrKhFe OJARE49VCiIg/xEUFY8RG7/xtnHxFo9f+rURGx9e4dVszQbWHuHxl+Ye7/XySkHvuv8LFCpvD2ON ETdvD/ow8iNf8z/h8R5faxlPHp9W9ESvETt/EUmGXwiW8xzh9DZ/EVAf8om84jK/E0Lh8dK38T5v YF3PXSMBX580ZGptIWBvEkIvHxqBai1PYF+vPlcv8FJdEHMf93Z/93if93pfk07M1xC/sHsf+IIf t39f+Ds5+Glh+FyO+Lnc4nef44wf+ZKfsIpf+ZZ/+UMx+WWJ+Zw/zpr/+TIfqpHf+aRfwKB/+uCq +MFa+nwRlqz/+pLk1bA/+zBOwYKJ+rgv5LCf+7zPwrTP1L0f/MI//Mvx+8Z//DhXf4cafcsPc9PJ OJ/c/DPHouIaOKQS87nPdR9CQQ7/MaYZxHUQUSSHov1aB/6a4nfbKjtXIXQV1t3LaQ/sQv3kmo9z Uv+40sE7t3ZsFf8KQ52uChAECNgjSFDgQIJAFBYs+M/hP4VAHjqMOBHARYsYH14EMNEhR4//Dm7U SLKjR44pQ65ECdLjyJAwJ0aUyNIhP5wmHx4kMFHmzZxA+dkkWtToUaRJlS5letTlv5QnoWp82jSq 1I8ls0qtqrTiw68QFXoM27Ul1q07BerMiFZszbZq18o9yzapyrohzeJlWVUmMMCAHwaeObYw3KaJ FS9mbJThY8iRIXMkGLXyxYKUJW9mePWx5syYLwPgzBm0PdAHH6sebVp059egT7sm//05dsrQtVvD 1l0atWXevX+/NsgTYeTTsnHvtseaoXPf0aVPp17d+nXsw7VTVn5VOG3m2nMHB+67O2/0uT2Pt637 fHTNcbeWfLpXa9GrZ9HynX/fbtr+TqrPv8YKNPBAxbJDDjPuGLztu+k0S8474WaL0Lv21mNPMgu7 +48o+7iKCsCp3GIqv7bo469Es0gkESQYVTQRQRprtPFGFjFC0UWlKJRRPh7vIvC/qlr8sES7jNTL vwE7ilHEGYUUUKsR+5MvxCWhRLJJk5TE8Usww7RyzCCRKvJHIoc0ysszsWKTSTSRBPJILp9Msso1 qaJyxB3lxDIvP/H8U0xCC8VRUP/+vARxTy2BVNSmN/eLc6Wu2pxz0Dun5AtTSH3sUkdEKZwz00/p VNNQVFM98b5KT+3ULZdabXTVKOUk9dVRZS1z0CYnLTNLR0G100VLgX0xUVZdVXXZxRTkkDjx1NNw sw5Fm607DM2Dtj1uR8t2uGnD83ZbcaPFtrdryZ2MuPMse485C+FlN1334nX2Xnzz1dc6evf191+A A173u3fB7dbg0qqtTUJrGybY4fIKjlba5QS2+GLqmNV4Y44TW+Djhz5ewCORQ1LgZJRRNioAlkNi OQCHSv5HZplV9sjmjnPWeWeee/Y5MYyDFnpoootm6Gekk1Z6aaabVtVoqKOWeur/jJ22+mqss9Z6 a6679ppqsMMWe2yyyzb7bLTTVntfr9t2+22445Z7brrrtvtuvPPOem2++/a7Ib0DFxNgAQo3XADJ IFAcAsgML0gfyB+DXJ/HMLD8cusux/wxxxnqnDYKCVocstEJguH0x3BQfXWmUHD9dWPtWnz2xR+q XXDct2bdod31C6n311GYCHbbFXdo9qQMd0j5iZAvHgKlmB/e9ZCI/8f6f5g/PKnde3dI84kuf+h0 GIiaPHf0r5Z++cI9Orz9ich/3vjj6b+e+oewJ+r2+qGf3/9/8O8o+vuH+DxiwOzBL4ECmIjyovM5 e0BwcpEjyOQeR0HJQPBvG+Rg/3YQJMD+ue99Hukd+U43vhPyTnWJGdQI2cfApCAwf/ibnvAcYj0C mglOUIpTDmdow/QFMWmPeuH6FohCEzpEfkgs31KWGL8ULlB7CjwKGKwYO7s8kUVMgUMXQ9JFODzE imMEg0PG+DyiGFGIa2TMvsYYnYgkZCEbahBpZkNGK04njo/Zoz3e+Mc86nGODMFjIcFQkDd67n3T 0WAEC1eQOEZykIYMJEES2UFMZlI6COqVVmDyk7IIy1Yv+QlRwgIWw4hkLSMpZVFO6ZBWyqSVFHml TWoZSieJEpZzYUktlaJJYAYzOtApznFwckxk8mNDgSFIYJi5GWI+62G6YY1xjv8Dn231EZKDtJcc gQDHQW7zm970Zh+1CZlzClOd68yOwjZkrgdJizPRXNA0C+Ic41DnmQw5JmT6KS6ypHJRsCoJYRzi TGCgEjFsZGjTdHVQwQwmoqrsybGeckpfrsSgEE1oppQ1qlFaNE21uhSjSsXRhqYUR//CJ2v2WZBn 9vGlzlRPucAzsYlVDJv2PBi2bEothx0MYTgVKjuN6jcbeSqkcpLJQz9FUkrh6UNEpAspK+oTXnbF mrTi1FOsyZMjqVSsRDlqWc16VrSmVa1rNdpY3ZogtsZ1aG+la5jkele85lWvpalrX/36VwPtVbCP AWxhDXtYxNpksGtLbGMd+1j/yEa2WYulbDu/RTGdAjVcNc1QecB12YR5dlyiredogdNNaU5zsz6i DsNYCzrQbrayZENQA2z7ENs2wCMvSwxvHeLbm+HsIcD9B3GH27Kl0AxkIHWKf4T7W+QmJbe69Uhu J2LdiRDXuETZ7nORsl2HYBe7klVasaALs6ZoN7oOcUB73euR904kvhPxblHUi97zpne9DnlAf012 MqWkDMD0HfBDhGtc8EbVLQkuSn8fsBLh1pe8jdnXyxhi4YLkQ8PYwTBBOkwQDYc4H49xL4nbC5kS TyfFDFnxhy/0HZFBBmXUEZnMjovfG+P2ttXdsX33+4/5BrjABh6yQyQ84Y6N/3e8/PVvU4IcZCC7 t72AChKUi2Ll+R6ZKEs2cpGL+2Puvmy/WJ5yfncL5pBYmctIsbGOqXvdHiO5QBUWs5gfU2M8Sye3 BdnzhVnm4T8X5MMuBvGGXzywgjhY0f2NToixGN4440dPWNkucL2r5YdYGdN92eGj5TzZfPWZIKK2 R4yvM93pQsbUpibIohUtGVZHx8GQmTVBGHDr6xA61j+NzIzt4WuC7LrUH+OzbSFD6s0AuyDCjo6y bY3rx9yaAbM1G4KeizOqprnMLJF2t6Wd6W1H2QEKFrIC/mtu9oY7Kd318qbTLWUpP+TbHpF2QVZs 7xNr6zv3VnG+GeLsX5+M2v9opUDBH1NwChSk3tcpXeIUx5CGI5whEofMwqXjTtE93DoWVzi0s9Nw ezSc48+eNskr7nHOjDzkGq8OyAlC8YkbfOBmfd1jap5xxl1nc5LZuT12rsFGutw3Pe+50HcKmZ5f B4Kf61dBXG70yNycIVKnjtEnBKGZq5PolmNI0qfj9YI0snMWZAjZGbI669yc6ivPeXXI17hHFtXh AETjER9iRBnKsCjeuyENlaLFiZzvH4L/dM8meHiP0I52R+F78+xXdxCCcKlHeR8MG0hFKYVE8pJf id4LaLm+B4+AqyP9CjN/QNC3zu8eET0QC/962Mde9rOXbNY3SHvB2V73u+f/fe99rzbcN+X3wyd+ 8Y1/fOQnX/nLZ/6/Xtv8swYfVfpqOsUQnZ6cqmtgpCVIMpXZWZ36CGLhokk4eQ199Jut+uJZPzwr pH2GmNP89njmS5sjkOfg//rYl6a4uqkwjEs/6OOkSTEvirKqqfoojBIoAyylVuIUKjNAKgsUSYEq qxFAdqoj/pOX96uXDhwm/Sumd2IO+7M/ovq/bZGY/Lumq9tAi5G+rvEXDbynEKTB46i+Fjw6OkrB 1yCmaArA/dtBrHO//UMtDCS+GpGqpeKSYPGO0xslXjEpT1OqJfSVJoydbINBIQIYIOTAnpqXIQQ/ aAnA55M7FOQpohLCIoS//yMcvqTqNEBxKgnEFTq8wrCCQFOZFSzUCOwzwjb8w9BCQzXswzFkw/Mj QzAsLbkbQSLsv3JRQUCMRH1TxPDAwUIMQ0YUqhxkxC7UxER0xBM0REn8vTeckViBQyhMFgt8lFOs wAmsQpJqxVccKebSQr/iQu2Trc8SxdYSxdW6xCA8v9HavvVouvYjLFtko1FUPx7MrDRcRt5Lxr+C RmqsRmscQGnMRm2kkWvsRm/8xsXaxsQCR7QSx9wjx0wyx4ZCR3ZsR3f8l8o7nHecR+x4u4KwR9NB nalbO83pR64ru8NDm6QDuwrCINJhOXugurUrK3XUmrxLve+ByCKyCc8DkP+qUCM1Igp/LArr4bvG q7vOk8j1+ciGbCzqe5B4sr7IMDuGwEd7wEevI8jI6JxGOjvVKYi1W0icdJ3NcEmWrEl6PD4EIR7R Cz0R2p6VIDyQDKEgoSotArwaSsAoUZL1wR4fKslstJNhuTsXCgnPg0rUwwCvlEibaDySlB7AA8uI 9EexdBEZIkmsPKx90cAZ3I14CTqEpMRMhAyXzEcYyKC4w6lu6kuIY7lUtMC4lL7yk4jFzIsWqaUz IgpKIiPKwzy7C4nIDCklUZLMHKWMSsxkNA654CWK+qqYIE1aWqjTvKqqciWBSs1eSqVX+sxZ2iXW /InaBE3A8pd8KqYa3ET/mAKMYEyNGhRB34gmeoqWfyqI5USn+QtK6OQXYIy/cEoneoKOlrom4ywN E9wn17LB1SjOFcwr3bybY/KI82xN9Zw8CgQpqkpPobgSKRylplIT+PTM1yzPwnK+6XzE/oQMawpP 7by/Ad2Mf2rOYRRQnngME9Qs/kvOrNPP3MFDm9iqlQArCc1QDVXG6ESbDf3Q4OvQvgHRuRFREz1R FAVEEl3R3UzRqmHR13NRe4BRGq1RG6UbGc1RvLpRHu3RktRRFfVRIW0jIF2rIT1SuipSqEHSGFRS J0U/Jo3SlHpSKmU+Kb1SLG2bKj3CLO1S3NnSf/FSMR1TMi1TM00VME1T/zVdUzZtqzN9UzgVxzaN jjh1jDkNpjodqxTNUz51mjv908rqU0FVGkAdrEE9VERN1JUqVDxVVEfVmEJ9VK1hVErdUUkdnErN VE31vUsllE39VHbqVI+oUlGFG1CNjFLlmFNdVXVKVVd91ZVgVVmdVW+8VFqlLVjNVV3dVV5V1VvF GA39VWGltl5F1GE9VmRFxzFNVmZ102J9Vmi9QFqNVjBpVmu9VgGkVm0dUmztVm990W0NV3Ed1535 VnO9l2I9V3VdV1LcUHZ9V2fJUng9GySdV74hV2q1V33dV37VV3wl134NWIG9mBsdWMb6V4RNWIVd 2Dc1WId92OtgWIn1Uv+IrViLvViMzVjonNiF1dhb5Vgb8ViRHVmS1VgfLVl1BdlXRVmWbdk/VdlC UVOYndlOTVn9dFmcDUeavcWc7VmxOVKfndGdtdGgrdSh/aWiTdajXVqaTVqnfVoPZVrFglphJVGq BVapFb6rxcas7VpJnVevDVssfVKxLVukWFezTduTBdtDdVq1fduvBVS4ndso3Vq7JUexvVtKFVW9 lVW6PdO+ZdUrDVy++tsyJVw6rdd9NdyGRdx5ZFzIjVzJhVzHRdfJlVcnvVzN3dwJq1yZ5VyK9VzR Hd0iFVTS3VvQTV3VVdvTbV3XBcdefd2XrdmWVVTZvd3oXF2gxV3eNVQM3f1drOxd4ZVRMg0IADsA = ------=_NextPart_000_0007_01C78A6E.781583A0-- From Kishor_Jaenicke@agiciel.com Sun Apr 29 11:29:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiBL8-0001G9-Ue for pkix-archive@lists.ietf.org; Sun, 29 Apr 2007 11:29:30 -0400 Received: from host203-20-dynamic.3-87-r.retail.telecomitalia.it ([87.3.20.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiBL4-0006W7-GB for pkix-archive@lists.ietf.org; Sun, 29 Apr 2007 11:29:30 -0400 Received: from luce-9fd222c3a6 ([105.183.39.164]:13377 "EHLO luce-9fd222c3a6" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host113-206-dynamic.6-87-r.retail.telecomitalia.it with ESMTP id S22TREOUJYBKJECV (ORCPT ); Sun, 29 Apr 2007 17:29:59 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Apr 2007 17:29:22 +0200 To: pkix-archive@lists.ietf.org From: "Kishor Jaenicke" Subject: Hot news? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.8 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Opening bell message. http://s6.bilder-hosting.de/img/VJJCW.gif Return Value The return value is the height of one row of icons, or zero if there were no icons. From owner-ietf-pkix@mail.imc.org Mon Apr 30 05:16:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiRzn-0006MO-5H for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 05:16:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiRzl-0006sl-Qd for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 05:16:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U8HRFI023573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 01:17:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3U8HRk3023572; Mon, 30 Apr 2007 01:17:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U8H5Yv023506 for ; Mon, 30 Apr 2007 01:17:26 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73A4E49B8; Mon, 30 Apr 2007 04:17:03 -0400 (EDT) From: Sam Hartman To: Stefan Santesson Cc: Michael Myers , "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Subject: Re: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN References: Date: Mon, 30 Apr 2007 04:17:03 -0400 In-Reply-To: (Stefan Santesson's message of "Fri, 27 Apr 2007 18:38:23 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi. I'd like to apologize for not getting back to this sooner and for (now) putting it off yet again. I'm about to get onto a plane to an IESG retreat. I'll try to deal with this over the next couple of days although I do have a few things ahead of it. I'll definitely discuss with Tim. From owner-ietf-pkix@mail.imc.org Mon Apr 30 10:51:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXEI-0008DJ-3d for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 10:51:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXEG-0003Gd-NK for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 10:51:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UE2gjc072188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 07:02:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UE2gsi072187; Mon, 30 Apr 2007 07:02:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UE2Kj9072153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 30 Apr 2007 07:02:41 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Mon, 30 Apr 2007 15:02:19 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Mon, 30 Apr 2007 15:02:09 +0100 From: Stefan Santesson To: Sam Hartman CC: Michael Myers , "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Date: Mon, 30 Apr 2007 15:01:57 +0100 Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Topic: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Index: AceK//uuLuOrz9YISlOaXS6aKHSMlQAMAfxg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3UE2fj8072182 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Thank you Sam. I'm looking forward to your reply. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 30 april 2007 10:17 > To: Stefan Santesson > Cc: Michael Myers; ietf-pkix@imc.org; Stephen Kent; Tim Polk; Russ > Housley > Subject: Re: SRV SAN applicability statement - Was RE: Requested > changes to SRV SAN > > Hi. > > I'd like to apologize for not getting back to this sooner and for > (now) putting it off yet again. I'm about to get onto a plane to an > IESG retreat. I'll try to deal with this over the next couple of days > although I do have a few things ahead of it. I'll definitely discuss > with Tim. > From owner-ietf-pkix@mail.imc.org Mon Apr 30 16:04:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hic78-0007Eo-1Y for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 16:04:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hic76-0007Yh-LS for pkix-archive@lists.ietf.org; Mon, 30 Apr 2007 16:04:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UJ54Sg015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 12:05:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UJ54C0015521; Mon, 30 Apr 2007 12:05:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3UJ4gHe015446 for ; Mon, 30 Apr 2007 12:05:03 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 20934 invoked from network); 30 Apr 2007 19:04:37 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.39.209 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 30 Apr 2007 19:04:37 -0000 X-YMail-OSG: jkqdg9gVM1m3d5ea09218L.CFBVxfh_MR0Uqy14zVJs0u2oF89gZ_jfBMyWJ2XzrDjcdWjKDIF0UpE3zxRr5mDNXMMtJp_nhRcMgxFXZdlXDwQ-- Reply-To: From: "Turner, Sean P." To: Subject: ECC Drafts Date: Mon, 30 Apr 2007 15:00:17 -0400 Organization: IECA, Inc. Message-ID: <027601c78b59$cace33d0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0277_01C78B38.43BC93D0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceLWcpz4W7/IDGNS0am1QiPzmzn7g== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 1.8 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0277_01C78B38.43BC93D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What's going on with the ECC drafts? spt ------=_NextPart_000_0277_01C78B38.43BC93D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECC Drafts

What's going on with the ECC = drafts?

spt

------=_NextPart_000_0277_01C78B38.43BC93D0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UJ54Sg015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 12:05:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UJ54C0015521; Mon, 30 Apr 2007 12:05:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3UJ4gHe015446 for ; Mon, 30 Apr 2007 12:05:03 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 20934 invoked from network); 30 Apr 2007 19:04:37 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.39.209 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 30 Apr 2007 19:04:37 -0000 X-YMail-OSG: jkqdg9gVM1m3d5ea09218L.CFBVxfh_MR0Uqy14zVJs0u2oF89gZ_jfBMyWJ2XzrDjcdWjKDIF0UpE3zxRr5mDNXMMtJp_nhRcMgxFXZdlXDwQ-- Reply-To: From: "Turner, Sean P." To: Subject: ECC Drafts Date: Mon, 30 Apr 2007 15:00:17 -0400 Organization: IECA, Inc. Message-ID: <027601c78b59$cace33d0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0277_01C78B38.43BC93D0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceLWcpz4W7/IDGNS0am1QiPzmzn7g== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0277_01C78B38.43BC93D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What's going on with the ECC drafts? spt ------=_NextPart_000_0277_01C78B38.43BC93D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECC Drafts

What's going on with the ECC = drafts?

spt

------=_NextPart_000_0277_01C78B38.43BC93D0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UE2gjc072188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 07:02:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UE2gsi072187; Mon, 30 Apr 2007 07:02:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UE2Kj9072153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 30 Apr 2007 07:02:41 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Mon, 30 Apr 2007 15:02:19 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Mon, 30 Apr 2007 15:02:09 +0100 From: Stefan Santesson To: Sam Hartman CC: Michael Myers , "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Date: Mon, 30 Apr 2007 15:01:57 +0100 Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Topic: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Index: AceK//uuLuOrz9YISlOaXS6aKHSMlQAMAfxg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3UE2fj8072182 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you Sam. I'm looking forward to your reply. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 30 april 2007 10:17 > To: Stefan Santesson > Cc: Michael Myers; ietf-pkix@imc.org; Stephen Kent; Tim Polk; Russ > Housley > Subject: Re: SRV SAN applicability statement - Was RE: Requested > changes to SRV SAN > > Hi. > > I'd like to apologize for not getting back to this sooner and for > (now) putting it off yet again. I'm about to get onto a plane to an > IESG retreat. I'll try to deal with this over the next couple of days > although I do have a few things ahead of it. I'll definitely discuss > with Tim. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U8HRFI023573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 01:17:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3U8HRk3023572; Mon, 30 Apr 2007 01:17:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U8H5Yv023506 for ; Mon, 30 Apr 2007 01:17:26 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73A4E49B8; Mon, 30 Apr 2007 04:17:03 -0400 (EDT) From: Sam Hartman To: Stefan Santesson Cc: Michael Myers , "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Subject: Re: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN References: Date: Mon, 30 Apr 2007 04:17:03 -0400 In-Reply-To: (Stefan Santesson's message of "Fri, 27 Apr 2007 18:38:23 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: Hi. I'd like to apologize for not getting back to this sooner and for (now) putting it off yet again. I'm about to get onto a plane to an IESG retreat. I'll try to deal with this over the next couple of days although I do have a few things ahead of it. I'll definitely discuss with Tim. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RIBJsk061954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 11:11:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RIBJtM061953; Fri, 27 Apr 2007 11:11:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RIBILU061941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 11:11:18 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3RIBFrY035000; Fri, 27 Apr 2007 11:11:15 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Denis Pinkas" , "Stefan Santesson" Cc: "pkix" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Fri, 27 Apr 2007 09:34:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I vote against this proposal as a PKIX standards-track work item. Should it be implemented and fielded in a scope that materially affects the Internet, then and only then publish an Informational. Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RI8KpR061628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 11:08:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RI8KvS061627; Fri, 27 Apr 2007 11:08:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3RI7xmj061517 for ; Fri, 27 Apr 2007 11:08:19 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 67043 invoked from network); 27 Apr 2007 18:07:50 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 27 Apr 2007 18:07:50 -0000 X-YMail-OSG: zasEo1kVM1nyxlxsxChxFzaoE1UHaGbztpo.wYIT4sZosKya1oJCyC78RV2D8DaxVA-- Message-ID: <46323DA8.7080301@connotech.com> Date: Fri, 27 Apr 2007 14:15:04 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Massimiliano Pala CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <462E4BFE.5060205@connotech.com> <46323988.3000704@cs.dartmouth.edu> In-Reply-To: <46323988.3000704@cs.dartmouth.edu> 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: Massimiliano Pala wrote: > Thierry Moreau wrote: > >> >> Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? >> >> If you think of DHCP, a look at SLP is certainly deserved. > > > Oh, I looked at that.. and it is quite interesting, although it is a bit > complicated, at a first glance. But it may be used in LANs to distribute > Request Query Authorities addresses. > Perhaps not just addresses, SLP "service attributes", for whatever use you may have in PKI resource discovery. >> I did the exercise with DNSSEC deployment, see >> http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt >> > > > Interesting, but can you be more specific on how this is related to the > problem I am trying to address ? Can you make an example ? > Ooops, I didn't mean that the above draft is helping your problem. Just an example of first attempt to make good use of SLP. > Thanks, > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHwreA060638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHwrUD060637; Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHwW2p060606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:58:53 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3RHw144034571; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Stefan Santesson" , "Sam Hartman" Cc: , "Stephen Kent" , "Tim Polk" , "Russ Housley" Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Date: Fri, 27 Apr 2007 09:21:13 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, I will give this some thought and respond if I come up with something useful. Until then, I can say immediately that I do not favor negative requirements. They cannot be tested. Mike -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Friday, April 27, 2007 9:38 AM To: Stefan Santesson; Sam Hartman; Michael Myers Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; Russ Housley Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN The discussion about SRVSAN applicability statement is stuck. And I would like to unstuck it. Do you think it is reasonable for an alt name RFC to state that the name MUST not be used in any protocol unless specifically allowed? Please see my e-mail below for an example where I think it would be unreasonable to make such restriction. If such restriction would be imposed, how should it be formulated? I personally don't think it can be reasonably formulated. When we have this issue sorted, I will go ahead and post an updated draft. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson > Sent: den 23 mars 2007 01:18 > To: 'Sam Hartman'; Michael Myers > Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; 'Russ Housley' > Subject: SRV SAN applicability statement - Was RE: Requested changes to > SRV SAN > > After some discussions face to face, it is clear to me that I have not > been successful in explaining my point. > > From what I have understood, Sam wants us to do is to say something > like the following: > The srv subjectAltName name form MUST NOT be used to validate the > identity of any entity unless the protocol within which the > identification is done explicitly specifies and permits the use of this > name form. > > Sam has told me that it would not be sufficient to require the use of > SRV SAN to be consistent with the protocol. It MUST be explicitly > allowed. > > > The rest of this mail intends to explain why this is unreasonable and > doesn't work. > I will first explain the general use case and then make an explicit > example. > > General use case > > 1) Client seek a service based on service name and domain. > 2) Client makes a query to the DNS server and receives a list of > suitable host names and their address. > 3) The Client contact one of the hosts suggested by DNS > 4) The client receive the certificate of that host > 5) The client verifies the identity of the host and determine if this > is a valid host for the requested service. > > Note that the information from the certificate is NOT used to construct > any DNS query. It is only used to validate the service host. > Note also that for this to happen at all, the service type asked for > MUST be supported by the DNS or you would not reach beyond step 2. So > for us to even consider the certificate in this case, we have an > automatic guarantee that at least the DNS supports this service name as > basis for host lookup. Thus it should already have passed the > applicability statement of RFC 2782. > > > Lets now take a specific case. > > 1) Client seeks the LDAP server of example.com > 2) Client makes a dns query for _ldap._tcp.example.com > 3a) Client receives the following list of suitable hosts: > ldap1.example.com and ldap2.example.com > 3b) Client contact ldap://ldap1.example.com and initiates a TLS session > according to RFC 4513 > 4) Client receives the server certificate from the TLS initialization. > 5) Client verifies the server certificate according to RFC 4513. > > Now. This server certificate has a subject DN with a number of > attributes that does not mean anything to the client. > The server certificate contains the dnsName SAN with the value > ldap1.example.com > The server certificate contains a SRV SAN otherName with the value > _ldap.example.com > > Through the dnsName SAN, the client will be assured that it is in fact > talking to the host ldap1.example.com. But unless the client can fully > trust the DNS, the client still don't know if this host is authorized > to provide the ldap service for this domain. If the DNS was spoofed, > the client could be talking to the wrong server. > > But, here the CA has also bound the key to the srv name > (_ldap.example.com). Through this name the client has an assertion from > the CA that this host is actually an authorized ldap server for the > example.com domain. > > Must the client disregard from this information. YES according to Sam > (If I understand him right). > > Because RFC 4513 does not explicitly mention and approve use of the SRV > SAN name form (And how could it, this name form is not an RFC yet) > > RFC 4513 states: > > 3.1.3. Server Identity Check > > In order to prevent man-in-the-middle attacks, the client MUST > verify > the server's identity (as presented in the server's Certificate > message). In this section, the client's understanding of the > server's identity (typically the identity used to establish the > transport connection) is called the "reference identity". > > The client determines the type (e.g., DNS name or IP address) of the > reference identity and performs a comparison between the reference > identity and each subjectAltName value of the corresponding type > until a match is produced. Once a match is produced, the server's > identity has been verified, and the server identity check is > complete. > > > This text is 100% consistent with using srv san otherName even though > it is not explicitly mentioned. > > So we have a case where use of DNS lookup for a service type that > established and supported by DNS servers as well as having an IANA > registered service name. We have a security protocol that provides > freedom for clients to define what a "reference identity" is. Yet we > would not be allowed to use the only name in the certificate that gives > the client what it needs to verify the host. > > That does not make any sense to me at all. > > Why is it necessary to update RFC 4513 to make it legal to use this > name form when its use is already consistent with the standard? > What if I have a privately defined SAN otherName, can I use that? I > think RFC 4513 clearly allows that. > What if that privately defined otherName contains exactly the same info > as our SRV SAN, can I use it? > > Please clarify if I have understood you wrong Sam. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 22 mars 2007 09:46 > > To: Michael Myers > > Cc: Stefan Santesson; ietf-pkix@imc.org; Stephen Kent; Tim Polk > > Subject: Re: Requested changes to SRV SAN > > > > >>>>> "Michael" == Michael Myers writes: > > > > >> Sam Hartman has a discuss requiring this document to say that > > >> this name form MUST NOT be used unless explicitly allowed by > > >> the protocol being used. > > > > Michael> Because . . . ? > > > > Two reasons. first, the SRV DNS RR definition has a very strong > > applicability statement. SRV records cannot be used except when a > > protocol specifically defines their use. This increases > > interoperability. You don't want some domains using MX to find mail > > servers and others using _smtp._tcp.domain SRV records. We should be > > consistent with the SRV spec wehn definining name types for use with > > those records. > > > > Second, the underlying interoperability concerns for this name type > > apply the are the same as for SRV records. We've had enough trouble > > with interoperability concerns caused by CN and email address in the > > subject name vs subjectAltName choices. We don't want to introduce > > other situations where there are multiple ways of naming the same > > entity without need to do so. > > > > --Sam Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHw1U4060539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHw1KW060538; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHveCo060482 for ; Fri, 27 Apr 2007 10:58:01 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 61B5627; Fri, 27 Apr 2007 19:57:39 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11612-05; Fri, 27 Apr 2007 19:57:37 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id F3BFA22; Fri, 27 Apr 2007 19:57:36 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042719573526:225995 ; Fri, 27 Apr 2007 19:57:35 +0200 Message-ID: <4632390D.2020509@edelweb.fr> Date: Fri, 27 Apr 2007 19:55:25 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Stefan Santesson Cc: Denis Pinkas , pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/27/2007 07:57:35 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/27/2007 07:57:36 PM, Serialize complete at 04/27/2007 07:57:36 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050503030504010403090802" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050503030504010403090802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > Denis, > > I have read your e-mail and your draft, at least a majority of it. It > does not provide the answers I need. > > I need you to motivate why we need yet another protocol for on-line > status checking. > A "Read the document" reply is not sufficient for me. > > I don't want a list of technical features you provide. I want an > analysis of the impact of the industry. > Personally I'm totally against writing yet another protocol for this, > and you have so far not been able to convince me. > > I have read the text, and I am waiting to at least a response to one question concerning the service (send some days ago). I also agree with all those who do not want yet another protocol just for certficate verification. As a detail, the definition of the initial verification, revalidation, the required inputs for both cases, their security feature, the requirements for external access to a repository or not, is very unclear, thus difficult to compare with SCVP, XKMS, OCSP, DVCS --------------ms050503030504010403090802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1NTI1WjAjBgkqhkiG9w0B CQQxFgQUxKSYzcAJwb5oHFGPbfbKkrDDerQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAnXx43cDBMLSe8awf 2N42X8s6SGw2dH+sT/xYR6rdTHGP5byesmAXUNcglxQxDqyG3NSW4rT4L3kQyNAFnP+h2uup h/RYb9Yb8IQVL00ctTSfy+uAaLfoDUJoBjPCxmivjAn6N63q1BQ/bMBi23fAcoAz7RuYVrHG JHYUthAvhuAAAAAAAAA= --------------ms050503030504010403090802-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHvavI060480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:57:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHva1o060479; Fri, 27 Apr 2007 10:57:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHvYCr060473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:57:35 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3RHvRL7031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2007 13:57:30 -0400 Message-ID: <46323988.3000704@cs.dartmouth.edu> Date: Fri, 27 Apr 2007 13:57:28 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Thierry Moreau CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <462E4BFE.5060205@connotech.com> In-Reply-To: <462E4BFE.5060205@connotech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005020009010300070008" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090005020009010300070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thierry Moreau wrote: > > Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? > > If you think of DHCP, a look at SLP is certainly deserved. Oh, I looked at that.. and it is quite interesting, although it is a bit complicated, at a first glance. But it may be used in LANs to distribute Request Query Authorities addresses. > I did the exercise with DNSSEC deployment, see > http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt Interesting, but can you be more specific on how this is related to the problem I am trying to address ? Can you make an example ? Thanks, -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms090005020009010300070008 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1NzI4WjAjBgkqhkiG9w0B CQQxFgQUV9sjqEEqC+rNkkqyIRwsLFs3Po4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYCW0rrLBd6KtuLlCJ3Oq8xh e8WgvzbBxHgPFme00zJFXI2jyBTvHpHREwSFnU4Auii84nZr5tohtcax3MGE6W8Cv+X1a371 +auhwr9T3Ly4yWqwf+zBjFhA+SOsiheAIhrtOZzOq9xrWBupWLnhKyilNopLnpXLmoegg+/I C28kmwAAAAAAAA== --------------ms090005020009010300070008-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHrrHH060142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:53:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHrrHE060141; Fri, 27 Apr 2007 10:53:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHrWN1060114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 10:53:53 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3RHrEki030813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2007 13:53:15 -0400 Message-ID: <4632388B.9070505@cs.dartmouth.edu> Date: Fri, 27 Apr 2007 13:53:15 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Anders Rundgren CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery Protocol - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> <000401c78699$ee787b20$82c5a8c0@arport2v> In-Reply-To: <000401c78699$ee787b20$82c5a8c0@arport2v> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000508060103080108030401" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000508060103080108030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > Hi Max, Hi Anders, > Some time ago you proposed new PKI protocols but then you did > not state any specific use-case. I'm happy to see such now :-) Yep, I finally had time to work on a practical implementation of the idea and figure out what can really be implemented and how easy would this be in practice. > Regarding painful rollover, I believe a 5-year plan or so is realistic > if it involves certificate changes. If the idea is really some kind of > "mapping scheme" between existing certificates and services it may > be faster but OTOH I don't really see how such a mapping utility > would work given the huge variations out there. But maybe you > are thinking of some kind of centralized discovery service? Sort of. For the rollover idea, I was thinking about switching to one service to another. For example a CA that wants to switch from CRLs to OCSP, it would not have to reissue all the valid certificates to have the clients to discover the new available service and not use the old one. Thinking about the future, this would really give the possibility to add/remove/move offered services by providing an easy way for CA management to do so. In the future-future, if this protocol is adopted, we can also think about an authority who will manage a network of Registration Authorities like the DNS, but for now, we should stay focused on this first step. > Personally I'm only interested in decentralized Internet-scale PKI > solutions (the opposite to S/MIME...) and would due to this base > a new scheme on the only Internet-scale "registry" there is: DNS. My solution is like DNS, but it is not hierarchical-more P2P based. I will present the idea at EuroPKI---unfortunately because of grant rules I can not forward the paper, yet. > I would suggest a scheme based on DNS names which both can > be obtained locally (from a config file) as well as being supplied > in a new certificate extension. This would allow step-wise migration > which has proved to be the fastest route to adoption. The following > is one way of architecting this: > > In the repository/certificate extension: "example.com" > > Searched for by an enhanced PKI client: > _thesuperduper-pki-lookup.example.com TXT "something" > _other-pki-lookup-service.example.com TXT "something" I am not sure about what you are saying here. If the DNS is used to store addresses to services, you can use DNS SRV records. But actually it is quite difficult, when you have a certificate, figuring out which is the DNS that has the information you need because there is not (usually) a direct mapping between DNS and certificates contents (if no DC is used). A PRQP would allow to map services also for CAs using X500 names. Another aspect to consider is that CA management do not always have direct control over the DNS, which is usually in charge of the networking people (but this may vary across different environments...). My point here is that based on my experience, DNS is not really the simplest solution to solve the PKI Resource Discovery problem... > Regarding applications, I would like to add automatic certificate > renewal services support. In this respect the PRQP could provide the URL where the application could apply for renewal of a certificate. A simple message could then be exchanged and the certificate issued without a single configuration provided from the user... -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms000508060103080108030401 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI3MTc1MzE1WjAjBgkqhkiG9w0B CQQxFgQUsogDQzIAH5BqBEZaqDGsDrmQcH4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYAA/HSu1hvRQub6pOVXT8zd Lxp+mkPdTX0kkYqvyCyc1SjcT//0Z5J8ubxuNizgh9W9b744RgmQ2Uu3CZDtROay0cAaN7fc Afu/y9tidCf7BU2zpKWFdC40ovPrfrQBJv69lheA7OPoD6SpRxuSWcSnsW7CiBNsAeg+yNe+ LUZNSwAAAAAAAA== --------------ms000508060103080108030401-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHddHK058960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:39:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHddpO058959; Fri, 27 Apr 2007 10:39:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHdHDW058937 for ; Fri, 27 Apr 2007 10:39:38 -0700 (MST) (envelope-from shitchings@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Fri, 27 Apr 2007 13:38:58 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01B3_01C788B8.433C3E10" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) thread-index: AceGeUnya1PIh0LESQSwo2yFejxeEQCeQvpA References: From: "Seth Hitchings" To: "Denis Pinkas" , "Tim Polk" Cc: "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_01B3_01C788B8.433C3E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Denis, If SCVP did not require clients to support protected responses, would you still find sufficient need to develop a new protocol? I think that there's some room for clarification as to whether a response received via a protected transport mechanism is in fact protected and therefore shouldn't require CMS encapsulation. I'm not advocating changing SCVP at this stage, mind you. Seth -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, April 24, 2007 1:32 AM To: Tim Polk Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Tim, Thank you for your time for reviewing LCVP. See my responses below. >Denis, > >I finally found some time this weekend to review the LCVP >specification. I thought it was important to avoid snap judgements. >After reviewing the specification, I do not see a justification for >pursuing this document. > >If we consider this specification from a DPV client viewpoint, there >are very few differences between an LCVP client and the minimal SCVP >client. You identify the following differences (my numbering for >clarity): > > (1) the protocol only supports DPV, i.e. it includes no provision >to support Delegated Path Discovery (DPD); > (2) requests and responses are not signed, since they are protected >by TLS, where clients are not authenticated; > (3) validation is only for one certificate at a time; > (4) there is no specific parameter in the request to add any >parameter to a validation policy known by the server. > >However, this overstates the differences. (1) SCVP implementations are >not required to implement both DPD and DPV. (2) SCVP clients and >servers MUST support protected (e.g., signed) responses, but the client >may choose to use TLS as a protected transport to protect the >responses. This single argument (i.e. SCVP clients and servers MUST support protected (e.g., signed) responses) illustrates why it not make sense to mandate such a support when only transport layer security is being used. This means it is not effective to profile SCVP to only fulfill the requirements addressed by LCVP. >(3) Clients are not only permitted to submit requests one certificate >at a time, conforming client implementations are not required to >support multi-certificate requests. (4) As in 3, modifying the >validation policy need not be supported by conforming clients. > >In short, LCVP does not provide functionality that is unavailable in >SCVP. This is incorrect. Please take a look at: validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, The meaning of producedAt in SCVP is different from the meaning of validationTime in LCVP. LCVP with this parameter may support the validation of certificates used for non repudiation puroposes, whereas SCVP can't. See the explanations about the grace period fullSubjectName allows to handle unique names, whereas SCVP can't. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. Of course, using four new OIDs it would be possible to expand SCVP to support these parameters, but it wan't be as simple as in LCVP. >While LCVP's ASN.1 appears less complicated, I am glad you acknowlege the fact that LCVP is simpler than SCVP. > the data structures generated by minimally conforming SCVP DPV-only >client implementations appear to have similar levels of complexity. I do not think so. Beside the unneeded complexity of the response which results from the use of CMS: ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } there is a lot of OIDs to manage. Another example of overcomplexity is the mandatory use of the following OID { id-svp 1 } to specify the default validation policy, while LCVP may simply omit the parameter: valPolicyRef ValPolicyRef OPTIONAL, Furthermore, where LCVP allows any default validation policy, in SCVP : " The default validation policy MUST use the basic validation algorithm as its default validation algorithm". There is a French common saying, which states roughly the following: " Why keep it simple, when you can make it complicated ?" It would perfectly apply to an SCVP profile (if any was possible). >I cannot see any reason to pursue a new DPV protocol that ignores the >requirements established in 3379 within the IETF. It does not ignore them, but does not take all of them. > I can see the >rationale for a lightweight client profile for SCVP, as suggested by >others on this list, to demonstrate how simple an SCVP client can >actually be. A lightweight client profile for SCVP is not realistic without changing SCVP. SCVP is already in the hands of the RFC editor for publication as an RFC. Denis >Thanks, > >Tim Polk > >On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > >> >> >> I needed a simple protocol to delegate the validation of a >> certificate to a server, to be used in environments where a client >> does not need to demonstrate to somebody else that it got a given >> response from a server. This implies that the server is fully trusted >> by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does not >> mean "Simple", or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests is not needed, and the use of a subset of >> the various OIDs is not trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight Certificate Validation Protocol (LCVP), like LDAP is >> simpler than DAP. :-) >> >> LCVP only supports a subset of the mandatory requirements described >> in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to a >> trusted server. The path validation (e.g. making sure that none of >> the certificates in the path are revoked) is performed according to a >> set of rules called a validation policy. It allows simplification of >> client implementations and only uses of a set of validation policies >> known by the server. The document defines a protocol that can be >> used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet >> been implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be re-targeted to the standard track category. >> >> Denis >> >> > > Regards, Denis Pinkas ------=_NextPart_000_01B3_01C788B8.433C3E10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3DCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA5IwggL7oAMCAQICAgCiMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNzE0NDgzNloXDTA3 MDkyNjE0NDgzNlowajELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEXMBUG A1UEAxMOU2V0aCBIaXRjaGluZ3MxKDAmBgkqhkiG9w0BCQEWGXNoaXRjaGluZ3NAY29yZXN0cmVl dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDULuw99zAAo0bVVJO8Muclrezh TKZpRgvLmNtEMSgZQHezFesdIs3MM1V4dT7rmf8JIm9ugAZrYrpOK79402QQvFhY4gVaBkPQflR3 u/yKvVO8BWcKeaCZAu9SiHW9MqMMSkh+qX8b3Var9T/6clbxMeCx37wByra6uvAPKfZUmnTERMqF IybXd5rkejV6Sn3Madu4iYh3FWd8sQEWV2Pqpz9IBjMRzXOKfFEPbopvGOCiXtnyzTiz00yh8JDe UZWf9K0jhBG7u8KeebWyxfANPbgnn89lCFZjkAz0aEhJpXxwsWqnjH1S6IfvnWxu59J5pecAAizr +iKDhaiwaBPZAgMBAAGjgdowgdcwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0 dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwJAYDVR0RBB0wG4EZc2hp dGNoaW5nc0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBA BggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJl ZXQuY29tLzANBgkqhkiG9w0BAQUFAAOBgQB0vJkV8SBdmz9K5S+Tw+0o1G08vfYQRDYcOzyoriV7 gZi8/vmnaUL7GMYRaEv3ei7LyLDXIm2FJSH5bZACEIR5Jhl5QWByV6F8EdlOYRUKn/PQgNhqWH9q B6I+Sn/Tqfgtm3ssboe6yJFBIQnk9S3WmIxHhGCPptQ0fvM8jy9BwzGCAx0wggMZAgEBMFgwUjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVl dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCiMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyNzE3Mzg1OFowIwYJKoZIhvcNAQkEMRYE FBLpOEElt/6LaSpte4DICeZDS7ohMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMGcGCSsGAQQBgjcQBDFaMFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0Nv cmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkC AgCiMGkGCyqGSIb3DQEJEAILMVqgWDBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVl dCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICAKIwDQYJ KoZIhvcNAQEBBQAEggEAFwiHUcb0nSQkiqHqqNo6VsbiCbl+4uYngx1pvaw80+PH3EBlZCqEDae6 6QLL7rMa7qRtSiwanKRbAjtXrByHQlYAA4fVXF+z7TN1iivDO3jC/4/D4uSueyJVfXCajsIpBORZ +y9a84SbI/wlPY//P4eDyrsyUzkDtTQAHTIPlR85/TCNfVO8djQfMBnv9vz6T+dcV6JQh021icMX K9ydNlMfkdYxW/gzYxdo1bCfAr/6LhZ9PfLb9KCeYKa0dx2CBZbtpFc7ezcMQpRVrEMnEpsXI0aZ Mdx99Wf+aVFl/sR6ChY3xes0UAmj42IaxwRR5BPAaSmwwtMRUaAlNxMrNgAAAAAAAA== ------=_NextPart_000_01B3_01C788B8.433C3E10-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHcvXR058927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:38:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHcuMY058926; Fri, 27 Apr 2007 10:38:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHcWnt058912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 10:38:55 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 18:38:32 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 27 Apr 2007 18:38:31 +0100 From: Stefan Santesson To: Stefan Santesson , Sam Hartman , Michael Myers CC: "ietf-pkix@imc.org" , Stephen Kent , Tim Polk , Russ Housley Date: Fri, 27 Apr 2007 18:38:23 +0100 Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Topic: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN Thread-Index: AcdsXovylPq1PkzrQG66Ae6cnmfEuQAN2k7gBxcM2DA= Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RHcuns058920 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The discussion about SRVSAN applicability statement is stuck. And I would like to unstuck it. Do you think it is reasonable for an alt name RFC to state that the name MUST not be used in any protocol unless specifically allowed? Please see my e-mail below for an example where I think it would be unreasonable to make such restriction. If such restriction would be imposed, how should it be formulated? I personally don't think it can be reasonably formulated. When we have this issue sorted, I will go ahead and post an updated draft. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson > Sent: den 23 mars 2007 01:18 > To: 'Sam Hartman'; Michael Myers > Cc: ietf-pkix@imc.org; Stephen Kent; Tim Polk; 'Russ Housley' > Subject: SRV SAN applicability statement - Was RE: Requested changes to > SRV SAN > > After some discussions face to face, it is clear to me that I have not > been successful in explaining my point. > > From what I have understood, Sam wants us to do is to say something > like the following: > The srv subjectAltName name form MUST NOT be used to validate the > identity of any entity unless the protocol within which the > identification is done explicitly specifies and permits the use of this > name form. > > Sam has told me that it would not be sufficient to require the use of > SRV SAN to be consistent with the protocol. It MUST be explicitly > allowed. > > > The rest of this mail intends to explain why this is unreasonable and > doesn't work. > I will first explain the general use case and then make an explicit > example. > > General use case > > 1) Client seek a service based on service name and domain. > 2) Client makes a query to the DNS server and receives a list of > suitable host names and their address. > 3) The Client contact one of the hosts suggested by DNS > 4) The client receive the certificate of that host > 5) The client verifies the identity of the host and determine if this > is a valid host for the requested service. > > Note that the information from the certificate is NOT used to construct > any DNS query. It is only used to validate the service host. > Note also that for this to happen at all, the service type asked for > MUST be supported by the DNS or you would not reach beyond step 2. So > for us to even consider the certificate in this case, we have an > automatic guarantee that at least the DNS supports this service name as > basis for host lookup. Thus it should already have passed the > applicability statement of RFC 2782. > > > Lets now take a specific case. > > 1) Client seeks the LDAP server of example.com > 2) Client makes a dns query for _ldap._tcp.example.com > 3a) Client receives the following list of suitable hosts: > ldap1.example.com and ldap2.example.com > 3b) Client contact ldap://ldap1.example.com and initiates a TLS session > according to RFC 4513 > 4) Client receives the server certificate from the TLS initialization. > 5) Client verifies the server certificate according to RFC 4513. > > Now. This server certificate has a subject DN with a number of > attributes that does not mean anything to the client. > The server certificate contains the dnsName SAN with the value > ldap1.example.com > The server certificate contains a SRV SAN otherName with the value > _ldap.example.com > > Through the dnsName SAN, the client will be assured that it is in fact > talking to the host ldap1.example.com. But unless the client can fully > trust the DNS, the client still don't know if this host is authorized > to provide the ldap service for this domain. If the DNS was spoofed, > the client could be talking to the wrong server. > > But, here the CA has also bound the key to the srv name > (_ldap.example.com). Through this name the client has an assertion from > the CA that this host is actually an authorized ldap server for the > example.com domain. > > Must the client disregard from this information. YES according to Sam > (If I understand him right). > > Because RFC 4513 does not explicitly mention and approve use of the SRV > SAN name form (And how could it, this name form is not an RFC yet) > > RFC 4513 states: > > 3.1.3. Server Identity Check > > In order to prevent man-in-the-middle attacks, the client MUST > verify > the server's identity (as presented in the server's Certificate > message). In this section, the client's understanding of the > server's identity (typically the identity used to establish the > transport connection) is called the "reference identity". > > The client determines the type (e.g., DNS name or IP address) of the > reference identity and performs a comparison between the reference > identity and each subjectAltName value of the corresponding type > until a match is produced. Once a match is produced, the server's > identity has been verified, and the server identity check is > complete. > > > This text is 100% consistent with using srv san otherName even though > it is not explicitly mentioned. > > So we have a case where use of DNS lookup for a service type that > established and supported by DNS servers as well as having an IANA > registered service name. We have a security protocol that provides > freedom for clients to define what a "reference identity" is. Yet we > would not be allowed to use the only name in the certificate that gives > the client what it needs to verify the host. > > That does not make any sense to me at all. > > Why is it necessary to update RFC 4513 to make it legal to use this > name form when its use is already consistent with the standard? > What if I have a privately defined SAN otherName, can I use that? I > think RFC 4513 clearly allows that. > What if that privately defined otherName contains exactly the same info > as our SRV SAN, can I use it? > > Please clarify if I have understood you wrong Sam. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 22 mars 2007 09:46 > > To: Michael Myers > > Cc: Stefan Santesson; ietf-pkix@imc.org; Stephen Kent; Tim Polk > > Subject: Re: Requested changes to SRV SAN > > > > >>>>> "Michael" == Michael Myers writes: > > > > >> Sam Hartman has a discuss requiring this document to say that > > >> this name form MUST NOT be used unless explicitly allowed by > > >> the protocol being used. > > > > Michael> Because . . . ? > > > > Two reasons. first, the SRV DNS RR definition has a very strong > > applicability statement. SRV records cannot be used except when a > > protocol specifically defines their use. This increases > > interoperability. You don't want some domains using MX to find mail > > servers and others using _smtp._tcp.domain SRV records. We should be > > consistent with the SRV spec wehn definining name types for use with > > those records. > > > > Second, the underlying interoperability concerns for this name type > > apply the are the same as for SRV records. We've had enough trouble > > with interoperability concerns caused by CN and email address in the > > subject name vs subjectAltName choices. We don't want to introduce > > other situations where there are multiple ways of naming the same > > entity without need to do so. > > > > --Sam Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHBavi057932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:11:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHBauH057931; Fri, 27 Apr 2007 10:11:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHBB3P057899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 10:11:32 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 18:11:10 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 27 Apr 2007 18:11:10 +0100 From: Stefan Santesson To: Denis Pinkas CC: pkix Date: Fri, 27 Apr 2007 18:11:02 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceIzQgjVWKgQKasQMOJMRyoTS9KQQAHKnCQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RHBX3O057922 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I have read your e-mail and your draft, at least a majority of it. It does not provide the answers I need. I need you to motivate why we need yet another protocol for on-line status checking. A "Read the document" reply is not sufficient for me. I don't want a list of technical features you provide. I want an analysis of the impact of the industry. Personally I'm totally against writing yet another protocol for this, and you have so far not been able to convince me. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Sent: den 27 april 2007 15:07 > To: Stefan Santesson > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > > Stefan, > > >Denis, > > > >I'm trying to bring this discussion up above the technical details and > features. Listing of technical features does not stand as a motivation > for doing the job. > >You have to explain why these features are important to the industry > and why solving the same problem can't be done without the rather > extreme measure you propose. If you protocol was covering new areas of > standardization, you would be required to do less of motivation than, > as now is the case, your work overlaps with current standards. > > > >This would be the third alternative for on-line certificate status > checking: > >- OCSP > >- SCVP > >- LCVP > > I fear you have not fully read my e-mail. Please re-read carefully. > > >Quote: > >> LCVP supports additional parameters, whereas SCVP does not (please > >> read the draft for the details): > > > >So we would have a "Lightweight" version of a protocol that is richer > than the standard protocol. > > LCVP is a "Light" version of CVP, not a light version of a "Server- > based Validation Certificate Protocol > (alias SCVP)". > > >Good or bad, that logic can also be a hard sell. > > If you take the time to read the document, you will get the answers to > most of your questions. > If there are some points that are not well explained, I may help. > > Denis > > > > > > >Stefan Santesson > >Senior Program Manager > >Windows Security, Standards > > > > > >> -----Original Message----- > >> From: Denis Pinkas [mailto:denis.pinkas@bull.net] > >> Sent: den 27 april 2007 14:20 > >> To: Stefan Santesson > >> Cc: pkix > >> Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > >> > >> Stefan, > >> > >> >Denis, > >> > > >> >> LCVP only supports a subset of the mandatory requirements > described > >> in > >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP > is > >> >> not either a profile of SCVP. > >> > >> >This by itself is highly problematic. > >> > >> I fear that you stopped reading the document, after having read this > >> sentence, > >> otherwise you would have seen the benefits. :-) > >> > >> >As you state, this causes your draft to not be a profile of SCVP. > >> Instead it would technically > >> > be a 3rd alternative protocol for on-line certificate status > >> checking. > >> > >> ??? It is not a third alternative, but a second one. > >> > >> The goal of LCVP is NOT "on-line certificate status checking", but > on- > >> line certificate validation. > >> It is not intended to be used as an alternative to OCSP. > >> > >> >It would take extreme reasons to justify creation of such new > >> protocol. > >> > >> The main arguments to use LCVP are: > >> "It is simple and provides more benefits when compared to SCVP". > >> > >> The main argument to use SCVP is: > >> " Why keep it simple, when you can make it complicated ?" > >> > >> >I have a hard time seeing this happen unless we actually change > SCVP > >> > to allow your document to be a profile. But to take back SCVP at > this > >> stage > >> > to the working group and to re-shape the requirements would also > be > >> > very hard to motivate and extremely hard to get consensus on. > >> > >> A lightweight client profile for SCVP would not be realistic without > >> changing SCVP. > >> However, I am NOT in any way asking for any change to SCVP, which is > >> already > >> in the hands of the RFC editor. > >> > >> >I think you need to focus a lot more on the justification for this > >> work. > >> >Not only why it is useful, but why it is so extraordinary important > >> >that it motivates any of these measures. > >> > >> Besides simplicity, the other arguments have already be given in an > e- > >> mail sent to Tim. > >> Here there are again: > >> > >> LCVP supports additional parameters, whereas SCVP does not (please > >> read the draft for the details): > >> > >> validationTime GeneralizedTime, > >> fullSubjectName FullSubjectName, > >> keyUsage KeyUsage > OPTIONAL, > >> extKeyUsage ExtKeyUsageSyntax OPTIONAL, > >> > >> validationTime allows to support the validation of signer's > >> certificates used with electronic signatures > >> as specified by ETSI, in the case where the signature policy > includes a > >> grace period. > >> > >> SCVP is unable to do it, unless adding "yet another" extension. > >> > >> fullSubjectName allows to handle unique names, and thus avoids > >> intentional or deliberate DN collisions. > >> > >> SCVP is unable to do it, unless adding "yet another" extension or > >> asking the client > >> to interpret itself the CertBundle parameter. In the later case, the > >> client is no more a thin client. > >> > >> keyUsage and extKeyUsage simply allow a application to know these > >> parameters > >> without the need to process the certificate. It is for thin clients > and > >> allows them to know > >> the intended key usage(s) of the certificate. > >> > >> SCVP is unable to return that information, unless adding "yet other" > >> extensions. > >> > >> BTW, there is a syntax "error" in LCVP that needs to be corrected to > >> make it effectively "lightweight". > >> This error originated from the fact that I copied some of the ASN.1 > >> structures from SCVP. Since > >> SCVP is not lightweight anyway, this may not be a major problem, but > >> the next version of SCVP > >> could possibly take benefit of it. > >> > >> I let you discover it, unless someone else discovers it before you. > :-) > >> > >> It will obviously be corrected in the next version to be published. > >> > >> Denis > >> > >> >Stefan Santesson > >> >Senior Program Manager > >> >Windows Security, Standards > >> > > >> > > >> >> -----Original Message----- > >> >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > >> >> pkix@mail.imc.org] On Behalf Of Denis Pinkas > >> >> Sent: den 20 april 2007 14:19 > >> >> To: pkix > >> >> Subject: Lightweight Certificate Validation Protocol (LCVP) > >> >> > >> >> > >> >> > >> >> I needed a simple protocol to delegate the validation of a > >> certificate > >> >> to a server, > >> >> to be used in environments where a client does not need to > >> demonstrate > >> >> to somebody else that it got a given response from a server. This > >> >> implies > >> >> that the server is fully trusted by the client. > >> >> > >> >> I considered using a profile of SCVP. Remember that the "S" does > not > >> >> mean "Simple", > >> >> or "Standard" anymore, but "Server-based". > >> >> > >> >> However, the use of CMS to encapsulate everything and allowing to > >> >> optionally sign requests > >> >> is not needed, and the use of a subset of the various OIDs is not > >> >> trivial as well. > >> >> > >> >> I looked at other alternatives, outside the IETF, but they do not > >> >> provide an adequate answer. > >> >> > >> >> This proposal is for lightweight clients, hence why it is called > >> >> Lightweight > >> >> Certificate Validation Protocol (LCVP), like LDAP is simpler than > >> DAP. > >> >> :-) > >> >> > >> >> LCVP only supports a subset of the mandatory requirements > described > >> in > >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP > is > >> >> not either a profile of SCVP. > >> >> > >> >> The major differences with SCVP are the following: > >> >> > >> >> - the protocol only supports DPV, i.e. it includes no > provisions > >> >> to support Delegated Path Discovery (DPD); > >> >> > >> >> - requests and responses are not signed, since they are > protected > >> >> by TLS, where clients are not authenticated; > >> >> > >> >> - validation is only for one certificate at a time; > >> >> > >> >> - there is no specific parameter in the request to add any > >> >> parameter to a validation policy known by the server. > >> >> > >> >> LCVP allows a client to delegate certificate path validation to > >> >> a trusted server. The path validation (e.g. making sure that > none > >> >> of the certificates in the path are revoked) is performed > according > >> >> to a set of rules called a validation policy. It allows > >> simplification > >> >> of client implementations and only uses of a set of validation > >> policies > >> >> known by the server. The document defines a protocol > >> >> that can be used to: > >> >> > >> >> (1) validate one certificate according to one validation > >> policy, > >> >> (2) query the validation policies supported by an LCVP > server. > >> >> > >> >> At this time, the document is a strawman proposal and has not yet > >> been > >> >> implemented. > >> >> There are certainly errors in it and it can certainly be improved > - > >> >> while keeping it "light". > >> >> > >> >> At this time, the document is an individual draft targeted for > the > >> >> experimental category. > >> >> > >> >> The document is available at: > >> >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > >> >> > >> >> The document is proposed to the PKIX WG for consideration and > >> comments. > >> >> > >> >> If the WG, later on, finds this approach interresting, then the > >> >> document could be > >> >> re-targeted to the standard track category. > >> >> > >> >> Denis > >> >> > >> > >> Regards, > >> > >> Denis Pinkas > >> > >> > > Regards, > > Denis Pinkas > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RD7eTO033971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 06:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RD7e7c033970; Fri, 27 Apr 2007 06:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RD7abD033961 for ; Fri, 27 Apr 2007 06:07:38 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA40488; Fri, 27 Apr 2007 15:12:36 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042715073145:123445 ; Fri, 27 Apr 2007 15:07:31 +0200 Date: Fri, 27 Apr 2007 15:07:29 +0200 From: "Denis Pinkas" To: "Stefan Santesson" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 15:07:31, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 15:07:32, Serialize complete at 27/04/2007 15:07:32 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, >Denis, > >I'm trying to bring this discussion up above the technical details and features. Listing of technical features does not stand as a motivation for doing the job. >You have to explain why these features are important to the industry and why solving the same problem can't be done without the rather extreme measure you propose. If you protocol was covering new areas of standardization, you would be required to do less of motivation than, as now is the case, your work overlaps with current standards. > >This would be the third alternative for on-line certificate status checking: >- OCSP >- SCVP >- LCVP I fear you have not fully read my e-mail. Please re-read carefully. >Quote: >> LCVP supports additional parameters, whereas SCVP does not (please >> read the draft for the details): > >So we would have a "Lightweight" version of a protocol that is richer than the standard protocol. LCVP is a "Light" version of CVP, not a light version of a "Server-based Validation Certificate Protocol (alias SCVP)". >Good or bad, that logic can also be a hard sell. If you take the time to read the document, you will get the answers to most of your questions. If there are some points that are not well explained, I may help. Denis > > >Stefan Santesson >Senior Program Manager >Windows Security, Standards > > >> -----Original Message----- >> From: Denis Pinkas [mailto:denis.pinkas@bull.net] >> Sent: den 27 april 2007 14:20 >> To: Stefan Santesson >> Cc: pkix >> Subject: Re: Lightweight Certificate Validation Protocol (LCVP) >> >> Stefan, >> >> >Denis, >> > >> >> LCVP only supports a subset of the mandatory requirements described >> in >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> >> not either a profile of SCVP. >> >> >This by itself is highly problematic. >> >> I fear that you stopped reading the document, after having read this >> sentence, >> otherwise you would have seen the benefits. :-) >> >> >As you state, this causes your draft to not be a profile of SCVP. >> Instead it would technically >> > be a 3rd alternative protocol for on-line certificate status >> checking. >> >> ??? It is not a third alternative, but a second one. >> >> The goal of LCVP is NOT "on-line certificate status checking", but on- >> line certificate validation. >> It is not intended to be used as an alternative to OCSP. >> >> >It would take extreme reasons to justify creation of such new >> protocol. >> >> The main arguments to use LCVP are: >> "It is simple and provides more benefits when compared to SCVP". >> >> The main argument to use SCVP is: >> " Why keep it simple, when you can make it complicated ?" >> >> >I have a hard time seeing this happen unless we actually change SCVP >> > to allow your document to be a profile. But to take back SCVP at this >> stage >> > to the working group and to re-shape the requirements would also be >> > very hard to motivate and extremely hard to get consensus on. >> >> A lightweight client profile for SCVP would not be realistic without >> changing SCVP. >> However, I am NOT in any way asking for any change to SCVP, which is >> already >> in the hands of the RFC editor. >> >> >I think you need to focus a lot more on the justification for this >> work. >> >Not only why it is useful, but why it is so extraordinary important >> >that it motivates any of these measures. >> >> Besides simplicity, the other arguments have already be given in an e- >> mail sent to Tim. >> Here there are again: >> >> LCVP supports additional parameters, whereas SCVP does not (please >> read the draft for the details): >> >> validationTime GeneralizedTime, >> fullSubjectName FullSubjectName, >> keyUsage KeyUsage OPTIONAL, >> extKeyUsage ExtKeyUsageSyntax OPTIONAL, >> >> validationTime allows to support the validation of signer's >> certificates used with electronic signatures >> as specified by ETSI, in the case where the signature policy includes a >> grace period. >> >> SCVP is unable to do it, unless adding "yet another" extension. >> >> fullSubjectName allows to handle unique names, and thus avoids >> intentional or deliberate DN collisions. >> >> SCVP is unable to do it, unless adding "yet another" extension or >> asking the client >> to interpret itself the CertBundle parameter. In the later case, the >> client is no more a thin client. >> >> keyUsage and extKeyUsage simply allow a application to know these >> parameters >> without the need to process the certificate. It is for thin clients and >> allows them to know >> the intended key usage(s) of the certificate. >> >> SCVP is unable to return that information, unless adding "yet other" >> extensions. >> >> BTW, there is a syntax "error" in LCVP that needs to be corrected to >> make it effectively "lightweight". >> This error originated from the fact that I copied some of the ASN.1 >> structures from SCVP. Since >> SCVP is not lightweight anyway, this may not be a major problem, but >> the next version of SCVP >> could possibly take benefit of it. >> >> I let you discover it, unless someone else discovers it before you. :-) >> >> It will obviously be corrected in the next version to be published. >> >> Denis >> >> >Stefan Santesson >> >Senior Program Manager >> >Windows Security, Standards >> > >> > >> >> -----Original Message----- >> >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- >> >> pkix@mail.imc.org] On Behalf Of Denis Pinkas >> >> Sent: den 20 april 2007 14:19 >> >> To: pkix >> >> Subject: Lightweight Certificate Validation Protocol (LCVP) >> >> >> >> >> >> >> >> I needed a simple protocol to delegate the validation of a >> certificate >> >> to a server, >> >> to be used in environments where a client does not need to >> demonstrate >> >> to somebody else that it got a given response from a server. This >> >> implies >> >> that the server is fully trusted by the client. >> >> >> >> I considered using a profile of SCVP. Remember that the "S" does not >> >> mean "Simple", >> >> or "Standard" anymore, but "Server-based". >> >> >> >> However, the use of CMS to encapsulate everything and allowing to >> >> optionally sign requests >> >> is not needed, and the use of a subset of the various OIDs is not >> >> trivial as well. >> >> >> >> I looked at other alternatives, outside the IETF, but they do not >> >> provide an adequate answer. >> >> >> >> This proposal is for lightweight clients, hence why it is called >> >> Lightweight >> >> Certificate Validation Protocol (LCVP), like LDAP is simpler than >> DAP. >> >> :-) >> >> >> >> LCVP only supports a subset of the mandatory requirements described >> in >> >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> >> not either a profile of SCVP. >> >> >> >> The major differences with SCVP are the following: >> >> >> >> - the protocol only supports DPV, i.e. it includes no provisions >> >> to support Delegated Path Discovery (DPD); >> >> >> >> - requests and responses are not signed, since they are protected >> >> by TLS, where clients are not authenticated; >> >> >> >> - validation is only for one certificate at a time; >> >> >> >> - there is no specific parameter in the request to add any >> >> parameter to a validation policy known by the server. >> >> >> >> LCVP allows a client to delegate certificate path validation to >> >> a trusted server. The path validation (e.g. making sure that none >> >> of the certificates in the path are revoked) is performed according >> >> to a set of rules called a validation policy. It allows >> simplification >> >> of client implementations and only uses of a set of validation >> policies >> >> known by the server. The document defines a protocol >> >> that can be used to: >> >> >> >> (1) validate one certificate according to one validation >> policy, >> >> (2) query the validation policies supported by an LCVP server. >> >> >> >> At this time, the document is a strawman proposal and has not yet >> been >> >> implemented. >> >> There are certainly errors in it and it can certainly be improved - >> >> while keeping it "light". >> >> >> >> At this time, the document is an individual draft targeted for the >> >> experimental category. >> >> >> >> The document is available at: >> >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> >> >> If the WG, later on, finds this approach interresting, then the >> >> document could be >> >> re-targeted to the standard track category. >> >> >> >> Denis >> >> >> >> Regards, >> >> Denis Pinkas >> >> Regards, Denis Pinkas Received: from [222.124.225.109] ([222.124.225.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCmmT5031681 for ; Fri, 27 Apr 2007 05:48:50 -0700 (MST) (envelope-from Hours@ownerdirect.com) Received: from scarnet1 by ownerdirect.com with ASMTP id 45F5BDC9 for ; Fri, 27 Apr 2007 19:49:36 +0700 Received: from scarnet1 ([192.113.148.20]) by ownerdirect.com with ESMTP id 014F7EC8EB48 for ; Fri, 27 Apr 2007 19:49:35 +0700 Message-ID: <001301c788ca$8146a350$6de17cde@scarnet1> From: "up our" To: ietf-pkix-archive@imc.org Subject: includes Date: Fri, 27 Apr 2007 19:49:33 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C78905.2DA57B50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 ------=_NextPart_000_000F_01C78905.2DA57B50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C78905.2DA57B50" ------=_NextPart_001_0010_01C78905.2DA57B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable By signing up our address order online. Powerpack tux plush newsletter gain. Week year shipped tracked worldwide = with privacy notice copyright. Minutes freespire fedora, ultimate packageno excuses this. Log in search = categories? Userslinux desktop cd core edgy eft mandriva sr. Securedvd activation key feisty lts, dvds powerpack. All currencies us = pound. Four of ubuntus variants one easy to use dvd. Dvds powerpack tux plush newsletter gain access valuable generous? = Shipping amp uslinks, ubuntu select four of. Updates additional software not included install disks, no more. = Securedvd activation key feisty lts dvds powerpack tux. Cd core edgy eft = mandriva sr plus securedvd, activation. Most innovative freedom loving. = Address order online hours day days week year shipped. Works you = complete updates additional software not included install. ------=_NextPart_001_0010_01C78905.2DA57B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
By signing up our address order = online.
Powerpack tux plush newsletter gain. = Week year=20 shipped tracked worldwide with privacy notice copyright.
Minutes freespire fedora, ultimate = packageno=20 excuses this. Log in search categories? Userslinux desktop cd core edgy = eft=20 mandriva sr.
Securedvd activation key feisty lts, = dvds=20 powerpack. All currencies us pound.
Four of ubuntus variants one easy to = use dvd.
Dvds powerpack tux plush newsletter = gain access=20 valuable generous? Shipping amp uslinks, ubuntu select four = of.
Updates additional software not = included install=20 disks, no more. Securedvd activation key feisty lts dvds powerpack tux. = Cd core=20 edgy eft mandriva sr plus securedvd, activation. Most innovative freedom = loving.=20 Address order online hours day days week year shipped. Works you = complete=20 updates additional software not included install.
------=_NextPart_001_0010_01C78905.2DA57B50-- ------=_NextPart_000_000F_01C78905.2DA57B50 Content-Type: image/gif; name="DVD.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c788ca$8146a350$6de17cde@scarnet1> R0lGODlhrAHYAYebAAAADoUAAABxDXt1DgAMcXcAfgh0ir++zLbUtqXA/UYSAFogAHgVAJwbALkV AOoVAAI7CyZIADxIBWtEDYdJBqVKALFKAOE7BABmABxSAU1cAGxUAHNaDpJVALtSBdNcAAWLACCC CkByCmJ9AIeJAKBzCLV7AOCGAACWBR6uADKqAG6RAXqRAqqaAMmhDOaaAAC+CxG4AErJAVrGA3bH AK66BsO6AufNAgXpABPiAkbkBWPWDYjsAKjeALHRANvXDQAAPyYAQUwJSmgARnQAO6QASrEATeAA MQAeSS0kRTElTGMeTYMjQJofQs0gPu4cRg1IPxNNO0JCN1FKQ3dAPKVGQbtDOe5FTgxYRhttQD5u PlRlToxgAKRZOL9TOepYNQGFMyV4PTWLN197MX1xO5aGPsqDTut5RACnQxyjTUytPF6kQ3ufPpSU ObmVNNWaRQLAOCm3Nj+xM2PIO3+9Tp+9ObW1O93OMgDcQhzmS0ziM1HZR4LqMp3XP7HnQdHdTAAD hh4Ae00AdmsJdX4AjaABg7wAdNEKgwAhjhctikAtc24kdHETfq4cfbgoitYjiQAzcypFh0NBhF1M e3o5ipE1ibYycdc5eQBYgiBSjD9delZufHVli5dje8VghOtbdQCDiCSCdTaNjG53gIKEe653hMiA fNyOiw6RghOfgTmtim2rhHqtha6fjLOne+KdhQC4dxy0czXLemTEeYe9eKm0erG0heG1gQLlhBbr eDXee2nVg3Tpe6Tsjb3Wi+vUhAkAyiMAxEcNwmMAwo4AvakAtL4AstsAyQYWziglxTYTyFwTsnMj v6MhvcolsdsbywxOthtBujc2vVQysYFFsZkxuL5GzeQ4tQBbvS5osz1fyVhczHdusqNdss1ittRf tgh+zBmNx0R5tliAsn97v5N3ybZywt55tQiovxipvkqZwGOayn6jtqmivMCWy+6lxwDAyxe1wjXO uWK1v3W+w6bMu///86aYrXiCfv8AAAD1Cvb/AAAA//0A+Qv/+PH/+SH5BAAx5j0ALAAAAACsAdgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWL/+xp3Mixo8ePIEOKHEmypMmTKE9iXMmypcuX MGPKnEmzps2bOHPq3Lkwpc+fQIMKHUq0qNGjPnkqXeoSqdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2I9OzaNOqXcu2rdu3cOPKnUt3Ztm7ePPq3cu3r9+/gJPWHUwzsOHDiE0SXsy4sePHOxNLnky5 suWRkDOjvcy5s1DNK3FchADarufTqA3D0QhjKADWISFA6AqjdurbuJ8C4bj7sIChv0UGdyoRSOnj yFsO7a2ReV7nBDRGl05gOsnq1aWDfL2Ruz3vJJ2D/z9p/Wny84Rdc/SOfSMw9xvbW3Xe+7095s5B 4teuEYD/5kD0tp9J5YnEz4H8dJRfUOg16KBC/kUIgEET/lOhhQIZl2FDAWqI4YXAhEgQdgJFKBAB J56IHYoLXVjhiwWxmOKMIYo4UI0C4fiPjCbOuONAFz4o5JAryfhjiT3+yKOEDAFzI5JARokhQU5K CeNDLpaoIkFBVvlPlVn+w09BQY555JFhTknkmg6q151GCcL5pncLiiQhd+CtON149Mn53ZsjeYcn R9n9Caihgmo5IkEaeqihjEayKemkDRnJIqSLSqlmQkFuqOmTXIaqZpIt9tjplUCaKmWkXfYHqHXW jf+X26yoXRTkhSuKmmqnCIV5q5Vk3pSkl70Cq+uUmI5K6bLJBRbhof39152038kKlqDxFWpPobFS mxez4FZE67j2hGvuceSmq+667Lbr7rvwfqUUrzzR25a95+arb7AS4ZuTvzIBzC9B8RZs8Ho/WauV wlMJSu2z0LK778ScUugflxcrKjCTuzZ05Yuk1oSqospSbPLEpxo75YQCl5xmxSuT7GLGH3bsMc0g Y5wkrwf3bNlFCgxcYQADEf1PAEYzFGbSSSdE9NNHC8S01EUL1EADA2FttdIqH21000X7LDZnQBfk wEBnR031Pw+w3dDU/6QdN0Nn1z232mojrbdA+RD/pMDffyvNcdsE9V1ym2PHexHYWv+jddACQa51 4wlB/g/kcC+0wECbRz4Q5gY1LXdDhhfOdz6le9002HMl7rpZFl19NdoOjC571WsnVHrpgDuUueWg r2053qxTKGXxJyc/pM+1O7BRAx01bxLE9gQwlfLYZ6/99ty79Xq63Ycv/vgUfW/++ehzRf5S6Uu8 Pvntxy///PTXbz9f7+N0//789+///wAMoAClkr+XDPCASCmgAg+CwAY68IHuWqAEJwgZCFrwgkah oAY3yMEOevCDIAyhCCeCwRKa8IQoTKEKV8hCoozwhTCMoQwH0sKrzPCGOHRIDXfIwx76sH45DKIQ /4dIxCJm5IdITKJGrCcZhinxiVhxYl+cZw8FpGQBUOzhSmT3OJ2MDiMtO8jwjEhGhBAFeh3RGxOf ArEHIIWJeKKePWSHsNyUETlDoWJHrKgRPlYPaRyRXh8BxxFCaoQBaQQkSagHOD9SkY9+5KMe9ShF kNxxhkOZjUewZQ9NdtIjFNBIKEVJylIyAJEb8eRI1sjEUdpjlLB0lSzvlErwXfIxQ0HBRzypSdn4 MpW//KRGeulLVcpGIxgwCS+HWUt76NIewUkmMjXyzI5UEoi3XEkmd9lMVWoEBxsBJzQ3EhxvcqSc yuxmM5+pSWnaQ5rudKdXstk9ogyHnPgcp0aCM/+caG5EmvrYSEDfiYF4mkSc9hDnMt/JTHu0Bjas sU3EIEhPHRKlNhIFCQo2ypFiUnOj1ayWE/Ux0JEU1J0IRWgWV4oZtsBgfCx1XVtEU9Ga2jSGMc2p CW9qUZ36VGw8DapQi/jTov5lqOIzqlKXylSVIPWpUK1nU6MS1bpM9TZV7clVt8pVFmZVm10Nq1jH StaymvWs3/tqQtB6FLWqha0ZdOtm4BoWuV6EpXbdF13Xlde+6m+vlvSrYM/zw8Ea9rByBSxgDKtY eCH2sYxpbABDSkDI6mRhVckoUswplnv25aFYQexJMSCQlyLEtCiYCMcOktqBkLYlr3WLaQdDml3/ 0Ywgo41tyKBKFCigpE4mAa1IjBlcjArXmnkBLUY3IqDmfMZWPaptQwQgEDAMxLqWPQh2C7LdDg1E Q9sFg3gZ4iFGBei64/2HdznE3fSqd70CEYB8oRsk+CYEvNf1VKMaIt7t/qO/FmEZQfy7VjBsxMAa QbBiC+TcjkznwQ02SY2YS+Ft8ea3+olwbxg8lOkA9yMQ5s9uRnwflNjnmhu5r3rNe16FlJdEX+3w R5gjIf7ESVvkkSWi6kgga0LMPvawz4FciCAzVcchLPISmGrWshpV6cgYgXGMEmKpgUQquyQTlZIV Vd7bMoRFvqISRMo0EDO9zMsRSVaOiFWswznK/2OfQnO/NuUjg1S5zrx1Ux05WR/knoQ7cbJHnAJt qOnxeFA6jnDCIlZJh4GHkyMZ0ER9kqA4ARnIj+7IpSUbLWnRqUMaOXGnS1LjaXmH0NUy9HogVmpB D3koTh71VkotR41EpEPl1VGWebVbLKMnjAUEtq+H/S9iG/vYcuG0stWH7Gazb9nQtiGl5IwTYevE 2s7GiJ4RXZVWL1LPQEHxrD/CMOrRMtohsdWnhLVumDEF28IiFbVfluVsxyTMSII3nDU2Kpz5+1b/ ltm/AU5vtQg4VPait77tPebDaYpjB7cQtYUGJZntumt0RpXGjUdng29qZLpKGcMVQhQsYrGPG/9p 5BI3wkRFduTkIlEjyw+N8pSr/I8cuVodWbnynlfRkGssyb8GTi/g+W3kNYHa1hyXtdwZ7YurdZpB hmf0f3TOcwd5AOEEUjusw213XEcb1t/Stq2P3Wxix51pprqSphmucVoLk9kzp7vQhTzLdL9cQSAX PLXBfeyQS93dwq72TTUtSFQ3SEjyYQ/GcyTok9yIHv2I7nRjZHRJa6TTz15wgwhe7wS5Xb33JhCt bz1JwAvc5qVG+jGmzuyJ59zR0750xa/aWxpxY8oL+bfHV76lOVFj6QuCOtTJ8ItrUizlWbj831dG bzVEuvTX7vzqWx9/jN3m9YGiGZC2dic0JZL/Pg5C3ek/ZNsQrQpnd7n+XNLKoxvR7PYDW5HZztYi vtz3QmL7j/tDKOoFMX4NwhGtcVy/4VkdcVzz5xP9NE3fhAMqZVzflFAeoVIhIV8ISIAcYYGB0hHB BE0YuIEQeBmvAR4PpYDxh4KVhxHG4SEE1n/VlV//MF8DAQU2CAUQIV3whVHxRYNccxAagoMCIYTl dRz514MYmBAvKH1EYWAK5h39hWCcdE8KpmAlERwD4hxWSBJbiGs6xh3idRpO2BEZWGFU5VZEER3W 0VwNBiv88YYcFhIhZmElFh8oUR5uSId6uC1xmBgkdmEh8WHRthK/UjLJ0ilF9mVS9mZn0nEK/2Ek YWImYlIQkshxdXZndUYsQWIkXcYoHGJfmVgQRWh+YBRyO9Mjo2gRh3gsP2hbApGI+faImfKKx1KJ hegpF3dEfbhJ4eFnC6gVuygU5qYggshj8OJEB9FrpGgTyriMefWLDMKE0DiN1FiNKbETIFdTBDdx 1KdUhKgqbTZUt/h/trVwIyds2UhPENeKllgQ02gtjgYo8fhDJXh7CeduztgiychxH6ONjuiIAPiP wwZuh0JrsyRuKAQxA3N37XZsBDlL8phouAdumQYtFZloh4GQIVGPhQZpkFZoxDFsvGZxMcOKcxZn xzKOKpmSJomSLpmLMPlxLVksM3OLaWKOfv9VFDfHStBXRYkUdEABlFMRdJQHcz65EUYZdEZJeUEX dODRlCGRlCWxAFRplCTRkz5njfWjkXehe1ppjWgEFfk4lnP1lc6XWNGmR2ZJEnKBPCL0Rc1DFz61 Eqd0SmghXbUlXd1TTAJBAQPhl2R5E/x3EaT1WuX3DyfFEHhpEIk5EBh4mG/VFQcIEpx1br94EZBJ EDwoEHw5EBAYfrLhmAIxmAqxmB1XfoeZmQNBUgLYGD9RgB4hfxtBWdCImeQnmiXzfa2ll+Xnf/p4 IYc5WiT5Ur6Jk4sBUrfJmIHpjkLxTCCFTKPlgAwlUp62ZygRUCXVS+s0m/t0T942K7pEm+b/1H+b GZjux53T2VHb6YEcMVBlCBKwuU/yOZ8NqE9fiBgq9Z4ekUzS9JEfoYJrGRIpdZ8UOIHCJEzgUU0n pWrUNJvP+VEcVaAEGhLCFVLgoUoRaIwJuoEcEVLy1H72eHskAaABSpkfuFzpB1ohiBTCBaKA4lmP ORKqBB5UyBGrkU8SaYxWSKInwaP26VsaAaQlOiv9dWAFU4x1CCDFuJzmOY1M+qQMNKRSylQOUYlQ ChFE8Z06xR2eyCm31YxX2o42w1OrNXFhomY99YtAVpChFiJBtqa1ZkIcaYwbCYcpFqb/d5Mzcili OkMRZ2ULAWWxiKcN5zL8lm/GuUAh0zIb/0eoDtGo/ehwxZYWK/mSLfGnjEqSjtqKO3OondeOlRqT oSqTljqqpjqTpApn43g4jXpZbKWl1tmRcUpuGlqrk5ajFmmruIqRWaqrdiJHwCqipiYYmypDiZqo ZMlVFYGsY7l9xXqOz/prUqdAYNM7+KhGQll9hGF2e1dAc0RHRxmue9R8vKqtFlF8xjcTn9eQJiMS buSVexSVHxGW89d2LGGtViN6EnchyCc+fbOu/rKuY7SMOokw3iFI9mB6CQuvG+F4jtd4NXeU2do+ xdcR9EqraTSlJaGWp4SxkBSxpQZzJ+eVuqeW9POut1ou9SaQ01ewEdM8VNRyPcdJkXRIG/+BSuRa MOKGSKiUrSa7fC6qsTbbTA0lTNpptM3Ecx1ZSh2Yq2EBHqhUtPbAARwRta/EEa70q9RSlx07tMN0 TER7mRgBmZBpmqgZX67VmP/gfWkbW6S5jwPBmwQht65FEN/3D3qpl/wXJHlrt3NLEJDJtxRxt9FK cr2Ko53GHSeYfmJRUs7EEfJkgsY4oxooFvIktJh7VIW7uS+UucDHuUJFuBPxmeUIuliCtmTEK6rp mwNhfwbBug4pFFuYErObQl4YLcT4ETG4uzLIcMvhEaAWiLL2h/cRIBBEvHboYMKraHtYV0QlFGsa ZPCRpBsmkdYSveZDEU7CZh3nL06Gqlf/Gil6kiOgwqfrFpAeFDKjyL0HQSxXRqgiFywgEpOSaKUg tL0m+b6UCL7MiVYXYaVqFnEVAomzqL8FQSzl9WL8OxdkZqlrZWHlISsFQmi4x5VnpW5k4mU2CXK4 pn+p+sGbeCwKXKrHooliRsIO3Cvydlu69iWm66Xc2IhxEcIojIsgXMJdurIvwaws4bk8ZMFV8cJC fEk+bK5DfMRITEJelcQ0JFl5VsTX86xQPMVUXMVWXFZMjEdXvMWV1bJc7MRZHBFffD9h7GtjfMZi W8ZqXMYttMaxi8ZwrDhuLMVxXMd2DMaHdcd6fD5z3MfOuMeA/C5+rKiDnF3pCCHsShdA/3wwiwxU AQam1waOcMuOhroYyMrDKvylK7zAFHHIl7qQ+vKp15anKrOoFOcYlywyolKI/RgVjUygrTYer4wX GFyStozJLTmSJXmP8vtwmpwxAhzDpVKT23gzATeozJiLkeoS64jMp6inLoMz6OEawwiR5WoU8Ghq iBZH9jiM/rljB4mxwgjLKcumSwuS3ZajMYPL+Ba/JIlvtqzD5gLPWYLLufzOu+bOWnKTkgxy6Puo /ayp7gYykpzMMAnMGTGR4RaRqcZoDA3OEH3N7sJJHonOTpHN58xtGInR1gzRGs1JJ3nLAh2O2WjP FsOSxuPJhRrPCM2Q9FxvJg0ZL53In/8sNOBI0H1KqjNtk51cyiM9yZBq0Ci9yvIcEfB8qA/nipWM PVHX1PHW0qqMqEp9KpCcp636zxn8b6smFRxt0duMzawma2I9q4HyzegzseqC1nwxyz8ROY2UeqpH EKvjlpA1sJOir3DxEVgZyANUyILF14AdjWYc2IS9xH9c2M91R4gNO369LIv92EPR2JI9KZDtVJN9 2Zid2Zq92XpV2Z792ePC2WgI2UMM2qZ92kIn2qq92qyN2aj92rAd25nb2rRd27aNS3vB1oerRNHK OlcHEZlD17Mn14D3OdNaEcKdL3Zdyx00FDUbsSlxcw/r3LsH3SJhstWjEQ+73drtETn/exJ8ZJVA gd2V8d1Bodb7cxFys94T8XmrZTiax6maQnp613e4c3X4fdwUQTkTgXnt3ZaLgzShl03BXTQCzhCs w95qU3ULATVK9w9gJ3HGfTrpGjUOrnbxrToAnTFdtNxiNNzA/RL6WnVYw98HUZW/jXqBE9f5XdRE dOEFLjjQnDZ5R5M1s3pmR+NqJ2AR9zW4o+AK8XcQXnGsd3gZE5duk+RK7jQHruF0k3ZCDjdxjciK 8nV8c+Wq0+T9SkFEYUVeHq4wS94hwUdKK0mSN5X2YHJpbs7gwUckOyd/4h269+bfCq7uuhElqxFq Wea+6NHfduZ6fpUzl7B4TqDiDRLP/y2y1qzRSJlE1vPo2R3oP8FEkRfplU4Sl24PlQ4eVJTpH8kd z41KjyolacMABMG1pg56tIc3f1o5w+3hBGE3hHc3Uu4QVWeaaZPrP+1BRbFQXmu1JKFJrjRK3EEB xp61Mhq2nQS2V7sRo+Tr51xKFF3OTDtKqJS1wG4PwK5KVOsq15S1w14SoRTupbRQQfvrBHq0niRH yA5AK+G2BZGEDPGYHpwT9K6YcXuEiFlQDsG2M8iZfwvwGRfwAs8Qd2uaBl8Q+j6D8q6XpRm3A4Gc Ap+XgenwE7Pw+k6D/Pe2CEFSjumDDAG7MiHbqDGeMSHyg21UK2HxMsHxt/3yMB/zb/+B8hcBB9Kq QUK4QEMRhgn2E7d7Ekj6FAimn9fYEqnIuyu2Ekdfijmx9PiYQ4JqwC72XQuxXqA4EYzoIS2c9DBh X/C1XigivovYYnUh9Wph9uEjY3NI1prGEUAWvOg8HhMmJ6gmztxhHwXyYDhGamSdh9Ery+xBkiO8 I4Lawa0oZVSG+PCF+AgR9mP6JTqyZVOCv8i8rzFNKb/Lhps2EnioYcybJ8mr0CCmh3tSkRYcaDdG h+fmphuBahWZh+DRG6jvXDaMEEvmEJKfLE6PMaDiwks9wGtWZsIvqTgEIxVSvwxRiUYGqL7/Kbl/ umd2JbuPEMhP+MxvEDaCiF161BX/kvVUr4+QP+qKkizsO8nvFbywDyiili3yYdYlZB/vAf/Tayex aigFAvoihhLgEb29wegMChAA7NnjN3CgwIMGBxJIqBDhQogRH9pD+BBhwYEYFW6k6HAix4HA/o0U +Q/ASJMjCaBk2XIkP5YnW8pMWbOmzJUoaerk6dLnT6BBhQ4lWtSoUZBJkzJcyNSiUoNPI9pjShGA xYpRM0LlOBFY06oYvyrUCFVq1YNXDRJgG/PqyJ0yr77VKVclypw0d/7M2TNo35yA7xItCbenYJsy S8btCfPlUciRJU+mHJTrZaxR1V5my3bj3MuaHwIJXdog6bQGx3Kd+3C1aaioPxpE/1l4rt+9PnG2 Haq3btzcLvcCI86SeHG4t2+2PO6WbmXo0aVPp17d+nWXfYPmDh69O3bw2L+HJ1/e/Hn06YGOj6ne /fvI7OHPp+8T9n38+fXv59/f//+N6hNwQAILNPBABBNUcEEGqwPwQQgjlHBCCiu08EIMM9RwQw47 9PBDEEMUcUQSSzTxRBRTVHFFFkNr8EUYY5RxRhr/afFGHHPUcUcek6rxRyAj63FIIu8L8kgkCyxy SQyTdPLJH5mUEiQog5zySiylrHJLLrv0Er4swxRzTDJJ/PJMNNNUU8gy29RwTThfdHNOOuu008U4 FbxzTz779PNPQP3Mc9D5AjX0UP9EE1V0UUY/JPRRSCOVrlFK55T0Ukwzra9STjv19FMeNRU1SVBL NbXRUVMl71RLVY2TVVjxdHVWWmsVVb4YY9XVQuh8M6xBXG398TnJtMPOWDX7k6qjCkFLCCtooeVw NhFjDLaoa4X7NbxsMfU1MWK3U+7bnsL91dduvdtLueSA80u61tIVN911kcJsv6wspDapfYf0LqWT vpUPXdzGncngcw8GTt6fGEv4YbuKMq1f/ZYtLV9nLVbKWaso3rghszgWSFrRPHbos832HLmjaE2W 6mWtmAU5X2YnghlkZU9u6OaVJfxIZI7N+mxm0WI2WmaXYza56J3v3XlZmqNmOuP/Jf8NOLGjCH54 Ody2jbhduuKdzmGuwd22OrK/Hngmr7Xlul5ctc566/XKbW9rtc+2ySSGBfzPYo1Buhlpqj3aDGqa jwbQZqUVr3npiXWu2fGuhka65KZlfja0wTErPOnMib589J+7glxMjYMOOeXWmm0cZ/4YD322nk93 WvTAK9d5cIxh11zo0Fl7HfTJjZaadMuT31HBvidjl+/mnesa67u//nd6cutuG2+8ye7tOch59px1 lG0uvPijVYe1AfbtDDoA+DlSwCAF5n8wgI3gx38g/fcPrX77GaR/BllAARcwEPv5byMBvNAAfweV A/7HgBG0h/4EqMBdZRBDFLwP/wNLYz8HJKUBOfLgp4QlqQBQ5gEPWJAGXfhCGMZQhhM6YQ1teEMc 5tA+M6ShDn2oHh4GUYgm+mERjQilIVLqiEtkYhOdeJQkRlGKU6RiFYv0RCxmUYtb5GIXvQhFK3Lq i3oKY6XGeEY0QqeMY0ojl9aYqDaS8Y1zpCNH4nhHPP6kjjzMo2T2+EdABlKQUuzjpAZ5SET2p5BP OuQix5hISEYSkY6clSQt6UJKGvGSdnTkJmeYSSdeEpSjJGVlWtMSB6QylSiBX0taKZRXsuSV8Trl P/oXS5SoUperLGUvK3NLlLBvPevSi0zqhxIAEsVcdMHlwX7DkmP6UprqqstIov/pk2vyjW3/ECY3 u/k94chkhUD5pjdZMs5pplMyvMzlSCAAAaBc01y5dMA/VGmUZRpTAfHcJzL7mRwrebJTDGCAUt6p FApQwCAHTQpBHQobhiqEoQk1KAQkalGDEFSgk6zMO4EiAAEABQUoQIlHf/JOkxoFAytlaUvdiVKY wvMfI0UJTVnSUpwqaaOxGqlScIADpfR0IPrQh1JAelTY/JQjSrUHSI16VKduJKI7pSpHogqSlQYV BQbJKr9GlrLLXNUgUYUBDLQ6EKFeNIPqXBV/0soRom7sIV0FSVSRGpqpDoShb0WZZjZS1qoGVqoY FVy/3gpYhZjVKkxjDe0QItb/jVz1rgOB7JXYykhllc4efFWIWIFGWQF0trIcyas9GEpXjqCWpX41 1WXR4x8oxNYgsl1sXScL2slC9rYggQMcONLbgZRVuMPVK2GLi1Faqk+whJQOEJzrXJQ8V7qufe1y 90NdSVlXu3TCrh832d1aSRK8J9yum8Y7lPLq57zrZW97e5leRI0Svp5yb33te9/xzle/5sXvgPb7 X13lF8ADJnCB6dhfBCdYwQtesIEdrF4Gu/HBE85RhC184UfCF8PVpXCHPfxhQW1YxCMmcYlNfFkQ p1jFK77QidEEYhdv6rsxrhKLaXxjNrEYRzjmcXhW3GMgB5lGOiZykY18ZP4Ib1nJQELyhpb8ZChH WcqUaXKVrXzlEU1Zy1vmspyw/GUw06a/YQZRl6M0yB6T+bpmViOM2cxlNTv5zWeMc53tfGc8o2jO e+YzGCfc4DwHWtAP6nOhDX1oAQ/6MohmdKMd/WhfChbSbS3ypAM7afIEBAA7 ------=_NextPart_000_000F_01C78905.2DA57B50-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCbTpP030629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 05:37:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RCbTQX030628; Fri, 27 Apr 2007 05:37:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCb7TZ030608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 05:37:28 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 13:37:06 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 27 Apr 2007 13:37:06 +0100 From: Stefan Santesson To: Denis Pinkas CC: pkix Date: Fri, 27 Apr 2007 13:36:58 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceIxlncDPnNRRvaT1SZVDgCCzLKjgAAImFA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RCbSTY030623 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I'm trying to bring this discussion up above the technical details and features. Listing of technical features does not stand as a motivation for doing the job. You have to explain why these features are important to the industry and why solving the same problem can't be done without the rather extreme measure you propose. If you protocol was covering new areas of standardization, you would be required to do less of motivation than, as now is the case, your work overlaps with current standards. This would be the third alternative for on-line certificate status checking: - OCSP - SCVP - LCVP Quote: > LCVP supports additional parameters, whereas SCVP does not (please > read the draft for the details): So we would have a "Lightweight" version of a protocol that is richer than the standard protocol. Good or bad, that logic can also be a hard sell. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Denis Pinkas [mailto:denis.pinkas@bull.net] > Sent: den 27 april 2007 14:20 > To: Stefan Santesson > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > > Stefan, > > >Denis, > > > >> LCVP only supports a subset of the mandatory requirements described > in > >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > >> not either a profile of SCVP. > > >This by itself is highly problematic. > > I fear that you stopped reading the document, after having read this > sentence, > otherwise you would have seen the benefits. :-) > > >As you state, this causes your draft to not be a profile of SCVP. > Instead it would technically > > be a 3rd alternative protocol for on-line certificate status > checking. > > ??? It is not a third alternative, but a second one. > > The goal of LCVP is NOT "on-line certificate status checking", but on- > line certificate validation. > It is not intended to be used as an alternative to OCSP. > > >It would take extreme reasons to justify creation of such new > protocol. > > The main arguments to use LCVP are: > "It is simple and provides more benefits when compared to SCVP". > > The main argument to use SCVP is: > " Why keep it simple, when you can make it complicated ?" > > >I have a hard time seeing this happen unless we actually change SCVP > > to allow your document to be a profile. But to take back SCVP at this > stage > > to the working group and to re-shape the requirements would also be > > very hard to motivate and extremely hard to get consensus on. > > A lightweight client profile for SCVP would not be realistic without > changing SCVP. > However, I am NOT in any way asking for any change to SCVP, which is > already > in the hands of the RFC editor. > > >I think you need to focus a lot more on the justification for this > work. > >Not only why it is useful, but why it is so extraordinary important > >that it motivates any of these measures. > > Besides simplicity, the other arguments have already be given in an e- > mail sent to Tim. > Here there are again: > > LCVP supports additional parameters, whereas SCVP does not (please > read the draft for the details): > > validationTime GeneralizedTime, > fullSubjectName FullSubjectName, > keyUsage KeyUsage OPTIONAL, > extKeyUsage ExtKeyUsageSyntax OPTIONAL, > > validationTime allows to support the validation of signer's > certificates used with electronic signatures > as specified by ETSI, in the case where the signature policy includes a > grace period. > > SCVP is unable to do it, unless adding "yet another" extension. > > fullSubjectName allows to handle unique names, and thus avoids > intentional or deliberate DN collisions. > > SCVP is unable to do it, unless adding "yet another" extension or > asking the client > to interpret itself the CertBundle parameter. In the later case, the > client is no more a thin client. > > keyUsage and extKeyUsage simply allow a application to know these > parameters > without the need to process the certificate. It is for thin clients and > allows them to know > the intended key usage(s) of the certificate. > > SCVP is unable to return that information, unless adding "yet other" > extensions. > > BTW, there is a syntax "error" in LCVP that needs to be corrected to > make it effectively "lightweight". > This error originated from the fact that I copied some of the ASN.1 > structures from SCVP. Since > SCVP is not lightweight anyway, this may not be a major problem, but > the next version of SCVP > could possibly take benefit of it. > > I let you discover it, unless someone else discovers it before you. :-) > > It will obviously be corrected in the next version to be published. > > Denis > > >Stefan Santesson > >Senior Program Manager > >Windows Security, Standards > > > > > >> -----Original Message----- > >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > >> pkix@mail.imc.org] On Behalf Of Denis Pinkas > >> Sent: den 20 april 2007 14:19 > >> To: pkix > >> Subject: Lightweight Certificate Validation Protocol (LCVP) > >> > >> > >> > >> I needed a simple protocol to delegate the validation of a > certificate > >> to a server, > >> to be used in environments where a client does not need to > demonstrate > >> to somebody else that it got a given response from a server. This > >> implies > >> that the server is fully trusted by the client. > >> > >> I considered using a profile of SCVP. Remember that the "S" does not > >> mean "Simple", > >> or "Standard" anymore, but "Server-based". > >> > >> However, the use of CMS to encapsulate everything and allowing to > >> optionally sign requests > >> is not needed, and the use of a subset of the various OIDs is not > >> trivial as well. > >> > >> I looked at other alternatives, outside the IETF, but they do not > >> provide an adequate answer. > >> > >> This proposal is for lightweight clients, hence why it is called > >> Lightweight > >> Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. > >> :-) > >> > >> LCVP only supports a subset of the mandatory requirements described > in > >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > >> not either a profile of SCVP. > >> > >> The major differences with SCVP are the following: > >> > >> - the protocol only supports DPV, i.e. it includes no provisions > >> to support Delegated Path Discovery (DPD); > >> > >> - requests and responses are not signed, since they are protected > >> by TLS, where clients are not authenticated; > >> > >> - validation is only for one certificate at a time; > >> > >> - there is no specific parameter in the request to add any > >> parameter to a validation policy known by the server. > >> > >> LCVP allows a client to delegate certificate path validation to > >> a trusted server. The path validation (e.g. making sure that none > >> of the certificates in the path are revoked) is performed according > >> to a set of rules called a validation policy. It allows > simplification > >> of client implementations and only uses of a set of validation > policies > >> known by the server. The document defines a protocol > >> that can be used to: > >> > >> (1) validate one certificate according to one validation > policy, > >> (2) query the validation policies supported by an LCVP server. > >> > >> At this time, the document is a strawman proposal and has not yet > been > >> implemented. > >> There are certainly errors in it and it can certainly be improved - > >> while keeping it "light". > >> > >> At this time, the document is an individual draft targeted for the > >> experimental category. > >> > >> The document is available at: > >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > >> > >> The document is proposed to the PKIX WG for consideration and > comments. > >> > >> If the WG, later on, finds this approach interresting, then the > >> document could be > >> re-targeted to the standard track category. > >> > >> Denis > >> > > Regards, > > Denis Pinkas > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCKAKL027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 05:20:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RCKAj2027776; Fri, 27 Apr 2007 05:20:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RCJlJS027720 for ; Fri, 27 Apr 2007 05:20:08 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25656; Fri, 27 Apr 2007 14:24:43 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042714193935:121625 ; Fri, 27 Apr 2007 14:19:39 +0200 Date: Fri, 27 Apr 2007 14:19:37 +0200 From: "Denis Pinkas" To: "Stefan Santesson" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 14:19:39, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/04/2007 14:19:39, Serialize complete at 27/04/2007 14:19:39 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, >Denis, > >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >This by itself is highly problematic. I fear that you stopped reading the document, after having read this sentence, otherwise you would have seen the benefits. :-) >As you state, this causes your draft to not be a profile of SCVP. Instead it would technically > be a 3rd alternative protocol for on-line certificate status checking. ??? It is not a third alternative, but a second one. The goal of LCVP is NOT "on-line certificate status checking", but on-line certificate validation. It is not intended to be used as an alternative to OCSP. >It would take extreme reasons to justify creation of such new protocol. The main arguments to use LCVP are: "It is simple and provides more benefits when compared to SCVP". The main argument to use SCVP is: " Why keep it simple, when you can make it complicated ?" >I have a hard time seeing this happen unless we actually change SCVP > to allow your document to be a profile. But to take back SCVP at this stage > to the working group and to re-shape the requirements would also be > very hard to motivate and extremely hard to get consensus on. A lightweight client profile for SCVP would not be realistic without changing SCVP. However, I am NOT in any way asking for any change to SCVP, which is already in the hands of the RFC editor. >I think you need to focus a lot more on the justification for this work. >Not only why it is useful, but why it is so extraordinary important >that it motivates any of these measures. Besides simplicity, the other arguments have already be given in an e-mail sent to Tim. Here there are again: LCVP supports additional parameters, whereas SCVP does not (please read the draft for the details): validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, validationTime allows to support the validation of signer's certificates used with electronic signatures as specified by ETSI, in the case where the signature policy includes a grace period. SCVP is unable to do it, unless adding "yet another" extension. fullSubjectName allows to handle unique names, and thus avoids intentional or deliberate DN collisions. SCVP is unable to do it, unless adding "yet another" extension or asking the client to interpret itself the CertBundle parameter. In the later case, the client is no more a thin client. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. It is for thin clients and allows them to know the intended key usage(s) of the certificate. SCVP is unable to return that information, unless adding "yet other" extensions. BTW, there is a syntax "error" in LCVP that needs to be corrected to make it effectively "lightweight". This error originated from the fact that I copied some of the ASN.1 structures from SCVP. Since SCVP is not lightweight anyway, this may not be a major problem, but the next version of SCVP could possibly take benefit of it. I let you discover it, unless someone else discovers it before you. :-) It will obviously be corrected in the next version to be published. Denis >Stefan Santesson >Senior Program Manager >Windows Security, Standards > > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- >> pkix@mail.imc.org] On Behalf Of Denis Pinkas >> Sent: den 20 april 2007 14:19 >> To: pkix >> Subject: Lightweight Certificate Validation Protocol (LCVP) >> >> >> >> I needed a simple protocol to delegate the validation of a certificate >> to a server, >> to be used in environments where a client does not need to demonstrate >> to somebody else that it got a given response from a server. This >> implies >> that the server is fully trusted by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does not >> mean "Simple", >> or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests >> is not needed, and the use of a subset of the various OIDs is not >> trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight >> Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. >> :-) >> >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to >> a trusted server. The path validation (e.g. making sure that none >> of the certificates in the path are revoked) is performed according >> to a set of rules called a validation policy. It allows simplification >> of client implementations and only uses of a set of validation policies >> known by the server. The document defines a protocol >> that can be used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet been >> implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be >> re-targeted to the standard track category. >> >> Denis >> Regards, Denis Pinkas Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RBH6gk020544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 04:17:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RBH6Bj020543; Fri, 27 Apr 2007 04:17:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RBGdOw020499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Apr 2007 04:17:00 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.85.3; Fri, 27 Apr 2007 12:16:38 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 27 Apr 2007 12:16:37 +0100 From: Stefan Santesson To: Denis Pinkas , pkix Date: Fri, 27 Apr 2007 12:16:29 +0100 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDT7TY8P2UxqBGRVCTPzTAXpm0VgEty2mQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RBH1Ov020526 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. This by itself is highly problematic. As you state, this causes your draft to not be a profile of SCVP. Instead it would technically be a 3rd alternative protocol for on-line certificate status checking. It would take extreme reasons to justify creation of such new protocol. I have a hard time seeing this happen unless we actually change SCVP to allow your document to be a profile. But to take back SCVP at this stage to the working group and to re-shape the requirements would also be very hard to motivate and extremely hard to get consensus on. I think you need to focus a lot more on the justification for this work. Not only why it is useful, but why it is so extraordinary important that it motivates any of these measures. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > pkix@mail.imc.org] On Behalf Of Denis Pinkas > Sent: den 20 april 2007 14:19 > To: pkix > Subject: Lightweight Certificate Validation Protocol (LCVP) > > > > I needed a simple protocol to delegate the validation of a certificate > to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does not > mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. > :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows simplification > of client implementations and only uses of a set of validation policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet been > implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QM0ImD004214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 15:00:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QM0IMD004213; Thu, 26 Apr 2007 15:00:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLxvge004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Apr 2007 15:00:17 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l3QLxmEm006099; Thu, 26 Apr 2007 14:59:50 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:59:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Thu, 26 Apr 2007 14:59:13 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD370124CE06@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <462E1B2E.6050708@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceGjJUTE9yZWLE4QjWXZ1z0DDtGgwBwRREQ From: "Hallam-Baker, Phillip" To: "Stephen Farrell" , "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 26 Apr 2007 21:59:47.0971 (UTC) FILETIME=[34E6B530:01C7884E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3QM0Hgd004202 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I heartily concur with Stephen here. If you want lighweight PKI then you don't want a certificate based PKI at all. You want a key centric model where the only thing that a relying application needs to do is to ask an external service 'what key should I use to talk protocol X to party Y'. XKMS is not perfect, but it exists and meets this need. The backing infrastructure behind XKMS will probably involve certificates and SCVP but the client is insulated from all that. I don't think that you get what you want here unless you abandon the fixation with certificates. > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Farrell > Sent: Tuesday, April 24, 2007 10:59 AM > To: Denis Pinkas > Cc: pkix > Subject: Re: Lightweight Certificate Validation Protocol (LCVP) > > > > Hi Denis, > > My €0.02: > > I don't believe there's a significant demand for this. At > least I've not heard of someone who wants this protocol. > > If there is a demand, (not met by SCVP), then I further doubt > that there's sufficient energy to fight all these fights all > over again. (cf. Santosh's mail just now.) > > If there was sufficient energy, then I doubt that the outcome > would be much different to SCVP. > > Finally, if I'm wrong about the above, then whoever it is > that wants whatever it is that SCVP doesn't do and who has > the energy to write new code should of course just use XKMS > and be done with it in a few days rather than in ~2010. > > All-in-all I'm for the WG not taking this on, Cheers, Stephen. > > Denis Pinkas wrote: > > > > I need a simple protocol to delegate the validation of a > certificate > > to a server, to be used in environments where a client does > not need > > to demonstrate to somebody else that it got a given response from a > > server. This implies that the server is fully trusted by the client. > > > > I considered using a profile of SCVP. Remember that the "S" > does not > > mean "Simple", or "Standard" anymore, but "Server-based". > > > > However, the use of CMS to encapsulate everything and allowing to > > optionally sign requests is not needed, and the use of a > subset of the various OIDs is not trivial as well. > > > > I looked at other alternatives, outside the IETF, but they > do not provide an adequate answer. > > > > This proposal is for lightweight clients, hence why it is called > > Lightweight Certificate Validation Protocol (LCVP), like LDAP is > > simpler than DAP. :-) > > > > LCVP only supports a subset of the mandatory requirements > described in > > [RFC3379] for DPV, hence it does not conform to RFC 3379. > LCVP is not > > either a profile of SCVP. > > > > The major differences with SCVP are the following: > > > > - the protocol only supports DPV, i.e. it includes no provisions > > to support Delegated Path Discovery (DPD); > > > > - requests and responses are not signed, since they are > protected > > by TLS, where clients are not authenticated; > > > > - validation is only for one certificate at a time; > > > > - there is no specific parameter in the request to add any > > parameter to a validation policy known by the server. > > > > LCVP allows a client to delegate certificate path validation to a > > trusted server. The path validation (e.g. making sure that none of > > the certificates in the path are revoked) is performed > according to a > > set of rules called a validation policy. It allows > simplification of > > client implementations and only uses of a set of validation > policies > > known by the server. The document defines a protocol that > can be used > > to: > > > > (1) validate one certificate according to one > validation policy, > > (2) query the validation policies supported by an > LCVP server. > > > > At this time, the document is a strawman proposal and has > not yet been implemented. > > There are certainly errors in it and it can certainly be > improved - while keeping it "light". > > > > At this time, the document is an individual draft targeted > for the experimental category. > > > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > > > The document is proposed to the PKIX WG for consideration > and comments. > > > > If the WG, later on, finds this approach interresting, then the > > document could be re-targeted to the standard track category. > > > > Denis > > > > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLuXns003550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 14:56:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QLuXab003549; Thu, 26 Apr 2007 14:56:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QLu9x5003511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Apr 2007 14:56:29 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l3QLu15O001397; Thu, 26 Apr 2007 14:56:01 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:56:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SCVP Question regarding Trust Anchors Date: Thu, 26 Apr 2007 14:55:26 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD370124CE05@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <20070425130525.GN1691@mars.cry.pto> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP Question regarding Trust Anchors Thread-Index: AceHSPHrHaOxunSwSnaycKOxNOjpaQBA578Q From: "Hallam-Baker, Phillip" To: "Julien Stern" , "Michael Myers" , "Russ Housley" , X-OriginalArrivalTime: 26 Apr 2007 21:56:01.0669 (UTC) FILETIME=[AE03C350:01C7884D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3QLuTx4003523 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A certificate can contain information that tells a relying party where to find information to verify the status of information provided by the issuer. The purpose of SCVP is to provide information on the trustworthyness of the information provided by the issuer. It does not make any sense for the issuer to be involved in supplying trust chain validation information and providing trust chain discovery information makes only limited sense. A more appropriate mechanism for this requirement would be to advertise the location of the SCVP server for a domain by means of a DNS SRV record. In practice two records are needed, one for path discovery (which may be asserted by the issuer) and the second for validation (which the relying party needs to choose). My machine knows that it is part of the verisign.com network. So why not deploy DNSSEC and then advertise the location of the local trust chain discovery and validation service via a DNSSEC secured SRV record? That server knows the trust criteria for the domain and can make a useful interrogation of the relying party path discovery server. Alternatively use the DNS to discover your XKMS servers for the same purposes. DNSSEC signed SRV is the way to cut through the Gordian knot of PKI deployment. > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern > Sent: Wednesday, April 25, 2007 9:05 AM > To: Michael Myers; Russ Housley; ietf-pkix@imc.org > Subject: Re: SCVP Question regarding Trust Anchors > > > On Wed, Apr 25, 2007 at 10:52:17AM +0200, Julien Stern wrote: > > > > Mike, > > > > just check RFC3125 (part of PKIX). > > It defines a validation policy where several trust anchors are > > associated with different inputs. > > The benefit would be to be able to validate such a policy with SCVP. > > A few people let me know that > 1) RFC3125 is part of S/MIME (not PKIX) > 2) It is "Experimental" > > However, it is related to the ETSI technical reports 102038 > and 102272, which define a broader notion of Trust Anchor than SCVP. > > Well, that's for the benefit: being in sync with these TRs > and the Experimental RFC. That being said, as Russ, I can > live with the current situation. It is always possible to > define a local policy that has more complex Trust Anchors... > > -- > Julien > > > -- > > Julien > > > > On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > > > > > Russ, > > > > > > Your explanation suggests "equivalency". > > > I fear for in-band negotiation of that state absent a use-case > > > requirement. > > > > > > Mike > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > > > Sent: Tuesday, April 24, 2007 7:00 AM > > > To: Michael Myers > > > Cc: ietf-pkix@imc.org > > > Subject: RE: SCVP Question regarding Trust Anchors > > > > > > > > > > > > Mike: > > > > > > If a validation policy includes several trust anchors, then it is > > > desirable for the path validation algorithm inputs for > each of these > > > might be different. I can live with the current > structure, but it > > > imposes the restriction that all of the trust anchors associated > > > with the validation policy must be used with the same path > > > validation algorithm inputs. > > > > > > Russ > > > > > > At 07:14 PM 4/23/2007, Michael Myers wrote: > > > >Russ, Julien: > > > > > > > >To what benefit? > > > > > > > >Mike > > > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PD5t45055165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3PD5tBZ055164; Wed, 25 Apr 2007 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PD5YJ2055108 for ; Wed, 25 Apr 2007 06:05:54 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id B09D94F402; Wed, 25 Apr 2007 15:05:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D180544293; Wed, 25 Apr 2007 15:05:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQGVD-GryQCg; Wed, 25 Apr 2007 15:05:27 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 198D644160; Wed, 25 Apr 2007 15:05:26 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 25 Apr 2007 15:05:26 +0200 From: "Julien Stern" Date: Wed, 25 Apr 2007 15:05:26 +0200 To: Michael Myers , Russ Housley , ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070425130525.GN1691@mars.cry.pto> Mail-Followup-To: Julien Stern , Michael Myers , Russ Housley , ietf-pkix@imc.org References: <200704241508.l3OF8Uu9042167@balder-227.proper.com> <20070425085216.GL1691@mars.cry.pto> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425085216.GL1691@mars.cry.pto> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Apr 25, 2007 at 10:52:17AM +0200, Julien Stern wrote: > > Mike, > > just check RFC3125 (part of PKIX). > It defines a validation policy where several trust anchors > are associated with different inputs. > The benefit would be to be able to validate such a policy with SCVP. A few people let me know that 1) RFC3125 is part of S/MIME (not PKIX) 2) It is "Experimental" However, it is related to the ETSI technical reports 102038 and 102272, which define a broader notion of Trust Anchor than SCVP. Well, that's for the benefit: being in sync with these TRs and the Experimental RFC. That being said, as Russ, I can live with the current situation. It is always possible to define a local policy that has more complex Trust Anchors... -- Julien > -- > Julien > > On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > > > Russ, > > > > Your explanation suggests "equivalency". > > I fear for in-band negotiation of that > > state absent a use-case requirement. > > > > Mike > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > > Sent: Tuesday, April 24, 2007 7:00 AM > > To: Michael Myers > > Cc: ietf-pkix@imc.org > > Subject: RE: SCVP Question regarding Trust Anchors > > > > > > > > Mike: > > > > If a validation policy includes several trust anchors, then it is > > desirable for the path validation algorithm inputs for each of these > > might be different. I can live with the current structure, but it > > imposes the restriction that all of the trust anchors associated with > > the validation policy must be used with the same path validation > > algorithm inputs. > > > > Russ > > > > At 07:14 PM 4/23/2007, Michael Myers wrote: > > >Russ, Julien: > > > > > >To what benefit? > > > > > >Mike > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P8qj38027892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 01:52:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3P8qjOH027891; Wed, 25 Apr 2007 01:52:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P8qNHX027858 for ; Wed, 25 Apr 2007 01:52:44 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 7672240F59; Wed, 25 Apr 2007 10:52:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 21BD744293; Wed, 25 Apr 2007 10:52:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI2nNNgnNJLw; Wed, 25 Apr 2007 10:52:18 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id B0B3A44160; Wed, 25 Apr 2007 10:52:17 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 25 Apr 2007 10:52:17 +0200 From: "Julien Stern" Date: Wed, 25 Apr 2007 10:52:17 +0200 To: Michael Myers Cc: Russ Housley , ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070425085216.GL1691@mars.cry.pto> Mail-Followup-To: Julien Stern , Michael Myers , Russ Housley , ietf-pkix@imc.org References: <200704241508.l3OF8Uu9042167@balder-227.proper.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mike, just check RFC3125 (part of PKIX). It defines a validation policy where several trust anchors are associated with different inputs. The benefit would be to be able to validate such a policy with SCVP. -- Julien On Tue, Apr 24, 2007 at 05:28:09PM -0800, Michael Myers wrote: > > Russ, > > Your explanation suggests "equivalency". > I fear for in-band negotiation of that > state absent a use-case requirement. > > Mike > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley > Sent: Tuesday, April 24, 2007 7:00 AM > To: Michael Myers > Cc: ietf-pkix@imc.org > Subject: RE: SCVP Question regarding Trust Anchors > > > > Mike: > > If a validation policy includes several trust anchors, then it is > desirable for the path validation algorithm inputs for each of these > might be different. I can live with the current structure, but it > imposes the restriction that all of the trust anchors associated with > the validation policy must be used with the same path validation > algorithm inputs. > > Russ > > At 07:14 PM 4/23/2007, Michael Myers wrote: > >Russ, Julien: > > > >To what benefit? > > > >Mike > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P25NgJ065643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 19:05:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3P25N4P065642; Tue, 24 Apr 2007 19:05:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3P251lM065597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2007 19:05:22 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3P24wJb041450; Tue, 24 Apr 2007 19:04:58 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Russ Housley" Cc: Subject: RE: SCVP Question regarding Trust Anchors Date: Tue, 24 Apr 2007 17:28:09 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Importance: Normal In-Reply-To: <200704241508.l3OF8Uu9042167@balder-227.proper.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Your explanation suggests "equivalency". I fear for in-band negotiation of that state absent a use-case requirement. Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley Sent: Tuesday, April 24, 2007 7:00 AM To: Michael Myers Cc: ietf-pkix@imc.org Subject: RE: SCVP Question regarding Trust Anchors Mike: If a validation policy includes several trust anchors, then it is desirable for the path validation algorithm inputs for each of these might be different. I can live with the current structure, but it imposes the restriction that all of the trust anchors associated with the validation policy must be used with the same path validation algorithm inputs. Russ At 07:14 PM 4/23/2007, Michael Myers wrote: >Russ, Julien: > >To what benefit? > >Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OILL1E067495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 11:21:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OILLw2067494; Tue, 24 Apr 2007 11:21:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3OIL0RG067384 for ; Tue, 24 Apr 2007 11:21:20 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 34690 invoked from network); 24 Apr 2007 18:20:49 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2007 18:20:49 -0000 X-YMail-OSG: Oz8jPQIVM1l5uJe4NgxQmtMLWi9betHtB_CnzlupceXSMLWOxfMsxzSe0ESGkIWJiQ-- Message-ID: <462E4BFE.5060205@connotech.com> Date: Tue, 24 Apr 2007 14:27:10 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Massimiliano Pala CC: Wen-Cheng Wang , pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> In-Reply-To: <462E1C8D.8090602@cs.dartmouth.edu> 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: Massimiliano Pala wrote: > Hello Wen-Cheng, > > thank you for the comment. Indeed the distribution of the RQA address > is something tricky, but the AIA/SIA extensions can be used to provide > that. Also the DHCP could be used for the same porpuse on a local > network. > Did you look at SLP (Service Location Protocol) in RFC2608 / RFC2609? If you think of DHCP, a look at SLP is certainly deserved. I did the exercise with DNSSEC deployment, see http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHvX3U064369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OHvX8w064368; Tue, 24 Apr 2007 10:57:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHvCQ2064322 for ; Tue, 24 Apr 2007 10:57:32 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.232.45.243) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) (authenticated as u18116613) id 461E4AF80031F10E; Tue, 24 Apr 2007 19:56:58 +0200 Message-ID: <000401c78699$ee787b20$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Massimiliano Pala" , "Wen-Cheng Wang" Cc: "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 19:44:04 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Max, Some time ago you proposed new PKI protocols but then you did not state any specific use-case. I'm happy to see such now :-) Regarding painful rollover, I believe a 5-year plan or so is realistic if it involves certificate changes. If the idea is really some kind of "mapping scheme" between existing certificates and services it may be faster but OTOH I don't really see how such a mapping utility would work given the huge variations out there. But maybe you are thinking of some kind of centralized discovery service? Personally I'm only interested in decentralized Internet-scale PKI solutions (the opposite to S/MIME...) and would due to this base a new scheme on the only Internet-scale "registry" there is: DNS. I would suggest a scheme based on DNS names which both can be obtained locally (from a config file) as well as being supplied in a new certificate extension. This would allow step-wise migration which has proved to be the fastest route to adoption. The following is one way of architecting this: In the repository/certificate extension: "example.com" Searched for by an enhanced PKI client: _thesuperduper-pki-lookup.example.com TXT "something" _other-pki-lookup-service.example.com TXT "something" Regarding applications, I would like to add automatic certificate renewal services support. regards Anders ----- Original Message ----- From: "Massimiliano Pala" To: "Wen-Cheng Wang" Cc: "pkix" Sent: Tuesday, April 24, 2007 17:04 Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHigFS062328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OHigZ3062327; Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHiLhU062247 for ; Tue, 24 Apr 2007 10:44:42 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.232.45.243) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) (authenticated as u18116613) id 46245DE10021B0F5; Tue, 24 Apr 2007 19:44:17 +0200 Message-ID: <001101c78698$2904cd40$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Massimiliano Pala" , "Wen-Cheng Wang" Cc: "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> <462E1C8D.8090602@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 19:44:04 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Max, Some time ago you proposed new PKI protocols but then you did not state any specific use-case. I'm happy to see such now :-) Regarding painful rollover, I believe a 5-year plan or so is realistic if it involves certificate changes. If the idea is really some kind of "mapping scheme" between existing certificates and services it may be faster but OTOH I don't really see how such a mapping utility would work given the huge variations out there. But maybe you are thinking of some kind of centralized discovery service? Personally I'm only interested in decentralized Internet-scale PKI solutions (the opposite to S/MIME...) and would due to this base a new scheme on the only Internet-scale "registry" there is: DNS. I would suggest a scheme based on DNS names which both can be obtained locally (from a config file) as well as being supplied in a new certificate extension. This would allow step-wise migration which has proved to be the fastest route to adoption. The following is one way of architecting this: In the repository/certificate extension: "example.com" Searched for by an enhanced PKI client: _thesuperduper-pki-lookup.example.com TXT "something" _other-pki-lookup-service.example.com TXT "something" Regarding applications, I would like to add automatic certificate renewal services support. regards Anders ----- Original Message ----- From: "Massimiliano Pala" To: "Wen-Cheng Wang" Cc: "pkix" Sent: Tuesday, April 24, 2007 17:04 Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OH0jPE055406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:00:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OH0jjW055405; Tue, 24 Apr 2007 10:00:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OH0NI0055378 for ; Tue, 24 Apr 2007 10:00:44 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 2EC251E; Tue, 24 Apr 2007 19:00:23 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11746-09; Tue, 24 Apr 2007 19:00:20 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id A75CF16; Tue, 24 Apr 2007 19:00:20 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042419001993:219829 ; Tue, 24 Apr 2007 19:00:19 +0200 Message-ID: <462E3721.6060808@edelweb.fr> Date: Tue, 24 Apr 2007 18:58:09 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Stephen Farrell Cc: Denis Pinkas , pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: <462E1B2E.6050708@cs.tcd.ie> In-Reply-To: <462E1B2E.6050708@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 07:00:20 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 07:00:20 PM, Serialize complete at 04/24/2007 07:00:20 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803050405090908050403" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060803050405090908050403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit One can say that SCVP has too moch of lower layer specific information. In fact, one can fold out the signeData or authenticateddata encapsulation as well as TLS transport layer security, http, and the contenttype encapsulation saying the the request and response structure need to be communicated to the partner. In a local unix environment, one could for example just exchange this via unix sockets/pipes as with some ldap, and you do not need any of the overhead, or one would use some IPSec authenticated channel etc. Or, one can replace all this lower layer bindings by some usage of WSS or secure WSS or beep, but that's another story. If one takes just the content of the queries, then it is a matter of taste how to encode certain details of the payload of the query. I don't see that there is a real need to define yet another payload format, as far as I see the Denis' essential argument is that the binding envelopes are too much overhead. I agree with Stpehen, that in case of, the appropriate subset of XKMS can be used, even if one doesn't like XML, then trasform XMKS into ASN.1 automatically and code in PER or use the fast doc encoding, etc. The still unclear question (at least to me) is about the service to be provided and whether there is a difference between the protocols. See my previous message. --------------ms060803050405090908050403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTY1ODA5WjAjBgkqhkiG9w0B CQQxFgQUlIE3/CQlfGf7OMSob8hI6Q2EslcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAoHY2hm9j6o/OV1dr rhfaYWy8D1qHdt1jFgJRmdaiI127AcJAgWgbxAI+RlC+NFEy/kX9jxTBd8dl1VimXLTHEl75 KfZyft82EAISPmbaw9oL21xq7hnaf5QA/YrG16LeBnIh8ktlIo/ABTlQaK3h6pEnDOs2j7bT T8pMHb7hntsAAAAAAAA= --------------ms060803050405090908050403-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF8pQq042188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 08:08:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OF8pT8042187; Tue, 24 Apr 2007 08:08:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3OF8Uu9042167 for ; Tue, 24 Apr 2007 08:08:50 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704241508.l3OF8Uu9042167@balder-227.proper.com> Received: (qmail 3857 invoked by uid 0); 24 Apr 2007 15:08:26 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 24 Apr 2007 15:08:26 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Apr 2007 10:59:58 -0400 To: "Michael Myers" From: Russ Housley Subject: RE: SCVP Question regarding Trust Anchors Cc: ietf-pkix@imc.org In-Reply-To: References: <200704231953.l3NJr9VR095229@balder-227.proper.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: Mike: If a validation policy includes several trust anchors, then it is desirable for the path validation algorithm inputs for each of these might be different. I can live with the current structure, but it imposes the restriction that all of the trust anchors associated with the validation policy must be used with the same path validation algorithm inputs. Russ At 07:14 PM 4/23/2007, Michael Myers wrote: >Russ, Julien: > >To what benefit? > >Mike > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley >Sent: Monday, April 23, 2007 11:44 AM >To: Julien Stern; ietf-pkix@imc.org >Subject: Re: SCVP Question regarding Trust Anchors > > > >You are right, in my personal opinion, that would be a better >structure. Can you propose text? > >Russ > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > > >Folks, > > > >sorry to ask this fairly late in the process, but it did not catch > >my eye before: > > > >The ValidationPolicy structure defines > >- userPolicySet > >- inhibitPolicyMapping > >- requireExplicitPolicy > >- inhibitAnyPolicy > > > >globally and not on a per trust-anchor basis. > > > >Wouldn't it be more logical and less limiting to define it for each > >trust anchor (like in RFC3125)... ? > > > >Regards, > > > >-- > >Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF5IMj041934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 08:05:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OF5IMs041933; Tue, 24 Apr 2007 08:05:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OF4tOl041893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2007 08:05:16 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3OF4ji2003654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2007 11:04:46 -0400 Message-ID: <462E1C8D.8090602@cs.dartmouth.edu> Date: Tue, 24 Apr 2007 11:04:45 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: Wen-Cheng Wang CC: pkix Subject: Re: PKI Resource Discovery - Proposal for a new Working Item References: <462D05DA.5060002@cs.dartmouth.edu> <002601c78622$c31e6e70$5d85900a@wcwang> In-Reply-To: <002601c78622$c31e6e70$5d85900a@wcwang> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070302040105090009000906" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070302040105090009000906 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Hello Wen-Cheng, thank you for the comment. Indeed the distribution of the RQA address is something tricky, but the AIA/SIA extensions can be used to provide that. Also the DHCP could be used for the same porpuse on a local network. Again, thanks. I'll try to come up with a draft for the WG to read hopefully in the next few days (or the next week). Let me know what do you think also about a possible session/proposal at the next IETF. Cheers, Max Wen-Cheng Wang wrote: > > Dr. Massimiliano Pala, > > That is an interesting idea. > > However, one imaginable problem you might face is "how > a relying party (the PRQP client) can find an authroized RQA?" > > One straightforward way is to let the CA issue a certificate first to > delegate the authority to the RQA and then use AIA/SIA extnesions > to provide the URL of the authroized RQA (the authroized PRQP server) > to the PRQP client. If you are going to adopt this kind of straightforward > solution, it will not be a painless rollover from traditional ways (embed > various pointers via CDP, AIA or SIA extensions) to the new way (a single > AIA/SIA extension comtaining the authroized PRQP access info). The > reason why it will not be a painless rollover is that the goal can not be > achieved without the need to re-issuing all the existing certificates to > add the newly defined PRQP access info into the AIA/SIA extension. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms070302040105090009000906 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTUwNDQ1WjAjBgkqhkiG9w0B CQQxFgQU/7rh+Rl+1aG5TC9jtt5JVN7Du5UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYBlIl91nqt8o5ij0sHDpyns iFfoF43XG8dMvsUdAIJMxG74yoFdQ0NPBOsJQz1kuGDyOKacKw7jdUKOuTGbsbifm36GG/5B +w7GavBidNu1FMqVBprBkBFavYU8WM39y88ekev5P5nK4pYxBxr15Rlo0ftoYpN0H2+xVmWx IQGUoAAAAAAAAA== --------------ms070302040105090009000906-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OEvjkl041253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 07:57:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OEvjq7041252; Tue, 24 Apr 2007 07:57:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OEvNx0041220 for ; Tue, 24 Apr 2007 07:57:44 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id B8CD368048; Tue, 24 Apr 2007 15:57:22 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07B08AD0C7; Tue, 24 Apr 2007 15:57:22 +0100 Received: from [134.226.36.174] (nanga.dsg.cs.tcd.ie [134.226.36.174]) by imx2.tcd.ie (Postfix) with ESMTP id 9042B68048; Tue, 24 Apr 2007 15:57:22 +0100 (IST) Message-ID: <462E1B2E.6050708@cs.tcd.ie> Date: Tue, 24 Apr 2007 15:58:54 +0100 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-AntiVirus-Status: MessageID = A17B08AD0C7 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.74.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3OEvix0041247 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Denis, My €0.02: I don't believe there's a significant demand for this. At least I've not heard of someone who wants this protocol. If there is a demand, (not met by SCVP), then I further doubt that there's sufficient energy to fight all these fights all over again. (cf. Santosh's mail just now.) If there was sufficient energy, then I doubt that the outcome would be much different to SCVP. Finally, if I'm wrong about the above, then whoever it is that wants whatever it is that SCVP doesn't do and who has the energy to write new code should of course just use XKMS and be done with it in a few days rather than in ~2010. All-in-all I'm for the WG not taking this on, Cheers, Stephen. Denis Pinkas wrote: > > I need a simple protocol to delegate the validation of a certificate to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to optionally sign requests > is not needed, and the use of a subset of the various OIDs is not trivial as well. > > I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows simplification > of client implementations and only uses of a set of validation policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet been implemented. > There are certainly errors in it and it can certainly be improved - while keeping it "light". > > At this time, the document is an individual draft targeted for the experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and comments. > > If the WG, later on, finds this approach interresting, then the document could be > re-targeted to the standard track category. > > Denis > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OESewP038492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 07:28:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OESenu038491; Tue, 24 Apr 2007 07:28:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OESKd2038447 for ; Tue, 24 Apr 2007 07:28:40 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Tue, 24 Apr 2007 07:27:43 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879077B856B@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceGWX4V3S2YxoSISNqv5f2boxE9SAAItibQ References: From: "Santosh Chokhani" To: "pkix" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3OESed2038486 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It may be better for LCVP to rely on signed objects and not change the SCVP. While I realize that most clients do SSL/TLS, if we want thin clients to differ the certification path discovery and validation to a Server, assuming that TLS or SSL client is there (which requires certification path validation), may not be the best assumption. Thus, leaving SCVP alone and processing signed CMS objects for LCVP may be a better choice. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, April 24, 2007 5:16 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I need a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAVDG2018511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OAVDnG018510; Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAUqGR018468 for ; Tue, 24 Apr 2007 03:31:13 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 25D9820; Tue, 24 Apr 2007 12:30:39 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20738-03; Tue, 24 Apr 2007 12:30:36 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id E08271F; Tue, 24 Apr 2007 12:30:31 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042412303017:218380 ; Tue, 24 Apr 2007 12:30:30 +0200 Message-ID: <462DDBC4.9030607@edelweb.fr> Date: Tue, 24 Apr 2007 12:28:20 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: Lightweight Certificate Validation Protocol (LCVP) References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 12:30:30 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 04/24/2007 12:30:31 PM, Serialize complete at 04/24/2007 12:30:31 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010405020002000500070205" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010405020002000500070205 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit LCVP as well as SCVP allow two different ways to identify a certificate. Either by providing the certificate or by a reference. In the second case the server needs to access a repository to obtain a certificate. To which degree does a server trust the repository to deliver a valid certificate? Or, in other words, would it be equivalent or not that the client obtains by whatever means a certificate and provides it as input. If the server is provided with a certificate as input, what is the meaning of a successful response: - this is a valid certifcate that has in fact been issued by the CA and it is trusted etc - this certificate seems indeed to be signed by the CA etc. Peter --------------ms010405020002000500070205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI0MTAyODIwWjAjBgkqhkiG9w0B CQQxFgQUXF077IR7r6ZcR4BqaljG2QvYMCwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAw10NSfk94iEYi+6P aLUgE7WF7/4mI0Nxzmtf9/xHBJziY/uQiQPIP9uXEb3YUMTUl1rYB4uqIkSn0ShqTJQScBf8 nFO3KCjjVj1iFXmQN2cwHoWHNSbEx7GRGcVEpXXk4Rx1egD5nniUGgYy5XiC+8Mao2DH8GAL iDfuQb0vPRAAAAAAAAA= --------------ms010405020002000500070205-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O9GJQq012433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 02:16:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O9GJCY012432; Tue, 24 Apr 2007 02:16:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O9GHvf012425 for ; Tue, 24 Apr 2007 02:16:18 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA29892 for ; Tue, 24 Apr 2007 11:21:16 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042411161537:8293 ; Tue, 24 Apr 2007 11:16:15 +0200 Date: Tue, 24 Apr 2007 11:16:12 +0200 From: "Denis Pinkas" To: "pkix" Subject: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 11:16:15, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 11:16:16, Serialize complete at 24/04/2007 11:16:16 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I need a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8WFrP008146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 01:32:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O8WFW6008145; Tue, 24 Apr 2007 01:32:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8WDPZ008139 for ; Tue, 24 Apr 2007 01:32:14 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24682; Tue, 24 Apr 2007 10:37:09 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042410320868:6945 ; Tue, 24 Apr 2007 10:32:08 +0200 Date: Tue, 24 Apr 2007 10:32:06 +0200 From: "Denis Pinkas" To: "Tim Polk" Cc: "pkix" Subject: Re: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 10:32:08, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 10:32:09, Serialize complete at 24/04/2007 10:32:09 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim, Thank you for your time for reviewing LCVP. See my responses below. >Denis, > >I finally found some time this weekend to review the LCVP >specification. I thought it was important to avoid snap judgements. >After reviewing the specification, I do not see a justification for >pursuing this document. > >If we consider this specification from a DPV client viewpoint, there >are very few differences between an LCVP client and the minimal SCVP >client. You identify the following differences (my numbering for >clarity): > > (1) the protocol only supports DPV, i.e. it includes no provision >to support Delegated Path Discovery (DPD); > (2) requests and responses are not signed, since they are >protected by TLS, where clients are not authenticated; > (3) validation is only for one certificate at a time; > (4) there is no specific parameter in the request to add any >parameter to a validation policy known by the server. > >However, this overstates the differences. (1) SCVP implementations >are not required to implement both DPD and DPV. (2) SCVP clients and >servers MUST support protected (e.g., signed) responses, but the >client may choose to use TLS as a protected transport to protect the >responses. This single argument (i.e. SCVP clients and servers MUST support protected (e.g., signed) responses) illustrates why it not make sense to mandate such a support when only transport layer security is being used. This means it is not effective to profile SCVP to only fulfill the requirements addressed by LCVP. >(3) Clients are not only permitted to submit requests one >certificate at a time, conforming client implementations are not >required to support multi-certificate requests. (4) As in 3, >modifying the validation policy need not be supported by conforming >clients. > >In short, LCVP does not provide functionality that is unavailable in >SCVP. This is incorrect. Please take a look at: validationTime GeneralizedTime, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, The meaning of producedAt in SCVP is different from the meaning of validationTime in LCVP. LCVP with this parameter may support the validation of certificates used for non repudiation puroposes, whereas SCVP can't. See the explanations about the grace period fullSubjectName allows to handle unique names, whereas SCVP can't. keyUsage and extKeyUsage simply allow a application to know these parameters without the need to process the certificate. Of course, using four new OIDs it would be possible to expand SCVP to support these parameters, but it wan't be as simple as in LCVP. >While LCVP's ASN.1 appears less complicated, I am glad you acknowlege the fact that LCVP is simpler than SCVP. > the data structures generated by minimally conforming SCVP DPV-only client >implementations appear to have similar levels of complexity. I do not think so. Beside the unneeded complexity of the response which results from the use of CMS: ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } there is a lot of OIDs to manage. Another example of overcomplexity is the mandatory use of the following OID { id-svp 1 } to specify the default validation policy, while LCVP may simply omit the parameter: valPolicyRef ValPolicyRef OPTIONAL, Furthermore, where LCVP allows any default validation policy, in SCVP : " The default validation policy MUST use the basic validation algorithm as its default validation algorithm". There is a French common saying, which states roughly the following: " Why keep it simple, when you can make it complicated ?" It would perfectly apply to an SCVP profile (if any was possible). >I cannot see any reason to pursue a new DPV protocol that ignores the >requirements established in 3379 within the IETF. It does not ignore them, but does not take all of them. > I can see the >rationale for a lightweight client profile for SCVP, as suggested by >others on this list, to demonstrate how simple an SCVP client can >actually be. A lightweight client profile for SCVP is not realistic without changing SCVP. SCVP is already in the hands of the RFC editor for publication as an RFC. Denis >Thanks, > >Tim Polk > >On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > >> >> >> I needed a simple protocol to delegate the validation of a >> certificate to a server, >> to be used in environments where a client does not need to demonstrate >> to somebody else that it got a given response from a server. This >> implies >> that the server is fully trusted by the client. >> >> I considered using a profile of SCVP. Remember that the "S" does >> not mean "Simple", >> or "Standard" anymore, but "Server-based". >> >> However, the use of CMS to encapsulate everything and allowing to >> optionally sign requests >> is not needed, and the use of a subset of the various OIDs is not >> trivial as well. >> >> I looked at other alternatives, outside the IETF, but they do not >> provide an adequate answer. >> >> This proposal is for lightweight clients, hence why it is called >> Lightweight >> Certificate Validation Protocol (LCVP), like LDAP is simpler than >> DAP. :-) >> >> LCVP only supports a subset of the mandatory requirements described in >> [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is >> not either a profile of SCVP. >> >> The major differences with SCVP are the following: >> >> - the protocol only supports DPV, i.e. it includes no provisions >> to support Delegated Path Discovery (DPD); >> >> - requests and responses are not signed, since they are protected >> by TLS, where clients are not authenticated; >> >> - validation is only for one certificate at a time; >> >> - there is no specific parameter in the request to add any >> parameter to a validation policy known by the server. >> >> LCVP allows a client to delegate certificate path validation to >> a trusted server. The path validation (e.g. making sure that none >> of the certificates in the path are revoked) is performed according >> to a set of rules called a validation policy. It allows >> simplification >> of client implementations and only uses of a set of validation >> policies >> known by the server. The document defines a protocol >> that can be used to: >> >> (1) validate one certificate according to one validation policy, >> (2) query the validation policies supported by an LCVP server. >> >> At this time, the document is a strawman proposal and has not yet >> been implemented. >> There are certainly errors in it and it can certainly be improved - >> while keeping it "light". >> >> At this time, the document is an individual draft targeted for the >> experimental category. >> >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt >> >> The document is proposed to the PKIX WG for consideration and >> comments. >> >> If the WG, later on, finds this approach interresting, then the >> document could be >> re-targeted to the standard track category. >> >> Denis >> >> > > Regards, Denis Pinkas Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8TBl9007833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 01:29:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O8TBAT007832; Tue, 24 Apr 2007 01:29:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O8SoGe007779 for ; Tue, 24 Apr 2007 01:29:10 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 7AD8741294; Tue, 24 Apr 2007 10:28:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 3ED9944293; Tue, 24 Apr 2007 10:28:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmlGBcEQZtQ9; Tue, 24 Apr 2007 10:28:40 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id C563044021; Tue, 24 Apr 2007 10:28:39 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Tue, 24 Apr 2007 10:28:39 +0200 From: "Julien Stern" Date: Tue, 24 Apr 2007 10:28:39 +0200 To: "David A. Cooper" Cc: Russ Housley , pkix Subject: Re: SCVP Question regarding Trust Anchors Message-ID: <20070424082839.GJ1691@mars.cry.pto> Mail-Followup-To: Julien Stern , "David A. Cooper" , Russ Housley , pkix References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> <462D2A85.1070307@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462D2A85.1070307@nist.gov> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, I agree that I can define my validation policy as I want and live with the ability to do this by only specifying an OID. Still, I believe the trade off has _really_ gone towards simplicity and not flexibility. Even the inhibitPolicyMapping, the requireExplicitPolicy and the inhibitAnyPolicy are booleans instead of integers. Also, I disagree that one can send multiple requests. The trust anchor for an OCSP response may not be the same as the one for the main certificate and may have conflicting parameters. Would it be complicated to leverage on RFC3125 which defines a Trust Anchor as: CertificateTrustPoint ::= SEQUENCE { trustpoint Certificate, -- self-signed certificate pathLenConstraint [0] PathLenConstraint OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, nameConstraints [2] NameConstraints OPTIONAL, policyConstraints [3] PolicyConstraints OPTIONAL } possibly replacing the Certificate by a PKCReference. -- Julien On Mon, Apr 23, 2007 at 05:52:05PM -0400, David A. Cooper wrote: > > > Russ, Julien, > > This was discussed on the list in early 2005 and the consensus was > against making this change. It was simply a trade off between > flexibility and complexity. In almost every case, the same set of > inputs (e.g., userPolicySet, inhibitPolicyMapping, > requireExplicitPolicy, etc.) are appropriate for each trust anchor. > Allowing different values to be specified for each trust anchor would > complicate things for all clients (and servers) for the benefit of the > few that would need this level of granularity in specifying validation > requirements and we already have enough complaints that SCVP is too > complicated. The few clients that need this degree of flexibility can > simply send multiple requests, with each request specifying a different > set of trust anchors along with the appropriate input values for that > set of trust anchors. > > (Note that in theory a validation policy could be defined in which > values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, > etc. were different for each trust anchor. The easiest way to do this > would be to only allow the client to specify the validation policy by > OID and to only include the validation policy by reference in the > response. That way the request would simply say "validate certificate X > under policy Y" and the response would say "the result of validating > certificate X under policy Y was ...". Since neither the request nor > the response would include any explicit information about the meaning of > policy Y, there would be no limitations on the complexity of the > definition of policy Y. Not that I would recommend defining overly > complicated validation policies, but I think it can be done with certain > limitations on what can be included in the request and in the response.) > > Dave > > Russ Housley wrote: > > > >You are right, in my personal opinion, that would be a better > >structure. Can you propose text? > > > >Russ > > > > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > > > >>Folks, > >> > >>sorry to ask this fairly late in the process, but it did not catch > >>my eye before: > >> > >>The ValidationPolicy structure defines > >>- userPolicySet > >>- inhibitPolicyMapping > >>- requireExplicitPolicy > >>- inhibitAnyPolicy > >> > >>globally and not on a per trust-anchor basis. > >> > >>Wouldn't it be more logical and less limiting to define it for each > >>trust anchor (like in RFC3125)... ? > >> > >>Regards, > >> > >>-- > >>Julien > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O7Dl9K098512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 00:13:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O7Dl1w098511; Tue, 24 Apr 2007 00:13:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O7DPXu098498 for ; Tue, 24 Apr 2007 00:13:46 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA44208; Tue, 24 Apr 2007 09:18:21 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042409131774:4519 ; Tue, 24 Apr 2007 09:13:17 +0200 Date: Tue, 24 Apr 2007 09:13:15 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Cc: "Julien Stern" Subject: Re: SCVP Question regarding Trust Anchors X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 09:13:17, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 24/04/2007 09:13:24, Serialize complete at 24/04/2007 09:13:24 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The comment from Julien is correct: multiple trust anchors with different conditions are not permittted, unless using a specific OID for the validation policy and have all the parameters known by the server. >You are right, in my personal opinion, that would be a better >structure. Can you propose text? In order to allow it, this would have required a small change in the ASN.1 structure. I made this remark to Tim, when he was editing the document, but it was not accepted. If a client wants to specify different parameters for each trust anchor, multiple calls will need to be made. Denis > >Russ > > >At 11:44 AM 4/23/2007, Julien Stern wrote: > >>Folks, >> >>sorry to ask this fairly late in the process, but it did not catch >>my eye before: >> >>The ValidationPolicy structure defines >>- userPolicySet >>- inhibitPolicyMapping >>- requireExplicitPolicy >>- inhibitAnyPolicy >> >>globally and not on a per trust-anchor basis. >> >>Wouldn't it be more logical and less limiting to define it for each >>trust anchor (like in RFC3125)... ? >> >>Regards, >> >>-- >>Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O3iBPd063541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 20:44:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O3iBNS063540; Mon, 23 Apr 2007 20:44:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from auth0.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O3hoKk063450 for ; Mon, 23 Apr 2007 20:44:10 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from auth0.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 6D6382CC41B; Tue, 24 Apr 2007 11:43:47 +0800 (CST) Received: from wcwang (unknown [10.144.133.93]) by auth0.cht.com.tw (Postfix) with SMTP id 3BC9F2CC3EF; Tue, 24 Apr 2007 11:43:47 +0800 (CST) Message-ID: <002601c78622$c31e6e70$5d85900a@wcwang> From: "Wen-Cheng Wang" To: "Massimiliano Pala" , "pkix" References: <462D05DA.5060002@cs.dartmouth.edu> Subject: Re: PKI Resource Discovery - Proposal for a new Working Item Date: Tue, 24 Apr 2007 11:43:41 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dr. Massimiliano Pala, That is an interesting idea. However, one imaginable problem you might face is "how a relying party (the PRQP client) can find an authroized RQA?" One straightforward way is to let the CA issue a certificate first to delegate the authority to the RQA and then use AIA/SIA extnesions to provide the URL of the authroized RQA (the authroized PRQP server) to the PRQP client. If you are going to adopt this kind of straightforward solution, it will not be a painless rollover from traditional ways (embed various pointers via CDP, AIA or SIA extensions) to the new way (a single AIA/SIA extension comtaining the authroized PRQP access info). The reason why it will not be a painless rollover is that the goal can not be achieved without the need to re-issuing all the existing certificates to add the newly defined PRQP access info into the AIA/SIA extension. Wen-Cheng Wang ----- Original Message ----- From: "Massimiliano Pala" To: "pkix" Sent: Tuesday, April 24, 2007 3:15 AM Subject: PKI Resource Discovery - Proposal for a new Working Item > Hello PKI-ers, > > I was looking at all the different possibilities we have now for `discovering' > PKI related resources, where by resources I include repositories and services > provided by a CA. For example an LDAP server, a CRL repository or an OCSP > service. > > Actually the `standard' way to do so is to embed pointers into certificates > via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, > as it is quite static (e.g., CA certs have usually quite long life period). > Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but > none of them seems to be supported widely across apps and systems. My take > is because possible solutions are many and they can be difficult to implement > (and some of them do not really provide an efficient solution, for example > the DNS approach requires that the application knows which is the right domain > to query for a service---which might not be trivial if the DC format is not > used). > > I am working on a proposal for developing a protocol to provide a specific > solution to the problem, and I really would like the WG to discuss the > problem and the proposed solution. > > I have a brief description of the work done so far here: > > http://www.openca.org/projects/libprqp > > Main goals of this work are: > * to make it easy for developers to discover PKI resources > * to provide a method to dynamically update PKI resources information > * to split pki-services management from certificates contents. For example > it would help in painless rollover between services, e.g. switching from > CRLs to OCSP without the need to re-issuing all the certificates (an example > could be taken from the DoD PKI) > > We might say that this protocol would provide a way to map X509 certificates to > network resources by providing pointers (URLs) to applications. > > I hope this idea could have some consent here and some help also in writing > a first draft. We might also setup a slot to discuss this idea at the next > IETF Meeting... > > Thanks for your attention in reading this email, I hope to receive many > useful comments and suggestions and, hopefully, also some help in this > task. > > > -- > > Best Regards, > > Dr. Massimiliano Pala > > --o------------------------------------------------------------------------ > Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu > project.manager@openca.org > > Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 > PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 > --o------------------------------------------------------------------------ > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNpR87029293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNpRT5029292; Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNp6JY029218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 16:51:27 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-249.fastq.com [65.39.92.249]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l3NNovVa083499; Mon, 23 Apr 2007 16:50:57 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Russ Housley" , "Julien Stern" , Subject: RE: SCVP Question regarding Trust Anchors Date: Mon, 23 Apr 2007 15:14:08 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Julien: To what benefit? Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley Sent: Monday, April 23, 2007 11:44 AM To: Julien Stern; ietf-pkix@imc.org Subject: Re: SCVP Question regarding Trust Anchors You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNNfHu024802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNNfp1024801; Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.ttu.edu (echion.net.ttu.edu [129.118.1.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNNflD024795 for ; Mon, 23 Apr 2007 16:23:41 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:23:40 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:23:19 -0500 Received: from mxin2.ttu.edu ([129.118.1.191]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 18:10:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin2.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:10:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqYCK009746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NLqYuk009745; Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqC3E009615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 14:52:33 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3NLplol010753; Mon, 23 Apr 2007 17:51:47 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l3NLp2fg027606; Mon, 23 Apr 2007 17:51:03 -0400 (EDT) Message-ID: <462D2A85.1070307@nist.gov> Date: Mon, 23 Apr 2007 17:52:05 -0400 From: "David A. Cooper" User-Agent: Thunderbird 1.5.0.10 (X11/20070305) MIME-Version: 1.0 To: Russ Housley CC: Julien Stern , pkix Subject: Re: SCVP Question regarding Trust Anchors References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 23:10:11.0463 (UTC) FILETIME=[8B0F3170:01C785FC] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Julien, This was discussed on the list in early 2005 and the consensus was against making this change. It was simply a trade off between flexibility and complexity. In almost every case, the same set of inputs (e.g., userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc.) are appropriate for each trust anchor. Allowing different values to be specified for each trust anchor would complicate things for all clients (and servers) for the benefit of the few that would need this level of granularity in specifying validation requirements and we already have enough complaints that SCVP is too complicated. The few clients that need this degree of flexibility can simply send multiple requests, with each request specifying a different set of trust anchors along with the appropriate input values for that set of trust anchors. (Note that in theory a validation policy could be defined in which values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc. were different for each trust anchor. The easiest way to do this would be to only allow the client to specify the validation policy by OID and to only include the validation policy by reference in the response. That way the request would simply say "validate certificate X under policy Y" and the response would say "the result of validating certificate X under policy Y was ...". Since neither the request nor the response would include any explicit information about the meaning of policy Y, there would be no limitations on the complexity of the definition of policy Y. Not that I would recommend defining overly complicated validation policies, but I think it can be done with certain limitations on what can be included in the request and in the response.) Dave Russ Housley wrote: > > You are right, in my personal opinion, that would be a better > structure. Can you propose text? > > Russ > > > At 11:44 AM 4/23/2007, Julien Stern wrote: > >> Folks, >> >> sorry to ask this fairly late in the process, but it did not catch >> my eye before: >> >> The ValidationPolicy structure defines >> - userPolicySet >> - inhibitPolicyMapping >> - requireExplicitPolicy >> - inhibitAnyPolicy >> >> globally and not on a per trust-anchor basis. >> >> Wouldn't it be more logical and less limiting to define it for each >> trust anchor (like in RFC3125)... ? >> >> Regards, >> >> -- >> Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMems024604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:22:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNMexw024603; Mon, 23 Apr 2007 16:22:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.ttu.edu (echion.net.ttu.edu [129.118.1.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMJnk024518 for ; Mon, 23 Apr 2007 16:22:39 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:22:12 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:21:47 -0500 Received: from mxin4.ttu.edu ([129.118.1.167]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 15:59:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin4.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:34:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJGA7R090016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJGA6a090015; Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJFkUf089980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 12:16:09 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3NJFcKs026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2007 15:15:39 -0400 Message-ID: <462D05DA.5060002@cs.dartmouth.edu> Date: Mon, 23 Apr 2007 15:15:38 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: pkix Subject: PKI Resource Discovery - Proposal for a new Working Item References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703040300000409040303" List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 20:34:52.0458 (UTC) FILETIME=[D87FE0A0:01C785E6] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030703040300000409040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello PKI-ers, I was looking at all the different possibilities we have now for `discovering' PKI related resources, where by resources I include repositories and services provided by a CA. For example an LDAP server, a CRL repository or an OCSP service. Actually the `standard' way to do so is to embed pointers into certificates via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, as it is quite static (e.g., CA certs have usually quite long life period). Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but none of them seems to be supported widely across apps and systems. My take is because possible solutions are many and they can be difficult to implement (and some of them do not really provide an efficient solution, for example the DNS approach requires that the application knows which is the right domain to query for a service---which might not be trivial if the DC format is not used). I am working on a proposal for developing a protocol to provide a specific solution to the problem, and I really would like the WG to discuss the problem and the proposed solution. I have a brief description of the work done so far here: http://www.openca.org/projects/libprqp Main goals of this work are: * to make it easy for developers to discover PKI resources * to provide a method to dynamically update PKI resources information * to split pki-services management from certificates contents. For example it would help in painless rollover between services, e.g. switching from CRLs to OCSP without the need to re-issuing all the certificates (an example could be taken from the DoD PKI) We might say that this protocol would provide a way to map X509 certificates to network resources by providing pointers (URLs) to applications. I hope this idea could have some consent here and some help also in writing a first draft. We might also setup a slot to discuss this idea at the next IETF Meeting... Thanks for your attention in reading this email, I hope to receive many useful comments and suggestions and, hopefully, also some help in this task. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms030703040300000409040303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIzMTkxNTM4WjAjBgkqhkiG9w0B CQQxFgQUhnkTyRknjTYw6D8fjJZSAAsN8x4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB2B7Qc0TIzw/3ElG/NFU2U HGsqz0JgbFqQGQ+OGOLU0F7thGYFSWMUxBIY7lezT56FUOwJM1litafdlrnwrrHJWwz1Xs74 rryZcy/O7Ih6kyGRYADznuQbCF6Mys3iBc2cjDKYF+U6QBB6E6InOuKR52NV/lTvMXVAh5HD /9R3AAAAAAAAAA== --------------ms030703040300000409040303-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMXBa024560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 16:22:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NNMXK1024559; Mon, 23 Apr 2007 16:22:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx2.ttu.edu (phorphyrion.net.ttu.edu [129.118.1.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NNMCW9024481 for ; Mon, 23 Apr 2007 16:22:32 -0700 (MST) (envelope-from housley@vigilsec.com) Received: from CETO.net.ttu.edu ([129.118.1.102]) by mx2.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 18:22:05 -0500 Received: from mail pickup service by CETO.net.ttu.edu with Microsoft SMTPSVC; Mon, 23 Apr 2007 18:21:43 -0500 Received: from mxin1.ttu.edu ([129.118.1.173]) by CETO.net.ttu.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Apr 2007 15:59:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by mxin1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:53:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJrA2q095237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJrAGe095236; Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3NJr9VR095229 for ; Mon, 23 Apr 2007 12:53:09 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704231953.l3NJr9VR095229@balder-227.proper.com> Received: (qmail 21940 invoked by uid 0); 23 Apr 2007 19:53:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Apr 2007 19:53:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 15:44:28 -0400 To: "Julien Stern" , ietf-pkix@imc.org From: Russ Housley Subject: Re: SCVP Question regarding Trust Anchors In-Reply-To: <20070423154446.GF1691@mars.cry.pto> References: <20070423154446.GF1691@mars.cry.pto> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-ID: List-Unsubscribe: X-OriginalArrivalTime: 23 Apr 2007 20:53:33.0210 (UTC) FILETIME=[74850FA0:01C785E9] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqYCK009746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NLqYuk009745; Mon, 23 Apr 2007 14:52:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NLqC3E009615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 14:52:33 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3NLplol010753; Mon, 23 Apr 2007 17:51:47 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l3NLp2fg027606; Mon, 23 Apr 2007 17:51:03 -0400 (EDT) Message-ID: <462D2A85.1070307@nist.gov> Date: Mon, 23 Apr 2007 17:52:05 -0400 From: "David A. Cooper" User-Agent: Thunderbird 1.5.0.10 (X11/20070305) MIME-Version: 1.0 To: Russ Housley CC: Julien Stern , pkix Subject: Re: SCVP Question regarding Trust Anchors References: <20070423154446.GF1691@mars.cry.pto> <200704231953.l3NJr9VR095229@balder-227.proper.com> In-Reply-To: <200704231953.l3NJr9VR095229@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Julien, This was discussed on the list in early 2005 and the consensus was against making this change. It was simply a trade off between flexibility and complexity. In almost every case, the same set of inputs (e.g., userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc.) are appropriate for each trust anchor. Allowing different values to be specified for each trust anchor would complicate things for all clients (and servers) for the benefit of the few that would need this level of granularity in specifying validation requirements and we already have enough complaints that SCVP is too complicated. The few clients that need this degree of flexibility can simply send multiple requests, with each request specifying a different set of trust anchors along with the appropriate input values for that set of trust anchors. (Note that in theory a validation policy could be defined in which values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, etc. were different for each trust anchor. The easiest way to do this would be to only allow the client to specify the validation policy by OID and to only include the validation policy by reference in the response. That way the request would simply say "validate certificate X under policy Y" and the response would say "the result of validating certificate X under policy Y was ...". Since neither the request nor the response would include any explicit information about the meaning of policy Y, there would be no limitations on the complexity of the definition of policy Y. Not that I would recommend defining overly complicated validation policies, but I think it can be done with certain limitations on what can be included in the request and in the response.) Dave Russ Housley wrote: > > You are right, in my personal opinion, that would be a better > structure. Can you propose text? > > Russ > > > At 11:44 AM 4/23/2007, Julien Stern wrote: > >> Folks, >> >> sorry to ask this fairly late in the process, but it did not catch >> my eye before: >> >> The ValidationPolicy structure defines >> - userPolicySet >> - inhibitPolicyMapping >> - requireExplicitPolicy >> - inhibitAnyPolicy >> >> globally and not on a per trust-anchor basis. >> >> Wouldn't it be more logical and less limiting to define it for each >> trust anchor (like in RFC3125)... ? >> >> Regards, >> >> -- >> Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJrA2q095237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJrAGe095236; Mon, 23 Apr 2007 12:53:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3NJr9VR095229 for ; Mon, 23 Apr 2007 12:53:09 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704231953.l3NJr9VR095229@balder-227.proper.com> Received: (qmail 21940 invoked by uid 0); 23 Apr 2007 19:53:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Apr 2007 19:53:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 15:44:28 -0400 To: "Julien Stern" , ietf-pkix@imc.org From: Russ Housley Subject: Re: SCVP Question regarding Trust Anchors In-Reply-To: <20070423154446.GF1691@mars.cry.pto> References: <20070423154446.GF1691@mars.cry.pto> 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: You are right, in my personal opinion, that would be a better structure. Can you propose text? Russ At 11:44 AM 4/23/2007, Julien Stern wrote: >Folks, > >sorry to ask this fairly late in the process, but it did not catch >my eye before: > >The ValidationPolicy structure defines >- userPolicySet >- inhibitPolicyMapping >- requireExplicitPolicy >- inhibitAnyPolicy > >globally and not on a per trust-anchor basis. > >Wouldn't it be more logical and less limiting to define it for each >trust anchor (like in RFC3125)... ? > >Regards, > >-- >Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJGA7R090016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJGA6a090015; Mon, 23 Apr 2007 12:16:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJFkUf089980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Apr 2007 12:16:09 -0700 (MST) (envelope-from pala@cs.dartmouth.edu) Received: from [129.170.212.228] (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.8) with ESMTP id l3NJFcKs026605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2007 15:15:39 -0400 Message-ID: <462D05DA.5060002@cs.dartmouth.edu> Date: Mon, 23 Apr 2007 15:15:38 -0400 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0a1 (X11/20060724) MIME-Version: 1.0 To: pkix Subject: PKI Resource Discovery - Proposal for a new Working Item References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030703040300000409040303" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030703040300000409040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello PKI-ers, I was looking at all the different possibilities we have now for `discovering' PKI related resources, where by resources I include repositories and services provided by a CA. For example an LDAP server, a CRL repository or an OCSP service. Actually the `standard' way to do so is to embed pointers into certificates via CDP, AIA or SIA extensions. Of course this approach has its own drawbacks, as it is quite static (e.g., CA certs have usually quite long life period). Other possibilities exist (e.g., DNS SRV records, Webservices, etc... ) but none of them seems to be supported widely across apps and systems. My take is because possible solutions are many and they can be difficult to implement (and some of them do not really provide an efficient solution, for example the DNS approach requires that the application knows which is the right domain to query for a service---which might not be trivial if the DC format is not used). I am working on a proposal for developing a protocol to provide a specific solution to the problem, and I really would like the WG to discuss the problem and the proposed solution. I have a brief description of the work done so far here: http://www.openca.org/projects/libprqp Main goals of this work are: * to make it easy for developers to discover PKI resources * to provide a method to dynamically update PKI resources information * to split pki-services management from certificates contents. For example it would help in painless rollover between services, e.g. switching from CRLs to OCSP without the need to re-issuing all the certificates (an example could be taken from the DoD PKI) We might say that this protocol would provide a way to map X509 certificates to network resources by providing pointers (URLs) to applications. I hope this idea could have some consent here and some help also in writing a first draft. We might also setup a slot to discuss this idea at the next IETF Meeting... Thanks for your attention in reading this email, I hope to receive many useful comments and suggestions and, hopefully, also some help in this task. -- Best Regards, Dr. Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------ --------------ms030703040300000409040303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8 fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91 dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0 dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3 DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6 AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1 MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG 9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8 K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0 aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0 cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4 MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0 bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIzMTkxNTM4WjAjBgkqhkiG9w0B CQQxFgQUhnkTyRknjTYw6D8fjJZSAAsN8x4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT 8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB2B7Qc0TIzw/3ElG/NFU2U HGsqz0JgbFqQGQ+OGOLU0F7thGYFSWMUxBIY7lezT56FUOwJM1litafdlrnwrrHJWwz1Xs74 rryZcy/O7Ih6kyGRYADznuQbCF6Mys3iBc2cjDKYF+U6QBB6E6InOuKR52NV/lTvMXVAh5HD /9R3AAAAAAAAAA== --------------ms030703040300000409040303-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NFjLGj058912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NFjLEY058911; Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NFj0d9058869 for ; Mon, 23 Apr 2007 08:45:21 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 47BCC41097 for ; Mon, 23 Apr 2007 17:44:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 1325544293 for ; Mon, 23 Apr 2007 17:44:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL6CcpqFNqlj for ; Mon, 23 Apr 2007 17:44:47 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 974F944160 for ; Mon, 23 Apr 2007 17:44:46 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Mon, 23 Apr 2007 17:44:46 +0200 From: "Julien Stern" Date: Mon, 23 Apr 2007 17:44:46 +0200 To: ietf-pkix@imc.org Subject: SCVP Question regarding Trust Anchors Message-ID: <20070423154446.GF1691@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, sorry to ask this fairly late in the process, but it did not catch my eye before: The ValidationPolicy structure defines - userPolicySet - inhibitPolicyMapping - requireExplicitPolicy - inhibitAnyPolicy globally and not on a per trust-anchor basis. Wouldn't it be more logical and less limiting to define it for each trust anchor (like in RFC3125)... ? Regards, -- Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NELTQU051774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 07:21:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NELTgN051773; Mon, 23 Apr 2007 07:21:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NEL62r051726 for ; Mon, 23 Apr 2007 07:21:28 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l3NEKk1i025250; Mon, 23 Apr 2007 10:20:46 -0400 (EDT) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 23 Apr 2007 10:20:46 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 10:20:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Mon, 23 Apr 2007 10:20:45 -0400 Message-ID: In-Reply-To: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceFK11UoDZ3DDp/SY+AIcU4LSAFUwAgru8Q References: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> From: "Kemp, David P." To: "Tim Polk" , "Denis Pinkas" Cc: "pkix" , "Sam Hartman" , "Russ Housley" , "Stephen Kent" , "Stefan Santesson" X-OriginalArrivalTime: 23 Apr 2007 14:20:46.0422 (UTC) FILETIME=[959E9760:01C785B2] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15128001 X-TM-AS-Result: : Yes--20.682000-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xNTEy?= =?us-ascii?B?NjAtNzA3NDEwLTcxMDM3NS03MDA4NjktNzAwODA3LTEyMTE1NS03?= =?us-ascii?B?MDIzNTgtNzAwNDc2LTcwMjI2MC03MDE1NzYtMTIxNzAxLTcwNzE2?= =?us-ascii?B?My03MDI2NDMtNzA0NDQ1LTcwNjI0Ny03MDcxMTQtNzA2ODIzLTcw?= =?us-ascii?B?MjcyNi03MDIxMzEtMTM5NzA0LTcwNzU0NS03MDAyNzItMTM5MDA2?= =?us-ascii?B?LTcwNDI4Ny03MDM4MjktNzEwNTU2LTcwMTAwNy03MDA3OTItMTIx?= =?us-ascii?B?NjQ4LTcwNDQzMC0xMTM2NjAtNzAzMjc3LTcwNTQ0MS03MDk1ODQt?= =?us-ascii?B?NzA0MzExLTcwMTQ1NS03MTE0MDItNzAxOTM3LTcwNTk2OS03MDM1?= =?us-ascii?B?NDMtNzA0NDIxLTcwMjc2Mi0xMjExMjQtNzAyNDg1LTcwMzg1MS0x?= =?us-ascii?B?ODYxMDItNzAwODMzLTcwNTkwNi03MDI2MjYtNzA3OTk3LTcwNDc4?= =?us-ascii?B?Mi03MDM5OTgtNzAwMTA0LTcwMTEwNy03MDQ0MjUtNzAyMzY3LTcw?= =?us-ascii?B?MTg1My03MDgxNzktNzA0OTgwLTcwMDEwNy03MDAwNzUtMTM5MDEw?= =?us-ascii?B?LTcwMjEyNi03MDU0MjQtNzA2NTYxLTcwMDYxNy03MTA4MDctNzA2?= =?us-ascii?B?NTY0LTcwOTQxNS03MDIwOTctNzAzNTg5LTcwMjkyMC03MDAyOTMt?= =?us-ascii?B?NzA2MTU3LTcwMTYxOC03MDIzNzYtNzA1NTI2LTcwMTQ0Ni03MDUw?= =?us-ascii?B?OTAtMTg2MDM1LTcwODE5Ni03MDQzNDItMTQ4MDUwLTIwMDQz?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3NELS2r051767 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim, Santosh indicates that SCVP could be "revised" (not profiled) to meet the needs of (2) transport-only protection. Does the working group support modifying SCVP so that clients SHOULD (vice MUST) support signed responses? On the surface that sounds reasonable, but a truly lightweight validation protocol would use message protection (signed or authenticated) and a UDP request/response like DNS, rather than a TCP handshake plus a TLS handshake. Just because everyone has a TLS library does not mean that TLS treads lightly on the network. See http://www3.ietf.org/proceedings/07mar/slides/isms-1.pdf Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tim Polk Sent: Sunday, April 22, 2007 5:24 PM To: Denis Pinkas Cc: pkix; Sam Hartman; Russ Housley; Stephen Kent; Stefan Santesson Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Denis, I finally found some time this weekend to review the LCVP specification. I thought it was important to avoid snap judgements. After reviewing the specification, I do not see a justification for pursuing this document. If we consider this specification from a DPV client viewpoint, there are very few differences between an LCVP client and the minimal SCVP client. You identify the following differences (my numbering for clarity): (1) the protocol only supports DPV, i.e. it includes no provision to support Delegated Path Discovery (DPD); (2) requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; (3) validation is only for one certificate at a time; (4) there is no specific parameter in the request to add any parameter to a validation policy known by the server. However, this overstates the differences. (1) SCVP implementations are not required to implement both DPD and DPV. (2) SCVP clients and servers MUST support protected (e.g., signed) responses, but the client may choose to use TLS as a protected transport to protect the responses. (3) Clients are not only permitted to submit requests one certificate at a time, conforming client implementations are not required to support multi-certificate requests. (4) As in 3, modifying the validation policy need not be supported by conforming clients. In short, LCVP does not provide functionality that is unavailable in SCVP. While LCVP's ASN.1 appears less complicated, the data structures generated by minimally conforming SCVP DPV-only client implementations appear to have similar levels of complexity. I cannot see any reason to pursue a new DPV protocol that ignores the requirements established in 3379 within the IETF. I can see the rationale for a lightweight client profile for SCVP, as suggested by others on this list, to demonstrate how simple an SCVP client can actually be. Thanks, Tim Polk On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > > > I needed a simple protocol to delegate the validation of a > certificate to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does > not mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows > simplification > of client implementations and only uses of a set of validation > policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet > been implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and > comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MLOkHm027767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 14:24:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MLOkeJ027766; Sun, 22 Apr 2007 14:24:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MLONM2027727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Apr 2007 14:24:44 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [129.6.222.17] ([129.6.222.17]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3MLNr74018026; Sun, 22 Apr 2007 17:23:53 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16907C96-CA09-4C95-9C57-2FB2AA83103A@nist.gov> Cc: pkix , Sam Hartman , Russ Housley , Stephen Kent , Stefan Santesson Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 17:23:52 -0400 To: Denis Pinkas X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I finally found some time this weekend to review the LCVP specification. I thought it was important to avoid snap judgements. After reviewing the specification, I do not see a justification for pursuing this document. If we consider this specification from a DPV client viewpoint, there are very few differences between an LCVP client and the minimal SCVP client. You identify the following differences (my numbering for clarity): (1) the protocol only supports DPV, i.e. it includes no provision to support Delegated Path Discovery (DPD); (2) requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; (3) validation is only for one certificate at a time; (4) there is no specific parameter in the request to add any parameter to a validation policy known by the server. However, this overstates the differences. (1) SCVP implementations are not required to implement both DPD and DPV. (2) SCVP clients and servers MUST support protected (e.g., signed) responses, but the client may choose to use TLS as a protected transport to protect the responses. (3) Clients are not only permitted to submit requests one certificate at a time, conforming client implementations are not required to support multi-certificate requests. (4) As in 3, modifying the validation policy need not be supported by conforming clients. In short, LCVP does not provide functionality that is unavailable in SCVP. While LCVP's ASN.1 appears less complicated, the data structures generated by minimally conforming SCVP DPV-only client implementations appear to have similar levels of complexity. I cannot see any reason to pursue a new DPV protocol that ignores the requirements established in 3379 within the IETF. I can see the rationale for a lightweight client profile for SCVP, as suggested by others on this list, to demonstrate how simple an SCVP client can actually be. Thanks, Tim Polk On Apr 20, 2007, at 8:19 AM, Denis Pinkas wrote: > > > I needed a simple protocol to delegate the validation of a > certificate to a server, > to be used in environments where a client does not need to demonstrate > to somebody else that it got a given response from a server. This > implies > that the server is fully trusted by the client. > > I considered using a profile of SCVP. Remember that the "S" does > not mean "Simple", > or "Standard" anymore, but "Server-based". > > However, the use of CMS to encapsulate everything and allowing to > optionally sign requests > is not needed, and the use of a subset of the various OIDs is not > trivial as well. > > I looked at other alternatives, outside the IETF, but they do not > provide an adequate answer. > > This proposal is for lightweight clients, hence why it is called > Lightweight > Certificate Validation Protocol (LCVP), like LDAP is simpler than > DAP. :-) > > LCVP only supports a subset of the mandatory requirements described in > [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is > not either a profile of SCVP. > > The major differences with SCVP are the following: > > - the protocol only supports DPV, i.e. it includes no provisions > to support Delegated Path Discovery (DPD); > > - requests and responses are not signed, since they are protected > by TLS, where clients are not authenticated; > > - validation is only for one certificate at a time; > > - there is no specific parameter in the request to add any > parameter to a validation policy known by the server. > > LCVP allows a client to delegate certificate path validation to > a trusted server. The path validation (e.g. making sure that none > of the certificates in the path are revoked) is performed according > to a set of rules called a validation policy. It allows > simplification > of client implementations and only uses of a set of validation > policies > known by the server. The document defines a protocol > that can be used to: > > (1) validate one certificate according to one validation policy, > (2) query the validation policies supported by an LCVP server. > > At this time, the document is a strawman proposal and has not yet > been implemented. > There are certainly errors in it and it can certainly be improved - > while keeping it "light". > > At this time, the document is an individual draft targeted for the > experimental category. > > The document is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt > > The document is proposed to the PKIX WG for consideration and > comments. > > If the WG, later on, finds this approach interresting, then the > document could be > re-targeted to the standard track category. > > Denis > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJhAr7009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 12:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MJhAl2009699; Sun, 22 Apr 2007 12:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJgmJc009616 for ; Sun, 22 Apr 2007 12:43:09 -0700 (MST) (envelope-from shitchings@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 15:42:46 -0400 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0024_01C784DB.BA59CCA0" Message-ID: In-Reply-To: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQAGlMiuAABnca8A== References: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> From: "Seth Hitchings" To: "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C784DB.BA59CCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh and Denis, My reading of the current SCVP draft (31) is that it allows unprotected responses to DPV queries when the transport mechanism is protected. Section 3.2.5.3, protectResponse, reads: SCVP clients that support delegated path validation (DPV) as defined in [RQMTS] require an authenticated response. Unless a protected transport mechanism (such a TLS) is used, such clients MUST always set this value to TRUE or omit the responseFlags item entirely, which requires the server to return a protected response. And section 4, Validation Response, begins: There are a number of forms of an SCVP response: 1. A success response to a request that has protectResponse set to FALSE. These responses SHOULD NOT be protected by the server. 2. The server MUST protect all other success responses. If the server is unable to return a protected success response due to local policy, then it MUST return an error response. It seems to me that a client can make a very simple DPV request over TLS by setting protectResponse to false, asserting only the id-stc-build-status-checked-pkc-path check, and omitting the wantBack item. Seth -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Sunday, April 22, 2007 9:36 AM To: pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I agree with Dave Engberg. Prior to PKIX taking this on as a Standards Track or Experimental RFC or other work item, an attempt must be made to profile SCVP for lightweight operations that meet most community needs. I have not done an analysis as to how this would turn out, but got curious and looked at the signature aspects of validation responses. My reading of the draft SCVP I-D is that it requires signed data or authenticated data for valid responses. In addition, the Server must be capable of generating signed data. It seems that Denis wants unprotected valid responses since the channel protects the responses. I think either the SCVP or the lightweight version can be revised to accommodate this. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Friday, April 20, 2007 10:26 AM To: Denis Pinkas; pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis ------=_NextPart_000_0024_01C784DB.BA59CCA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3DCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA5IwggL7oAMCAQICAgCiMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNzE0NDgzNloXDTA3 MDkyNjE0NDgzNlowajELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEXMBUG A1UEAxMOU2V0aCBIaXRjaGluZ3MxKDAmBgkqhkiG9w0BCQEWGXNoaXRjaGluZ3NAY29yZXN0cmVl dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDULuw99zAAo0bVVJO8Muclrezh TKZpRgvLmNtEMSgZQHezFesdIs3MM1V4dT7rmf8JIm9ugAZrYrpOK79402QQvFhY4gVaBkPQflR3 u/yKvVO8BWcKeaCZAu9SiHW9MqMMSkh+qX8b3Var9T/6clbxMeCx37wByra6uvAPKfZUmnTERMqF IybXd5rkejV6Sn3Madu4iYh3FWd8sQEWV2Pqpz9IBjMRzXOKfFEPbopvGOCiXtnyzTiz00yh8JDe UZWf9K0jhBG7u8KeebWyxfANPbgnn89lCFZjkAz0aEhJpXxwsWqnjH1S6IfvnWxu59J5pecAAizr +iKDhaiwaBPZAgMBAAGjgdowgdcwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0 dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwJAYDVR0RBB0wG4EZc2hp dGNoaW5nc0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBA BggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJl ZXQuY29tLzANBgkqhkiG9w0BAQUFAAOBgQB0vJkV8SBdmz9K5S+Tw+0o1G08vfYQRDYcOzyoriV7 gZi8/vmnaUL7GMYRaEv3ei7LyLDXIm2FJSH5bZACEIR5Jhl5QWByV6F8EdlOYRUKn/PQgNhqWH9q B6I+Sn/Tqfgtm3ssboe6yJFBIQnk9S3WmIxHhGCPptQ0fvM8jy9BwzGCAx0wggMZAgEBMFgwUjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVl dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCiMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyMjE5NDI0NlowIwYJKoZIhvcNAQkEMRYE FDP98I/3yFHoeMN4zO45tstZPRDYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMGcGCSsGAQQBgjcQBDFaMFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0Nv cmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkC AgCiMGkGCyqGSIb3DQEJEAILMVqgWDBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVl dCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICAKIwDQYJ KoZIhvcNAQEBBQAEggEAJDcXEbSNbQAK+X7HzKpR2OqHe/VJNLqFz5fkyPQ/a6IIzjEmUdmre9yz RzEfphqXbA8inQJc0dwxlZWx3mRXmBe2E2WoH10rwxw/WmFG8KnxG9XK57uk4UwYQ3qQZQuaTj7K /RCePY/qAyFpEjwXQdMN5hG76KgwG8pR1fsm4srTxt9Gayk2oS2hbgi7MRUVq+rnGhlXc3Dj58oX QAWV40N6UmnLtJPuAqjSLL1vNb+w3hXUFkg5+KCuaVbe1rp9RAQ1ij+ceQ/br/hfdXpAhFd25Chl wraRNmQERts7q/oeF53i+DP0BSKnzvBP1ZeEwUiL97Zh3DL1MSMNYoJEQAAAAAAAAA== ------=_NextPart_000_0024_01C784DB.BA59CCA0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MGbDHj077522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MGbDLY077521; Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MGaqKe077475 for ; Sun, 22 Apr 2007 09:37:13 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Lightweight Certificate Validation Protocol (LCVP) Date: Sun, 22 Apr 2007 09:36:10 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87907742325@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) thread-index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQAGlMiuA= References: From: "Santosh Chokhani" To: "pkix" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3MGbDKe077514 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Dave Engberg. Prior to PKIX taking this on as a Standards Track or Experimental RFC or other work item, an attempt must be made to profile SCVP for lightweight operations that meet most community needs. I have not done an analysis as to how this would turn out, but got curious and looked at the signature aspects of validation responses. My reading of the draft SCVP I-D is that it requires signed data or authenticated data for valid responses. In addition, the Server must be capable of generating signed data. It seems that Denis wants unprotected valid responses since the channel protects the responses. I think either the SCVP or the lightweight version can be revised to accommodate this. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dave Engberg Sent: Friday, April 20, 2007 10:26 AM To: Denis Pinkas; pkix Subject: RE: Lightweight Certificate Validation Protocol (LCVP) I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis Received: from [83.225.47.230] ([217.200.126.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KMMjKb082238 for ; Fri, 20 Apr 2007 15:22:49 -0700 (MST) (envelope-from TEY-Ledbetter@VISUALINFINITY.NET) Received: from bingo ([193.117.7.196]:14446 "EHLO bingo" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [83.225.47.230] with ESMTP id S22ANGXXBBESZRAZ (ORCPT ); Sat, 21 Apr 2007 00:20:23 +0200 Date: Sat, 21 Apr 2007 00:19:46 +0200 From: "TEY Ledbetter" Reply-To: "TEY Ledbetter" Message-ID: <117050221603.861834310725@VISUALINFINITY.NET> To: Subject: problems poorly written MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original It's an experiment of some sort, I'd guess. AN ALLE FINANZINVESTOREN! DIESE AKTIE WIRD DURCHSTARTEN! FREITAG 20. APRIL STARTET DIE HAUSSE! REALISIERTER KURSGEWINN VON 400%+ IN 5 TAGEN! Symbol: G7Q.F Company: COUNTY LINE ENERGY 5 Tages Kursziel: 0.95 Schlusskurs: 0.21 WKN: A0J3B0 ISIN: US2224791077 Markt: Frankfurt LASSEN SIE SICH DIESE CHANCE NICHT ENTGEHEN! G7Q WIRD WIE EINE RAKETE DURCHSTARTEN! UNSERE ERWARTUNGEN WIRD G7Q.F UBERTREFFEN! Have fun with the new, leaner arithmetic and logical parsing, and I'll see you soon with relationals. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEoPg8013366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KEoPE5013365; Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEo2jF013304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 Apr 2007 07:50:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 924CA1773A; Fri, 20 Apr 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HeuR0-0000Ci-Bm; Fri, 20 Apr 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-10.txt Message-Id: Date: Fri, 20 Apr 2007 10:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --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 : Lightweight OCSP Profile for High Volume Environments Author(s) : R. Hurst, A. Deacon Filename : draft-ietf-pkix-lightweight-ocsp-profile-10.txt Pages : 20 Date : 2007-4-20 This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client side processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-lightweight-ocsp-profile-10.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-lightweight-ocsp-profile-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-20091812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-lightweight-ocsp-profile-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20091812.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEQJVu011115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 07:26:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KEQJU0011114; Fri, 20 Apr 2007 07:26:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KEPvvX011081 for ; Fri, 20 Apr 2007 07:26:18 -0700 (MST) (envelope-from dengberg@corestreet.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Lightweight Certificate Validation Protocol (LCVP) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 20 Apr 2007 10:25:58 -0400 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_001F_01C78336.49661D10" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Lightweight Certificate Validation Protocol (LCVP) Thread-Index: AceDSYzVwfYEVkLTQNep4gEb0pKs+QADMJSQ From: "Dave Engberg" To: "Denis Pinkas" , "pkix" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C78336.49661D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would recommend writing this as a profile of SCVP instead of implementing yet another certificate validation protocol. This would be similar to what Hurst and Deacon did with their Lightweight OCSP Profile, which put constraints on OCSP client requests to improve performance and scalability. I believe that a profile of SCVP could meet the design goals that you list, below, but you could still use existing SCVP relying party toolkits and servers rather than reinventing the wheel. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Friday, April 20, 2007 8:19 AM To: pkix Subject: Lightweight Certificate Validation Protocol (LCVP) I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis ------=_NextPart_000_001F_01C78336.49661D10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1zCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA40wggL2oAMCAQICAgCfMA0GCSqG SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNjEzMjUwNVoXDTA3 MDgxMjEzMjUwNVowZzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEWMBQG A1UEAxMNRGF2aWQgRW5nYmVyZzEmMCQGCSqGSIb3DQEJARYXZGVuZ2JlcmdAY29yZXN0cmVldC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9g2Z9TBa7wYqlyhCoriYfugKX5mwz j1wVuDKEZ7ZsgoC0zT2Pm43BMkWwOL8GDXYMqbAt/1YelpCYMv8stgRDLj6N3DDyCNk4ihZONITf o7F+RxnaH782KvJ5YwrIXDKMXWb6oqThFVDM05QKgC994W6Zp555F7NFEvPA/4rqK/1Ba0k2p8A3 yZazUimG3tt7x0tz6K7Z043ezRSUBB8VwgNSr4tQyElyuACrU3IA90yYZRm1maDe6jWylqDOXU/P A22IC/Ma1sJ42k17Nhl3i/37SLOsHSLcyJk7bKgJPSgSqI+OBzYaDX6YGdoV6O/wih9f9YrovAH8 zF2pOXcHAgMBAAGjgdgwgdUwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6 Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwIgYDVR0RBBswGYEXZGVuZ2Jl cmdAY29yZXN0cmVldC5jb20wHwYDVR0jBBgwFoAU2Ox/kxjFZgPDEGw8BPZ3hT7/C7YwQAYIKwYB BQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vZ2VvdHJ1c3Qtb2NzcC5jb3Jlc3RyZWV0LmNv bS8wDQYJKoZIhvcNAQEFBQADgYEAqMfvLi9brJBbTKdWcwUJAWPHgex9/KhvW8nherc7imLZdFXH jp0NTTtgDK+aO/EJV/97JIyStyhfIH5vrZpb+ToFXz4O0Yb78KTHFdHjzlWei/Guo+kuUXouP8ZC Tqkr0mFlqeRGFbq7w2SJhwhXEcO1K5Y8g0jf+kXr1ejYw9ExggMdMIIDGQIBATBYMFIxCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5AgIAnzAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA0MjAxNDI1NThaMCMGCSqGSIb3DQEJBDEWBBTuoWN5 Q/DUyBp432F7QNJZ6+1CFDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq hkiG9w0CBTBnBgkrBgEEAYI3EAQxWjBYMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3Ry ZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgIAnzBp BgsqhkiG9w0BCRACCzFaoFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRk LjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCfMA0GCSqGSIb3 DQEBAQUABIIBAG4fBSksN4eFtjOtFBpY6m8miiNT5YMojtJX5EWeHyVYXnUSE+ftNudCgU0R/kLG 0Ji0TpmjlrRjSn3djXMB8LjZsBoXSi767LC1nJJJvgnmBWJxi7vTZxVkAOg4BlpPoJ8NQkW72aVl H4p7rTorKWmfSFG5L0Zq+3wj2Wy5bQnTk+ghrjmdCQJzfrahl7jAmI+b6hEVzzRsVNf53my/3GvE Zo5CMSp/A3/FUIW+8OgUxwHQ5WjMS+/7/igGbvIAgVV4G6aymtuOedOXIDu8mfX9NV0Cw8DdpssX 2fJjP3ftkiZMZWV4oXZ0lZQkC2R1Ir2aHpdFNaHGRJgMkkzhheIAAAAAAAA= ------=_NextPart_000_001F_01C78336.49661D10-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KCJhXh096155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 05:19:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KCJhtq096154; Fri, 20 Apr 2007 05:19:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KCJJ8K096133 for ; Fri, 20 Apr 2007 05:19:41 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA12650 for ; Fri, 20 Apr 2007 14:24:14 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042014195376:99046 ; Fri, 20 Apr 2007 14:19:53 +0200 Date: Fri, 20 Apr 2007 14:19:14 +0200 From: "Denis Pinkas" To: "pkix" Subject: Lightweight Certificate Validation Protocol (LCVP) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/04/2007 14:19:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/04/2007 14:19:56, Serialize complete at 20/04/2007 14:19:56 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I needed a simple protocol to delegate the validation of a certificate to a server, to be used in environments where a client does not need to demonstrate to somebody else that it got a given response from a server. This implies that the server is fully trusted by the client. I considered using a profile of SCVP. Remember that the "S" does not mean "Simple", or "Standard" anymore, but "Server-based". However, the use of CMS to encapsulate everything and allowing to optionally sign requests is not needed, and the use of a subset of the various OIDs is not trivial as well. I looked at other alternatives, outside the IETF, but they do not provide an adequate answer. This proposal is for lightweight clients, hence why it is called Lightweight Certificate Validation Protocol (LCVP), like LDAP is simpler than DAP. :-) LCVP only supports a subset of the mandatory requirements described in [RFC3379] for DPV, hence it does not conform to RFC 3379. LCVP is not either a profile of SCVP. The major differences with SCVP are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add any parameter to a validation policy known by the server. LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of validation policies known by the server. The document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. At this time, the document is a strawman proposal and has not yet been implemented. There are certainly errors in it and it can certainly be improved - while keeping it "light". At this time, the document is an individual draft targeted for the experimental category. The document is available at: http://www.ietf.org/internet-drafts/draft-pinkas-pkix-lcvp-01.txt The document is proposed to the PKIX WG for consideration and comments. If the WG, later on, finds this approach interresting, then the document could be re-targeted to the standard track category. Denis Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3IGe6Z8012217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 09:40:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3IGe6tI012216; Wed, 18 Apr 2007 09:40:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from friend (static-68-161-226-3.ny325.east.verizon.net [68.161.226.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3IGe294012199 for ; Wed, 18 Apr 2007 09:40:04 -0700 (MST) (envelope-from phoffman@imc.org) Date: Wed, 18 Apr 2007 09:40:02 -0700 (MST) Received: from imc.org (imc.org [192.168.1.103]) by imc.org (8.13.1/8.13.1) with SMTP id V2CijDt626 for ; Mon, 12 Apr 1993 19:37:45 +0900 Message-Id: <20550313834431.f4pJR186752@imc.org> From: Sean To: ietf-pkix@imc.org Subject: Re: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C78218.609238D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C78218.609238D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Worldwide Lotto service! Play lotto around the World! There is only one day left to go and time is running out on your chance = to win over $36,000,000. Its happening this Tuesday - over $50 Million to be drawn in the biggest = lottery of the week in North America. Buy as many tickets as you want and increase your chance to change your = life forever. Or Search the World for 48 lotteries with total jackpots of US$ = 311,902,180=20 Get your tickets now to all the leading lotteries from around the world = ! wMbMM405308 ------=_NextPart_000_001D_01C78218.609238D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    = Worldwide Lotto=20 service!
Play lotto around the=20 World!
There is only one day = left to go and=20 time is running out on your chance to win over $36,000,000.
Its happening this = Tuesday - over=20 $50 Million to be drawn in the biggest lottery of the week in North=20 America.
Buy as many tickets as = you want and=20 increase your chance to change your life forever.
Or Search the World = for 48 lotteries=20 with total jackpots of US$ 311,902,180
 
 
Sqepj3375
<= /FONT> ------=_NextPart_000_001D_01C78218.609238D0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJoP56089312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJoPPN089311; Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJo4UB089227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 12:50:25 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7C640328F3; Mon, 16 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HdXD8-0000Kh-CB; Mon, 16 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-09.txt Message-Id: Date: Mon, 16 Apr 2007 15:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --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 : Lightweight OCSP Profile for High Volume Environments Author(s) : R. Hurst, A. Deacon Filename : draft-ietf-pkix-lightweight-ocsp-profile-09.txt Pages : 20 Date : 2007-4-16 This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client side processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-lightweight-ocsp-profile-09.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-lightweight-ocsp-profile-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-16144445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-lightweight-ocsp-profile-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-16144445.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from [203.87.246.200] ([203.87.246.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3F5qvwY042482 for ; Sat, 14 Apr 2007 22:52:58 -0700 (MST) (envelope-from strain@ovan.com) Received: from nimpha by ovan.com with ASMTP id 0CFB675F for ; Sun, 15 Apr 2007 13:53:36 +0800 Received: from nimpha ([165.142.85.85]) by ovan.com with ESMTP id 0BE182961833 for ; Sun, 15 Apr 2007 13:53:35 +0800 Message-ID: <000f01c77f22$66c6d1f0$c8f657cb@nimpha> From: "reactivate caused" To: ietf-pkix-archive@imc.org Subject: by right Date: Sun, 15 Apr 2007 13:53:33 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C77F65.74EA11F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 ------=_NextPart_000_000B_01C77F65.74EA11F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C77F65.74EA11F0" ------=_NextPart_001_000C_01C77F65.74EA11F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Networking, domain, group remote photo gallery collect? Able scan files videoaudio exeptions. Cost exceeding passed lose share = certify cards! Marketed producers consumers attempt. Selected cut rtm, surprising rcs! = Deprived toif poor die useful. Delightful intensive customize bolster! Card, numbers other private things, do. Shadow happened overwrite undo = revert major overhaul friendly? Presence, protection post technical. Cut = rtm, surprising, rcs december. Handler dom apply handlers var result, expose, return. Jai publi une = traduction en, de cet, french neobat. ------=_NextPart_001_000C_01C77F65.74EA11F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Networking, domain, group remote photo = gallery collect?
Able scan files videoaudio exeptions. = Cost=20 exceeding passed lose share certify cards!
Marketed producers consumers attempt. = Selected cut=20 rtm, surprising rcs! Deprived toif poor die useful.
Delightful intensive customize = bolster!
Card, numbers other private things, do. = Shadow=20 happened overwrite undo revert major overhaul friendly? Presence, = protection=20 post technical. Cut rtm, surprising, rcs december.
Handler dom apply handlers var result, = expose,=20 return. Jai publi une traduction en, de cet, french neobat.
 
------=_NextPart_001_000C_01C77F65.74EA11F0-- ------=_NextPart_000_000B_01C77F65.74EA11F0 Content-Type: image/gif; name="binaries codes.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c77f22$66c6d1f0$c8f657cb@nimpha> R0lGODlh2AGoAYecAAwABYMHAACEAHyFAwAAdo0Aegl5dLLDvsvky6PK9k0mAGcgBnYtAKYUBsYt DNorAABDDCgyADk0Dm5DCIYzBaNIAMVFAN00AABoDRRhAERcAGNpAoBbDqlaDcxjC9piAA1zBx6I BkGAAFGBDIOHBZ1xALWDDd6IAgufBR+aBUCuA1OrAnaRAK6RDciXCt2tAATFACDDAk3NAF3MAIW9 AJPIDca2BNK6CQDaCS3cBTTsAGLVAIPdAKPoC8LVAObgAAAAPS0OSzoHP1ULNoUNRK0NSMQAMdEA RwAYRB8pR04qM10lNY0TOKkhQrcuReQpOgNNOCVHTkxGNlE1TYtCO5NJSsVDN+VFOgZRNCFlMUFp SV1UOIRZAJpqS7JiP9hXTQCINSl3NjqNSFGKNXt9RZd+OLF4Pdt3Qw2qPRyYSTGcMlyaR36fNqaU O8WURtGmTgC4NCXFNDazMW66QHW2Sq6xQsuxNe3CTAbRTSraMkzfTGzYNoztNpzURMnVRNnmOgAL dCYBfzMAeFgNi4wDfKsAe8MNgeQFhA0djiIgjjkmfGIphIYbf6USe7IniuktdwA/cShJfzo3jW5L d4wzcZsyhrk0hNhMgABRghRlhTVZg2xncYtWc6tTesVdf9xTdgCMeRJ2fUR+iG6Nhn93fadzi8OD iet4hQCifyiVgkGTd2KVinOffJugeMCbhN2pdQe+jRPDeDrOc1O+inm8daXKicbDjuLOgwDThSzu dDjnglfjf3LbjqDVfsbag9vcfgAAuy4At0EJtGkLvIQAvKUFxM4Ay+YAugocviwbtUEntWostooe wq0jtMAout8kzgBJyh5HukZGvWtLwY04xqRJvMhNweVFuABnshdrxjZdymFls3Vjw59js7ZRu9Zl tgCKySWHy0p7zmiOzIeDzqOIuryJv96LwgCcwx2svDGTtmuguoGduZabvMeVxeqnsgm8uiOxuEO8 yVu8x3m4tJHFyf/3/ZOelndyivgJAA3wCP/+AA4H9f8E/wf0//Lx/CH5BABrnzkALAAAAADYAagB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqTGmvpcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPKXMm0aUelUKNKnUq1qtWrWLNq3cq1q1WnYMOK HUu2rNmzaNOqfeq1rdu3cOPKnUu3rt27ePMOXcu370G9gAML9um3sOGKgxMrXsy4sePHkCNLnky5 suXLNQ9r3swZs+fPoEMH5ky6tOnTqNGKXs26teuqqWPLni3w9WfauHOTtM2bsG6GQC7yYwgAwO/j yJMrV2h8IDCBzSsG/zfdYHTpy7Nrp12d+trrA8FL/xyusDvF6+K3q1+vlgBB902Lp4deHLp9gQTy O5TfHP4/YAAKBOBz/0TXHH8EyYeffuPxQx57EEYYEnoD5eefgc4F2JCF4RV4n4cLwvfgP/Ad2OFC /sFHoH8CjYghiCCOCCOMHAo4oEHmSRhRbzzSBMSPQMYEQEtAuFSkPUO2lGRNSyZZnEv8OQkTMC9R aQ8BSvJ305H2HJkkgC9xaY+VYyoJpZlhviQlmk3CtGSPcMYZ1JtNyndmnXbaFCWafJ6p5p9ItoSl Tm1eqeaafCKa5KB+sukno4waqpiOlJ5FIYwYvrifdQmeCN6lJn6Y0IufikqqpwWBiuqH8yEn56tG 0f+ZKKCz6unnm0g+2WeWjmaJK01aBpproVDmSWyeufYq7LGwNttbRZcWqOCJ4dXX0LQzIoRtagZa i+k/zobLW6W5taqbuM2Sexy67Lbr7rtCqSvvvPTWa29hr/0K7778apWSuSYFoBLA9xZs8EYCS6RA WAun1ABEBJfU78SK6XtTAG4poLECLzngMVQWz9QAxUcdXBpQGMPksQMdf6wssMjak8/MOLFsj804 u2RzyvakjDHPG+cUdEsjtzR0zwHwfDPJTL+7AEwcG90SzylzHLVNNi8t7NY0+Ty11GDvibRLV19N U9H2FJ0y2l+3bY/ZTfNkMoQLFNTwPw0/MJDe0jr/VLdAf/P9j+AJ1W34P3+/6IBBfwu0scYMMSC5 5I7TlyCCAiUcVtycQ1XR4gTd3bDold+tEOj/gK5pQgu3jrdADAwU+z+z0w47QZo3hLrsBHks0O4D AT/38MT/A0FBtc/+YsK5a3ui5s0jBP1AxwtUPe2UC0QB7gNFb1Dy1hdUPfi4dW6+SxUJoL4AA61P EAbwty+/QigMVL9A8GPg0PXX7y8+BP1TiPvCZzwAvi9+A9Ff8Vhyvqws8IEQjKBBGkhBz0nwNBXM oAY3yEHfXPCDKumgCEdIQneB8IQoTKEKV8jCFrrwhTA0WQkxE8O5zfCGOFxKDXfIkBz68IdAFCEP /4dIxCIaESRBTKISl8jEJj7miLJxYrugSMUqWnGFUnzWFSWYxbpsESNddOIX1xLGfo3xjGhMoxrX OJIyIoWNcIxj8dy4FznWkI7xsiNi8MjHPhJFj/TyY1EASchCGtJggqThITWDFAhgBQZHCZlNIOnG RZYFBZi8H/tOAgOOdNJ4EcGBJUcJkaDgICb6wErMguLIlwAQgC/JH63kRMp5bbIgOMilKKuFHm+t 75b/0CVBMimQ+zVkgP/45fw++cl/fFKB/4BmAOWYyEFSZJcFgaYCbwnM+/BPIM38ZDeniZBvOnMg 4vQm9YqZSWOS04jVDAwl3eQnGNjTni75ZUsEkP/PlrwSlvYAaEvmaSs0tTKg/hzoPvtpD37GhKDx zGMtE5Kjf4BhIBe1KI4GMp3qTCejBgFDRkG6EI+y6j7N4aZAQErSiboUIUGJlKBcMiguHcmmM80p sXLaJTHNpFA47VJOIWWkH80yokjdyUUwZ9IWOYggAyIQ5pz6oBtJpEbf+o9AKvrSrj4ELpJMKmgA CVaxJsarDTGrWkeI1geu9a1wnSEh40pXJrb1rnjNK1Pqyte++nUwtfyrYPel18Ia9rCITewJB5sZ xS6WsZCNrCINK9l0OXaClc2sZS57L8169rNI5axoR1sw0JqWNaQFy2m/kloIQba1sI2tbKm5WqD/ zPa2KaytDnHL287o9reU6a1YgMvBsBLXs8a9S3L/SkqhBIsfwKKKrggVLJksdys+xYtMdyvclbCI OKJ6yFSxRaDwoihV3poqWb77nfdYiL3Swta2uksQoOgLT43qCZkahSiu3cRiiprLdoOiLW9R5L3m HdVJ6auR9IgnVN0i2INPVKP5Kti9DNKUhSeyLaxeOL4Vwo+IieMt+ErEONECV3RrdVyaQOsgEYZw gkeV3lXN2HnUChWIInbiG3MqqzIWr+WWOiP1wvhyPGbwtY4MZJQm2cY6ztZCoqXjAz15ytMyMHMW jGIPRUy9Wj5xmKVMrawquTb2FVKt+jtdnOC3/0/X9W+wqssr5+a3zT+1R5O7LOEykzkiXU6Vn6l8 5oE411jF0lV//VtQ6x610T2Jc553ZdwAs5hJt8LzT4Zkaa7haqctjsnA6PPlDQ/6yhAbM4ezrGpB k7pTPkYyqpmzLVNL2daFPmxWJB3qXrclrLkOtrCHzUBfT4bYyTG2sieFbJL4jiLeQ82VH0Dt7iUt ac1Wy6nSIryURBss3puP4AhXuZMsuyhoY1tVGsBuddfE3f/V1dOCkrW40FnTRHOJuuFtF9GmGU0M IJvGoJK1ercsa5PTmctasjKGwwRoA2d4wxOd37ewzOABD7hMyga1cy+G0xW3BwUSnSRHHnSVk/8W 1shHjtCEityVLmklrgRqDwy0ROP20PhBD+oSnc8F5DF3uZr7hHOjZPsvQOGnQ1se0Fcu9Ok0D3lM dl7nrSVp6Q3Vpz0wOfVW2ryhDP16zWPudKbHpexNRzut3oQCjy/G5C6h5DwpKfavi92fap/JP4Pu krq3pO187zpMTtlywG9d6K2c+64sCLFszcecoDw6X4C5SXO+qJnBHAg2EwJNdBJEpefUvOg/LxBh FlMgoDfm/bQpKmBep/Od7x/mU7yQ+hkT9QTZPDFHv5nMXkQfBGmmLnepegLiL4HgLQjm/7H7aP7v es2nHyYHAnyBVP8f+sh+9YF5+9v3r/OYx3z//96p/HsaBPPdNIvbraJ1rGddfTcxvNTlAlG48Fwv zdYK4ZW4//UzuyTIxFn+N4ASJXkR9CMfwVW5oYAGaBJAQVT2AF1W8V4+8mg/RWcwIYGioS8DRoB5 AWpUkV0yESlxFlYdaBl0lh81cYJdgWwpwioGFlUi5h9AsmTW4S1W5SAy8mGvZiMaohvu8V3PUV43 iEF8ZRGBRiI/RioOdi0lFmIzYmIIYWLToWGtthnB0R1RtlENGBZJWB2Ys20V4mHJJ4Z/NoXoZS0P Qh6z1hfkJYM41oVgBBRFElSFUiiRAoE5YWn7xYJDx1ODcoe8NhUaMYSuFodyaBF2diuM+DIg/7iC a2aBKxaJcDaIIDNL14UlMvUmm+iBdiErvoIni4aB1hUzyPJpy4WKioZyYQWKcIaJsHhnkugmyFJm pZKImtGGfIFrpgJrvWiLnYIUkoZynvhHJsGLZ6SLuLhHxdiMUXFZzigYyziNO+JZ1FgWV2GJQEQn pFgs0RgX15YyIZMy84ZHZqM0MwE34YiO35gTFvFtB5EPgDQzM5M5U6YQ8HiNKuYT8IY2R1M0V0Nt D5BFD/Mw1oZtB/E4BpGP+ggU5fgScGMP85Yk+eA2WVSRFfkS3cNk2cKQ1wgU8HY14ehwPSNxV8GO oKE0A+kSKCkT9OiSMlFwL8Fv7XgTFWE6wf9Tbq8DIgaZOR7JOgTRk6nji0XWO0TZODuJMEZJZAOB lEK5EIsDOuOWkwtmj/oYEsJTZfeBk932ELtzHThJlKZjOrWTlDNiOmAZOktplbczEGhJEP2jjM4T HZOjltRjQG55lT3ESmW3JJOjcRqXMgkHGTxXdCx3cy9xmDahNEVXdPcnFBQQmYrpE48pjXrpQjhR mTXJWrdFfm1Uk9S4mT1xmaT5UqIZXNxyIp5JLrd3GOu3VMgIEenHEJB3MN2ELac5GO6nFCIFBjfh my0BnMBpD735ElrHG0ByU0YiE70pUsZYmoCGEDVIateBVVk4YlJ4EEHoZ97Rnd6pHklYEPD/lZ31 lZu7JhNBBYEQCCYtYSUiWIFcooHJCYhEIlTtyZ6YAXSHknLmqRQVQSBW9V4l4imYMyJV2Hgv0lQv +B9EyJ2zsWHpgWCm4XF5uHh3GBMkyFN7CChkYiUXWiUDAhr6OX8k2p9aAYF26CcaKIF9SHE4kaGh SHKvuHheISac+BJ+mCZewl+OZqJGh4TyVWMfMp1FaRIDmmMHMSIs4iJEWZ0EwaRQKCpQimUGVmtI Cp3M6BrIsl9jEqJ/aJ8a+iZisl+uyGhIwaVbYlQ+WozaSBVY+qbZplttuqYe+CuSZIr4RqctVl15 anWXpqfcJWZXaEfhGWso5aCpEVrn4YQo/9ZLcolChXqGQ9aD5xJPL3aD2zZhVzRfX1aVY0GAp9iI ikKMPzSiydVpz0lsROE1bcOqrFqSlPEmETkTSqM0ZvMmSoOrL9GSMvE0D6mOLBmssDqsnqFYzUE6 Ozk6bPmTA/GUZ5E7pvNtpkM4uSOPeXmtbDmUDLEyu7Mx3BM8zyYQ9AinIAE6qAM6ypqU3BoR0fqt v5it1vo7BBGvZvmWDSGUj/oR9EquY7GuB3kSu5M7KTaW7oo4TVqwDxGWYsGs/NqwqmGN+QeocuOw y6gXmml2/FJ0EhsuITOnvXF376dnCNF5FFsS92RPIrF5BdGaJqN91RdOIxt7//QRG4tpUP/hsi6h SwwVLglxPO80m6d3ECpbsp4El5EHYtZjQHhJqeZkTkB7L5EaegixfOBEtAohFDwXdS3xdXKnUIOH eE8HdmLbL/dETzYLE/VXszaJhEQZX81xP3DLS83Bek3GFJt3HSyrEZG0Nbv5pTSqtjbBlMaXTPMD BwJhuP+AuE47P01FtaR3EeIXfEbrefMjKv2DuFs1uZlLubjnEOyzSY67fJjLUYwEWhdBUt3RVEHG UnLLUQi4UuVBEN1BeQRBUiQ1a9cxu7Jbu7yLUb27uQvRnK5LpLdrYAzoW8zFtqSLYfDRUcCbnCCR uu+xu8lxvD30noCrW9hrtdzbvXHVvXr/mb0t2FriW76vYljkiWPpy0P5Cr6Cy2FfpKlt675I5xN2 Ol0fSqo3xKeoyCT4242VkVe3uGOrQiERFkORKr8/dmsN+28k1yYfWnWzeD4jaqGT+Gnle6kOmoRR 9imxeUGcusALPMD0y4NmVqQptjonQXsdkcIoEZ4KjKks/Kb2dYp45oqKtnZuFos8UaY+zMOeBsRl erb/FcRmC2kea75EoYqnKsRATMQ/LIuR5sQlKqMu6iuPNsRXUcIjYTpIybBm0a4TAcbZym52U7Km xavWxMVszFtKPJoMZlZtPMd0XMd2jEZvnMeRccd83Mc2pMeAbFp+zBZ1Ncj0FcjRaMiK/7zIjMxD iMwvjbwSjzzJlDxYd1zJmCzH0JjJGxvJnqxrnCyyn7xAocx4XVjKxga+5zbKrNxdRtYXZBwbSNnK HDE9YKGQZ3isEdE4fxPLTeHLC4lmUzGSLHltXTGrffWIWIHMtLqhM6lvi/GQQSHNUQGKrpg0ogzM DaHNENE83AxBU9WTBqnCG9GEjgM59wE9COlntnw314Y77/wPAqM5H4wQ3ioQ7SaUC7DPdXMT+Sxw V6O/lygzL5GRRXPQU2EzzDxxQJGRVbxBMqk1WsNxSoGSvxI1GN0S1Aw2EPk2OhMTCk02RNOPQ5HR YEPRLoasL0JuJtEwucM8VvnNCOGvCf/hrO02EPFqrTS9MhtZROeqk3dzOCDhPT3Jz4lTbmYst9hS kM0Krs82lQYbOvc8EbgszgIB1QqBrH85O85KEo3z0vI6lF2JES/SkwIZ1j0tz8u61mYpqQcDFBSN 0lYTFbNqMzincTmjcB0HExkn0h4NNhGtNBHdExRdKChNE1T31zD3FUtbr9XiZByhOGjdltiarsl6 rcCjsMMDFH/pEoepmBdbFBrbclRjUDBxf6NtdiyX2HfdEoqpzDfx2a7t2W6jxrN927KNsVIxmTn3 Eqnd171dFInNcpG52D133PbAAS6h3C9327jC20B0nLqdFFq3JFrXSg6Vd2P3pSeHLO3/9Hcw8d0/ 0X47mz8gOxPmTXY8x3VTcVCae7TrFHmrCRF0S3m3tHvmVHyE27lPm0bzjRz/fRYBLhJREh3KZBAK lOAcMbPZQn6vBJcP7nzHB04wu0Z5qxzm5xQ9obOLgXXwJxVyh0+VRMukhcr+QuISYuItgeKErOJ4 weLu6+IyDrEwXuN3BVw2nuM6vuOfPOM+rlk8HuSkXIz0++OhJuSFZeRJ4VJKzpl65ONI7saWzORN 7n9RfuVYrlpV/kZZ3uVe/rAy/uUl/lp8vOWCJOZVixYk+xADjohonhBghWhfmxXy53JLd+eLF9qZ GbZz4p9NseYY0d+HBBSJPd3x91BF/8EsOHHedNd3js6f9isUWJfEcqHnlFlbiue1PFF/1ZW2N1Ho lh62J8tiSTJPcHDqcKDeOQEFrA4F9ekTw2mmn65c1F1bw3nrV2wTQRKcLgGcDjWfN4HnYbvrxFns xi7sxe6bys5QQLWcNoHr9lmHve6cLrrrwBlUNRHrRFGcrx7tYOojxE6c1K7ratrtp6WJhsIo2I4T yvnqi0JTOEEl8l4m3X5TXJIk2C7t0v7qQZWc2AvvQ0UkXIKiMFGhknLw4G5T5Q6JOdXvzq6CW/Lw AB8k5a6H/x5RbMtnw/u6m/IPayggz7shSridIF/yLNK8y+vxKj8cDzIdC/pkTUUeSv8qoTKSux3S qQPx8QtRXgDqHAu2vt7pvJsr9NOhg09V8oamyYuq8SMmEQSi80fq1vbB9FpV8peyoCEPhQma8h8W KiySIyQMhlKvhFd6jxrGZZgVEymKJlbS9n9LVxeB9SdcYN6i81ppg0VKwDm2LTzvi3CItCRmLU/v i/1REEQ4HA89o7I+JfQOpjv6MjWx9sIyKJRP6nCvvI43qKum+WVPVcCYFuBhVZRqLTOsndPb9OeF ZLJmqE1/IUKqY0TasO1bKdb7pC3P8QyxgynR81XfvUBvMg26EEGBpmaOXIB7yC7OGbOfHKXfYx+x /M9vSTWc+EIi0D2qFAD29l7RsYP/QenVnFn4G+naPyxYXP5T4f1WIefkH6NFbP4w02ZBCv0mjPeI FWgHnHw3RsKn0meH2oNWBhAA/g0kWNDgQAAJBSL8t7BhwoIKCUpsWNGiQgD2NGbUaI8jR48bO4Ls WFJkSJMpR65EiZKkSpgxZc5UWBLjTJw5de7k2dPnT6BBcWb8eLJlTJIgaxplqnTjS5hOXZos6lNq QpZTbVK9yjKp0apHoz7V2fUk1LFKsY5capYoWLhC5c6lW9fuz4N59S4UyHei3oiBLV406HCwX8CF DyM0jDhxXoeOH1KE+Fcww8WDCWOO/Fhz5cSdMxsOLXoz4bNkn7bNetf1a9ixZacO/4uW6taWYZt6 3fm2aVXbNHm3tqn7aO3duePKfBk8K3KxSIuzTl39622ms7Vv5x7UM+AABAOE/0e+vGfTpsebV6Bg Imj33wcuKGgec3z75z3H/4f/Mmn6/gnQsoHIM+9A8iID7UD0Bmrgwe9MW2DCgih8zL789NOPv/gU 0MjDjkC0B0QRRezuRBRTtCufjvJh8cP2cmovxhBr/Mm5lBooCcQHddQogBBFBBInB4p0oKMhgxRy vB1pJGnIGU2kSz4qqwSMPw3Jc4CgLf/Jh6AvvSzQoPUK6rEBK9NUc00223TzTYJUzGkpOXl6QMbu fKwTxSQ1euDPktZLcsIJNTrSnv87fYJzUUYbdfRRSCOVlE3SAENzUgIx1bTRSzf19FNQQd1zVFJL NRVFKU9VdVVWW3X1VVhHDXVWWmu19VZcc9XVylh79fVXYIMVVqhdizX2WGQHGnZZZpt19lloo5V2 Wmqrtda7ZLPVdltuu/X22zivFXdccss191x07QJ3XXbbPShdeOOVd97Y3LX3Xjjp1ddXfPv191+9 9hV4YHMBNvjgbglWWDuEG3Y4sYUjLvdhiiu22FuJM9Z4Y4479vhjkEMWmdmLSzb5ZJRTVnnlZEe+ lmWYY5Z5ZpprtvlmnHPWeWeee/Y5Z5eDFvqun4s2+mikk1Z6aaabdvppqKOWeur/g4e2ul6qs/7n aq67BrlP2Ir8achDZQPb65i0Xpq8AMNcdMA0L83Q0UrV3hrtnnoMlMmOCtVogbvO1JMuvXuScnCg KmRTbkyxvNDpoAD/u+9eU+Vu8EQRNbSjQyX3/DUcfco887I+9BNQ5XCaUcmcCrfnc588FJEB2puk MclB/ZYc750Y6Mh3jYCfq+yy16tRRDppr930FCGAoCTi4yJxxLnyctxIgpRnIELF/unSe4JmtKzL 7bM3/zHR6n6MfMxKA63I8/8pX7Ty5R+o/oGwL3A8uwnCwH8ADoQCA5SP85w3EAgQJIEGWSAG/ncQ CiBQgQIkIGMMo7xGLbB9C9Gg/wYrGMG72UV49nieRkooFZmM0B7AQ2FHSvjC4JnkeSUUzkloiBPt VUcmFOgID+3hQxO6MIZDFB7wbrhC3IysTQL4BxOdSBAmDiSKiZliFKtIEBRkEQXtG4gWt/iPL4JR glAk4z8eaEZGhVGMXRzjPzSIxS6q8U1nbGIZr/gYOqLRjROUogD8OMYvTnEg/8ujXu4oyMSc8YGL 9Mwd6RjGL4pGkVzcIxQR2T8c/COTm8SiFxtZxg5KsYwwKEgoK1lJw/hRlQg04Bvd9MZJapIgmWRg JV3ZJlLy0Za6BIwrF+jIAEZxIbksiBx7ycdLGnKUosRjAN9IzFzeEZJtHIg+Dv8CA2L2L4HbPGUy jzlGWsrylA38DxvNGc5TEiSbjDIMNJlZx4LkUp6MeqM04eiZWGYmll88IzYLgs7HaHGWVGrlQHJp zIOIBpEU6eMfq6kPiPrPgQMBKEX7V0pemuab3VwlRXHwUYMWhiKmzGY4aXlHOMnRgXRkqC4PyKh1 QtSaHgVpAV+qTmwSU5XeTGi3CoqpLA5yohe95xoJIlP5eBJTEbVgPP25qI6ui6ePWSecbgkpuYSO d9Q6ItfeNFX0qY9iYiUqr0ylyq2mNSVlZWtbW6ZWV7lVrnNdF1ztele85lWve+VrX/2aMbp+6q+D TVxgDXvYYhE2YohlbGNtplj/yF7NsT6LrMsm66/KEuuym31MZj37WdBajbOjJW1pmRZa1KZ2Sqa1 lWrxxtoquVa2s10YbG1bWtpC67aSyq1ad/tb4AY3Zb3ll3CNO1niquq4y71tcp37XOiKi7nTDWx0 retZ6mbXrdfljnZvpq+dhlcj4RVASjByXu6m90RAYC97O+JelYBBvmAwSXvhaw/5miS/NIHKWvwY k/u2tyT33ap3tSWXAANBIwQgAIAVPOAH2wO+CY6wTBickgtLuMImAQYwStLhD3s4swb2lFBA/GHV qOTEGiGwhFVDp5msuCMnXotKMrzgBs9YxOrlMXdqbN7g3PfHXPHIkJnTX460/zjES2bLxkh8M9Ak VKzsJUiHAdNhLFeJH/w4yJYHgmUwW/kfDCYImSNy3pZWrccKYxOV9yJW0ERZpHJGD5opYua8MFjP BJDyk/3MTjgH+j2AOW+V6FwZN0OGL5Wi858dbaVGMwYwiY70mPmsZyolmiBuFnNeEq3phzza0UG5 MZCRopaYZFjPZUFyik29muIkV9SfkvOiCd0Y0ti6qXXuc6jffGYFzTq2xG0TQytT6SgbW9e7Lk2v 7XzsXEPbzkhb87DeVGgLYuQ9tda2pIEd1l4LW9zjrli1V0VudOvM3Otmd7vd7ax0y+fdAnvyvLvG XHv7Nt77nlm+/f1vgAdc4A6DHfXAYcVvhM/K4PMKCAA7 ------=_NextPart_000_000B_01C77F65.74EA11F0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B72q7g042207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3B72qIX042206; Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gateway.baea.com.au (gateway.baea.com.au [202.20.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B72p7I042196 for ; Wed, 11 Apr 2007 00:02:52 -0700 (MST) (envelope-from ian.brumby@baesystems.com) Received: from unknown (HELO sbuxscan.baea.com.au) ([150.207.31.25]) by gateway.baea.com.au with ESMTP; 11 Apr 2007 16:32:51 +0930 Received: from bunya.baea.com.au (bunya [150.207.1.63]) by sbuxscan.baea.com.au (8.13.6/8.12.10) with ESMTP id l3B72oEt022198 for ; Wed, 11 Apr 2007 16:32:50 +0930 (CST) Received: from SBW3OWEX1.au.baesystems.com (exchange [150.207.4.37]) by bunya.baea.com.au (8.13.6+Sun/8.13.6) with ESMTP id l3B72ojp028985 for ; Wed, 11 Apr 2007 16:32:50 +0930 (CST) Received: from brdw3ex1.au.baesystems.com ([150.207.68.10]) by SBW3OWEX1.au.baesystems.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:32:49 +0930 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-pkix-lightweight-ocsp-profile-08.txt Date: Wed, 11 Apr 2007 17:02:49 +1000 Message-ID: <0D88367CF035304ABCB1022D82AF0753673F7D@brdw3ex1.au.baesystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile-08.txt Thread-Index: Acd8B2+oUOqz45a1RP60+P4LmQ++NA== From: "BRUMBY, Ian" To: X-OriginalArrivalTime: 11 Apr 2007 07:02:50.0070 (UTC) FILETIME=[6ABC7760:01C77C07] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3B72q7I042200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Under Signed OCSPResponses (1.2.2), the extension is referred to as id-ocsp-nocheck instead of id-pkix-ocsp-nocheck. Under Transport Profile (4), there is some ambiguity as to whether a request that is exactly 255 bytes should be a GET or POST. Should this be worded something like "less than or equal to 255 bytes in total" rather than "smaller than 255 bytes in total"? Immediately following that is a typo - OCSPReqeust. Regards, Ian Brumby BAE Systems Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBvXh086161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 04:11:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l39BBvuu086160; Mon, 9 Apr 2007 04:11:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBWWt086104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 04:11:54 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l39BB7gw012799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 13:11:07 +0200 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ekr@networkresonance.com, ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070409:ekr@networkresonance.com::3QoFEDKqVNPqTq5Q:MsX X-Hashcash: 1:22:070409:ietf-smime@imc.org::tQBP8tX8HMZykdCj:6/O+ X-Hashcash: 1:22:070409:ietf-pkix@imc.org::ZPi90spiQd3Aos3c:DKnD X-Hashcash: 1:22:070409:pgut001@cs.auckland.ac.nz::Nnw/iCZnyUzfe4w7:LBLl Date: Mon, 09 Apr 2007 14:11:04 +0200 In-Reply-To: (Peter Gutmann's message of "Sat\, 07 Apr 2007 19\:01\:26 +1200") Message-ID: <87lkh1eoiv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Eric Rescorla writes: > >>So, what's the right answer here? > > Read the OID and hash value, toss the rest. Doing anything else is just > asking for trouble. > > (There's really no question here: There are two ways to do this, knowing in > advance what you'll encounter in the field isn't possible, so the only > workable solution is to not compare the encoded value, or if you must, > compare two pre-encoded alternatives for each possible hash algorithm. This > still breaks though if someone gets the encoding slightly wrong... comparing > a pre-built value is just asking for trouble). That approach, to not validate the parameters field, is what led to the variant of Bleichenbacher's attack in several TLS implementations. I'm strongly opposed to permit this in conforming implementations. Even if we restrict it to either absent parameters or NULL parameters, that would enable a side-channel: you can "leak" one bit of information by deciding which of NULL or absent you use. It is not clear to me how important that threat is. There are other ways to leak information in the TLS protocol (packet ordering, random values, etc). However, there may be some value in not expanding the ways to leak information further. I could live with MUST generate NULL parameters fields on encoding, and MUST accept both NULL and absent fields on decoding. /Simon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37N0kfg083780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37N0kvo083779; Sat, 7 Apr 2007 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l37N0ijJ083766 for ; Sat, 7 Apr 2007 16:00:44 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704072300.l37N0ijJ083766@balder-227.proper.com> Received: (qmail 12222 invoked by uid 0); 7 Apr 2007 23:00:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 7 Apr 2007 23:00:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Apr 2007 18:49:14 -0400 To: Dr Stephen Henson , ietf-smime@imc.org From: Russ Housley Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <461782DB.6010502@drh-consultancy.demon.co.uk> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> 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: Thanks for pointing this out. I did say that you needed to make sure it was a valid parameter encoding, but I should have included this important additional information. Thanks. Russ At 07:39 AM 4/7/2007, Dr Stephen Henson wrote: >Russ Housley wrote: > > > > Note that the DigestInfoValue is part of the structure that is > > "encrypted" with the RSA private key when generating a signature. It is > > recovered by "decrypting" the signature value with the RSA public key. > > > >Note that care should be taken when handling the DigestInfo structure >recovered from an RSA signature. > >As well as the original Bleichenbacher signature forgery attack (caused >by ignoring trailing garbage after DigestInfo) there is a variant which >inserts garbage in the middle of the recovered structure. Allowing >arbitrary parameter values in the DigestAlgorithmIdentifier (for example >large OCTET STRINGs) is one way to do this. Unlike the original attack >this variant produces a "valid" DigestInfo structure. > >As a result in the specific case of the recovered DigestInfo from an RSA >signature OpenSSL now only tolerates a NULL or absent parameter field. >This is OK for all existing digests. > >It is more liberal about DigestInfo structures in other contexts. > >Steve. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7h91048306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 10:07:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37H7hQL048305; Sat, 7 Apr 2007 10:07:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7MVF048229; Sat, 7 Apr 2007 10:07:42 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.218] (helo=[10.33.180.177]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1HaENj-0004qT-AT; Sat, 07 Apr 2007 18:07:21 +0100 Message-ID: <4617CFBA.3050604@drh-consultancy.demon.co.uk> Date: Sat, 07 Apr 2007 18:07:06 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> <20070407143003.73D811CC3D@delta.rtfm.com> In-Reply-To: <20070407143003.73D811CC3D@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > At Sat, 07 Apr 2007 12:39:07 +0100, > Dr Stephen Henson wrote: >> >> Russ Housley wrote: >>> Note that the DigestInfoValue is part of the structure that is >>> "encrypted" with the RSA private key when generating a signature. It is >>> recovered by "decrypting" the signature value with the RSA public key. >>> >> Note that care should be taken when handling the DigestInfo structure >> recovered from an RSA signature. >> >> As well as the original Bleichenbacher signature forgery attack (caused >> by ignoring trailing garbage after DigestInfo) there is a variant which >> inserts garbage in the middle of the recovered structure. Allowing >> arbitrary parameter values in the DigestAlgorithmIdentifier (for example >> large OCTET STRINGs) is one way to do this. Unlike the original attack >> this variant produces a "valid" DigestInfo structure. >> >> As a result in the specific case of the recovered DigestInfo from an RSA >> signature OpenSSL now only tolerates a NULL or absent parameter field. >> This is OK for all existing digests. >> >> It is more liberal about DigestInfo structures in other contexts. > > Steven, > > As I recall OpenSSL puts the NULL in the digestAlgorithm encoding > as well. Am I right about that? > > Yes. It places the NULL in the DigestAlgortihmIdentifier for RSA signatures DigestInfo according to PKCS#1. It also includes it in other DigestAlgorithmIdentifier structures too. As I recall (I'd have to check some ancient email archives) the NULL was needed to pass an old S/MIME v2 compliance test some years back. Steve. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWahu030748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EWaM7030746; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from randymail-a2.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWGNA030720; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 7353EEEBB8; Sat, 7 Apr 2007 07:32:15 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B2CC1CC3D; Sat, 7 Apr 2007 07:30:42 -0700 (PDT) Date: Sat, 07 Apr 2007 07:30:42 -0700 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ekr@networkresonance.com, ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: References: <20070406182928.6C6E65C02B@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070407143042.7B2CC1CC3D@delta.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Sat, 07 Apr 2007 19:01:26 +1200, Peter Gutmann wrote: > > > Eric Rescorla writes: > > >So, what's the right answer here? > > Read the OID and hash value, toss the rest. Doing anything else is just > asking for trouble. > > (There's really no question here: There are two ways to do this, knowing in > advance what you'll encounter in the field isn't possible, so the only > workable solution is to not compare the encoded value, or if you must, > compare two pre-encoded alternatives for each possible hash algorithm. This > still breaks though if someone gets the encoding slightly wrong... comparing > a pre-built value is just asking for trouble). Totally agree. My question was more what we ought to recommend. -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVxiE030702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EVx1I030701; Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from randymail-a3.g.dreamhost.com (sd-green-bigip-145.dreamhost.com [208.97.132.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVcNY030681; Sat, 7 Apr 2007 07:31:58 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a3.g.dreamhost.com (Postfix) with ESMTP id B0A06185976; Sat, 7 Apr 2007 07:31:36 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 73D811CC3D; Sat, 7 Apr 2007 07:30:03 -0700 (PDT) Date: Sat, 07 Apr 2007 07:30:03 -0700 From: Eric Rescorla To: Dr Stephen Henson Cc: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: <461782DB.6010502@drh-consultancy.demon.co.uk> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> <461782DB.6010502@drh-consultancy.demon.co.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070407143003.73D811CC3D@delta.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Sat, 07 Apr 2007 12:39:07 +0100, Dr Stephen Henson wrote: > > > Russ Housley wrote: > > > > Note that the DigestInfoValue is part of the structure that is > > "encrypted" with the RSA private key when generating a signature. It is > > recovered by "decrypting" the signature value with the RSA public key. > > > > Note that care should be taken when handling the DigestInfo structure > recovered from an RSA signature. > > As well as the original Bleichenbacher signature forgery attack (caused > by ignoring trailing garbage after DigestInfo) there is a variant which > inserts garbage in the middle of the recovered structure. Allowing > arbitrary parameter values in the DigestAlgorithmIdentifier (for example > large OCTET STRINGs) is one way to do this. Unlike the original attack > this variant produces a "valid" DigestInfo structure. > > As a result in the specific case of the recovered DigestInfo from an RSA > signature OpenSSL now only tolerates a NULL or absent parameter field. > This is OK for all existing digests. > > It is more liberal about DigestInfo structures in other contexts. Steven, As I recall OpenSSL puts the NULL in the digestAlgorithm encoding as well. Am I right about that? Thanks, -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdcR0009496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37BdcSD009495; Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdGwY009477; Sat, 7 Apr 2007 04:39:37 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.222] (helo=[10.36.182.67]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1Ha9GF-0002s9-8U; Sat, 07 Apr 2007 12:39:15 +0100 Message-ID: <461782DB.6010502@drh-consultancy.demon.co.uk> Date: Sat, 07 Apr 2007 12:39:07 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ietf-smime@imc.org CC: ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <200704062009.l36K9MMG018505@balder-227.proper.com> In-Reply-To: <200704062009.l36K9MMG018505@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > Note that the DigestInfoValue is part of the structure that is > "encrypted" with the RSA private key when generating a signature. It is > recovered by "decrypting" the signature value with the RSA public key. > Note that care should be taken when handling the DigestInfo structure recovered from an RSA signature. As well as the original Bleichenbacher signature forgery attack (caused by ignoring trailing garbage after DigestInfo) there is a variant which inserts garbage in the middle of the recovered structure. Allowing arbitrary parameter values in the DigestAlgorithmIdentifier (for example large OCTET STRINGs) is one way to do this. Unlike the original attack this variant produces a "valid" DigestInfo structure. As a result in the specific case of the recovered DigestInfo from an RSA signature OpenSSL now only tolerates a NULL or absent parameter field. This is OK for all existing digests. It is more liberal about DigestInfo structures in other contexts. Steve. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771kMA080871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3771kaf080870; Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.10.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771OZ1080808; Sat, 7 Apr 2007 00:01:45 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 045B09C671; Sat, 7 Apr 2007 19:01:24 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTmWuDzOKBYY; Sat, 7 Apr 2007 19:01:23 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D5BBE9C670; Sat, 7 Apr 2007 19:01:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E6298514010; Sat, 7 Apr 2007 19:01:20 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ha4vO-0002Z4-00; Sat, 07 Apr 2007 19:01:26 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, ietf-smime@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> Message-Id: Date: Sat, 07 Apr 2007 19:01:26 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla writes: >So, what's the right answer here? Read the OID and hash value, toss the rest. Doing anything else is just asking for trouble. (There's really no question here: There are two ways to do this, knowing in advance what you'll encounter in the field isn't possible, so the only workable solution is to not compare the encoded value, or if you must, compare two pre-encoded alternatives for each possible hash algorithm. This still breaks though if someone gets the encoding slightly wrong... comparing a pre-built value is just asking for trouble). >My understanding from discussions in Prague is that this reflects NIST's >current guidance as well. This would put them in conflict with ISO, who (the last time I checked) say the parameter should be omitted. In any case though it doesn't really matter which side wants to hold their breath the longest, if you read the OID and hash and work with that you can't go wrong. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K9iSP018528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K9i2N018526; Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l36K9MLX018503 for ; Fri, 6 Apr 2007 13:09:43 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704062009.l36K9MLX018503@balder-227.proper.com> Received: (qmail 5038 invoked by uid 0); 6 Apr 2007 20:09:16 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 6 Apr 2007 20:09:16 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Apr 2007 16:09:19 -0400 To: Eric Rescorla , ietf-smime@imc.org From: Russ Housley Subject: Re: AlgorithmIdentifier, SHA-1, etc. Cc: ietf-pkix@imc.org In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> References: <20070406182928.6C6E65C02B@laser.networkresonance.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: Note that the DigestInfoValue is part of the structure that is "encrypted" with the RSA private key when generating a signature. It is recovered by "decrypting" the signature value with the RSA public key. An implementation should check that the expected digest algorithm was used. As Eric point out, this check is easier to perform if the two values are encoded in exactly the same manner. One needs to look deeper into signatures in certificates and CMS SignerInfo to see where these comparisons are really performed. The certificate signature has this structure: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } In practice, the signature algorithm tells the digest algorithm as well as the digital signature algorithm. The ones that are relevant to this question are: sha1WithRSAEncryption sha224WithRSAEncryption sha256WithRSAEncryption sha384WithRSAEncryption sha512WithRSAEncryption There is no filed that explicitly carries a digest algorithm identifier. So, the digest algorithm for comparison to the DigestInfoValue inside the signature value must be generated in some manner by the implementation. I believe than many implementations use a simple internal table. Adding entries to this table is part of the work needed to add support for additional RSA signature algorithms. So, the table should contain exactly the octet string that will appear in DigestInfoValue, including the NULL parameter required by PKCS#1. The CMS SignerInfo has this structure: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Again, the signature algorithm tells the digest algorithm. The same set of algorithm identifiers are used here. In each case, the digestAlgorithm must contain the digest algorithm identifier that is implicitly named by the signature algorithm, and the DigestInfoValue must contain the same digest algorithm identifier. As Eric has already explained, the parameter in DigestInfoValue must be NULL, but we are "forgiving" in the processing of the parameter for digestAlgorithm. The parameter can be NULL or absent. In order to use the same signature validation routines for CMS and certificates, I believe that most implementations use the same internal table as discussed above for the DigestInfoValue comparison. Then, in addition, the digest algorithm identifier is compared to the digestAlgorithm field in SignerInfo. The signature value must contain exactly the expected digest algorithm identifier with a NULL parameter. So, the only comparison that is not an exact match is the comparison from the internal table entry to the digestAlgorithm field. I suggest that the object identifiers must match, but one can ignore the parameters, after making sure they are either absent or NULL. That is, do not let the parameters carry some inappropriate value. Russ At 02:30 PM 4/6/2007, Eric Rescorla wrote: >I'm trying to get a handle on how one ought to encode AlgorithmIdentifier. > >As people will perhaps remember, the ASN.1 is: > > >AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > >Present hash functions do not take any useful parameters, leaving >us with two encoding options: > > - omit the parameter. > - include a NULL > >To make things more complicated, there are (at least) two different >contexts in which this production appears: > > - The S/MIME DigestAlgorithmIdentifier production. > - Inside the DigestInfo of the S/MIME signature. > >RFC 3370's guidance is to omit the parameter for SHA-1 and include >a NULL for MD5 (see S 2.1 and 2.2.). > >However, the current PKCS#1 errata >(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) >recommend that when one is encoding DigestInfo, one should >encode it as NULL: > > Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 > (see 9.2), the parameters field associated with id-sha1, id-sha256, > id-sha384 and id-sha512 SHALL have a value of type NULL. This is to > maintain compatibility with existing implementations and with the > numeric information values already published for EMSA-PKCS1-V1.5 > which are also reflected in IEEE 1363a-2004[27]. > >My understanding from discussions in Prague is that this reflects >NIST's current guidance as well. > >Technically these don't conflict, but obviously, it's undesirable to >have the encoding in the message not match that in the DigestInfo, >since doing binary comparisons is common practice here. So, what's the >right answer here? > >-Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8mkm018485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K8mXB018484; Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8l7s018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:47 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 2B7F15C027; Fri, 6 Apr 2007 13:08:07 -0700 (PDT) Date: Fri, 06 Apr 2007 13:09:27 -0700 From: Eric Rescorla To: Blake Ramsdell Cc: Eric Rescorla , ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. In-Reply-To: <4616A772.5080704@sendmail.com> References: <20070406182928.6C6E65C02B@laser.networkresonance.com> <4616A772.5080704@sendmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070406200807.2B7F15C027@laser.networkresonance.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Fri, 06 Apr 2007 13:02:58 -0700, Blake Ramsdell wrote: > > Eric Rescorla wrote: > > Technically these don't conflict, but obviously, it's undesirable to > > have the encoding in the message not match that in the DigestInfo, > > since doing binary comparisons is common practice here. So, what's the > > right answer here? > > In my case when I receive a digest AlgorithmIdentifier, I bust it open > and get the OID out and discard the wrapper (the outer > AlgorithmIdentifier). So I'm not affected by a mismatch if I do that. > > But yeah, short of normalizing the values in some way, you're pretty > much done. That is, there's no binary comparison, and you perform an > equivalence check by converting both values in such a way that the same > answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get > the same answer. Yeah, my thinking is that it would be better for these to match so that naive implementations work. -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K3NZa018236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K3N8g018234; Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K32Bw018210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2007 13:03:22 -0700 (MST) (envelope-from blake@sendmail.com) Received: from [192.168.0.4] (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l36K5jaW030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Apr 2007 13:05:46 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l36K5jaW030920 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175889948; bh=aVUBogemJPBCmvA6TmGQBDPKvVw=; h=X-DomainKeys: DomainKey-Signature:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=P8zcssmaxmJQn2uS2mduKb+pZqYph502du+Rhj oz4yZfQaArDkNt7AfRsfFo5FSvLAAC1CFH7rfPqj6sUMw4CObhoW2wsWI5GfPXIbLvC Gvuwm3xeBdUzwpvrgGrOBRWDRitcAzYrL0vH08tYsyv4+tiA0XtFvZFj2flnI2dT9o= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l36K5jaW030920 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=M7QxpsVFvlDXTcT5fBvQfqV4pzi8V2LciIPs1Mr4TkNwYbmHCLgP25WxWutq8Tfca UIJAoXLOcUuro2ug33LJ5hdBmAtdYg/0yQCgktOuYBdouWnS4c/noP3Slxw+cDB1u4b AlbcVO/fyzIZ9O5Zl69vGmDx2GwEh45JB7/V3WY= Message-ID: <4616A772.5080704@sendmail.com> Date: Fri, 06 Apr 2007 13:02:58 -0700 From: Blake Ramsdell User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Eric Rescorla CC: ietf-smime@imc.org, ietf-pkix@imc.org Subject: Re: AlgorithmIdentifier, SHA-1, etc. References: <20070406182928.6C6E65C02B@laser.networkresonance.com> In-Reply-To: <20070406182928.6C6E65C02B@laser.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Rescorla wrote: > Technically these don't conflict, but obviously, it's undesirable to > have the encoding in the message not match that in the DigestInfo, > since doing binary comparisons is common practice here. So, what's the > right answer here? In my case when I receive a digest AlgorithmIdentifier, I bust it open and get the OID out and discard the wrapper (the outer AlgorithmIdentifier). So I'm not affected by a mismatch if I do that. But yeah, short of normalizing the values in some way, you're pretty much done. That is, there's no binary comparison, and you perform an equivalence check by converting both values in such a way that the same answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get the same answer. Blake -- Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU94x009906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36IU97j009905; Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU8Dj009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:08 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 6C6E65C02B; Fri, 6 Apr 2007 11:29:28 -0700 (PDT) Date: Fri, 06 Apr 2007 11:30:49 -0700 From: Eric Rescorla To: ietf-smime@imc.org Cc: ietf-pkix@imc.org Subject: AlgorithmIdentifier, SHA-1, etc. User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070406182928.6C6E65C02B@laser.networkresonance.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm trying to get a handle on how one ought to encode AlgorithmIdentifier. As people will perhaps remember, the ASN.1 is: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } -- contains a value of the type -- registered for use with the -- algorithm object identifier value Present hash functions do not take any useful parameters, leaving us with two encoding options: - omit the parameter. - include a NULL To make things more complicated, there are (at least) two different contexts in which this production appears: - The S/MIME DigestAlgorithmIdentifier production. - Inside the DigestInfo of the S/MIME signature. RFC 3370's guidance is to omit the parameter for SHA-1 and include a NULL for MD5 (see S 2.1 and 2.2.). However, the current PKCS#1 errata (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) recommend that when one is encoding DigestInfo, one should encode it as NULL: Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 (see 9.2), the parameters field associated with id-sha1, id-sha256, id-sha384 and id-sha512 SHALL have a value of type NULL. This is to maintain compatibility with existing implementations and with the numeric information values already published for EMSA-PKCS1-V1.5 which are also reflected in IEEE 1363a-2004[27]. My understanding from discussions in Prague is that this reflects NIST's current guidance as well. Technically these don't conflict, but obviously, it's undesirable to have the encoding in the message not match that in the DigestInfo, since doing binary comparisons is common practice here. So, what's the right answer here? -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l362H84m019697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l362H8pP019696; Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l362GlZh019600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 5 Apr 2007 19:17:08 -0700 (MST) (envelope-from Ryan.Hurst@microsoft.com) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 5 Apr 2007 19:16:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Thu, 5 Apr 2007 19:16:46 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Apr 2007 19:16:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCSP Problem Date: Thu, 5 Apr 2007 19:16:28 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D8004B82DD5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <200704060218.06836.pg@futureware.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Problem Thread-Index: Acd37K9aRKdvVWGXRiamd8+ck0eVIQABC2pQ References: <200704060218.06836.pg@futureware.at> From: Ryan Hurst To: =?iso-8859-1?Q?Philipp_G=FChring?= , X-OriginalArrivalTime: 06 Apr 2007 02:16:46.0731 (UTC) FILETIME=[A08605B0:01C777F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l362H8Zg019691 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OCSP allows for several trust models (although not explicitly called out). I generally refer to them as: VA Direct - I trust the OCSP responder to sign for any CA. VA Delegated - I trust the OCSP responder to delegate its signing ability to any of its sub-Vas. CA signed - Signed by the same ca/key that signed the certificate. CA delegated - Signed by a OCSP responder delegated by the CA to sign responses on its behalf. The most common deployed trust model is the CA delegated trust model. In your case (a OCSP request for multiple certificates issued by multiple CAs) the responder could have a certificate from each of the CAs its delegated for where each of these certificates are bound to the same key pair therefore the signature would still be valid and the bag in the response could contain each of these certificates. With that being said it is uncommon for a client to generate requests for more than one certificate at a time. Ryan -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Philipp Gühring Sent: Thursday, April 05, 2007 5:18 PM To: ietf-pkix@imc.org Subject: OCSP Problem Hi, The OCSP RFC says that a OCSP request can contain several queries for different certificates. Those queries can be for certificates from different CA´s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by the OCSP Server certificate that corresponds to the CA of the certificate that was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from different CA´s? Which corresponding OCSP server certificate should be used to sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can´t cover the other certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA´s in a OCSP request? I couldn´t find anything in the RFC mentioning that issue. Best regards, Philipp Gühring Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l361TaA4014460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l361Tag4014459; Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l361TGY0014435 for ; Thu, 5 Apr 2007 18:29:36 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCSP Problem Date: Thu, 5 Apr 2007 18:29:10 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790748A865@EXVS01.ex.dslextreme.net> In-Reply-To: <200704060218.06836.pg@futureware.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Problem Thread-Index: Acd36lMlcTSD1u5xRgmBbF7/u1DubgAAIhlA References: <200704060218.06836.pg@futureware.at> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l361TaY0014453 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The responder should have certificates signed by each of the CAs that it services. The Responder should send all the certificates that are relevant to the request. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Philipp Gühring Sent: Thursday, April 05, 2007 8:18 PM To: ietf-pkix@imc.org Subject: OCSP Problem Hi, The OCSP RFC says that a OCSP request can contain several queries for different certificates. Those queries can be for certificates from different CA´s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by the OCSP Server certificate that corresponds to the CA of the certificate that was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from different CA´s? Which corresponding OCSP server certificate should be used to sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can´t cover the other certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA´s in a OCSP request? I couldn´t find anything in the RFC mentioning that issue. Best regards, Philipp Gühring Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l360IZ1l007097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l360IZHK007096; Thu, 5 Apr 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l360IDUo007061 for ; Thu, 5 Apr 2007 17:18:34 -0700 (MST) (envelope-from pg@futureware.at) Received: from linux.lan (authenticated user pg@futureware.at) by mailbox.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 12-md50000000057.tmp for ; Fri, 06 Apr 2007 02:18:08 +0200 From: Philipp =?iso-8859-1?q?G=FChring?= Organization: Futureware 2001 To: ietf-pkix@imc.org Subject: OCSP Problem Date: Fri, 6 Apr 2007 02:18:06 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200704060218.06836.pg@futureware.at> X-Authenticated-Sender: pg@futureware.at X-Spam-Processed: dns4.go-now.at, Fri, 06 Apr 2007 02:18:08 +0200 (not processed: spam filter disabled) X-Return-Path: pg@futureware.at X-MDaemon-Deliver-To: ietf-pkix@imc.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l360IYUo007091 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The OCSP RFC says that a OCSP request can contain several queries for different certificates. Those queries can be for certificates from different CA´s (/Sub-CAs). Additionally, the RFC demands that the OCSP response has to be signed by the OCSP Server certificate that corresponds to the CA of the certificate that was asked for in the request. According to the RFC, the whole OCSP response has to be digitally signed. Now what happens if a client asks for several different certificates from different CA´s? Which corresponding OCSP server certificate should be used to sign the whole response? * The one of the first certificate request? * The one of the last certificate request? * Any of the certificate requests? Is it a security hole, that the digital signature can´t cover the other certificates in that case? Or is it prohibited to ask for certificates from different (Sub-)CA´s in a OCSP request? I couldn´t find anything in the RFC mentioning that issue. Best regards, Philipp Gühring Received: from vig91-2-89-82-251-146.dsl.club-internet.fr (vig91-2-89-82-251-146.dsl.club-internet.fr [89.82.251.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l33HUExR081303 for ; Tue, 3 Apr 2007 10:30:14 -0700 (MST) (envelope-from trimbath@BISMARK.COM) Received: from mabrouk-12j9e0v by BISMARK.COM with ASMTP id 3DE81DBC for ; Tue, 3 Apr 2007 16:50:43 +0200 Received: from mabrouk-12j9e0v ([196.144.12.17]) by BISMARK.COM with ESMTP id AA33E48E8A6A for ; Tue, 3 Apr 2007 16:50:43 +0200 Message-ID: <001001c775ff$6df87c20$92fb5259@mabrouk12j9e0v> From: "Dena trimbath" To: ietf-pkix-archive@imc.org Subject: Soft Claws Chart Phone Date: Tue, 3 Apr 2007 16:50:32 +0200 Message-ID: <001001c775ff$6df87c20$92fb5259@mabrouk12j9e0v> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 000730-2, 03/04/2007), Outbound message X-Antivirus-Status: Clean browsers called Quick displays thumbnail Since http://img444.imageshack.us/img444/7424/r1qy3.jpg thing starting why Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31JGYqh018880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 12:16:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31JGYxT018879; Sun, 1 Apr 2007 12:16:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l31JGDhw018864 for ; Sun, 1 Apr 2007 12:16:33 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704011916.l31JGDhw018864@balder-227.proper.com> Received: (qmail 25935 invoked by uid 0); 1 Apr 2007 19:16:07 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 1 Apr 2007 19:16:07 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Apr 2007 15:16:11 -0400 To: "Anders Rundgren" From: Russ Housley Subject: Re: netscape-cert-renewal-url & beyond Cc: ietf-pkix@imc.org In-Reply-To: <00e001c77491$220ff6e0$82c5a8c0@arport2v> References: <005901c7735e$56b522a0$82c5a8c0@arport2v> <4561C2210415D081@pne-smtpin2-sn2.hy.skanova.net> <00e001c77491$220ff6e0$82c5a8c0@arport2v> 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: Anders: > >It helps the subject of the certificate, but this same information > >could be provided to the subject when the certificate is issued > >Ehh? When the certificate is "issued"? I think you need to >elaborate a bit on what you had in mind preferably fitting the 10M >and counting consumer/citizen certificate holders in the EU. At the time the CA provides the certificate to the subject, they could provide the URL for renewal. It does not need to be in the certificate itself. It just needs to be available to the subject when they want to renew. > >without burdening all of the parties that make use of the certificate. > >How could a relying party be "burdened" by a non-critical extension >it may not understand and definitely do not have to care for? It is information for the subject, it has no value to the relying party. The extension makes the certificate larger, so it takes more bandwidth, which remains an important consideration in some parts of the Internet. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31J8srA018166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 12:08:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31J8sHC018164; Sun, 1 Apr 2007 12:08:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31J8VuD018018 for ; Sun, 1 Apr 2007 12:08:53 -0700 (MST) (envelope-from anders.rundgren@telia.com) Received: from arport2v (81.233.229.21) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) (authenticated as u18116613) id 45FFF5CB003111E8; Sun, 1 Apr 2007 21:08:28 +0200 Message-ID: <00e001c77491$220ff6e0$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Russ Housley" , References: <005901c7735e$56b522a0$82c5a8c0@arport2v> <4561C2210415D081@pne-smtpin2-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) Subject: Re: netscape-cert-renewal-url & beyond Date: Sun, 1 Apr 2007 21:08:25 +0200 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.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Russ Housley wrote: >It helps the subject of the certificate, but this same information >could be provided to the subject when the certificate is issued Ehh? When the certificate is "issued"? I think you need to elaborate a bit on what you had in mind preferably fitting the 10M and counting consumer/citizen certificate holders in the EU. >without burdening all of the parties that make use of the certificate. How could a relying party be "burdened" by a non-critical extension it may not understand and definitely do not have to care for? Anders At 02:32 AM 3/31/2007, Anders Rundgren wrote: >Although the "netscape-cert-renewal-url" certificate extension does >not appear to be incorporated in any PKIX RFC, it is anyway >documented in vendor specs like: >http://msdn2.microsoft.com/en-us/library/aa378149.aspx > >I have two open questions regarding this particular extension: > >1. Is it supported by any PKI-clients and if so which ones? > >2. If it is not already supported on major scale wouldn't it be >worthwhile supporting such a facility? My personal experience >with certificates (I have had numerous), is that they tend to silently >expire, leaving you high and dry and concluding that "passwords are >better". When you have to "renew" from scratch you are thrown >into laborious processes which can take weeks to perform. > >If you have certificate and key in a connected device >like a web-server or mobile phone, you could very well >create something like we already have with Windows update, >JRE update, Adobe update, where the user in some instances >only would have to issue a PIN in order to get a credential >update. For commercial certificates the process would be >slightly more complex but of course an auto-renewal-process >must support this use-case as well. > >I do not propose making the Netscape extension a PKIX >standard but rather start discussing the road to a better >support of credential life-cycles. > >Comments? > >Anders Rundgren Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l31FnW0A008757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2007 08:49:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l31FnW6o008756; Sun, 1 Apr 2007 08:49:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l31FnBNh008739 for ; Sun, 1 Apr 2007 08:49:31 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200704011549.l31FnBNh008739@balder-227.proper.com> Received: (qmail 4280 invoked by uid 0); 1 Apr 2007 15:49:03 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 1 Apr 2007 15:49:03 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Apr 2007 11:46:41 -0400 To: "Anders Rundgren" From: Russ Housley Subject: Re: netscape-cert-renewal-url & beyond Cc: ietf-pkix@imc.org In-Reply-To: <005901c7735e$56b522a0$82c5a8c0@arport2v> References: <005901c7735e$56b522a0$82c5a8c0@arport2v> 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: Such an extension is suitable for publication as an informational RFC, unless change control is released to the IETF, in which case a standards-track RFC is possible if there is sufficient interest. That said, it does nothing to help a relying party. It helps the subject of the certificate, but this same information could be provided to the subject when the certificate is issued without burdening all of the parties that make use of the certificate. Russ At 02:32 AM 3/31/2007, Anders Rundgren wrote: >Although the "netscape-cert-renewal-url" certificate extension does >not appear to be incorporated in any PKIX RFC, it is anyway >documented in vendor specs like: >http://msdn2.microsoft.com/en-us/library/aa378149.aspx > >I have two open questions regarding this particular extension: > >1. Is it supported by any PKI-clients and if so which ones? > >2. If it is not already supported on major scale wouldn't it be >worthwhile supporting such a facility? My personal experience >with certificates (I have had numerous), is that they tend to silently >expire, leaving you high and dry and concluding that "passwords are >better". When you have to "renew" from scratch you are thrown >into laborious processes which can take weeks to perform. > >If you have certificate and key in a connected device >like a web-server or mobile phone, you could very well >create something like we already have with Windows update, >JRE update, Adobe update, where the user in some instances >only would have to issue a PIN in order to get a credential >update. For commercial certificates the process would be >slightly more complex but of course an auto-renewal-process >must support this use-case as well. > >I do not propose making the Netscape extension a PKIX >standard but rather start discussing the road to a better >support of credential life-cycles. > >Comments? > >Anders Rundgren