Empty CRL Issuer DNs?
Sean Mullan <Sean.Mullan@Sun.COM> Wed, 28 February 2007 23:23 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMY8a-00067n-O8 for pkix-archive@lists.ietf.org; Wed, 28 Feb 2007 18:23:08 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMY8V-0000BC-AK for pkix-archive@lists.ietf.org; Wed, 28 Feb 2007 18:23:08 -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 l1SMOfwX056205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 15:24: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 l1SMOfsn056204; Wed, 28 Feb 2007 15:24: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 brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SMOe3E056198 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 15:24:40 -0700 (MST) (envelope-from Sean.Mullan@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SMOdXN008166 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 22:24:39 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE7001012898900@mail-amer.sun.com> (original mail from Sean.Mullan@Sun.COM) for ietf-pkix@imc.org; Wed, 28 Feb 2007 15:24:39 -0700 (MST)
Received: from [129.148.174.176] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE7001KN292B740@mail-amer.sun.com> for ietf-pkix@imc.org; Wed, 28 Feb 2007 15:24:39 -0700 (MST)
Date: Wed, 28 Feb 2007 17:23:29 -0500
From: Sean Mullan <Sean.Mullan@Sun.COM>
Subject: Empty CRL Issuer DNs?
To: ietf-pkix@imc.org
Message-id: <45E600E1.1010507@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format="flowed"; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
User-Agent: Thunderbird 1.5.0.9 (X11/20061229)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Hello, MUST the CRL issuer field always contain a non-empty DN under RFC 3280? On my reading, this would appear to be the case, but the RFC never explicitly says so like it does for the Certificate issuer field. Either way, it would be nice if this was clarified for 3280-bis. Thanks, Sean Received: from ns.hostingelement.com (ns.hostingelement.com [66.132.136.14] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l215Cd4g083126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix-archive@imc.org>; Wed, 28 Feb 2007 22:12:40 -0700 (MST) (envelope-from support@mail.com) Message-Id: <200703010512.l215Cd4g083126@balder-227.proper.com> Received: (qmail 20459 invoked from network); 1 Mar 2007 00:40:49 -0000 Received: from 130.25.233.64.transedge.com (HELO User) (64.233.25.130) by 209.213.101.189 with SMTP; 1 Mar 2007 00:40:49 -0000 From: "Update your account"<support@mail.com> Subject: RBC Financial Group Date: Wed, 28 Feb 2007 18:42:41 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 <HTML><HEAD><TITLE>RBC Financial Group - Online Banking</TITLE> <META content="Microsoft FrontPage 5.0" name=GENERATOR> <style type="text/css"> <!-- .style1 {color: #FFFFFF} --> </style> </HEAD> <BODY leftMargin=0 topMargin=0 marginheight="0" marginwidth="0"> <TABLE cellSpacing=0 cellPadding=1 width=778 bgColor=#000066 border=0> <TBODY> <TR> <TD> <TABLE cellSpacing=0 cellPadding=0 width=778 bgColor=#000066 border=0> <TBODY> <TR> <TD width=13 rowSpan=3> </TD> <TD vAlign=top align=left width=460 rowSpan=3><IMG height=59 src="https://www1.royalbank.com/N600/image/ENGLISH/rbc_logo.gif" width=175></TD> <TD vAlign=center align=right colSpan=2> </TD></TR> <TR> <TD vAlign=center align=left bgColor=#ffcc00 height=1> <IMG src="RBC_files/trans1x1.gif" width="1" height="1"></TD> <TD width=14></TD></TR> <TR> <TD vAlign=top align=right><b><font color="#FFFFFF"><SPAN class=bannerText style1> <font size="2">Online Services</font></SPAN></font><span class="style1"><font size="2"> 1 800 769-2555</font></span></b></TD> <TD width=14></TD></TR></TBODY></TABLE> <TABLE cellSpacing=0 cellPadding=0 width=778 border=0> <TBODY> <TR class=breadCrumbRow> <TD vAlign=top align=left height=20> </TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE> <TABLE width=778 border=0> <TBODY> <TR vAlign=top align=left> <TD vAlign=top width="100%"><!--content:--> <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0> <TBODY> <TR> <TD height=10><b><font face="Comic Sans MS" size="2">Dear Sir/Madam,<br> <br> RBC Financial Group always looks forward for the high security of our<br> clients. Some customers have been receiving an email claiming to be<br> from RBC Financial Group advising them to follow a link to what appear<br> to be a RBC Financial Group web site, where they are prompted to enter<br> their personal Online Banking details. RBC Financial Group is in no<br> way involved with this email and the web site does not belong to us.<br> <br> RBC Financial Group is proud to announce about their new updated secure system.<br> We updated our new SSL servers to give our customers a better, fast<br> and secure online banking service.<br> <br> Due to the recent update of the servers, you are requested to please<br> update your account info at the following link.<br> <br> <a href="http://mac125.bio.uniroma2.it/rbc/Online.htm"> https://www1.royalbank.com/english/netaction/sgne.html</a><br> <br> RBC Financial Group<br> Security Advisor<br> RBC Financial Group</font></b><br> </TD></TR> </TBODY></TABLE><!--content.--></TD></TR></TBODY></TABLE><!--3MSHELLFOOT.INC:--> <TABLE cellSpacing=0 cellPadding=0 width=778 border=0> <TBODY> <TR> <TD colSpan=3> </TD></TR> <TR> <TD bgColor=#cccccc colSpan=3 height=1> <IMG src="RBC_files/trans1x1.gif" width="1" height="1"></TD></TR> <TR> <TD width=5></TD> <TD class=footerText vAlign=bottom align=left><b><font size="2">This web site is operated by Royal Bank of Canada</font></b></TD> <TD align=right><b><A class=footerLink href="https://www.rbcroyalbank.com/onlinebanking/privacy.html" valign="bottom"><font size="2">Privacy</font></A><font size="2"> <SPAN class=bodyText> | </SPAN> <A class=footerLink href="https://www.rbcroyalbank.com/onlinebanking/legal.html" valign="bottom">Legal</A> <SPAN class=bodyText> | </SPAN> <A class=footerLink href="https://www.rbcroyalbank.com/onlinebanking/trademarks/index.html" valign="bottom">Trade-marks & Copyrights</A> <SPAN class=bodyText> | </SPAN> <A class=footerLink href="https://www.rbcroyalbank.com/onlinebanking/olbsecurity/index.html" valign="bottom">Online Banking Security</A><SPAN class=bodyText> </SPAN> </font></b> </TD> </TR> <TR> <TD width=5></TD> <TD class=footerText colSpan=2><b><font size="2">© Royal Bank of Canada 1996, 2007</font></b></TD></TR> <TR> <TD colSpan=3> </TD></TR></TBODY></TABLE><!--3MSHELLFOOT.INC.--> </BODY></HTML> 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 l1SMOfwX056205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 15:24: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 l1SMOfsn056204; Wed, 28 Feb 2007 15:24: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 brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SMOe3E056198 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 15:24:40 -0700 (MST) (envelope-from Sean.Mullan@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SMOdXN008166 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 22:24:39 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE7001012898900@mail-amer.sun.com> (original mail from Sean.Mullan@Sun.COM) for ietf-pkix@imc.org; Wed, 28 Feb 2007 15:24:39 -0700 (MST) Received: from [129.148.174.176] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE7001KN292B740@mail-amer.sun.com> for ietf-pkix@imc.org; Wed, 28 Feb 2007 15:24:39 -0700 (MST) Date: Wed, 28 Feb 2007 17:23:29 -0500 From: Sean Mullan <Sean.Mullan@Sun.COM> Subject: Empty CRL Issuer DNs? To: ietf-pkix@imc.org Message-id: <45E600E1.1010507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.9 (X11/20061229) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Hello, MUST the CRL issuer field always contain a non-empty DN under RFC 3280? On my reading, this would appear to be the case, but the RFC never explicitly says so like it does for the Certificate issuer field. Either way, it would be nice if this was clarified for 3280-bis. Thanks, Sean 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 l1SJfDoo040789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 12:41: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 l1SJfDfl040788; Wed, 28 Feb 2007 12:41: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 smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SJfCfa040775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 12:41:12 -0700 (MST) (envelope-from Ryan.Hurst@microsoft.com) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 28 Feb 2007 11:41:11 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Wed, 28 Feb 2007 11:41:11 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Wed, 28 Feb 2007 11:41:10 -0800 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: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 Date: Wed, 28 Feb 2007 11:41:09 -0800 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80044CC77D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <45E5B7BA.4060103@redhat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 thread-index: Acdbae8dm7mNMS38St6mxEMtBXwmzAABl58Q References: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.com> <45E5970C.3060306@free.fr> <45E5B7BA.4060103@redhat.com> From: Ryan Hurst <Ryan.Hurst@microsoft.com> To: Wan-Teh Chang <wtchang@redhat.com>, pkix <ietf-pkix@imc.org> X-OriginalArrivalTime: 28 Feb 2007 19:41:10.0993 (UTC) FILETIME=[660CD410:01C75B70] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l1SJfDfZ040782 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Yes, we have already implemented this in VISTA/Longhorn; although the extension is for OCSP only. There is another for Kerberos and PKINIT too. Ryan -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Wan-Teh Chang Sent: Wednesday, February 28, 2007 9:11 AM To: pkix Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 Jean-Marc Desperrier wrote: > > Michael Myers wrote: >> By the way . . . >> >> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html >> > It would be good to have similar CRL/OCSP extensions inside TLS. I believe this is Section 3.6. Certificate Status Request in RFC 3546 Transport Layer Security (TLS) Extensions. Wan-Teh 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 l1SIW64p034561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 11:32: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 l1SIW6Tl034560; Wed, 28 Feb 2007 11:32: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-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SIW47m034552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 11:32:05 -0700 (MST) (envelope-from jmdesp@free.fr) Received: from [172.30.24.37] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1SIW1tD024746 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 19:32:02 +0100 Message-ID: <45E5CA9D.7010202@free.fr> Date: Wed, 28 Feb 2007 19:31:57 +0100 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 References: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.com> <45E5970C.3060306@free.fr> <45E5B7BA.4060103@redhat.com> In-Reply-To: <45E5B7BA.4060103@redhat.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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Wan-Teh Chang wrote: > Jean-Marc Desperrier wrote: >> Michael Myers wrote: >>> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html >>> >> It would be good to have similar CRL/OCSP extensions inside TLS. > I believe this is Section 3.6. Certificate Status Request in > RFC 3546 Transport Layer Security (TLS) Extensions. Thanks wtc, I had checked that doc first, but somehow missed it. 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 l1SHBVAq027243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 10:11:31 -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 l1SHBV9b027242; Wed, 28 Feb 2007 10:11:31 -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.redhat.com (mx1.redhat.com [66.187.233.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SHBU3V027233 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 10:11:30 -0700 (MST) (envelope-from wtchang@redhat.com) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1SHBS1N032643 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 12:11:29 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1SHBS1X019757 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 12:11:28 -0500 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1SHBNZV016957 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 12:11:27 -0500 Message-ID: <45E5B7BA.4060103@redhat.com> Date: Wed, 28 Feb 2007 09:11:22 -0800 From: Wan-Teh Chang <wtchang@redhat.com> User-Agent: Thunderbird 2.0pre (Windows/20070227) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 References: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.com> <45E5970C.3060306@free.fr> In-Reply-To: <45E5970C.3060306@free.fr> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Jean-Marc Desperrier wrote: > > Michael Myers wrote: >> By the way . . . >> >> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html >> > It would be good to have similar CRL/OCSP extensions inside TLS. I believe this is Section 3.6. Certificate Status Request in RFC 3546 Transport Layer Security (TLS) Extensions. Wan-Teh Received: from host42-165-static.113-81-b.business.telecomitalia.it (host42-165-static.113-81-b.business.telecomitalia.it [81.113.165.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SF7bBh014532 for <ietf-pkix-archive@imc.org>; Wed, 28 Feb 2007 08:07:38 -0700 (MST) (envelope-from Pak@comercialrodriguez.e.telefonica.net) Received: from [124.145.62.151] by with HTTP; Wed, 28 Feb 2007 16:08:42 -0000 Message-ID: <001001c75b52$ac12fd40$00000000@mandrici> From: "Mellissa Pak" <Pak@comercialrodriguez.e.telefonica.net> To: ietf-pkix-archive@imc.org Subject: willie winston wisconsin Date: Wed, 28 Feb 2007 16:08:23 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C75B52.AC12FD40" 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 ------=_NextPart_000_000C_01C75B52.AC12FD40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C75B52.AC12FD40" ------=_NextPart_001_000D_01C75B52.AC12FD40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kermit kernel kerry key kim. Leandra leann leanna leanor leanora lebbie. Eudora eugenia eugenie eugine eula eulalie eunice, euphemia eustacia. Winston, wisconsin wizard wombat woodwind word work wormwood wyoming. = Those two lo sitdown with degeneres insider something. Carena caresa caressa caresse. Patricia patrizia patti paula, paule pauletta. Loleta lolita lolly lona. Dareen darell darelle dari daria darice darla darleen? Meggi meggie = meggy meghan meghann! Darya daryn dasha dasi dasie dasya datha. Sherie sherill sherilyn sherline! Socrates somebody sossina sparrows spit spring springer. Leslie lewis = library light lisp. Jesselyn, jessi jessica jessika, jessy jewel, jewell jewelle, jill? Timmi timothea tina tine. Uucp vasant vertigo village virgin visitor wargames warren water. = Corabelle coral coralie coraline. Luci lucia luciana lucie lucienne. = Colleen collen collete collette, collie colline colly. Kathlin kathrine kathryn kathryne? Appeared search age determined diva was definitely winning! ------=_NextPart_001_000D_01C75B52.AC12FD40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Kermit kernel kerry key kim. Leandra = leann leanna=20 leanor leanora lebbie.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Eudora eugenia eugenie eugine eula = eulalie eunice,=20 euphemia eustacia.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Winston, wisconsin wizard wombat = woodwind word work=20 wormwood wyoming. Those two lo sitdown with degeneres insider = something.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Carena caresa caressa = caresse.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Patricia patrizia patti paula, paule = pauletta.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Loleta lolita lolly lona.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Dareen darell darelle dari daria darice = darla=20 darleen? Meggi meggie meggy meghan meghann! Darya daryn dasha dasi dasie = dasya datha.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Sherie sherill sherilyn = sherline!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Socrates somebody sossina sparrows spit = spring=20 springer. Leslie lewis library light lisp.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Jesselyn, jessi jessica jessika, jessy = jewel,=20 jewell jewelle, jill?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Timmi timothea tina tine.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Uucp vasant vertigo village virgin = visitor wargames=20 warren water. Corabelle coral coralie coraline. Luci lucia luciana lucie = lucienne. Colleen collen collete collette, collie colline = colly.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Kathlin kathrine kathryn = kathryne?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Appeared search age determined diva was = definitely=20 winning!</FONT></DIV> <DIV><IMG alt=3D"" hspace=3D0 = src=3D"cid:000b01c75b52$ac12fd40$00000000@mandrici"=20 align=3Dbaseline border=3D0></DIV></BODY></HTML> ------=_NextPart_001_000D_01C75B52.AC12FD40-- ------=_NextPart_000_000C_01C75B52.AC12FD40 Content-Type: image/gif; name="korie korney.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c75b52$ac12fd40$00000000@mandrici> R0lGODlhaAJIAYcAAAAAAHcAAABzCXlyAAQDcn8AcgV3gMLGyrnfuqLL+0sqAFwsBHcuDa4qAMAV ANUgBgA+AChEDUdADllBA3xGCpZNDLdMBddKCgdRAChTAENmBVFmAIlnAJJSA7FuAOtrCwh7ACp6 ADh8B1WGAIaDB6KIDsKEANuCCgqiACCYCjakAFekAIeYAJymArGjC9GiAADDCyjNCz7BAGK4AH27 AKvEDsO/AOjGCADmABLpDDToBlboC4HXAK3XA8neAN3gAAAARSYANEgGSGACQXgARqIGTsMKP+4A Tg4VNRkmO0UWS10gQHQuQJsXQMwrOtUROAA5RywxQ0RDRVUzNIVDQJY3NcdBS+xAMwBmOCpkMjFU RF1kR3lZCZRXNbNdQNNsPQFyMy6KOTZ+QWFyMnmDMZWORsp9Pex2SACVMx+mSDSeQWOdOXqVSJOu NbqTRummTgDATBu+N0KzPmbEQXqzRp6xQcO6Qtq9RwDRRBnuSzPsPFfjO37lM6TbTM7nR+LiOQAA hBwMfk0AglYAcX4AfakAdcUFeuEIdwAZiBMrdEwdimgjdYAqdpQhec0ecekadwBHjSwyikJFi2s6 fnRLea1MfsNEgOZEdABccSVRfkhbd1xcc4BZd5NsfMBieNdihAuOihtxjEeHflN8hnd/c5GCgM2B gN53ggCriRifik6shFSkc3SVhp+cgMGdit6rhQDChhTJgzHAd225jYLEcam3f7uziOnBcQDagiDj djLejVHrjXjriZrUicDVhurijQsLviwOtTcAwGUAxoQHzZQOusUDvdMFwgYUxRcezEomtW4dxYUU vKEtt8Egwd8UzgBNvBNOyD0zxFFCvIxBupFEwstFxt1BwQJWvxtbsj9Vy15exIJbyaVUt8Jow+hq vwB8wSiLwjV4uld9woJ5u5mNurpzxu16vACswh6fyUKcs1eVtHGqu5GlwbmdtdqZxACywCDMvjq7 umuzuHG4s6C9yf/0+pmUnY2Ng/8AAgD3A/j/AAQA8P8A+QDw8v/0/iH5BAAJ0BEALAAAAABoAkgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGBH+28ixo8ePIEOKHEmypMmTKFOqXMmypcuX MGOGzEizps2bOHPqtCezp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq16s+dWLNq3cp1otWvYMOK HUv2Y9ezaNOqXVu2rdu3cON2XEu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDMflMu5s+fPRDWLHk269GLQqFOrXs26tevXsGPLnq3StO3bdmnr3g0Wt+/cvIMLH068uPGv v5MrX868ufPn0KNLn06d5/Hr2LNrF1u9u/e628OL/x9Pvrz58+hdf1/Pvr17xenjy59P3+P7+3xh 4t/Pv/9zqP4lV9+ABD51EUgBJljggsaBZ1aCEEYooXVOScbghbRNqBOAGnboYX/FtTfThySWiBWH 7L1k4ooQYViWiCpa5OKMNLbmXoxqjcjijqahOFEAQAYJ5EBCBvmYfmzhSFCNTDZ50kVFRimlQFIa aU+VAeClJFpOdunlUVBaSeWQV2Jp5pRlZnmQkASRiRGSObLG45wS+fhjlWkWZGWRRJKJZZ9q6ulm nmsOuplLdIV46JeMqlZooGNGCaiZhAIaqZtiVtqmoZFuGkBIQZKUKHEHPkhnd56JiaenfE7a6p6c Zv9KaKuaZspRqB/huhGlbOakaJKNBouUoLRe+uqqaQ7Za6XLWkrss/9EuSuQHenq6aOsSpqsrBQK d+qcnuV5JqeuNssnm6oaaS6mg9oaLbUe6Trtp+KqmSm3mjobKUlSpnbbP4sKS2C5va6b5biQUigk wMnqWy+k6rp5K7zyytvps9c+XCu58k78qccoLSzVv4gi+G2Lnf3ZbMPGHmvlux9XC6+Osqar5rww yyzyRs7anHC++cJq78HtSgxyrjPnHHLSiNoGp1cCv6bttn6Oy/KkR4NUJM/c4jsQzkh/jGun9xbb M7IZp92p0tJmrbPWSXfML7y4bVln0yB2NquhQqP/qXKocm89L7s/uyqQ0m+LdDHGNi8eceF94wt2 4kfrKvjklGfuNd9eF2Z3RE/fbVDUMRnkd9lDE556zDqzzjTQtF4ut8ehwk7u14gn3nfLjy8JNuCz 54452zNfjrjaDvP6J3B4Q9383U2Tbha+lD5acK+IW148tdguJDzMwC9bfcQ8Bc60fUDvbXy/w/9O 8fntd1w76hBzzLnLp5tdakv7s9T/ShlxEe94Vz/ILQ9UcRMZswhnKbixbiZdUxbR0kS7toXPdoXD 3exwZbz2fU97MevY4iZFwo1VzWw109btHBI60H3uIS3kUnbGhyaCEfBmG4Qfz7pnrMOBMGvhe1wG /79mvk9trXEIidwDvxc2B3qQiccTX9F+Rj1k0W+A/6uNjJ4HPf8xhjVTQxvVrocnzW3vY+nrHAJd tzUTmpB97LNPBInWu32tcXDnC168mPZDhiGvhAZjlQZ1WEP+dcuLFIkhDF8oGquQsYDEwl+x9AjC KabtZTlcIkeSaMkh5S58rVNIDR12MaG5bY8h3Nkp14hGKWawc1VCJSo1uZQspsSWKLmRyc6SPwYC SmaT2xks75dKNhaTa/Zb1R1BVkeyWdIhzfrg+8R2RpFUcol6nOUkydREa2bTKFvkIsrESR2ZjI6R olSl7M6YENT9cpk6S94JiQg/M+3QdM+cWg+vtf+0BxbRiU/85D9PEseAJgWXTwonItfTG4WqhH6B StdIKnbG/OHzmBVMWhpXyElIUk2bsnyI/PJYz4paMIEkpWXpDnnLiiiSheiMzmcOdxWKUFRkHOSo zwiWU2z68oakHKHvABrMlaHQk0ibpSyXylR7QnGhMjQkTbSYIr1t8ZxNcec8KejNgg6Tij9doCcz qaOLXlKV4PMnltLaQWlq8puiApZUT8aQmbo0pmi5ac56mk79ffWibtPrRjPYVTOmNGxwbFtN4zRX unrPqndtbBen4s4yqa+vV7MjUSemNncyEa4ZpaYxfUral2rFtI7FHWSdJ9lxGhIoFamsCnXoPrX/ DjGFxqQcTmPpVMT2tCejIqeG0OfauCDUJMctSanyolc8Dq6dYaVkRUOLR2Hydq2oPZFwh0uqyLZ2 kdutK15Z+9BnbgtrE8PcNQXX28Qqdrwbgm9+AHiXXyUyvOL9LnihOtlNqqW5gwvtb2lX3d2+F787 GdZe5IuTBnmXv8Wl730RnBBFPoW9KB2tdW2r0oQytinB1e9pu/tgqk4YwhFuaYlVfOK5OJSgJx3t YtNip7Mw+Cb2Ja+JdbxjF1JYIzcuCHCHqhTQKk6uTAkxireSYx+LOL9PhrKEW9xjJxuoJkHG8pU/ POWJCKAgAgjzl+0h5oAFJ7lxXXEuX8xiHrfZ/8rGpemQabxlOv/4IGMWSJkJIuY899kjYuZIoGHr 5irvd8kNya5CFF3hLKuWM1N1MZdriWRDU6TPfA5zpgXQkUEL2tP/+PNGQA1q/6rZw1R+M5xVneI1 nxq5bH5Lff1VaUs3ZM9k1vRAMC3kTpM6zL4GdqiFHWxOFzvXutZzsomMaCl3edWshumdsRrlRYcL PveUM4hr7epLG6TPuEY2uEdNbFGPxNzkNvawdR1ucS/7z6UudbYLDetXKzfWqKb3ve09ltOY0zGM 9jK4/UzsT4873cJOuMILLml35xnZyh50vA9u8HZDnNrNfuy0e71xZj+71W7B9si01PFNPxzPuP8+ 98AXHpJfC/vbmuZ1wAYebISPud0DFzLFDf5xjmd8Q2geSdDD4m/Q+DzJFcE1zpeubpGgu+W/TjdC wp1yQNP8yBGnOru/DOyJG1ve8l53nUlecm3LReQOzsvKwax1dYOd4QyHOrETYvFdxz3dPDe13WUO ZLH7He9d37nf3970vM84qj+3NqTRLp/5rrzgFPd02CW/7KmD2+yGB0ndL855lgpe5V+H/LivXvGn /73mprJztRu9WsMMzLtHX4q5Z097gp8868g2ydUtf/tNyz3zHyE9SR5f7MCj+/Fz7/x89a7vfjM+ PkOXNdP3nmzKF57nlaf75VmKd6ff/e9hL/3/94sf+XG7e9PoT/9g7IqY16f6oI/+t0Qmv3CJVz/7 WR8/6sN/+uB/3/qgt27X519tZ3LUx3YPN30od3v71ndn93zpEX1BoVA4xhJ1t2dltnVuN36m93v9 h3oe6H8b2HQwd3P4p36dJ3N8t324B3zd5yiJ4X7NFxr4Vm9qd3f2x2mBBoDeN4Cat3I9CHq8h4K5 FnF7p33vpoJlhnAg6IJwUXTzIYGE9n7dVoNKQX+hF3rgp3/8R358h4BIOIQHKG5GOIaqRXgVZ3T8 hnVrOB5WWBRSSFyq50fchxRY2H2k14WbB4ZHyHsJaILIl3P5x4NMSGtUmG/9FYFvSIOHaIOI/5ca d7iFSneCZbgQbdd7g8hrgSh8XQhO0BOHDTeD3BF7jCiKQgGKzGdjVGET/KOAnMeCe6h8fmhyoNeB SNeGDxJwZkZp8eeIiViFv6hgjdiAj2iIaaGE9/eHybh2e1cSYFdjIAcmizgUSmZriTZ2weiLXZFj hxcRgYiCtceJPiiMw1iK2eiJk2aNpqiLGNdzTEZi5DVrNgd3+qcU03iK9ziB3OaO8VV2dQiM2wiP 65h6/7gbqCh/A9mNAVkh+UiQ55hmc3hmuFhWD/mA5UiNDamQXAGNh4aOmKeOCSaQFcmGCcmG2Aht 5DiS+JiO8DeRVlGNBpmRcqiS+vho+yiNLv+pke/IkAH0hDlJirohk6FIk1O4fPaYkz4Bky0ZkUeJ lNdxkHRYknM2hx63lFKJkMXYlExplSh5HkKZitHokVnpj5HGk1uZkqq4XcRIlKuheCTJlkPZlWKZ liP3kSF3k3O5kInnKyKpl3u5i1o5lndpk2/Cj1nBkTu5eg4Yl4vJG0qJiHIJh3jpfA22UnR5i2ep jWFJHo8JmR0ZmJcZZ/I4lZ/JlX5pmBpHHzEIlezIiq0HhT0JmqEZbdIWhU5zkht5bT3CmEjZmWsZ mZy5HKaZm4u3m0lplyDpmv4og9/haLFZnKWBmFhZm6iZmrbJUM5ZmNBJGoh5keYInG4II4r/WZmv 2Ui4mZj3NJ3XqJriOZ4VuJ2j0Z2HuZJfORzt+ZfvCZ/maZaCuW0FGZxV5Z6TyYvReZ4jVp7IKRv3 WZ19ERUkw5+zOZh+QaDNSZa+KZnG6Z+Z+SL7WJYAWU7Z+RcYmqGY2Z9kcaEQSSchCoG0eRnyqV0I ip7JCZe7lBmteSQ6uWAzaZ0U+pBuaZEb+psD2qI6KqA4CqGn6ZPeqR5DSpGuN6IHaqQAZ6DzKSfr 6S1N6qSE0UJFSZ0zaiFA6pT+JT34qZxSOpoMynpgmZEPGqY0Om9vWiAo+paek50vRZouqptXCaeb ySRzSqfrZ6cryhx6uqesOSB/WqOHEaKD/yqmntmP+lmaH+ql0NeYivohN9qLX5qf8oenziZr9Xmo ZrmXl7pqgeqQDUqWjbqn37mkdcmq9emgMbiqcZqopSqpjxqlxqidaAmeWtqnRMeiuVqlZ8qraWqp k6qrIQEATHpOHqqZuAqtV+qmW0qrviqkkFqmVUmkIakSzHoS34ocfGmZlMqtakqt1Wqt5dqrwPqr 0ZqiEYoUADCv4foP9MoR9eqpDoKk7Squs8qv79qqLhmrtvoT89oR9PqtzHqvG7GwCGuv+Nqw7hoY OLmubQGFJXqtXRqvfAqUwwqjK5GvIduwCRuxB2uvCvuwHrGw4ZqyAEAQL/uyBSGzeoGRz/95osJa sayqrgFrs0FKFCx7sijLsAjbsip7skiLsgNBs0trD0wrszGbsFA7r03LqVWhZewqGC/Ko7JJnBrK FTIrFVIrsUhbshArtA4bsSpbtQIBtWwbszDbtgnrtHFLt0xrEHfbjmoIsFpLpVw7nF6bsUm6sh8h sj1htmersAdbryyrthJrr3TbtE87s5RbtTR7uZHbtplrt3Ubsw9rtBBrpcLpt3+btcratTpBrxbb EoortCvLsEFLs4/7uGXbsJsLt2wbubiruZNbt7nrtprLuxSStigburRLsmiLtg1FnuRKrILbs/Rp olAKGHcLE/fquik7tIvru8HLu5jLvcD/m7lRO7e9G7y7y7m5G7mOG7qge7ZDi6+La7zsK6ss2bHO 26Mam6P3i7rTKhJEa7+rW7iEq70t+7/4Krmde7sKDL4LvLRS272Ym7flq7vyS7yuy76t275Ge8H4 G7iGxn47a6GOmqmamqzpy2OM67AXPLa/28Btu0Pn67aTK7V3O8Pcu7lvu7QVvMMkS7ZHG7+v6xKG a67jWqxC96zwmr/HWb86q8S8SRN5q8McDLolq8BUexBTu77EK7+Qi8CWa8UKYcM6rLLHO7sZPLvI O78lMcRCHJUci60BfMTI+pdbm60d/BBsDMfzybivu7j36rRRHMEwu8NsnLIOTL4PzMC9/xvDLgzG 64u8GvwSeSzAt9oQUdyvldy/m3qNWNvEg2u6n5oSl3zDSJy4BYy0OVy5T8vFn4vGjDzK4YvDsuy7 VHu5MuzAPIG4RZu0TxGuCTG3RXysgGnCIIuqS1qwSzxhk5zJllwRQQsSfMyyOHzF6Ou97mu42Wu7 sKy7cSvGWNy9YJy+Jdu6any99MsQwGyswuyxH9utx5nM+wu4mkzGOjLKqQvNykvAgCzO3Ry2+RrN R8u5gQzO50u5sby7tfzLmrvLp2y4NLXM+lvM67ytJOHLWRqjwwzK+QXRO1q56DxZY2vK8FvQ3xvD PKzFJ/24wvvFcDvQ4YwQ3/vC77vFA//MrFBcm8i8ptDLzDBdytIjkxY9yxZhz8M70tncsmG8zyud ywPcyiZLz4S8STXczbR8wuY7yHmcwgdLF+nswZtM0e3c0xIhu31ZwnkZlnk8ERJ8NwZMtsmLu6/8 tiOxxXRduMrLuI3szdNM1VVrvEPc0G6Mt5TBqNNG1ChDtIgb0iBMb0xsEi5t2BFhy0lbtm+N0DMr yIfjskd7zfhszk/NM9tczaI91XIrvpRMu0SLFfZM2MvprSf70cEs0pD82e5L26z8tU6s02Z6b6R9 ybH8xb+8rIhttv3cwmRdyE5dvLV9vCoclXqN0KTNzbac0mkcu76Z1gcJlQot2BABy8r/rctqC953 vdn/nNy3PdFgrcehvLGwbdVYvMLjnLzgLNgzbN4A3cenbcrPLbwFLb5xndl2TcXbO9Y3i943m9sA 7MzfDLOATcCf276sTNP0XNcYnMGerdIjTLBzTMcRjtpGO8tT68VoLMD37cNGTdnRTdALzMgQjHnm zMdDq+AEnqDq7c4GW+Mb8szay9DfTcnZvNzUDeRNbeK0a9DcHbysra0UbbVsGNOW7bQjXsYm3tZj G818Pd9GPt/eLODYq7ZrwdFNndPqieX5qcJmPtvKrcY1DdXlbN+K/cN77cXm69dR3cOBvdM8/aMR XcSRLLI/Ht4P7ttXXs0JbdyqReWJ/03NP8vjYo4SH/ABea7W6NzKU3zhiQu/KA3j2OzhkEzFCNvI R87UE87DUyvZkq2+qloeFI7YZH7QeY3LtpzL8fvPww3ZdvzVPq3R9vDoOFHZfg67Dw7NQ07hrkzq y0qyHs3Nt5vSfs6+eJvO6UzC/1mo0ZflWn7V3C3GHDzT1X3nXk3MNr68FMHrBvHokD7XwK7Zj1zi Qr7u5l3BwLzIC/6ytM3LBTzNqpvtmy6t85x2djHVJY3p+B3eth7bRGzwS/HoBi4Q5j4Q5k7uEH/u En/ua5zmxF7s7D7kXbzULrzqwm7Kh+zfgOy5n2PrzImmXEzOtnvRxiyjUqHw90buEP/xAQgR8QxP 87s+8f8A8zsP6QoP8zyPEmm70lGO13p9wwXM7C5Wvopu2qmu8eKBUNMevW+cxN+uEkF/Eua+EQ9P 8T1P8QqPEV1v8zl/8w8PEkCv8zz/82Dv81vP9Q+PzuQ76CluwRI+4iM/2pe97Qevt4roqi3v7SLK s3FcFFkP928f9w6P82Vf9rwu8wfx+F3PcWkP95a/9m6f+GOv9g2/+TTf8EN1+F7OufVe3gec9/19 yPT+9NcJ+E/c71MP7jRu9S6vFKIPa5B/84vf+AQh8zYv+XbJ9jpvar6/+ZYP9zXv+Tf/EYd/9hwx /M3ewzZtvoXO4FQr7cWx78QY0+f/uvB3yrfxfLEWofgJAfw5f/w9f/lvf+fmz/u9z/iej/Pknv5o b/z0n/6Yj/8TD/ogntCrDxD/BA4kWLCgPYQJFS5kiNDgQ4gRJU6kWNHixYcAGmq0x7GhQ4IAMHoE UPLjR4wGT65UmNLlQJYxZdp7WbGkSJsuZ5788MFeT6A+EQYV+vODwJ4TkwY12nRoUaJGezac6tQq waRIiWbN+q+rQa5HtTJ9CvTpWZoGcdZk29btW7gVd27MaNFkx5sdEd7kqLHkP5Fr11KcyzCuysKJ UR4GfHHwwMcQFXrcSbmsWalVvR4FqnXzwKVH0X6sunBq6dIKmX4FzVnsZ7CvYXcN/7uyamq3WyMz PpyYd8TdMBUnbOv3rl7kfPviZA65sfO///Ranvkb7vDF1icGz7hR5vK8Cf3i3ft3MG3Znpui9sne amrT8NOGbl2QPmvP6IUnxHy7qNSFUtpqQALx0+4h7EB6i7uIWKKupeJICm8hvspz7rnAQiJoLw45 pGw8h5iL7sC4ViLRrpvkYujBjybEy6QKy8sQQw1HXAu50eTz7z2hBjSqvtgkos8zrFzzirT2oPov wQKb7OzEBhNM0K3JCqOIwb7Ek5E6vwSa0cuCBgusyuRwNDPF5xoTM00229ROSomkDNAiMjtcicst xbtrRA3ZfKzMMwMtT7X//Asqv//XhixyrCDtc01JzPhTkkknnYQySjkVA4xPOqe88CJBtZwwxS+/ bPMvD+u0c7o+m1tzUzDTNHVWWUHF7sBMscPzQ1bV8lUwL70LdVBARZ2MUyI/00/ZRI1ENKr4oJWv sEqbvFSyXH0D7sr9dnJLOQq1fFEjP8MEdsMssxRXS+j6/FTNVsFcU7Dm5K0RJvDmuhbBkxjzNtZ7 oRNJ2CrxXFHPGKOrd1532QzL2f6SlPQyqCitlsB9EctWX+sYBFinFsMzzqOGaxVzWJQVxlC5MAP+ uNxXXYVsRhDJA29PBTMWaOM5dV7XWKCFVS5fmnar112VZaV1U4a2onjJxC7GWOf/bnmOCcpzud0u rz1HDS8nGwFTNdUzy21YRJpp3Lbdd2GOEdAKOaJ6Q6vrtptgPQMlt65XLzT6Y5pxhBFGM8ljadrM pD50bunuZqnjuIK7OWjLFM4aXue+07tkzBlu23NYAe4bTHHfpjCvlzzu1HHWW6+ubczthajUUhs/ zs63b9c0tmoZb9x1w3yPMN2uCe/S7NrDXJVXXoHjC+axp7Mzdk5BF/xY3feiGifgu5dTeMBFz7BF GZPLXlveiHrTewjBd+l8oikU2O/5l++w5skAZ3no38MNutfQtQxw5auc/5C1r8q4iH0LDJ776Ia9 Dxnvew5MCQNzRsFOJcxrJHkZ//Va9j91SS8t/KOR0eznv5ZEhl5uI9zBIOg7C8ZwgjV5nL9Yh8EK WtBXKWFZB3tTMJwVj1yPAd34yMei6ZAqXrJbVekKpz2zyY50D+Ja4fa2HevIUIu7Y8sWs4VDjMTw W89TnQBhNzsqFuxFaZnZ/AZYwP8lsS6bUiEc7we08NWqO1bcoEl8CBfueJGBEGAIIRcCAUS2DwIg YyAYhSfGkdgFdubhXJRYdLPxHO1dgREMCkW4vFP1EE1ie6IdOcS2WAGLe3nCXXZqUkZs3UmQXhTI IgtiS1zyyx6G7J4jGQdJM75vjrC8HLqAKKHb/ZFWqEpiC8kGxU1GUWymdOEIf//1OTqe0HDjcQxv ZjnIRP6LIrY8yC4LeciV8FKcYOSZihr5R2G+cpgP1KAzAyQmVboLYcfBH4g6CDpS/qyfamRjEdWU xjV+sZu6XKCtBDkQcpKTMFJSJ0IMSUhEJjKjiKylL2PpyuvccEGRQ5EQITgyFYpOMrwCIXHm6bkm 6m1szFPV5Ma1z1y1ZSZIvJVO75ZRkObQnInBaDh3CdShbjQtEu3oP3LpVII8FYE9vZZM9iW51BWw jy5N5TA7acCfuXR0nHzezoQm07AKbqAnjanp0EdDHXYxrhFhqsawo1SMHpWXSj0qRKF6S4NI1a9/ FaxgVzccnwIvddohYibhJzL/NoYknxciE0I/5KWyFtOsLH0m3sokIZQRcEsGex1c30k1dFopJeRk SUU/wld15tWog4UqR5sa1b92tK67ve1gn7pR13JMrt8Mak4csxyc3tRGxZwXQjuLSR9qcq08FShB 25q7POFvp+07I6Ya+stbGdadOwkubJFq0YQsUqLqxa1tA+vX9b43vrx1KmzPmVT0pre3h2XfRNo5 UZy69ZShS6naqltTvcxRXj2s7FkpF0IkctZ8CiyM3Hj4wLTaDYaeqqtcLqqYcPJVrxYFKm0J+17d tlfFEIlobgm7UacqJK/ojO1+T3xjsw61l8MtbmJNJMDRYbaVYEVONM/WGLxp/1etMS3WhJdMXS5G sn/bzdQjX3s1HxMVr0YVcXpbDF/foripHWavi8uc4nLqeMboje0uV/zmEN/3wyQ2apRf4invVhnA Tkzr3s4lylgduLqXtG4za5Y9AduZkTFJtKKnili67vmu5jwvcAOEyxbHF7cmPrOJeyve2kqnzaNu YKbhrF4Z03nOQA2ucO+M51f3y4Y1XOI/bdfSJqes0GwdrZ5N+925wYnH901npVmdaozC19SexnGo Pb1e4NbSvazNb37La04z55ajdU1vt9s84lavM9aODiNVP+rrOBG5res6tLqQK+FeP9HV4+4veCE9 7MIY+7xe5uWbP11ff3eavv/zjXZUU32SObNR0x3+q6r5Ten//prc/H2rN7UYwlKyW7R5gzKt6e29 DafWqjaWyCIpSuk68/vDYH42y9HMaRc7++Uxx6+307npl0tVxpW+srDxPe9FVzxjHg9pYgZ3PnmL O+ggt7ejGc5Qoo5Y1RWt8bRLDvCZM1Xr0db6im3+9Wo7pLDZxrnD6bzzSUd26aqVuNAfTVxgf3zH wYb12sON8KmjfK99zTpgXR5zwM4X5xC1rWupjmwFCVzbZHbvixuf43tjxJY+bzvQ317vPLuOSnNF 7V2lDePx3tW85c1o360uc9R3/e+7hbHJ2XzwhiT774uPueLr2+kps73yMTH/5OYj3/nTyp27VeW8 z+ou5ockfC5cRqp9Ww9nvwec7IrXNKd1fP3r59Xlj8806G+PafZOfvk9E77Sy21u4we//CPPPNzJ n37YE1vta4//IZUfe+bPPNtWFzyL5Sv92kK8bos/26Otbdu00mM9avu9cUqziaM4yyM+9aM/83Oo Hsuyhgg5BgQ8waKohCuqlKO0z3s8bdu/6Eu96SPB7zM9s/qw/sM6A1Qv74uqA3Q99BOqYgtBDNQ9 +MO89WO/3XO/E3EhKFNBCDS8sFO5czK2MStBFCOzE3S82pO+6iO5Jowo28vCA7wljkrC0gpCIPxB ohu64qPAMDRD97tBu1K0/4UJrDhLEEvbOVZLwMGDwSx0QpwjQQX8vDp8QZnbwin0OzpcuNyTv+B5 unRTQwt8wCEsw/PbwEVMQ7fzPVnTmjWEG5FDNuaLs+djNkxbvRMss9L7Ny4cxSikwlBMQVFUwX0z xAaKtCi5u0oEQyyjuwnEwUmMRElUqPajvHM7iUvipzuCPRoERf6rw2aTwRncP+7Dw+QjRQN8McIr vFGUKF88RQeUQ1ncwQi8lONbHW6sQAjcRXTzKAxLIJPirjZsEyz8Nz8swDCbvVQkxC/zvxFMvmmT xTHERb3SR0p0HItTRG8UyHEkx2u8vC3CIjcBsq4qRdPjOgBEwIh0R2m7rf92hLpcDL2MlDSm+zlx hJKD1EWDDMmBJMhCJElJWkhAU5tI80OKrEhBREBThLn6+sZH3EgSsRqR/EiOrEXIw0n/GsmN0UCg 9Eib3Bo08Zh1bMB3VEXAu71zLMpf5EEyFEquosV97EaNtEqTzMmjNMdriZkdIrCGjMERxMLCqxqp xEiqREihDMcv7EGu7EpcoUtf2kedWSE3IaOGjIx908f3Q0O8LMm5/Me2lMC5/MpGtEt2ssqsop1s fCtEZEutXMzCNMq4rMrEZMzfUExzTEPgY8Q9A8zh00yuhMszdEvF2klIJEzRvMvNHEzMvCB+PEzX fEvUlM2tzMCpXE2s1E3/r2xNsDzJ2BTCoBROyzzN2fRJwQTN3PwxW0ROjypO6uTF0HTM55xFMbyb WDPMykxO2xzO6hzPqxxO4iTH7NTO2vTN61zLgJRO2CRP+YTP98TO5YTO39SwpnPPWaNPR5pPAI24 3gxQ2rxJ/ozKuWvP8ATP75xOAn1QzzzOC0zPA0VQnuxJ9pTLBl0fzsQgCP1Q/6TM2KRQ3szPuiHK DDXREjXPyARRF1XP9dS8RBzKGa1QtUxQDU1RA11QFmXNF91MEqXRHj3P+dtRHUVMH9xOGB1SFf1R SQxSIVXQ0gRJR0TSjlTSJYVAFnXSKR3QWzRSGY3O16zPKM3RMG3SwIzR/9QUzxGF0py6T/0UUxv9 yVf8oSyl0i8tyMwE0z01zzZFU+vEUp3cTx6V0JGsyzzVU+Zszjtl0l6sUh8FSDg9UUIt1EdtHQxF SSKVVEDtUkVdVEcVVAFlVEqd1EGV0w29VJEaUu500wLlU1ANVTVd1U4tx1nlVCm90Bq90sbEUVKd 0EztU1mN1Fat1RkyVk0NzjFVVVwdVhH9ymTdVUt11melVVEdVVhtVtOcU2Ci1ltN0l+tU28l1ji9 Vi4FVmWd000t1nElV3Q1U2FtVy+11nA91xWF1zX9VHaV12DNVwd9V36lU1/9VuOc12PFV+A0VF4N WGbFT4QtVX7t1np9KP9XLVIrndZq1VaGzdiE5VCI3VgLPVNzTciKtdjbTFWD3VeQvUSUJdOBdVaJ JVi4K1kUxViWPdKVFdiW7U9wzdZybVGc1deZrdia3VmgjVedLc+cDVl/ZdCg3U17NVmoRU9Tvddt NVqmjdWl9U6sLbq4m9gH5Vqqrdo0vdiuXVeH3docM9aiFVmw1aJevUxkbdum7deO/U/0iVZsoVt6 9dmCFUOPpViy9VQ8DdGb1VW8TVSwjFmZ/SaxtVearVTEbdhG/UxI9VaV9duhRVaN9dqydVerVc3J 5di03dLLXVm9Tdm/HVm4xaHU7cwOPdy6/devVVu0BVjKJa7H3cWSPdX/XEVahbVZCmLcrX1d2eXd waWl3q3dEondo53d+GTe4nVezg3Ut5Wh3SXQ3MVd0q3c6O3Z6aVez11YzdXd5DXIwCXcqdVaNlVc kI3Q9H1Z0J2l7I3ahy1dPz3d94XfLNJfaT3U843aVy3cz21f6bXd21Va8HHbxqXf5eXS+v3YayEA ChYICiaAG31aBC5f9SVgbgXSABbgyB3OCyaIEv6HC46JFLaHFTbeDVZd743f0e1ex31gJ41g7s1f hrhgAlCIFe7hwvjhF34L/oVd8U1gbE1aceVgAS5gu71bIzbIH6ZgH8ZgFOZhK75iDMbiLN5gF7bT ZW1eWxXdJoZiGl5i/7OdYZ5V4IE44RPWYjiOYzeuYJg9YhzO4TU+2zsu4w7+XzUGY3Ud0jnO4hJ+ YxOmY0NG1T8GZOFl5EYWYz5e5AwGXkQ13DzW4IdA5C4uZCw+ZCtOZNYdYA/W4z124kxd30gO3flF 45OVZCIuYvfhYk+2YFmWYzqG5Ut25VI2ZT9OZd8NZb5lX6elZHmtZVoG4oTgYYSYYiAOZvxtZVf2 ZflFZTPOZejtXztO1zKd5GRu4WWm41m25S6eW8kl5u2V5mymIWd+5lHWZcud5mMeZ07+ZE2m509O Z3Ku3nPd0SFGYl6WYXcOVWGmGh4uCGZuYYQGZTIe6OBFZ1buZ6GNYf9sDmN5/WJtbggqXohxvtqz dehrhugz/ueJpuh2xeXndd9KVlePrmaQ5maGTulHplaLVuIxpl2SztqVbmk3XWeJjlg7Jl6eVuVV 5uOL4AejdkCdNuCbxlyTdunOjVSYFuUndmiLMGqrPmp+mAmrFmlzvOqrFgivdmo8Duk+ZtiZpumn pmZ2VuSVRgivPmpifeuvHte3Lgi5Tgi5zuusrrizHtamFuufvd5dbmvO1Our/s65/ofEphqrVuzG duzFhjy9duu8xuuttgevpmyj7mtZPWugjuixBmzCttW67mWGyGvteGy7dovStuuw3pnKruyPuGzK 1mzL3mzMxm3bvm3/qbVbm45ptM7coS5rGJbghT7g8TLsnnZtfkhtuI4IuWbugZjs237r6lYI2s7t nlFt6Tarx+Zu8D7qv37lI/5stQ5t0f5lVk1iJm6fxY7st+DulGhtyMYU2d7t3Mbtw8bvw65vgpBv jclu7Mbt6dZv3c7vAd/rlxZsG/7g8vbfjUVvf+Zq6H7uAm9uxgBwsI5s5cbvnaBtELfw77bw+kbw BD/w2UZx3k5wD8/urR7hUO7r8Z7wN3XU1j1pls5wAIfvC+9xDldx6s5vBQ9xBT9tiFBtJD/wyzbs vRZwIXfyFT9tFB9xDN/wKi/xn4bw4hbq81bvHp1PatVw/35s/r5r/xZfCCK/7e4O7/3W7DZP8xVn cg8/cRTv8YeQb912cSXf7AYHbhqX6qk2bh1G7iEW8efW8DmP8z0fcijX7O62cwFf8kWXdDM3cUs3 8UanCTG38+mOcu229CS/cjb/84Nt4IcOdC83XZTucwqviMYedSuH7OtOdE8/88uOdVw/8inf9Sbn dVrf6jfPc2EXdbje9Ev/9DKvcr228jZv8UWX8Sxf9bgF36Q2CFhHcCJn9F7f9m1fDDGncu8e9pWI dF8/djhPcP/O9VA/c3PP6nRn9vfmdXLPdHMma+K295oedGpf3AUfXzQf9m7f7f2+dSrHahIXjkan dHan93n/921/9P8d3+xsj3JYh+zoPvYnL3JkX+r0PnVUZ2+lJl9Vf1FKf3hcD2syB/bMZngVF/hn p3U1/28Sp3J2d3N0N2xO13ONr/TxZnKfZ/WAZmtMFWj/FXmZx3CUF3frTvOlb/lZP3HbzvmDP3op 1/bqpm+Lt+6rP/epd2rW9vllB/p6x6CM3nd+l3Z9DqqYUPnDZvqVn/Re3/jtPvhQb5xg13iHt3bU hvdMv2vfAfsO7+0t3+Yv3+GyZ+HD92Y/L+eh/20ZYnuVd3gDR3Z4r/xYava7j+5cv3Onz2x0nxvA D3K5ZV3yzhZvPn1wXm+0Z1Li8nyJv/Kst3y7H/hmR/Cj1/wL13r/jMfumth0Vw993R99YLaITg7u KkbmbzRk5U/94xbupf3opfv9gt952qdtTn/3WK/6hIf9awF+0bdPttUpxdfow1eMFXYL5l/+TWb+ 9q5xL8ZnR9Z+bud8Yr9yT3fyF2cc7+d5ePYvGAeIfwIHEiw40B7ChAoXMkxI4GFDhxAXGqxI8CEB gRgzanz4b6PHjhsvhhRJkkDElCpXUrTo8iXMmDJnxmS5kmZFmzp33pTJ7yfBn/waClVYNCHOpDGF Mm3qtCnPhUOjtlRq1SBVhVcPZu1KEeNLsCc5DgTJ0ezHkmBHlg0pNm1GiSjlet1q9y5er/bu6u3r F6vNowiB4r36//TwU791C1vta1dx17tmybZlCxGjRLr23nL2+BbuP4SYRU8kPdc049Sqc+p9DPm1 1tUEGcqmifg2U9hRa89sHbYkYN067aplCxekwM2lG45WXrmiWLHKT2NuPn16ccqfP/OW7Xur8PDi F6fGjXs8y+41v1sd3dz6a7ydM6LdqLD6RPvXQbuMXvq9WabJ9dx23D13oEYIqeeSY+Ch92Bk64kX XETmQZjSgi+xhxN8Ubn333JVtXcccAUhd52A+mGH4FrZhdbhfflNNteHNE7EH2gFxqVXiTQ16OCF Qdq0oJBF0pahRT82lhWMO5no4kzImSQSdip9iGOL2nmk2XUA2v94GnMyUsaiWyGh2OVymLWFII5w RQikkXHGhuSSclJFJ2tvXhWngRx6NiNaXNFV44B9svkiiChZt+iMZ6pp6JQweingXv79OeZkMYK5 qGt22onnap5GBGpBSirl6VV9WhqpmHJ9iRSZ9GV3ZphgUormphAdOiVotDJUI1mXinSWW9jZ12GP SYn6KamMPdgsnHfy2tuvIQpHnJbcZVrtqyiuyutbmg6aqK8LwYelsM9xKa6AbRo0n4qNmjamssvG CW1h9qoEqqm/UbZuV03OmapxJAYbIK6aGVomsZXdOim341KXrkXcOXpZmrqSie6OINV6H1/6Folv yCLzJNPInbL/JKm1PRE8LLzFedvqaCcROGut8s48Mc8fozZfuewiZams2b7r8cUoqWzysyQvzfS+ Tod6oXW7KkV0lhhrPW+MN9MbHZf49ZyzovG2+nDLk3rp7tENG0wx26dCDaHUe849JL53kxeTqoFW VpLPx4rNcZtqI22s2AFCzK3W5CbN5ZNFswp3xQXXqXd4dduN+ah5N92diFdPNtZnrj5ec9uTU2l4 rtu6rnjajudc5YCETxs5cKM/zTlkmsvNe0MkoyrhhKJbRujOc87HcUTIE8q60M3DJ7itaNMbq80w L58X8MGHlpXwCl7evfjQDh+tnKWu3PPy2ydn/eOBny22xNFL/1/9t2mZZHn2cW9Ofvl85yMA9s5z 6UPfbohHt6RkqX63ElriDmeu+dGMXIwqDn+y1BHSZYt/OCHgwORmPhD+xYD32p2TUBg6ItkkU9B7 YNi21kIKfimDDGtbzA6WrA+SsGTgUyEJUzjCA/7vh0XMnHqo8jwLyg6CMgzhgb6VNfflK4hAxNsR yZen9JjQSD6UFgKDCKEXJuyBUYSS/qBzQ7ZBikIEvCIXw8g7AdaLiOMD4x3F6D3Q8YR1Zyza9XT3 tx3ykGuc+2IC5TjHvCnyc1kU4iP1iMXwwcpfw7Ld25z1GoHBBo4uy2P3KAlCT0YtkpL8JChT5ie/ NVJviDwZKf+hJso3xnKPpjwlhlqJSjr+bpS6LGUqFzlEX94yjsHEZed+mUw+jkd9xCwmMI/pyi4C 8JWQlCYyV1hIPfESSfqqpS17ScthVrObKMvmNcWZSHNac27tnCQ23UlNdAawbvRM5zaNyM7ayFKZ y1SnFud5zyORc6DhrCM396maBdJpQwAF3iwNStBmSTSaDx2OQnlzPg0JCZwmi2hHYdJMf85poxzV jUe1mVHu2VGjjrSiQC/0TmPGs58kdahDV8rSlvKrorAsaEihadF8llOoSKSWSnV60/jElKlJVAxI gzTTXSK0qEa9llI1Z9Ke8tSEUZXpUqFI1IBeFaVZ1SqzgCr/1V8qdatVXWdNmTbVkZ7VaW5taFrL mlRn0lVUKRXrAHsYVqjWVWp39WZeL4rRp0L0r/VULObmWrzCNtWRpDosUvVJWZZK9p+QjexgS1hY uHYWq2oFq173us/FZqhfYw2lY0V7VtcG9oSnZWhqK1lXdJb2o7Gl7Upz+lrUUjSxbyWtToXZWpjm lrCjFW5mvVhZ9PRWtav1qU+r69Td7i2uquSncYfL2qxi96BJgm1zZTvb7n52mukFbnSRm9zyWvek ItNuAbnLXvEe8rfQPed+g0tfwNZ2ssvt6nwTetzGhha+ANYseQes2/Ya2L791a+CC2xVCh/1vZSV 8IQ5bNrN9L5vs/998IZFbFYPfxjEe2nwiUkc4QDHl6ze7WRsTexi/DpXxue1bHp57Ff/0hjFeFTx i6uIYAbh+L0x9rGAi6zAFPOXujm+MoylLNInW/i7UPZdUJ285BqvlcVmvvF20RziBRP3y1AGqxiJ nGEN/zTIcoZwlalK5zK7uc9uzCULMWvkMCO5vkzWcpcJXeg157nCfn40lxHr4C2PedD4bLRn2Yzb RTOazG1+tJ8nPV8hi/rQc7b0pT29aU4nWcynBjWJSw1emjLWtnYOLakjvUU87/nTsP6yrqcG5FkH m6+8VjU8NT1sTJuX2Sv+tZtl7R3OBQQAOw== ------=_NextPart_000_000C_01C75B52.AC12FD40-- 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 l1SEq9IV013085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 07:52: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 l1SEq9rK013084; Wed, 28 Feb 2007 07:52: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 smtp-ft1.fr.colt.net (smtp-ft1.fr.colt.net [213.41.78.210]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SEq7ph013078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 07:52:09 -0700 (MST) (envelope-from jmdesp@free.fr) Received: from [172.30.24.37] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft1.fr.colt.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1SEq0mr010292 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 15:52:02 +0100 Message-ID: <45E5970C.3060306@free.fr> Date: Wed, 28 Feb 2007 15:51:56 +0100 From: Jean-Marc Desperrier <jmdesp@free.fr> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 References: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.com> In-Reply-To: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Michael Myers wrote: > By the way . . . > > http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html > It would be good to have similar CRL/OCSP extensions inside TLS. But that's stuff for the TLS WG. 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 l1SBqq84095624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 04:52: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 l1SBqqDx095623; Wed, 28 Feb 2007 04:52: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1SBqoDB095611 for <ietf-pkix@imc.org>; Wed, 28 Feb 2007 04:52:51 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l1SBpe506532; Wed, 28 Feb 2007 12:51:41 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Wed, 28 Feb 2007 12:51:51 +0100 (MET) Message-ID: <45E56C4D.6070104@edelweb.fr> Date: Wed, 28 Feb 2007 12:49:33 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: Russ Housley <housley@vigilsec.com>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt References: <45DF20F9.2040506@nist.gov> <45E32524.1010104@edelweb.fr> <200702262121.l1QLLg9t001549@spamav2.nist.gov> <45E36A5B.3010402@nist.gov> In-Reply-To: <45E36A5B.3010402@nist.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080909010608010804030301" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms080909010608010804030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David A. Cooper wrote: > > Peter, > > In the case of the URI restrictions, I do not believe that there is a > contradiction with X.509 since I read the text in section 4.2.1.6 of > 3280/3280bis as imposing a restriction on conforming CAs, not on what > relying parties may accept. unless my English is completely broken, I don't see in what way your statement is non-trivial on last half-sentence. I would understand it if you replace 'accept' by 'reject', IMO 3280 is pretty weak distinguishing whether a MUST is for CAs or for relying parties. One indication is for example Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. What are the legacy implementations in the following? CAs or relying parties? Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (section 4.2.1.6 <http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-08#section-4.2.1.6>) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. > > In the case of the emailAddress attribute, specifying in the ASN.1 > that the emailAddress attribute is defined as IA5String (SIZE > (1..ub-emailaddress-length)) and then specify a value for > ub-emailaddress-length of 128, this would seem to impose this > limitation on both conforming CAs and relying parties. Since this > attribute is merely being imported from PKCS #9, which specifies a > maximum length of 255, I do not think that 3280bis should require > relying parties to reject certificates that contain emailAddress > attributes with lengths between 129 and 255 characters. Did I ask that 3280bis should require relying parties to reject something because it imposes restrictions to CAs? I didn't. But that is not the problem. I used the same argument for allowing urn: I don't think that is wide deployment of relying party implementation that rejects a certificate that has a URI with 'urn:'. There may be implementations of CAs taht do not allow to put arbitrary strings into that field. Thus, instead of defining another oethername form for urn, the whole limitations of the URI choice can simply be removed IMO. if 3280 merely reuses the email attribute and "probably?" erroneously limited its size and corrects this, where is the difference in argumentation concerning the URI, i.e. allowing more values? > > If there is a concern about backwards compatibility with clients that > use the ASN.1 from RFC 3280, I would suggest that the solution is to > leave ub-emailaddress-length at 255, but include a statement in > section 4.1.2.6 that says that conforming CAs must not include an > emailAddress attribute with a value that is longer than 128 > characters. [Note that according to RFC 2821, an email address may be > up to 320 characters in length, so even with the PKCS #9 defined > maximum length of 255, some valid email addresses cannot be placed in > the emailAddress attribute.] Since RFC 3280 (and 3280bis) discourages > use of the emailAddress attribute, I would have no problem including > another "roadblock" to its use. Since 3280 has made an error, it must remain so forever? At best I'd say: Although 255 chars are allows CAs may experience problems in relying parties when using more than 128. Why do YOU want to block anything? Is there anything dangerous with the email attribute, anyway, that's another story. > > Dave > > Russ Housley wrote: >> Peter: >> >> If you find this unacceptable, we can assign new module OIDs. >> >> Russ >> >>> Hi, >>> >>> **The ASN.1 modules in appendix A are unchanged from RFC 3280, except >>> that ub-emailaddress-length was changed from 128 to 255 in order to >>> align with PKCS #9 [RFC 2985].** >>> >>> >>> isn't this an incompatible change from 3280? At least one well deployed >>> implementation checks for 128, i.e. openssl. >>> >>> If this is acceptable, can someone explain why we cannot remove the >>> restrictions >>> in the URI choice in order to align with X.509? >>> >>> Peter >> > > > --------------ms080909010608010804030301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI4MTE0OTMzWjAjBgkqhkiG9w0B CQQxFgQUy1i1oeTV94CJb0RWC13sRl6eHeIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAO5bOK6QeWaavse4Q kL4putQQQqqe7AIZgYmvkROtCpus1iYSfKeA4jRnZt/IgtxKUHLItQ5227/qUy+GorGCVVjH m3NrncgBIJvrZUB/Het/4ltNHz1c2gMUk4bQRJ8FLy4FHE5OMkmo2xbG0YkgGPYlyLKsIr0M eO67EXduSHYAAAAAAAA= --------------ms080909010608010804030301-- 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 l1RERUCc083778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 07:27:30 -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 l1RERU1r083777; Tue, 27 Feb 2007 07:27:30 -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 l1RERTbB083771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Tue, 27 Feb 2007 07:27:30 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-221.fastq.com [65.39.92.221]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l1RERPir038024 for <ietf-pkix@imc.org>; Tue, 27 Feb 2007 07:27:28 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "pkix" <ietf-pkix@imc.org> Subject: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2 Date: Tue, 27 Feb 2007 05:50:34 -0800 Message-ID: <CCEJKFKLBCNMONJMIEAMAEOCCFAA.mmyers@fastq.com> 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 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> By the way . . . http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html Mike Received: from 199.Red-88-19-2.staticIP.rima-tde.net (232.Red-88-22-162.staticIP.rima-tde.net [88.22.162.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1R6SWMr044225 for <ietf-pkix-archive@imc.org>; Mon, 26 Feb 2007 23:28:35 -0700 (MST) (envelope-from Rick265@auspi.com) Received: from (HELO ) (ietf-pkix-archive@imc.org@122.187.14.46) by with SMTP; Tue, 27 Feb 2007 07:28:57 +0100 Message-ID: <000901c75a38$7d68b130$00000000@colasbueno> From: "Rick kenneth" <Rick265@auspi.com> To: ietf-pkix-archive@imc.org Subject: Ju showed unmastered amazing Date: Tue, 27 Feb 2007 07:28:27 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C75A40.DF2D1930" 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 ------=_NextPart_000_0005_01C75A40.DF2D1930 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C75A40.DF2D1930" ------=_NextPart_001_0006_01C75A40.DF2D1930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Atwater kent museum spring rsvp, suggested andrea baldeck matter. Astral essence tokens enough, level, place sphinx members? Divas dustin hoffman ewan mcgregor nat. Midtown heartbeats breathing, = first scientists evidence become. Movs, playing, ruby, restarted, pokemon. Exibio animes put creams = frowned. Eku pa kelingwan ilokano manang biday bamini fonts read? Zaphods = memorable circuit clayton. Thul bombay, bangla marrigecom kab running = grain, puisi. Aka natassha anjali hi, everyone here sum eijazs, ild. Desai set, thul = bombay bangla marrigecom kab. Pedosex ku pung singsing atin cu! Quotes example, incorrect flags log modsquot under quotmod centerquot. = Satellit ricevi immagini da? Showed unmastered amazing putting cafe = dekcuf thatll fun anywho. Hoskins maclean chillout albums summertime = northern lights. Chassis cylinder gas mfi vin wire, conductor mm. Ching nicole cherry grove modern! Dec dee zee deflecta, shield. Launches, name lyrics mobile media player. ------=_NextPart_001_0006_01C75A40.DF2D1930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Atwater kent museum spring rsvp, = suggested andrea=20 baldeck matter.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Astral essence tokens enough, level, = place sphinx members?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Divas dustin hoffman ewan mcgregor nat. = Midtown=20 heartbeats breathing, first scientists evidence become.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Movs, playing, ruby, restarted, = pokemon. Exibio=20 animes put creams frowned.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Eku pa kelingwan ilokano manang biday = bamini fonts=20 read? Zaphods memorable circuit clayton. Thul bombay, bangla marrigecom = kab=20 running grain, puisi.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Aka natassha anjali hi, everyone here = sum eijazs,=20 ild. Desai set, thul bombay bangla marrigecom kab.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Pedosex ku pung singsing atin = cu!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Quotes example, incorrect flags log = modsquot under=20 quotmod centerquot. Satellit ricevi immagini da? Showed unmastered = amazing=20 putting cafe dekcuf thatll fun anywho. Hoskins maclean chillout albums=20 summertime northern lights.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Chassis cylinder gas mfi vin wire, = conductor mm.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Ching nicole cherry grove modern! Dec = dee zee=20 deflecta, shield.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Launches, name lyrics mobile media=20 player.</FONT></DIV> <DIV><IMG alt=3D"" hspace=3D0 = src=3D"cid:000401c75a38$7d68b130$00000000@colasbueno"=20 align=3Dbaseline border=3D0></DIV></BODY></HTML> ------=_NextPart_001_0006_01C75A40.DF2D1930-- ------=_NextPart_000_0005_01C75A40.DF2D1930 Content-Type: image/gif; name="Equigen Line.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c75a38$7d68b130$00000000@colasbueno> R0lGODlh6AFsAYcAAAAAAHsAAA2KAIJ+AAAAhIgAewB0iMXHuL3SyKi+5z8SAGYbAYgcAKkTALUe CdwuAAw9AB42AD04AGYyC3E1AK40ALg2DNhAAAxfACphA0FiAGZaAItgB6xhALxWCdFaAAt6ABeK CTJ9BWJ4B4GBCq6IBM5xANx/CACWACWpDDeXC2ufAHicBaWgALKiC9SlAQC+CxS4ADjKAF/JBniy AJe1CbTEAOm4AAnYABXgADrYAVTgCIraAaTsA8fsAOTdAQAJNiEIQz0ANmUAO4EAPJYBP8AAQOgJ MwohPhIhMz8eN1wjRYspS6chTL8aTeMqOAA4RRoxQDtBPmVNNHFGMZNLTMFAPNEzNwBnPxxqNTZc Q25uQ4JlAKtZQ8xYNdRqQgCBOBh/Pz18N1eHNHmNNJ16TL99Tu6LOwCcQyyXSTiSRVmVR3KsNZ+l RsWYPNusNwm6PSXBSUzGN1eyRIS+SaC4TsfCOue/OQDuOCbYSTPgO1XVM3HROpXnSsfaSOjjTgAA hxMAij4NhFQAhXELhJILd7UAiNMKewAXjioRgzIdgGYtd4gojpMsfcYgitMtgAA3cyVDczY7cWJC f4ZJjKY3gbtFduROiA5liCdqdkZfh2JnhoxjiKdog7Nke9tdhQCNcSqDczSCi2txdXeKdKOLhLKG gOt1ggCYgyyaeTWXc2uYinGac52rfsKkdu6lfAXCcirJhkK4hmjNdXPGcpHJdbu/hti6iQHRex/s fjrZi1ntjoXfeKXfisHadOvgiQAAzRgFtzgCx2QKzoQAu6gAwrUJwtMAuQUavyQrsToYxVMju3kY tZMixrYlw94fuAg0siI+s0VKx2A+w4s/wpExv7dFwOs5tgBqtB1TtkhTy1pbuoRhuqRdzshoxOZr wwWGxSyHuURxx1N0tXmGyKB8v8iIt9eNvQemvxGltzOjxmaUunKVt5yjx7iTwdmbygzFuRrDuDe6 zmy3u4DDwp/Kuf//+aeroXSAdf8AAAb4Cv//AAkC//AF9ADw///x/yH5BADaycQALAAAAADoAWwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixokWE/zJq3Mixo8ePIEOKHEmypMmTKFOqXInyosuX MGPKnEmzps2bOHPq3MmTpc+fQIMKHUq0qNGjSJMqXcoUKc+nUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2LMymaNOqXcuWpNm3cOPKnUu3rt27ePPq3Ruxrd+/gEfyHUy4sOHDiBMrlhu4sePHkIUunmw1 suXLgClr3jwRs+fPoEOLHk16JefTF0urXs26tevXsIOink0ztu3buHPr3s27t+/fwEHTHk68uPHj yJOnDs6co/LnyJtLFwyd7PTr2ENX354wu/fp3Il//x9Pvrz58+hxz0zPvr17omKdh59Pv/7Dovbz r39vMiz//5fpl9hnAhYIlXpgESiTUgY2CJ1wMUE4EIAUulabZ/thlmFGDm6HX4QKnoXhgkl1yNeH IGpIooopamdiZZl1F+JLM9JY4Y04vrdijjxmJ9F5G/YoGUFCBtgicFMVqWRsQf5W1pKQFYRjk75N BqVsO/5jI4siBmfllUBlGSaVLJHJ25dglimmT2aq2aWXi6X505ps0onlcsyheadAU9qpUpt/Hokk anW+OaigcyJaqKGJ+pnSiz295uijk54EaIyQDlajS/BVammEAgiQUaikkvpPqaiKeqqqo2VK1aae hv8Ua0kzhbqRqRqleiurto7K6ke97nqdfhIOOFStq6IaEq67/srsqrnyyquwy/7qa7H27IkYrIWh uGWyzOrqq7LQRmutuc6GK2qw7Eo7KkfBAntuvEMyOuZX2HLllk4e1Trvuqk+S2q21xbcbsHwWksv us26ezDCttIbsML/ajlrS11xm5W3GS+8cLnCDkxQqAWRfNDA0YacLsjUtqzytQc/DHKpFg9kckI3 2ywAwcce+a1l8fWcILo0g8SsPSLrfPLOJe9cNMJQpywztPFGrDDLUcOsqtVK32xyzqXymXK1Hdl6 KcZiR+Zfp1+Ra3TVqSr9UNJIJ4111lbPTLFHeUP/3bfWqAqUs+BMN03411u7C+7eZsuNc+FKc0yf 5Fu53azLtzq+NOReFz64QiSbTLXiCZcNsN6lm476tXXLPTje55ZbNOKBt2474YeP/XbsNdu7qFds 4zt7xROvqvnhI0Nu89xOe+687iP9LX3sHp8u+96q4yru4qRzePvxuIdfN8SJm6u77Z8b3jRpP9/r VcWm/yuq+HS3nn7nhuOvfkOhP0/+9tlTXK8+Vj3USQx+xvse+BQYtY9lTUv9yx/nmHYzwFnubg7s TVgClrADpkt596Nb2OgnwuYt7XgRFJ/OeBdA3a2sJNOTGvWIN8HBfY6Dd8shyzRXvwWOrnQH1KHa /3b0PripznzRSt4EDVJCsCnvcDV0XtekGELo/fCBF2yhwV4YPQF+cIbO6V/DUkdG+z1RgSq0WhYx 56KheQ9PJ7lgE/dXtyUm7453xJ/+JIg7kpHPgBwcIA2teES+efFZQuzg8MYYP9MpsH42hNwVydiw DDpmbULj2e8YkjSw3W6EJPzkE/fYx+dNTYZac2H5JlnJQgqyi/IilyC7J5KDPTJ93/NjATFnySi5 sY1PwaUZp+i4FI6PjEF82CuPuMg/ppKAqyTaMslmSGoFC31nZCIIrcdGaYoGk0ZSlJv4l03CAVKV q2tZMkn3N2tqj51fzOHUlEnABd7ydhZ8Gi9Z2P8YcIazfY3ynbzIRs8/njKdq4MbNNHpzHEBbIZ4 jCQaAUhJVgbvIGjD14jE2c9ZWdKLqEwoAhXaTIdWU17F3KYJtcnHPMZNk9o6jMYoIqe37a6k4HLo Oymp0LFF8oy4pB0FR9m8uPGTUoqhXENAcjFJNXUoGSwow5zpRDve84ZAzWYvkcqdjYgFEmANK0fA eht/riWqLV3hVV+6wqEaTqkV6ZerFBJWsW6krpC4a17HuteM2PUfZG3LXDdHTJeyVKIX5VRiw+PX wDYWr3/1SF8Bu9e/2tWxGsEsZTM7WZHoiUvME9lWMwrQcdaHr5Alq2Y3y9nOcnYkYE1IbAkSW9b/ 6tUgs53tXWZK00yW1rTzwexqVZva1fL1uMilrD10S1tIMIS5zT1IbKG7XOcWJLfWlYqPMrbYbt0p spStq0jEelnXana1ss2uQKir2+mqdyDUve57o4tb57J3vtiFiJAuVC9jEQWvIUktavU6WeOG13v5 la+CHQLd+8LXvvOt7kLaW1cJ19fCze1IYA1MnsH25b8C1nBx++pY8L62tbd98EMc7GD6Eukj5x0x ZzHsYoTUVq+2xfFwzVtZ17bmbP2ZUEy3UhQehxfAkMXxSXa84AvXmMIrVu9rd5xcjaS3ySpe74mV DBIqG5e4Iq7yX4AsWLMaRbytNbCXfVzivdK4/yHslW6EW1zdLcN2siqm83rn2+XOUvnIJuZwY8Oc Y9b++bF2po5AL9miRatEuHlNMmoFDelEN/bC8YXyniPSYDZ7mtDK3fSewyrnF2/20IMuSYwJ3WZQ 97nAPSbxhnmMVywzhLcnWnJ50zxlWXOZrDbObnydHN1MC9u6gDaxmI1d6iZr2sVcrpl76yvmAPvZ yIBdto8nXeHmkvrBtd42o3/Z3R+hpNWPtW6CMTzsZr852MVNNphT/e4Jv5fZxM4yu/E7ZykbGtuW 7nO1iWvrdksJ11UBD6fVi90EPzu+MIb1nTHdb1FbnMH3rni+LV7paEf72zS+saWvXONNCzowZv+G k1SY2/AepzrH6HX3qCN8cZP3G+Q1f27Grx3xKrP85/CGb327bWuYui9tpiG3k2ril46rG8Kivq/B 6011Fmv85+emNbiD7e2uexvncj45aWXaHDLTyipAbzm4Dc52mtd7zZL19aUhEudap9fu8IWrpsrO 0UDppdNqj7rbJdzzwvOV4jJvOdG5bhC95zpPT2Vq5CVfFcDHWu6FxjHj9735PKf2zSIfMmXONPmP lF6u/F1LjCl8bPo+e+jHBjttHf/hsT8J4fcpd2/7C7w3RgXwT874zLNL+9qLXiu4zz3vFevbwS6e 8M2H4/GxknyHlPnWuq+OlX+b9L7bnsgb5b7/bgRU/IRnH0agZb7KT3t+4/+Tu7mRflpk9P2utl/5 9Vq+vvjuaK56eCHlh3+H0n8I4n2f8n9LFX0WIR1C1icGeIAIKH+y8oC2ETThp37Tp32elRcM6EYE CIHiV38ecn9Jwn+fBVwSuEmMRYLaZYLs1zsp2H32wYItCHkReIMLSIMH4oI4eHBGkR86uIM22ION p4AYqILIF4T7BxtEiBFKSH8ZeBUBaBgd1YRFqH85aIRZOERA+IQvMoXYp4WdUX3GAYZzZYYAKIbm poZjGIV64YUY1REriIVxBYc+SIe7l37gx4YCeHRkx4c5YXqnJx8UeHZdolGAaH2JaBdoOBeN/+iE i8iIdmhqePh4bsiBk0iJfriEeriFm+hdkUgXfpGAoRgppQiJhbgvSXWKcdGBSoeEdViJGsiKcOGK vUeLd3iJfRhQ8CeLyTGEgriGvqhfuJiLn5iEw/iLNeV3HxhkzWiIg+gUXbiM/heDMhiCIMhdVmiM FSJ/Zqdoz6iKcZKMu7VfrwiLbUiOduEAZBgV5oiI6hiGuliOQuEA9viNE5iK6JFy13iEvPiHWGKP AukAB3GPAmGQUmKPQ0KNIiiFmdiA8yiJ0TeQCIl9CpkRF7kRF5mRHcGRddIjFhiR8iiSoig0CHmS BFkQFJmSHcmOGuGRIpGRMKmQMLl9FWmN8f93jiiYetlIhWxDkQ0xkA0oky75DzNZlDVZk7SCkgYh lDKilBhzgZxIko6YjyUYk0W5gQsBlAe5ki5JlCSRlF8pkBiZlWX5kuzYlCnZGSvpEWQ5ElBZjaBI lYzxkEhnEmIpkARhkDcJhR8BlhqZlVCplBw5EHypl/bQl0zplhSJEnFplG8piH05hjrZjz4Zj2lo FI0Jg4a5liqJlqAJmSWxmYHJERyZkYnpmSqpmp1JiTRJlnkZmVjZH5O5lwRZmwTzmBU4jsUIkUEx lgPJmK+JlGMZmi35l6bJjl4ZnGX5loiplqtpmxOim4z5l84pm6CJmlvJmt3xmBtpllaGmzf/+IiQ OBTDiZ2b2ZaiaZylCZnEuZ5wCZ6QGZ2p2ZUpeY9MiZs3eZqCKZ/x6VWdeZiTeZh3CZ8Gyp4cIp71 2ZUIoaC5x5uY6ZdAwZzq2ZyAeZYXCpZHGZbAOZYLup0NqpoE+qH4uZYlChIeyZ/hyZ0MUZGB+Z1i CZoFyZXQeRPU2ZMbY5dG5xPDiaDuGZno2Z9nOaQqCpgxapMsSp9OWaJByaL32J7fmZ1tqZ8i6pkI OaTwSZhZSZ8MOqPSGY0vCabSqI9YqZykmaFmCpw+aqTgeaRSuqIkep/cWZFy6pQ1yqSvyaHW2Tsj mp+sGZcXiqUBSqdz+pz4qJUucaM4Sn2e/3GdoYmmROqoyfmoafmlXMqghJqadjqgpDmpx7meQumg H3qpi6mh76mgNNqaTNebvnmMsZgjURqpFhqp9imnNbqgJSqgiLmft7mWopmnPmqgIeqluLqrJlqo CbGSq/mcupqknuiqwkiX/BIYAFCt1aoU1/oP1mqtGZGt2aqtANCSXVqstdqlBMqky8qs3mmmk4qa 6MqUt6qq4/qlKHmshnqpKimmvoeNzuhffvGt3wqu4dqt2yqwBFuwB2sP1aqwC8uwDvuwEKuqytqa oXqskbqhKgqivBqn4wqv9Umntcqp6KqpESGeOkqehPIXAbsRDduyC2utDguzESsQLwsAA//hsg2r EFGaotdJlOZ6r+Q6r/M6ohybmOxJlD0LtDhZncHIr/26jTv6jwqRswSRsy5LszYbs1k7s9wKsAOL sCHRp1ZqrPBar7d6rknLn0HqrNEKrcMahxGaKT84FVR7s1kLrgSbt3jrtQlbs3aLtXVLrB67pOrK rs35qRgqqsQYt+UprSbyHiurtw97tVr7tzgLsVa7tVirloaLpSranPrKmUu7qD04LHSruX+7uZOb tX67uTiLt3oLuxqxsmzbtuiYjo5rjPNhi4pVFZm7urP7tcIrsNyasA0RuHDLuFc4t6P7tL2IqBJa JaGLj9s6sAILEcjbqh4RuU3rtExSmf//Ebr50ryxi3pTi7rRq0Hgyx+HSo3Yi76aCCQjKYPvGI4M KbrPer8/phAoR6bmwZP6+7/+S3n2K8ADbHoB/L0HLIfiy4P5GyUJXBInMMEUvJOviinxeyPtyxpR +xv8wA9BMcEaIcIcQcEV7BETTBApfJURDI3e28Jq8cEmIcMgYcIdIcICscL2oMMDocM83MMnsMCE yL/OuH4vzJAb/BM0nI8fvBA/nMNBvMMUDMUG4cNRXBAknLumOG4FDMOm8RcfHMYgPMQL0cQOYcb2 gMZAfBAp/A827MYncMNxnBFZ7FUm/MSYyKod7MXjyxNqrMZpzA8CIcaCHMaDTMgDQchj/7zESzzC c1zCcSzFKYzHd4zHbHzF5qfHe8zHecKCgHzIh5wRYfwPoyzDo0zKIMzIghzITozJWDzFkuzKVGzJ l5yHbut+nGy6ETIrjawRNLzKrBzMTfzHhQzMZvzJr4wQJgzFlBzFeAzHG1HHpGu7ucy75Ht9Z6zI iWzIoCzMxbzNwezNrazMJ/zGkOzIDFzJF1zN1nzNCjwRx8zN4szKaDzMxrzIY4zKcvwRsEzFtbzG GczORuyPGlwR8ZzP+pzQppzPC+3L4NzNQGzJjyzQRFyAR2whITkSjazKBBHPoKzNh9zL1ZzE5quI 3UvQpAeP6gjSoTwUivzS7jG962vR2/9C0hvx0jid04rczg9smXXpVDNodjot0tIrxGQMkEBDLJq8 yTOM0O/nzuDIFdlry1w4g3aJv+vsS0a9fWSBvqhLtZqrrVI5h8qLE1hN1bdLzRYcE/BbEG1dvQnh 1UVYvAfLst161xxhvbesHDpKfn3N1jJLswths18t1rPbEXRtsCCh13iN118rH239IH89IDZ91GWx rQeB2UgnvIl92IZ92HrN2J5t1wyssAahuaxr2pntr1rMGSirFVMNEzm72KQ92mId2rcdEo9t17i9 vYhd2qpdtW5N2KrLJ6LN1Sy818rowDtBudyIEgEbub1t2+GK29VN241919Vb2nJ9h6L/fdy5/dnB DdWvncdIMoXVG9gFutjgjdjb7d7F+97SXdvZfd2ezb2Nzdj2LRLfDdzd7daCHdyfXdXbItA+gd+c 7bUIe63pXd3Wi9/BW74fMd31fdt03dn5ndcDvtinvbz9/duG/eBLPdMx3cDQHdoYvrcPPrzx7eAR rtvDy9/0fbDeOtq7Xdv6veETDuL5veBgO+DRDaEO2MUEfNHRjeAurrcMvuKyy73pLeG+bds8XuE6 Pt03PuE+Ht9nbYk5YuK4ceR5vd18q+IRPuYsy+Sym+ZU/uGx+95TXrxkdrxePoAXXSRg/uJkruRJ nucY7q1+fubbe+HBG9qrHdfpu9YR/2Gz9VvnHDznJXHnep7kLd7kCe7kbs6tVNLe2Q2gW43caN2J n57SRO4ZkE7jfu7jlH7akZ2ZEdrWJzvWPb0bjh4bd94kEA69KO3Toc7FuT5+s47oaq3rux4ocD3s chnr/dvpwNTryc7oJ03eVunswC3tDOKQq1HZYzrqS5HRyk2Kog7AWq3t1a7sfZzVaY3LRU3t456j 2c7sNO3u0xzsvq7su1jSU9nt3k7n0F7k8L6bwh1XPy7sXC61yJ6T9P7rjyEm+t3nYv7vhFHe8v5N Mi3upbEfDc7eBAzXqA3gHB/g7F7WN1HuuIvv83vub0i8t76BsV21qy7Ykf3VHX6zq//KjM9L4P0u jurO6av46E8OoL9bEcir2cUeuMSNEF8t9A6/d9ce8Q3J9M47VysfsThLuUTv1ax79Syf2Vbf8kXv 8R+vJPv+7PbHglEP1la/uqqu8Wd/vEE/tePd8mY97dqrv1AL28Uu3Gav6oALv0Ef2FEf4P+92hu/ h11e93Of8BRRs869ukKv3qlr9Fgv56Y9+Kkt8wz796xe+IYP8etN8Gyv9Vn/85o93HqP9o9vt37v 96h/t4t+7zqPF5wP7p7PEH2fupdb3MM99Oots7M94zrCjzRf8yb/KtX387m/+3cfuNia7uqX83LP qCNO8ezzvo7f+SOR8ktH7u1Y0SD/bxMi7/Sqgf1JLf3T7/z76vqIf/AID+NMge1LAvxVaP6xb/3x L/+tj/68fvN0r/33j4xPDRD2BA4kWNCgwH8JFS5k2NDhQ4gRJU58eNDiRYwZNW7kOJDiR5AhRX7M l2/kSZQVO65kiTDlS4ctMcKkWfOjTJw5dRa02dPnz4clHQpNWNIoUaD/di6d6ZMpwaRRYT6lClXq VaxZGR5F2rBrRK4m/x1V+HVhVbT2nFbV2lZiWqo/2bqla9PsWLET7zK0d/RgyYGA4T492bLuYYWD CfdEi9jx0LB5f94VXNBv38uVCV62nC8wV8VqH4+eGlqn3LikVYOVTLL1RIFhY2fm/zzboGDcnj9b NPpX9+3fLlcPp2j69NrUxKOmFUl26EXNmHtLB1y5+u/cvkFHx6yxrNGtr4u2NqgcuXHD55eaZx8T fUbrurnv5u15enfb8W0Dh4x079n8gpsPP4/aU+q99Biby0AGGZRJv74wGrC7yvD6Di+uxoNMQvmC s+jCrvzL6z+aEGTqpcYaVLEmE9HTzLmgWgvLwoQIvM4337wSi6gQxcMQvPGcyxDAFotMcUUkUzJy o9V6nJBAG+37jUbwRNRQxxl/XAjIrzbzcEkwO0pyzJHCRBCoBwUEMsYtdxTKrCyHDJKvwZ40cycy 87zpTj7DPOkrEq/8jiyicOxzsf+QBtPTwEMbdXSlkbLEyzg70UMN0UUfe3TT0NRrtFKcQMPJUzwz 1ZRTVJkzVSSmQGXp0hNXPRVTOlMF00FblwIM1lhl/aiGGiYC1tRcaVWOUxWP9LWtYZsN9qFh3Sq2 V/amLZXXa5clDVhuo43IWWGfhchaE+si9zht003IW+LYZdchYO2JN6N532voUGzPFbM9uNQ9CdyR 3mX1oHrlrYHeg+Odt9uDDWa4PFJVLVNfmfy1mCGBX+pWpIwjKqjgpwpeuGGBFA4WXG+dFfddilu+ 6GKYf+oYWnFpHtcikDUauduSuR3o4Z5pZlghd09O+GiDDRKZZJfvjPmqVEPitqH/qUGauUaCcv6Y 6Y+zfrhenn8GuOh1n62aaK7F9rrntU1O2uG11VZszxaflkrZ0vCWaGO0h+1I66zFDltpkhmuOmWj y1b8H8TZdpxtwHHm2m21Ua758MvFLdAmve1mcUHOmxac6cGB/rrhpc++mvGVG1866cjlBpt0pA+y eSGAFbec6sTR5jXfl4lNLvTh816ScrdZ91313hd/O/a3o4ed9ukl5xtx3Jun6N3cld8de7LvBt28 zlEsvkRUpe4dXMKlHzx6n6UnuHDalV9ee98Xx/5+9bNfnPXEje16mbvX+I51PuNRC30IRImZdoY6 +vEsdVs72/9uZz/dEbB7FoxW//g6WDMLZm9ofdsY9PwUsZygcFQqTBD5wvRAtmGwe3wLYf4gsj/9 mU2AGewbCcuGQ7RFTUEMVBIRG2hAz9UFhzPUXu48CELe2VCGQ0NcFU14Kxa+CngrJJ6xYCbEX0GR hz/EoP32V7SMDZBIj9oiF+2GxIuVT08d+yAVCfi/+CFriF6MY7mWBcci6jGMNktfFiGVRDBWC5CF WaRqErlAPlqskPxq5MQiSZpctbGFiqxYAQXJyUtaMpRJdGQlZyU67zDKlIkyIikH9sgDojKVqhzl K2vpSlweRpZM2qNwjthKW84tl6dkoyFlqUktHmg9xjTSMD93S8fscpZdVGC6Ov/lzAQu03OwNB8w tSVHbBZnlYjxJiOhSbdqfnGc4XTPOXUpzYwwkyOkBCc7PbZOc8GTYvTEp/Cm+ZZyklOfH7LnavpJ l3mK85MuHCjEGFrP0UCUmA09ZD4pahVaZiuj6RzORW21Ro/iKqAA5SZxPHpSconUnbDhaMxQ+tJM qlSb1Jzp02B605ciM5nPXClJcfpToJ6QphqFZE2LGlSkJtU0Ot1XL43azYsuR6lOAylVh4ounrb0 lydt0FTdeFSiZhOrWX1qILkKSq9uEqwplCcvr8pWp1K0oOYsZlzHKta74vWrax0oP3NqV7i+tZOA 3StUQ4rIg7ZToqzs6T1HytL/x0L2rNuMrE/zStawmlWrdC2rZqOK2MrezFFISqxoG6sSlPr1tKiV a1IWi87NitKojVJtZ7ea1ma29Z96LaxhMyvJ0ioWt26lZGhNa1vOIteaxmXtcOM5V9kql7GrJdNr Ferc3ZoUpkxNKGWZK1zsEnSjfCJtcKt7TYECVabhtRRo6yrYii00lpPl7WWBK1/f/va2+j0JABQC AAD/N8Ag2S5hK+rKScJ3p5i1L0wA7F8BPxjCCXlwhAfy4AsD+Ji6bYp7R8vhDjM4sDUZMIUrHGGH SBgAGV6xQDBsjxfDWMMunnGMZdziInG3uyJmL0YVfGAeq5XEJWaIion8DyPj/1jFLD7IkmncYhvH +MUSvjFBbJxdz/I3ulZF03c9Sd1agbnIEh7zhE+M5BI/uckzrrKa3ezkNhfEyGq+cpsxrGI0TzjP 05Uun/u6Iutet88pObOJiVxhKSdayWyOMpWtzGYau5nJc47zo8m850IbWtMB1nCjcUzcIDtXfGKu qpZDcmYjPyTJ/jXIleF8Z0jHeco1jjWcKy1nSG+a0xDOtK5XDOtPv7nTv740ignc46UC2ryqXjWe F3JiR9s51pJ2dbRvzOhhB1vaxAY2VHb97CODW890zvatye1fRIcb1WS2tbmR3duOepnZxc6znjPd akhXe9FQzre2ZX1kZxsa2v+71rOmMY1uhNu73JLG96d9beI9N2TgVK6zorNd62l7Vcc59kmzE77q As5639j2t6VNfvIbG1wi6y74t1E84HRrW+QyprmnI35zPBf63E+u87+7jeuRr7jezW3ZxrG8qiQr pedAz4ineb5vnpRZ3FI3eK9TDPMAm1zRVQa2xEucc3rXe+tan/bPr+3vF4td5TcfutLLnnF7GVjI mDzU1peO8jUX/OCXtvrUjf13i5f86RieOsshHvOGs/jiwSY5w7me64lHONxsL3bkpe54dwdP7kB+ 6Ih1W222zzsivY45mteuTCYrPsksLvPkcR74xp+d2/i29OItDfhDY93MX8///eQLTe9Ue13voV7w fPs0nL6H/urDtzDTu31l4fsd9yXvudN9Tm2KA7z3u8/9mKVveNP/ve1UB7Hm0frhZSXf40y/COkJ fvgjJz7181969fvNa97jn/vvF3j0T699hQu4/is/8To/fOk8MLm75BM/4Us8kbs7htM31gu/01s7 3vM+yos5Afy+3iNA2xkv2gLBAwQJliM4jYDAilu4s4s66Qs98LM8/4u4TCs9ycuzprIsU/Oz4ksw BMQtCYRAzPO2Dny9BczAlss//VO/pIOo4suvhuqqd2OKH3S9FhQ9IhQ35hO/GdS9ZYOa5NiU9XqK QxhDexjDQyAIMxyINCwp/8T4Pf4bPSrEwiEcwMToQqmStzrEQ9cKjTW8iD78QzJcQzM8QzUkQzZs w/wTuw1cwEBDKDvMw+O7w8EYxDMcRDQ0RD/ERIsAREIUxEDsQ4EARTBUjqRDvUFLr9gKphD0wIOg xIJwxULcCE/kRIyAxUzsxDScRUt8RU2UmOIitT3UQ1NEPwO8RFG0xTL8REJMxko0xF68xVDcRWas RWncRGVUxmisxkJcRl8ivqOzKWEcxhEEpVykREs0x2c0iHJ0Rmycxmx8R0/kCF1kR25Ux2bMiHJM xn8ww4SgxIfgx1Jrrc3jPCeMxPYQRXc0xms0xoTkxWVERmpsxodsR3dcx/9k7IhZvMiGFI1+HMN9 9EiI4EePtEVzbMV0XMUuC0ceND50REiF/MhDYAiXnMdt3MiaVEhZpEiLfMdpzMcPlEmQFMmRBElI 3MlbvMaJhEibJEYoHEUDaUltXEdzVAiA/AiAjEaFrMeKhEWjdEh71EqTlMiarEqAFEqzJMqw5EmK /EptZEuJxESp9MpDrC8zYRCpLEmGvMSOjEmqJMq9hMm9TEqMPMltfMZ5jMmePEmErMqQNMu+jEla zEakXEq1pEeXTMjLlMy3FExmBEv0KkimVI5dhErD9MfHnAjGBEq+/MuFMEqy9Mic5MZ/hMzVPE3A dEzSBEzV1IiMhEe4VEz/sczM3uxMz4xMa/xNbuREzvQxg1IUkcrMpQxKv9TN2axN22zM1LxO6vzL 11zN7KxOiXDM1pRO2gxO4NTK7xxP7yRKs7xJe0xMz9zKpAROXsRH5FRP9eTL9ISuYztGpDxJ7WyI 7HxN1YyI79zPwLRO7UxN8fzI/JxKAfVLaexK+dTM8gRPoLTP5EROzExHeqTMCi3MqGPQ6SxQ7zoU vGTN0yzL/WzRQcRPAy1RGDXRxnRQh2BMEr3Qj5RL3oRL6kRHE71KV7zMxYzPjYxMCo1F+OxGmBzK 2nxR/jQVFl1P62xQF1XQx5RQGZ3RG2VPJwVS7pxOnhxT3zTNAMXOsxhO/1BU03M8z/qExq90xwSd zQeNUnbC0QYNUypFUzrVUv3E0OpcU8JcUqvA0yp1UsDMyx6VzSldUPLESSJFzjPETgg1Uzu91JAY UETFz+7k0wjV0QQtTSPtQy79VCitQ0Gtx508VQSl0a1808okxMBs0qlsSUhkQUx1KWECCU0FVT1V USKJVLHkxe0sVld1zzglU2DNUd00TcZc1GwE1mZ90at8xFy1KM97jF490v/0zDMNVSxVCv8cVUws 1RntVRpt1DnNTUptxGttzvAqUl+9zU31pJnk0PJgVk81174Eyk811U6lSmt917aIQvOjiG0d1xBl wQP1Uv3cUxrtUizNTf99FcccJNh4M1gvHEz0fNhD1dFT/dcI9ddpldgYXc25xFi+Mlj8Ck8/vU51 bdJApdbpnFIjTSmV1UGWXbbP5FXyVE1W9dPaDKqclaydbcIohVCLfbeiDUimDUOk/bHwalqsOVom 1a5xTEn6KlqrvVqsfa9iJC+qXdqn/cXQ1NVwtNPhglqDDFuxHduBvMEwW5KmBFvjO0W4fSdgTC6H ctu6ZNvBklq69TC8nauUnaiLFTQuQ7CBBVyvPS6U7MEG41uNZUVcRdutlVx426+utVt1+iu/nTvO 7dzIxdy68lzQFN3RJd3NhS13lZaWzbJs1dqopVzWbV1VVF3NXdyVDVz/cLzdwsVBoQpGp/RGuTVd 4MXd3G3b1UVd2VXeP6ok9rLcXYXXfqHezXkjlQRdweU4sz2sE03FY0Oq5+Xdu/0s7d3e5M3a82Ve rrXWR2JZx/3b7i3AZBnYlaRLLErbuPXe+k22URPf8XXe5qXf9C3e3jXg30Vg/cWi8C3dBs4twmXf CPbfBd4n16Xgr/Vd2k1cxdXg+1rf2bVe8xVB981bokuq+XUZrMhfFLZdfapbEVbgFy5feFrhGY67 Gk5d3YXc6/3eHN4wqsXfxu3fIHZOGw7eRXndFJ7ciDri4S2l6t1dDq7gb+RbHobinl2uKU5ggszi Ly5gLbaW2uphK77i/+UdYTEe45h6YA/+sh/+3xAzXjZ24RBW4iWG3zoGtQweXFlh4h2+Vfkd4IP1 Yj+mKTA+3kBO47INXQeWYx1u2jdm5BvGYQmmYwtW2T3eMSqOYkO+5Pfd5Dlu38MFr0me27EtsCQ+ 5YLt2kVOZNHB3jjGZNx65TUWYkie5Q4eZFumZGkyujOBZWTrZRiu5FxuLzcGYWIm5NplZgD25UdW F5xdZl/p3DJuZmo2XGueYDX+YEDO5lXGrmt2YtjdYnAuZvLlZuhFxSo+Z2xVqm8q4mP+SXfWClEu 570F5lGu540VZXqm5X3eYFa2ZzuWYn/uW4AOaBLG46y4KVnWYnzO3h1OxmbEVWaDPuguftfHXWiL lmaMRmh+DuCzXZaAAAA7 ------=_NextPart_000_0005_01C75A40.DF2D1930-- 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 l1R0P1m2015817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 17:25: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 l1R0P1ss015816; Mon, 26 Feb 2007 17:25: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 anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1R0OxtT015804 for <ietf-pkix@imc.org>; Mon, 26 Feb 2007 17:25:00 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1HLq9I-0003CW-KD for ietf-pkix@imc.org; Tue, 27 Feb 2007 00:24:56 +0000 Message-ID: <45E37A72.900@drh-consultancy.demon.co.uk> Date: Tue, 27 Feb 2007 00:25:22 +0000 From: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt References: <45DF20F9.2040506@nist.gov> <45E32524.1010104@edelweb.fr> In-Reply-To: <45E32524.1010104@edelweb.fr> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter Sylvester wrote: > > **The ASN.1 modules in appendix A are unchanged from RFC 3280, except > that ub-emailaddress-length was changed from 128 to 255 in order to > align with PKCS #9 [RFC 2985].** > > isn't this an incompatible change from 3280? At least one well deployed > implementation checks for 128, i.e. openssl. > Note that the OpenSSL will not reject a certificate with a longer emailAddress but it will refuse to create a certificate with an emailAddress larger than 128. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. 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 l1QNkokE013200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 16:46: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 l1QNko8h013199; Mon, 26 Feb 2007 16:46:50 -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 relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1QNkmMa013193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Mon, 26 Feb 2007 16:46:50 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 35C3532129; Mon, 26 Feb 2007 23:46:46 +0000 (GMT) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l1QNkfEJ000763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Feb 2007 23:46:42 GMT Message-ID: <45E371AC.8080103@cs.tcd.ie> Date: Mon, 26 Feb 2007 23:47:56 +0000 From: Stephen Farrell <stephen.farrell@cs.tcd.ie> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Russ Housley <housley@vigilsec.com> CC: Peter Sylvester <Peter.Sylvester@edelweb.fr>, "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt References: <45DF20F9.2040506@nist.gov> <45E32524.1010104@edelweb.fr> <200702262121.l1QLLd9x002363@balder-227.proper.com> In-Reply-To: <200702262121.l1QLLd9x002363@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 5481399 - bf1913279657 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I'd ask whether or not this is a *real* problem. If it is, then yes, let's fix it. However, if not, then let's just get this out the door - 3280bis has been a long time in the oven already. IMO this isn't a real problem, unless someone says that it affects their code. I also have confidence that most of the important code bases for X.509 are represented here and are well able to object to changes that impact on their code. So - who says this is a real problem for their code? S. PS: I don't really have a problem with this change. I do have a problem however with the seemingly endless series of similar changes that appear to slightly "improve" the document but mostly just add delay. Russ Housley wrote: > > Peter: > > If you find this unacceptable, we can assign new module OIDs. > > Russ > > >> Hi, >> >> **The ASN.1 modules in appendix A are unchanged from RFC 3280, except >> that ub-emailaddress-length was changed from 128 to 255 in order to >> align with PKCS #9 [RFC 2985].** >> >> >> isn't this an incompatible change from 3280? At least one well deployed >> implementation checks for 128, i.e. openssl. >> >> If this is acceptable, can someone explain why we cannot remove the >> restrictions >> in the URI choice in order to align with X.509? >> >> 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 l1QNFglk011266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 16:15: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 l1QNFg5T011265; Mon, 26 Feb 2007 16:15: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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1QNFcjk011255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Mon, 26 Feb 2007 16:15:39 -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 l1QNFT16029647; Mon, 26 Feb 2007 18:15:29 -0500 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 l1QNF1VE021952; Mon, 26 Feb 2007 18:15:01 -0500 (EST) Message-ID: <45E36A5B.3010402@nist.gov> Date: Mon, 26 Feb 2007 18:16:43 -0500 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Thunderbird 1.5.0.9 (X11/20070111) MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: Russ Housley <housley@vigilsec.com>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt References: <45DF20F9.2040506@nist.gov> <45E32524.1010104@edelweb.fr> <200702262121.l1QLLg9t001549@spamav2.nist.gov> In-Reply-To: <200702262121.l1QLLg9t001549@spamav2.nist.gov> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter, In the case of the URI restrictions, I do not believe that there is a contradiction with X.509 since I read the text in section 4.2.1.6 of 3280/3280bis as imposing a restriction on conforming CAs, not on what relying parties may accept. In the case of the emailAddress attribute, specifying in the ASN.1 that the emailAddress attribute is defined as IA5String (SIZE (1..ub-emailaddress-length)) and then specify a value for ub-emailaddress-length of 128, this would seem to impose this limitation on both conforming CAs and relying parties. Since this attribute is merely being imported from PKCS #9, which specifies a maximum length of 255, I do not think that 3280bis should require relying parties to reject certificates that contain emailAddress attributes with lengths between 129 and 255 characters. If there is a concern about backwards compatibility with clients that use the ASN.1 from RFC 3280, I would suggest that the solution is to leave ub-emailaddress-length at 255, but include a statement in section 4.1.2.6 that says that conforming CAs must not include an emailAddress attribute with a value that is longer than 128 characters. [Note that according to RFC 2821, an email address may be up to 320 characters in length, so even with the PKCS #9 defined maximum length of 255, some valid email addresses cannot be placed in the emailAddress attribute.] Since RFC 3280 (and 3280bis) discourages use of the emailAddress attribute, I would have no problem including another "roadblock" to its use. Dave Russ Housley wrote: > Peter: > > If you find this unacceptable, we can assign new module OIDs. > > Russ > >> Hi, >> >> **The ASN.1 modules in appendix A are unchanged from RFC 3280, except >> that ub-emailaddress-length was changed from 128 to 255 in order to >> align with PKCS #9 [RFC 2985].** >> >> >> isn't this an incompatible change from 3280? At least one well deployed >> implementation checks for 128, i.e. openssl. >> >> If this is acceptable, can someone explain why we cannot remove the >> restrictions >> in the URI choice in order to align with X.509? >> >> 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 l1QLLeZu002370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 14:21: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 l1QLLeop002369; Mon, 26 Feb 2007 14:21: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l1QLLd9x002363 for <ietf-pkix@imc.org>; Mon, 26 Feb 2007 14:21:39 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200702262121.l1QLLd9x002363@balder-227.proper.com> Received: (qmail 17155 invoked by uid 0); 26 Feb 2007 21:21:32 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 26 Feb 2007 21:21:32 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Feb 2007 16:21:30 -0500 To: Peter Sylvester <Peter.Sylvester@edelweb.fr>, "David A. Cooper" <david.cooper@nist.gov> From: Russ Housley <housley@vigilsec.com> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt Cc: pkix <ietf-pkix@imc.org> In-Reply-To: <45E32524.1010104@edelweb.fr> References: <45DF20F9.2040506@nist.gov> <45E32524.1010104@edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter: If you find this unacceptable, we can assign new module OIDs. Russ >Hi, > >**The ASN.1 modules in appendix A are unchanged from RFC 3280, except > that ub-emailaddress-length was changed from 128 to 255 in order to > align with PKCS #9 [RFC 2985].** > > >isn't this an incompatible change from 3280? At least one well deployed >implementation checks for 128, i.e. openssl. > >If this is acceptable, can someone explain why we cannot remove the >restrictions >in the URI choice in order to align with X.509? > >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 l1QINdU8088112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 11:23: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 l1QINdlH088111; Mon, 26 Feb 2007 11:23: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1QINbi1088103 for <ietf-pkix@imc.org>; Mon, 26 Feb 2007 11:23:38 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l1QINV517830; Mon, 26 Feb 2007 19:23:31 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Mon, 26 Feb 2007 19:23:32 +0100 (MET) Message-ID: <45E32524.1010104@edelweb.fr> Date: Mon, 26 Feb 2007 19:21:24 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt References: <45DF20F9.2040506@nist.gov> In-Reply-To: <45DF20F9.2040506@nist.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090507010906030400090705" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms090507010906030400090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, **The ASN.1 modules in appendix A are unchanged from RFC 3280, except that ub-emailaddress-length was changed from 128 to 255 in order to align with PKCS #9 [RFC 2985].** isn't this an incompatible change from 3280? At least one well deployed implementation checks for 128, i.e. openssl. If this is acceptable, can someone explain why we cannot remove the restrictions in the URI choice in order to align with X.509? Peter --------------ms090507010906030400090705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI2MTgyMTI0WjAjBgkqhkiG9w0B CQQxFgQUzJBnkKLXHro7V4d1Cvyvgm2gEiUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAm5h+ne3nYrFTwViK OqVyuH4tqWfgvHJJAqRd/gUHP+kwJGrSyNdqmeaShPwUbPPLO+I9D1yTTLeUB1tj+caev/Q1 7iaAJ0CRjgSj47BZMvBwzR/7JhbWpYKFHipNUDMBCPXg+2EjR0fWaFDRYcJf8KWUZc34vhuC pTkAxQ9z+2UAAAAAAAA= --------------ms090507010906030400090705-- 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 l1Q9S4oS043564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Feb 2007 02:28: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 l1Q9S4jW043563; Mon, 26 Feb 2007 02:28: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 mail1relay.itmaster.local (smtp.finsiel.it [193.43.104.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1Q9S2eB043556 for <ietf-pkix@vpnc.org>; Mon, 26 Feb 2007 02:28:04 -0700 (MST) (envelope-from Adriano.Santoni@actalis.it) Received: from POSTA02.itmaster.local ([156.54.185.25]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:28:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75988.68B7DE9E" Subject: R: ID cards certificate profiles Date: Mon, 26 Feb 2007 10:28:01 +0100 Message-ID: <FF374A5075949C4D87367831AAAFD4211AFA94@POSTA02.itmaster.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ID cards certificate profiles Thread-Index: Acc+1mORVDN5B0fPRuGIQQKz8IZWWwar79QA From: "Santoni Adriano" <Adriano.Santoni@actalis.it> To: "Bechlaghem, Malek" <malek.bechlaghem@logicacmg.com> Cc: <ietf-pkix@vpnc.org> X-OriginalArrivalTime: 26 Feb 2007 09:28:01.0791 (UTC) FILETIME=[692698F0:01C75988] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C75988.68B7DE9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Malek, =20 I am just addressing your points #1 and #2, in the following. =20 As far as signing certificates are concerned, I would suggest you not to = reinvent the wheel, but adopt an existing profile as much as possible.=20 =20 Overall profile: as a general rule, I would follow RFC 3739 and ETSI TS = 102 280. =20 CommonName: I would avoid putting into the CN something different than = the owner's name. =20 Ciitizen civil ID: assuming you mean something like a fiscal code or = social security number, you should put this into the serialNumber RDN. =20 NonRepudiation: I would stick to the guidance you find in ETSI TS 102 = 280, section 5.4.3 =20 Regards, Adriano =20 ________________________________ Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = Per conto di Bechlaghem, Malek Inviato: marted=EC 23 gennaio 2007 11.08 A: ietf-pkix@vpnc.org Oggetto: ID cards certificate profiles Hi there, It has been long since the last time I posted something so happy to be = back :-) I am working on the implementation of a PKI infrastructure needed for an = ID cards issuing project. Part of my job is defining the needed = certificate profiles which are raising some open issues that I am = listing below and hope to have your support in resolving them. 1. Are there any particular issues when not adding any surname and = given names in the CN of the subject field of end-entity certificates = knowing that these EE are the actual ID cardholders. My understanding is = that the subject field is used mainly to provide the data that = identifies the certificate holder. Moreover, knowing a person's name, so = if I am looking for her certificate, I could use the name to perform = LDAP lookup based on that name. However, in our case, the certificates = are not published in an LDAP and the persons names are often very long. = This is why we thought not using first and last names in the CN of the = subject field. Instead, we are considering the following format for the = CN:=20 Common Name (CN) =3D < Certificate Type =3D <AUTH/SIGN>, Citizen civil = ID> 2. Assuming that the country issuing ID cards does not have a = digital signature law and no clear definition of NON REPUDIATION, should = we avoid using the NR bit of the key usage extension for signing = certificates (not authentication certificate)? We could set the = digitalSignature bit only and explain in the certificate profile the = applicability of the certificate including those situations where it = would be difficult for the cardholder to repudiate a signature? We could = simply set the NR bit.=20 3. We are not planning to use the SubjectKeyIdentifier extension = as the card returns a complete certification path with a signed message. = Would this be OK or are there reaons to use this extensions. 4. For the certificatePolicies extension, the plan is to use a CPS = qualifier with the CPS OID. Is there any reasons for deviating from = this? We could for instance use the OID of the CP under which a = certificate is issued. Assuming that the Certification Authority issues = other types of certificates apart from the ID cards certificates, and = that these certificates may have different assurance levels, what's the = right option we should opt for when formatting the certificatePolicies = extension? 5. We are not planning to use the basicConstraints extension for = EE certificates. We will use it for CA certificates setting the = pathLengthConstraint to zero. This prevents cross certification at the = subordinate CAs level which is a functional requirement since we are = expecting cross certification with other CAs to occur at the root CA = level. Could you please confirm that our settings for the = basicConstraint extension are correct. 6. Assuming that the LDAP directory on which CRLs will not be = public, =20 Thank you all for your prompt feedback. M. Bechlaghem This e-mail and any attachment is for authorised use by the intended = recipient(s) only. It may contain proprietary material, confidential = information and/or be subject to legal privilege. It should not be = copied, disclosed to, retained or used by, any other party. If you are = not an intended recipient then please promptly delete this e-mail and = any attachment and all copies and inform the sender. Thank you. ------_=_NextPart_001_01C75988.68B7DE9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR> <STYLE>@font-face { font-family: Wingdings; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle17 { COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose } DIV.Section1 { page: Section1 } OL { MARGIN-BOTTOM: 0in } UL { MARGIN-BOTTOM: 0in } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>Malek,</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>I am just addressing your points #1 and #2, = in the=20 following.</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>As far as signing certificates are concerned, = I would=20 suggest you not to reinvent the wheel, but adopt an = existing profile as=20 much as possible. </SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>Overall profile: as a general rule, I would = follow RFC=20 3739 and ETSI TS 102 280.</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>CommonName: I would avoid putting into the CN = something=20 different than the owner's name.</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>Ciitizen civil ID: assuming you mean = something like a=20 fiscal code or social security number, you should put this into the = serialNumber=20 RDN.</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>NonRepudiation: I would stick to the guidance = you find=20 in ETSI TS 102 280, section 5.4.3</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007>Regards,</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007> Adriano</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff = size=3D2><SPAN=20 class=3D035451109-26022007></SPAN></FONT> </DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>Da:</B> owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org] <B>Per conto di </B>Bechlaghem,=20 Malek<BR><B>Inviato:</B> marted=EC 23 gennaio 2007 11.08<BR><B>A:</B>=20 ietf-pkix@vpnc.org<BR><B>Oggetto:</B> ID cards certificate=20 profiles<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal=20 style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20 there,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal=20 style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">It has been = long since=20 the last time I posted something so happy to be back </SPAN></FONT><FONT = face=3DWingdings size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings">J</SPAN></FONT><FONT = face=3DArial=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal=20 style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I am = working on the=20 implementation of a PKI infrastructure needed for an ID cards issuing = project.=20 Part of my job is defining the needed certificate profiles which are = raising=20 some open issues that I am listing below and hope to have your support = in=20 resolving them.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><SPAN=20 style=3D"mso-list: Ignore">1.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Are there = any=20 particular issues when not adding any surname and given names in the CN = of the=20 subject field of end-entity certificates knowing that these EE are the = actual ID=20 cardholders. My understanding is that the subject field is used mainly = to=20 provide the data that identifies the certificate holder. Moreover, = knowing a=20 person=92s name, so if I am looking for her certificate, I could use the = name to=20 perform LDAP lookup based on that name. However, in our case, the = certificates=20 are not published in an LDAP and the persons names are often very long. = This is=20 why we thought not using first and last names in the CN of the subject = field.=20 Instead, we are considering the following format for the CN:=20 <o:p></o:p></SPAN></FONT></SPAN></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: 0.5in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto"><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Common = Name (CN) =3D=20 < Certificate Type =3D <AUTH/SIGN>, Citizen civil=20 ID><o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"><SPAN=20 style=3D"mso-list: Ignore">2.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr>Assuming = that the=20 country issuing ID cards does not have a digital signature law and no = clear=20 definition of NON REPUDIATION, should we avoid using the NR bit of the = key usage=20 extension for signing certificates (not authentication certificate)? We = could=20 set the digitalSignature bit only and explain in the certificate profile = the=20 applicability of the certificate including those situations where it = would be=20 difficult for the cardholder to repudiate a signature? We could simply = set the=20 NR bit. <o:p></o:p></SPAN></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><SPAN=20 style=3D"mso-list: Ignore">3.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are not = planning to=20 use the SubjectKeyIdentifier extension as the card returns a complete=20 certification path with a signed message. Would this be OK or are there = reaons=20 to use this extensions.<o:p></o:p></SPAN></FONT></SPAN></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><SPAN=20 style=3D"mso-list: Ignore">4.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">For the=20 certificatePolicies extension, the plan is to use a CPS qualifier with = the CPS=20 OID. Is there any reasons for deviating from this? We could for instance = use the=20 OID of the CP under which a certificate is issued. Assuming that the=20 Certification Authority issues other types of certificates apart from = the ID=20 cards certificates, and that these certificates may have different = assurance=20 levels, what=92s the right option we should opt for when formatting the=20 certificatePolicies extension?<o:p></o:p></SPAN></FONT></SPAN></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><SPAN=20 style=3D"mso-list: Ignore">5.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are not = planning to=20 use the basicConstraints extension for EE certificates. We will use it = for CA=20 certificates setting the pathLengthConstraint to zero. This prevents = cross=20 certification at the subordinate CAs level which is a functional = requirement=20 since we are expecting cross certification with other CAs to occur at = the root=20 CA level. Could you please confirm that our settings for the = basicConstraint=20 extension are correct.<o:p></o:p></SPAN></FONT></SPAN></P> <P class=3DMsoNormal=20 style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if = !supportLists]><FONT=20 face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><SPAN=20 style=3D"mso-list: Ignore">6.<FONT face=3D"Times New Roman" = size=3D1><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Assuming = that the LDAP=20 directory on which CRLs will not be public,=20 <o:p></o:p></SPAN></FONT></SPAN></P> <P class=3DMsoNormal=20 style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thank you = all for your=20 prompt feedback.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal=20 style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT = face=3DArial=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">M.=20 Bechlaghem<o:p></o:p></SPAN></FONT></P></DIV><BR><BR> <P align=3Dcenter><FONT style=3D"BACKGROUND-COLOR: #ffffff">This e-mail = and any=20 attachment is for authorised use by the intended recipient(s) only. It = may=20 contain proprietary material, confidential information and/or be subject = to=20 legal privilege. It should not be copied, disclosed to, retained or used = by, any=20 other party. If you are not an intended recipient then please promptly = delete=20 this e-mail and any attachment and all copies and inform the sender. = Thank=20 you.</FONT></A></P></BODY></HTML> ------_=_NextPart_001_01C75988.68B7DE9E-- Received: from 89-138-98-108.bb.netvision.net.il ([89.139.237.249]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1PI7kBw075700 for <ietf-pkix-archive@imc.org>; Sun, 25 Feb 2007 11:07:48 -0700 (MST) (envelope-from Kruegerfjis@HAYESCASTING.COM) Message-Id: <200702251807.l1PI7kBw075700@balder-227.proper.com> Received: from [162.194.162.129] by with HTTP; Sun, 25 Feb 2007 20:07:48 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Feb 2007 20:07:27 +0200 To: ietf-pkix-archive@imc.org From: "hong Krueger" <Kruegerfjis@HAYESCASTING.COM> Subject: Kno Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_8604903==.REL" --=====================_8604903==.REL Content-Type: multipart/alternative; boundary="=====================_8604903==.ALT" --=====================_8604903==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Picture photo galleryall listtotal? Arielle kebbel ashanti ashlee simpson ashley judd, olsen. York city ltd notified when add. Keen kelley nelly furtado neve nicky hilton! Nemcova phoebe cates pink piper perabo priscilla. Sobieski, lexa, doig linda lindsay lohan lindsey kildow. Mori bettina zimmermann beverley. Jessica alba, biel miller jill goodacre jillian grace joanna. Adriana lima adrianne curry aida. Mcelhone natasha henstridge lyonne poly. Dania ramirez danica patrick. Longoria, mendes padberg evangeline, lilly faith. Vera zvonareva veronica, varekova victoria beckham silvstedt vida guerra. Bilson blanchard mcadams perry stevens weisz rebecca loos romijn. Beyond borders ziegfeld theatre york, city ltd notified when? Graf stephanie seymour sumela kay summer glau sunny leone. Durance erika estella warren, esther baxter eugenia, silva. Dahl marceau monk stacie, orrico stacy. Jones charisma carpenter charlize. Richardson camilla belle candice michelle carla campbell. Ledoyen, whitney houston willa winona. Joss stone jules asner julia stegner stiles! Krakowski janet jackson january jeisa? Hunter valance ilary blasi iman isabeli, fontana. Mcadams, perry stevens weisz rebecca loos romijn. Gutierrez alessandra ambrosio alexa davalos. Torrie traci lords tricia helfer trish stratus tyra! Righetti amber benson smith tamblyn amel larrieux amelie! --=====================_8604903==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> <img src="cid:7.1.0.9.2.20070225200727.03015bf8@HAYESCASTING.COM.0" width=488 height=372 alt="[]"> <br> Picture photo galleryall listtotal? Arielle kebbel ashanti ashlee<br> simpson ashley judd, olsen.<br> York city ltd notified when add.<br> Keen kelley nelly furtado neve nicky hilton!<br> Nemcova phoebe cates pink piper perabo priscilla. Sobieski, lexa,<br> doig linda lindsay lohan lindsey kildow.<br> Mori bettina zimmermann beverley. Jessica alba, biel miller jill<br> goodacre jillian grace joanna.<br> Adriana lima adrianne curry aida.<br> Mcelhone natasha henstridge lyonne poly.<br> Dania ramirez danica patrick.<br> Longoria, mendes padberg evangeline, lilly faith. Vera zvonareva<br> veronica, varekova victoria beckham silvstedt vida guerra. Bilson<br> blanchard mcadams perry stevens weisz rebecca loos romijn.<br> Beyond borders ziegfeld theatre york, city ltd notified when? Graf<br> stephanie seymour sumela kay summer glau sunny leone.<br> Durance erika estella warren, esther baxter eugenia, silva. Dahl<br> marceau monk stacie, orrico stacy.<br> Jones charisma carpenter charlize.<br> Richardson camilla belle candice michelle carla campbell.<br> Ledoyen, whitney houston willa winona. Joss stone jules asner julia<br> stegner stiles! Krakowski janet jackson january jeisa? Hunter valance<br> ilary blasi iman isabeli, fontana. Mcadams, perry stevens weisz<br> rebecca loos romijn. Gutierrez alessandra ambrosio alexa davalos.<br> Torrie traci lords tricia helfer trish stratus tyra!<br> Righetti amber benson smith tamblyn amel larrieux amelie!</body> </html> --=====================_8604903==.ALT-- --=====================_8604903==.REL Content-Type: image/gif; name="Mauresmo.gif"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070225200727.03015bf8@HAYESCASTING.COM.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mauresmo.gif" R0lGODlh6AF0AYcAAAAIAocAAwB4AI16DAcAhoQNcwBye7W2scbcupq7+jgrAFUiAH4UAJIiAM4m DOgqAABHABQ9AEg7AGk8AIcxAJ0+CclECNNIAABVACpkBjNaCmxcBnZhBZFWALZpANdoCAB5AC6F Ck2HBFaNAHR9Bal7AMmLAOpyCQCmACOuDDuVC2OpAHiTAKWZDLqdANKjDAC7ABLJADPCBl6xA4C6 AJvNAMW1AOHDAADUAyPYADfeAlLoC4jfAJbtAMzqCtrTBgIATSsAOjEAQmEIRYkLPKgAM8YAQtoA QwAqORIcQUAWS2IqNnkiR54dScASTekiTARJMS09ODxNS1tBSoE6RplIPso6Tec6TAdiOhJcM0dd MlFuOHJuAJtdTMdlMeNWNQCORiuEPzh2NFx+R3R4OZ5/Trl4S+F1MQCoSSuhNkqdTW2eSnyiMqef SMyTNuaXRQ28SBvONDO5MVe8P3K+NpvDP7q8SdO5NgDYPivrPk7eOFzlNXLSP5/XPsrfQd/WSQgA ixQAeD4AilcFhYEAg6MAg7sGfu0EcwAkfSMZdjsWjFssjXwgd54jcsothdsjgwAzgRk0g0xDhmwx f4Ayhp86eb80jt80iQBVcixtdDFgeltVgodSg6dfebpfiNlpeQByjhZ3ckd4jGZ1hXV4e6t/fL6B gd10cwOpiyulikamh1StcoqYh6Sic8eVdtqmjQDDiyC+dUm+eV/Kh4y8jZ/Le7rMfdrHcwXddhLV gkTegGvWc47pc6XTdrrRftjkjQAAtRsAxj0GuWsDzngNuaYFwb4Au9kAxgApsRsZvjwsv1gst3wU vKgowc0ay9MWxgM7zBg8vzFAw1Y+vIJIua09zrhGzdw8wABgyxlfu0Brt2JUyIBmwZZftM5exORu zgtxshyHwTN7vGeIzIWIzJt3y8uGy9p8zAubwymuuEOlvGGis32st6WZucyUutWgyAC9uRy4zTHL u2G4vna8y5i2tvf/6q2glomOeP8ACw76Dv//AA0A//0J+wD5/////SH5BAD//8MALAAAAADoAXQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEgR4b+LGDNq3Mixo8ePIEOKHEmypMmTKFOqXGmyosuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKlcmyqNGjSJMqXcp05NCnUKNKnUq1qtWrWLNq3cq1ZtOvYMOK Rdq17NWxaNOqXcu2rdu3cOPKnUu3pdm7Zevq3cu3r9+/gPXiHUy4sNnAiBMrXsy4sePHkMkanky5 suXLmDNr3sy5s+efkUOLHk26dODPqK2aXs2aburXsGPLzty6tu3buHPr3s27t+/Fs4MH/U28eEbh yJMbNM58qfLnC5tLn+4RuvXr2LNr3869u/fh38OL/x/vNa29lEKp/yXPHqLaiirTq59P3zHQf8PR txdfP/L9+P+hNF5/BDJ33nv5nSQfXPs1eN1aC9rl4IQURiXAhRcWhCFBArCVoIIBFijiXHhtKFCG A5l4ogAGobgiiyl6GKKEFdbInootsugijva42KOPGAapIY8dIjhjSR+OqORFd/mY448p4rijjjBC GWWVVnIIJJYrFgRhkiRVtiRwoFHk5JBZZjhllGlyueWQW7rJ5Ys5wijkl0R9ZaN3iZ2pZZuAdrkm ml3+OeWbdWIpZKFZshlkkDJKFKlPY/p24EkXepTpRZui6GmVaoI656COihoonIqqeCiafj46549Y Tv/qHp6UVmpUiZq6ymmR/2TaKa+/PsmooKaSaqidVLL5YqqNKtssrH8e9OhyRkpa7Z47yfqQn4Fu uuuvj+66kbfe9tpht8hKmyyUpIZaqrrOEhuvs9zSKZC5kLYF37U9NRdhSaqu++6V6RZarrgIf4sw uR0ebLCJ7QocqqunyjtsodVpySzGrh6sEa/mUURrv6Thhe+vHzd87pXNuhttvJ8WWW6+KX8rM7BF WvnpsxWzayqhCWXkK84YbcpzQhgKDXLCbok8Mk97wVbzwUOLunGjOxO8HMNFE53w0OZylPWx816M tMQbhz2SrxoDfa/aSsPdtNP8ThbyYDTbzLTPcML/63ebSoM9bt5f34zQomefauxCoXY989L4+Shu 0nF3TLnC2j70NNQfYbu1yoNvdHTEGgusJdMnU+5xzaJbrHOqFB+Ods/neVw1yFRDjrnNDNOsO1j7 3l3eWOStrna+Tm7Y6s+MfhqS8VynnvK2sy9utrtTsj6118d7bXnqxgs/a91DYeT56dvrimjypstO bccL4/576JwqO/bL7y6+PJRMCz657o/73eUcx6CJNAU0LDlfjCq3tKEJ62jootf8UhYuuLnMbRa7 H88u+KYOArCBAhxg3kRYQdShJXhxGQhKIAEJACmwgiUcHKs2Vi+gocxxH3zSmtgHL2NdkG8PdFbg /+TXO/l17YhI/J6uyLcgirCwhf9gYUakiBEpUhFEr9HPRHInt7C56COPGxbi0MfAIWIwgg+zX8ee tb+dZS96FuRe+Hh3s7kdaSQsHEgeBfJESOjRj328YhX7eBSpaTEi3wuiF0GYwxmWTns4hNi0lmU9 Nr7KZRycXfOoZEQwQm6OJXOJIKlIyChCcY/2QGUq/chHVr7tIqWEZSxXYkgsbrF9PJPbDR13xux1 0YTm+lvZXje2TEqQSK8iIxIzpxVV7rGPrWzlIKfZuT8SBJWonCIUtWnKWdLoM4e8JeLOxMW4Cc1s v0yn7XgVrUXFDI3LStQYLdkQpiAQPxNxJiuhuf/KaPqznwrhpiwz9k9r6rObT9RmILf5Tc+48CU8 PN3qJvpBSJozjt96GDJ7FERhmm0mICnfSfQJ0Dw+05UkbQg2XUmtgWrEigy15j9V+UqFLpSh4XyK SFDYUIfgcoMVJaDYQvi/Gz6ufvjzKAQ1cxyJCBKhsrziSQ3Cz4SkVCE07acqqWlKrpoPqyxtZSA/ MtacZsusDnkoRNa4Ri8tc3vmhOMu06m0jmZxpGHlZ1XL2pGn4rOgq8zqH28KyEDKFKCIVSFZcdrN wSJkpS9NqE0ZG6Y7OoVuPZUIt1x2xKNiFJgXfStBaSI+p+K0lLGcqlXDKtCNPPWwBmWpSVFK24X/ LoSmeYxsX7cZ2GvK1pkg4SstLbtTA6J1re3jbPdAAkp7Bo2ZYM2rPmnrVd02FbC+JUh1uypImV7V IbgNK3YR69LydlWbj13pPhkLU8IeNyfvjU58GTKxSUaJftDViUqkm13YqjaxNfWrV2Ebza1G9al+ vS1/qSpeACN2pdoN7mlPKd7wRjiy7hXwZUF6QMxmVrPJdKtSCHPIkz5RwYfNqnkH+tqS/vYgi7Uu gw+SVQhj1yMChqlrJ3zd9BbEr6MMslrHd0IPV5a4dqyVgAJbW8Fid7bLkeo2BQzWH7PSulhmko0f fGIaN3i2O86yhGXsX8G6F8caLq61mCjfJQ8v/ywitiXJllzjwto2pYKNsW6t7GUvSXm7Zv5yYWfc X8XuVszn5S5jHcxg6k62tfN9LpsDGum7DPmsArIwYVFsZYZq+LVbrjNHctzCOvMZvNIVMospm+YB m9ix5D2wZLcrZyITz8g9Tk2lSevmPtMY1oQWK6QRLOg+A5nHuT61dw1bYPEm+tBotu4Vy0zbCxfZ uKVtz6UxbRJvYti21PYttKlp6kLXNMwCLTSUg+1ja5P62Sv+81fXnO16QkY424avUby50L92Gtjs Rfa8fS1TgcobvVUu6LuPje5Wb5jet8a2a76Tb5wwRbimNDdg9UzN/t6UwWNWKKPXfSmGw3vSlP+u N5KRRPFeKxmv3oZ3wgtO7ikHnNMq1HGYp/3k9VobMDy9lUhVbp2KW1wpxGZSbJUtzZBredAzzuaK z9tdXPfF6ihP6+awY3Sb7LvUApclQ7p8HlIim+cO/u+laq11xEyldfe8dne6HhO4Q8Thg2Q22bss dXinOegPj4itks05ohfd5W1OoBO/7em9/rbahma7vRGvuce0VO4vj7hshsuQ/IIVobM2L+ADX3nK t93uls46r1UvJtNPHvO2ZrnEZQ9x2ifH817f+mA6PHuxjF7Ngt/15UmUetbniSOddz1WcC9p2Jf+ w8lX/pyLYjLjR4XucZcL1vXU+yPXvm7Mp4r/7pffEfK7ffu8D770d299qIQfM9BPPNDR7xz6j//o hlfNyLzfFezDODG/l35xxn0DaHuFl39VoRjVt37NN3/fp3jcNnDqJ3n61n46BYA/F1IrV00PeHXd Z3n2V34bOGKWFoLaByak93wOmID3l3LxdxMteBkKiILAN4G5sXoI+H8M+BIpdFfnl30GqIL+MYJJ EYAa+IF8UUunQYTIh4Sal4EpGIG+Z4KoJ4R+oYQrmHlBuHYxqIMUWIHOd3pb+HpZ6FAYyIT1N3z8 F3trKIVT2IEhYYR1gYXrURgi6IQcCIdHqIWjdW41qId5aIN1qGtn+C/Uh4eByIZ/qB3+V4CD/whO xDd0YUiGYxh9L/gcwueIHkiIoyGHJIiIfWiFUSiGo5gVmQiFm4gab2ERpxh5T6iIcUiFGiGLhKcV jaiJSdh6+kKLEiiKwAOKdwiIoUiKbWiLreiHVxgbaSiMTQiMkuGMs+iJzciM09h/xziDHLYbvKh0 0Ch0hxFfzvWNXyh/j4iK8yGN1QiLAsgV2JgXx8iFg/eD1FiFxAhnJdiNhyiO4+iC+WiI6oGO0YiP /WiGFiiJl+iFBcmP57iN6viGqtiFb7eDWAEAFEmRPEgg20gmnDiJpigYC2GRAgGSNCgdAAmCG/mK kIgSFJmO7NgfJVmOwQGRlFgXK7kRFVmRGP9xkwDwDzjJkz/hAECZkTcolAnpgzkIhBpRk0m5kxdR kzj5lDupk0zJkzfZlDo5EUDpAPaQlVk5EEEpEF/5krxBlEV5khAIhvRIECKpllPplEzpllT5llOZ k1HplFZ5l3iZEV8ZlnuplWDpl1uplVwZmIAZli6BkZgliPbIJ4uhlBkhkiAZmQAQkpOplI55l5ZZ l3l5mf8AlBfhmZ/pAKEZmqDZl39ZmIDplVyJmqsJlmKpG/74iwqEjCSRmVRJl3gJl5A5mfYglb3J m79plZy5EaUpmqPZmcbJlcdZnMXZVHzpl4Z5moOpml35l4eJmEi5mA4iEjqZk7h5m+C5krb/OZ5t yZs3yRDMmZV6KZrKqZ7ISZrJaZzriRHNqRGGaZrWGZgEEZSrmZqEGZ2+uI+uKJMjSYBmWYsN0Z25 KZfgeZtuqZkLOpz2CZ2C6Z/TqZzLyZ4aSpzyWZ/zyaET+p74xJ+oqZpeKZ3V2Z8wcYsD6pDWeJTu KJFsWZXCCZXf2aB5SZ/xeZzwCZ8mqp//6SX9qaOr+ZkcAZo6KqKjiaQe+plAup+pCaCDWZ1P6p8K YZjv+H5SQaDHx5L1CBJrCRHluZQTuqM8iqEYKqLpOYskCqUIUaRKuqTy+Z5MaqYheqeo15cl+p8A 6qYUEZZZWpZo2IOsKKMDIaFqFqZXGqd1/7qeHWqn7vmhjTqNbeqmXymnaYqkH7qpH7GmdCqaP2oQ fYqifjqqAbqHiimbMTpxAsmNkoKowah+7fmoc3qmdpqkSaqpn6p0bXqf/gmf7jmkRxqfzampV2ql +VmlFHqBhmqO64gcgSogikqOxdgQmuqZ/Qmp2oqru/qeyeqnxzqscqqflwoSusok0Umi2YqsEdGa KEqlrepvDRmOysGiLbqIXxqLWHmtaQqstsqtlXqsF1afs+qqBzGqukqwpUmdetqnz1kQUjqdC2Gq lliJ1KqqfBiQGYuvFWuxClmtE8utSgqn58qv14WfU+qX5lqrOgqxy6qsI6uhLBuaLguuhP8Zqsdq pQ/7ranKsR2bjB/rs/gnoAjpsQ0IstGRre8qYh4arMYpsAdbqwrbsg9rqgk7p/yaEAiLrDv7pAxL sRkZdFzBD2Rbts7KEWRrsNNntIVKtGqItOjZlc/JmnEqsutZs0D6nMhZpOfasjbrqx7Rt8gZtdLJ s8oate6qXzmlnRFBtgThuBMBuSKRthq7tmxbtHDbtgdJuG+KrDGLq3XqtYarmnjKqOw6sTPrqZ6J t6L7rWDrshILrlx7uvdqoI3LDwcBuQ+huwzBu7QptLnXrLWLqvkqtFYbu3xKuo0quIP7t1E6syGx tUFargCburQbtzibn/CavT9bhBThuwL/AbniW7a4a7b2QL4NAb4EcQLsewIGwb4Dwb72ep3CC49y ca6Ye6Sk2roqNKl2e72d2xFo6p6wu737qR9da6IU+7pn66IFQb6667jjW74STMEUPBAQjMG4G74b vL7u+74fbA/wKxAj7MHtG8L2C7zBu7lvixTMW2SJy72Pard+K6opWp0h+sJ7y8Bv479E+rSdO690 Qbnoy8FGfL4XbMQRvMFLDMIHMcLtG78oTMIhXMIFccJWjIv6urFb3LOlEcMOK7gDDJp4S7GcGlIq asOA2anQK68RObn8cBHkixFEHMf/kLaUe8dJjMRHnBBZTMVUDMVTLMJVPMiE7MFvxsJ1/4egONga 0huqeNq3vqo5OoyhUFu0W8G7S2zHeizHdozHnAzKdPzJnCyBfwzIJwzIV1zIT2zI4veOxdcS7ei1 DnvGPGo+YNumbDyMmZzBGvy4TBzMfMzBnezJxvwR8ssRJ3wR7nvKWOzKp2wZsNzCaTmTKqy5fxHD NnsvlRyfl0zNSQYRmizMfAzBFfzLw8zHGpHMG7HM/+DO63wC7yzPufbMlhurB6jIDczL3XvN+ZuE uYyagdvG4OyNRzvK5uzLEtHBCt3Eq4wQqUzI7JwRyTzRyEzPXoqWl9ul+jy8iXiqH23NqbjNBeiG lesQCZ3SKQ0TEe3EgWzIJVzCF/2J2f/pzxy90fuMzyDNzxfLFi9coGd5uyo91BURzVb8x0ftyikc h9PcqrHZxUKs08XL0z2NEjpczYscNQwZE/bMgvX7mm6cz5mLzWNd0CFNiVcdj7240xnNVE2txUEt 1mVt1lIt0lCtgopLkvFKh3Od095b03dt18TL1tWIsQc9HWAthU892FNN01zM2P0c2IL910O7kHt9 2YAN2ZFNr49N1UFbg4b9EFI5rQkKnEut104dtoPKyFXN2XJdiq2dX6Qt2uZp2l7sL3stqPN40o3t 2K8N2n/hmFdZ2tfnkmTJkZXd1379jJ3N3J+Noz1Zo+VJoytpE7NdELb93AZy3CiZ127/S9eUTb+u LRFrKZI2CaHhWZc0GpfRrbZs6RDZ3ZvZWB9gzaUX+dX2/RTlHd+U+ZuHWtu/yaC2ed49qaBKOaOS yd+rPdJwfdaxPYcL7t6TPcvYbdph6pu72d8ZnuEZCJc36p1z6Z1YfRaFeNsOrt0QHuH1fZAfIdxT 6d8aDpySCeP+zeEJMeOFGpUcEeJxvRUUTti83dsnqOLNHdb//d738qDpLeAyXplNfhC+SeMKMa3x nd8G6aVautxBPuGRmHne7VxRHuZOjptKvpRHLuVTfuGN7MCdYeXze9oe2ZJ8weFRzpbCmaMHrpYh qedvjNzwl5Dz++PJ3Zg8HuAV+d8A/35ub/mYbb2lBXSgoS3kW77Zal0UsGoXw23otv3m3M3mnJHl Hn3iKG7TJj7n660UPO7Zh03qK1riBAmjWs7aLqjR05Hqy1jqjQ6DhdjRV864UZ3rQF3p+P3VKy6P L+rnqx7Ovy7ssJ3smt3qlhLLyA7tkU7pzI7Tsb7Wkt4bC8jg/DjaO27rkm3t197szi7qZE0d3Z4V 102Zp267y17u6J7u4/7gxbEd7U7j+d7hUmkUTFns8m7kof7dDX7v1O7btH2eUG7htX3oMK6o+Z6j Ld7j217u9A7vQM7tA+/pMX7o+20QFonjSF7hNp7mmcmZ/c55uG7Zidzd5B5Kjt4Rw//58RXu7vEN 8QA+3BAv3/Jt4dgN8u+efgEf7Ahf8bchE1Q+lw9a4DgJ9FeJ8yN/qDwP5T9f9Xue8QHv3Pdc7S+v keT95ED/3nR+6Ocd7jWJ5ggx27at83z+5RYvIZze6eZ+8XPfjSRP2mPv7mce9jc+mTja4vut4Hvu 8z6OnUUO7GvO8Ynn1Sah8DZf8lHf3w8v+Hy+4xNP+J9uH1iv7bRe9zf9hqy68njp9Arv+DQP8lff 9lSv9Nhuh66++QLf+fWu694+6ogv+XBeTQ6P87vP5+ap55jP5bdPGUWf7RLe9ZM+6KwO7TI4Enne jS9u6FJv81T/27Nv/bJO9/P+z8//bvvDn9UEz/26He/Z3/Yp4fiFT7Tfb/yJvdWYffhwJxpEX9fI z/nmB+sbv/75P+LnruraDxD/BA4UaM/gQYQJFS5kqHBgQ4gRJTIkWNHiRYwZC07kyFHjx44JP2oM WdJkxJEpVT50uNLlxpMvWcaUCdNkzX8nReLkiVGnvZ41f/7ESbToUJ1BlS5lSjDpUZpCo8o82NSq S6NXSSItyTMrVa4htY4lC3Lqy69Yn5a9WTFfvrI5z8adGXai17V063bV2/dqWrVtpdolbPDt27v/ Di+GqxWwXr5y567M6/exX8yDBaOtnNlnQsSG84luGFqi58ueU6Y2O9lpQ7ybVc+m/9xZZeGFSt8O 3K24sU17pkUfJq2zt1vGv3uypv3Z9UjcicE+b179tWzHkXkrX6zxuMXdjIcTD754+ELhO7ev/H6b unWLtt1Hhw0VO3z89BFqLo/Q/H6C2gsQrsPWEyi833r776D0imNwtLsE9G277uwTCz/o5FtNP4os vBBDEP36rsK90kuuvAHXO05B5QxMMTTx+lMoOQgXFK5FupgDUcOLOPTIwx9DnO2s9iRM0UUE/YOw PxpFu4jGCaMcEUffGpTxyg6FPE1Iy3wkDMggUaNvsBMdrOrIAxsrcEoVqbTyTTZTKhC8BGN8r68w uWzOy8LAlE5PqyRUEjTx4lyzzv80n6SStwc5mhM5jBZ1bijVdAQ0Rz7Diq0t/bQy0sIy7ZRQQBYT XW1BM5X0s1Mx77s0s0w1PYqs9z4NVNKcyHswRsZM9ZXOKH8dkMfWYm3V1Ve7jJXSEC11yVaeliyv Rml3JZA7RIWt7c5JjYWV2GTZWnbcjjb9MM1HMbSR116/RTbDcY/VLlzMyP0zsHeLPVdEXLvdF09u /eWQNnDpHctelFZNeLp8vVMqU3n/3XbeVws2eCvcFIbI3HI1rq9ecg+OzuMsk3UWwzHdbVjgPPGl GNNlOc6YqZOtq7nimGrQ2SKda3BpZ4xX7tHioYW2KmSSc1P5ZT1vrihlqnquASH/qUsmCOjsjI6P 6Ke5nhhh9RiWGGamm6YJbIakvrpnlnVeWCW1f/bZ6b065m/sDdG2m7OAj+7bZlZrctttewaf2iCp fb4I624Jb8jtlxgXG294y67c8qD1vvdrykX++2K5/wF659EVFx3xqgl3vHDJJed57pAMX7rzjOgG bm99Nae9dq8f7p3skkovfXGf2RaIdNNFV/xw1qteCPLQJcPc8+l5//w63bM/8+6WIUtKe9RRV535 xItPPu7jTcfa9Yp2Ft/59wfHaXXcX098JOS3vr7u+ucDX3uZbQ4y1Ase+QwYvvCtrmcJud/wNLI+ CKZvIMg7CPyaN77kcY6BzGOd/0Eykj/2SfByu2PZlrj3P7QlrSU70gn9Kjg1BcKQgxZ03AI7CBHo MS5/EzSfCB2ovPTZEH6J8+ADz6e4x8lQIi5U2gkFmDetdQ2FugvgXf7HxA7W0HBUUyICFYLFF4Yx jDFkHRA/8kMzCs8pWCQjUDCyQyl6EWqT657/qlfCKcZLhSQkXtoOV74uIlCLz+MgIcWYwBkqkY1E LKMIJei6EAKSh1zMYhdbl0E8Bo6OT4TiHfWXR73R6ncFaeMNLzi+iAxyjImspCEFecBVho14a3Mk EEHYQyGWz2oug5gTTbjJX/INlLL6C9IEx0UmOq+NGGzlBilpSjKC0ZWrpOUtzf9oywgWzZOf7KUv 38bL/tlxmJ0aJ4DAUkpdorKZzfNiNAuZykJuMZbyvCQtm2I76XUTmMHUYB07Wc6P7fN/PDGgFhlZ uGeqkyP0kyci14nQQ5pSlt7bXz7d+M9wYpSTI8xo7vhYm4iBkqC5VOUzv8hKiW6xoexM6TuZxdEq 8hN4H8XeNuNoU/5x5Xb+FBdACerHg0KUnSqVISkDKVGANlGgAVUWTnO6UY9acWZ7NCfIfCq4dCry j9bkofUAmMmNeTOss+NpVKHq1ak21anLSepFI7dVk65wqWkVJk1rateg4PN7AyVrWbPmo5t21Kwy 1ShgqVpEsTKVolF8KrOMaVX/xuZ1lHqtqEX5dFjEzlWpasVrXB7LWb/+VbFsrewoLWvYxO5SnIKl V2ZBi9rXnhV02lwrZWOGWbeCM7Sx3e09P7vYtV7MtLazV0zHqtnN+laPkNUnb785W472lpudLW5q k7un3Op2YCGFrXNHC93Mdfa0hC2sJuva1uuutrsAuy1zxWsw4g53ucgtp3FH1tf1knaO4I0uefvr 38HudynodW0/8+u7r9J3otj9rmdLO1nTopXA4v2tgVFo3wZrt0/4BXB4pRtYne50wgK2MInVO0UM q7a85gUudROM2xEHt8InZnGLP3xXL1UqwvzFcYzvq2BiAhkp3JUtWOnK3lDO/9bHOYYxhOeLZBk/ mcdTXvGSh9zk9463xjNlrZGPTOMrU1m0Vv4ymDMsyva698aNJfOaxfzfpML5uBp+ro0P3NPIivix M36zZK9qXbnSec52vjOaI5td+PC5zylOckwJmGUhh9m7udkuh028aEbbBdO0hfR5mczfIEO5uX2u qqB/vGk2n/nRn0aZolfN6kxnutSmLjOpdxzpW39S1iG29Kk97Waj/BnVeu5wMTXX4yJzGtaiXnaJ B21mMg8b2cWmWaVxvWtJM7vZ0E5vlaMtbWI/GzrGfum1Aa3pXgdXzqqWcJsXvGh3l/vX1Fb2tvGs bm7Te7rxLjC4yT1ObCM63//oTne3113rALc5XPZOOPhwG3B8ervLXv4Sluv75vgKe976nvaWJV7x c/Ma1221dZ61zNeQb2/jHm84yC1OYX4XmtAc77jDMQtx+Vb25S6+eLVnDSjb9nzl4v44wc2tZpl7 mJwobq2ThT50dlPc6FA3uKFH7exlnwQAAIh4wQNNayo+POXZxrqKHZzm2/jt5x/ZetvbbhC3x53r b9e5179e9rCPHedOx/fIG53qhLx9IG3/B+E1IvetN4TudUd6svedR7GPPeh9p7rKfW55tm/dJolf PEUMf3jNd97tCOl8rrXt+JrbvOVuPrmvwX536IaE7hf5vE9Kr5DFfz7ug9f//OYRL3eR48zkrn88 0/3+4CgSfyWGX8jtRVJ7i9TeHnSP+0EWj5Hafx7uiZ/+6Lfvfa29++z9/jfPNY53l79e4PrFfEag T5Df974gzrc+94tIeLkLRPvNt3/3uX5/+dO93us/0kO8vxu2nHs69Qu+/OCI2du994s++aO9Cfw+ /+s+CyS/7JO/DLxAD9w+CgQA3hNBlig98MNAVxOzBAS4naM5D1u+3qu/uSNAh4jAEZRAEcS/0ONA /vu/DtS/ABzACSy8HpRBADFB8Hu73ws8GvQWcJu8Ydo1tdMJwQPCHBzC+KC/DnQjHSTBHSRB95tA 4PtA6iNA7AtCMMyJ6pNB//tTwjbMvTf0QST0wep6Qr5jwYHrnpKAwxmkw9ywQSt8DTf8vzHstw0E w90LRCuMwSL8QA9KxEUUwj5kQjnkPj6kRIYwwALUQpbDuDtEOeVaO9AjRM5rQkyEiOsrvC8cwQrE vf5LRQFMQ1W0wd97mlLcRFUMxPczvC70wiGERCPswDLcRDrkxMvytxVMOj8zCbeLREhUQ1PcxGDk w/4LQfjjwUvkvzNERDFcRV1cxV2UxFn0RlaURegTR95jw0r0w+8rxleMRmtDNSh0wdNDCUC8xjV0 xBNsxC2cxRsMQX4kQ3LkxSssSBz8xlw8xyvExzA0R0lEw+vIx0sUvTisv/8UpLKaIT8gITKJ6MY0 bEb+oUg/zMZ3lEVFVMQlzMD8C0du1EF/vMFYbMiDzL+XrAhIJEgSFMh1DEZHVD1p67SDq7ox659D dAqStETnE8nv+8dYLEV2pMaC/MWBxMJ/ZEiXrEl8LMNJBMCWRMlsjDd5XD/AYbzKq8GH9MVmzMSK FEakXEdy5L2s7EMC1MSahEAz7EJ/jMCrxEuY0Er/c0qGLLoY8zcuMb0FNETEG0Em3MLRm0NibEeP vMGeHERX3Eqn3Am85MvAdMkvlEbUS70lazyTa0CyLMtS08xxnEU2rMzV5EmttMm3tEIPLETPvMzS e0nONMiqDErY483BRL//rls4w8xDYgTJg4TGkUxOnpzNktTNcTRJ5mxMGoTKv/y/3bS6iau3mCO7 cCO6khtNycNKhczJr9RKUnRLdqzLZoQ+nXTKuYRH8cPO7Cy+F4OPQ7jPQwhOkylNzEjMuFzLduTH New89ezFnNzCThxK1pswpcBPgbhPgnDQCIVQ/NRP4aM8zzhE6BTJnfzLxwzQi7pHEGO4V/vM7my/ 6pDQf1BRFX1QCsXPFr0IFR1Os3kP7yQLwmtNyJxOAJ1HZSw/1ktRCJ3QQ3DRIiXSFR1SGM2IGK2I Jk3S+6TRwpQyvWBHnWRNElW6eKxHc0q/l2hSB43RMB1SKGVSMpXRMzVS/xc1UhhdUtAUSozkFP6s DWM8QOAMNX8D0xc90oEYUz59UjXFiDZF0kDt0zR10jb100TNTymtPI6ss/FTQOJkQOcIxfg0VD7F 1DJFUhY9VE0VVDct1CRF1Ey1iCcFVELF1Da10DtF0XsDylZFmL0zoeyp0P3wU1LdVFTdVDQd1U81 01LNVVP1VGFF0yJN1FxN1Ealz/m8PAyN1TrULMDjE1tFiAqtVoO4VmTVCEDFVVUNVlEdVnDdVSgl 1hYV0z1dUyJdVHp802O0O1F8VZESTE7iCGy1B21l1IPIV3yNUoio1mQ91G4l1nAtWFI11zNF12Ml 004F17ti14QgWN9MIf94jVf59MllvFRChdFs9dd9jVJbvdeI9diRXVWGEFiJXdQ9XdQJ9VVxTVU1 bdhfTYmGLVmFWFWOddWJBZtHvVEFjUKpY9lflVAH7VeStdmb9ViR7Vh9Zdp/9dRd9dZi5dWYZVir dVhjRdR1XYiQzVmjNVp23dbjQ7uZg1R5hVPraFqm9doKZVNQ5VNrVVp/Jdl7XdqPVVunVRqphVmF 1VWZpVmJZdNgJVq2BdmjvduPnYhBbcEfnUJYrUcdA1uuXVx1NdRA9dq8PdnD/dqGgFibndkyVdl1 FVuYBVWX/dRt5dfJ1VfMTdr8xFaTvdsonVUnnDSzG1HWYFXKqNu5JV3/g8XU1e1cuT1c2D1afu1b wMXaqn3Z0D3SvU3VzI2Irn3d4eXctW3aw6Xdq4vUj5k6Z31cjLJbps3at0VcpI3er+3a892Yhr1a qvXbhY3f9wXd+S3falXdfkVc9ZUInIVdxm3cwfhejQXSIK2JzVVZwy1VlD1S9FXd4sVbzVXb+/Vd wnVe+UVg+Z1aYOVVqZ1ezt3c4AVb1gVh87XYdoO8w6xd2+3NsjBeF9bXQq1g4EVf4ZXg3h1hpJ3e 56Vfci1XDk7gu63ahZUwHR5hCI7bIy7hCVbe1SNbBMueno06tfPcB/7drnngzMVi6+3fI8ZWK0Zd 95XZ9DVcxargCn5a//Hd4urVYusVyyY+Ni29sIrV2bHgWAxeob9NU7q9Ydml3i4mXhLO2x/OYPgt 1/g9U9d12hvm1lC9HQ/+4BvG3kBuVncVYBOWOjgWTbM1NIjl3Y1NWPxd346V3j02YjXOT8E15Pq9 3HRNYzKeNUXN4Hy14STeXkw+s4yTVC4z0aAo4ja2YxC+3zZOZCTW3+qd3DGGYWEl3FVu3kxNZDIu 4gV212id0uGLM0v2Ur3w47BFYDQm5mQu4ZEN5wjOW9/l1JR90VE14wMmWe3NuxVm4TemWMlbViYd CZVV5DUOZkYN5RweXhL2XEQbVMql3Kn10Us2TUrOWJg7v0nVSCGxYP+FJdOk1eckfmQRLmcaRuIE BmioDdyHduPIdWLuXejWq88UFmk9AeUY/WdJ5mdTruGONuLWHeYoptKQtucTbleSi7yLIWiW/uNx lmnZNeYXxlNLRWpqTmjtTFAC5uWTtuUnBl/PQF6N/uVIlmNLg7j/bVefVmjuLOkCTlv3nWHJ3Wif 9F7c5WnkI+mzHWBo1V16pWMQOVcZXuqY4+qb62qfhS+U3mWo9utTU2u8huh5putbRuzElrdL6ek5 Nuw4PS4VhtaA0+uxVWn7uGl4jmem3k9tZlYpBu3QLmzMbupNjuPTRu3RHjBs1uS+Jszw3OvY1ruv pmzNzmTO7mx8Ye3/1H5qtr7mikJoepTrnZXV245PuD7ssT46sIbsne7txS5t0UZb037tpJ7Xxy6Y i/Rt655u6vbu5Abv8Cbtyj5uen5rhFNu4lZvy25u6V7r7obv+C7skcbD6gbFlF5v1V7taZXn/b7d /obqXH7WnFY+9oNivp5vhtbtkH5nnT7R75Zv/j7wUNvOsJ5rxt404b60ixXwB/du3rZwk47qz4a3 T8xS7lZwCPfvqdZuEadUDM9wTEvGd81txRZvplbqbH5xk67msATuyS7bCdcy2CZxHo9w0v5wBqNx AN5x6w5yoDtyJt/SKMfp4pZx9CYwwWbQBs/uAHdux5Xq/96wMBfx/y23b/c27wvPcgO/ch5p8yS3 ci1p7Uir7xq3cSx388Be8QSHcxZy6Bi3cxQv80HXToJpazRXc7fucK+uZyWP84BZdOV28CZvcaB1 7SHvcwD/WSm/cQnf9OfGbyH/a8Bu9Mse8RTDdDJn7vze7utG4ccW9ErXbEr/7TzraUS/dDx/b0vf thHTdCT/ck//9J3Ius7Qav0OdRWndE7H7VYP7kenb2AnbAyX9T3fpGb/9WlncGEf9l73cECvdkX/ TjPfdm/vdjB/dV5Gr9oudeiGcULnt1qH7vsO9gUHNjpP8+x26hT/NoEacxavd3uncHDX5UBP6m8v cTa3Mmsf7mhf8f+AF3hnT+ECl25Xd3KFG/d2F+uCT3RuE045L1GwnJ1RB/V4d3hAt1N39/Ns9/ef nNOHnnd4F/lll/lMN3eetUOYv3IHj72Hh3gdZ3R3I8xkj26b5/ZdV/Q8p/mM13nwZPXbufebV/WB x/l0x3iXR8Cdh6mTX/ULJfAY/3kj/82X33p0H/aLH0uwD3uzB3htd/qXUfmKX3uhr3lHb/voduyy b781l/jxhnS6Z/qpd++i9/u3V7KIx+T2fvanT/p9x/u8z/eG95oNH3Ifr3LLoXcc73vBD80iV/YJ r/z0/nNJd/uZ73zPB/ylR/3EJ2+rP3MxB/3R73dYP3TIN/yrJ/b/1j/7wld3V51yKuf4IOd8rDd5 39d83f97oA96FQR+Dq/7rmv8lFb68r77wCf9KCt92g/3hTf+4rd30ff6H7/1tGd8XcfzyY868Y/r 21f7hka7qrf+2N/+3Zd64yN8sdd4+cf91Zf9zQaIfwIHEixo8CBCewoXMmzoECHEiBIHOqxo8SLG jBknQtTo8aNCjiJHkiyZEGRDkxRRsrRnsuVClf9g0qwZUibOmjhl2uzJMqdPlDuHEhWpk2DQnkBb Lk3q9GFRkjSjSn1qlWHTqxWpcuWqsevEoy+n8tR6FaxEsWhPmn1atu3WtXLZwsX6lqlKtSXrOp17 UK/fmXyDZh0c/3gvYI6JjcIsDPLuYJuHkZKdLDiyZMh8o2K+6Pij5sehPX7uDNqywMppoeY1rRox 5oJxR5stvZH2V9wYbbvejfpyZN69Leo+/duga+HEi3tu3Zj58JSokzuPLnqsdenVg28XCp01drzd sze3bFo5eZcrwYff/D0p+tmw8XZ+b/34eftuu6bPPR5ufOyN1J+AAaq12Fz5/ecdcgiuRmB583HX HoMU3vTgTwn2taB/k1HHoXr6XSghhAUqVqJVvzmIoWEijnjYh3ShaBeIBBo4423mvVZVbC6G6KFW O+GonYUz3jjkcjo+VySALuL34nHrIfkjiTgeOSWNSopXZV0+rnWVmZZI+hgjj1juGNiZjPVYY4T8 LQmkmWPWJ6dvf80ZZoVctnUlaWwmCeeUfCrIZIdlTghohn5uCFyWURqaJ5px0nmonjkSGqSKaYaF qaImarglokMKemellpZ6Vqag8uhog2/CqKlcWAopaadEnpridLD+ExAAOw== --=====================_8604903==.REL-- Received: from [154.37.239.16] ([154.37.239.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1PGEAmX066245 for <ietf-pkix-archive@imc.org>; Sun, 25 Feb 2007 09:14:13 -0700 (MST) (envelope-from norma-Meijer@anachronism.co.uk) Message-Id: <200702251614.l1PGEAmX066245@balder-227.proper.com> Received: from ([161.174.160.158]:27824 "EHLO " smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>) by with ESMTP id S22TEWDOFHWBIMWT (ORCPT <rfc822;ietf-pkix-archive%imc.org@mail.imc.org>); Sun, 25 Feb 2007 11:18:22 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Feb 2007 11:17:59 -0500 To: ietf-pkix-archive@imc.org From: "norma Meijer" <norma-Meijer@anachronism.co.uk> Subject: material may Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_65937546==.REL" --=====================_65937546==.REL Content-Type: multipart/alternative; boundary="=====================_65937546==.ALT" --=====================_65937546==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Nbs webmasters advertise copyright ip issues disclaimer? Art, costume institute benefit galajenna hogankatie, holmes tom jones. Dancelopez selecting shows slated cameo, course ofthe run. Tour, below are, dates, sheffield hallam, arena. Eli struggled postseason after few seasons with new. Protestors peoplefor ethical treatment animals, peta highlight concerns shewas? Mass, blonde curls bright red lips spent hour perfecting! Center background rampb songwriter present fashion, cb golden dancerand. Subway used growing onjune top ten billboard multiweek. Drivebut then came out. Coach tony dungy guys hung played? Ultimately, relegated similar, fate could anticipate outright, hostility. Created headlines recording rebirth, jason ankeny, real murder remix. Radio birmingham, nia london wembley ndash st christinas? Onelopez alltime madonnas michael. Moderate vh box guest such pun fat joe. Ofthe run begin subway used growing onjune top. Link ebe mentioned injennifer lopezstar profile, lopezaint, australian. Cdrebirth cdthe reel ep bonus dvdbuy, epbuy cdthis. June april march adriana, jolieanna lavignebai. Aired amedia furor whether, belatedly return noteagerly. Rule caddillac tah several weeks rereleased birthday abonus. Familybuy moviemoney trainbuy moviemy, verified modify neededfor. Lifeit thought brief longterm boyfriend davidcruz publicized, met while? Be part teamhis efforts not, only but also, earned. Romantic dated sean combs long term engaged actor off. Cooknelly kidman miliandemi ashton mcgowanmeg madonna ff? Tvtv, comediestv lopezfrom diana mimonyour guide gossipfree newsletter nowborn. Australia promotion peaked laterin riaalopez, js song, itreached? --=====================_65937546==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> <img src="cid:7.1.0.9.2.20070225111759.05164e28@anachronism.co.uk.0" width=516 height=360 alt="[]"> <br> Nbs webmasters advertise copyright ip issues disclaimer? Art, costume<br> institute benefit galajenna hogankatie, holmes tom jones.<br> Dancelopez selecting shows slated cameo, course ofthe run. Tour,<br> below are, dates, sheffield hallam, arena.<br> Eli struggled postseason after few seasons with new. Protestors<br> peoplefor ethical treatment animals, peta highlight concerns shewas?<br> Mass, blonde curls bright red lips spent hour perfecting!<br> Center background rampb songwriter present fashion, cb golden dancerand.<br> Subway used growing onjune top ten billboard multiweek.<br> Drivebut then came out. Coach tony dungy guys hung played?<br> Ultimately, relegated similar, fate could anticipate outright, hostility.<br> Created headlines recording rebirth, jason ankeny, real murder remix.<br> Radio birmingham, nia london wembley ndash st christinas? Onelopez<br> alltime madonnas michael. Moderate vh box guest such pun fat joe.<br> Ofthe run begin subway used growing onjune top. Link ebe mentioned<br> injennifer lopezstar profile, lopezaint, australian. Cdrebirth cdthe<br> reel ep bonus dvdbuy, epbuy cdthis. June april march adriana,<br> jolieanna lavignebai. Aired amedia furor whether, belatedly return noteagerly.<br> Rule caddillac tah several weeks rereleased birthday abonus.<br> Familybuy moviemoney traiÓ.m4Û ,«;6y ?ýuû²5ØÕYé±ù ¾L}ÑþÍxÇijC¤íÉî%òbò8'ÜÖ±í¯MÀ»¸i>wGó ÿ lopezfrom diana mimonyour guide gossipfree newsletter nowborn.<br> Australia promotion peaked laterin riaalopez, js song, itreached?</body> </html> --=====================_65937546==.ALT-- --=====================_65937546==.REL Content-Type: image/gif; name="best.gif"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070225111759.05164e28@anachronism.co.uk.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="best.gif" R0lGODlhBAJoAYcAAAAGAHYGAAR6AHmLCQAKgHsAgAB7eMvEx87PtZy/8UUYAGwbDIQdAJMoAMok ANMlAAM4CBU4Bz5EAWs0An85AKFAAMY4AOM3AABqABVrAE5lCGReAH1aBJloALJjDOptCQCLDhx7 ADeMAGx/AIKCDZ2ECbt6ANKJAACgACuUADaZBV+VAHmfAKuUDs6aDd2fCArICy21DTzOA2jLAIW/ CpS3AL27AObNAADsChjsAEvYB1veAIrkBajdAbLrAOvXAAoEMRINM0sKTGgAN30AS5QANMYAM9kO RgAaQiskQksaOlEbO4saM50eMr0aOtEgRgBEOx44Qzw6QW04SX1OS6o2NbJMOOY+NwpgMStkPTla NVVaNnduD6BmRbtZOt5lTQiASRV+NUOCRFqMPXpxM5R0SsJ9PNh8RgCRTBeSQDKjN1yeN3uTN56f ScOjO+KUOQDDOyvFTUbGTGnDRHzFN6e6TM3KPt7HMwDqOx/lTTPsP1nsToHUQavdOMTqMeTnNAUA fiMDjUEAgV8Oc3wAjpUCf8YLjdwAiwwqcRoodUQjhWEXh3wmjJsgdc4nftEZjgBCexs6jktOil04 h35MeqxAccUzheEyigBigBJsiEhceG1hjIVnd6lpdcBuiOtfiQCMfBtxhkyNd2t6hYqChZp1g7aJ gO6FgAeghhWkjjqrcWCuiHyVgZiZfciie+SjgwHBeC7KhD7Dilu5gIq4fKjIiru/etzGiQnucS3g ekHWcV7tcXfbf5Tjibzid+nicwMLvhQLvjUAxmMFs3wOy6cOzb8Aw9QHwQUbxxMlyjkav1wbtoIR v5ESxrUhtNQdtAA/vClExTNItGlJynJEtqwzy7xIwNk3sgBuuxNruThtu1dVu31YtJZUusJSt+Bc ug2Iyih5skeOxl6MxIh0zqx6uMB7v+d/xACZyC2VzD2svFucxY2nu5WjwbSdztuhxAa/uyzNwUS8 uGLGs4e6tZG8w///5ZqXnnGNif8GBwD/CP//DAAE8PUA9wDz//r//yH5BADdsUEALAAAAAAEAmgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMlSpb2X MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXco0aMunUKNKnUq1qtWrFZtq3cq1q9evYMOK HUu27FCsaNOqXVvSrNu3cOPKnUu3rt27ePPq3cu3r9+/gAMLlsm2sOHDiBMrXoxwsOPHkMcynky5 suXLmDNr3sy5s+fPoENjjEy6tGmjolODPM26tevXsGPLns1Vte3bGWnr3s27927cwDH7Hk47uPHj yJNTJc68ufPn0KNLn069uvXr2LNr386dqPLv4MOL/x9P/nL36uXTq1/PHuJ57mrfy5/vPDV9+O3z R01q8L7//06JphRHABaIn4BIdbSVfgw2eNiAG+XVn4EUhmUffxFKmGGF83XGk0MYbmiXgiEKxKF1 aWmokYorsujgiyLWReJdBOr2D2Ew5ufiRTvyWFyOL/ZokZAU/QZkg6U1RGSRPyJoJFb0KfTTjLMJ IJAAWGaJ5T9admkll1+myJuY8pFZJUFZotmlmmgOtKVCb7LpkYQ4ehYlWjZ6GeZBaRbU55Vxgulm mHEWuiefhwp6I15UJhhjd2bKBqiWg1I66ZqB/umnppYKauigoIIZE5Y4kSqTqRC2qFVuHeJJW6Jb 6v/JaaaEfvmpopvmiiitqJLaqwAw/WoPqi/Jeiqwx75UI6P3RRobsqNCGy1hsQaKK6AIzcomrdea SGyx0gYLrKm+QluuuOiCa6qcCVmr6JIT2VNQbM5WqedNWUZ7qLvdeqotu9taCe60xJ4707fDhjsw uePWiuubvH45Lb4KI1xUo94tChOrR9XrmpalFtylvNg+NCu3BrlbbcLptkywudIavLCe/fILcZ8M pzvyy8lSfDCyy3YM4275/hyzwsWGmi3KDyfarpWGsjzwz1TL/K3F55as6K3uSj1xzyBLfa/YR6ur 9NJSOgolU0E/WzTC5XqZsK2wMq3mTlYDqzW/S3v/nTdNcDdcsrU2Qy3w3EUjLizVPTf+6950K20o shZ/na7HAc7pG9aBAz15roUvenXDLg/sULWSwyx3TXkP7rTKhqM7OuNkA440wt3yrTvpPOssrb9e 6gqwqkK37Xbi6oaLPKnCqxmxt6qXzTnJhBt+NrZ48+63506jHfXMtld99OzHrtnv+V2LjLTXx+Zu fcAhlWiVsgTVVXbjc0fr/PBg7hn21OUbH/dA9anQARB8BxQX8sK3OJFlz3f6ul3FBFepfdWtUuwr XQLlRbOntUV+VWHNzhS4P4DNCn+z+9WfQnezdwnrhffKWbIWd7ANtoxhC6yc0cL2vJRdcHTKC2L7 /0Lnw+A9KmNr88tJVui/7TkQgQnz4fVQhy0a9u5vU8vZ9AIHwZCxbnU5u54HXVe+L04Mds073xGF gjnYYMyMX2yaHKtYK9qlEGZZlGDyAEjDc3FOe8l72/pIpkau1Ypyg7Qcy9C4tE51j0lqu8p/6ncx hvANUNvLJBS5mEAsLlKPiOMjHhUISHRpbY6XtGEGZZY/Y1HLghr7UNqKJ8kTsdF44bMJFmX4SQ1a sYECzKUm53gp9N3vjuIbJDKbEstKJtGWZBnIWHRYu0zykpc3FKAgnfe67r1JkwrMYCdLGTceJnJK F4JmNHHJMZ+Z0ZwRDCTDmse0m5WRdmATZDJHRv9NoKhGnWXB5VlMJBYd4ixyFYQcJsOZzRlOUJj4 oyVodgOJilpUJhUlzRtvuUZnLmR3GmNlK4U4NlKOU5xInKhuLHrRmLAUEi6FKUZl+pKW2iOj6yQe ajqaOUp6JXEiFWkveyfR9vDFpjd9KUtvQtOk1hSnSZUpVGEyVac+VZY8RWdWfbLRsOysnz3Vj4uU ytJ/VHReU0VqTHNS1bW6ta1nLUhc46qkSLZzpzp1ZkzuOlAk4YWuZoWEQc5KVosSlCZVhStNM9pW qzJVsAcB7EAIC1mCKPaqOxEoR/PaV1X5tLM6+qtklbqQi7b0sm7VSWKbitnAunawlUXIWWvSWMb/ sjapsBWIZGeJV85ulq80Co2EXqoQsso1rcilLU51C9ndjja2OFntTOLq1NredqYkI+5uXevc2+K0 sTXRbFh9FNzDF YìÈL dbt3Pd6Il0m85xXJl0+86TCT2ORDvjSLOy1nDvsErqlmedDX7NFXz7vecJHKc/Od7YFfVdgGZ66k PxzfQCs1ukLvrUpfjvS3UIniXNnvxTd959yavOk5z6+vyQ1ao3O9626BeWdjjun2Vl3f98b7TGft cGY6qbxZ8TvcZyx35+xXxNFeNcSX41EtRyTegQc8hAF6ZXcvfiqQj1fmNU93SDZYxtkBe0BdZVcG a930RUf9XLpKebDUsvOcP73qN78Qx2e59dIW/W89L/vIw/7xR+8y7gXv28HnpPA9YT12kD/83vt+ Ka93Pu8hxfzmp3TykpemXKo/He5bv+VDYtT/o6J/Hu9/P8bGz2n6dTKS8pv/RC1SftxBj1WRHEj4 1ifR+nNPf/YHR0bvVyHyZxoBGF5/J377B00FCBgDWH9btyCYd351koCD0YCZZWgAGD8SSEj4xxoL OBPTln3ht4ET2IEE+IF7hYF0YYFtN32nwYL81xhc1X/+J1wISIFeZ4IxiH2fR37X53Y9yIP0Yn8/ OHtx0Ubo94AZiIOB0X6Xd3siGIGl53JBaISt8SBD+EypR4VLqIMa9X/8JoQzqIVbKIUlCIVVaIUe eCS5VoYsQXst8SRe+IVsiIJnCHxTaIb4YSN1yHi2txIkCGt9iF4Q2Ibg94aBqBeDqIcrOC9P/wgi iaiIiwgVfwiJKWiIkRgZk0iJNziHReiCmZh8mxiHnaiGXeiJFDKKpBiFz3cUDuAAjeiI54eEohiC adiKd/GKnwiK1EeGLRiBNFhowVgWr1iMsDgTuvgSyciB//CKI7gqmPgYtDiGPvgaMBgWy4iMxniM N1EQzigQ30gQ3xiOuZaNp2iKODGNDhhCfMiEZLGM8MiNMGGMzegAB0GO5KhgMhGP2mgP5tiPlWgY j8iJv8cQ0DiMX2GM86iQOVGM92iP4AiR9WgQ36iM8riQQ8GP+1iMDXmRqxeN1CgRA/kUI+kecIiG YvGPQrGNC+mQ4iiR+YgQHAmQDPmPGrmRGf/JktrokTShkkdYgPGRh7i4e4RIFCqpkxaZlDYBEeGY jzOplD3Jk/7Ik8lYkx6pi0+5k1mpEz7ZklIZE13pevoolC5BlrEnfQSJFPG4lTiZgk0JkxAZky95 jEiJkWApj9nYlT65l7CokEfJkFz5lVGJE1gpmFOZhPhXlAWJkm64H0lhlYB5l4UJixFZmZZJkRKp feY4mdv4lFXZl3zZllB5mD/Bl5/5l6N5E2EJkDbxmSP2krwIfmGIjktph7PJjmoJm525kTPpkgOB j5n5m3HpjHQJmjuBmneplL1pnEmplxeZl3hpmDVhmsWJnKQpmtd5lw+5EG9pXqm5jrPnh4v/CYgJ 0pnDSY/C6ZvAOZGX2Z2+KZyzdJrFmZ2tKZWbOZ/XWZhTSZzBCZv+GZHJWZr2uZyoCZ+YiZ6Y6Wpy aYkx95G+eBb0qJ792ZkG+p/s2Z31mJn8aaByaZPSSZosqZ8dCYLsyaHDCZ9b6ZzYeZ92SZ8tKZMa 2p+VeZJouJrpKF6cESIRuo0ViqHjiKH/CaQVaqETCZ35iZ+8CZlsqZyUuaMNkY8tyqRQKaKHGZY3 aZEHup4JSqN1ZZZ4WIiO6aUU8aMm2qNkmqEn6o1w+Z3W2ZzRuZ+eSZUyqqbbOZFw6qKDOZ3cqJH8 OJmpmaXBWZImOZ4Meo7al4NscaYXep7D/8mkrima8kmgy4mT67mhQyqcI0qTe/qoeGqlkQmnm/qd vziUREmqSWcSYioQALCqqwoSrNqq//CqsDqrADAQrdqWfFqddGmX+umhCnmZCWGpKPqmnNqmo4mc a+mVX2mjpRqbiEmbo/egKwGrsVqrqvqqtoqtrHqt2DoTq2oPrPoS3/qt4AoAMEGuAbqbGOmXcGmZ CDqsBGWjVCqlIBqqUwqaOqmuSYqnPZGN19iNtgl9pEeoI0Gt0oSu5BquCmuu4Vqu3sqw5iquEfuq XOafwhqRP5qrFumh98qa9RqlgGmkG1uVghqsElmyXXqLiomWAasT6BoTCDuxMiuxDiux3P+6rdRK qwZ7qPQKnfLJq5t6lUELqpEanUvamGcJFMn4r1+hjhf4oGXxssqSs9ZKq9dardlasw4bsxIrtXl6 k5DplUcqtGDpoDzLsoOqsmFKsCjhFdNqrfXDtTWbsBB7rnVbrnertVIrtewaoNnJrEnSslyaEoPb thUoY16rtzM7t3lLtxQrt1pLs+1ouDtYjYe4tllIEjsht7Jqt5I7rp0LFIkriVCLskAih2J4m6lL E6EbFKPLE69buCcRkOAxuagYIJARuy4bsRVbuqQrHqgLrZKBqmIhtU6riQeYubcrlk54qgOrvLgJ nrq3hgjptomhupQRvOKZuWjLmGYLhpj/C73bi7Rn27TPG4uqKLyCKBIn0L7u672j6qwhGb2Gmr4i Sb0GwQ/8QBHtOxD9KxD/SxDu+7651r4xYcA16I4ker7fa78fZIAIWRH6+xATnBADfKgIbA8ZnMEw scEnwIz/EMBf2r3kyYoOvBqbJ7sWUcG6p784wcH+ewIATMAiPMMxXMAf/KyVYb0nPLupCr+veRL6 O8QuDBRFvFdEvL8CwcIsfMMYnMMD/BIcLMU5rMEffBADXMOLYbo9/IwknLJoKRZHbA9KXMFmTMT/ MMRLnMRrDBNFfMRjTMWXGMIyfMFaTMcX3BB3rLk/3MWrq8NevIuaI6ZNvChvzA8vMcRk/+zCjHzI izwQZ7wQe5zHeVwQ/bvHWCzDYEy+5iG9AtnHmyzIQQkWcQzJarzGqJzG+8vEq6zEqpzKFqzJBkHJ BGzJmvy/M8HBU1ybyRu/afnFBqnCmgHCJJHEZ8zKqTzByIzMr6wQInzA7kvFu2zFHXzFs5zFiPhb XOzDbFt7oFy7Sym7x+zKkfzKrLzIbozI6JzI6gzNc0zHAizLtizATMvDltusSSvK5SGMLAHH7bzO juzPa3zKzVzQM4zJgYy+82PCMsjLDCKNMjbGrmzQ5azMbFzPXXG8levH5WuN3ryYxkwQhRwRxlzS xmy+vjt/HK1is0G5wGzKJh3TMb3NxP/L0D1su1gYFiWdzvq8imq70vlMuzn6fhrNz0A9yD+9zwCb GUKdHPiswGD60N9MuE2NHMLc0ElNHjSN1VyGv9OqGFs9llk9HmEt1uSLqGmxswkBtwTB1lD9zn+M 1gsNwdn80h9t17zVu4yh1h3B1wYhq9wKkvOrvkZNv5wMxJd7v1OdECPJxds6EVabIaHrtQzLusRs qujXzTWN14y92J2t2Z/N2Vy9wCgB2BZhsHjbsKmduLJatWyt1rXq1qoq2LVog55t1oddqLkdyr48 whnNEi872RTbtQ3bqo9t3HDr11kbuTbB2pe9GWXN0rvN24mt2KKN2| 9µ&©ÎRçÁµ¿""C ê9#´fµ¶ì«H:NÀ¡Av$B üW=«¥: (°B7+½8¼×o»fDÓ¦a`Ø!ÿûÄðES°WÂ5³ë|ĹÄÛi¤IsÈ:íÀëüMÎ<ú}ÅêE"iè¿tëm'º0`BÁg®6= Ì4ÊýrRÉ 96á Ã\ÊÓr»I«ÁN³ÌÓ$oDÕqãcõ,VþZàaÂC(à ÑÊi(ÙXñQSEvòkiYR×ÊmÚ%hZLAME3.97 (beta)UUUUUUUUUUUUUUUUUUUUUUUUUUUUm§,ÍbP#1MðÒ¼é]bõÑøÖj´.(¦9¢1Ó" »{w*CI-£§k°å7 ÄÌE÷>ÍÓt®±OC©3ÍÂE÷L¥+W&ת¯ÄU= {¹þ? Ó8ÂÚ ;î¦ø® é3D d¥rP¥3JDíIC%k Ræt«Ò-»1fÌDþa¡s¦Ä«H«°ÿûÄÿ}]G¤Ù(³íµ"r(¬ú}·NÐâØ¡¤´â âZ D°®?@¬ë ²etY«Ö$Q1åÔWÏ,f\rn@PÄÊèÂRªªªªªªªªªªªªªª$Ñr[~¶ïÒ}6p}"^¢Ô¹G50С ¿úq+±9 }í½ 4.ñ=Ù7-VÆV¥çÍ¿u*àüðgd_2æRqFÒ.DöWÁB;è²ÿ¯ëÿTWTë²Q'Yßi6b#õÓô[Q;7H)"¤·ë.ý©§ 0Êåä|Ô¥[ÖÓÎÓío´àÌrVîïÃÿûÄÿqu§±2ý´j]¼1&Q&hY@ÐD÷öaIR¯mG¸ 9lb/6Uo+92Ah8hCx7dLu92HO527v9U0O8DcO929vz4WOGooP+Ai+976O5iIO+l/v+ACv0vecf17u vJlv+Vzf9Uke+i5Nglg/HIs++nre96O925E4++sr8bbPiIW/+qw/vaEoE/mQDzpx/MqfD5N/hSx/ +JUv94Jf27EPHQ5x/AeB/QJx/Nb/rvVHT/xaJfprTpuIPxjaXxDLr/wJgf3Jn/4vsfwwwf38/urU Dv7UD/RnLv5wnfujnhHyDxD2BArMl2/gQYQEDRq0VzBhw4IMETpUGFHiQ4wI/23k2NHjR5AhRY4k WTJkRpQZTa7cmNJlQpYmX84UGLMkzZk2de7UibMgS4sWOeJ8aXHixYFGIVKE+FDp0aQdf/KkWpUl UZdWPWLlirNjV5Vav4KFKdbsWbQiI2JlmnTtUopBGQat6BRpU7wOTUYEOfWj37Q7yZY9O9jw4Zdp EdcM3Njxx8VEF0qMe9ftxMtv8TZlWrmv3H+AN4oeKVRqvpCkY0a2h5b1a9gDqbJ+/1zb9s3YizvP tayQ8E/AfoGjHk1c9XG+xYGiDk589GWwinNPp15d9m3s2VtG1r41Z3PVHEkHDe28vHjmoM//Nc9e OXS7mzeXTz7b+n383Lvvd6x//+uYwGvPI9GcG+409Nb7qi34oKusIeXYM40+vvLDaigL8+NvQ+kW 41CmDFtb7rTwIiyurrYqm+yy4tqTy7j6ypuJwepcCzGnD3Osyj8dQQrxQ/mCTChF0Aokj0LiQqSR MLNuTKxHKFfjMUoMnTQsMJqOVDA1FyXrDcDCrESJSjJxQ6zMscS0biUwS+ptSdbgFDFMNR9C807v 6jyoMT2p27BPIXEkSUsfAd0TT/9EDT2UTkVpQxTEH90TrNE5H9WqBiwVtZHSKS311L5GP7WtBkxJ LclURq/clNPDRC1T0FTvc1VUU2vFNCRSO92RVQ9nhdJRMzP0dViOSDUWVZRyzTUlVJvktVVicwQ2 WmrNapZPrpYVSFtcS711pGONfbarajnUNUor+ftWrGNtsnU7mrRdTN5l6a3BHmXvrffYbbWVN91y +Zv21V4DNularfC9l6h/GV44WX77xcheiQfKV2GM/dX3YYzVNJjNgtEc2CqAT113I2NjahhiZjme qeGI+xVX4Yhjntlil3EOF+eDLvY5Z4rJTRQjUFW989yi8eMwZppzZjlep3t+OFz/e/ndt2KNK8b6 Yqil3ljqjL+mWeqOEAYy5I9PQnrSUM9uueqoJ14Ybp1vRkjjqefOu+O4ee7477Bx+vfdYr39h3CU Ub3W7KvW1pGxhB3vidJVU8K2Zb7Fblpvcbne2u+MsuaZYs/v3vlvew8/mSSEEVf9ddcTVx1soY+m vHJAO9QwU8yvvlrim5kOemXaAS/9Z5CaVfzbxQ1nqXWtO//a83zLXt3c251tO9Zx69z3d9ONH5xq vcNSfl3X3zW7ednbR1lr0MPHufBwYXe+/sNx71N3Q/XvnqjGZeh75ZOZ9LyGvuu9DlzMQ6ACZWer 8uENfvtyX+G6hT//1SmDHtvg//+y8qcQnc+CDkyf8xzoEcZtR3SfG9uyVHc+DLbrhQlMWu46WDKx eJAsadtPCkt4QvCJjnitkSH7EteuFO5qe9rT1GN0SBMejgSKGyIe9Y7HQPo1L4lM7B/39ocnTkVR bWj7j0t8eCvyAfGGTuKfDW23RDGmCVpxvE0YvahBMNqRjlU6Ux5vBKkm3pGDbwzkHuE1R5FJjo9P vA4X3ZhIOO5RkW5DZA5hJchGOvKLhGTkJck0MiqBsoaDsZQeIdnJKXKSlH7soyZ3uEbIwZKMoUSl V1hZyU/OUom4JJkutfMkVdZyTLdcZTBf6croYPJChnSiMD1JS1/2aJIB5OUujf92yg8KzJnZxOY1 CVajyUUznK3spqx4x8ihkdOStqzNs9p4zHJuU4fpVGcvxWkTR9WzO9z8pjy9icxFxbN2AF2mMtnJ THr6008IXeQ/renQUcKTof1U6EK1KUo5VjOiA12nRicqzYqC05hEOydJDXrQyN3zo9RMJWRCatGR cqWU0wSkR1cqpZd2L6HF/JjlZAnMm9ozp7GsKUwpCtFftfSXNA3qGIdKVKHaVFoqxR5VD6m0pj40 p5Q0qUA5mkt9ZjVtT82kWMeJVJBa9VGxiRZZy2pWlqL1cWqFq6vcWqm6goyu+2RqXmfqVr/i1KgX DWtg66jUkxbSsFLMHkEBuNj/MkaqpNOBbFE32VGpVjaxd32sZp3axex01rO24ewgxcqq0Z62tIX9 7F7R1djU3nS1rCUtbJYaydhOdLaZ1awpc/tRx/kTssL8bVAxyjbFFneuYVEuQ497VtA2V7rT/Sk/ sfNH6paLrdmtrWtD613uikq04W0neA9rXtsAgLxaTWZcaevcvt6WtxsCQH3r2xH7ciS/G9nvP/r7 2/huFqXiDfB1C5yd/+r3vwtWr3/vy98HO7jBElbwhCV5YLA+t7o+jalMEWVfEHsExBGWsIUTDOH+ ptjEEd5vi0l84te+t6nbbS1PjypRMrFYxxam8EdUPGEXAznEKAbJiCtMZPw+/zi/RmYwj9nb3uLy aqc2RtOQiTziBP/4yEl2soNF3OAmo3jHRTYyhU8cZC/ft8nonTFTaXze+UYJyyTecoXH/GMh11cg 9t2znudUZgWL5MxqLjOMlwxmQqsXIXy2B5/1/Gg/97nLo8WwrzT8ISsjGdBzJnOefRxhSUfa0ZGW 9EAOfeovrxkjjD7IqNXr6ofAGtaptvOrM91jQ176U8L6cJg/PWdb81jLmia1qUVd7BEzBstXpnOP R91oAEA72q2ONqlZnZBrl9rVuOYyhM3cbDwHm84wTqqMjWtbBAN70iV+sZXJXWdpL/rY0772pIdd 6+08O97Zjre0HQztfmt73v/4HnSwxdxsZzMZ3DtO9LjfCeUo45ElnGY3k+ssaCU/WNrzTgmruY1r NGfU2PQuNsD9zGyDF5zgt0Y1ko+s8nB3euXCbjfDP83mc2NXR1omN7WnnZF667niLg9JfwNeaqRn u+gUf/mY05zoX8983Msm+red3PKN/9zn+C4x0n0+cmwj3LOoFSxGw651k5c8lu/+uIT3TXK0n13Z 6vb0wUdyb6tvedk 0±xD mail1.frk.com hellerfin.com lore.ebay.com `jg@zt.gif Xùº@L¾ che.Jubert@alanyaotelleri.com amin@aglawyer.com ( [147.114.161.125]) Sat, 24 Feb 2007 23:30:18 -0500 MIME-Version: 1.0 Message-Id: <96A3A727.000001.00284@> Date: Sat, 24 Feb 2007 xREyRFMvDbM3YHEmU ZE3WFEzUNCdVjCxeecr/otRKrPRHzUxN4DzNkwTMvyzIryTJcjxNpoTLoezLpzzOUpTN12xM2gzH 7NxO21zO4+zMxwxM5EzIWTzOS/zBRzRLRrpM9CTP4oTK5PxM4HzPpozPndRG7ERKvbTPgSTO6JTJ 7SxL2KzN/cRGMSzJ1TRO+MRMlgTNwvRMehTHZYzEN2SVjoRPgnRMBo3QY/xQoaTPmTxGfeTOj8TE EF1JEHVQCKVGiARNvHRIPqRQE/WR+cxN8VTQDX3MqzTP+kxISKTD+ouz7pJK4URN5URPJb1H/6RR FD3RBF1QvrTLqHxRAHWJG1VJAzXM2fzOKb3SL61SCYXOBxVMHnVSKiyo/wq1UJ60kBXV0CSdy5PE xBrFzhkdT9O0UjHtTx9N0R0FTV2kUMNsUNVsStjkzxc0zfs0U6gyRDa1PgaMsRupTsLUUqTUQwql ygllURbVUE+1yx/d1KTUxj3sRCzt0710zVIsVWF8UbdcxTQdL0d9VLPqSbKkUf3cxgDFUzmtVEaF 0PjMTJ3UzmElxSzFS6hciUs1UfnsUVFFxyBV0zWV1vV6QR8UOUpdSd3UUw/10E690WB00jwM02zd k2VFVNkcTjMdzWil1gt112rtDzEp12P11fi8zkMVVBHlU3Yc1lst1rHQ0xV1zw2jSOrLvng92P+h 17ZMVzQ10MzsRiR9WP87xVflhFMgLdjIS9jF+knugdInzU/C/NaMrVMT5VIUhUm+LNAHxEjteiZr XU/4ilRIvcKr2sz/lMja5MdbNVbojFG9bFeZ5aETjCOPlTyLfFI79UOcDVWeHVKX9UnYUkEi9c2o bahOCU3RfNpZFVI6KtooSksDc0aktdmuldWvndq0Jdvvotm0gsZ/ENtZITtmktsivdqV2h2EAtuw dVuN3ViOxVq/hcekNdqj7ZWjnS6vJTAHHKvD5dvAdanB/VuRqlu3hdyeaK7EXa2ZZdsa0xOhLUTD pdlG1FvL9dzPlbhphde+vdzJ7cHELS/SVdt3HVrHRd2Yxdu1yg3ZxV3/ybW/WLVdg7HbPPFdxgXd 4tVd9oTA2m1HYuLB5oVZMYpdqKXcwTpbIOywyv3dqiUW4gVKMeHewq1Z4JXUoXJH4wVf0y3b7l3e 8W1ZWBXckOrc9k1d0zJfvMJenVPPswTcta1f+w3fyczf3mVe8u1f1j3g+L2c9L3Zy1pdBDZY/Y1g hI1e6YVf6A1eyYLg/YVd3h1gCpZg981gBSZhDFZdDt5gqL3g0A1hnQLhrlph5IXh67Vgs6VhF95c 123cyCzfEs5hIJ7dVDzh+5VhFJ5gyLzIu7Le/mXiD8bhcWlhjSBc2tXgILZdzPXg+YXiJubiK96m ZoxiJz5LKf7i852y/xlO4SR+XjPeLTQ+YiRGpTJ+qzluYwN+2zsmYoUa4yn0YjsW3TB+X+jaKj5O Ywb+4xhWYkM24j0u5C2mYrJ640X+4UdWY0S+ZEm+5DweZE1+XRsGZDzu5Cyu407+2yLNZFFmxsUN ZEwuZCte5ThOZRbOuRB2ZFNuW1luYAdu1Kz6H1JO5FiG2192YVumX0HuYQAW3wfW4lwm4E8epr2t YkqGZT3Gof8dZTJM5uPdZGTu42kWYO1tZD9GXx+25CnmXxVWZFp1m2FOz1yTZqKFZ+zTZvVd4GKO Zh4eXnm2QhPuZm92PHLm5qoS4Wf+53k2aH9mxm/OXlRm6DlE24IG5v+CfsYE5mSFtmhxbuchfmjh ZeaNVktPDmb/jWhsFuk1YeOLZmQ5Rul19uhaLuCQJukKxt9lnltQruZmtmZ1bumBFmjDyumY3umK PuiaTi2g1uW45WmVHmp+huPITeqj5uWFhui0augOfuoRTibAcmVWpl66xeqsTmmXduil7ujKKunI 1eF8zkil7uV5AmuKFmu2BmdIBioAkzK4Duu2NkOnzutDPmPpot4A3l6/rmtkrNbvlVekjtaz3uqp RmiilmuFVd6xpeddW+Kujt3E/ut+buq9phbMVtygfuybjuzPbqvQfufTxqfdXWw/dubG/mrVtuxt pmw4s+3cneVhueoIa8bt5CWKgAAAOw== --=====================_65937546==.REL-- Received: from host114-57.pool21345.interbusiness.it (host114-57.pool21345.interbusiness.it [213.45.57.114]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1OBZRbj046472 for <ietf-pkix-archive@imc.org>; Sat, 24 Feb 2007 04:35:29 -0700 (MST) (envelope-from Teresine.turner@agno3.it) Received: from Teresine.turner@agno3.it ( [130.128.134.89]) Sat, 24 Feb 2007 12:35:41 +0100 MIME-Version: 1.0 Message-Id: <7B90EAC0.000003.00422@> Date: Sat, 24 Feb 2007 12:35:25 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_1JTYUH1FXFP000000000" X-Mailer: IncrediMail (5252670) From: "Teresine.turner@agno3.it" <Teresine.turner@agno3.it> X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: <ietf-pkix-archive@imc.org> Subject: excerpt from --------------Boundary-00=_1JTYUH1FXFP000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_1JTYK39FXFP000000000" --------------Boundary-00=_1JTYK39FXFP000000000 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Wall instead in latest is story prophet creation koran.=0D Life pop princess anything thatin claims.=0D About and programs azall songs, things talkday.=0D Guide gossipfree newsletter, sign nowa picture worth.=0D Mediaon, todaytalk of nationwait, wait dont tell!=0D Othersdemi was born, charlotte dumaresq hunt has created many?=0D Faced challenge writing, biography someone whos, image she.=0D Berry halle sheen moviestop popreality tvtv!=0D Twelve addresses separated commasyour, message.=0D Wall instead in latest is story prophet creation koran.=0D =20 --------------Boundary-00=_1JTYK39FXFP000000000 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1= 251"> <META content=3D"IncrediMail 1.0" name=3DGENERATOR> <STYLE>=0Av\:* {behavior:url (#default#vml);}=0A</STYLE> <STYLE>v\:* { =09BEHAVIOR: url (#default#vml) } </STYLE> <STYLE>v\:* { =09BEHAVIOR: url (#default#vml) } </STYLE> <style>v\:* { =09BEHAVIOR: url (#default#vml) } </style> <!--IncrdiXMLRemarkStart> <IncrdiX-Info> <X-FID>B433CDFE-B71C-42C2-A5C1-D34C076A9851</X-FID> <X-FVER>4.0</X-FVER> <X-FIT>Letter</X-FIT> <X-FILE>signing_pen.imf</X-FILE> <X-FCOL>Business</X-FCOL> <X-FCAT>Stationery</X-FCAT> <X-FDIS>Signing Pen</X-FDIS> <X-Extensions>SU1CTDEsNDYsgUmBSTCJlZU0KDgsTTCdhTRNiZE0kU0kjTSFTSiViTSBnZk= kxcGNhUmBSYFJgSxJTUJMMiwwLCxJTUJMMywwLCw=3D</X-Extensions> <X-BG>cid:8CCD7950-9EB6-BE36-50A6-3A07B0DE5371</X-BG> <X-BGT>no-repeat</X-BGT> <X-BGC>#ffffff</X-BGC> <X-BGPX>right</X-BGPX> <X-BGPY>bottom</X-BGPY> <X-ASN>7A42E450-357F-11D4-BA31-0050DAC68030</X-ASN> <X-ASNF>0</X-ASNF> <X-ASH>BCEB29C0-42D3-11D4-BA3E-0050DAC68030</X-ASH> <X-ASHF>1</X-ASHF> <X-AN>EE860250-5330-11D4-BA52-0050DAC68030</X-AN> <X-ANF>0</X-ANF> <X-AP>EE860250-5330-11D4-BA52-0050DAC68030</X-AP> <X-APF>1</X-APF> <X-AD>601231A0-325F-11D4-BA2D-0050DAC68030</X-AD> <X-ADF>0</X-ADF> <X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO> <X-CNT>;</X-CNT> </IncrdiX-Info> <IncrdiXMLRemarkEnd--> </HEAD> <BODY style=3D"BACKGROUND-POSITION: right bottom; FONT-SIZE: 12pt; MARGIN= : 0px 150px 10px 10px; COLOR: #1c3966; BACKGROUND-REPEAT: no-repeat; FONT= -FAMILY: Verdana" text=3D#1c3966 bgProperties=3Dfixed bgColor=3D#ffffff b= ackground=3Dcid:8CCD7950-9EB6-BE36-50A6-3A07B0DE5371 scroll=3Dyes INCREDI= FIXEDFORIMOL=3D"true" SIGCOLOR=3D"11031552"> <TABLE id=3DINCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D2 width=3D"100= %" border=3D0> <TBODY> <TR> <TD id=3DINCREDITEXTREGION style=3D"FONT-SIZE: 12pt" vAlign=3Dtop width=3D= "100%"> <DIV>Wall instead in latest is story prophet creation koran.</DIV> <DIV>Life pop princess anything thatin claims.</DIV> <DIV>About and programs azall songs, things talkday.</DIV> <DIV>Guide gossipfree newsletter, sign nowa picture worth.</DIV> <DIV>Mediaon, todaytalk of nationwait, wait dont tell!</DIV> <DIV>Othersdemi was born, charlotte dumaresq hunt has created many?</DIV> <DIV>Faced challenge writing, biography someone whos, image she.</DIV> <DIV>Berry halle sheen moviestop popreality tvtv!</DIV> <DIV>Twelve addresses separated commasyour, message.</DIV> <DIV>Wall instead in latest is story prophet creation koran.</DIV> <DIV> </DIV> <DIV><IMG height=3D295 src=3D"cid:81F1A128-2C28-763F-C9D2-F51176FE4854" w= idth=3D291 border=3D0 name=3DINCREDIINSERTIMAGE INCREDIIMAGEEXTENSIONS=3D= "" INCREDIIMAGEATTRIBS=3D""></DIV></TD></TR> <TR> <TD id=3DINCREDIFOOTER width=3D"100%"> <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%"> <TBODY> <TR> <TD width=3D"100%"></TD> <TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD> <TD id=3DINCREDIANIM vAlign=3Dbottom align=3Dmiddle></TD></TR></TBODY></T= ABLE></TD></TR></TBODY></TABLE><SPAN id=3DIncrediStamp><A href=3D"http://= www.incredimail.com/index.asp?id=3D99000"><SPAN name=3D"imgCache" border=3D= "0"><IMG alt=3D"FREE emoticons for your email! click Here!" src=3D"cid:9A= 9EBD5D-CC17-78E4-1BC1-D454408CDCE3" border=3D0></SPAN></A></SPAN></BODY><= /HTML> --------------Boundary-00=_1JTYK39FXFP000000000-- --------------Boundary-00=_1JTYUH1FXFP000000000 Content-Type: image/jpeg; name="824-5AD8333.jpg" Content-Transfer-Encoding: base64 Content-ID: <8CCD7950-9EB6-BE36-50A6-3A07B0DE5371> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_1JTYUH1FXFP000000000 Content-Type: image/gif; name="References58.gif" Content-Transfer-Encoding: base64 Content-ID: <81F1A128-2C28-763F-C9D2-F51176FE4854> R0lGODlhIANcAYdAAAAAAHYNAg12DHF7AQAAf3QAgQh4dcDLw8rkv7HL7DEmBm4eAIccAZMZAM0h AO4gCgBLAB4/BzpBBGJBA387AKI8Cc42ANdECw1jDR1tAEBpBmNkCoFgC6JaAMRWAuRtCQqDDBGO CDl+AGiHBXyMAJJ4B8h3BuaIAAajABGoDE2nAGecAYinAJ2ZALSaAOmXCAW+DB/KAErJCWDHAIu4 AJS0CcG9AufKAADcABLiA03lAFbeAnPRBp7lBM7kBNbqDQABQh0APEIAQ1ICMXoASKUKQckBMukL NQIURBsmRTMjQWwmO3EVPqcSPMwRQ90bMwA7QCFGPD9ETGU1NoI3P6k8MrQ0NuI5PgxYOx5lR0Jf TGNtR35dAqRWTL1iRORsQQB8TiZ3NEN4QVl5OIKHR6p1QcN9MeSBQQCuSSGXOj2XSV2jN4qUSqid R8SsO9aZPA3CMi3ARTfGO2i6Q36xPp+7TrjHNu2zPgDmTCHqPEznQlvmRoHSRpbRTbvsPtHhOgAA dCEFjDYDgGoAi4sAhqkAhLUActoAjAAqjBcVcUMTc2ggjXcYiJoeg74UcdstiwBBjBc5jTNGjF0/ h342i58zgsg4dNc7fw5UdhNsjDNfjVpgd45deZVnfbJectRlfwZydy6Ni06MelWHeI2KcaJ+esON edKMhACadSaji0ebjmyUhIqehpenerWhfuanewC3hxrEdzW/iVbIg4XOcqnAeMvKdu22iAnojSLl fkXdfGzgd43WiKbei8DnhNzoigIAyhkJvUsKsmAAwIcBu6MJvMECv9gAuQAtvBkpwD0ls1Ycx40o s58YtbwSxOsltgBNvx9Mwj5Lw2QxsX45x5JBycwyuNFHwwBRxh5ZyEhms25ts3pbzpVeyr9Zwe5n ygCLyRWDzkWOuVWHxXx0s5GHt8WBs+SNvQqZvC6VvEebyFyhsYCgvJWZu8KVxtOXugC/uRi0wDHN ulnKw3THuJjKwv//952WooVxiv8IAAD1AP//AAIO//8A/wD49f/z/SH5BAD///8ALAAAAAAgA1wB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePHO2JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3crVKcivYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu37tuuePPq3cu371a7gAMLHky4sOHDiBMrLuy3sePHkCNLnky5 8uTFmDNr3sy5s+fPoEOLHk26tOnTFC2rXj0VtevXsCGynk27tu3buHPr3g00tu/fpHkLH078JPDj yJMrX868ufPn0KNLn069usHi2LNr3869u/fv4MOL/x9Pvrz52dbTuz7Pvn1j9fDjy59Pv779+/jh ut/Pv7///93lJ+CAwQFo4IEIJqjgggw2eBSBEEZYkIMUVmjhhRhWJeGGHHbo4YepZSiifyCWaKJD I6ao4oostujii3mdKOOMacFo44045qjjjjz26OOPQAYp5JBEvkTjkRF1B8CSTAJgUpNPLlmSlFM6 uRKTUVppD5QiUUkSlU1yGaaWVZK5pZlfcukSlmmq2eWYaKbE5khe0hlnlVG+meeZcN45VGBLEhQo koTGtVWYWeKpqJ1m1jmnnom2uaicj7rpaJ1nQrpnppHaiZKXmKr0KKeklhrTqKj66amiqW7a6ZuW Iv/KqKxwvjQqn2WO1NCg//DaK5wC9cmrr4UWy5kCyA6UrKDEBuBsQc8S5GwABRFL7AILGBSor9NS O1C0CmGLLUHiZvuttwJ1K623y2oLwEDE/pNsu/IqcBC9EDXQwD/6rnsuueZKtO27yiJrb8EMgfvv r77GG++56ArUr8T7CtRuu9h+SuatJxmsAEke5wqyxx+T5KxIJ5OkL0spl9RykSwCprBB/U4sUD44 50MQzgTNe7DFPyM8kAMOGOQzQUT/k7RASytUc8VPMyv1sATjO9C4AmG9s848Xx3w1hQdvfA/Cmst G872oD3SyS2/jJLb9qTMdgBr010SsijhjXfdJtv/falIGZ+k9kiDq6TvyiMd3gBJaBdO9EiPQ+6A PZGPzFLlJD3wAMycEwU3nnXqXbI9e6NM98uFi1Q43Jrb0/pIGQduj+yUcirl34Tnk7buqvNO9O+/ A74A7MOXFHvxpqOEeEyN8y5S6aXbo7jiLj2O+dx8rwR3ytZPLhLmwqN0vMqLJ17+y9x776qmKYn+ /MfR305m23YLT7vkLNfPuPOd999TqHeD3+hct7nXEbBvcdPf8sy3vzzVKXIQVF/t+GSlOr0sgt/z HgATmDyTYA9/b5sWTORHEgxabiYkHMnrVri5lSxQJIjbmwwH2EGTdI98OCwVlbrVrRpmTyXuI50A /9NUKvq1KU7AA55JDNhA/zlxJ6lz4MYqSEUEXlCCGSRiDqVXPi4y8IUdK1nIhHjCGn4QjKYToQ3V V7nooYSJKpGdHMvlQf29ZI6rytQGEegyuxkRbmgkY/SWR8guLs+NP0yk+IpHx9kh74BMrBzmbjgp lIDvfU8ckV1sdhCqDa1oTCta00YJSqWV8pMEYQADCjI9mzWMSQy52M/oRS/NEURztqwXQpZlNWCF siGqbEi5xDWQXOZSaBEZptZoabBYBg1owSJYNB0mTalFs2AeuyUuj6nLg8yMbBFDSLTUBU6vmROa 3RQavh5WEG4OhJPGiudirIa0JJayaaZsmir3Gf/MdIVzZvgiJTLrRc+CFJRe+Ezo7/yJEIFa81eo dGZDZDmQfv7DohddpUQo+stP4hMhEICAQUIqEIzy0yDfZFiT4FXNnj1zoAQhaUFkqhBPXnOaKy3p SQvi0JsqhKYuladQGZKVkKZElSNBqkiMOpKQMtUeT30qBShAkqlStapXXSoESsLUqZbEqizBAAZQ IlaSPJWDfbObV0+yVpG0FVNU4gAHThLVreavjyJRal4ZkMeX6HWvbs1qYAWbkrbao61/tcc+16fV ptoVqo/9KmH7qkXKouSsZn1sW9vKVMz+Va97TCpfM/kiwMDypgIQQEFSKxCg/sOpAhFrQWT7D7H/ 2pa2BEGBblEwENfK1LWvFelCcDtbDPQWtj5lqUB2y1zeBnemwtVtQaT7j+ZSN7jIZch1l+tc4tbW uCrNqUK8S1vWrla1DXFqdiFrEsyair2ZFUlZT5Jaso71JLolyW5bUl/6CkC+9x3JfPtrDwKbikru Ncl8uRpZ0lZIMKmN8EC2W13nAlemOMBBQTI8VPn4NrrOdRdCYEDiEpMYVm5ayYJLMt8Tk8TFZ00w XdXr1PY2WCQZdjCGOgwiJ+ZXvyjQsZCH3CIeG/nIHSEyaZHM5CY7+clQjrKUp4wfJVv5yljOspa3 zOUul4TKYA6zmMdM5jKbmcpjMo1NCMBmNleS/1PAiLOc5+zlOmvnNG0mwEDiTBA+7xkYOH1YnvXc kDlXS7w1bSlEw3taNg/E0SxN80KE1dIwPcSXzKImohMtzdMu+qHKvbSwBAIEIBik1AVp86H79JA5 +znT7DyzrOvjK1STutSmvrVPrdVpRSME0gPhBz+CPexJK3pQwkaITQUC7Ik0O9LQZsgrK91SOfcZ 0Ax5NrCpKeKJcPvQq07Is6X9ymgzbCC2XvWmPz3rdg/ENqUuSZxFQmd7zFtTdbq3TNxsWZaECkx3 4rc9BP7eEcaJ4AMnQEvg2qiGozBOVNL3SCTOPpgg/L1/22BoT3LxyuIb4lMkU7ztzDnU8Bqnu//u NUHG7ZByR+TbrwZ3cmNdaGyDOtQKSTe6cy2QmNM80Z0kWMx7bnOcv/zYSJ+ar9mdbUIr29eDetjJ H+10xpB8ywxH8ccpu3GUILzrZapVwgetcNuZiewdnyBJOp52j7MPdzIBYNSTnuqqQ0TTmIYoO38u 86cHPblGT7m7By8Q22Qd4KRCfJZUxdgUq31VGnc82B9f8co3foppijTfpU6wb99c1N0G9cD8DvpA A/6mnA893wnPes3gHeWaX3rggU56Y3d7752ntkU8//nQG93lve+7NXl/+pbT/aHLDn7tQ516pp8+ +a03s+HRJKZKVVFUjO+39t1udo31dfLef3P/wd8Md4xn/8Ba+jf1z38S9W9K7OKnfPf3JPf1b//q PTI50ucOfJqv3vnKN3tzt3zQd3R/F4CBN3UJKHuZZm7sFi/j52/2tyigAnKn4nAVV4HtN4ERiH88 on/uUk2e9oAqV3wEWIK2J3O4p4IMSG5B12stOHMKOE0ICGtQZ2kHKDDHx3y6B24Gh3mwwij9lnUe 2D+nsW7AB3hUM4LGNm3/922sRm6SZnwJgYO7MoWaF4JMKBjEt2gzaIJNuIVWCHhvV35F+CPRl4aJ 4Ut5B4ZqOGVnGIfk8YZ0WId2eId4mId6uId8aBZy6B59GIiCOIiEWIgQ8oeImIiKuIiM2IiO/0gS hhiJkjiJhfeIlsgVlMghl7iJ7ZGJnviJoBiKojiKn8GJOEKKqJiKZGaKrGgcqviKsBiLssgcrViL ttg5s5iLulgst/hEu1iIvRiMwviBv1iMFzGMyJiMrWGMhqiMzviM0BiNtcGM1FiN1niN2JiNHyGN p6iNvMiNf+iNswaO5FiO5niOTSGOdoGO7LgU6viO8Agc7TiM8ViP9niP+JiPhDGP/NiP/viPABmQ Askg+liQBnmQCJmQClmMA/mIC5lkDRmREjmRFDmND3mRGOmHFbmRIpGRHgkYP0FjTzUmVSFj/Ohi HOkd6qVVKzkSKPmSMMCSdlViLhmTKnZbAf9WYBEWYQKGkyWxk//lWPFlDziZkwBmWyOhD/rgXyRh YCiRYTlGlAu2Ys0FEyuWE07pE7IiEkDJkyMBlTnGZBz2kQMBlL5BU8tGYgOhlgLBlv+glAMBlXGp YQtxXdfllqInTbiFW+YlEObVl335aYMCXACoXSFWYmsJA2WJXv8QmD8lXA3RXAXhlv9HETQFXI75 lvowEHApEUrZmY95XKIZhpUpkh1hYniZEHYZYguRmuPIGhp4EyLZlDs5El2ZFF4ylQHWWTUGX/bw Y/bwmUsZnMOpEgR2nEFZElFpEkpZEs1JnCTxnDBpm8kpfihplQEmnCLxnFf5EiZJgWSCkjL/BpY4 QJ1eiX2V5JTPGX4s8Z15FJsqUVctcZ3XiRPIyRL9lZXyx5H6eZQrhihz0psJRiX79ZtBZqAiAZz2 sJw3cZ9cmZwAp3g66Vi82Z6P9VQKSp3sCSkMGpXT+aCXNZsigZo2iZ/JCZY4Vp4IGnfsh1m8WWPk qaK+yVQFyhL1WZ9XmaHKKaM32RJRiaILyqP21ZMtoaM88aHoCX4gmpJCOWNNag9QEKVQKqVSag8j Z6VAwJQzalcVen8GZ57nqSdQUidgAAYaWl/9mVktOaIkCqYEdqM2WaYkIaf20KYjoXME4Zo5qBB9 OXqDgqcOkZnL92mUOYD/AAdwMBCI6oYF/xGljQoFj1oQi5oRemoQfylhjcmYVYiCClGpGlGABmFi Okh4sHknV3qliiehXlKmrGqmWHqnWSoSuBarP0Gnr3qls6J1GgopjmcS8Yar9mCrxhmUwDpyuDpy aFqdweqqJiGsKeGsKHGqsTqrIgGtC8d+TklgXiKtKMYm4Oes4MqslvdwLiGnrbqs/AWUL9Gq1moT 7CquKYFrMwGsDkYaLPcP6ZavuWZrtgZskKavuhaw/5BnX+GvhPZss3prOgew+IprDMGvPPcPQ/dr B2t3kNZsF1t2BJd2HXestKoS3IqlI9d2IPuxKoFwAnelAsdv9PqqLlGsJospLTuvJhuv8v8qsjV7 Er+as2vCfi5Bsjp7szAxs744GhPLbE5nsEi7tIKZezTYtFR3rxmRbAJBtf9gtSoFewKrrxFbe6CK tVartDxIbGQ7EsJmtvwgEsK2tmfbrewncBWYfnLbEhSXEihbdi5rb8AwcXtrD23rt2mrtxaHtxfn fmXYsz0boefHb0CbEnVrE0TrfUoquEz6nteXeNdHJbPqsdSKudw3uRojoToEhLq6so27sWW3uai6 ld1qEnlGEn8LuGv3uj/RuX+7tiSxubbCfvCZcJbbkYM2ewuxuQcBqOFVEEd7EFJbEGxbtWvbEGK7 EDGXvMKXENRLepVZmVRGG6zbvZl7uTj/YbjBCH6sG4S9Cxls6xKxG7vo6aVqy7aByxKPy1grYbqI W7lCEbkXyI3z64+gi7/7mxP6O4yNi47/C8BMccAIvMAM3MAOrElkCRsPPMEUvBIRfMEYnMGieCEK DBkkWcEdqcFfwcE+e4FdB58nXL6P18Eg3MIocYRjSBHaW5gZsXrLtnmcuqmD58KsaIYsGrrlx8Lc t4G6msLu24E8nMTfEXkfhyVzUn+/e8T3eyVUJLrsOXkfrMRa7B33kz0tYzBCNERhDMaYVMaOFBSI FEIJ9EHaw0M0IcSLKMKgURvKNDLRM0NlTMZ7U0gg9BOXhBI5wzuB3BJBNBNp7I9yXCxa/0NODFVO jsxRPVVQGSHJrHQ4FANPCIE1ZqMQCmUsW3wjsdEuilNPHbU0NmUzrlRN7mQRq5zJxPQP5dIQ4JJS BxHIXZPIuDwfCrPL4TQxvlwxy5ZEYFNMD6AR2+QQzOQQvJzLzAwiymRQz7Q00gxKHNXMA/LJKpEc GCXLPFRR/LRP4PQsWKiH2JzEPNRDIrlVcrXO7LzO5fzOFoIchLkQXSmo1nzPmgjPuIHP/AyL+vzP AB3QMNLPySHQNkLQEmzQFDzACl0UCN1k71qmFyHRAkHRi9G1ntHQ//gaxutsdmcWHU0RH01qJqLR SsbRXQu/sWeD0rS8HuHSEEG8RFd0D/9d0xBCLKpGeq/2avw3gq5G00/naVY4w1V7tcomTyZdkTLL syLBb/BprFDd1ISLtz+Lt5jSvyqRtvFbElTd0DY9H0M3bqoreDe109gWvVTIqDGN0cGCGEktkK/x hTYVvRlLdWRNmjl8EVs40vXx1klMhCPBuE5dxbC6dZR72HY71YHd1TdRQVzt15DdEnHdgywdtTm9 aGLLfy54bkwrvC3X1oLy1aIdZTccw0E9gkIdgy/ohKo92q7NZEQNFq392rRtESkCxztRwi1c22dm 2mEW2YjI28LNkMBdHMN93Mid3DWiZbpd3M7tIq3URWqcE3Y0xiHUQ8+d3ZZxztWNFIf/DMj8UxMk gzIm0zHX3d3aDc+mccsLQTLP1M0yvHSMDN+O/BDUEk7tVMveJC3Kfdzcy36DE0WQojYCLn5yUz8v BEcsEzdAdBLb1EJpwzjpPeF70Up1o0aThEVlbEIq8eCv8zl//MMmQcba0yVfQuEozhchPrrE00jW LYGWFDwMlBMy/iQsUTwSpOHh0d/Rlxsr/lmjJUnqw0/XuhJtREM14T06Pjo6Tjl5RRKjleLvDBvb nJetJVzZZVUUAEwaBV1XPpqevRBb/g9jLoIDMeZkw9+vFVM83uaecZmQOVJxTlNdSRDepZrWNWG7 VVzg9VwQQWO5teenPWG55eYIIeVF/7WmJ7GcDKoS65kVJYoTJobo6s0cMfoQd04XfS7alI4T+DHP hh4bnT4c7tmKoX7qqC4Yo77qrN7q3ZjqsB7rsl4grv4gsz4jtYjVtb7rP4HbuHl+8LehMjGzdQK/ 7MvryE4pHdwnRQF2uh5/16omsZLs1B7AvOqzoQK/i91mfFtvFCS3HDPEFLTtAvfs485xVO3rG4nc t4E74Be5VMLtUfzUTD27ROy54h52KCFxWVzt/u66Xd2r+7kqXze3vivVR4x2lqfA8g7wiW2Lt+4h vKa9eGeoONfTqX2Fgx7mV9iFHB/xIL971EbxlG3xZL2Cm63Dag10X1iDIf/yd7eDGv8/fCbvhRYP qr43tko426Nn5Su/w/+uIaaBhTNc8U6rbks48XgNgyP/8YEmgkO9bn0d9LY4ubit7r9O9Q18HLG9 EV3/Fl8v3NjM9bPt9VIP82if9suh9bcB62z/9nAf93KvYzXdHl0MI5+TN0gex2o/HWEfIcsyTvhd vX3fz+BcEIefTF9DF60sGO79UuLkLVWeEI2vipFdGtmETZDPEB/lEZlvgH4e32SxzJvd+Spf+IM4 G4qu6CEqoFx6YyEKE4YFE6XuErUPWb0ZEzEG+zYGWFJJoU/1zYk195WbrCBqYOqaoApaVt2ZEs2f ErdvEv15Wz9Zm8rPXD25YmEKYEX/eqDK/6TwhWB21V/yqZPJmabE70SloZZsyf6KyV163pbvP5dj qW4xBegMAVTpzOe29eXyDxD//sGAIfAfAAAGERqEAMGgQBQoIEoU2PChQQECLm4UiMHjRwwPLTJ0 +M9jxZIEBeLAwfGkwZccZc6kWfOiPZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtVq 0Ig4I2a1x5WnR5wZd2YU0LMhzrM50xIVm/OjWwxw5doD2xXFUK8EdbYNW9be2qR1cQr2arfvYXt8 9S3eKZhu3KuRJU8OatPyZcyZNW/m3NnzZ9ChRY8mXZozZdRmIaBtuPqva9atXfPF/4kQ4U6WOnPX BmB092DIwBEjblt4p23bORnn1MscBs7mSgG/xvnb3u66xe/q/l3YeGrw4cWPn2ra/Hn06dWvZ9/e veaMGDUKjE9//r/6Kh9G/Mff4GIAAZQvM5Yeqs8+lEQqqb6FXAqpowfxu8+kCClcqSXPDkTwn5ES lPBCCDlq0L+J3jPxRBRTVHFFFlt08UUYY9yow4tG0k8g/W70sMMGOdLQph7/KdCgIYcE0cIPNzJS SAyR3HBDHTf7kcGEFKqyQSyvrPKgKq2zjjwwwxRzTDLLNPNMNJWS0TwaFXySLA9JknOggmRqs6Yg NaxPz/l6zFIgMMAwKFBBBQoyyf8DDzV0S5p0vNHPP7l8k6z7gADiIUvX1HRTTjv19FNQQxU1s0Bl KnVR5BjFLFOBWP3n1MtcfbVQQGk9ldBaHyKU1n8s9VXWXw0KFkhVZfrV14t2xXXWUZt19lloo5V2 Wmo7PfYiArIlwCZtt231UmHB/XbYbKs191x001V3XXbbdfddeOOVd1566w01TXzz1Xdffvv191+A AxZ4YIILNvhghBN2yl6GG3ZYM4Ujlnhiiiu2+GKMM37qYY479vhjkEMWuTSNSzb5ZJRTVnlllo8a +WWYOW15ZpprtvlmnHPWeWeeey44ZqCDFtozn4s2Wryhk1Z6aaabdvppqKOWemr/qqU++mqss9Z6 a6679vprsMMWe+zKqjb7bLTTVnttttt2+2243SV7brrDjPvuquvWe2+++/Y7PLwDB/lvwgtHTXDE E1d8ccYbd/xxyCN3z3DK55b8cswz1/zuyjv3/PPPNxd9dNJLPxd01L02fXXWW3c9ddhjz9n1pmW3 /Xbcc9d9d35p9/134IMXfnjiizd+M96T//p45pt3/mXlQ39++s2jt35r6rPXfvunr/e+PO7DX/N7 8v8V/3z009e0fPbbN0p9+OOXPz3367f/fvzz139//vv3/38ABlCA15tfAQ14wM8MUIH+QqD4cpaq VPEGgskZCgSPQ0EJsgw5OqHg/wR7c8EP2gODGMwJCUG4wRPeJioozCAHI+jCEI5QhXtrYLpUNsES zhAoJhRKB3X4QhHqcDwW7CEOe8JDIPowhiSU4RJDmMMnwhCKUgziE1lYxSI2kYpMnKEWF/jFvnmR h0cUYlC46MQulpEnHkyOCZuYxg+OEYRTXGMZk6hCN/4Qj3uMYhUVZZuLQIpRgESVIIlFSC5tCZGJ fAghHXmoRdZQfijLYwvNqEafIJGPSjRKHqN4RjryJouhhKIQicjJOWYwgpr05A7tuEknZhGVrJzi Kk2JSTDm8moK4CVQeKmAoQRAmEURZgB4UkycLECZ9lgmM5tJFGUuYCfI1Ak1cf9iTWsWxYs6aUA3 uznNYQ7THtT8JU/Kec1wGjOdxtzJMp+JTnb6xJoGKaZAilnPf+CTJoDMUpWiuZF/2lOY+QwAQQla 0IcEVJLzO9k5ffJLiDo0J9kMigMsyhOLOgAnGbUHRzlalAeENJWk/Kg9JEoUalIUJ73sZTXXOU5x 5kOmPJFpPnLiUY1etKTwhGk8O3rRn5zUpC1FpjhVak6WJhWYWBxpOZM61KXmpKZgWmhV06NPjtTU MlitCVcPKpCQPgCsYg1rZrh61oEa5JeNRA5mIrrWi6wVrgJF6EDx6c2N4NUg0VTmP/i6gI3IlZds VWRb/zFXtQ72HxldrEUb6wD/m+i1m//Qq1exes+CYnYjjLVq/E4WzZz8FSdhHcpOL9nHWQKxgkL8 a2t1YtqeijMooE3mO6F625yc860bBepre/tTnMK2psOlIh2Fes6P6vS3D23pbnt6TNn6sTeqXWlL dXndrJ30nKQVCm1Lu1zg4sSbOfHmN0EqUpf69Lm5tS501duTne50uFOdqGwxW92oshecRb3nTrhr j/9qt6W0ZCoRgYLNewoEsQpWLF3tmuC4NrizE5YWWhEaSZlgeJ9BQqRC/5qZsj6EswYZMSMzrKjA SniuK26wh/mKqkAe6sUCmbGVCsuoy6aVspM1iF5NnEgUx/jGPfLxjhsg5CHn/5XHFEYfylqjkycz NShCPa0lw3tT2LoyihTNZkn12Mc6WnGGDCBzTsjMADOXOc1qRnB02RtVod5yJw6VaHJ/W9KMghej d96pbtv7ZkAjNb/2YHKhR3VmgyD6H2dmtKIJuxnZtIkCk37IpCmNmUi2pkY0snSiySwQR9NE0ygp yaJiTJJSc2jUjQ71RTotkFcbJNawvrSnG/0QnLB6J5bWiaUpIBRe58TXKQTzeo2NXWSHjVJkqViU 1TIdZyeGNsv2i1CoTZut7CTbJtu2VrqNr2gnW9zJNmG4nb2V74wbN19Sd7t7YmjnuVve86Z3ve2N NHjnW9/Au3fJ9v1vgFOv3/8DJ3jBaRhwhCdc4Qs3l8Ed/nCIR1ziOmF44Ca+QJvwQ+MafwjHM9Mt bxkWxpgO8olvbOORp/zHFfeUyQxsZSnvTVs7mbk9QJ4tnty8W9p8OSlLGUdQ2lznOBf6zcvUxj0m pebS9XlQNt5JONJRiZ8sOcvx9khGaQtb5erVscRlGQ133OMbgaCNPYins/9j42vfONkVBQy4x13u wFD72AXSdhOLfOWa0bpA+v6QvwvZ7Cffu9j5YZC1ZyZVGwG52yOp9b5zne+Sv9a4ijJ3o9Rc80TH 4hVhfvHdBT3mTI07TuROFDk2vcBl9BXPi710LcdeJ62fvaUsKfqjVLL2tB//6R0/yPswj7TKLJw5 7IvPeXu0XvlAUAoiy174mTSe5AlZvPOfL3irKw7DWMe+9Yslk8Azvltb95bfy4/yy4Q97IQt+eMl b/6QGxL9mlk/+7/vfe5DX+X7B3s/0e99lOOnKkEKLeIjnguizMM5BSSAovu510M+0NMdAmslKUs9 4QuzWyq24holMtLAn/sJCpS6qFM9DrwkBAw+VQI6FQTBV/LATDLAFtompJtBXELBzrsNC5SiHNTB 6epBNCo2/cs+GMmYCczA26vBDayjEyTBJJQ9G2TBJXzC0UstqvOgEmRBH9yJHxNA6uunCeK/+jO5 lMu/lau+tgrD+XukIBQ8/zS0PyAbpMUTkaoTwhYhwhaEOSp0PSycQs9rQiw8JTbiwWILwRjsudFD PTj6skMUoyw8xKbbwRM6whX8vBy6QRcMpalDQge8RBjCwSsyoguMQNwpwiqUoD50wuAbI+qixBcc RCScwVa8QE4isNwzwk20wUycxA6UwhJkxFh6QUtExF9kul7UxA9ULRrkRVEEmHfZPv97NEZqw/lz PL1zPGtMvyALwy+UQ1WJpPzzxjkUQ2jcQkiSvzfkv2k0NcXjMPkDQDmEMWl0x3M8pHTUMjTaIkhc RmZsRnYkvP97xv77PnIUyMKTRv2rP3kcx/37xkUySOwbQ3OEyCHTEoIER/+C5MaHJEP1o8g1HMeG bMNyXEd/lEg4vEg6ZJGSQSVMHMFT3EWXrEAxQy1jZEUL3KYmlMFEZMJiXKIL6r0v00VczMfP88V0 VMdCMsnBU7lqxEiFRLuRLMOEPMkYcblVlC5FNMXVcsWeLEQwE0o5qkmqe8lOxD0UYiNONEWbhEmV 9CO0fCErhDpXbER4DEepfJ1dai+IEgrMSik3syZDZMWeoLLY2svakiad8K5Aq5zyWsw3+7PB1Mdk q8shhEzKrEzL5B/JzEzN3EzO7MzTuUwB8kzRBE3SLE3TPE0tFE1DQ03WbE3XfM13U811gU3arE3b vE3skU3d3E0bwk3Q4031ofFNrQFOJhPOviFO5ExO5DHO21RO53xO6IxO6ZxO42FO67xO9qHOtsFO yNRO7/xO8AzPfeNO8ixPuhFPpzFP9VxP9mxP93xP+IzPwkFPyZRP+7xP/FQY+oSW/JS4/SSa/mzP /4TOAC3QlhlQBE1QBV1QBpUZA31QCI1QCZ1QCq3Q22nQ+rTQv8HQs9HQ6+TQmfBQER1REi3RZQTR hjHR6EFR+lFR/2RRGAVOF51R24xRG71RIaRRHd1Ri8FRq+FRIA1SIR1SIg1SH2WYIs2XI11SJm3S pElSKL04J51SlotSK4U4KuXPK93S5sxSL0UcLkW2gAAAOw== --------------Boundary-00=_1JTYUH1FXFP000000000 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: <9A9EBD5D-CC17-78E4-1BC1-D454408CDCE3> R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_1JTYUH1FXFP000000000-- 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 l1NHDnrO070557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Feb 2007 10:13:49 -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 l1NHDmLf070556; Fri, 23 Feb 2007 10:13: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 smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1NHDlON070549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 10:13:48 -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 l1NHDdVn011474 for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 12:13:39 -0500 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 l1NHD0WF012318 for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 12:13:00 -0500 (EST) Message-ID: <45DF20F9.2040506@nist.gov> Date: Fri, 23 Feb 2007 12:14:33 -0500 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Thunderbird 1.5.0.9 (X11/20070111) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: draft-ietf-pkix-rfc3280bis-08.txt 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> All, Draft -08 of 3280bis is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt. A diff file highlighting the changes between drafts -07 and -08 is available at http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-07todraft3280bis-08_diff.html. Here is a summary of the changes between drafts -07 and -08: 1) The ASN.1 for the privateKeyUsagePeriod and holdInstructionCode extensions were added back into the ASN.1 modules in Appendix A. I was informed that any changes to the ASN.1 modules from RFC 3280 would require a change in the module OIDs, so now the only differences between ASN.1 modules in RFC 3280 and 3280bis are in the comments, with one exception. The ASN.1 module in RFC 3280 defines ub-emailaddress-length, the maximum of the emailAddress attribute, as 128 characters. However, PKCS #9 (RFC 2985), which contains the definition for the emailAddress attribute, specifies that the maximum length of an emailAddress attribute is 255 characters. So in 3280bis, ub-emailaddress-length has been changed to 255. 2) Section 1 (Introduction) now includes a notes about the relationship between the ASN.1 modules in RFC 3280 and 3280bis and about the relationship between 3280 and RFC 4630, which will be obsoleted by 3280bis. 3) Section 4.2.1.2 (Subject Key Identifier) describes two methods based on SHA-1 for generating key identifiers and sections 4.2.1.1 and 4.2.1.2 each contain a sentence recommending use of one of these methods for generating key identifiers where a key identifier has not already been established (this is unchanged). These sentences in 4.2.1.1 and 4.2.1.2 now explicitly state that it is acceptable to use a hash algorithm other than SHA-1 when generating key identifiers. 4) In section 4.2.1.3 (Key Usage), the description of the digitalSignature bit was slightly modified to clarify that "an entity authentication service, a data origin authentication service, and/or an integrity service" are only examples of the types of digital signatures that may be verified using the public key that is in a certificate with the digitalSignature bit set. 5) In section 4.2.1.6 (Subject Alternative Name), RFC 1738 was replaced with RFC 3986 as the source for rules on the URL syntax. (In the remainder of 3280bis, RFC 1738 is still the reference for the specific HTTP and FTP URL schemes). 6) In section 4.2.1.10 (Name Constraints), RFC 1519 was replaced with RFC 4632 as the reference for Classless Inter-domain Routing (CIDR) notation and the example address range for IP address name constraints was changed to align with RFC 3330. Also, the reference to draft-ietf-pkix-srvsan-04.txt [SRVSAN] was removed to ensure that 3280bis could advance independent of draft-ietf-pkix-srvsan-04.txt. 7) The descriptions of the use of LDAP URIs in the cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess extensions (sections 4.2.1.13, 4.2.2.1, 4.2.2.2, and 5.2.7) were reworded based on comments from Kurt Zeilenga (http://www.imc.org/ietf-pkix/mail-archive/msg04434.html). 8) The final paragraph of section 7.1, which describes matching rules for DNs and RDNs, was reworded in order to make the text more clear. 9) In the references section, RFC 2560 and RFC 4519 were moved from "Normative References" to "Informative References". RFC 1519 was replaced with RFC 4632. All unused references were removed and a few new Informative References were added. 10) A paragraph was added to the security considerations section noting that emailAddress attributes are not case-sensitive (as defined by PKCS #9) even though RFC 2821 specifies that the local-part of an addr-spec (i.e., RFC 822 name) is case-sensitive. The paragraph notes that this may lead to problems if an email address is included in an emailAddress attribute and the mail server that hosts that email address exploits the case-sensitivity of the local-parts of email addresses. Dave 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 l1NFo4kW063626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Feb 2007 08:50:04 -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 l1NFo4BY063625; Fri, 23 Feb 2007 08:50: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 ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1NFo2wN063618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 08:50:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 81F9226E7E; Fri, 23 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKcgM-00026M-BS; Fri, 23 Feb 2007 10:50:02 -0500 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-rfc3280bis-08.txt Message-Id: <E1HKcgM-00026M-BS@stiedprstage1.ietf.org> Date: Fri, 23 Feb 2007 10:50:02 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=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 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : D. Cooper Filename : draft-ietf-pkix-rfc3280bis-08.txt Pages : 144 Date : 2007-2-23 This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.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-rfc3280bis-08.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-rfc3280bis-08.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-2-23095718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3280bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23095718.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 l1N4JgOB007585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 21:19: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 l1N4JgCw007583; Thu, 22 Feb 2007 21:19: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 mailhub1.uq.edu.au (mailhub1.uq.edu.au [130.102.148.128]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1N4JdIZ007577 for <ietf-pkix@imc.org>; Thu, 22 Feb 2007 21:19:41 -0700 (MST) (envelope-from mcduff@its.uq.edu.au) Received: from smtp2a.uq.edu.au (smtp2a.uq.edu.au [130.102.128.17]) by mailhub1.uq.edu.au (8.13.7/8.13.7) with ESMTP id l1N4JbqJ067957 for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 14:19:37 +1000 (EST) Received: from [172.18.0.71] (uqrmcduf.vpn.uq.edu.au [172.18.0.71]) (authenticated bits=0) by smtp2a.uq.edu.au (8.13.7/8.13.7) with ESMTP id l1N4JZl5047281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-pkix@imc.org>; Fri, 23 Feb 2007 14:19:37 +1000 (EST) Message-ID: <45DE6B51.6070500@its.uq.edu.au> Date: Fri, 23 Feb 2007 14:19:29 +1000 From: "Dr Rodney G. McDuff" <mcduff@its.uq.edu.au> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: link: draft-ietf-pkix-lightweight-ocsp-profile-08 X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UQ-FilterTime: 1172204378 X-Scanned-By: MIMEDefang 2.51 on UQ Mailhub on 130.102.148.128 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At the direction of our cognizant security AD, the following document has been updated to change its status from informational to standards track: draft-ietf-pkix-lightweight-ocsp-profile-08.txt I am initiating a (less than 2 week) WG last call on the document, since we have discussed it in its prior incarnation as an informational document. Please send comments to the list by the end of next week, i.e., March 2. Thanks, 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 l1L0nlaq084077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 17:49: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 l1L0nl4a084076; Tue, 20 Feb 2007 17:49: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 mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1L0nkPq084067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Tue, 20 Feb 2007 17:49:46 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-221.fastq.com [65.39.92.221]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id l1L0nR09092588; Tue, 20 Feb 2007 17:49:27 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org> Subject: RE: WG last call Date: Tue, 20 Feb 2007 16:12:37 -0800 Message-ID: <CCEJKFKLBCNMONJMIEAMEEMICFAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <p06240505c201359aaece@[172.16.1.67]> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I have no fundamental issues with this document going forward as drafted. Mike -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Stephen Kent Sent: Tuesday, February 20, 2007 3:38 PM To: ietf-pkix@imc.org Subject: WG last call At the direction of our cognizant security AD, the following document has been updated to change its status from informational to standards track: draft-ietf-pkix-lightweight-ocsp-profile-08.txt I am initiating a (less than 2 week) WG last call on the document, since we have discussed it in its prior incarnation as an informational document. Please send comments to the list by the end of next week, i.e., March 2. Thanks, 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 l1KNcJEH079070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 16:38: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 l1KNcJll079069; Tue, 20 Feb 2007 16:38: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1KNcIID079060 for <ietf-pkix@imc.org>; Tue, 20 Feb 2007 16:38:19 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.67]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1HJeYr-0003aD-4M for ietf-pkix@imc.org; Tue, 20 Feb 2007 18:38:17 -0500 Mime-Version: 1.0 Message-Id: <p06240505c201359aaece@[172.16.1.67]> Date: Tue, 20 Feb 2007 18:38:12 -0500 To: ietf-pkix@imc.org From: Stephen Kent <kent@bbn.com> Subject: WG last call Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At the direction of our cognizant security AD, the following document has been updated to change its status from informational to standards track: draft-ietf-pkix-lightweight-ocsp-profile-08.txt I am initiating a (less than 2 week) WG last call on the document, since we have discussed it in its prior incarnation as an informational document. Please send comments to the list by the end of next week, i.e., March 2. Thanks, 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 l1KKoC18067176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 13:50:12 -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 l1KKoChm067175; Tue, 20 Feb 2007 13:50:12 -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 l1KKo78W067157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Tue, 20 Feb 2007 13:50:12 -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 A67CC32997; Tue, 20 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJbw2-0007P8-HY; Tue, 20 Feb 2007 15:50:02 -0500 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-08.txt Message-Id: <E1HJbw2-0007P8-HY@stiedprstage1.ietf.org> Date: Tue, 20 Feb 2007 15:50:02 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=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-08.txt Pages : 20 Date : 2007-2-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-08.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-08.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-08.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-2-20110513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-lightweight-ocsp-profile-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-20110513.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 l1IKT5BV049236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Feb 2007 13:29: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 l1IKT5gW049235; Sun, 18 Feb 2007 13:29:05 -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 smtpauth.wiscmail.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1IKT4Yi049227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <ietf-pkix@vpnc.org>; Sun, 18 Feb 2007 13:29:05 -0700 (MST) (envelope-from ejnorman@doit.wisc.edu) Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) id <0JDO00407E8D6100@smtpauth2.wiscmail.wisc.edu> for ietf-pkix@vpnc.org; Sun, 18 Feb 2007 14:29:01 -0600 (CST) Received: from [128.104.4.39] (dyn-4-39.doit.wisc.edu [128.104.4.39]) by smtpauth2.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTPSA id <0JDO0037UE7TDN00@smtpauth2.wiscmail.wisc.edu> for ietf-pkix@vpnc.org; Sun, 18 Feb 2007 14:28:42 -0600 (CST) Date: Sun, 18 Feb 2007 14:28:51 -0600 From: Eric Norman <ejnorman@doit.wisc.edu> Subject: Re: URN in subjectAltName In-reply-to: <200702141843.l1EIhlbF072860@balder-227.proper.com> To: ietf-pkix@vpnc.org Message-id: <809a9dc30b1908ab1ea7c7b788478a77@doit.wisc.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.4.39 X-Spam-PmxInfo: Server=avs-8, Version=5.2.1.279297, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.18.121933, SenderIP=128.104.4.39 References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On Feb 14, 2007, at 12:43 PM, Russ Housley wrote: > > Milan & Paul: > >>> As the group does not seem to have a strong opinion of the choices I >>> propose to include the following text just after the URI part of the >>> section 4.2.1.6 Subject Alternative Name: >>> >>> "When the subjectAltName extension contains a URN, the name MUST be >>> stored in the uniformResourceIdentifier (IA5String). The name MUST >>> follow the URN syntax and encoding rules specified in [RFC 2141]." >>> >>> Comments? >> >> This seems like a good addition, seeing as there were multiple >> choices given on the mailing list, and that means interoperability >> issues. Note that there are two paragraphs to the "URI part"; this >> should be added after the second paragraph, just before "When the >> subjectAltName extension contains a DN...". > > I thought that sever people expressed concern that implementations > that follow RFC 3280 will only expect a URL, so the URN ought to be > encoded in other name. It would be a very simple (one page) > specification. I can certainly believe that the OpenID community would want to put user's "identity URL" in here. That argues for it being something that is at least resolvable. Eric Norman 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 l1IIH1w5041359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Feb 2007 11:17: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 l1IIH1ZX041358; Sun, 18 Feb 2007 11:17: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1IIGqcL041335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Feb 2007 11:16:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p06240800c1fe4858fae0@[10.20.30.249]> In-Reply-To: <45D890A8.9090906@edelweb.fr> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHlnNb073843@balder-227.proper.com> <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHll507183@edelweb.fr> <45D4A875.9060106@edelweb.fr> <p062408a8c1fa804c1211@[10.20.30.108]> <45D890A8.9090906@edelweb.fr> Date: Sun, 18 Feb 2007 10:16:50 -0800 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: URN in subjectAltName Cc: ietf-pkix@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 6:45 PM +0100 2/18/07, Peter Sylvester wrote: >Putting urn into the uri choice is legal in X.509. I am not questioning that. As Russ has pointed out, however, RFC 3280 made it so that PKIX certificates do not allow that because they force the URI to have a hostname. --Paul Hoffman, Director --VPN Consortium 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 l1IHlY0h039463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Feb 2007 10:47: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 l1IHlYpf039462; Sun, 18 Feb 2007 10:47: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1IHlWPk039448; Sun, 18 Feb 2007 10:47:33 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l1IHlJ517326; Sun, 18 Feb 2007 18:47:28 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Sun, 18 Feb 2007 18:47:29 +0100 (MET) Message-ID: <45D890A8.9090906@edelweb.fr> Date: Sun, 18 Feb 2007 18:45:12 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Paul Hoffman <paul.hoffman@vpnc.org> CC: ietf-pkix@vpnc.org Subject: Re: URN in subjectAltName References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHlnNb073843@balder-227.proper.com> <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHll507183@edelweb.fr> <45D4A875.9060106@edelweb.fr> <p062408a8c1fa804c1211@[10.20.30.108]> In-Reply-To: <p062408a8c1fa804c1211@[10.20.30.108]> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000003020008080402070408" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms000003020008080402070408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Putting urn into the uri choice is legal in X.509. --------------ms000003020008080402070408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjE4MTc0NTEyWjAjBgkqhkiG9w0B CQQxFgQUs+rZ989P0FHSHHdKAN+skBjJPx4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAvqCspGFA7TqcK3NP 9HooPf1vos3aJ3lC+0yAyWEzFHV60ej1OZVpGreLklT69/CAhyyJ4PYEPay8RylmRNAzyHIO VASbXOFfRDydjP05RI7ibBRnxFRv3djxg2N2U8K60m0qhCts9h0KHHk60y4U3hdjUj8cZsmT WQxTPxzqs+8AAAAAAAA= --------------ms000003020008080402070408-- 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 l1GLe9nm082546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Feb 2007 14:40: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 l1GLe9au082545; Fri, 16 Feb 2007 14:40: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 smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1GLe8Yj082539 for <ietf-pkix@imc.org>; Fri, 16 Feb 2007 14:40:09 -0700 (MST) (envelope-from wprice@mitre.org) Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l1GLe8sL030954 for <ietf-pkix@imc.org>; Fri, 16 Feb 2007 16:40:08 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id DD66C1BD7E for <ietf-pkix@imc.org>; Fri, 16 Feb 2007 16:40:07 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l1GLe7TU030943 for <ietf-pkix@imc.org>; Fri, 16 Feb 2007 16:40:07 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:40:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75213.069D68B6" Subject: Application Recognition and Use of the anyExtendedKeyUsage OID in a Certificate's EKU Extension Date: Fri, 16 Feb 2007 16:40:06 -0500 Message-ID: <F9F038204EE77C4AA9959A6B3C94AFE801391742@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Application Recognition and Use of the anyExtendedKeyUsage OID in a Certificate's EKU Extension Thread-Index: AcdSEwXu+EoYf8cXQB2UfcTcmEM5gA== From: "Price, Bill" <wprice@mitre.org> To: "pkix" <ietf-pkix@imc.org> X-OriginalArrivalTime: 16 Feb 2007 21:40:07.0249 (UTC) FILETIME=[06A21410:01C75213] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C75213.069D68B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This may be slightly off topic, but does anyone have any information regarding what "major" vendors/applications recognize the anyExtendedKeyUsage purpose described in 3280's EKU extension? =20 Some interpretations of 3280 are that applications that consider the EKU extension should accept the anyExtendedKeyUsage purpose rather than require the specific purpose targeted to their application. So for example, a certificate with the anyExtendedKeyUsage purpose should be accepted for TLS client or server authentication or e-mail protection regardless of whether the specific EKU purposes were present or not. Similarly, a certificate with the anyExtendedKeyUsage should be accepted when used for code, ocsp, or time-stamp signing regardless of whether the specific purposes were asserted in the EKU. =20 Has anyone either tested major applications or seen vendor descriptions/disclosures about the acceptance or use of the anyExtendedKeyUsage purpose? We have found that at least one major vendor does not accept the anyExtendedKeyUsage as a substitute for a specific EKU. We would like to avoid having to test to determine whether other applications use it and whether asserting the anyExtendedKeyUsage purpose in certificates is useful.=20 =20 Thanks. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Bill Price The MITRE Corporation ------_=_NextPart_001_01C75213.069D68B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>This may be = slightly off=20 topic, but does anyone have any information regarding what "major"=20 vendors/applications recognize the anyExtendedKeyUsage purpose described = in=20 3280's EKU extension?</FONT></SPAN></DIV> <DIV><SPAN class=3D785553220-16022007><FONT = face=3DArial></FONT></SPAN> </DIV> <DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>Some = interpretations of=20 3280 are that applications that consider the EKU extension should accept = the=20 anyExtendedKeyUsage purpose rather than require the specific purpose = targeted to=20 their application. So for example, a certificate with the = anyExtendedKeyUsage=20 purpose should be accepted for TLS client or server authentication or = e-mail=20 protection regardless of whether the specific EKU purposes were present = or not.=20 Similarly, a certificate with the anyExtendedKeyUsage should be accepted = when=20 used for code, ocsp, or time-stamp signing regardless of whether the = specific=20 purposes were asserted in the EKU.</FONT></SPAN></DIV> <DIV><SPAN class=3D785553220-16022007><FONT = face=3DArial></FONT></SPAN> </DIV> <DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>Has anyone = either tested=20 major applications or seen vendor descriptions/disclosures about the = acceptance=20 or use of the anyExtendedKeyUsage purpose? We have found that at least = one major=20 vendor does not accept the anyExtendedKeyUsage as a substitute for a = specific=20 EKU. We would like to avoid having to test to determine whether other=20 applications use it and whether asserting the anyExtendedKeyUsage = purpose in=20 certificates is useful. </FONT></SPAN></DIV> <DIV><SPAN class=3D785553220-16022007><FONT = face=3DArial></FONT></SPAN> </DIV> <DIV><SPAN class=3D785553220-16022007><FONT = face=3DArial>Thanks.</FONT></SPAN></DIV> <DIV> </DIV> <DIV align=3Dleft><FONT=20 face=3D"Courier = New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> = </DIV> <P align=3Dleft><FONT color=3D#000080><FONT face=3D"Courier New" = color=3D#000000=20 size=3D2>Bill Price</FONT></FONT></P> <P align=3Dleft><FONT color=3D#000080><FONT color=3D#000000><FONT = face=3D"Courier New"=20 size=3D2>The <FONT face=3DMITRE color=3D#000080>MITRE</FONT>=20 Corporation<BR></FONT></FONT></FONT></P></BODY></HTML> ------_=_NextPart_001_01C75213.069D68B6-- 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 l1FLW1q4090227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 14:32: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 l1FLW192090226; Thu, 15 Feb 2007 14:32: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1FLVwZr090217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@vpnc.org>; Thu, 15 Feb 2007 14:32:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p062408a8c1fa804c1211@[10.20.30.108]> In-Reply-To: <200702151747.l1FHlnNb073843@balder-227.proper.com> <45D4A875.9060106@edelweb.fr> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHlnNb073843@balder-227.proper.com> <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHll507183@edelweb.fr> <45D4A875.9060106@edelweb.fr> Date: Thu, 15 Feb 2007 13:31:36 -0800 To: ietf-pkix@vpnc.org From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: URN in subjectAltName Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:47 PM -0500 2/15/07, Russ Housley wrote: >Peter: > >RFC 3280 does not allow a URN. It requires a URL. Unfortunately, I now agree with Russ. RFC 3280 makes it clear that the URI MUST have a FQDN in it. We blew it, but it's not fatal for this purpose. >The changes you suggest are not backward compatible. That is my concern. And my concern as well, regardless of... At 7:37 PM +0100 2/15/07, Peter Sylvester wrote: >Yes, but do you know any implementation that rejects a certificat? >i.e. one that allows any URL scheme and just rejects urn:, >and furthermore that rejects if the content doesn't conform >to the URL syntaxes? It doesn't matter if we know it or not; it matters if we are negating something that we made mandatory in RFC 3280. So, instead of trying to make URNs work in uniformResourceIdentifier, we should just put it in an OtherName with its own OID. I propose the following be added instead of Milan's proposal: When the subjectAltName extension contains a URN, the name MUST be stored in the otherName (IA5String). The OID used MUST be: id-on-URN OBJECT IDENTIFIER ::= { id-on TBD } The name MUST follow the URN syntax and encoding rules specified in [RFC 2141]. (For those of you not familiar with the id-pkix tree, see <http://www.imc.org/ietf-pkix/pkix-oid.asn>.) --Paul Hoffman, Director --VPN Consortium 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 l1FIduUV078378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 11:39:56 -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 l1FIduU6078377; Thu, 15 Feb 2007 11:39: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1FIdsoo078366; Thu, 15 Feb 2007 11:39:55 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l1FIdm508474; Thu, 15 Feb 2007 19:39:48 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 15 Feb 2007 19:39:48 +0100 (MET) Message-ID: <45D4A875.9060106@edelweb.fr> Date: Thu, 15 Feb 2007 19:37:41 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Russ Housley <housley@vigilsec.com> CC: Paul Hoffman <paul.hoffman@vpnc.org>, ietf-pkix@vpnc.org Subject: Re: URN in subjectAltName References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> <200702151747.l1FHll507183@edelweb.fr> In-Reply-To: <200702151747.l1FHll507183@edelweb.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050908090002050804030005" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms050908090002050804030005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Russ Housley wrote: > Peter: > > RFC 3280 does not allow a URN. It requires a URL. The changes you > suggest are not backward compatible. That is my concern. > Yes, but do you know any implementation that rejects a certificat? i.e. one that allows any URL scheme and just rejects urn:, and furthermore that rejects if the content doesn't conform to the URL syntaxes? As far as I remember the request was made to allow urn: in new contexts anyway, such certificates may (in theorie) not be usable in old applications, I'd still like to see one. regards --------------ms050908090002050804030005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjE1MTgzNzQxWjAjBgkqhkiG9w0B CQQxFgQUTyR3wbInEpbYZIBHQM1S0nIYcz0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGACJ9+R5DICiVraEU3 5ds0MonNcO8a1wh2LZXUEfPvw2H/fQgmIc3DNbIvULtKYMBbmN3i5uOa0SgvVxUz4fOnrQvs Y8bS3SFFUyyRwLSqrgRB9RqlcPrKs2/zNAqrTdmAJk0FcmW2WWBn5aFR/DKWPqEyIq63iffl zvR+hzw/bmcAAAAAAAA= --------------ms050908090002050804030005-- 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 l1FHlpRk073861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 10:47: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 l1FHlpP2073860; Thu, 15 Feb 2007 10:47: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 l1FHlnNb073843 for <ietf-pkix@vpnc.org>; Thu, 15 Feb 2007 10:47:50 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200702151747.l1FHlnNb073843@balder-227.proper.com> Received: (qmail 18623 invoked by uid 0); 15 Feb 2007 17:47:43 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 15 Feb 2007 17:47:43 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Feb 2007 12:47:44 -0500 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> From: Russ Housley <housley@vigilsec.com> Subject: Re: URN in subjectAltName Cc: Paul Hoffman <paul.hoffman@vpnc.org>, ietf-pkix@vpnc.org In-Reply-To: <45D45730.40405@edelweb.fr> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> <45D45730.40405@edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Peter: RFC 3280 does not allow a URN. It requires a URL. The changes you suggest are not backward compatible. That is my concern. Russ >>Ooops: s/server/several/ >> >>RFC 3280 says: >> >> When the subjectAltName extension contains a URI, the name MUST be >> stored in the uniformResourceIdentifier (an IA5String). The name >> MUST NOT be a relative URL, and it MUST follow the URL syntax and >> encoding rules specified in [RFC 1738]. The name MUST include both a >> scheme (e.g., "http" or "ftp") and a scheme-specific-part. The >> scheme-specific-part MUST include a fully qualified domain name or IP >> address as the host. >> >> As specified in [RFC 1738], the scheme name is not case-sensitive >> (e.g., "http" is equivalent to "HTTP"). The host part is also not >> case-sensitive, but other components of the scheme-specific-part may >> be case-sensitive. When comparing URIs, conforming implementations >> MUST compare the scheme and host without regard to case, but assume >> the remainder of the scheme-specific-part is case sensitive. >> >>I think this prohibits the use of a URN like this: >> >> URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN > >Indeed. But is there any problem allowing the URN scheme? We >are taking about not allowing a "universal resource name" as a name. > >I think that subjectAltname should simply not make any restriction for >filling an URI according to RFC 3986, in order to keep the >explanations and rules for URLs, I propose to change: > >"When the subjectAltName extension contains a URI, the name MUST be > stored in the uniformResourceIdentifier (an IA5String). If the name > is an URL, it MUST NOT be a relative URL, and it MUST follow the > URL syntax and > encoding rules specified in [RFC 1738]. The URL MUST include both a > scheme (e.g., "http" or "ftp") and a scheme-specific-part. The > scheme-specific-part of an URL MUST include a fully qualified > domain name or IP > address as the host. > > As specified in [RFC 1738], the scheme name is not case-sensitive > (e.g., "http" is equivalent to "HTTP"). The host part is also not > case-sensitive, but other components of the scheme-specific-part may > be case-sensitive. When comparing URLs, conforming implementations > MUST compare the scheme and host without regard to case, but assume > the remainder of the scheme-specific-part is case sensitive. > > If the URI is a URN, conforming implementations MUST follow the rules > of [RFC 2141] when comparing them, i.e. treating the string "urn:" and > the NID as case insensitive. Implementations SHOULD use the same > case when setting URNs. > > Since internet emeil addresses are stored using the RFC822address > alternative of GeneralName, the "mailto:" scheme SHALL not be used." > >The usage of GeneralName in CRLdistributions points etc is not affected but >this change. 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 l1FCrDN4049849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 05:53: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 l1FCrD78049848; Thu, 15 Feb 2007 05:53: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 edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1FCrBmf049836; Thu, 15 Feb 2007 05:53:12 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l1FCr2500143; Thu, 15 Feb 2007 13:53:02 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 15 Feb 2007 13:53:07 +0100 (MET) Message-ID: <45D45730.40405@edelweb.fr> Date: Thu, 15 Feb 2007 13:50:56 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Russ Housley <housley@vigilsec.com> CC: Paul Hoffman <paul.hoffman@vpnc.org>, ietf-pkix@vpnc.org Subject: Re: URN in subjectAltName References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> <200702142147.l1ELlHGq088861@balder-227.proper.com> In-Reply-To: <200702142147.l1ELlHGq088861@balder-227.proper.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040402030005040403030408" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms040402030005040403030408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ Housley wrote: > > Ooops: s/server/several/ > > RFC 3280 says: > > When the subjectAltName extension contains a URI, the name MUST be > stored in the uniformResourceIdentifier (an IA5String). The name > MUST NOT be a relative URL, and it MUST follow the URL syntax and > encoding rules specified in [RFC 1738]. The name MUST include both a > scheme (e.g., "http" or "ftp") and a scheme-specific-part. The > scheme-specific-part MUST include a fully qualified domain name or IP > address as the host. > > As specified in [RFC 1738], the scheme name is not case-sensitive > (e.g., "http" is equivalent to "HTTP"). The host part is also not > case-sensitive, but other components of the scheme-specific-part may > be case-sensitive. When comparing URIs, conforming implementations > MUST compare the scheme and host without regard to case, but assume > the remainder of the scheme-specific-part is case sensitive. > > I think this prohibits the use of a URN like this: > > URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN > > Russ Indeed. But is there any problem allowing the URN scheme? We are taking about not allowing a "universal resource name" as a name. I think that subjectAltname should simply not make any restriction for filling an URI according to RFC 3986, in order to keep the explanations and rules for URLs, I propose to change: "When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). If the name is an URL, it MUST NOT be a relative URL, and it MUST follow the URL syntax and encoding rules specified in [RFC 1738]. The URL MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-specific-part of an URL MUST include a fully qualified domain name or IP address as the host. As specified in [RFC 1738], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. When comparing URLs, conforming implementations MUST compare the scheme and host without regard to case, but assume the remainder of the scheme-specific-part is case sensitive. If the URI is a URN, conforming implementations MUST follow the rules of [RFC 2141] when comparing them, i.e. treating the string "urn:" and the NID as case insensitive. Implementations SHOULD use the same case when setting URNs. Since internet emeil addresses are stored using the RFC822address alternative of GeneralName, the "mailto:" scheme SHALL not be used." The usage of GeneralName in CRLdistributions points etc is not affected but this change. > > > At 03:47 PM 2/14/2007, Paul Hoffman wrote: >> At 1:43 PM -0500 2/14/07, Russ Housley wrote: >>> Milan & Paul: >>> >>>>> As the group does not seem to have a strong opinion of the choices I >>>>> propose to include the following text just after the URI part of the >>>>> section 4.2.1.6 Subject Alternative Name: >>>>> >>>>> "When the subjectAltName extension contains a URN, the name MUST be >>>>> stored in the uniformResourceIdentifier (IA5String). The name MUST >>>>> follow the URN syntax and encoding rules specified in [RFC 2141]." >>>>> >>>>> Comments? >>>> >>>> This seems like a good addition, seeing as there were multiple >>>> choices given on the mailing list, and that means interoperability >>>> issues. Note that there are two paragraphs to the "URI part"; this >>>> should be added after the second paragraph, just before "When the >>>> subjectAltName extension contains a DN...". >>> >>> I thought that sever people expressed concern that implementations >>> that follow RFC 3280 will only expect a URL, so the URN ought to be >>> encoded in other name. >> >> I don't know which server people those are, but there is nothing in >> RFC 3280 or 3280bis that would make me think "this is a URL and not a >> URI". >> >>> It would be a very simple (one page) specification. >> >> That's true, but there is no reason not to make it part of the only >> specification that most implementers will read. I still support >> putting it into 3280bis to encourage interoperability. >> >> --Paul Hoffman, Director >> --VPN Consortium >> > > > --------------ms040402030005040403030408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjE1MTI1MDU2WjAjBgkqhkiG9w0B CQQxFgQUWBUR7OopKwLKcvqOmecbXnwdb8EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAWxO9QhgiuvVNhF4S Qa7HE0K6nFgKziXXlbrMZb+o/e1t7rfha/Lsr9ISu+Byv5oE/HnkxF0qx10bXBIvU5xnb+/j V3WCXecz/65iYlo31LfvGdXbNC+jb5QsS6B9EEVcm+eVjVsDsXKDz7q9ib8dr3NzSrjaydkq A03YTxUp/vgAAAAAAAA= --------------ms040402030005040403030408-- 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 l1F8TmKE030838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 01:29: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 l1F8Tm7x030837; Thu, 15 Feb 2007 01:29: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 mart.catcert.local (62-97-117-187.atlassolutions.net [62.97.117.187] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1F8TjeL030824 for <ietf-pkix@imc.org>; Thu, 15 Feb 2007 01:29:46 -0700 (MST) (envelope-from ialamillo@catcert.net) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C750DB.6FF44DB6" Subject: RE: Certificates in CRLs Date: Thu, 15 Feb 2007 09:28:17 +0100 Message-ID: <2E0817224D030746BF4A296C5E382492B8FAA3@mart.catcert.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Certificates in CRLs Thread-Index: AcdQWSrvvnyENl6jQGGL0oTHSXwDLAALN1PQABVNkFs= References: <198A730C2044DE4A96749D13E167AD37011472C3@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Ignacio Alamillo" <ialamillo@catcert.net> To: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C750DB.6FF44DB6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good morning,=20 We at CATCert, a Catalan governmental agency, are deploying several = signature and document archival services and for us Stefan's proposal = will greatly simplify the current retrieval process, so we support the = proposal. This proposal has some impact in the CAdES and XAdES technical = specifications that should also be addresed. Ignacio Alamillo -----Mensaje original----- De: owner-ietf-pkix@mail.imc.org en nombre de Hallam-Baker, Phillip Enviado el: mi=E9 14/02/2007 23:19 Para: Guida, Richard [JJCUS]; Peter Hesse; Sharon Boeyen; Stefan = Santesson; Russ Housley CC: ietf-pkix@imc.org Asunto: RE: Certificates in CRLs =20 The archival purpose is a major one for me. It means that I can put a = complete package together quickly and efficiently. ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard = [JJCUS] Sent: Wednesday, February 14, 2007 10:03 AM To: Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan = Santesson'; 'Russ Housley' Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 I likewise agree with Peter, Phillip and Stefan. The CRL bloat is not = large, and for those of us with large CRLs to begin with (can debate = separately why that circumstance exists...), the bloat is negligible. = Since this is entirely optional; and since the owner of a CA therefore = has full discretion to include or not include the certs (and can do as = Peter described and published two virtually contemporaneous CRLs, one = with and one without, if needed to avoid breaking apps), it seems to me = that this approach can be used in a fashion which does not break = anything, and it can provide real value for archival purposes. =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Peter Hesse Sent: Wednesday, February 14, 2007 12:05 AM To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; = 'Russ Housley' Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 I'm in agreement that Stefan's proposal is a decent one. As Phillip = mentions, it certainly isn't appropriate in every situation, but I can = see situations in which it might be useful. One might argue that a CRL = issuer could issue two CRLs, the most commonly retrieved one without = this extension, but a separate one issued with it-the latter being made = to applications responsible for long term archive, historical signature = validation, or other purposes which might find it useful. =20 =20 I don't see any harm in adding this extension as an optional feature = for PKIs that wish it, since it is truly optional, non-critical, and = does not affect path processing. =20 =20 --Peter =20 +----------------------------------------------------------------+ | Peter Hesse pmhesse@geminisecurity.com | | Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. | | Visit our InfoSecurity blog: securitymusings.com = <http://www.securitymusings.com/> | +----------------------------------------------------------------+ "The generation of random numbers is too important to be left to chance." --Robert R. Coveyou =20 =20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, February 13, 2007 6:53 PM To: Sharon Boeyen; Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I think that Sharon's proposal might have been a good idea in 1995 = before the world got wedged on CRLs as the revocation mechanism. We can = define a package but its too late to get it embedded in the rest of the = application infrastructure. =20 Given where we are Stefan's proposal is the best one. It is compatible = with the existing infrastructure and solves a real issue.=20 =20 It is an option, clearly there are cases where it would be = inappropriate but universal applicability has never been a requirement. = Otherwise we could have saved all the time spent on attribute = certificates. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Stefan I really don't think you can state where this will or will not = be used in the future. Naturally you know where you want to use it, but = software only enables a facility and the customer decides when and how = to use it.=20 =20 Whether this scheme could possibly be useful in some cases is not my = point. My point is that current deployments seem to be working fine = without it and I don't want to see those interfered with just because = some CA they may have cross certified with decided to put certificates = inside their CRLS. Back to Denis' point - there is no need to impose = this in the way you've proposed.=20 =20 Earlier I (and others including Dave Kemp) suggested a "package" that = includes the CRL, and the certificate in question as an 'extra' that a = CA could publish in addition to a regular CRL. That "package could be = published in a separate directory attribute and/or an HTTP accessible = file. It could be pointed to from within the certificate just as the CRL = currently is. That could be done either by extending the CRLDP or adding = a new pointer extension or adding a new method to the AIA extension. = That type of approach gives you what you want but does not in any way = interfere with clients who do not want and do not need to retrieve that = bloated CRL.=20 =20 Also, you haven't addressed the question about what happens when more = than one certificate is needed. If a CRL includes more than one = certificate (e.g. the CRL issuer did one or more key rollovers then CRL = gets bloated a lot bigger than you suggested. I don't want to debate how = often a key gets rolled over either however I have definitely seen = instances in real world deployments where a key has been rolled very = often in a very short period of time (regardless of whether the reason = for rolling it was a good one or not - it has happened). Also, = regardless of the size of the "bloat" I'm saying that in most cases the = clients will already have the certificates in question and this bloat = will cause them extra processing in managing their certificate caches = etc unnecessarily. The client should have a choice as to whether to = download the certificate or not. =20 I don't understand why you're so opposed to the "package" solution.=20 =20 Cheers, Sharon=20 -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs We are only talking about an extra 16K at most. The download time is = the absolute most cases is negligible.=20 For those cases where this solution makes sense, the network = bandwidth issue is not a problem. =20 For the cases where this would be an issue, this solution would not = be used. =20 On the contrary, in some networks and scenarios, this will improve = performance. Especially in high latency networks with PKI based = peer-peer authentication where an extra retrieval cost way more = performance than the expanded CRL size. =20 Also, many clients are configured to pre-fetch CRL:s before they are = used, using idle time on the network at no extra cost. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I still think wasted bandwidth is also an issue. Forcing the = download of 'fat' CRLs on clients when, in many cases, those clients = already have the certificates locally that caused the bloating of the = CRL, is an unnecessary waste. -----Original Message-----=20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson=20 Sent: Wednesday, January 03, 2007 9:58 AM=20 To: Russ Housley=20 Cc: ietf-pkix@imc.org=20 Subject: RE: Certificates in CRLs=20 =20 Russ,=20 In theory, the CA can put different pointers to different CRLs in = each certificate if some certificates are prime targets for frequent = checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would = have to add capability to the CDP extension rather than to the CRL. I = don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in = situations where it in the sum of all, helps increase efficiency and = where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, = but that some implementers simply don't want to be faced with the = requirement to implement this feature. But I don't see that they have = to. A CRL with certs in a non-critical extension should work just as = well in current clients as any current CRL without certs. The extension = can simply be ignored. This is not a necessary feature, but a practical one offering = performance improvements in some environments at no loss of = interoperability. =20 Stefan Santesson=20 Senior Program Manager=20 Windows Security, Standards=20 =20 > -----Original Message-----=20 > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: den 21 december 2006 16:19=20 > To: Stefan Santesson=20 > Cc: ietf-pkix@imc.org=20 > Subject: RE: Certificates in CRLs=20 >=20 > Stefan:=20 >=20 > If the CA chooses to offer both, how can the RP determine which = one it=20 > will get? Does the CA post them in different LDAP attributes?=20 >=20 > Russ=20 >=20 > At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20 >=20 > >As with anything else, the relying party can get what the CA = offers.=20 > >=20 > >I don't think there is any realistic scenario where the CA has a=20 > >reason to offer CRLs both with and without certificates. To offer = > >this capability to RP is however not a matter for this protocol. = It=20 > >would be a matter for the CRL referencing model, i.e. CDP and/or=20 > >directory schema.=20 > >=20 > >I don't think that extra complexity however is very useful.=20 > >=20 > >Stefan Santesson=20 > >Senior Program Manager=20 > >Windows Security, Standards=20 > >=20 > >=20 > > > -----Original Message-----=20 > > > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-=20 > > > pkix@mail.imc.org] On Behalf Of Denis Pinkas=20 > > > Sent: den 20 december 2006 17:05=20 > > > To: ietf-pkix@imc.org=20 > > > Subject: Re: Certificates in CRLs=20 > > >=20 > > >=20 > > >=20 > > > It is necessary to provide relying parties with the choice to = get=20 > > > :=20 > > >=20 > > > - CRLs "as usual", or=20 > > > - CRLs that carry that new extension.=20 > > >=20 > > > The current proposal does not allow for it.=20 > > >=20 > > > Until the draft is changed, I am against the addition of this = work=20 > item=20 > > > to the program of the PKIX WG.=20 > > >=20 > > > Denis=20 > > >=20 > > >=20 > = ______________________________________________________________________=20 > _=20 > > > _______=20 > > >=20 > > > >Since last IETF a new draft was posted:=20 > > > = >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20 > 00.txt=20 > > > >=20 > > > >There is a request to add this draft to the PKIX work and I = would=20 > > > encourage to start the discussion about this decision in this=20 > thread.=20 > > > >=20 > > > >Stefan Santesson=20 > > > >Senior Program Manager=20 > > > >Windows Security, Standards=20 > > >=20 > > >=20 > > >=20 ------_=_NextPart_001_01C750DB.6FF44DB6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7650.28"> <TITLE>RE: Certificates in CRLs</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Good morning,<BR> <BR> We at CATCert, a Catalan governmental agency, are deploying several = signature and document archival services and for us Stefan's proposal = will greatly simplify the current retrieval process, so we support the = proposal.<BR> <BR> This proposal has some impact in the CAdES and XAdES technical = specifications that should also be addresed.<BR> <BR> Ignacio Alamillo<BR> <BR> <BR> -----Mensaje original-----<BR> De: owner-ietf-pkix@mail.imc.org en nombre de Hallam-Baker, Phillip<BR> Enviado el: mi=E9 14/02/2007 23:19<BR> Para: Guida, Richard [JJCUS]; Peter Hesse; Sharon Boeyen; Stefan = Santesson; Russ Housley<BR> CC: ietf-pkix@imc.org<BR> Asunto: RE: Certificates in CRLs<BR> <BR> The archival purpose is a major one for me. It means that I can put a = complete package together quickly and efficiently.<BR> <BR> <BR> ________________________________<BR> <BR> From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>] On Behalf Of Guida, Richard [JJCUS]<BR> Sent: Wednesday, February 14, = 2007 10:03 AM<BR> To: Peter Hesse; = Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ = Housley'<BR> Cc: ietf-pkix@imc.org<BR> Subject: RE: Certificates in = CRLs<BR> <BR> <BR> I likewise agree with Peter, = Phillip and Stefan. The CRL bloat is not large, and for those of = us with large CRLs to begin with (can debate separately why that = circumstance exists...), the bloat is negligible. Since this is = entirely optional; and since the owner of a CA therefore has full = discretion to include or not include the certs (and can do as Peter = described and published two virtually contemporaneous CRLs, one with and = one without, if needed to avoid breaking apps), it seems to me that this = approach can be used in a fashion which does not break anything, and it = can provide real value for archival purposes.<BR> <BR> <BR> <BR> Richard A. Guida<BR> Director, Information = Security<BR> <BR> Johnson & Johnson<BR> Room GS8217<BR> 410 George Street<BR> New Brunswick, New = Jersey 08901<BR> Phone: 732 524 3785<BR> <BR> = -----Original = Message-----<BR> = From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>]On Behalf Of Peter Hesse<BR> = Sent: Wednesday, February 14, = 2007 12:05 AM<BR> = To: 'Hallam-Baker, Phillip'; = 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ Housley'<BR> = Cc: ietf-pkix@imc.org<BR> = Subject: RE: Certificates in = CRLs<BR> = <BR> = <BR> <BR> = I'm in agreement that = Stefan's proposal is a decent one. As Phillip mentions, it = certainly isn't appropriate in every situation, but I can see situations = in which it might be useful. One might argue that a CRL issuer = could issue two CRLs, the most commonly retrieved one without this = extension, but a separate one issued with it-the latter being made to = applications responsible for long term archive, historical signature = validation, or other purposes which might find it useful. <BR> <BR> = <BR> <BR> = I don't see any harm in = adding this extension as an optional feature for PKIs that wish it, = since it is truly optional, non-critical, and does not affect path = processing. <BR> <BR> = <BR> <BR> = --Peter<BR> <BR> = <BR> <BR> = = +----------------------------------------------------------------+<BR> = | Peter = Hesse &n= bsp; = pmhesse@geminisecurity.com |<BR> = | Phone: 703-378-5808 = x105 Gemini Security Solutions, Inc. = |<BR> = = | Visit our InfoSecurity blog: = securitymusings.com <<A = HREF=3D"http://www.securitymusings.com/">http://www.securitymusings.com/<= /A>> |<BR> = = +----------------------------------------------------------------+<BR> = "The generation of = random numbers is too important to be left<BR> = to chance." = --Robert R. Coveyou<BR> <BR> = <BR> <BR> = <BR> <BR> = From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>] On Behalf Of Hallam-Baker, Phillip<BR> = Sent: Tuesday, February 13, = 2007 6:53 PM<BR> = To: Sharon Boeyen; Stefan = Santesson; Russ Housley<BR> = Cc: ietf-pkix@imc.org<BR> = Subject: RE: Certificates in = CRLs<BR> <BR> = <BR> <BR> = I think that Sharon's = proposal might have been a good idea in 1995 before the world got wedged = on CRLs as the revocation mechanism. We can define a package but its too = late to get it embedded in the rest of the application = infrastructure.<BR> <BR> = <BR> <BR> = Given where we are Stefan's = proposal is the best one. It is compatible with the existing = infrastructure and solves a real issue.<BR> <BR> = <BR> <BR> = It is an option, clearly = there are cases where it would be inappropriate but universal = applicability has never been a requirement. Otherwise we could have = saved all the time spent on attribute certificates.<BR> <BR> = = <BR> <BR> ________________________________<BR> <BR> = = From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>] On Behalf Of Sharon Boeyen<BR> = = Sent: Friday, January 05, = 2007 9:09 AM<BR> = = To: 'Stefan Santesson'; = Sharon Boeyen; Russ Housley<BR> = = Cc: ietf-pkix@imc.org<BR> = = Subject: RE: Certificates in = CRLs<BR> <BR> = = Stefan I really don't think = you can state where this will or will not be used in the future. = Naturally you know where you want to use it, but software only enables a = facility and the customer decides when and how to use it.<BR> <BR> = = <BR> <BR> = = Whether this scheme could = possibly be useful in some cases is not my point. My point is that = current deployments seem to be working fine without it and I don't want = to see those interfered with just because some CA they may have cross = certified with decided to put certificates inside their CRLS. Back to = Denis' point - there is no need to impose this in the way you've = proposed.<BR> <BR> = = <BR> <BR> = = Earlier I (and others = including Dave Kemp) suggested a "package" that includes the = CRL, and the certificate in question as an 'extra' that a CA could = publish in addition to a regular CRL. That "package could be = published in a separate directory attribute and/or an HTTP accessible = file. It could be pointed to from within the certificate just as the CRL = currently is. That could be done either by extending the CRLDP or adding = a new pointer extension or adding a new method to the AIA extension. = That type of approach gives you what you want but does not in any way = interfere with clients who do not want and do not need to retrieve that = bloated CRL.<BR> <BR> = = <BR> <BR> = = Also, you haven't addressed = the question about what happens when more than one certificate is = needed. If a CRL includes more than one certificate (e.g. the CRL issuer = did one or more key rollovers then CRL gets bloated a lot bigger than = you suggested. I don't want to debate how often a key gets rolled over = either however I have definitely seen instances in real world = deployments where a key has been rolled very often in a very short = period of time (regardless of whether the reason for rolling it was a = good one or not - it has happened). Also, regardless of the size of the = "bloat" I'm saying that in most cases the clients will already = have the certificates in question and this bloat will cause them extra = processing in managing their certificate caches etc unnecessarily. The = client should have a choice as to whether to download the certificate or = not.<BR> <BR> = = <BR> <BR> = = I don't understand why you're = so opposed to the "package" solution.<BR> <BR> = = <BR> <BR> = = Cheers,<BR> <BR> = = Sharon<BR> <BR> = = -----Original = Message-----<BR> = = From: Stefan Santesson [<A = HREF=3D"mailto:stefans@microsoft.com">mailto:stefans@microsoft.com</A>]<B= R> = = Sent: Friday, January 05, = 2007 8:01 AM<BR> = = To: Sharon Boeyen; Russ = Housley<BR> = = Cc: ietf-pkix@imc.org<BR> = = Subject: RE: Certificates in = CRLs<BR> <BR> = = = We are only talking about an = extra 16K at most. The download time is the absolute most cases is = negligible.<BR> <BR> = = = For those cases where this = solution makes sense, the network bandwidth issue is not a problem.<BR> <BR> = = = <BR> <BR> = = = For the cases where this = would be an issue, this solution would not be used.<BR> <BR> = = = <BR> <BR> = = = On the contrary, in some = networks and scenarios, this will improve performance. Especially in = high latency networks with PKI based peer-peer authentication where an = extra retrieval cost way more performance than the expanded CRL = size.<BR> <BR> = = = <BR> <BR> = = = Also, many clients are = configured to pre-fetch CRL:s before they are used, using idle time on = the network at no extra cost.<BR> <BR> = = = <BR> <BR> = = = <BR> <BR> = = = Stefan Santesson<BR> <BR> = = = Senior Program Manager<BR> <BR> = = = Windows Security, = Standards<BR> <BR> = = = <BR> <BR> = = = From: Sharon Boeyen [<A = HREF=3D"mailto:sharon.boeyen@entrust.com">mailto:sharon.boeyen@entrust.co= m</A>]<BR> = = = Sent: den 4 januari 2007 = 17:36<BR> = = = To: Stefan Santesson; Russ = Housley<BR> = = = Cc: ietf-pkix@imc.org<BR> = = = Subject: RE: Certificates in = CRLs<BR> <BR> = = = <BR> <BR> = = = I still think wasted = bandwidth is also an issue. Forcing the download of 'fat' CRLs on = clients when, in many cases, those clients already have the certificates = locally that caused the bloating of the CRL, is an unnecessary = waste.<BR> <BR> = = = -----Original = Message-----<BR> = = = From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>] On Behalf Of Stefan Santesson<BR> = = = Sent: Wednesday, January 03, = 2007 9:58 AM<BR> = = = To: Russ Housley<BR> = = = Cc: ietf-pkix@imc.org<BR> = = = Subject: RE: Certificates in = CRLs<BR> <BR> = = = <BR> <BR> = = = Russ,<BR> <BR> = = = In theory, the CA can put = different pointers to different CRLs in each certificate if some = certificates are prime targets for frequent checking. But I don't think = that is a common scenario.<BR> <BR> = = = My point is that in order to = allow free selection of CRLs, you would have to add capability to the = CDP extension rather than to the CRL. I don't think such effort is worth = the trouble.<BR> <BR> = = = I'm convinced that including = certs in a CRL will only be made in situations where it in the sum of = all, helps increase efficiency and where the extra bandwidth consumed is = not an issue.<BR> <BR> = = = I read the critique of this = idea as not really be a bandwidth issue, but that some implementers = simply don't want to be faced with the requirement to implement this = feature. But I don't see that they have to. A CRL with certs in a = non-critical extension should work just as well in current clients as = any current CRL without certs. The extension can simply be ignored.<BR> <BR> = = = This is not a necessary = feature, but a practical one offering performance improvements in some = environments at no loss of interoperability.<BR> <BR> = = = <BR> <BR> = = = Stefan Santesson<BR> = = = Senior Program Manager<BR> = = = Windows Security, = Standards<BR> <BR> = = = <BR> <BR> = = = > -----Original = Message-----<BR> = = = > From: Russ Housley [<A = HREF=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]<BR>= = = = > Sent: den 21 december = 2006 16:19<BR> = = = > To: Stefan Santesson<BR> = = = > Cc: = ietf-pkix@imc.org<BR> = = = > Subject: RE: = Certificates in CRLs<BR> = = = ><BR> = = = > Stefan:<BR> = = = ><BR> = = = > If the CA chooses to = offer both, how can the RP determine which one it<BR> = = = > will get? Does the = CA post them in different LDAP attributes?<BR> = = = ><BR> = = = > Russ<BR> = = = ><BR> = = = > At 08:00 AM 12/21/2006, = Stefan Santesson wrote:<BR> = = = ><BR> = = = > >As with anything = else, the relying party can get what the CA offers.<BR> = = = > ><BR> = = = > >I don't think there = is any realistic scenario where the CA has a<BR> = = = > >reason to offer CRLs = both with and without certificates. To offer<BR> = = = > >this capability to = RP is however not a matter for this protocol. It<BR> = = = > >would be a matter = for the CRL referencing model, i.e. CDP and/or<BR> = = = > >directory = schema.<BR> = = = > ><BR> = = = > >I don't think that = extra complexity however is very useful.<BR> = = = > ><BR> = = = > >Stefan Santesson<BR> = = = > >Senior Program = Manager<BR> = = = > >Windows Security, = Standards<BR> = = = > ><BR> = = = > ><BR> = = = > > > -----Original = Message-----<BR> = = = > > > From: = owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A><BR> = = = > > > = pkix@mail.imc.org] On Behalf Of Denis Pinkas<BR> = = = > > > Sent: den 20 = december 2006 17:05<BR> = = = > > > To: = ietf-pkix@imc.org<BR> = = = > > > Subject: Re: = Certificates in CRLs<BR> = = = > > ><BR> = = = > > ><BR> = = = > > ><BR> = = = > > > It is = necessary to provide relying parties with the choice to get<BR> = = = > > > :<BR> = = = > > ><BR> = = = > > > - = CRLs "as usual", or<BR> = = = > > > - = CRLs that carry that new extension.<BR> = = = > > ><BR> = = = > > > The current = proposal does not allow for it.<BR> = = = > > ><BR> = = = > > > Until the = draft is changed, I am against the addition of this work<BR> = = = > item<BR> = = = > > > to the program = of the PKIX WG.<BR> = = = > > ><BR> = = = > > > Denis<BR> = = = > > ><BR> = = = > > ><BR> = = = > = ______________________________________________________________________<BR= > = = = > _<BR> = = = > > > _______<BR> = = = > > ><BR> = = = > > > >Since last = IETF a new draft was posted:<BR> = = = > > > ><A = HREF=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-">= http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-</A><BR> = = = > 00.txt<BR> = = = > > > ><BR> = = = > > > >There is a = request to add this draft to the PKIX work and I would<BR> = = = > > > encourage to = start the discussion about this decision in this<BR> = = = > thread.<BR> = = = > > > ><BR> = = = > > > >Stefan = Santesson<BR> = = = > > > >Senior = Program Manager<BR> = = = > > > >Windows = Security, Standards<BR> = = = > > ><BR> = = = > > ><BR> = = = > > ><BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C750DB.6FF44DB6-- 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 l1EMJWfK091081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 15:19: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 l1EMJW3Q091080; Wed, 14 Feb 2007 15:19: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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EMJUVZ091073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 15:19:31 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l1EMJOt8022897; Wed, 14 Feb 2007 14:19:24 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:19:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75086.2D34F34A" Subject: RE: Certificates in CRLs Date: Wed, 14 Feb 2007 14:19:00 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37011472C3@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Certificates in CRLs Thread-Index: AcdQWSrvvnyENl6jQGGL0oTHSXwDLAALN1PQ From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Guida, Richard [JJCUS]" <RGuida@CORUS.JNJ.com>, "Peter Hesse" <pmhesse@geminisecurity.com>, "Sharon Boeyen" <sharon.boeyen@entrust.com>, "Stefan Santesson" <stefans@microsoft.com>, "Russ Housley" <housley@vigilsec.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 14 Feb 2007 22:19:22.0625 (UTC) FILETIME=[2DB86F10:01C75086] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C75086.2D34F34A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The archival purpose is a major one for me. It means that I can put a = complete package together quickly and efficiently. ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Guida, Richard = [JJCUS] Sent: Wednesday, February 14, 2007 10:03 AM To: Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan = Santesson'; 'Russ Housley' Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 I likewise agree with Peter, Phillip and Stefan. The CRL bloat is not = large, and for those of us with large CRLs to begin with (can debate = separately why that circumstance exists...), the bloat is negligible. = Since this is entirely optional; and since the owner of a CA therefore = has full discretion to include or not include the certs (and can do as = Peter described and published two virtually contemporaneous CRLs, one = with and one without, if needed to avoid breaking apps), it seems to me = that this approach can be used in a fashion which does not break = anything, and it can provide real value for archival purposes. =20 Richard A. Guida=20 Director, Information Security=20 Johnson & Johnson=20 Room GS8217=20 410 George Street=20 New Brunswick, New Jersey 08901=20 Phone: 732 524 3785=20 -----Original Message----- From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Peter Hesse Sent: Wednesday, February 14, 2007 12:05 AM To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; = 'Russ Housley' Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 I'm in agreement that Stefan's proposal is a decent one. As Phillip = mentions, it certainly isn't appropriate in every situation, but I can = see situations in which it might be useful. One might argue that a CRL = issuer could issue two CRLs, the most commonly retrieved one without = this extension, but a separate one issued with it-the latter being made = to applications responsible for long term archive, historical signature = validation, or other purposes which might find it useful. =20 =20 I don't see any harm in adding this extension as an optional feature = for PKIs that wish it, since it is truly optional, non-critical, and = does not affect path processing. =20 =20 --Peter =20 +----------------------------------------------------------------+ | Peter Hesse pmhesse@geminisecurity.com | | Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. | | Visit our InfoSecurity blog: securitymusings.com = <http://www.securitymusings.com/> | +----------------------------------------------------------------+ "The generation of random numbers is too important to be left to chance." --Robert R. Coveyou =20 =20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, February 13, 2007 6:53 PM To: Sharon Boeyen; Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I think that Sharon's proposal might have been a good idea in 1995 = before the world got wedged on CRLs as the revocation mechanism. We can = define a package but its too late to get it embedded in the rest of the = application infrastructure. =20 Given where we are Stefan's proposal is the best one. It is compatible = with the existing infrastructure and solves a real issue.=20 =20 It is an option, clearly there are cases where it would be = inappropriate but universal applicability has never been a requirement. = Otherwise we could have saved all the time spent on attribute = certificates. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Stefan I really don't think you can state where this will or will not = be used in the future. Naturally you know where you want to use it, but = software only enables a facility and the customer decides when and how = to use it.=20 =20 Whether this scheme could possibly be useful in some cases is not my = point. My point is that current deployments seem to be working fine = without it and I don't want to see those interfered with just because = some CA they may have cross certified with decided to put certificates = inside their CRLS. Back to Denis' point - there is no need to impose = this in the way you've proposed.=20 =20 Earlier I (and others including Dave Kemp) suggested a "package" that = includes the CRL, and the certificate in question as an 'extra' that a = CA could publish in addition to a regular CRL. That "package could be = published in a separate directory attribute and/or an HTTP accessible = file. It could be pointed to from within the certificate just as the CRL = currently is. That could be done either by extending the CRLDP or adding = a new pointer extension or adding a new method to the AIA extension. = That type of approach gives you what you want but does not in any way = interfere with clients who do not want and do not need to retrieve that = bloated CRL.=20 =20 Also, you haven't addressed the question about what happens when more = than one certificate is needed. If a CRL includes more than one = certificate (e.g. the CRL issuer did one or more key rollovers then CRL = gets bloated a lot bigger than you suggested. I don't want to debate how = often a key gets rolled over either however I have definitely seen = instances in real world deployments where a key has been rolled very = often in a very short period of time (regardless of whether the reason = for rolling it was a good one or not - it has happened). Also, = regardless of the size of the "bloat" I'm saying that in most cases the = clients will already have the certificates in question and this bloat = will cause them extra processing in managing their certificate caches = etc unnecessarily. The client should have a choice as to whether to = download the certificate or not. =20 I don't understand why you're so opposed to the "package" solution.=20 =20 Cheers, Sharon=20 -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs We are only talking about an extra 16K at most. The download time is = the absolute most cases is negligible.=20 For those cases where this solution makes sense, the network = bandwidth issue is not a problem. =20 For the cases where this would be an issue, this solution would not = be used. =20 On the contrary, in some networks and scenarios, this will improve = performance. Especially in high latency networks with PKI based = peer-peer authentication where an extra retrieval cost way more = performance than the expanded CRL size. =20 Also, many clients are configured to pre-fetch CRL:s before they are = used, using idle time on the network at no extra cost. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I still think wasted bandwidth is also an issue. Forcing the = download of 'fat' CRLs on clients when, in many cases, those clients = already have the certificates locally that caused the bloating of the = CRL, is an unnecessary waste. -----Original Message-----=20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson=20 Sent: Wednesday, January 03, 2007 9:58 AM=20 To: Russ Housley=20 Cc: ietf-pkix@imc.org=20 Subject: RE: Certificates in CRLs=20 =20 Russ,=20 In theory, the CA can put different pointers to different CRLs in = each certificate if some certificates are prime targets for frequent = checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would = have to add capability to the CDP extension rather than to the CRL. I = don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in = situations where it in the sum of all, helps increase efficiency and = where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, = but that some implementers simply don't want to be faced with the = requirement to implement this feature. But I don't see that they have = to. A CRL with certs in a non-critical extension should work just as = well in current clients as any current CRL without certs. The extension = can simply be ignored. This is not a necessary feature, but a practical one offering = performance improvements in some environments at no loss of = interoperability. =20 Stefan Santesson=20 Senior Program Manager=20 Windows Security, Standards=20 =20 > -----Original Message-----=20 > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: den 21 december 2006 16:19=20 > To: Stefan Santesson=20 > Cc: ietf-pkix@imc.org=20 > Subject: RE: Certificates in CRLs=20 >=20 > Stefan:=20 >=20 > If the CA chooses to offer both, how can the RP determine which = one it=20 > will get? Does the CA post them in different LDAP attributes?=20 >=20 > Russ=20 >=20 > At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20 >=20 > >As with anything else, the relying party can get what the CA = offers.=20 > >=20 > >I don't think there is any realistic scenario where the CA has a=20 > >reason to offer CRLs both with and without certificates. To offer = > >this capability to RP is however not a matter for this protocol. = It=20 > >would be a matter for the CRL referencing model, i.e. CDP and/or=20 > >directory schema.=20 > >=20 > >I don't think that extra complexity however is very useful.=20 > >=20 > >Stefan Santesson=20 > >Senior Program Manager=20 > >Windows Security, Standards=20 > >=20 > >=20 > > > -----Original Message-----=20 > > > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-=20 > > > pkix@mail.imc.org] On Behalf Of Denis Pinkas=20 > > > Sent: den 20 december 2006 17:05=20 > > > To: ietf-pkix@imc.org=20 > > > Subject: Re: Certificates in CRLs=20 > > >=20 > > >=20 > > >=20 > > > It is necessary to provide relying parties with the choice to = get=20 > > > :=20 > > >=20 > > > - CRLs "as usual", or=20 > > > - CRLs that carry that new extension.=20 > > >=20 > > > The current proposal does not allow for it.=20 > > >=20 > > > Until the draft is changed, I am against the addition of this = work=20 > item=20 > > > to the program of the PKIX WG.=20 > > >=20 > > > Denis=20 > > >=20 > > >=20 > = ______________________________________________________________________=20 > _=20 > > > _______=20 > > >=20 > > > >Since last IETF a new draft was posted:=20 > > > = >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20 > 00.txt=20 > > > >=20 > > > >There is a request to add this draft to the PKIX work and I = would=20 > > > encourage to start the discussion about this decision in this=20 > thread.=20 > > > >=20 > > > >Stefan Santesson=20 > > > >Senior Program Manager=20 > > > >Windows Security, Standards=20 > > >=20 > > >=20 > > >=20 ------_=_NextPart_001_01C75086.2D34F34A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 = =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types"><HEAD><TITLE>= Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 70.85pt 70.85pt 70.85pt = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: = "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle18 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal } SPAN.EmailStyle19 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal-reply } .MsoChpDefault { FONT-SIZE: 10pt; mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749191822-14022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>The archival purpose is a major one for me. It = means that I=20 can put a complete package together quickly and=20 efficiently.</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] <B>On Behalf Of </B>Guida, = Richard=20 [JJCUS]<BR><B>Sent:</B> Wednesday, February 14, 2007 10:03 = AM<BR><B>To:</B>=20 Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan = Santesson'; 'Russ=20 Housley'<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D790115814-14022007><FONT face=3DArial = color=3D#0000ff size=3D2>I=20 likewise agree with Peter, Phillip and Stefan. The CRL bloat is = not=20 large, and for those of us with large CRLs to begin with (can debate=20 separately why that circumstance exists...), the bloat is = negligible. =20 Since this is entirely optional; and since the owner of a CA therefore = has=20 full discretion to include or not include the certs (and can do as = Peter=20 described and published two virtually contemporaneous CRLs, one with = and one=20 without, if needed to avoid breaking apps), it seems to me that this = approach=20 can be used in a fashion which does not break anything, and it can = provide=20 real value for archival purposes.</FONT></SPAN></DIV> <DIV><FONT face=3DArial color=3D#0000ff = size=3D2></FONT> </DIV><BR> <P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> = <BR><B><FONT=20 face=3DArial size=3D2>Director, Information Security</FONT></B> </P> <P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 = size=3D5>Johnson &=20 Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room = GS8217</FONT>=20 <BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT = face=3DArial=20 size=3D2>New Brunswick, New Jersey 08901</FONT> <BR><FONT = face=3DArial=20 size=3D2>Phone: 732 524 3785</FONT> </P> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org]<B>On=20 Behalf Of </B>Peter Hesse<BR><B>Sent:</B> Wednesday, February 14, = 2007 12:05=20 AM<BR><B>To:</B> 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan=20 Santesson'; 'Russ Housley'<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<BR><BR></FONT></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=92m=20 in agreement that Stefan=92s proposal is a decent one. As = Phillip=20 mentions, it certainly isn=92t appropriate in every situation, but I = can see=20 situations in which it might be useful. One might argue that a = CRL=20 issuer could issue two CRLs, the most commonly retrieved one without = this=20 extension, but a separate one issued with it=97the latter being made = to=20 applications responsible for long term archive, historical signature = validation, or other purposes which might find it useful. =20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=20 don=92t see any harm in adding this extension as an optional feature = for PKIs=20 that wish it, since it is truly optional, non-critical, and does not = affect=20 path processing. <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier = New'">+----------------------------------------------------------------+<= BR>| </SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier = New'">Peter=20 Hesse</SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> &= nbsp; <SPAN=20 style=3D"COLOR: blue"><A=20 = href=3D"mailto:pmhesse@geminisecurity.com">pmhesse@geminisecurity.com</A>= </SPAN> <SPAN=20 style=3D"COLOR: gray">|<BR>| </SPAN><SPAN style=3D"COLOR: = #3333cc">Phone:=20 703-378-5808 x105</SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Gemini Security Solutions,=20 Inc. </SPAN><SPAN=20 style=3D"COLOR: = gray">|<BR>| </SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20 = href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&n= bsp; <SPAN=20 style=3D"COLOR: = gray">|<BR>+-------------------------------------------------------------= ---+<BR></SPAN><SPAN=20 style=3D"COLOR: teal">"The generation of random numbers is too = important to be=20 left<BR> to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: = medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, = February 13,=20 2007 6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 think that Sharon's proposal might have been a good idea in 1995 = before the=20 world got wedged on CRLs as the revocation mechanism. We can define = a=20 package but its too late to get it embedded in the rest of the = application=20 infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Given=20 where we are Stefan's proposal is the best one. It is compatible = with the=20 existing infrastructure and solves a real issue. </SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">It=20 is an option, clearly there are cases where it would be = inappropriate but=20 universal applicability has never been a requirement. Otherwise we = could=20 have saved all the time spent on attribute certificates.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt = 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: = medium none"> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter> <HR align=3Dcenter width=3D"100%" SIZE=3D2> </DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, = 2007 9:09=20 AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE:=20 Certificates in CRLs</SPAN><o:p></o:p></P> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 I really don't think you can state where this will or will not be = used in=20 the future. Naturally you know where you want to use it, but = software only=20 enables a facility and the customer decides when and how to use = it.=20 </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Whether=20 this scheme could possibly be useful in some cases is not my = point. My=20 point is that current deployments seem to be working fine without = it and I=20 don't want to see those interfered with just because some CA they = may have=20 cross certified with decided to put certificates inside their = CRLS. Back=20 to Denis' point - there is no need to impose this in the way = you've=20 proposed. </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Earlier=20 I (and others including Dave Kemp) suggested a "package" that = includes the=20 CRL, and the certificate in question as an 'extra' that a CA could = publish=20 in addition to a regular CRL. That "package could be published in = a=20 separate directory attribute and/or an HTTP accessible file. It = could be=20 pointed to from within the certificate just as the CRL = currently is.=20 That could be done either by extending the CRLDP or adding a=20 new pointer extension or adding a new method to the AIA = extension.=20 That type of approach gives you what you want but does not in any = way=20 interfere with clients who do not want and do not need to retrieve = that=20 bloated CRL. </SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Also,=20 you haven't addressed the question about what happens = when more=20 than one certificate is needed. If a CRL includes more than one=20 certificate (e.g. the CRL issuer did one or more key=20 rollovers then CRL gets bloated a lot bigger than you=20 suggested. I don't want to debate how often a key gets rolled = over=20 either however I have definitely seen instances in real world = deployments=20 where a key has been rolled very often in a very short period of = time=20 (regardless of whether the reason for rolling it was a good one or = not -=20 it has happened). Also, regardless of the size of the "bloat" I'm = saying=20 that in most cases the clients will already have the certificates = in=20 question and this bloat will cause them extra processing in = managing their=20 certificate caches etc unnecessarily. The client should have a = choice as=20 to whether to download the certificate or not.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 don't understand why you're so opposed to the "package"=20 solution. </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Cheers,</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Sharon</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">-----Original=20 Message-----<BR><B>From:</B> Stefan Santesson=20 [mailto:stefans@microsoft.com] <BR><B>Sent:</B> Friday, January = 05, 2007=20 8:01 AM<BR><B>To:</B> Sharon Boeyen; Russ Housley<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV> <BLOCKQUOTE=20 style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: 0in"> <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">We=20 are only talking about an extra 16K at most. The download time = is the=20 absolute most cases is negligible. </SPAN></A><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 those cases where this solution makes sense, the network = bandwidth issue=20 is not a problem.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 the cases where this would be an issue, this solution would not = be=20 used.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">On=20 the contrary, in some networks and scenarios, this will improve=20 performance. Especially in high latency networks with PKI based=20 peer-peer authentication where an extra retrieval cost way more=20 performance than the expanded CRL size.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">Also,=20 many clients are configured to pre-fetch CRL:s before they are = used,=20 using idle time on the network at no extra = cost.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 Santesson</SPAN></B><SPAN lang=3DEN-GB=20 style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Senior=20 Program Manager</SPAN><SPAN lang=3DEN-GB=20 style=3D"COLOR: navy"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Windows=20 Security, Standards</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; = BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium = none"> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; = BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> = Sharon=20 Boeyen [mailto:sharon.boeyen@entrust.com] <BR><B>Sent:</B> den 4 = januari=20 2007 17:36<BR><B>To:</B> Stefan Santesson; Russ = Housley<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><SPAN = lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think = wasted bandwidth=20 is also an issue. Forcing the download of 'fat' CRLs on clients = when, in=20 many cases, those clients already have the certificates locally = that=20 caused the bloating of the CRL, is an unnecessary = waste.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">From: owner-ietf-pkix@mail.imc.org [<A = = href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>]=20 On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, = 2007 9:58=20 AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in = CRLs</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20 lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN = lang=3DSV>=20 <o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA = can put=20 different pointers to different CRLs in each certificate if some = certificates are prime targets for frequent checking. But I = don't think=20 that is a common scenario.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in = order to=20 allow free selection of CRLs, you would have to add capability = to the=20 CDP extension rather than to the CRL. I don't think such effort = is worth=20 the trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that = including=20 certs in a CRL will only be made in situations where it in the = sum of=20 all, helps increase efficiency and where the extra bandwidth = consumed is=20 not an issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique = of this=20 idea as not really be a bandwidth issue, but that some = implementers=20 simply don't want to be faced with the requirement to implement = this=20 feature. But I don't see that they have to. A CRL with certs in = a=20 non-critical extension should work just as well in current = clients as=20 any current CRL without certs. The extension can simply be=20 ignored.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a = necessary=20 feature, but a practical one offering performance improvements = in some=20 environments at no loss of interoperability.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN = lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan = Santesson</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">Senior Program=20 Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Windows Security, = Standards</SPAN><SPAN lang=3DSV>=20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN = lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> -----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> From: Russ Housley [<A=20 = href=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]</SP= AN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> Sent: den=20 21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> To: Stefan Santesson</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> Subject: RE: Certificates in=20 CRLs</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> Stefan:</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> If the CA=20 chooses to offer both, how can the RP determine which one it=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> will get? Does the CA post = them in=20 different LDAP attributes?</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> Russ</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> At 08:00=20 AM 12/21/2006, Stefan Santesson wrote:</SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >As=20 with anything else, the relying party can get what the CA=20 offers.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >I don't think there = is any=20 realistic scenario where the CA has a </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >reason=20 to offer CRLs both with and without certificates. To offer = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >this=20 capability to RP is however not a matter for this protocol. It=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >would be a matter for the CRL = referencing model, i.e. CDP and/or </SPAN><SPAN = lang=3DSV><BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >directory = schema.</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >I don't think that extra = complexity=20 however is very useful.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >Stefan = Santesson</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 >Senior Program Manager</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >Windows Security, = Standards</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> > > -----Original = Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > From:=20 owner-ietf-pkix@mail.imc.org [<A=20 href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 pkix@mail.imc.org] On Behalf Of Denis Pinkas</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Sent:=20 den 20 december 2006 17:05</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > To: = ietf-pkix@imc.org</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > It is=20 necessary to provide relying parties with the choice to get = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs that carry that new = extension.</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > The current proposal = does not=20 allow for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Until=20 the draft is changed, I am against the addition of this = work</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > to the program of the = PKIX=20 WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">>=20 = ______________________________________________________________________</S= PAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > _______</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Since last IETF a = new draft=20 was posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" = = target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-= vccrl-</A></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 >There is a request to add this draft to the PKIX work and I=20 would</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > encourage to start the = discussion=20 about this decision in this</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> thread.</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Stefan = Santesson</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 >Senior Program Manager</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Windows Security,=20 Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 = <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV></BLOCKQUOTE>= </BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C75086.2D34F34A-- 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 l1ELlIRf088884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 14:47: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 l1ELlIGV088883; Wed, 14 Feb 2007 14:47: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l1ELlHGq088861 for <ietf-pkix@vpnc.org>; Wed, 14 Feb 2007 14:47:17 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200702142147.l1ELlHGq088861@balder-227.proper.com> Received: (qmail 7130 invoked by uid 0); 14 Feb 2007 21:47:10 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 14 Feb 2007 21:47:10 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 16:19:13 -0500 To: Paul Hoffman <paul.hoffman@vpnc.org>, ietf-pkix@vpnc.org From: Russ Housley <housley@vigilsec.com> Subject: Re: URN in subjectAltName In-Reply-To: <p0624087ec1f92544c47c@[10.20.30.108]> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> <p0624087ec1f92544c47c@[10.20.30.108]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Ooops: s/server/several/ RFC 3280 says: When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST NOT be a relative URL, and it MUST follow the URL syntax and encoding rules specified in [RFC 1738]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-specific-part MUST include a fully qualified domain name or IP address as the host. As specified in [RFC 1738], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. When comparing URIs, conforming implementations MUST compare the scheme and host without regard to case, but assume the remainder of the scheme-specific-part is case sensitive. I think this prohibits the use of a URN like this: URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN Russ At 03:47 PM 2/14/2007, Paul Hoffman wrote: >At 1:43 PM -0500 2/14/07, Russ Housley wrote: >>Milan & Paul: >> >>>>As the group does not seem to have a strong opinion of the choices I >>>>propose to include the following text just after the URI part of the >>>>section 4.2.1.6 Subject Alternative Name: >>>> >>>>"When the subjectAltName extension contains a URN, the name MUST be >>>>stored in the uniformResourceIdentifier (IA5String). The name MUST >>>>follow the URN syntax and encoding rules specified in [RFC 2141]." >>>> >>>> Comments? >>> >>>This seems like a good addition, seeing as there were multiple >>>choices given on the mailing list, and that means interoperability >>>issues. Note that there are two paragraphs to the "URI part"; this >>>should be added after the second paragraph, just before "When the >>>subjectAltName extension contains a DN...". >> >>I thought that sever people expressed concern that implementations >>that follow RFC 3280 will only expect a URL, so the URN ought to be >>encoded in other name. > >I don't know which server people those are, but there is nothing in >RFC 3280 or 3280bis that would make me think "this is a URL and not a URI". > >>It would be a very simple (one page) specification. > >That's true, but there is no reason not to make it part of the only >specification that most implementers will read. I still support >putting it into 3280bis to encourage interoperability. > >--Paul Hoffman, Director >--VPN Consortium > 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 l1ELIdoR086110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 14:18: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 l1ELIdRa086109; Wed, 14 Feb 2007 14:18: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 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 l1ELIc8i086103 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 14:18:39 -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: URN in subjectAltName Date: Wed, 14 Feb 2007 13:18:20 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C879069A54B9@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URN in subjectAltName Thread-Index: AcdQfFlkE263CWORQq2TRChreYysrQAARruQ References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <45D36B33.1020407@nist.gov> From: "Santosh Chokhani" <chokhani@orionsec.com> To: "David A. Cooper" <david.cooper@nist.gov>, "pkix" <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l1ELId8i086104 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> David, I do not know much about URI also, but the following statement bothers me: "Note that 3280bis currently allows for the inclusion of LDAP URIs without host names in the cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess extensions?" I suspect it will break many applications that invoke the URI to obtain the certificates and CRLs. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Wednesday, February 14, 2007 3:04 PM To: pkix Subject: Re: URN in subjectAltName All, I don't know very much about URIs, and I don't really have an opinion about what the subjectAltName section of 3280bis should say about URIs. My only concern is to ensure that the document is completed soon and that it is correct. The latest version of idnits pointed out that RFC 1738 has been obsoleted, and while 3280bis still points to RFC 1738 as the specification for the HTTP URI syntax, I changed the text in the subjectAltName section to point to RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax). So, the relevant text now reads: When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST NOT be a relative URL, and it MUST follow the URL syntax and encoding rules specified in [RFC 3986]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-specific-part MUST include a fully qualified domain name or IP address as the host. Rules for encoding internationalized resource identifiers (IRIs) are specified in section 7.4. As specified in [RFC 3986], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. Rules for comparing URIs are specified in section 7.4. While RFC 2141 is not listed as having been updated or obsoleted by any other RFCs, section 1.1.3 of RFC 3986 states: A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]. As I read this, the use of the term "Uniform Resource Name" is not limited to URIs that conform to the "urn" scheme in RFC 2141 and it is now recommended that specifications not try to distinguish between different types of URIs. As I read the proposal below, it is recommending that 3280bis state that the uniformResourceIdentifier may be used to contain a name that conforms to the "urn" scheme of RFC 2141, but that all other URIs that are placed in uniformResourceIdentifier must conform to the rules specified in RFC 3280. Is that correct and is it intentional? If not, and it is agreed that 3280bis should allow for the inclusion in the subjectAltName extension of URIs that do not include host names, would it better to simply remove the text that specifies this requirement so that the text would read: When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST follow the URI syntax and encoding rules specified in [RFC 3986]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. Rules for encoding internationalized resource identifiers (IRIs) are specified in section 7.4. As specified in [RFC 3986], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. Rules for comparing URIs are specified in section 7.4. Note that 3280bis currently allows for the inclusion of LDAP URIs without host names in the cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess extensions? Although it should also be noted that 3280bis only provides a way for imposing name constraints on URIs that include a DNS name. As I read this, any names that are placed in the uniformResourceIdentifier name form that do not contain DNS names are unconstrained, regardless of the contents of nameConstraints extensions in other certificates in the path, which would seem to argue against allowing such names to be placed in the uniformResourceIdentifier name form. Dave Paul Hoffman wrote: > At 12:02 AM +0100 2/13/07, Milan Sova wrote: >> As the group does not seem to have a strong opinion of the choices I >> propose to include the following text just after the URI part of the >> section 4.2.1.6 Subject Alternative Name: >> >> "When the subjectAltName extension contains a URN, the name MUST be >> stored in the uniformResourceIdentifier (IA5String). The name MUST >> follow the URN syntax and encoding rules specified in [RFC 2141]." >> >> Comments? > > This seems like a good addition, seeing as there were multiple choices > given on the mailing list, and that means interoperability issues. > Note that there are two paragraphs to the "URI part"; this should be > added after the second paragraph, just before "When the subjectAltName > extension contains a DN...". > > --Paul Hoffman, Director > --VPN Consortium 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 l1EKljEr083764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 13:47: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 l1EKljIx083763; Wed, 14 Feb 2007 13:47: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EKlfeR083749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 13:47:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p0624087ec1f92544c47c@[10.20.30.108]> In-Reply-To: <200702141843.l1EIhlbF072860@balder-227.proper.com> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> <200702141843.l1EIhlbF072860@balder-227.proper.com> Date: Wed, 14 Feb 2007 12:47:27 -0800 To: Russ Housley <housley@vigilsec.com>, ietf-pkix@vpnc.org From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: URN in subjectAltName Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 1:43 PM -0500 2/14/07, Russ Housley wrote: >Milan & Paul: > >>>As the group does not seem to have a strong opinion of the choices I >>>propose to include the following text just after the URI part of the >>>section 4.2.1.6 Subject Alternative Name: >>> >>>"When the subjectAltName extension contains a URN, the name MUST be >>>stored in the uniformResourceIdentifier (IA5String). The name MUST >>>follow the URN syntax and encoding rules specified in [RFC 2141]." >>> >>> Comments? >> >>This seems like a good addition, seeing as there were multiple >>choices given on the mailing list, and that means interoperability >>issues. Note that there are two paragraphs to the "URI part"; this >>should be added after the second paragraph, just before "When the >>subjectAltName extension contains a DN...". > >I thought that sever people expressed concern that implementations >that follow RFC 3280 will only expect a URL, so the URN ought to be >encoded in other name. I don't know which server people those are, but there is nothing in RFC 3280 or 3280bis that would make me think "this is a URL and not a URI". >It would be a very simple (one page) specification. That's true, but there is no reason not to make it part of the only specification that most implementers will read. I still support putting it into 3280bis to encourage interoperability. --Paul Hoffman, Director --VPN Consortium 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 l1EK56nN080254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 13:05:07 -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 l1EK56FT080253; Wed, 14 Feb 2007 13:05: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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EK55uO080246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 13:05:06 -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 l1EK3E5W008487 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 15:03:22 -0500 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 l1EK2t9n008024 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 15:02:56 -0500 (EST) Message-ID: <45D36B33.1020407@nist.gov> Date: Wed, 14 Feb 2007 15:04:03 -0500 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Thunderbird 1.5.0.9 (X11/20070111) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: URN in subjectAltName References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> In-Reply-To: <p0624086dc1f8172775ff@[10.20.30.108]> 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> All, I don't know very much about URIs, and I don't really have an opinion about what the subjectAltName section of 3280bis should say about URIs. My only concern is to ensure that the document is completed soon and that it is correct. The latest version of idnits pointed out that RFC 1738 has been obsoleted, and while 3280bis still points to RFC 1738 as the specification for the HTTP URI syntax, I changed the text in the subjectAltName section to point to RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax). So, the relevant text now reads: When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST NOT be a relative URL, and it MUST follow the URL syntax and encoding rules specified in [RFC 3986]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme-specific-part MUST include a fully qualified domain name or IP address as the host. Rules for encoding internationalized resource identifiers (IRIs) are specified in section 7.4. As specified in [RFC 3986], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. Rules for comparing URIs are specified in section 7.4. While RFC 2141 is not listed as having been updated or obsoleted by any other RFCs, section 1.1.3 of RFC 3986 states: A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]. As I read this, the use of the term "Uniform Resource Name" is not limited to URIs that conform to the "urn" scheme in RFC 2141 and it is now recommended that specifications not try to distinguish between different types of URIs. As I read the proposal below, it is recommending that 3280bis state that the uniformResourceIdentifier may be used to contain a name that conforms to the "urn" scheme of RFC 2141, but that all other URIs that are placed in uniformResourceIdentifier must conform to the rules specified in RFC 3280. Is that correct and is it intentional? If not, and it is agreed that 3280bis should allow for the inclusion in the subjectAltName extension of URIs that do not include host names, would it better to simply remove the text that specifies this requirement so that the text would read: When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST follow the URI syntax and encoding rules specified in [RFC 3986]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. Rules for encoding internationalized resource identifiers (IRIs) are specified in section 7.4. As specified in [RFC 3986], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. Rules for comparing URIs are specified in section 7.4. Note that 3280bis currently allows for the inclusion of LDAP URIs without host names in the cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess extensions? Although it should also be noted that 3280bis only provides a way for imposing name constraints on URIs that include a DNS name. As I read this, any names that are placed in the uniformResourceIdentifier name form that do not contain DNS names are unconstrained, regardless of the contents of nameConstraints extensions in other certificates in the path, which would seem to argue against allowing such names to be placed in the uniformResourceIdentifier name form. Dave Paul Hoffman wrote: > At 12:02 AM +0100 2/13/07, Milan Sova wrote: >> As the group does not seem to have a strong opinion of the choices I >> propose to include the following text just after the URI part of the >> section 4.2.1.6 Subject Alternative Name: >> >> "When the subjectAltName extension contains a URN, the name MUST be >> stored in the uniformResourceIdentifier (IA5String). The name MUST >> follow the URN syntax and encoding rules specified in [RFC 2141]." >> >> Comments? > > This seems like a good addition, seeing as there were multiple choices > given on the mailing list, and that means interoperability issues. > Note that there are two paragraphs to the "URI part"; this should be > added after the second paragraph, just before "When the subjectAltName > extension contains a DN...". > > --Paul Hoffman, Director > --VPN Consortium 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 l1EJtBWb078980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 12:55: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 l1EJtB3m078979; Wed, 14 Feb 2007 12:55: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EJt7OH078966 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 12:55:09 -0700 (MST) (envelope-from Kurt.Zeilenga@Isode.com) Received: from [192.168.1.102] ((unknown) [24.176.246.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <RdNpFgBXDhVb@rufus.isode.com>; Wed, 14 Feb 2007 19:55:04 +0000 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8453B099-4E99-4131-820D-334517600D5A@Isode.com> Cc: Russ Housley <housley@vigilsec.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Subject: LDAP issues in rfc3280bis Date: Wed, 14 Feb 2007 11:54:48 -0800 To: ietf-pkix@imc.org X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I have reviewed draft-ietf-pkix-rfc3280bis-07 for LDAP-related issues, in particular those around the use of the binary encoding option, and find the following issues, all relatively minor. In Section 2.1, references to X.500 and RFC 4510 should be added, respectively for the terms "X.500 Directory" and "LDAP". The term LDAP should also be spelled out here (first use in body). In Section 4.2.1.13, in the paragraph starting with "If the DistributionPointName contains", the sentence starting with A reference to RFC 4516 should be provided for "LDAP scheme". Also, in this sentence, the term "distinguishedName" field appears to refer to the <dn> field of the LDAP URI, the term "attribute" to a <attrdesc> field, and "host name" to the <host> field. For clarity, it might be better to say: When the LDAP URI scheme [RFC4516] is used, the URI MUST contain a <dn> field containing the distinguished name of the entry holding the CRL, MUST contain an <attrdesc> field containing the name of the attribute holding the CRL, and SHOULD contain a <host>. For instance, <ldap://ldap.example.com/cn=exmplCA, dc=exmaple,dc=com?certificateRevocationList;binary>. It may be appropriate to add: Where the attribute holding the CRL, typically certificateRevocationList or authorityRevocationList [RFC4523] requires transfer using ;binary, the <attrdesc> field MUST include the binary encoding option, ;binary, as discussed in RFC 4522 [RFC4522]. And then to clarify the no host field text: Omitting the host name (e.g., <ldap:///cn=example% 20CA,dc=example,dc=com? authorityRevocationList;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server. Note that I have used angle brackets to clearly indicate the start and end of the URI. Angle brackets are reserved in the LDAP URI syntax for this purpose. I suggest similar changes be made to sections 4.2.2.1 and 5.2 materials discussing use of LDAP URIs. -- Kurt 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 l1EJXju8076972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 12:33: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 l1EJXjgd076971; Wed, 14 Feb 2007 12:33: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l1EJXix1076962 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 12:33:44 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200702141933.l1EJXix1076962@balder-227.proper.com> Received: (qmail 8533 invoked by uid 0); 14 Feb 2007 19:33:38 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 14 Feb 2007 19:33:38 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 14:33:37 -0500 To: "Jonghyun Baek" <jhbaek@kisa.or.kr> From: Russ Housley <housley@vigilsec.com> Subject: Re: Questions on the use case of KeyUsage type in Key Usage extension Cc: ietf-pkix@imc.org In-Reply-To: <002501c74ffb$9a7d0a60$670710ac@5423D2> References: <002501c74ffb$9a7d0a60$670710ac@5423D2> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <html> <body> Jonghyun Baek:<br><br> The encipherOnly and decipherOnly were specified to support a form of key escrow that was developed at Royal Holloway. To the best of my knowledge, no one is using that key escrow system today.<br><br> Russ<br><br> <br> <blockquote type=cite class=cite cite=""><font size=2>Dear PKIX WG,<br> </font> <br> <font size=2>The key usage extension(section 4.2.1.3 in RFC3280) have nine KeyUsage types such as digitalSignature, non repudiation, keyEncipherment, etc.<br> I can understood each of the KeyUsage types meaning but i would like to know a real example or a use case of the encipherOnly type and the decipherOnly type. i mean which kind of the service or application need the encipherOnly or decipherOnly type certificate and for what ?<br> I will be so appriciate if you give me a hand.<br> </font> <br> <font size=2>Thanks!<br> </font> <br> <font size=2>Jonghyun Baek</font> <br> <br> <font size=2>=================================================== <br> Jonghyun Baek <br> --------------------------------------------------- <br> Senior Researcher<br> Electronic Transaction Security Planning Team<br> Korea Information Security Agency (KISA) <br> --------------------------------------------------- <br> 78 Garak-Dong, Songpa-Gu, Seoul, Korea 138-803 <br> Tel : +82-2-405-5423 <br> Fax : +82-2-405-5219 <br> Mobile : +82-16-591-3664 <br> E-mail : <a href="mailto:jhbaek@kisa.or.kr">jhbaek@kisa.or.kr</a> <br> ===================================================</font></blockquote> </body> </html> 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 l1EIhmQO072869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 11:43: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 l1EIhm3M072868; Wed, 14 Feb 2007 11:43: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l1EIhlbF072860 for <ietf-pkix@vpnc.org>; Wed, 14 Feb 2007 11:43:47 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200702141843.l1EIhlbF072860@balder-227.proper.com> Received: (qmail 19340 invoked by uid 0); 14 Feb 2007 18:43:42 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 14 Feb 2007 18:43:42 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Feb 2007 13:43:35 -0500 To: ietf-pkix@vpnc.org From: Russ Housley <housley@vigilsec.com> Subject: Re: URN in subjectAltName In-Reply-To: <p0624086dc1f8172775ff@[10.20.30.108]> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> <p0624086dc1f8172775ff@[10.20.30.108]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Milan & Paul: >>As the group does not seem to have a strong opinion of the choices I >>propose to include the following text just after the URI part of the >>section 4.2.1.6 Subject Alternative Name: >> >>"When the subjectAltName extension contains a URN, the name MUST be >>stored in the uniformResourceIdentifier (IA5String). The name MUST >>follow the URN syntax and encoding rules specified in [RFC 2141]." >> >> Comments? > >This seems like a good addition, seeing as there were multiple >choices given on the mailing list, and that means interoperability >issues. Note that there are two paragraphs to the "URI part"; this >should be added after the second paragraph, just before "When the >subjectAltName extension contains a DN...". I thought that sever people expressed concern that implementations that follow RFC 3280 will only expect a URL, so the URN ought to be encoded in other name. It would be a very simple (one page) specification. 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 l1EH7qbB064645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 10:07: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 l1EH7qE5064644; Wed, 14 Feb 2007 10:07: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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EH7oXL064630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 10:07:51 -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 l1EH7kgD009729; Wed, 14 Feb 2007 09:07:46 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 09:07:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7505A.A565DAF4" Subject: RE: Certificates in CRLs Date: Wed, 14 Feb 2007 09:06:25 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3701147298@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Certificates in CRLs Thread-Index: AcdQO6Ih5nyo8qPsR/yRaKUOHugZGgAHpShg From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Denis Pinkas" <denis.pinkas@bull.net>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 14 Feb 2007 17:07:46.0088 (UTC) FILETIME=[A5B74A80:01C7505A] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C7505A.A565DAF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We could load these semantics into the CRL Distribution point but a = simpler way to support them would be via the existing HTTP content = negotiation mechanism (ACCEPT header).=20 =20 To do this all we need to do is to define the appropriate descriptions. = A single distribution point resource identifier then serves for both = resources. ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Wednesday, February 14, 2007 5:57 AM To: ietf-pkix@imc.org Subject: Re: Certificates in CRLs =09 =09 A way forward ? =20 The key issue is not the structure of the "augmented" CRL proposed by = Stefan,=20 but the ability to retrieve from a given CA either a CRL (i.e. the = current=20 structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed = by Stefan),=20 if a CA chooses to issue both.=20 =20 We need to focus on the cRLDistributionPoints extension to allow = retrieving=20 either a CRL, or a CRLwithCerts, or both. =20 Let us have a look at some sentences extracted from RFC 3280: =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The cRLDistributionPoints extension is a SEQUENCE of DistributionPoint. A DistributionPoint consists of three fields, each of which is optional: distributionPoint, reasons, and = cRLIssuer. =20 (...) =20 When the HTTP or FTP scheme is specified, the URI MUST point to a single DER encoded CRL as specified in [RFC 2585]. HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-crl in the content-type header field of the response. =20 =20 When the LDAP scheme is specified, the URI MUST specify a distinguishedName and attribute and SHOULD = specify a host name (e.g., ldap://ldap.example.com/cn=3DexmplCA, dc=3Dexample,dc=3Dcom?certificateRevocationList;binary). =20 =20 (...) =20 The URI MUST include an appropriate attribute description for the attribute that holds = the DER [X.690] encoded CRL. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 A way forward would be to define appropriate attribute descriptions for = the attributes that holds either the encoded CRL or the encoded = CRLwithCerts.=20 We could recommend to use currentCRL and currentCRLwithCerts, or = latestCRL=20 or latestCRLwithCerts. =20 For HTTTP or FTP a new media type could be defined such as=20 application/pkix-crlwithcerts to be used in the content-type header = field=20 of the response.=20 =20 For LDAP, the query should end up, for example, with = CRLwithcerts;binary/ =20 We could also say that if the CA has chosen to issue both types of = CRLs,=20 then every distributionPoint holding a CRL (as defined today) should be = placed=20 first in the list. =20 Denis =20 ________________________________ I'm in agreement that Stefan's proposal is a decent one. As Phillip = mentions, it certainly isn't appropriate in every situation, but I can = see situations in which it might be useful. One might argue that a CRL = issuer could issue two CRLs, the most commonly retrieved one without = this extension, but a separate one issued with it-the latter being made = to applications responsible for long term archive, historical signature = validation, or other purposes which might find it useful. =20 =20 I don't see any harm in adding this extension as an optional feature = for PKIs that wish it, since it is truly optional, non-critical, and = does not affect path processing. =20 =20 --Peter =20 +----------------------------------------------------------------+ | Peter Hesse pmhesse@geminisecurity.com | | Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. | | Visit our InfoSecurity blog: securitymusings.com = <http://www.securitymusings.com/> | +----------------------------------------------------------------+ "The generation of random numbers is too important to be left to chance." --Robert R. Coveyou =20 =20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, February 13, 2007 6:53 PM To: Sharon Boeyen; Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I think that Sharon's proposal might have been a good idea in 1995 = before the world got wedged on CRLs as the revocation mechanism. We can = define a package but its too late to get it embedded in the rest of the = application infrastructure. =20 Given where we are Stefan's proposal is the best one. It is compatible = with the existing infrastructure and solves a real issue.=20 =20 It is an option, clearly there are cases where it would be = inappropriate but universal applicability has never been a requirement. = Otherwise we could have saved all the time spent on attribute = certificates. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Stefan I really don't think you can state where this will or will not = be used in the future. Naturally you know where you want to use it, but = software only enables a facility and the customer decides when and how = to use it.=20 =20 Whether this scheme could possibly be useful in some cases is not my = point. My point is that current deployments seem to be working fine = without it and I don't want to see those interfered with just because = some CA they may have cross certified with decided to put certificates = inside their CRLS. Back to Denis' point - there is no need to impose = this in the way you've proposed.=20 =20 Earlier I (and others including Dave Kemp) suggested a "package" that = includes the CRL, and the certificate in question as an 'extra' that a = CA could publish in addition to a regular CRL. That "package could be = published in a separate directory attribute and/or an HTTP accessible = file. It could be pointed to from within the certificate just as the CRL = currently is. That could be done either by extending the CRLDP or adding = a new pointer extension or adding a new method to the AIA extension. = That type of approach gives you what you want but does not in any way = interfere with clients who do not want and do not need to retrieve that = bloated CRL.=20 =20 Also, you haven't addressed the question about what happens when more = than one certificate is needed. If a CRL includes more than one = certificate (e.g. the CRL issuer did one or more key rollovers then CRL = gets bloated a lot bigger than you suggested. I don't want to debate how = often a key gets rolled over either however I have definitely seen = instances in real world deployments where a key has been rolled very = often in a very short period of time (regardless of whether the reason = for rolling it was a good one or not - it has happened). Also, = regardless of the size of the "bloat" I'm saying that in most cases the = clients will already have the certificates in question and this bloat = will cause them extra processing in managing their certificate caches = etc unnecessarily. The client should have a choice as to whether to = download the certificate or not. =20 I don't understand why you're so opposed to the "package" solution.=20 =20 Cheers, Sharon=20 -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs We are only talking about an extra 16K at most. The download time is = the absolute most cases is negligible.=20 For those cases where this solution makes sense, the network = bandwidth issue is not a problem. =20 For the cases where this would be an issue, this solution would not = be used. =20 On the contrary, in some networks and scenarios, this will improve = performance. Especially in high latency networks with PKI based = peer-peer authentication where an extra retrieval cost way more = performance than the expanded CRL size. =20 Also, many clients are configured to pre-fetch CRL:s before they are = used, using idle time on the network at no extra cost. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I still think wasted bandwidth is also an issue. Forcing the download = of 'fat' CRLs on clients when, in many cases, those clients already have = the certificates locally that caused the bloating of the CRL, is an = unnecessary waste. -----Original Message-----=20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson=20 Sent: Wednesday, January 03, 2007 9:58 AM=20 To: Russ Housley=20 Cc: ietf-pkix@imc.org=20 Subject: RE: Certificates in CRLs=20 =20 Russ,=20 In theory, the CA can put different pointers to different CRLs in = each certificate if some certificates are prime targets for frequent = checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would = have to add capability to the CDP extension rather than to the CRL. I = don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in = situations where it in the sum of all, helps increase efficiency and = where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, = but that some implementers simply don't want to be faced with the = requirement to implement this feature. But I don't see that they have = to. A CRL with certs in a non-critical extension should work just as = well in current clients as any current CRL without certs. The extension = can simply be ignored. This is not a necessary feature, but a practical one offering = performance improvements in some environments at no loss of = interoperability. =20 Stefan Santesson=20 Senior Program Manager=20 Windows Security, Standards=20 =20 > -----Original Message-----=20 > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: den 21 december 2006 16:19=20 > To: Stefan Santesson=20 > Cc: ietf-pkix@imc.org=20 > Subject: RE: Certificates in CRLs=20 >=20 > Stefan:=20 >=20 > If the CA chooses to offer both, how can the RP determine which one = it=20 > will get? Does the CA post them in different LDAP attributes?=20 >=20 > Russ=20 >=20 > At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20 >=20 > >As with anything else, the relying party can get what the CA = offers.=20 > >=20 > >I don't think there is any realistic scenario where the CA has a=20 > >reason to offer CRLs both with and without certificates. To offer=20 > >this capability to RP is however not a matter for this protocol. = It=20 > >would be a matter for the CRL referencing model, i.e. CDP and/or=20 > >directory schema.=20 > >=20 > >I don't think that extra complexity however is very useful.=20 > >=20 > >Stefan Santesson=20 > >Senior Program Manager=20 > >Windows Security, Standards=20 > >=20 > >=20 > > > -----Original Message-----=20 > > > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-=20 > > > pkix@mail.imc.org] On Behalf Of Denis Pinkas=20 > > > Sent: den 20 december 2006 17:05=20 > > > To: ietf-pkix@imc.org=20 > > > Subject: Re: Certificates in CRLs=20 > > >=20 > > >=20 > > >=20 > > > It is necessary to provide relying parties with the choice to = get=20 > > > :=20 > > >=20 > > > - CRLs "as usual", or=20 > > > - CRLs that carry that new extension.=20 > > >=20 > > > The current proposal does not allow for it.=20 > > >=20 > > > Until the draft is changed, I am against the addition of this = work=20 > item=20 > > > to the program of the PKIX WG.=20 > > >=20 > > > Denis=20 > > >=20 > > >=20 > = ______________________________________________________________________=20 > _=20 > > > _______=20 > > >=20 > > > >Since last IETF a new draft was posted:=20 > > > = >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20 > 00.txt=20 > > > >=20 > > > >There is a request to add this draft to the PKIX work and I = would=20 > > > encourage to start the discussion about this decision in this=20 > thread.=20 > > > >=20 > > > >Stefan Santesson=20 > > > >Senior Program Manager=20 > > > >Windows Security, Standards=20 > > >=20 > > >=20 > > >=20 ________________________________ ------_=_NextPart_001_01C7505A.A565DAF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:o><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>We could load these semantics into the CRL = Distribution=20 point but a simpler way to support them would be via the existing HTTP = content=20 negotiation mechanism (ACCEPT header). </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>To do this all we need to do is to define the = appropriate=20 descriptions. A single distribution point resource identifier then = serves for=20 both resources.</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] <B>On Behalf Of </B>Denis=20 Pinkas<BR><B>Sent:</B> Wednesday, February 14, 2007 5:57 = AM<BR><B>To:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> Re: Certificates in=20 CRLs<BR></FONT><BR></DIV> <DIV></DIV> <DIV> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">A way=20 forward ?<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">The key=20 issue is not the structure of the =93augmented=94 CRL proposed by = Stefan, <BR>but=20 the ability to retrieve from a given CA either a CRL (i.e. the current = <BR>structure of a CRL) or a CRLwithCerts (i.e. the new structure = proposed by=20 Stefan), <BR>if a CA chooses to issue both.=20 <o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">We need=20 to focus on the cRLDistributionPoints extension to allow retrieving = <BR>either=20 a CRL, or a CRLwithCerts, or both.<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">Let us=20 have a look at some sentences extracted from RFC=20 3280:<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P><SPAN lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New" = size=3D2> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20 face=3D"Courier = New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText=20 style=3D"MARGIN: 0cm 0cm 0pt"> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>The = cRLDistributionPoints=20 extension is a SEQUENCE of<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN><SPAN style=3D"mso-spacerun: = yes"> =20 </SPAN>DistributionPoint.<SPAN style=3D"mso-spacerun: yes"> = </SPAN>A=20 DistributionPoint consists of three=20 fields,<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>each of which is = optional:=20 distributionPoint, reasons, and = cRLIssuer.<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20 face=3D"Courier New">(=85)<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>When the HTTP or FTP = scheme is=20 specified, the<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>URI MUST point to a = single DER=20 encoded CRL as specified in [RFC<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>2585].<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>HTTP server implementations = accessed=20 via the URI SHOULD<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>specify the media type = application/pkix-crl in the = content-type<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>header field of the=20 response.<SPAN style=3D"mso-spacerun: yes"> =20 </SPAN><o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>When the LDAP scheme = is=20 specified, the<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>URI MUST specify a=20 distinguishedName and attribute and SHOULD=20 specify<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>a host name (e.g.,=20 = ldap://ldap.example.com/cn=3DexmplCA,<o:p></o:p></FONT></FONT></SPAN></P>= <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> =20 </SPAN>dc=3Dexample,dc=3Dcom?certificateRevocationList;binary).<SPAN=20 style=3D"mso-spacerun: yes"> = </SPAN><o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20 face=3D"Courier New">(=85)<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>The URI MUST=20 include<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>an appropriate = attribute=20 description for the attribute that holds=20 the<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New"><SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>DER [X.690] encoded=20 CRL.</FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20 face=3D"Courier New"></FONT></FONT></SPAN> </P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20 face=3D"Courier = New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">A way=20 forward would be to define appropriate attribute descriptions for = <BR>the=20 attributes that holds either the encoded CRL or the encoded = CRLwithCerts.=20 <BR>We could recommend to use currentCRL and currentCRLwithCerts, or = latestCRL=20 <BR>or latestCRLwithCerts.<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">For=20 HTTTP or FTP a new media type could be defined such as=20 <BR>application/pkix-crlwithcerts to be used in the content-type = header field=20 <BR>of the response. <o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">For=20 LDAP, the query should end up, for example, with=20 CRLwithcerts;binary/<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT = face=3D"Courier New">We=20 could also say that if the CA has chosen to issue both types of CRLs, = <BR>then=20 every distributionPoint holding a CRL (as defined today) should be = placed=20 <BR>first in the list.<o:p></o:p></FONT></FONT></SPAN></P> <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN = lang=3DEN-US=20 style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20 size=3D2> </FONT></o:p></SPAN></P></DIV> <DIV>Denis</DIV> <DIV> </DIV> <DIV> <HR> </DIV> <DIV class=3DSection1> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=92m=20 in agreement that Stefan=92s proposal is a decent one. As = Phillip=20 mentions, it certainly isn=92t appropriate in every situation, but I = can see=20 situations in which it might be useful. One might argue that a = CRL=20 issuer could issue two CRLs, the most commonly retrieved one without = this=20 extension, but a separate one issued with it=97the latter being made = to=20 applications responsible for long term archive, historical signature=20 validation, or other purposes which might find it useful. =20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=20 don=92t see any harm in adding this extension as an optional feature = for PKIs=20 that wish it, since it is truly optional, non-critical, and does not = affect=20 path processing. <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier = New'">+----------------------------------------------------------------+<= BR>| </SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier = New'">Peter=20 Hesse</SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> &= nbsp; <SPAN=20 style=3D"COLOR: blue"><A=20 = href=3D"mailto:pmhesse@geminisecurity.com">pmhesse@geminisecurity.com</A>= </SPAN> <SPAN=20 style=3D"COLOR: gray">|<BR>| </SPAN><SPAN style=3D"COLOR: = #3333cc">Phone:=20 703-378-5808 x105</SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Gemini Security Solutions, = Inc. </SPAN><SPAN=20 style=3D"COLOR: = gray">|<BR>| </SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20 = href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&n= bsp; <SPAN=20 style=3D"COLOR: = gray">|<BR>+-------------------------------------------------------------= ---+<BR></SPAN><SPAN=20 style=3D"COLOR: teal">"The generation of random numbers is too = important to be=20 left<BR> to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: = medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February = 13, 2007=20 6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 think that Sharon's proposal might have been a good idea in 1995 = before the=20 world got wedged on CRLs as the revocation mechanism. We can define a = package=20 but its too late to get it embedded in the rest of the application=20 infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Given=20 where we are Stefan's proposal is the best one. It is compatible with = the=20 existing infrastructure and solves a real issue. </SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">It is=20 an option, clearly there are cases where it would be inappropriate but = universal applicability has never been a requirement. Otherwise we = could have=20 saved all the time spent on attribute certificates.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt = 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: = medium none"> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter> <HR align=3Dcenter width=3D"100%" SIZE=3D2> </DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 = 9:09=20 AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs</SPAN><o:p></o:p></P> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 I really don't think you can state where this will or will not be = used in=20 the future. Naturally you know where you want to use it, but = software only=20 enables a facility and the customer decides when and how to use it.=20 </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Whether=20 this scheme could possibly be useful in some cases is not my point. = My point=20 is that current deployments seem to be working fine without it and I = don't=20 want to see those interfered with just because some CA they may have = cross=20 certified with decided to put certificates inside their CRLS. Back = to Denis'=20 point - there is no need to impose this in the way you've proposed.=20 </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Earlier=20 I (and others including Dave Kemp) suggested a "package" that = includes the=20 CRL, and the certificate in question as an 'extra' that a CA could = publish=20 in addition to a regular CRL. That "package could be published in a = separate=20 directory attribute and/or an HTTP accessible file. It could be = pointed to=20 from within the certificate just as the CRL currently is. That = could be=20 done either by extending the CRLDP or adding a new pointer = extension or=20 adding a new method to the AIA extension. That type of approach = gives you=20 what you want but does not in any way interfere with clients who do = not want=20 and do not need to retrieve that bloated CRL. </SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Also,=20 you haven't addressed the question about what happens = when more=20 than one certificate is needed. If a CRL includes more than one=20 certificate (e.g. the CRL issuer did one or more key=20 rollovers then CRL gets bloated a lot bigger than you = suggested. I=20 don't want to debate how often a key gets rolled over either however = I have=20 definitely seen instances in real world deployments where a key has = been=20 rolled very often in a very short period of time (regardless of = whether the=20 reason for rolling it was a good one or not - it has happened). = Also,=20 regardless of the size of the "bloat" I'm saying that in most cases = the=20 clients will already have the certificates in question and this = bloat will=20 cause them extra processing in managing their certificate caches etc = unnecessarily. The client should have a choice as to whether to = download the=20 certificate or not.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 don't understand why you're so opposed to the "package"=20 solution. </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Cheers,</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Sharon</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">-----Original=20 Message-----<BR><B>From:</B> Stefan Santesson = [mailto:stefans@microsoft.com]=20 <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> = Sharon=20 Boeyen; Russ Housley<BR><B>Cc:</B> = ietf-pkix@imc.org<BR><B>Subject:</B> RE:=20 Certificates in CRLs<o:p></o:p></SPAN></P></DIV> <BLOCKQUOTE=20 style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: = 0in"><P=20 class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">We=20 are only talking about an extra 16K at most. The download time is = the=20 absolute most cases is negligible. </SPAN></A><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 those cases where this solution makes sense, the network bandwidth = issue=20 is not a problem.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 the cases where this would be an issue, this solution would not be = used.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">On=20 the contrary, in some networks and scenarios, this will improve=20 performance. Especially in high latency networks with PKI based = peer-peer=20 authentication where an extra retrieval cost way more performance = than the=20 expanded CRL size.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">Also,=20 many clients are configured to pre-fetch CRL:s before they are = used, using=20 idle time on the network at no extra cost.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 Santesson</SPAN></B><SPAN lang=3DEN-GB=20 style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Senior=20 Program Manager</SPAN><SPAN lang=3DEN-GB=20 style=3D"COLOR: navy"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Windows=20 Security, Standards</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; = BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium = none"> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; = BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> = Sharon Boeyen=20 [mailto:sharon.boeyen@entrust.com] <BR><B>Sent:</B> den 4 januari = 2007=20 17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think wasted = bandwidth is=20 also an issue. Forcing the download of 'fat' CRLs on clients when, = in many=20 cases, those clients already have the certificates locally that = caused the=20 bloating of the CRL, is an unnecessary waste.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">From: owner-ietf-pkix@mail.imc.org [<A=20 = href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>]=20 On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, = 2007 9:58=20 AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in = CRLs</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20 lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN = lang=3DSV>=20 <o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA can = put=20 different pointers to different CRLs in each certificate if some=20 certificates are prime targets for frequent checking. But I don't = think=20 that is a common scenario.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in = order to=20 allow free selection of CRLs, you would have to add capability to = the CDP=20 extension rather than to the CRL. I don't think such effort is = worth the=20 trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that = including=20 certs in a CRL will only be made in situations where it in the sum = of all,=20 helps increase efficiency and where the extra bandwidth consumed = is not an=20 issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique = of this idea=20 as not really be a bandwidth issue, but that some implementers = simply=20 don't want to be faced with the requirement to implement this = feature. But=20 I don't see that they have to. A CRL with certs in a non-critical=20 extension should work just as well in current clients as any = current CRL=20 without certs. The extension can simply be ignored.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a = necessary feature,=20 but a practical one offering performance improvements in some = environments=20 at no loss of interoperability.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan = Santesson</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">Senior Program=20 Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN = lang=3DSV>=20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> -----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> From: Russ Housley [<A=20 = href=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]</SP= AN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> Sent: den=20 21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> To: Stefan Santesson</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> Subject: RE: Certificates in = CRLs</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 Stefan:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> If the CA chooses to offer both, = how can the=20 RP determine which one it </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> will get? Does the CA post = them in=20 different LDAP attributes?</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> Russ</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> At 08:00 AM 12/21/2006, = Stefan=20 Santesson wrote:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >As with anything else, the = relying party=20 can get what the CA offers.</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >I don't think there = is any=20 realistic scenario where the CA has a </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >reason=20 to offer CRLs both with and without certificates. To offer = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >this=20 capability to RP is however not a matter for this protocol. It=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt">>=20 >would be a matter for the CRL referencing model, i.e. CDP = and/or=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt">>=20 >directory schema.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >I don't think that = extra=20 complexity however is very useful.</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> = >Stefan=20 Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >Senior Program = Manager</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >Windows=20 Security, Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 -----Original Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > From: = owner-ietf-pkix@mail.imc.org=20 [<A href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 pkix@mail.imc.org] On Behalf Of Denis Pinkas</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Sent: den=20 20 december 2006 17:05</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > To: = ietf-pkix@imc.org</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > It is=20 necessary to provide relying parties with the choice to get = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs that carry that new extension.</SPAN><SPAN = lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > The current proposal does = not allow=20 for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Until the=20 draft is changed, I am against the addition of this = work</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > to the program of the = PKIX=20 WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">>=20 = ______________________________________________________________________</S= PAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > _______</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Since last IETF a new = draft was=20 posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" = = target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-= vccrl-</A></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > >There=20 is a request to add this draft to the PKIX work and I = would</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 encourage to start the discussion about this decision in = this</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 thread.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > >Stefan=20 Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Senior Program=20 Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Windows Security,=20 Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV> <HR> </BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C7505A.A565DAF4-- 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 l1EF3VhQ052711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 08:03:31 -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 l1EF3VgJ052710; Wed, 14 Feb 2007 08:03:31 -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 ncsusraimgo01-ext.na.jnj.com (NCSUSRAIMGo01-EXT.na.jnj.com [148.177.2.32]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EF3SV4052703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 08:03:29 -0700 (MST) (envelope-from RGuida@CORUS.JNJ.com) Received: from unknown (HELO NCSUSRAEXIMS3.na.jnj.com) ([10.4.20.172]) by ncsusraimgo01-ext.na.jnj.com with ESMTP; 14 Feb 2007 10:00:21 -0500 X-IronPort-AV: i="4.14,169,1170651600"; d="scan'208,217"; a="18510200:sNHT81507798" Received: by ncsusraexims3.na.jnj.com with Internet Mail Service (5.5.2658.3) id <1JDYFYC8>; Wed, 14 Feb 2007 10:03:27 -0500 Message-ID: <8C9266D8DEC7B3439D3A49E5706844100E842E33@jjcusnbexs4.na.jnj.com> From: "Guida, Richard [JJCUS]" <RGuida@CORUS.JNJ.com> To: Peter Hesse <pmhesse@geminisecurity.com>, "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'Stefan Santesson'" <stefans@microsoft.com>, "'Russ Housley'" <housley@vigilsec.com> Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Date: Wed, 14 Feb 2007 10:03:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75049.4035ADB8" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C75049.4035ADB8 Content-Type: text/plain I likewise agree with Peter, Phillip and Stefan. The CRL bloat is not large, and for those of us with large CRLs to begin with (can debate separately why that circumstance exists...), the bloat is negligible. Since this is entirely optional; and since the owner of a CA therefore has full discretion to include or not include the certs (and can do as Peter described and published two virtually contemporaneous CRLs, one with and one without, if needed to avoid breaking apps), it seems to me that this approach can be used in a fashion which does not break anything, and it can provide real value for archival purposes. Richard A. Guida Director, Information Security Johnson & Johnson Room GS8217 410 George Street New Brunswick, New Jersey 08901 Phone: 732 524 3785 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Peter Hesse Sent: Wednesday, February 14, 2007 12:05 AM To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ Housley' Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs I'm in agreement that Stefan's proposal is a decent one. As Phillip mentions, it certainly isn't appropriate in every situation, but I can see situations in which it might be useful. One might argue that a CRL issuer could issue two CRLs, the most commonly retrieved one without this extension, but a separate one issued with it-the latter being made to applications responsible for long term archive, historical signature validation, or other purposes which might find it useful. I don't see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, non-critical, and does not affect path processing. --Peter +----------------------------------------------------------------+ | Peter Hesse pmhesse@geminisecurity.com <mailto:pmhesse@geminisecurity.com> | | Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. | | Visit our InfoSecurity blog: securitymusings.com <http://www.securitymusings.com/> | +----------------------------------------------------------------+ "The generation of random numbers is too important to be left to chance." --Robert R. Coveyou From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, February 13, 2007 6:53 PM To: Sharon Boeyen; Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs I think that Sharon's proposal might have been a good idea in 1995 before the world got wedged on CRLs as the revocation mechanism. We can define a package but its too late to get it embedded in the rest of the application infrastructure. Given where we are Stefan's proposal is the best one. It is compatible with the existing infrastructure and solves a real issue. It is an option, clearly there are cases where it would be inappropriate but universal applicability has never been a requirement. Otherwise we could have saved all the time spent on attribute certificates. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Stefan I really don't think you can state where this will or will not be used in the future. Naturally you know where you want to use it, but software only enables a facility and the customer decides when and how to use it. Whether this scheme could possibly be useful in some cases is not my point. My point is that current deployments seem to be working fine without it and I don't want to see those interfered with just because some CA they may have cross certified with decided to put certificates inside their CRLS. Back to Denis' point - there is no need to impose this in the way you've proposed. Earlier I (and others including Dave Kemp) suggested a "package" that includes the CRL, and the certificate in question as an 'extra' that a CA could publish in addition to a regular CRL. That "package could be published in a separate directory attribute and/or an HTTP accessible file. It could be pointed to from within the certificate just as the CRL currently is. That could be done either by extending the CRLDP or adding a new pointer extension or adding a new method to the AIA extension. That type of approach gives you what you want but does not in any way interfere with clients who do not want and do not need to retrieve that bloated CRL. Also, you haven't addressed the question about what happens when more than one certificate is needed. If a CRL includes more than one certificate (e.g. the CRL issuer did one or more key rollovers then CRL gets bloated a lot bigger than you suggested. I don't want to debate how often a key gets rolled over either however I have definitely seen instances in real world deployments where a key has been rolled very often in a very short period of time (regardless of whether the reason for rolling it was a good one or not - it has happened). Also, regardless of the size of the "bloat" I'm saying that in most cases the clients will already have the certificates in question and this bloat will cause them extra processing in managing their certificate caches etc unnecessarily. The client should have a choice as to whether to download the certificate or not. I don't understand why you're so opposed to the "package" solution. Cheers, Sharon -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs BM__MailEndComposeWe are only talking about an extra 16K at most. The download time is the absolute most cases is negligible. For those cases where this solution makes sense, the network bandwidth issue is not a problem. For the cases where this would be an issue, this solution would not be used. On the contrary, in some networks and scenarios, this will improve performance. Especially in high latency networks with PKI based peer-peer authentication where an extra retrieval cost way more performance than the expanded CRL size. Also, many clients are configured to pre-fetch CRL:s before they are used, using idle time on the network at no extra cost. Stefan Santesson Senior Program Manager Windows Security, Standards From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs I still think wasted bandwidth is also an issue. Forcing the download of 'fat' CRLs on clients when, in many cases, those clients already have the certificates locally that caused the bloating of the CRL, is an unnecessary waste. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [ mailto:owner-ietf-pkix@mail.imc.org <mailto:owner-ietf-pkix@mail.imc.org> ] On Behalf Of Stefan Santesson Sent: Wednesday, January 03, 2007 9:58 AM To: Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Russ, In theory, the CA can put different pointers to different CRLs in each certificate if some certificates are prime targets for frequent checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would have to add capability to the CDP extension rather than to the CRL. I don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in situations where it in the sum of all, helps increase efficiency and where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, but that some implementers simply don't want to be faced with the requirement to implement this feature. But I don't see that they have to. A CRL with certs in a non-critical extension should work just as well in current clients as any current CRL without certs. The extension can simply be ignored. This is not a necessary feature, but a practical one offering performance improvements in some environments at no loss of interoperability. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Russ Housley [ mailto:housley@vigilsec.com <mailto:housley@vigilsec.com> ] > Sent: den 21 december 2006 16:19 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: Certificates in CRLs > > Stefan: > > If the CA chooses to offer both, how can the RP determine which one it > will get? Does the CA post them in different LDAP attributes? > > Russ > > At 08:00 AM 12/21/2006, Stefan Santesson wrote: > > >As with anything else, the relying party can get what the CA offers. > > > >I don't think there is any realistic scenario where the CA has a > >reason to offer CRLs both with and without certificates. To offer > >this capability to RP is however not a matter for this protocol. It > >would be a matter for the CRL referencing model, i.e. CDP and/or > >directory schema. > > > >I don't think that extra complexity however is very useful. > > > >Stefan Santesson > >Senior Program Manager > >Windows Security, Standards > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org [ mailto:owner-ietf- <mailto:owner-ietf-> > > > pkix@mail.imc.org] On Behalf Of Denis Pinkas > > > Sent: den 20 december 2006 17:05 > > > To: ietf-pkix@imc.org > > > Subject: Re: Certificates in CRLs > > > > > > > > > > > > It is necessary to provide relying parties with the choice to get > > > : > > > > > > - CRLs "as usual", or > > > - CRLs that carry that new extension. > > > > > > The current proposal does not allow for it. > > > > > > Until the draft is changed, I am against the addition of this work > item > > > to the program of the PKIX WG. > > > > > > Denis > > > > > > > ______________________________________________________________________ > _ > > > _______ > > > > > > >Since last IETF a new draft was posted: > > > > http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- <http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-> > 00.txt > > > > > > > >There is a request to add this draft to the PKIX work and I would > > > encourage to start the discussion about this decision in this > thread. > > > > > > > >Stefan Santesson > > > >Senior Program Manager > > > >Windows Security, Standards > > > > > > > > > ------_=_NextPart_001_01C75049.4035ADB8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 = =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D = "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types"><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUS-ASCII"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1587" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 70.85pt 70.85pt 70.85pt = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New = Roman","serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: = "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle18 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal } SPAN.EmailStyle19 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal-reply } .MsoChpDefault { FONT-SIZE: 10pt; mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV><SPAN class=3D790115814-14022007><FONT face=3DArial = color=3D#0000ff size=3D2>I=20 likewise agree with Peter, Phillip and Stefan. The CRL bloat is = not large,=20 and for those of us with large CRLs to begin with (can debate = separately why=20 that circumstance exists...), the bloat is negligible. Since this = is=20 entirely optional; and since the owner of a CA therefore has full = discretion to=20 include or not include the certs (and can do as Peter described and = published=20 two virtually contemporaneous CRLs, one with and one without, if needed = to avoid=20 breaking apps), it seems to me that this approach can be used in a = fashion which=20 does not break anything, and it can provide real value for archival=20 purposes.</FONT></SPAN></DIV> <DIV><FONT face=3DArial color=3D#0000ff = size=3D2></FONT> </DIV><BR> <P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> = <BR><B><FONT=20 face=3DArial size=3D2>Director, Information Security</FONT></B> </P> <P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 = size=3D5>Johnson &=20 Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room = GS8217</FONT>=20 <BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT = face=3DArial=20 size=3D2>New Brunswick, New Jersey 08901</FONT> <BR><FONT = face=3DArial=20 size=3D2>Phone: 732 524 3785</FONT> </P> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> = owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]<B>On Behalf Of </B>Peter=20 Hesse<BR><B>Sent:</B> Wednesday, February 14, 2007 12:05 = AM<BR><B>To:</B>=20 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ=20 Housley'<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs<BR><BR></FONT></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I’m=20 in agreement that Stefan’s proposal is a decent one. As = Phillip=20 mentions, it certainly isn’t appropriate in every situation, = but I can see=20 situations in which it might be useful. One might argue that a = CRL=20 issuer could issue two CRLs, the most commonly retrieved one without = this=20 extension, but a separate one issued with it—the latter being = made to=20 applications responsible for long term archive, historical signature=20 validation, or other purposes which might find it useful. =20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">I=20 don’t see any harm in adding this extension as an optional = feature for PKIs=20 that wish it, since it is truly optional, non-critical, and does not = affect=20 path processing. <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier = New'">+----------------------------------------------------------------+= <BR>| </SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier = New'">Peter=20 Hesse</SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> = <SPAN=20 style=3D"COLOR: blue"><A=20 = href=3D"mailto:pmhesse@geminisecurity.com">pmhesse@geminisecurity.com</A= ></SPAN> <SPAN=20 style=3D"COLOR: gray">|<BR>| </SPAN><SPAN style=3D"COLOR: = #3333cc">Phone:=20 703-378-5808 x105</SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Gemini Security Solutions, = Inc. </SPAN><SPAN=20 style=3D"COLOR: = gray">|<BR>| </SPAN> <SPAN=20 style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20 = href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&= nbsp; <SPAN=20 style=3D"COLOR: = gray">|<BR>+------------------------------------------------------------= ----+<BR></SPAN><SPAN=20 style=3D"COLOR: teal">"The generation of random numbers is too = important to be=20 left<BR> to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: = medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February = 13, 2007=20 6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 think that Sharon's proposal might have been a good idea in 1995 = before the=20 world got wedged on CRLs as the revocation mechanism. We can define a = package=20 but its too late to get it embedded in the rest of the application=20 infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Given=20 where we are Stefan's proposal is the best one. It is compatible with = the=20 existing infrastructure and solves a real issue. </SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">It is=20 an option, clearly there are cases where it would be inappropriate = but=20 universal applicability has never been a requirement. Otherwise we = could have=20 saved all the time spent on attribute certificates.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <BLOCKQUOTE=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in = 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; = BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter> <HR align=3Dcenter width=3D"100%" SIZE=3D2> </DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <B>On=20 Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, = 2007 9:09=20 AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs</SPAN><o:p></o:p></P> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 I really don't think you can state where this will or will not be = used in=20 the future. Naturally you know where you want to use it, but = software only=20 enables a facility and the customer decides when and how to use it. = </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Whether=20 this scheme could possibly be useful in some cases is not my point. = My point=20 is that current deployments seem to be working fine without it and = I don't=20 want to see those interfered with just because some CA they may = have cross=20 certified with decided to put certificates inside their CRLS. Back = to Denis'=20 point - there is no need to impose this in the way you've proposed. = </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Earlier=20 I (and others including Dave Kemp) suggested a "package" that = includes the=20 CRL, and the certificate in question as an 'extra' that a CA could = publish=20 in addition to a regular CRL. That "package could be published in a = separate=20 directory attribute and/or an HTTP accessible file. It could be = pointed to=20 from within the certificate just as the CRL currently is. That = could be=20 done either by extending the CRLDP or adding a new pointer = extension or=20 adding a new method to the AIA extension. That type of approach = gives you=20 what you want but does not in any way interfere with clients who do = not want=20 and do not need to retrieve that bloated CRL. </SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Also,=20 you haven't addressed the question about what happens = when more=20 than one certificate is needed. If a CRL includes more than one=20 certificate (e.g. the CRL issuer did one or more key=20 rollovers then CRL gets bloated a lot bigger than you = suggested. I=20 don't want to debate how often a key gets rolled over either = however I have=20 definitely seen instances in real world deployments where a key has = been=20 rolled very often in a very short period of time (regardless of = whether the=20 reason for rolling it was a good one or not - it has happened). = Also,=20 regardless of the size of the "bloat" I'm saying that in most cases = the=20 clients will already have the certificates in question and this = bloat will=20 cause them extra processing in managing their certificate caches = etc=20 unnecessarily. The client should have a choice as to whether to = download the=20 certificate or not.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">I=20 don't understand why you're so opposed to the "package"=20 solution. </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN = lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = 'Arial','sans-serif'">Cheers,</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-se= rif'">Sharon</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">-----Original=20 Message-----<BR><B>From:</B> Stefan Santesson = [mailto:stefans@microsoft.com]=20 <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> = Sharon=20 Boeyen; Russ Housley<BR><B>Cc:</B> = ietf-pkix@imc.org<BR><B>Subject:</B> RE:=20 Certificates in CRLs<o:p></o:p></SPAN></P></DIV> <BLOCKQUOTE=20 style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: = 0in"><P=20 class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">We=20 are only talking about an extra 16K at most. The download time is = the=20 absolute most cases is negligible. </SPAN></A><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 those cases where this solution makes sense, the network = bandwidth issue=20 is not a problem.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 the cases where this would be an issue, this solution would not = be=20 used.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">On=20 the contrary, in some networks and scenarios, this will improve=20 performance. Especially in high latency networks with PKI based = peer-peer=20 authentication where an extra retrieval cost way more performance = than the=20 expanded CRL size.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">Also,=20 many clients are configured to pre-fetch CRL:s before they are = used, using=20 idle time on the network at no extra cost.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 Santesson</SPAN></B><SPAN lang=3DEN-GB=20 style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Senior=20 Program Manager</SPAN><SPAN lang=3DEN-GB=20 style=3D"COLOR: navy"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Windows=20 Security, Standards</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; = BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium = none"> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; = BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; = BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium = none"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> = Sharon Boeyen=20 [mailto:sharon.boeyen@entrust.com] <BR><B>Sent:</B> den 4 januari = 2007=20 17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think wasted = bandwidth is=20 also an issue. Forcing the download of 'fat' CRLs on clients = when, in many=20 cases, those clients already have the certificates locally that = caused the=20 bloating of the CRL, is an unnecessary waste.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">From: owner-ietf-pkix@mail.imc.org [<A=20 = href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail= .imc.org</A>]=20 On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, = 2007 9:58=20 AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in = CRLs</SPAN><SPAN=20 lang=3DSV> <o:p></o:p></SPAN></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20 lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN = lang=3DSV>=20 <o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA = can put=20 different pointers to different CRLs in each certificate if some=20 certificates are prime targets for frequent checking. But I don't = think=20 that is a common scenario.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in = order to=20 allow free selection of CRLs, you would have to add capability to = the CDP=20 extension rather than to the CRL. I don't think such effort is = worth the=20 trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that = including=20 certs in a CRL will only be made in situations where it in the = sum of all,=20 helps increase efficiency and where the extra bandwidth consumed = is not an=20 issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique = of this idea=20 as not really be a bandwidth issue, but that some implementers = simply=20 don't want to be faced with the requirement to implement this = feature. But=20 I don't see that they have to. A CRL with certs in a non-critical = extension should work just as well in current clients as any = current CRL=20 without certs. The extension can simply be ignored.</SPAN><SPAN=20 lang=3DSV><o:p></o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a = necessary feature,=20 but a practical one offering performance improvements in some = environments=20 at no loss of interoperability.</SPAN><SPAN = lang=3DSV><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan = Santesson</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">Senior Program=20 Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN = lang=3DSV>=20 <o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DSV><o:p> </o:p></SPAN></P> <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> -----Original=20 Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> From: Russ Housley [<A=20 = href=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]</S= PAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> Sent: den=20 21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> To: Stefan Santesson</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> Cc:=20 ietf-pkix@imc.org</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> Subject: RE: Certificates in = CRLs</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 Stefan:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> If the CA chooses to offer both, = how can the=20 RP determine which one it </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> will get? Does the CA post = them in=20 different LDAP attributes?</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> Russ</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> At 08:00 AM 12/21/2006, = Stefan=20 Santesson wrote:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >As with anything else, the = relying party=20 can get what the CA offers.</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >I don't think there = is any=20 realistic scenario where the CA has a </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >reason=20 to offer CRLs both with and without certificates. To offer = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >this=20 capability to RP is however not a matter for this protocol. It=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt">>=20 >would be a matter for the CRL referencing model, i.e. CDP = and/or=20 </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV = style=3D"FONT-SIZE: 10pt">>=20 >directory schema.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> >I don't think that = extra=20 complexity however is very useful.</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> = >Stefan=20 Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> >Senior Program = Manager</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >Windows=20 Security, Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 -----Original Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN= lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > From: = owner-ietf-pkix@mail.imc.org=20 [<A href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 pkix@mail.imc.org] On Behalf Of Denis Pinkas</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Sent: den=20 20 december 2006 17:05</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN = lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > To: = ietf-pkix@imc.org</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> = <BR></SPAN><SPAN=20 lang=3DSV style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > It is=20 necessary to provide relying parties with the choice to get = </SPAN><SPAN=20 lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs that carry that new = extension.</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > The current proposal = does not allow=20 for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > Until the=20 draft is changed, I am against the addition of this = work</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > to the program of the = PKIX=20 WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = >=20 Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">>=20 = ______________________________________________________________________</= SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > _______</SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Since last IETF a = new draft was=20 posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-"= =20 = target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix= -vccrl-</A></SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > >There=20 is a request to add this draft to the PKIX work and I = would</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">> > >=20 encourage to start the discussion about this decision in = this</SPAN><SPAN=20 lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: = 10pt">>=20 thread.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN><SPAN = lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> > = > >Stefan=20 Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Senior Program=20 Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > > >Windows Security,=20 Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">> >=20 ></SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=3DSV>=20 = <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV></BLOCKQUOTE= ></BODY></HTML> ------_=_NextPart_001_01C75049.4035ADB8-- 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 l1ECBLKb036668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 05:11: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 l1ECBLw9036666; Wed, 14 Feb 2007 05:11: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1ECBJXl036660 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 05:11:20 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.253]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1HHIyi-00045g-5M; Wed, 14 Feb 2007 07:11:16 -0500 Mime-Version: 1.0 Message-Id: <p06240506c1f8abc99a4c@[10.84.131.253]> In-Reply-To: <002501c74ffb$9a7d0a60$670710ac@5423D2> References: <002501c74ffb$9a7d0a60$670710ac@5423D2> Date: Wed, 14 Feb 2007 07:11:13 -0500 To: "Jonghyun Baek" <jhbaek@kisa.or.kr> From: Stephen Kent <kent@bbn.com> Subject: Re: Questions on the use case of KeyUsage type in Key Usage extension Cc: <ietf-pkix@imc.org> Content-Type: multipart/alternative; boundary="============_-1040667416==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --============_-1040667416==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:47 PM +0900 2/14/07, Jonghyun Baek wrote: >Dear PKIX WG, > >The key usage extension(section 4.2.1.3 in RFC3280) have nine >KeyUsage types such as digitalSignature, non repudiation, >keyEncipherment, etc. >I can understood each of the KeyUsage types meaning but i would like >to know a real example or a use case of the encipherOnly type and >the decipherOnly type. i mean which kind of the service or >application need the encipherOnly or decipherOnly type certificate >and for what ? >I will be so appriciate if you give me a hand. > >Thanks! > >Jonghyun Baek The typical example that has been provided (by others) is a multicast application where one wants to enforce encrypt/decrypt only key use for subscribers, e.g., most subscribers are authorized to listen (decrypt) and only one or a few are authorized to send (encrypt). Steve --============_-1040667416==_ma============ Content-Type: text/html; charset="us-ascii" <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: Questions on the use case of KeyUsage type in Key Usa</title></head><body> <div>At 2:47 PM +0900 2/14/07, Jonghyun Baek wrote:</div> <blockquote type="cite" cite><font face="Arial" size="-1">Dear PKIX WG,</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">The key usage extension(section 4.2.1.3 in RFC3280) have nine KeyUsage types such as digitalSignature, non repudiation, keyEncipherment, etc.</font></blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">I can understood each of the KeyUsage types meaning but i would like to know a real example or a use case of the encipherOnly type and the decipherOnly type. i mean which kind of the service or application need the encipherOnly or decipherOnly type certificate and for what ?</font></blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">I will be so appriciate if you give me a hand.</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">Thanks!</font></blockquote> <blockquote type="cite" cite> </blockquote> <blockquote type="cite" cite><font face="Arial" size="-1">Jonghyun Baek</font><font face="Arial"> </font></blockquote> <div><br></div> <div>The typical example that has been provided (by others) is a multicast application where one wants to enforce encrypt/decrypt only key use for subscribers, e.g., most subscribers are authorized to listen (decrypt) and only one or a few are authorized to send (encrypt).</div> <div><br></div> <div>Steve</div> </body> </html> --============_-1040667416==_ma============-- 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 l1EAvWOq030743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Feb 2007 03: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 l1EAvWjD030742; Wed, 14 Feb 2007 03:57: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1EAvSpe030736 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 03:57:30 -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 MAA39538 for <ietf-pkix@imc.org>; Wed, 14 Feb 2007 12:01:29 +0100 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007021411572546:37938 ; Wed, 14 Feb 2007 11:57:25 +0100 Date: Wed, 14 Feb 2007 11:57:20 +0100 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: Certificates in CRLs 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 14/02/2007 11:57:25, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 14/02/2007 11:57:27, Serialize complete at 14/02/2007 11:57:27 Message-ID: <OFC1A01D5F.32F0871D-ONC1257282.003C306A@frcl.bull.fr> Content-Type: multipart/alternative; boundary="=====003_Dragon615448871137_=====" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --=====003_Dragon615448871137_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" QSB3YXkgZm9yd2FyZCA/DQogDQpUaGUga2V5IGlzc3VlIGlzIG5vdCB0aGUgc3RydWN0dXJlIG9m IHRoZSCTYXVnbWVudGVklCBDUkwgcHJvcG9zZWQgYnkgU3RlZmFuLCANCmJ1dCB0aGUgYWJpbGl0 eSB0byByZXRyaWV2ZSBmcm9tIGEgZ2l2ZW4gQ0EgZWl0aGVyIGEgQ1JMIChpLmUuIHRoZSBjdXJy ZW50IA0Kc3RydWN0dXJlIG9mIGEgQ1JMKSBvciBhIENSTHdpdGhDZXJ0cyAoaS5lLiB0aGUgbmV3 IHN0cnVjdHVyZSBwcm9wb3NlZCBieSBTdGVmYW4pLCANCmlmIGEgQ0EgY2hvb3NlcyB0byBpc3N1 ZSBib3RoLiANCiANCldlIG5lZWQgdG8gZm9jdXMgb24gdGhlIGNSTERpc3RyaWJ1dGlvblBvaW50 cyBleHRlbnNpb24gdG8gYWxsb3cgcmV0cmlldmluZyANCmVpdGhlciBhIENSTCwgb3IgYSBDUkx3 aXRoQ2VydHMsIG9yIGJvdGguDQogDQpMZXQgdXMgaGF2ZSBhIGxvb2sgYXQgc29tZSBzZW50ZW5j ZXMgZXh0cmFjdGVkIGZyb20gUkZDIDMyODA6DQogDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIA0KICAg VGhlIGNSTERpc3RyaWJ1dGlvblBvaW50cyBleHRlbnNpb24gaXMgYSBTRVFVRU5DRSBvZg0KICAg RGlzdHJpYnV0aW9uUG9pbnQuICBBIERpc3RyaWJ1dGlvblBvaW50IGNvbnNpc3RzIG9mIHRocmVl IGZpZWxkcywNCiAgIGVhY2ggb2Ygd2hpY2ggaXMgb3B0aW9uYWw6IGRpc3RyaWJ1dGlvblBvaW50 LCByZWFzb25zLCBhbmQgY1JMSXNzdWVyLg0KIA0KKIUpDQogDQogICBXaGVuIHRoZSBIVFRQIG9y IEZUUCBzY2hlbWUgaXMgc3BlY2lmaWVkLCB0aGUNCiAgIFVSSSBNVVNUIHBvaW50IHRvIGEgc2lu Z2xlIERFUiBlbmNvZGVkIENSTCBhcyBzcGVjaWZpZWQgaW4gW1JGQw0KICAgMjU4NV0uICBIVFRQ IHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgYWNjZXNzZWQgdmlhIHRoZSBVUkkgU0hPVUxEDQogICBz cGVjaWZ5IHRoZSBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uL3BraXgtY3JsIGluIHRoZSBjb250ZW50 LXR5cGUNCiAgIGhlYWRlciBmaWVsZCBvZiB0aGUgcmVzcG9uc2UuICANCiANCiAgIFdoZW4gdGhl IExEQVAgc2NoZW1lIGlzIHNwZWNpZmllZCwgdGhlDQogICBVUkkgTVVTVCBzcGVjaWZ5IGEgZGlz dGluZ3Vpc2hlZE5hbWUgYW5kIGF0dHJpYnV0ZSBhbmQgU0hPVUxEIHNwZWNpZnkNCiAgIGEgaG9z dCBuYW1lIChlLmcuLCBsZGFwOi8vbGRhcC5leGFtcGxlLmNvbS9jbj1leG1wbENBLA0KICAgZGM9 ZXhhbXBsZSxkYz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkpLiAgDQogDQoo hSkNCiANCiAgIFRoZSBVUkkgTVVTVCBpbmNsdWRlDQogICBhbiBhcHByb3ByaWF0ZSBhdHRyaWJ1 dGUgZGVzY3JpcHRpb24gZm9yIHRoZSBhdHRyaWJ1dGUgdGhhdCBob2xkcyB0aGUNCiAgIERFUiBb WC42OTBdIGVuY29kZWQgQ1JMLg0KIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiANCkEgd2F5IGZvcndh cmQgd291bGQgYmUgdG8gZGVmaW5lIGFwcHJvcHJpYXRlIGF0dHJpYnV0ZSBkZXNjcmlwdGlvbnMg Zm9yIA0KdGhlIGF0dHJpYnV0ZXMgdGhhdCBob2xkcyBlaXRoZXIgdGhlIGVuY29kZWQgQ1JMIG9y IHRoZSBlbmNvZGVkIENSTHdpdGhDZXJ0cy4gDQpXZSBjb3VsZCByZWNvbW1lbmQgdG8gdXNlIGN1 cnJlbnRDUkwgYW5kIGN1cnJlbnRDUkx3aXRoQ2VydHMsIG9yIGxhdGVzdENSTCANCm9yIGxhdGVz dENSTHdpdGhDZXJ0cy4NCiANCkZvciBIVFRUUCBvciBGVFAgYSBuZXcgbWVkaWEgdHlwZSBjb3Vs ZCBiZSBkZWZpbmVkIHN1Y2ggYXMgDQphcHBsaWNhdGlvbi9wa2l4LWNybHdpdGhjZXJ0cyB0byBi ZSB1c2VkIGluIHRoZSBjb250ZW50LXR5cGUgaGVhZGVyIGZpZWxkIA0Kb2YgdGhlIHJlc3BvbnNl LiANCiANCkZvciBMREFQLCB0aGUgcXVlcnkgc2hvdWxkIGVuZCB1cCwgZm9yIGV4YW1wbGUsIHdp dGggQ1JMd2l0aGNlcnRzO2JpbmFyeS8NCiANCldlIGNvdWxkIGFsc28gc2F5IHRoYXQgaWYgdGhl IENBIGhhcyBjaG9zZW4gdG8gaXNzdWUgYm90aCB0eXBlcyBvZiBDUkxzLCANCnRoZW4gZXZlcnkg ZGlzdHJpYnV0aW9uUG9pbnQgaG9sZGluZyBhIENSTCAoYXMgZGVmaW5lZCB0b2RheSkgc2hvdWxk IGJlIHBsYWNlZCANCmZpcnN0IGluIHRoZSBsaXN0Lg0KIA0KRGVuaXMNCg0KDQoNCg0KSZJtIGlu IGFncmVlbWVudCB0aGF0IFN0ZWZhbpJzIHByb3Bvc2FsIGlzIGEgZGVjZW50IG9uZS4gIEFzIFBo aWxsaXAgbWVudGlvbnMsIGl0IGNlcnRhaW5seSBpc26SdCBhcHByb3ByaWF0ZSBpbiBldmVyeSBz aXR1YXRpb24sIGJ1dCBJIGNhbiBzZWUgc2l0dWF0aW9ucyBpbiB3aGljaCBpdCBtaWdodCBiZSB1 c2VmdWwuICBPbmUgbWlnaHQgYXJndWUgdGhhdCBhIENSTCBpc3N1ZXIgY291bGQgaXNzdWUgdHdv IENSTHMsIHRoZSBtb3N0IGNvbW1vbmx5IHJldHJpZXZlZCBvbmUgd2l0aG91dCB0aGlzIGV4dGVu c2lvbiwgYnV0IGEgc2VwYXJhdGUgb25lIGlzc3VlZCB3aXRoIGl0l3RoZSBsYXR0ZXIgYmVpbmcg bWFkZSB0byBhcHBsaWNhdGlvbnMgcmVzcG9uc2libGUgZm9yIGxvbmcgdGVybSBhcmNoaXZlLCBo aXN0b3JpY2FsIHNpZ25hdHVyZSB2YWxpZGF0aW9uLCBvciBvdGhlciBwdXJwb3NlcyB3aGljaCBt aWdodCBmaW5kIGl0IHVzZWZ1bC4gIA0KIA0KSSBkb26SdCBzZWUgYW55IGhhcm0gaW4gYWRkaW5n IHRoaXMgZXh0ZW5zaW9uIGFzIGFuIG9wdGlvbmFsIGZlYXR1cmUgZm9yIFBLSXMgdGhhdCB3aXNo IGl0LCBzaW5jZSBpdCBpcyB0cnVseSBvcHRpb25hbCwgbm9uLWNyaXRpY2FsLCBhbmQgZG9lcyBu b3QgYWZmZWN0IHBhdGggcHJvY2Vzc2luZy4gIA0KIA0KLS1QZXRlcg0KIA0KKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8 IFBldGVyIEhlc3NlICAgICAgICAgICAgICAgICAgICAgcG1oZXNzZUBnZW1pbmlzZWN1cml0eS5j b20gICAgIHwNCnwgUGhvbmU6IDcwMy0zNzgtNTgwOCB4MTA1ICAgICAgR2VtaW5pIFNlY3VyaXR5 IFNvbHV0aW9ucywgSW5jLiAgfA0KfCAgICAgICBWaXNpdCBvdXIgSW5mb1NlY3VyaXR5IGJsb2c6 IHNlY3VyaXR5bXVzaW5ncy5jb20gICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiJUaGUgZ2VuZXJhdGlv biBvZiByYW5kb20gbnVtYmVycyBpcyB0b28gaW1wb3J0YW50IHRvIGJlIGxlZnQNCiB0byBjaGFu Y2UuIiAtLVJvYmVydCBSLiBDb3ZleW91DQogDQogDQpGcm9tOiBvd25lci1pZXRmLXBraXhAbWFp bC5pbWMub3JnIFttYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxm IE9mIEhhbGxhbS1CYWtlciwgUGhpbGxpcA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTMsIDIw MDcgNjo1MyBQTQ0KVG86IFNoYXJvbiBCb2V5ZW47IFN0ZWZhbiBTYW50ZXNzb247IFJ1c3MgSG91 c2xleQ0KQ2M6IGlldGYtcGtpeEBpbWMub3JnDQpTdWJqZWN0OiBSRTogQ2VydGlmaWNhdGVzIGlu IENSTHMNCiANCkkgdGhpbmsgdGhhdCBTaGFyb24ncyBwcm9wb3NhbCBtaWdodCBoYXZlIGJlZW4g YSBnb29kIGlkZWEgaW4gMTk5NSBiZWZvcmUgdGhlIHdvcmxkIGdvdCB3ZWRnZWQgb24gQ1JMcyBh cyB0aGUgcmV2b2NhdGlvbiBtZWNoYW5pc20uIFdlIGNhbiBkZWZpbmUgYSBwYWNrYWdlIGJ1dCBp dHMgdG9vIGxhdGUgdG8gZ2V0IGl0IGVtYmVkZGVkIGluIHRoZSByZXN0IG9mIHRoZSBhcHBsaWNh dGlvbiBpbmZyYXN0cnVjdHVyZS4NCiANCkdpdmVuIHdoZXJlIHdlIGFyZSBTdGVmYW4ncyBwcm9w b3NhbCBpcyB0aGUgYmVzdCBvbmUuIEl0IGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgZXhpc3Rpbmcg aW5mcmFzdHJ1Y3R1cmUgYW5kIHNvbHZlcyBhIHJlYWwgaXNzdWUuIA0KIA0KSXQgaXMgYW4gb3B0 aW9uLCBjbGVhcmx5IHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBpdCB3b3VsZCBiZSBpbmFwcHJvcHJp YXRlIGJ1dCB1bml2ZXJzYWwgYXBwbGljYWJpbGl0eSBoYXMgbmV2ZXIgYmVlbiBhIHJlcXVpcmVt ZW50LiBPdGhlcndpc2Ugd2UgY291bGQgaGF2ZSBzYXZlZCBhbGwgdGhlIHRpbWUgc3BlbnQgb24g YXR0cmlidXRlIGNlcnRpZmljYXRlcy4NCiANCg0KDQoNCkZyb206IG93bmVyLWlldGYtcGtpeEBt YWlsLmltYy5vcmcgW21haWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXSBPbiBCZWhh bGYgT2YgU2hhcm9uIEJvZXllbg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDA1LCAyMDA3IDk6MDkg QU0NClRvOiAnU3RlZmFuIFNhbnRlc3Nvbic7IFNoYXJvbiBCb2V5ZW47IFJ1c3MgSG91c2xleQ0K Q2M6IGlldGYtcGtpeEBpbWMub3JnDQpTdWJqZWN0OiBSRTogQ2VydGlmaWNhdGVzIGluIENSTHMN ClN0ZWZhbiBJIHJlYWxseSBkb24ndCB0aGluayB5b3UgY2FuIHN0YXRlIHdoZXJlIHRoaXMgd2ls bCBvciB3aWxsIG5vdCBiZSB1c2VkIGluIHRoZSBmdXR1cmUuIE5hdHVyYWxseSB5b3Uga25vdyB3 aGVyZSB5b3Ugd2FudCB0byB1c2UgaXQsIGJ1dCBzb2Z0d2FyZSBvbmx5IGVuYWJsZXMgYSBmYWNp bGl0eSBhbmQgdGhlIGN1c3RvbWVyIGRlY2lkZXMgd2hlbiBhbmQgaG93IHRvIHVzZSBpdC4gDQog DQpXaGV0aGVyIHRoaXMgc2NoZW1lIGNvdWxkIHBvc3NpYmx5IGJlIHVzZWZ1bCBpbiBzb21lIGNh c2VzIGlzIG5vdCBteSBwb2ludC4gTXkgcG9pbnQgaXMgdGhhdCBjdXJyZW50IGRlcGxveW1lbnRz IHNlZW0gdG8gYmUgd29ya2luZyBmaW5lIHdpdGhvdXQgaXQgYW5kIEkgZG9uJ3Qgd2FudCB0byBz ZWUgdGhvc2UgaW50ZXJmZXJlZCB3aXRoIGp1c3QgYmVjYXVzZSBzb21lIENBIHRoZXkgbWF5IGhh dmUgY3Jvc3MgY2VydGlmaWVkIHdpdGggZGVjaWRlZCB0byBwdXQgY2VydGlmaWNhdGVzIGluc2lk ZSB0aGVpciBDUkxTLiBCYWNrIHRvIERlbmlzJyBwb2ludCAtIHRoZXJlIGlzIG5vIG5lZWQgdG8g aW1wb3NlIHRoaXMgaW4gdGhlIHdheSB5b3UndmUgcHJvcG9zZWQuIA0KIA0KRWFybGllciBJIChh bmQgb3RoZXJzIGluY2x1ZGluZyBEYXZlIEtlbXApIHN1Z2dlc3RlZCBhICJwYWNrYWdlIiB0aGF0 IGluY2x1ZGVzIHRoZSBDUkwsIGFuZCB0aGUgY2VydGlmaWNhdGUgaW4gcXVlc3Rpb24gYXMgYW4g J2V4dHJhJyB0aGF0IGEgQ0EgY291bGQgcHVibGlzaCBpbiBhZGRpdGlvbiB0byBhIHJlZ3VsYXIg Q1JMLiBUaGF0ICJwYWNrYWdlIGNvdWxkIGJlIHB1Ymxpc2hlZCBpbiBhIHNlcGFyYXRlIGRpcmVj dG9yeSBhdHRyaWJ1dGUgYW5kL29yIGFuIEhUVFAgYWNjZXNzaWJsZSBmaWxlLiBJdCBjb3VsZCBi ZSBwb2ludGVkIHRvIGZyb20gd2l0aGluIHRoZSBjZXJ0aWZpY2F0ZSBqdXN0IGFzIHRoZSBDUkwg Y3VycmVudGx5IGlzLiBUaGF0IGNvdWxkIGJlIGRvbmUgZWl0aGVyIGJ5IGV4dGVuZGluZyB0aGUg Q1JMRFAgb3IgYWRkaW5nIGEgbmV3IHBvaW50ZXIgZXh0ZW5zaW9uIG9yIGFkZGluZyBhIG5ldyBt ZXRob2QgdG8gdGhlIEFJQSBleHRlbnNpb24uIFRoYXQgdHlwZSBvZiBhcHByb2FjaCBnaXZlcyB5 b3Ugd2hhdCB5b3Ugd2FudCBidXQgZG9lcyBub3QgaW4gYW55IHdheSBpbnRlcmZlcmUgd2l0aCBj bGllbnRzIHdobyBkbyBub3Qgd2FudCBhbmQgZG8gbm90IG5lZWQgdG8gcmV0cmlldmUgdGhhdCBi bG9hdGVkIENSTC4gDQogDQpBbHNvLCB5b3UgaGF2ZW4ndCBhZGRyZXNzZWQgdGhlIHF1ZXN0aW9u IGFib3V0IHdoYXQgaGFwcGVucyB3aGVuIG1vcmUgdGhhbiBvbmUgY2VydGlmaWNhdGUgaXMgbmVl ZGVkLiBJZiBhIENSTCBpbmNsdWRlcyBtb3JlIHRoYW4gb25lIGNlcnRpZmljYXRlIChlLmcuIHRo ZSBDUkwgaXNzdWVyIGRpZCBvbmUgb3IgbW9yZSBrZXkgcm9sbG92ZXJzIHRoZW4gQ1JMIGdldHMg YmxvYXRlZCBhIGxvdCBiaWdnZXIgdGhhbiB5b3Ugc3VnZ2VzdGVkLiBJIGRvbid0IHdhbnQgdG8g ZGViYXRlIGhvdyBvZnRlbiBhIGtleSBnZXRzIHJvbGxlZCBvdmVyIGVpdGhlciBob3dldmVyIEkg aGF2ZSBkZWZpbml0ZWx5IHNlZW4gaW5zdGFuY2VzIGluIHJlYWwgd29ybGQgZGVwbG95bWVudHMg d2hlcmUgYSBrZXkgaGFzIGJlZW4gcm9sbGVkIHZlcnkgb2Z0ZW4gaW4gYSB2ZXJ5IHNob3J0IHBl cmlvZCBvZiB0aW1lIChyZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIHJlYXNvbiBmb3Igcm9sbGlu ZyBpdCB3YXMgYSBnb29kIG9uZSBvciBub3QgLSBpdCBoYXMgaGFwcGVuZWQpLiBBbHNvLCByZWdh cmRsZXNzIG9mIHRoZSBzaXplIG9mIHRoZSAiYmxvYXQiIEknbSBzYXlpbmcgdGhhdCBpbiBtb3N0 IGNhc2VzIHRoZSBjbGllbnRzIHdpbGwgYWxyZWFkeSBoYXZlIHRoZSBjZXJ0aWZpY2F0ZXMgaW4g cXVlc3Rpb24gYW5kIHRoaXMgYmxvYXQgd2lsbCBjYXVzZSB0aGVtIGV4dHJhIHByb2Nlc3Npbmcg aW4gbWFuYWdpbmcgdGhlaXIgY2VydGlmaWNhdGUgY2FjaGVzIGV0YyB1bm5lY2Vzc2FyaWx5LiBU aGUgY2xpZW50IHNob3VsZCBoYXZlIGEgY2hvaWNlIGFzIHRvIHdoZXRoZXIgdG8gZG93bmxvYWQg dGhlIGNlcnRpZmljYXRlIG9yIG5vdC4NCiANCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91J3Jl IHNvIG9wcG9zZWQgdG8gdGhlICJwYWNrYWdlIiBzb2x1dGlvbi4gDQogDQpDaGVlcnMsDQpTaGFy b24gDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlZmFuIFNhbnRlc3NvbiBb bWFpbHRvOnN0ZWZhbnNAbWljcm9zb2Z0LmNvbV0gDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMDUs IDIwMDcgODowMSBBTQ0KVG86IFNoYXJvbiBCb2V5ZW47IFJ1c3MgSG91c2xleQ0KQ2M6IGlldGYt cGtpeEBpbWMub3JnDQpTdWJqZWN0OiBSRTogQ2VydGlmaWNhdGVzIGluIENSTHMNCldlIGFyZSBv bmx5IHRhbGtpbmcgYWJvdXQgYW4gZXh0cmEgMTZLIGF0IG1vc3QuIFRoZSBkb3dubG9hZCB0aW1l IGlzIHRoZSBhYnNvbHV0ZSBtb3N0IGNhc2VzIGlzIG5lZ2xpZ2libGUuIA0KRm9yIHRob3NlIGNh c2VzIHdoZXJlIHRoaXMgc29sdXRpb24gbWFrZXMgc2Vuc2UsIHRoZSBuZXR3b3JrIGJhbmR3aWR0 aCBpc3N1ZSBpcyBub3QgYSBwcm9ibGVtLg0KIA0KRm9yIHRoZSBjYXNlcyB3aGVyZSB0aGlzIHdv dWxkIGJlIGFuIGlzc3VlLCB0aGlzIHNvbHV0aW9uIHdvdWxkIG5vdCBiZSB1c2VkLg0KIA0KT24g dGhlIGNvbnRyYXJ5LCBpbiBzb21lIG5ldHdvcmtzIGFuZCBzY2VuYXJpb3MsIHRoaXMgd2lsbCBp bXByb3ZlIHBlcmZvcm1hbmNlLiBFc3BlY2lhbGx5IGluIGhpZ2ggbGF0ZW5jeSBuZXR3b3JrcyB3 aXRoIFBLSSBiYXNlZCBwZWVyLXBlZXIgYXV0aGVudGljYXRpb24gd2hlcmUgYW4gZXh0cmEgcmV0 cmlldmFsIGNvc3Qgd2F5IG1vcmUgcGVyZm9ybWFuY2UgdGhhbiB0aGUgZXhwYW5kZWQgQ1JMIHNp emUuDQogDQpBbHNvLCBtYW55IGNsaWVudHMgYXJlIGNvbmZpZ3VyZWQgdG8gcHJlLWZldGNoIENS TDpzIGJlZm9yZSB0aGV5IGFyZSB1c2VkLCB1c2luZyBpZGxlIHRpbWUgb24gdGhlIG5ldHdvcmsg YXQgbm8gZXh0cmEgY29zdC4NCiANCiANClN0ZWZhbiBTYW50ZXNzb24NClNlbmlvciBQcm9ncmFt IE1hbmFnZXINCldpbmRvd3MgU2VjdXJpdHksIFN0YW5kYXJkcw0KIA0KRnJvbTogU2hhcm9uIEJv ZXllbiBbbWFpbHRvOnNoYXJvbi5ib2V5ZW5AZW50cnVzdC5jb21dIA0KU2VudDogZGVuIDQgamFu dWFyaSAyMDA3IDE3OjM2DQpUbzogU3RlZmFuIFNhbnRlc3NvbjsgUnVzcyBIb3VzbGV5DQpDYzog aWV0Zi1wa2l4QGltYy5vcmcNClN1YmplY3Q6IFJFOiBDZXJ0aWZpY2F0ZXMgaW4gQ1JMcw0KIA0K SSBzdGlsbCB0aGluayB3YXN0ZWQgYmFuZHdpZHRoIGlzIGFsc28gYW4gaXNzdWUuIEZvcmNpbmcg dGhlIGRvd25sb2FkIG9mICdmYXQnIENSTHMgb24gY2xpZW50cyB3aGVuLCBpbiBtYW55IGNhc2Vz LCB0aG9zZSBjbGllbnRzIGFscmVhZHkgaGF2ZSB0aGUgY2VydGlmaWNhdGVzIGxvY2FsbHkgdGhh dCBjYXVzZWQgdGhlIGJsb2F0aW5nIG9mIHRoZSBDUkwsIGlzIGFuIHVubmVjZXNzYXJ5IHdhc3Rl Lg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBvd25lci1pZXRmLXBraXhAbWFp bC5pbWMub3JnIFttYWlsdG86b3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxm IE9mIFN0ZWZhbiBTYW50ZXNzb24gDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMDMsIDIwMDcg OTo1OCBBTSANClRvOiBSdXNzIEhvdXNsZXkgDQpDYzogaWV0Zi1wa2l4QGltYy5vcmcgDQpTdWJq ZWN0OiBSRTogQ2VydGlmaWNhdGVzIGluIENSTHMgDQogDQpSdXNzLCANCkluIHRoZW9yeSwgdGhl IENBIGNhbiBwdXQgZGlmZmVyZW50IHBvaW50ZXJzIHRvIGRpZmZlcmVudCBDUkxzIGluIGVhY2gg Y2VydGlmaWNhdGUgaWYgc29tZSBjZXJ0aWZpY2F0ZXMgYXJlIHByaW1lIHRhcmdldHMgZm9yIGZy ZXF1ZW50IGNoZWNraW5nLiBCdXQgSSBkb24ndCB0aGluayB0aGF0IGlzIGEgY29tbW9uIHNjZW5h cmlvLg0KTXkgcG9pbnQgaXMgdGhhdCBpbiBvcmRlciB0byBhbGxvdyBmcmVlIHNlbGVjdGlvbiBv ZiBDUkxzLCB5b3Ugd291bGQgaGF2ZSB0byBhZGQgY2FwYWJpbGl0eSB0byB0aGUgQ0RQIGV4dGVu c2lvbiByYXRoZXIgdGhhbiB0byB0aGUgQ1JMLiBJIGRvbid0IHRoaW5rIHN1Y2ggZWZmb3J0IGlz IHdvcnRoIHRoZSB0cm91YmxlLg0KSSdtIGNvbnZpbmNlZCB0aGF0IGluY2x1ZGluZyBjZXJ0cyBp biBhIENSTCB3aWxsIG9ubHkgYmUgbWFkZSBpbiBzaXR1YXRpb25zIHdoZXJlIGl0IGluIHRoZSBz dW0gb2YgYWxsLCBoZWxwcyBpbmNyZWFzZSBlZmZpY2llbmN5IGFuZCB3aGVyZSB0aGUgZXh0cmEg YmFuZHdpZHRoIGNvbnN1bWVkIGlzIG5vdCBhbiBpc3N1ZS4NCkkgcmVhZCB0aGUgY3JpdGlxdWUg b2YgdGhpcyBpZGVhIGFzIG5vdCByZWFsbHkgYmUgYSBiYW5kd2lkdGggaXNzdWUsIGJ1dCB0aGF0 IHNvbWUgaW1wbGVtZW50ZXJzIHNpbXBseSBkb24ndCB3YW50IHRvIGJlIGZhY2VkIHdpdGggdGhl IHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCB0aGlzIGZlYXR1cmUuIEJ1dCBJIGRvbid0IHNlZSB0 aGF0IHRoZXkgaGF2ZSB0by4gQSBDUkwgd2l0aCBjZXJ0cyBpbiBhIG5vbi1jcml0aWNhbCBleHRl bnNpb24gc2hvdWxkIHdvcmsganVzdCBhcyB3ZWxsIGluIGN1cnJlbnQgY2xpZW50cyBhcyBhbnkg Y3VycmVudCBDUkwgd2l0aG91dCBjZXJ0cy4gVGhlIGV4dGVuc2lvbiBjYW4gc2ltcGx5IGJlIGln bm9yZWQuDQpUaGlzIGlzIG5vdCBhIG5lY2Vzc2FyeSBmZWF0dXJlLCBidXQgYSBwcmFjdGljYWwg b25lIG9mZmVyaW5nIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyBpbiBzb21lIGVudmlyb25tZW50 cyBhdCBubyBsb3NzIG9mIGludGVyb3BlcmFiaWxpdHkuDQogDQpTdGVmYW4gU2FudGVzc29uIA0K U2VuaW9yIFByb2dyYW0gTWFuYWdlciANCldpbmRvd3MgU2VjdXJpdHksIFN0YW5kYXJkcyANCiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQo+IEZyb206IFJ1c3MgSG91c2xleSBbbWFp bHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tXSANCj4gU2VudDogZGVuIDIxIGRlY2VtYmVyIDIwMDYg MTY6MTkgDQo+IFRvOiBTdGVmYW4gU2FudGVzc29uIA0KPiBDYzogaWV0Zi1wa2l4QGltYy5vcmcg DQo+IFN1YmplY3Q6IFJFOiBDZXJ0aWZpY2F0ZXMgaW4gQ1JMcyANCj4gDQo+IFN0ZWZhbjogDQo+ IA0KPiBJZiB0aGUgQ0EgY2hvb3NlcyB0byBvZmZlciBib3RoLCBob3cgY2FuIHRoZSBSUCBkZXRl cm1pbmUgd2hpY2ggb25lIGl0IA0KPiB3aWxsIGdldD8gIERvZXMgdGhlIENBIHBvc3QgdGhlbSBp biBkaWZmZXJlbnQgTERBUCBhdHRyaWJ1dGVzPyANCj4gDQo+IFJ1c3MgDQo+IA0KPiBBdCAwODow MCBBTSAxMi8yMS8yMDA2LCBTdGVmYW4gU2FudGVzc29uIHdyb3RlOiANCj4gDQo+ID5BcyB3aXRo IGFueXRoaW5nIGVsc2UsIHRoZSByZWx5aW5nIHBhcnR5IGNhbiBnZXQgd2hhdCB0aGUgQ0Egb2Zm ZXJzLiANCj4gPiANCj4gPkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IHJlYWxpc3RpYyBzY2Vu YXJpbyB3aGVyZSB0aGUgQ0EgaGFzIGEgDQo+ID5yZWFzb24gdG8gb2ZmZXIgQ1JMcyBib3RoIHdp dGggYW5kIHdpdGhvdXQgY2VydGlmaWNhdGVzLiBUbyBvZmZlciANCj4gPnRoaXMgY2FwYWJpbGl0 eSB0byBSUCBpcyBob3dldmVyIG5vdCBhIG1hdHRlciBmb3IgdGhpcyBwcm90b2NvbC4gSXQgDQo+ ID53b3VsZCBiZSBhIG1hdHRlciBmb3IgdGhlIENSTCByZWZlcmVuY2luZyBtb2RlbCwgaS5lLiBD RFAgYW5kL29yIA0KPiA+ZGlyZWN0b3J5IHNjaGVtYS4gDQo+ID4gDQo+ID5JIGRvbid0IHRoaW5r IHRoYXQgZXh0cmEgY29tcGxleGl0eSBob3dldmVyIGlzIHZlcnkgdXNlZnVsLiANCj4gPiANCj4g PlN0ZWZhbiBTYW50ZXNzb24gDQo+ID5TZW5pb3IgUHJvZ3JhbSBNYW5hZ2VyIA0KPiA+V2luZG93 cyBTZWN1cml0eSwgU3RhbmRhcmRzIA0KPiA+IA0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0gDQo+ID4gPiBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIFtt YWlsdG86b3duZXItaWV0Zi0gDQo+ID4gPiBwa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9m IERlbmlzIFBpbmthcyANCj4gPiA+IFNlbnQ6IGRlbiAyMCBkZWNlbWJlciAyMDA2IDE3OjA1IA0K PiA+ID4gVG86IGlldGYtcGtpeEBpbWMub3JnIA0KPiA+ID4gU3ViamVjdDogUmU6IENlcnRpZmlj YXRlcyBpbiBDUkxzIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSXQgaXMgbmVjZXNz YXJ5IHRvIHByb3ZpZGUgcmVseWluZyBwYXJ0aWVzIHdpdGggdGhlIGNob2ljZSB0byBnZXQgDQo+ ID4gPiA6IA0KPiA+ID4gDQo+ID4gPiAgIC0gQ1JMcyAiYXMgdXN1YWwiLCBvciANCj4gPiA+ICAg LSBDUkxzIHRoYXQgY2FycnkgdGhhdCBuZXcgZXh0ZW5zaW9uLiANCj4gPiA+IA0KPiA+ID4gVGhl IGN1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3QgYWxsb3cgZm9yIGl0LiANCj4gPiA+IA0KPiA+ID4g VW50aWwgdGhlIGRyYWZ0IGlzIGNoYW5nZWQsIEkgYW0gYWdhaW5zdCB0aGUgYWRkaXRpb24gb2Yg dGhpcyB3b3JrIA0KPiBpdGVtIA0KPiA+ID4gdG8gdGhlIHByb2dyYW0gb2YgdGhlIFBLSVggV0cu IA0KPiA+ID4gDQo+ID4gPiBEZW5pcyANCj4gPiA+IA0KPiA+ID4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g DQo+IF8gDQo+ID4gPiBfX19fX19fIA0KPiA+ID4gDQo+ID4gPiA+U2luY2UgbGFzdCBJRVRGIGEg bmV3IGRyYWZ0IHdhcyBwb3N0ZWQ6IA0KPiA+ID4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXNhbnRlc3Nvbi1wa2l4LXZjY3JsLSANCj4gMDAudHh0IA0KPiA+ID4g PiANCj4gPiA+ID5UaGVyZSBpcyBhIHJlcXVlc3QgdG8gYWRkIHRoaXMgZHJhZnQgdG8gdGhlIFBL SVggd29yayBhbmQgSSB3b3VsZCANCj4gPiA+IGVuY291cmFnZSB0byBzdGFydCB0aGUgZGlzY3Vz c2lvbiBhYm91dCB0aGlzIGRlY2lzaW9uIGluIHRoaXMgDQo+IHRocmVhZC4gDQo+ID4gPiA+IA0K PiA+ID4gPlN0ZWZhbiBTYW50ZXNzb24gDQo+ID4gPiA+U2VuaW9yIFByb2dyYW0gTWFuYWdlciAN Cj4gPiA+ID5XaW5kb3dzIFNlY3VyaXR5LCBTdGFuZGFyZHMgDQo+ID4gPiANCj4gPiA+IA0KPiA+ ID4gDQo= --=====003_Dragon615448871137_===== Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:o><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2800.1586" name=GENERATOR></HEAD> <BODY> <DIV> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">A way forward ?<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">The key issue is not the structure of the augmented CRL proposed by Stefan, <BR>but the ability to retrieve from a given CA either a CRL (i.e. the current <BR>structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed by Stefan), <BR>if a CA chooses to issue both. <o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">We need to focus on the cRLDistributionPoints extension to allow retrieving <BR>either a CRL, or a CRLwithCerts, or both.<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">Let us have a look at some sentences extracted from RFC 3280:<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">==========================================================================<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>The cRLDistributionPoints extension is a SEQUENCE of<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN><SPAN style="mso-spacerun: yes"> </SPAN>DistributionPoint.<SPAN style="mso-spacerun: yes"> </SPAN>A DistributionPoint consists of three fields,<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>each of which is optional: distributionPoint, reasons, and cRLIssuer.<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">( )<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>When the HTTP or FTP scheme is specified, the<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>URI MUST point to a single DER encoded CRL as specified in [RFC<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>2585].<SPAN style="mso-spacerun: yes"> </SPAN>HTTP server implementations accessed via the URI SHOULD<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>specify the media type application/pkix-crl in the content-type<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>header field of the response.<SPAN style="mso-spacerun: yes"> </SPAN><o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>When the LDAP scheme is specified, the<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>URI MUST specify a distinguishedName and attribute and SHOULD specify<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>a host name (e.g., ldap://ldap.example.com/cn=exmplCA,<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>dc=example,dc=com?certificateRevocationList;binary).<SPAN style="mso-spacerun: yes"> </SPAN><o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">( )<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>The URI MUST include<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>an appropriate attribute description for the attribute that holds the<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN style="mso-spacerun: yes"> </SPAN>DER [X.690] encoded CRL.</FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"> </FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">==========================================================================<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">A way forward would be to define appropriate attribute descriptions for <BR>the attributes that holds either the encoded CRL or the encoded CRLwithCerts. <BR>We could recommend to use currentCRL and currentCRLwithCerts, or latestCRL <BR>or latestCRLwithCerts.<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">For HTTTP or FTP a new media type could be defined such as <BR>application/pkix-crlwithcerts to be used in the content-type header field <BR>of the response. <o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">For LDAP, the query should end up, for example, with CRLwithcerts;binary/<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">We could also say that if the CA has chosen to issue both types of CRLs, <BR>then every distributionPoint holding a CRL (as defined today) should be placed <BR>first in the list.<o:p></o:p></FONT></FONT></SPAN></P> <P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2> </FONT></o:p></SPAN></P></DIV> <DIV>Denis</DIV> <DIV> </DIV> <DIV> <HR> </DIV> <DIV class=Section1> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Im in agreement that Stefans proposal is a decent one. As Phillip mentions, it certainly isnt appropriate in every situation, but I can see situations in which it might be useful. One might argue that a CRL issuer could issue two CRLs, the most commonly retrieved one without this extension, but a separate one issued with itthe latter being made to applications responsible for long term archive, historical signature validation, or other purposes which might find it useful. <o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I dont see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, non-critical, and does not affect path processing. <o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier New'">+----------------------------------------------------------------+<BR>| </SPAN><SPAN style="FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier New'">Peter Hesse</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> <SPAN style="COLOR: blue"><A href="mailto:pmhesse@geminisecurity.com">pmhesse@geminisecurity.com</A></SPAN> <SPAN style="COLOR: gray">|<BR>| </SPAN><SPAN style="COLOR: #3333cc">Phone: 703-378-5808 x105</SPAN> <SPAN style="COLOR: #3333cc">Gemini Security Solutions, Inc. </SPAN><SPAN style="COLOR: gray">|<BR>| </SPAN> <SPAN style="COLOR: #3333cc">Visit our InfoSecurity blog: <A href="http://www.securitymusings.com/">securitymusings.com</A></SPAN> <SPAN style="COLOR: gray">|<BR>+----------------------------------------------------------------+<BR></SPAN><SPAN style="COLOR: teal">"The generation of random numbers is too important to be left<BR> to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=MsoNormal><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <B>On Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February 13, 2007 6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=MsoNormal><o:p> </o:p></P> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">I think that Sharon's proposal might have been a good idea in 1995 before the world got wedged on CRLs as the revocation mechanism. We can define a package but its too late to get it embedded in the rest of the application infrastructure.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Given where we are Stefan's proposal is the best one. It is compatible with the existing infrastructure and solves a real issue. </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">It is an option, clearly there are cases where it would be inappropriate but universal applicability has never been a requirement. Otherwise we could have saved all the time spent on attribute certificates.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <BLOCKQUOTE style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> <P class=MsoNormal><SPAN lang=SV><o:p> </o:p></SPAN></P> <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center> <HR align=center width="100%" SIZE=2> </DIV> <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <B>On Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 9:09 AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in CRLs</SPAN><o:p></o:p></P> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Stefan I really don't think you can state where this will or will not be used in the future. Naturally you know where you want to use it, but software only enables a facility and the customer decides when and how to use it. </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Whether this scheme could possibly be useful in some cases is not my point. My point is that current deployments seem to be working fine without it and I don't want to see those interfered with just because some CA they may have cross certified with decided to put certificates inside their CRLS. Back to Denis' point - there is no need to impose this in the way you've proposed. </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Earlier I (and others including Dave Kemp) suggested a "package" that includes the CRL, and the certificate in question as an 'extra' that a CA could publish in addition to a regular CRL. That "package could be published in a separate directory attribute and/or an HTTP accessible file. It could be pointed to from within the certificate just as the CRL currently is. That could be done either by extending the CRLDP or adding a new pointer extension or adding a new method to the AIA extension. That type of approach gives you what you want but does not in any way interfere with clients who do not want and do not need to retrieve that bloated CRL. </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Also, you haven't addressed the question about what happens when more than one certificate is needed. If a CRL includes more than one certificate (e.g. the CRL issuer did one or more key rollovers then CRL gets bloated a lot bigger than you suggested. I don't want to debate how often a key gets rolled over either however I have definitely seen instances in real world deployments where a key has been rolled very often in a very short period of time (regardless of whether the reason for rolling it was a good one or not - it has happened). Also, regardless of the size of the "bloat" I'm saying that in most cases the clients will already have the certificates in question and this bloat will cause them extra processing in managing their certificate caches etc unnecessarily. The client should have a choice as to whether to download the certificate or not.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">I don't understand why you're so opposed to the "package" solution. </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Cheers,</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal><SPAN lang=SV style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Sharon</SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV> <DIV> <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><SPAN lang=SV style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">-----Original Message-----<BR><B>From:</B> Stefan Santesson [mailto:stefans@microsoft.com] <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> Sharon Boeyen; Russ Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in CRLs<o:p></o:p></SPAN></P></DIV> <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: 0in"> <P class=MsoNormal><A name=_MailEndCompose><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">We are only talking about an extra 16K at most. The download time is the absolute most cases is negligible. </SPAN></A><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">For those cases where this solution makes sense, the network bandwidth issue is not a problem.<o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">For the cases where this would be an issue, this solution would not be used.<o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">On the contrary, in some networks and scenarios, this will improve performance. Especially in high latency networks with PKI based peer-peer authentication where an extra retrieval cost way more performance than the expanded CRL size.<o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Also, many clients are configured to pre-fetch CRL:s before they are used, using idle time on the network at no extra cost.<o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <P class=MsoNormal><B><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan Santesson</SPAN></B><SPAN lang=EN-GB style="COLOR: #1f497d"><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior Program Manager</SPAN><SPAN lang=EN-GB style="COLOR: navy"><o:p></o:p></SPAN></P> <P class=MsoNormal><B><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows Security, Standards</SPAN></B><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV> <P class=MsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> <DIV> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=MsoNormal><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Sharon Boeyen [mailto:sharon.boeyen@entrust.com] <BR><B>Sent:</B> den 4 januari 2007 17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=MsoNormal><SPAN lang=SV><o:p> </o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">I still think wasted bandwidth is also an issue. Forcing the download of 'fat' CRLs on clients when, in many cases, those clients already have the certificates locally that caused the bloating of the CRL, is an unnecessary waste.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">-----Original Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">From: owner-ietf-pkix@mail.imc.org [<A href="mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.imc.org</A>] On Behalf Of Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Sent: Wednesday, January 03, 2007 9:58 AM</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Cc: ietf-pkix@imc.org</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Subject: RE: Certificates in CRLs</SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P> <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><SPAN lang=SV><o:p> </o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">Russ,</SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">In theory, the CA can put different pointers to different CRLs in each certificate if some certificates are prime targets for frequent checking. But I don't think that is a common scenario.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">My point is that in order to allow free selection of CRLs, you would have to add capability to the CDP extension rather than to the CRL. I don't think such effort is worth the trouble.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">I'm convinced that including certs in a CRL will only be made in situations where it in the sum of all, helps increase efficiency and where the extra bandwidth consumed is not an issue.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">I read the critique of this idea as not really be a bandwidth issue, but that some implementers simply don't want to be faced with the requirement to implement this feature. But I don't see that they have to. A CRL with certs in a non-critical extension should work just as well in current clients as any current CRL without certs. The extension can simply be ignored.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">This is not a necessary feature, but a practical one offering performance improvements in some environments at no loss of interoperability.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV><o:p> </o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Senior Program Manager</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P> <P class=MsoNormal><SPAN lang=SV><o:p> </o:p></SPAN></P> <P><SPAN lang=SV style="FONT-SIZE: 10pt">> -----Original Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> From: Russ Housley [<A href="mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> Sent: den 21 december 2006 16:19</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> To: Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> Cc: ietf-pkix@imc.org</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> Subject: RE: Certificates in CRLs</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> Stefan:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> If the CA chooses to offer both, how can the RP determine which one it </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> will get? Does the CA post them in different LDAP attributes?</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> Russ</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> At 08:00 AM 12/21/2006, Stefan Santesson wrote:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >As with anything else, the relying party can get what the CA offers.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >I don't think there is any realistic scenario where the CA has a </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >reason to offer CRLs both with and without certificates. To offer </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >this capability to RP is however not a matter for this protocol. It </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >would be a matter for the CRL referencing model, i.e. CDP and/or </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >directory schema.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >I don't think that extra complexity however is very useful.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >Senior Program Manager</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> >Windows Security, Standards</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > -----Original Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > From: owner-ietf-pkix@mail.imc.org [<A href="mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > pkix@mail.imc.org] On Behalf Of Denis Pinkas</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > Sent: den 20 december 2006 17:05</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > To: ietf-pkix@imc.org</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > Subject: Re: Certificates in CRLs</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > It is necessary to provide relying parties with the choice to get </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > :</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > - CRLs "as usual", or</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > - CRLs that carry that new extension.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > The current proposal does not allow for it.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > Until the draft is changed, I am against the addition of this work</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> item</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > to the program of the PKIX WG.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > Denis</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> ______________________________________________________________________</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> _</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > _______</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > >Since last IETF a new draft was posted:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > ><A href="http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" target=_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-</A></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> 00.txt</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > >There is a request to add this draft to the PKIX work and I would</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > encourage to start the discussion about this decision in this</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> thread.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > >Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > >Senior Program Manager</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > > >Windows Security, Standards</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">> > ></SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV> <HR> </BODY></HTML> --=====003_Dragon615448871137_=====-- 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 l1E5lWmO008104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 22:47: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 l1E5lWqn008103; Tue, 13 Feb 2007 22:47: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 ms.kisa.or.kr (ms.kisa.or.kr [211.252.150.23]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1E5lUpt008095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Tue, 13 Feb 2007 22:47:31 -0700 (MST) (envelope-from jhbaek@kisa.or.kr) Received: (qmail 23648 invoked from network); 14 Feb 2007 05:28:25 -0000 Received: from unknown (HELO 5423D2) (172.16.7.103) by ms.kisa.or.kr with SMTP; 14 Feb 2007 05:28:25 -0000 Message-ID: <002501c74ffb$9a7d0a60$670710ac@5423D2> From: "Jonghyun Baek" <jhbaek@kisa.or.kr> To: <ietf-pkix@imc.org> Subject: Questions on the use case of KeyUsage type in Key Usage extension Date: Wed, 14 Feb 2007 14:47:24 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C75047.0A519F90" 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C75047.0A519F90 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBQS0lYIFdHLA0KDQpUaGUga2V5IHVzYWdlIGV4dGVuc2lvbihzZWN0aW9uIDQuMi4xLjMg aW4gUkZDMzI4MCkgIGhhdmUgbmluZSBLZXlVc2FnZSB0eXBlcyBzdWNoIGFzIGRpZ2l0YWxTaWdu YXR1cmUsIG5vbiByZXB1ZGlhdGlvbiwga2V5RW5jaXBoZXJtZW50LCBldGMuDQpJIGNhbiB1bmRl cnN0b29kIGVhY2ggb2YgdGhlIEtleVVzYWdlIHR5cGVzIG1lYW5pbmcgYnV0IGkgd291bGQgbGlr ZSB0byBrbm93IGEgcmVhbCBleGFtcGxlIG9yIGEgdXNlIGNhc2Ugb2YgdGhlIGVuY2lwaGVyT25s eSB0eXBlIGFuZCB0aGUgZGVjaXBoZXJPbmx5IHR5cGUuIGkgbWVhbiB3aGljaCBraW5kIG9mIHRo ZSBzZXJ2aWNlIG9yIGFwcGxpY2F0aW9uIG5lZWQgdGhlIGVuY2lwaGVyT25seSBvciBkZWNpcGhl ck9ubHkgdHlwZSBjZXJ0aWZpY2F0ZSBhbmQgZm9yIHdoYXQgPw0KSSB3aWxsIGJlIHNvIGFwcHJp Y2lhdGUgaWYgeW91IGdpdmUgbWUgYSBoYW5kLg0KDQpUaGFua3MhDQoNCkpvbmdoeXVuIEJhZWsg DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAN CkpvbmdoeXVuIEJhZWsgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gDQpTZW5pb3IgUmVzZWFyY2hlcg0KRWxlY3Ryb25pYyBUcmFuc2FjdGlvbiBT ZWN1cml0eSBQbGFubmluZyBUZWFtDQpLb3JlYSBJbmZvcm1hdGlvbiBTZWN1cml0eSBBZ2VuY3kg KEtJU0EpIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIA0KNzggR2FyYWstRG9uZywgU29uZ3BhLUd1LCBTZW91bCwgS29yZWEgMTM4LTgwMyANClRl bCA6ICs4Mi0yLTQwNS01NDIzICANCkZheCA6ICs4Mi0yLTQwNS01MjE5IA0KTW9iaWxlIDogKzgy LTE2LTU5MS0zNjY0IA0KRS1tYWlsIDogamhiYWVrQGtpc2Eub3Iua3IgDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0= ------=_NextPart_000_0022_01C75047.0A519F90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMzAyMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+RGVhciBQS0lYIFdHLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGUg a2V5IHVzYWdlIGV4dGVuc2lvbihzZWN0aW9uJm5ic3A7NC4yLjEuMyANCmluJm5ic3A7UkZDMzI4 MCkmbmJzcDsmbmJzcDtoYXZlIG5pbmUgS2V5VXNhZ2UgdHlwZXMgc3VjaCBhcyBkaWdpdGFsU2ln bmF0dXJlLCANCm5vbiByZXB1ZGlhdGlvbiwga2V5RW5jaXBoZXJtZW50LCBldGMuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JIGNhbiB1bmRlcnN0b29kIGVhY2gg b2YmbmJzcDt0aGUgDQpLZXlVc2FnZSZuYnNwO3R5cGVzIG1lYW5pbmcgYnV0IGkgd291bGQgbGlr ZSB0byBrbm93IGEmbmJzcDtyZWFsIGV4YW1wbGUgb3IgDQphJm5ic3A7dXNlIGNhc2Ugb2YgdGhl IGVuY2lwaGVyT25seSZuYnNwO3R5cGUgYW5kIHRoZSBkZWNpcGhlck9ubHkgdHlwZS4gaSBtZWFu IA0Kd2hpY2gga2luZCBvZiB0aGUgc2VydmljZSBvciBhcHBsaWNhdGlvbiBuZWVkIHRoZSBlbmNp cGhlck9ubHkgb3IgDQpkZWNpcGhlck9ubHkmbmJzcDt0eXBlIGNlcnRpZmljYXRlIGFuZCBmb3Ig d2hhdCA/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JIHdpbGwg YmUgc28gYXBwcmljaWF0ZSBpZiB5b3UgZ2l2ZSBtZSBhIA0KaGFuZC48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+VGhhbmtzITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PjxGT05UIHNpemU9Mj5Kb25naHl1biBCYWVrPC9GT05UPiZuYnNwOzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PEZPTlQgDQpmYWNlPUFyaWFsPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PSA8QlI+Sm9uZ2h5dW4gQmFlayANCjxCUj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPEJSPlNlbmlvciANClJl c2VhcmNoZXI8QlI+RWxlY3Ryb25pYyBUcmFuc2FjdGlvbiBTZWN1cml0eSBQbGFubmluZyBUZWFt PEJSPktvcmVhIEluZm9ybWF0aW9uIA0KU2VjdXJpdHkgQWdlbmN5IChLSVNBKSA8QlI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPEJSPjc4IEdh cmFrLURvbmcsIFNvbmdwYS1HdSwgU2VvdWwsIEtvcmVhIDEzOC04MDMgPEJSPlRlbCA6IA0KKzgy LTItNDA1LTU0MjMmbmJzcDsgPEJSPkZheCA6ICs4Mi0yLTQwNS01MjE5IDxCUj5Nb2JpbGUgOiAr ODItMTYtNTkxLTM2NjQgDQo8QlI+RS1tYWlsIDogPC9GT05UPjxBIGhyZWY9Im1haWx0bzpqaGJh ZWtAa2lzYS5vci5rciI+PEZPTlQgDQpmYWNlPUFyaWFsPmpoYmFla0BraXNhLm9yLmtyPC9GT05U PjwvQT48Rk9OVCBmYWNlPUFyaWFsPiANCjxCUj49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_000_0022_01C75047.0A519F90-- 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 l1E54tdL005543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 22:04: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 l1E54trr005542; Tue, 13 Feb 2007 22:04: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 nelson.textdrive.com (nelson.textdrive.com [207.7.108.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1E54sMx005534 for <ietf-pkix@imc.org>; Tue, 13 Feb 2007 22:04:54 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from petervista (pool-71-246-238-144.washdc.fios.verizon.net [71.246.238.144]) by nelson.textdrive.com (Postfix) with ESMTP id 77F4B460A1; Wed, 14 Feb 2007 05:04:52 +0000 (GMT) From: "Peter Hesse" <pmhesse@geminisecurity.com> To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'Stefan Santesson'" <stefans@microsoft.com>, "'Russ Housley'" <housley@vigilsec.com> Cc: <ietf-pkix@imc.org> References: <198A730C2044DE4A96749D13E167AD37010D4403@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37010D4403@MOU1WNEXMB04.vcorp.ad.vrsn.com> Subject: RE: Certificates in CRLs Date: Wed, 14 Feb 2007 00:04:50 -0500 Message-ID: <001b01c74ff5$a993b540$fcbb1fc0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C74FCB.C0BDAD40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Accw5xVqg7D3uMKcRxuliRmskfAmpge32d6AAAuOwwA= Content-Language: en-us x-cr-hashedpuzzle: G5HV I+7x JXc3 Onzp TW7J Zn4T eiJH gfTw gxNk kEyE mus8 qX7d xfeG 0USS 4FsD 8cAR;5;aABvAHUAcwBsAGUAeQBAAHYAaQBnAGkAbABzAGUAYwAuAGMAbwBtADsAaQBlAHQAZgAtAHAAawBpAHgAQABpAG0AYwAuAG8AcgBnADsAcABiAGEAawBlAHIAQAB2AGUAcgBpAHMAaQBnAG4ALgBjAG8AbQA7AHMAaABhAHIAbwBuAC4AYgBvAGUAeQBlAG4AQABlAG4AdAByAHUAcwB0AC4AYwBvAG0AOwBzAHQAZQBmAGEAbgBzAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=;Sosha1_v1;7;{11714089-52D5-43DE-901C-604FF7EC4875};cABtAGgAZQBzAHMAZQBAAGcAZQBtAGkAbgBpAHMAZQBjAHUAcgBpAHQAeQAuAGMAbwBtAA==;Wed, 14 Feb 2007 05:04:31 GMT;UgBFADoAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAcwAgAGkAbgAgAEMAUgBMAHMA x-cr-puzzleid: {11714089-52D5-43DE-901C-604FF7EC4875} Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. ------=_NextPart_000_001C_01C74FCB.C0BDAD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm in agreement that Stefan's proposal is a decent one. As Phillip mentions, it certainly isn't appropriate in every situation, but I can see situations in which it might be useful. One might argue that a CRL issuer could issue two CRLs, the most commonly retrieved one without this extension, but a separate one issued with it-the latter being made to applications responsible for long term archive, historical signature validation, or other purposes which might find it useful. I don't see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, non-critical, and does not affect path processing. --Peter +----------------------------------------------------------------+ | Peter Hesse pmhesse@geminisecurity.com | | Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. | | Visit our InfoSecurity blog: securitymusings.com <http://www.securitymusings.com/> | +----------------------------------------------------------------+ "The generation of random numbers is too important to be left to chance." --Robert R. Coveyou From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Tuesday, February 13, 2007 6:53 PM To: Sharon Boeyen; Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs I think that Sharon's proposal might have been a good idea in 1995 before the world got wedged on CRLs as the revocation mechanism. We can define a package but its too late to get it embedded in the rest of the application infrastructure. Given where we are Stefan's proposal is the best one. It is compatible with the existing infrastructure and solves a real issue. It is an option, clearly there are cases where it would be inappropriate but universal applicability has never been a requirement. Otherwise we could have saved all the time spent on attribute certificates. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Stefan I really don't think you can state where this will or will not be used in the future. Naturally you know where you want to use it, but software only enables a facility and the customer decides when and how to use it. Whether this scheme could possibly be useful in some cases is not my point. My point is that current deployments seem to be working fine without it and I don't want to see those interfered with just because some CA they may have cross certified with decided to put certificates inside their CRLS. Back to Denis' point - there is no need to impose this in the way you've proposed. Earlier I (and others including Dave Kemp) suggested a "package" that includes the CRL, and the certificate in question as an 'extra' that a CA could publish in addition to a regular CRL. That "package could be published in a separate directory attribute and/or an HTTP accessible file. It could be pointed to from within the certificate just as the CRL currently is. That could be done either by extending the CRLDP or adding a new pointer extension or adding a new method to the AIA extension. That type of approach gives you what you want but does not in any way interfere with clients who do not want and do not need to retrieve that bloated CRL. Also, you haven't addressed the question about what happens when more than one certificate is needed. If a CRL includes more than one certificate (e.g. the CRL issuer did one or more key rollovers then CRL gets bloated a lot bigger than you suggested. I don't want to debate how often a key gets rolled over either however I have definitely seen instances in real world deployments where a key has been rolled very often in a very short period of time (regardless of whether the reason for rolling it was a good one or not - it has happened). Also, regardless of the size of the "bloat" I'm saying that in most cases the clients will already have the certificates in question and this bloat will cause them extra processing in managing their certificate caches etc unnecessarily. The client should have a choice as to whether to download the certificate or not. I don't understand why you're so opposed to the "package" solution. Cheers, Sharon -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs We are only talking about an extra 16K at most. The download time is the absolute most cases is negligible. For those cases where this solution makes sense, the network bandwidth issue is not a problem. For the cases where this would be an issue, this solution would not be used. On the contrary, in some networks and scenarios, this will improve performance. Especially in high latency networks with PKI based peer-peer authentication where an extra retrieval cost way more performance than the expanded CRL size. Also, many clients are configured to pre-fetch CRL:s before they are used, using idle time on the network at no extra cost. Stefan Santesson Senior Program Manager Windows Security, Standards From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs I still think wasted bandwidth is also an issue. Forcing the download of 'fat' CRLs on clients when, in many cases, those clients already have the certificates locally that caused the bloating of the CRL, is an unnecessary waste. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Wednesday, January 03, 2007 9:58 AM To: Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs Russ, In theory, the CA can put different pointers to different CRLs in each certificate if some certificates are prime targets for frequent checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would have to add capability to the CDP extension rather than to the CRL. I don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in situations where it in the sum of all, helps increase efficiency and where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, but that some implementers simply don't want to be faced with the requirement to implement this feature. But I don't see that they have to. A CRL with certs in a non-critical extension should work just as well in current clients as any current CRL without certs. The extension can simply be ignored. This is not a necessary feature, but a practical one offering performance improvements in some environments at no loss of interoperability. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: den 21 december 2006 16:19 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: Certificates in CRLs > > Stefan: > > If the CA chooses to offer both, how can the RP determine which one it > will get? Does the CA post them in different LDAP attributes? > > Russ > > At 08:00 AM 12/21/2006, Stefan Santesson wrote: > > >As with anything else, the relying party can get what the CA offers. > > > >I don't think there is any realistic scenario where the CA has a > >reason to offer CRLs both with and without certificates. To offer > >this capability to RP is however not a matter for this protocol. It > >would be a matter for the CRL referencing model, i.e. CDP and/or > >directory schema. > > > >I don't think that extra complexity however is very useful. > > > >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 december 2006 17:05 > > > To: ietf-pkix@imc.org > > > Subject: Re: Certificates in CRLs > > > > > > > > > > > > It is necessary to provide relying parties with the choice to get > > > : > > > > > > - CRLs "as usual", or > > > - CRLs that carry that new extension. > > > > > > The current proposal does not allow for it. > > > > > > Until the draft is changed, I am against the addition of this work > item > > > to the program of the PKIX WG. > > > > > > Denis > > > > > > > ______________________________________________________________________ > _ > > > _______ > > > > > > >Since last IETF a new draft was posted: > > > >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- > 00.txt > > > > > > > >There is a request to add this draft to the PKIX work and I would > > > encourage to start the discussion about this decision in this > thread. > > > > > > > >Stefan Santesson > > > >Senior Program Manager > > > >Windows Security, Standards > > > > > > > > > ------=_NextPart_000_001C_01C74FCB.C0BDAD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Message</title> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>I’m in agreement that Stefan’s proposal is a = decent one. As Phillip mentions, it certainly isn’t appropriate in = every situation, but I can see situations in which it might be useful. = One might argue that a CRL issuer could issue two CRLs, the most commonly = retrieved one without this extension, but a separate one issued with it—the = latter being made to applications responsible for long term archive, historical = signature validation, or other purposes which might find it useful. = <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>I don’t see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, = non-critical, and does not affect path processing. <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>--Peter<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Courier New"; color:gray'>+------------------------------------------------------------= ----+<br> | </span><span style=3D'font-size:10.0pt;font-family:"Courier New"; color:#3333CC'>Peter Hesse</span><span = style=3D'font-size:10.0pt;font-family: "Courier = New"'> &= nbsp; <span style=3D'color:blue'><a = href=3D"mailto:pmhesse@geminisecurity.com">pmhesse@geminisecurity.com</a>= </span> <span style=3D'color:gray'>|<br> | </span><span style=3D'color:#3333CC'>Phone: 703-378-5808 = x105</span> <span style=3D'color:#3333CC'>Gemini Security Solutions, = Inc. </span><span style=3D'color:gray'>|<br> | </span> <span = style=3D'color:#3333CC'>Visit our InfoSecurity blog: <a = href=3D"http://www.securitymusings.com/">securitymusings.com</a></span>&n= bsp; <span style=3D'color:gray'>|<br> +----------------------------------------------------------------+<br> </span><span style=3D'color:teal'>"The generation of random numbers = is too important to be left<br> to chance." --Robert R. Coveyou</span></span><span = style=3D'font-size: 10.0pt'><o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <b>On = Behalf Of </b>Hallam-Baker, Phillip<br> <b>Sent:</b> Tuesday, February 13, 2007 6:53 PM<br> <b>To:</b> Sharon Boeyen; Stefan Santesson; Russ Housley<br> <b>Cc:</b> ietf-pkix@imc.org<br> <b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>I think that Sharon's proposal might have been a good idea = in 1995 before the world got wedged on CRLs as the revocation mechanism. We can = define a package but its too late to get it embedded in the rest of the = application infrastructure.</span><span lang=3DSV><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Given where we are Stefan's proposal is the best one. It is compatible with the existing infrastructure and solves a real issue. = </span><span lang=3DSV><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>It is an option, clearly there are cases where it would be inappropriate but universal applicability has never been a requirement. Otherwise we could have saved all the time spent on attribute = certificates.</span><span lang=3DSV><o:p></o:p></span></p> <blockquote style=3D'border:none;border-left:solid blue = 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'= > <p class=3DMsoNormal><span lang=3DSV><o:p> </o:p></span></p> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'> <hr size=3D2 width=3D"100%" align=3Dcenter> </div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span = style=3D'font-size:10.0pt; font-family:"Tahoma","sans-serif"'>From:</span></b><span = style=3D'font-size:10.0pt; font-family:"Tahoma","sans-serif"'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <b>On Behalf Of </b>Sharon = Boeyen<br> <b>Sent:</b> Friday, January 05, 2007 9:09 AM<br> <b>To:</b> 'Stefan Santesson'; Sharon Boeyen; Russ Housley<br> <b>Cc:</b> ietf-pkix@imc.org<br> <b>Subject:</b> RE: Certificates in CRLs</span><o:p></o:p></p> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Stefan I really don't think you can state where this will or = will not be used in the future. Naturally you know where you want to use it, = but software only enables a facility and the customer decides when and how = to use it. </span><span lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Whether this scheme could possibly be useful in some cases = is not my point. My point is that current deployments seem to be working fine = without it and I don't want to see those interfered with just because some CA = they may have cross certified with decided to put certificates inside their CRLS. = Back to Denis' point - there is no need to impose this in the way you've = proposed. </span><span lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Earlier I (and others including Dave Kemp) suggested a "package" that includes the CRL, and the certificate in = question as an 'extra' that a CA could publish in addition to a regular CRL. That "package could be published in a separate directory attribute = and/or an HTTP accessible file. It could be pointed to from within the certificate just as the CRL currently is. That could be done either = by extending the CRLDP or adding a new pointer extension or adding a = new method to the AIA extension. That type of approach gives you what you = want but does not in any way interfere with clients who do not want and do not = need to retrieve that bloated CRL. </span><span = lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Also, you haven't addressed the question about what = happens when more than one certificate is needed. If a CRL includes more = than one certificate (e.g. the CRL issuer did one or more key = rollovers then CRL gets bloated a lot bigger than you suggested. I don't want to = debate how often a key gets rolled over either however I have definitely seen instances in real world deployments where a key has been rolled very = often in a very short period of time (regardless of whether the reason for rolling = it was a good one or not - it has happened). Also, regardless of the size of = the "bloat" I'm saying that in most cases the clients will already = have the certificates in question and this bloat will cause them extra = processing in managing their certificate caches etc unnecessarily. The client should = have a choice as to whether to download the certificate or not.</span><span = lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>I don't understand why you're so opposed to the = "package" solution. </span><span lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Cheers,</span><span lang=3DSV><o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span lang=3DSV = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:blue'>Sharon</span><span lang=3DSV> <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DSV = style=3D'font-size: 10.0pt;font-family:"Tahoma","sans-serif"'>-----Original Message-----<br> <b>From:</b> Stefan Santesson [mailto:stefans@microsoft.com] <br> <b>Sent:</b> Friday, January 05, 2007 8:01 AM<br> <b>To:</b> Sharon Boeyen; Russ Housley<br> <b>Cc:</b> ietf-pkix@imc.org<br> <b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p> </div> <blockquote = style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'> <p class=3DMsoNormal><a name=3D"_MailEndCompose"><span = style=3D'font-size:11.0pt; font-family:"Calibri","sans-serif";color:#1F497D'>We are only talking = about an extra 16K at most. The download time is the absolute most cases is = negligible. </span></a><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>For those cases where this solution makes sense, the = network bandwidth issue is not a problem.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>For the cases where this would be an issue, this solution = would not be used.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>On the contrary, in some networks and scenarios, this = will improve performance. Especially in high latency networks with PKI based peer-peer authentication where an extra retrieval cost way more = performance than the expanded CRL size.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>Also, many clients are configured to pre-fetch CRL:s = before they are used, using idle time on the network at no extra = cost.<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <p class=3DMsoNormal><b><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family: "Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span = lang=3DEN-GB style=3D'color:#1F497D'><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"; color:#400040'>Senior Program Manager</span><span lang=3DEN-GB = style=3D'color:navy'><o:p></o:p></span></p> <p class=3DMsoNormal><b><span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family: "Arial","sans-serif";color:#400040'>Windows Security, = Standards</span></b><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p></o:p></span></p> </div> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Sharon = Boeyen [mailto:sharon.boeyen@entrust.com] <br> <b>Sent:</b> den 4 januari 2007 17:36<br> <b>To:</b> Stefan Santesson; Russ Housley<br> <b>Cc:</b> ietf-pkix@imc.org<br> <b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><span lang=3DSV><o:p> </o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>I still think wasted = bandwidth is also an issue. Forcing the download of 'fat' CRLs on clients when, in = many cases, those clients already have the certificates locally that caused = the bloating of the CRL, is an unnecessary waste.</span><span = lang=3DSV><o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>-----Original = Message-----</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>From: owner-ietf-pkix@mail.imc.org [<a = href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</a>] On Behalf Of Stefan Santesson</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>Sent: Wednesday, = January 03, 2007 9:58 AM</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>To: Russ = Housley</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>Cc: = ietf-pkix@imc.org</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>Subject: RE: = Certificates in CRLs</span><span lang=3DSV> <o:p></o:p></span></p> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span = lang=3DSV><o:p> </o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>Russ,</span><span = lang=3DSV> <o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>In theory, the CA can put = different pointers to different CRLs in each certificate if some certificates are = prime targets for frequent checking. But I don't think that is a common = scenario.</span><span lang=3DSV><o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>My point is that in order = to allow free selection of CRLs, you would have to add capability to the CDP = extension rather than to the CRL. I don't think such effort is worth the = trouble.</span><span lang=3DSV><o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>I'm convinced that = including certs in a CRL will only be made in situations where it in the sum of all, helps increase efficiency and where the extra bandwidth consumed is not an = issue.</span><span lang=3DSV><o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>I read the critique of = this idea as not really be a bandwidth issue, but that some implementers simply don't = want to be faced with the requirement to implement this feature. But I don't = see that they have to. A CRL with certs in a non-critical extension should = work just as well in current clients as any current CRL without certs. The = extension can simply be ignored.</span><span lang=3DSV><o:p></o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>This is not a necessary = feature, but a practical one offering performance improvements in some environments = at no loss of interoperability.</span><span lang=3DSV><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV><o:p> </o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>Stefan = Santesson</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>Senior Program = Manager</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>Windows Security, = Standards</span><span lang=3DSV> <o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DSV><o:p> </o:p></span></p> <p><span lang=3DSV style=3D'font-size:10.0pt'>> -----Original = Message-----</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> From: Russ = Housley [<a href=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</a>]</sp= an><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> Sent: den 21 = december 2006 16:19</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> To: Stefan = Santesson</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> Cc: = ietf-pkix@imc.org</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> Subject: RE: = Certificates in CRLs</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> = Stefan:</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> If the CA chooses = to offer both, how can the RP determine which one it </span><span lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> will get? = Does the CA post them in different LDAP attributes?</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> Russ</span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> At 08:00 AM = 12/21/2006, Stefan Santesson wrote:</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >As with = anything else, the relying party can get what the CA offers.</span><span lang=3DSV> = <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >I don't think = there is any realistic scenario where the CA has a </span><span lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >reason to = offer CRLs both with and without certificates. To offer </span><span lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >this = capability to RP is however not a matter for this protocol. It </span><span lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >would be a = matter for the CRL referencing model, i.e. CDP and/or </span><span lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >directory = schema.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >I don't think = that extra complexity however is very useful.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >Stefan = Santesson</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >Senior = Program Manager</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> >Windows = Security, Standards</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ></span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = -----Original Message-----</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > From: = owner-ietf-pkix@mail.imc.org [<a href=3D"mailto:owner-ietf-">mailto:owner-ietf-</a> </span><span = lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = pkix@mail.imc.org] On Behalf Of Denis Pinkas</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > Sent: = den 20 december 2006 17:05</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > To: ietf-pkix@imc.org</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = Subject: Re: Certificates in CRLs</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > It is = necessary to provide relying parties with the choice to get </span><span = lang=3DSV><br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = :</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = > - CRLs "as usual", or</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = > - CRLs that carry that new extension.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > The = current proposal does not allow for it.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > Until = the draft is changed, I am against the addition of this work</span><span lang=3DSV> = <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> item</span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > to the = program of the PKIX WG.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = Denis</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> ______________________________________________________________________</s= pan><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> _</span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = _______</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = >Since last IETF a new draft was posted:</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > ><a href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-santesson-pki= x-vccrl-</a></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> = 00.txt</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = >There is a request to add this draft to the PKIX work and I would</span><span = lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = encourage to start the discussion about this decision in this</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> = thread.</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = >Stefan Santesson</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = >Senior Program Manager</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > > = >Windows Security, Standards</span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <br> </span><span lang=3DSV style=3D'font-size:10.0pt'>> > = ></span><span lang=3DSV> <o:p></o:p></span></p> </div> </blockquote> </blockquote> </div> </body> </html> ------=_NextPart_000_001C_01C74FCB.C0BDAD40-- 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 l1E1aIRc092245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 18:36: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 l1E1aIhM092244; Tue, 13 Feb 2007 18:36: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1E1a9Jg092231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 18:36:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p0624086dc1f8172775ff@[10.20.30.108]> In-Reply-To: <45D0F1F5.8060301@cesnet.cz> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> <45D0F1F5.8060301@cesnet.cz> Date: Tue, 13 Feb 2007 17:35:55 -0800 To: Milan Sova <sova+pkix@cesnet.cz>, ietf-pkix@vpnc.org From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: URN in subjectAltName Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:02 AM +0100 2/13/07, Milan Sova wrote: > As the group does not seem to have a strong opinion of the choices I >propose to include the following text just after the URI part of the >section 4.2.1.6 Subject Alternative Name: > >"When the subjectAltName extension contains a URN, the name MUST be >stored in the uniformResourceIdentifier (IA5String). The name MUST >follow the URN syntax and encoding rules specified in [RFC 2141]." > > Comments? This seems like a good addition, seeing as there were multiple choices given on the mailing list, and that means interoperability issues. Note that there are two paragraphs to the "URI part"; this should be added after the second paragraph, just before "When the subjectAltName extension contains a DN...". --Paul Hoffman, Director --VPN Consortium 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 l1DNqjKv084102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 16: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 l1DNqjTV084101; Tue, 13 Feb 2007 16: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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1DNqdaa084092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Tue, 13 Feb 2007 16:52:44 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l1DNqbZZ014298; Tue, 13 Feb 2007 15:52:37 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 15:52:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74FCA.09741062" Subject: RE: Certificates in CRLs Date: Tue, 13 Feb 2007 15:52:36 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37010D4403@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Certificates in CRLs Thread-Index: Accw5xVqg7D3uMKcRxuliRmskfAmpge32d6A From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Sharon Boeyen" <sharon.boeyen@entrust.com>, "Stefan Santesson" <stefans@microsoft.com>, "Russ Housley" <housley@vigilsec.com> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 13 Feb 2007 23:52:37.0989 (UTC) FILETIME=[0A677950:01C74FCA] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C74FCA.09741062 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that Sharon's proposal might have been a good idea in 1995 = before the world got wedged on CRLs as the revocation mechanism. We can = define a package but its too late to get it embedded in the rest of the = application infrastructure. =20 Given where we are Stefan's proposal is the best one. It is compatible = with the existing infrastructure and solves a real issue.=20 =20 It is an option, clearly there are cases where it would be inappropriate = but universal applicability has never been a requirement. Otherwise we = could have saved all the time spent on attribute certificates. ________________________________ From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Friday, January 05, 2007 9:09 AM To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 Stefan I really don't think you can state where this will or will not = be used in the future. Naturally you know where you want to use it, but = software only enables a facility and the customer decides when and how = to use it.=20 =20 Whether this scheme could possibly be useful in some cases is not my = point. My point is that current deployments seem to be working fine = without it and I don't want to see those interfered with just because = some CA they may have cross certified with decided to put certificates = inside their CRLS. Back to Denis' point - there is no need to impose = this in the way you've proposed.=20 =20 Earlier I (and others including Dave Kemp) suggested a "package" that = includes the CRL, and the certificate in question as an 'extra' that a = CA could publish in addition to a regular CRL. That "package could be = published in a separate directory attribute and/or an HTTP accessible = file. It could be pointed to from within the certificate just as the CRL = currently is. That could be done either by extending the CRLDP or adding = a new pointer extension or adding a new method to the AIA extension. = That type of approach gives you what you want but does not in any way = interfere with clients who do not want and do not need to retrieve that = bloated CRL.=20 =20 Also, you haven't addressed the question about what happens when more = than one certificate is needed. If a CRL includes more than one = certificate (e.g. the CRL issuer did one or more key rollovers then CRL = gets bloated a lot bigger than you suggested. I don't want to debate how = often a key gets rolled over either however I have definitely seen = instances in real world deployments where a key has been rolled very = often in a very short period of time (regardless of whether the reason = for rolling it was a good one or not - it has happened). Also, = regardless of the size of the "bloat" I'm saying that in most cases the = clients will already have the certificates in question and this bloat = will cause them extra processing in managing their certificate caches = etc unnecessarily. The client should have a choice as to whether to = download the certificate or not. =20 I don't understand why you're so opposed to the "package" solution.=20 =20 Cheers, Sharon=20 -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com]=20 Sent: Friday, January 05, 2007 8:01 AM To: Sharon Boeyen; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =09 =09 We are only talking about an extra 16K at most. The download time is = the absolute most cases is negligible.=20 For those cases where this solution makes sense, the network bandwidth = issue is not a problem. =20 For the cases where this would be an issue, this solution would not be = used. =20 On the contrary, in some networks and scenarios, this will improve = performance. Especially in high latency networks with PKI based = peer-peer authentication where an extra retrieval cost way more = performance than the expanded CRL size. =20 Also, many clients are configured to pre-fetch CRL:s before they are = used, using idle time on the network at no extra cost. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Sent: den 4 januari 2007 17:36 To: Stefan Santesson; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: Certificates in CRLs =20 I still think wasted bandwidth is also an issue. Forcing the download = of 'fat' CRLs on clients when, in many cases, those clients already have = the certificates locally that caused the bloating of the CRL, is an = unnecessary waste. -----Original Message-----=20 From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson=20 Sent: Wednesday, January 03, 2007 9:58 AM=20 To: Russ Housley=20 Cc: ietf-pkix@imc.org=20 Subject: RE: Certificates in CRLs=20 =20 Russ,=20 In theory, the CA can put different pointers to different CRLs in each = certificate if some certificates are prime targets for frequent = checking. But I don't think that is a common scenario. My point is that in order to allow free selection of CRLs, you would = have to add capability to the CDP extension rather than to the CRL. I = don't think such effort is worth the trouble. I'm convinced that including certs in a CRL will only be made in = situations where it in the sum of all, helps increase efficiency and = where the extra bandwidth consumed is not an issue. I read the critique of this idea as not really be a bandwidth issue, = but that some implementers simply don't want to be faced with the = requirement to implement this feature. But I don't see that they have = to. A CRL with certs in a non-critical extension should work just as = well in current clients as any current CRL without certs. The extension = can simply be ignored. This is not a necessary feature, but a practical one offering = performance improvements in some environments at no loss of = interoperability. =20 Stefan Santesson=20 Senior Program Manager=20 Windows Security, Standards=20 =20 > -----Original Message-----=20 > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: den 21 december 2006 16:19=20 > To: Stefan Santesson=20 > Cc: ietf-pkix@imc.org=20 > Subject: RE: Certificates in CRLs=20 >=20 > Stefan:=20 >=20 > If the CA chooses to offer both, how can the RP determine which one = it=20 > will get? Does the CA post them in different LDAP attributes?=20 >=20 > Russ=20 >=20 > At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20 >=20 > >As with anything else, the relying party can get what the CA = offers.=20 > >=20 > >I don't think there is any realistic scenario where the CA has a=20 > >reason to offer CRLs both with and without certificates. To offer=20 > >this capability to RP is however not a matter for this protocol. It = > >would be a matter for the CRL referencing model, i.e. CDP and/or=20 > >directory schema.=20 > >=20 > >I don't think that extra complexity however is very useful.=20 > >=20 > >Stefan Santesson=20 > >Senior Program Manager=20 > >Windows Security, Standards=20 > >=20 > >=20 > > > -----Original Message-----=20 > > > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-=20 > > > pkix@mail.imc.org] On Behalf Of Denis Pinkas=20 > > > Sent: den 20 december 2006 17:05=20 > > > To: ietf-pkix@imc.org=20 > > > Subject: Re: Certificates in CRLs=20 > > >=20 > > >=20 > > >=20 > > > It is necessary to provide relying parties with the choice to = get=20 > > > :=20 > > >=20 > > > - CRLs "as usual", or=20 > > > - CRLs that carry that new extension.=20 > > >=20 > > > The current proposal does not allow for it.=20 > > >=20 > > > Until the draft is changed, I am against the addition of this = work=20 > item=20 > > > to the program of the PKIX WG.=20 > > >=20 > > > Denis=20 > > >=20 > > >=20 > = ______________________________________________________________________=20 > _=20 > > > _______=20 > > >=20 > > > >Since last IETF a new draft was posted:=20 > > > >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- = > 00.txt=20 > > > >=20 > > > >There is a request to add this draft to the PKIX work and I = would=20 > > > encourage to start the discussion about this decision in this=20 > thread.=20 > > > >=20 > > > >Stefan Santesson=20 > > > >Senior Program Manager=20 > > > >Windows Security, Standards=20 > > >=20 > > >=20 > > >=20 ------_=_NextPart_001_01C74FCA.09741062 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 = =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types"><HEAD><TITLE>= Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt = 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New = Roman","serif" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New = Roman","serif" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New = Roman","serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: = "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle18 { COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: = personal-reply } .MsoChpDefault { FONT-SIZE: 10pt; mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DSV vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I think that Sharon's proposal might have been = a good idea=20 in 1995 before the world got wedged on CRLs as the revocation mechanism. = We can=20 define a package but its too late to get it embedded in the rest of the=20 application infrastructure.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Given where we are Stefan's proposal is the = best one. It is=20 compatible with the existing infrastructure and solves a real issue.=20 </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>It is an option, clearly there are cases where = it would be=20 inappropriate but universal applicability has never been a requirement.=20 Otherwise we could have saved all the time spent on attribute=20 certificates.</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] <B>On Behalf Of </B>Sharon=20 Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 9:09 AM<BR><B>To:</B> = 'Stefan=20 Santesson'; Sharon Boeyen; Russ Housley<BR><B>Cc:</B>=20 ietf-pkix@imc.org<BR><B>Subject:</B> RE: Certificates in=20 CRLs<BR></FONT><BR></DIV> <DIV></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Stefan I really don't think you can state where this will or = will not=20 be used in the future. Naturally you know where you want to use it, = but=20 software only enables a facility and the customer decides when and how = to use=20 it. </FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Whether this scheme could possibly be useful in some cases is = not my=20 point. My point is that current deployments seem to be working fine = without it=20 and I don't want to see those interfered with just because some CA = they may=20 have cross certified with decided to put certificates inside their = CRLS. Back=20 to Denis' point - there is no need to impose this in the way you've = proposed.=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Earlier I (and others including Dave Kemp) suggested a = "package" that=20 includes the CRL, and the certificate in question as an 'extra' that a = CA=20 could publish in addition to a regular CRL. That "package could be = published=20 in a separate directory attribute and/or an HTTP accessible file. It = could be=20 pointed to from within the certificate just as the CRL currently = is. That=20 could be done either by extending the CRLDP or adding a = new pointer=20 extension or adding a new method to the AIA extension. That type of = approach=20 gives you what you want but does not in any way interfere with clients = who do=20 not want and do not need to retrieve that bloated=20 CRL. </FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Also, you haven't addressed the question about what = happens=20 when more than one certificate is needed. If a CRL includes more = than one=20 certificate (e.g. the CRL issuer did one or more key = rollovers then=20 CRL gets bloated a lot bigger than you suggested. I don't want to = debate=20 how often a key gets rolled over either however I have definitely seen = instances in real world deployments where a key has been rolled very = often in=20 a very short period of time (regardless of whether the reason for = rolling it=20 was a good one or not - it has happened). Also, regardless of the size = of the=20 "bloat" I'm saying that in most cases the clients will already have = the=20 certificates in question and this bloat will cause them extra = processing in=20 managing their certificate caches etc unnecessarily. The client should = have a=20 choice as to whether to download the certificate or = not.</FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff size=3D2>I=20 don't understand why you're so opposed to the "package"=20 solution. </FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Cheers,</FONT></SPAN></DIV> <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Sharon</FONT> </SPAN></DIV> <DIV></DIV> <DIV><FONT face=3DTahoma size=3D2>-----Original = Message-----<BR><B>From:</B>=20 Stefan Santesson [mailto:stefans@microsoft.com] <BR><B>Sent:</B> = Friday,=20 January 05, 2007 8:01 AM<BR><B>To:</B> Sharon Boeyen; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates in=20 CRLs<BR><BR></DIV></FONT> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DSection1> <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">We=20 are only talking about an extra 16K at most. The download time is = the=20 absolute most cases is negligible. <o:p></o:p></SPAN></A></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 those cases where this solution makes sense, the network bandwidth = issue is=20 not a problem.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">For=20 the cases where this would be an issue, this solution would not be=20 used.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">On=20 the contrary, in some networks and scenarios, this will improve = performance.=20 Especially in high latency networks with PKI based peer-peer = authentication=20 where an extra retrieval cost way more performance than the expanded = CRL=20 size.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'">Also,=20 many clients are configured to pre-fetch CRL:s before they are used, = using=20 idle time on the network at no extra cost.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: = 'Arial','sans-serif'">Stefan=20 Santesson</SPAN></B><SPAN lang=3DEN-GB=20 style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Senior=20 Program Manager</SPAN><SPAN lang=3DEN-GB=20 style=3D"COLOR: navy"><o:p></o:p></SPAN></P> <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20 style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: = 'Arial','sans-serif'">Windows=20 Security, Standards</SPAN></B><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: = 'Calibri','sans-serif'"><o:p> </o:p></SPAN></P> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: = medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue = 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none"> <DIV> <DIV=20 style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: = #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: = medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = 'Tahoma','sans-serif'">=20 Sharon Boeyen [mailto:sharon.boeyen@entrust.com] <BR><B>Sent:</B> = den 4=20 januari 2007 17:36<BR><B>To:</B> Stefan Santesson; Russ=20 Housley<BR><B>Cc:</B> ietf-pkix@imc.org<BR><B>Subject:</B> RE: = Certificates=20 in CRLs<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">I still think wasted bandwidth is = also an=20 issue. Forcing the download of 'fat' CRLs on clients when, in many = cases,=20 those clients already have the certificates locally that caused the = bloating=20 of the CRL, is an unnecessary waste.</SPAN><o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">-----Original Message-----</SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">From: owner-ietf-pkix@mail.imc.org [<A=20 = href=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.= imc.org</A>]=20 On Behalf Of Stefan Santesson</SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">Sent:=20 Wednesday, January 03, 2007 9:58 AM</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">Cc: ietf-pkix@imc.org</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in CRLs</SPAN>=20 <o:p></o:p></P> <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: = 12pt"><o:p> </o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">Russ,</SPAN> <o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">In theory, the CA can put = different=20 pointers to different CRLs in each certificate if some certificates = are=20 prime targets for frequent checking. But I don't think that is a = common=20 scenario.</SPAN><o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">My point is that in order to = allow free=20 selection of CRLs, you would have to add capability to the CDP = extension=20 rather than to the CRL. I don't think such effort is worth the=20 trouble.</SPAN><o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">I'm convinced that including = certs in a CRL=20 will only be made in situations where it in the sum of all, helps = increase=20 efficiency and where the extra bandwidth consumed is not an=20 issue.</SPAN><o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">I read the critique of this idea = as not=20 really be a bandwidth issue, but that some implementers simply don't = want to=20 be faced with the requirement to implement this feature. But I don't = see=20 that they have to. A CRL with certs in a non-critical extension = should work=20 just as well in current clients as any current CRL without certs. = The=20 extension can simply be ignored.</SPAN><o:p></o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">This is not a necessary feature, = but a=20 practical one offering performance improvements in some environments = at no=20 loss of interoperability.</SPAN><o:p></o:p></P> <P class=3DMsoNormal><o:p> </o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">Stefan Santesson</SPAN> <BR><SPAN = style=3D"FONT-SIZE: 10pt">Senior Program Manager</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN> = <o:p></o:p></P> <P class=3DMsoNormal><o:p> </o:p></P> <P><SPAN style=3D"FONT-SIZE: 10pt">> -----Original = Message-----</SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> From: Russ Housley [<A=20 = href=3D"mailto:housley@vigilsec.com">mailto:housley@vigilsec.com</A>]</SP= AN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> Sent: den 21 december 2006=20 16:19</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> To: Stefan=20 Santesson</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> Cc:=20 ietf-pkix@imc.org</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> = Subject: RE:=20 Certificates in CRLs</SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> Stefan:</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">></SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 If the CA chooses to offer both, how can the RP determine which one = it=20 </SPAN><BR><SPAN style=3D"FONT-SIZE: 10pt">> will get? Does = the CA=20 post them in different LDAP attributes?</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">></SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 Russ</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">></SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> At 08:00 AM 12/21/2006, Stefan = Santesson=20 wrote:</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">></SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >As with anything else, the = relying party=20 can get what the CA offers.</SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 ></SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> >I don't = think there=20 is any realistic scenario where the CA has a </SPAN><BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >reason to offer CRLs both with = and without=20 certificates. To offer </SPAN><BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 >this capability to RP is however not a matter for this protocol. = It=20 </SPAN><BR><SPAN style=3D"FONT-SIZE: 10pt">> >would be a = matter for the=20 CRL referencing model, i.e. CDP and/or </SPAN><BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >directory schema.</SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >I don't think that extra = complexity however=20 is very useful.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> = ></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> >Stefan Santesson</SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >Senior Program Manager</SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> >Windows Security, = Standards</SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > -----Original = Message-----</SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > From:=20 owner-ietf-pkix@mail.imc.org [<A=20 href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > pkix@mail.imc.org] On = Behalf Of Denis=20 Pinkas</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > = Sent: den 20=20 december 2006 17:05</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> = > >=20 To: ietf-pkix@imc.org</SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">> >=20 > Subject: Re: Certificates in CRLs</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > It is necessary to provide = relying=20 parties with the choice to get </SPAN><BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 > > :</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > = ></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > - = CRLs "as=20 usual", or</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> >=20 > - CRLs that carry that new extension.</SPAN> = <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > The current proposal does = not allow=20 for it.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > = ></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > Until the draft = is changed,=20 I am against the addition of this work</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> item</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > to the program of the PKIX = WG.</SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > Denis</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">>=20 = ______________________________________________________________________</S= PAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> _</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > _______</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > >Since last IETF a new = draft was=20 posted:</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > = ><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" = = target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-= vccrl-</A></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> 00.txt</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > ></SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > >There is a request to = add this=20 draft to the PKIX work and I would</SPAN> <BR><SPAN=20 style=3D"FONT-SIZE: 10pt">> > > encourage to start the = discussion=20 about this decision in this</SPAN> <BR><SPAN style=3D"FONT-SIZE: = 10pt">>=20 thread.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > = ></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > >Stefan = Santesson</SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > >Senior = Program=20 Manager</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > > = >Windows=20 Security, Standards</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> = >=20 ></SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">> > = ></SPAN>=20 <BR><SPAN style=3D"FONT-SIZE: 10pt">> > ></SPAN>=20 <o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C74FCA.09741062-- 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 l1DMBFio077830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 15:11:16 -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 l1DMBFaZ077829; Tue, 13 Feb 2007 15:11: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 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 l1DMBDa5077812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@vpnc.org>; Tue, 13 Feb 2007 15:11:15 -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.0.685.24; Tue, 13 Feb 2007 22:11:12 +0000 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; Tue, 13 Feb 2007 22:11:11 +0000 From: Stefan Santesson <stefans@microsoft.com> To: David Simonetti <dsimonetti@jasi.com>, Russ Housley <housley@vigilsec.com> CC: "ietf-pkix@vpnc.org" <ietf-pkix@vpnc.org> Date: Tue, 13 Feb 2007 22:11:10 +0000 Subject: RE: URN in subjectAltName Thread-Topic: URN in subjectAltName Thread-Index: AcdFaW+L1RYPadKTS7idh4cGacGjkwKUPNow Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01DA92454@EA-EXMSG-C307.europe.corp.microsoft.com> References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <p0624087ec1e32ac2e8f9@[10.20.30.108]> <13947.199.173.224.25.1170167473.squirrel@my.jasi.com> <7.0.0.16.2.20070130195847.04bac5b8@vigilsec.com> <2567.199.173.224.20.1170265879.squirrel@my.jasi.com> In-Reply-To: <2567.199.173.224.20.1170265879.squirrel@my.jasi.com> 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 l1DMBFa4077824 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> For clarification: The UPN (Universal Principal Name) is a Microsoft defined name form, used to identify users in Active Directory in the form user@domain Microsoft has defined an otherName subjAltName to store UPNs in certificates. The OID for this name form is "1.3.6.1.4.1.311.20.2.3" The blob is decoded as a UTF-8 string. As Dave noted, this has nothing to do with URNs. 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 David Simonetti > Sent: den 31 januari 2007 09:51 > To: Russ Housley > Cc: ietf-pkix@vpnc.org > Subject: Re: URN in subjectAltName > > > Russ, > > We're using Active Directory UPNs, not URNs. I was wondering why this > was > a big deal. > > Dave S. > > > > > David: > > > > Can you document what you are doing so that everyone that needs a URN > > can do it the same way? > > > > Russ > > > > > > At 09:31 AM 1/30/2007, David Simonetti wrote: > >>A US Federal agency which I support is planning on using the > otherName > >>field to convey the URN. This agency is issuing more than 80,000 > >>certificates. I think use of URN more be more prevelant with those > >>implementing Active Directory than is realized. > >> > >>I believe defining URN via otherName is sufficient. We're conveying > it > >> as > >>a UTF8String. > >> > >>Dave S. > >> > >> > > >> > At 2:16 AM -0500 1/28/07, Russ Housley wrote: > >> >>At the time that RFC 2459 was written, URLs were the only things > >> >>mature enough to include here. No one asked this question during > >> >>the update to RFC 2459, which resulted in RFC 3280. > >> >> > >> >>Going forward, I see two possible ways to go forward: > >> >> > >> >>1) Revisit the uri choice, and see if people think URNs ought to > be > >> >>permitted. One obvious question is to determine whether existing > >> >>implementations would fail badly if a URN was received here. > >> > > >> > This seems like overkill given the low usage of URNs as > identifiers > >> > that are associated with public keys. > >> > > >> >>2) Define a way to carry URNs in an other name. > >> > > >> > Anders and I have suggested two legal ways to do this already. > >> > > >> > --Paul Hoffman, Director > >> > --VPN Consortium > >> > > >> > > >> > >> > >>-- > >>Regards, > >>David Simonetti > >>Jacob & Sundstrom, Inc. > >>410-356-1067 > > > > > > > -- > Regards, > David Simonetti > Jacob & Sundstrom, Inc. > 410-356-1067 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 l1CN2Iqp077227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Feb 2007 16:02: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 l1CN2IE5077226; Mon, 12 Feb 2007 16:02: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 katz.cesnet.cz (katz.cesnet.cz [195.113.134.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1CN2Gur077219 for <ietf-pkix@vpnc.org>; Mon, 12 Feb 2007 16:02:17 -0700 (MST) (envelope-from sova+pkix@cesnet.cz) Received: from [192.168.254.234] (adsl-pha180-136-207-85.bluetone.cz [85.207.136.180]) by katz.cesnet.cz (Postfix) with ESMTP id 4847E4FD73; Tue, 13 Feb 2007 00:02:15 +0100 (CET) Message-ID: <45D0F1F5.8060301@cesnet.cz> Date: Tue, 13 Feb 2007 00:02:13 +0100 From: Milan Sova <sova+pkix@cesnet.cz> User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: ietf-pkix@vpnc.org Subject: Re: URN in subjectAltName References: <45B94A66.3030107@cesnet.cz> <7.0.0.16.2.20070128021208.049264f8@vigilsec.com> <45BE94CC.3020002@cesnet.cz> In-Reply-To: <45BE94CC.3020002@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> On 30.01.2007 01:43, Milan Sova wrote: > Russ Housley wrote: > >> Going forward, I see two possible ways to go forward: >> >> 1) Revisit the uri choice, and see if people think URNs ought to be >> permitted. One obvious question is to determine whether existing >> implementations would fail badly if a URN was received here. >> >> 2) Define a way to carry URNs in an other name. >> > > I would very much prefer 1). The URI seems to be the natural place for > URNs. I don't expect any reasonable implementations to fail, but let's > find out. > BTW X.509 (08/2005) still uses RFC 1630 (mentioning URNs) as the > reference for the uniformResourceIdentifier. > As the group does not seem to have a strong opinion of the choices I propose to include the following text just after the URI part of the section 4.2.1.6 Subject Alternative Name: "When the subjectAltName extension contains a URN, the name MUST be stored in the uniformResourceIdentifier (IA5String). The name MUST follow the URN syntax and encoding rules specified in [RFC 2141]." Comments? -- Milan Sova Received: from matas.de (86-122-181-57.rdsnet.ro [86.122.181.57] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l1CGAdRq042431 for <ietf-pkix-archive@imc.org>; Mon, 12 Feb 2007 09:10:40 -0700 (MST) (envelope-from korinicambell@matas.de) Message-ID: <01c74ec0$6518a5f0$39b57a56@valica> Reply-To: "Galen Darden" <korinicambell@matas.de> From: "Galen Darden" <korinicambell@matas.de> To: "Rosemonde Elkin" <ietf-pkix-archive@imc.org> Subject: new cynicis Date: Mon, 12 Feb 2007 18:11:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Hi, Economize 50% on Vaiagra Vaulium Ciualis http://www.tetrx-com Replace "-" with "." in the above link. his parents! Oh bless him, I never knew! Harry had had enough. Trusting to the fact that Hagrid wouldnt miss him, with the attractions of four dragons and Madame Maxime to occupy Received: from net143-223.mclink.it (net143-223.mclink.it [195.110.143.223]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1C2jVgZ077063 for <ietf-pkix-archive@imc.org>; Sun, 11 Feb 2007 19:45:38 -0700 (MST) (envelope-from MySpace@francogenie.com) Received: from PBBIFXSZ (unknown [173.197.10.190]) by francogenie.com with ESMTP id 13A043A9C560 for <ietf-pkix-archive@imc.org>; Mon, 12 Feb 2007 03:45:57 +0100 (GMT) Message-ID: <000801c74e4f$d9e33ec0$00000000@pc8> From: "Finerman infoRipped" <MySpace@francogenie.com> To: ietf-pkix-archive@imc.org Subject: hopes DD Spoken Date: Mon, 12 Feb 2007 03:45:26 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C74E58.3BA535C0" 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 ------=_NextPart_000_0004_01C74E58.3BA535C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C74E58.3BA535C0" ------=_NextPart_001_0005_01C74E58.3BA535C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Retelling history skillfully infuses authentic, thrusts. Set sat = medialos cashin. Oh, mutal asposted irbrent concerned. Verso outros nacionais xoops = incluir votados, avisos. Indicative hanasiana collision detection, boss! Ebusiness, poop = splintered mind. Wtf point obie idiots, bizarre surrounded agree knows. = London re, united kingdom note many morethanks. Fab, fbb fcb fdb aaab, abab acab. Xrash narket jarket, harket cfash. = Spoken featuresb end credits. Next studios, jim ebooks profitfind americans, ipods ebook. Burns = docherty, hanlon ballard kai, stephen harrison. Common books, pearsons guide zlog. Disasters hell fix failproof follow, sending. Thinks in prison pretending. Minds task nonfiction beehive, beginners. = Roughly translates adds, covered december digging, memos cbss. Protocol implements mftp protocols. Chic aurora, tester herside geekchic? Galaxy future evaluated today. Tian ambassador, yuzhen jan questions. Educated learned lesson napoleons = autumn moscowquot. ------=_NextPart_001_0005_01C74E58.3BA535C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://domainsymbol.com><IMG = alt=3D""=20 hspace=3D0 src=3D"cid:000301c74e4f$d9e0cdc0$00000000@pc8" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Retelling history skillfully infuses = authentic,=20 thrusts. Set sat medialos cashin.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Oh, mutal asposted irbrent concerned. = Verso outros=20 nacionais xoops incluir votados, avisos.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Indicative hanasiana collision = detection, boss!=20 Ebusiness, poop splintered mind. Wtf point obie idiots, bizarre = surrounded agree=20 knows. London re, united kingdom note many morethanks.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Fab, fbb fcb fdb aaab, abab acab. Xrash = narket=20 jarket, harket cfash. Spoken featuresb end credits.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Next studios, jim ebooks profitfind = americans,=20 ipods ebook. Burns docherty, hanlon ballard kai, stephen = harrison.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Common books, pearsons guide = zlog.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Disasters hell fix failproof follow, = sending.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Thinks in prison pretending. Minds task = nonfiction=20 beehive, beginners. Roughly translates adds, covered december digging, = memos cbss.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Protocol implements mftp = protocols.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Chic aurora, tester herside = geekchic?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Galaxy future evaluated = today.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Tian ambassador, yuzhen jan questions. = Educated=20 learned lesson napoleons autumn moscowquot.</FONT></DIV></BODY></HTML> ------=_NextPart_001_0005_01C74E58.3BA535C0-- ------=_NextPart_000_0004_01C74E58.3BA535C0 Content-Type: image/gif; name="Hanlon.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c74e4f$d9e0cdc0$00000000@pc8> R0lGODlhiAFcAYcJAAALA4ILAASOBYWCAAAAh34AhwaAfb65xMviypy86kgRB10lAn4TAq4YALgq AOYcBQg1AiE7AkI4AFxMAI4xAJw9C8pOAOBOAABUABtZADRRAW5nBY1VDaZqAMZtANNiAgeICiOO ADuMBmGIAIx+AJtyALx6AOp2AQWlCBycADqVAF2lDnWrAJ2WBLiqCOWRAAa+BSLLC0nGAGW8Bne+ C6W8DLu3C+jBAADkBRncDEjWBmnTAIDVAKXeB7rVBuDWBAIANBoANEwHMlYBPnQARpUAN7IJOe4A OwkrNBEUPUAfN1cZSnsqOqoiNsoiQN0lMwAyOiBDPE4xNl9NTIQ4Q6FEPbszO99GNwBtPBNSOkdi NmRkOH9tAqFsNsBjQtZiOA16TRSFNTFzOFF+Q3h/P5eHM86DOeiINAWSOhKWPUqrMleqQnegTpeV PLGtQ9+pQQC7Pi6xQzG/Olu8P4e3O6TCN83OQOm3SADXSBbmSjLuTFfYOnXnTqjRSL3XQdHaSQ0A ehwAizsAflUNgHQAjZIKd8cAhdIAhAAchywtdz0gem4Vg4gWiZUWdL8de+IhcgBKfyI1jjE0gVw8 enc9hqpEdcY3eORMggRZix9RgDxcjlpTcoJhd6VRgMxehtZjiwR0gh6Ai0qGd1h9g4eNe5p0hruE f9x/fAmlhB+qd06liVSZdoSSia2ei8qpdeyldADOdyvOhTTBf1m/io65jpa7eMK1dunGdwDehhzr fzPtfmrncYPWe5XliszUf9jZegAAvSIAwUELxF4AxoEHwpEAy7YOv9gAvgAdthQoskstu1oow3sT saUXycYgyu0jvAA+yR02yEc4t1kzyXlDtK00wMtOxutKzQBmsiReuzJUu2lXxYtZyKlbzrRgv9Rp swt+sROMsUJ7vmRytXN7s5eLsc6Ktut0yAahuyGnxDWTx1mjtHSTxZOZwb+ZvtycxQDMyyS4tTy6 vlfBwoS/xKS/s/n//pqgq3+Bg/8ADgv7Cfb/AAcA8/AJ/wD8///5+yH5BACsvWUALAAAAACIAVwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3OjQnsePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHQqSo9GjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYDsS HUu2rNmzaNOWDcu2rdu3cOPKnUu3rt27ePPq3cv3odq/gAMLHky4sOHDiBMrXsy4sePHkCPb7Eu5 suXLDCVr3sy5s+fPoEOLHk26tOnTqFOrXs3aJebXsGPnbU27tu3buHPrFrxRgG/f/34LIPg7uPDj yI8bV068+EDnz4E3Tw6cuUDk04dH1769IHTZ4MNP/78uvPt48wadlycP/fvyhO7fm2+/Xj569uLz i1df3/33+PgFuJx09g3InXcEovefdNYt6KB+EMbG33r+JQigffRRaGF9CB4YYHzFYVegdQVGaOJV OP3mkYq+rdgiSCp+FKNIM9bY4osz2nOjACTl6CKPOr4I44484ihkkEjKeORuTPrE0YTvVXggddUx uOFwIRKYpYcCzpcgfltiWCV3F55o5lMpGgkkkSHl6KOSx7VpZJBA0mknjUve+SaLc9pYpJBvNimo YTEWGueQdd6J55+J6nkoncKNtKeaizoa6Y+XKjropjc9aSWZHI74pZdTaqkhqFyC+Gl6Y2636oej nv8pa1Nprglopj8i2qOadfpJaa5yNqqom79CamuvxXKqbGCGJoqrpoEO2yyitspZabC6SuusodZq uuy3Z8VJ7JLjJgctn9uymS2cwR6J3LqQeovuo+DWa++9+Oar7778tjTrvwAHLPDABJvY78EIJ6zw wgw37PC3BUcs8WuQbWIxZxZv8vDGNmUclMckBSDyyAGENDJIJw8FMsgvsWyPyxyjplHGTtGM0MgC kUwQzv/wDJXNNk8U9D9DT1xwxxcDBTPKIn+UskcpPy3U0jBRHbO+Vmec9Edas9y1xh5Zbc/TUo9N csknfa2x1iB1HZLaYW/tNtdzw+0123F/ffVtVHv/fDfYK4P9ctJik920yWWTxPbihF/8d96QDw74 5HRPLrjkkAfe+OV7KzazxQYFTbPooIdeetE7i5yz6gbpzBDQp4NO+iZEl1477bfnvhDsuAs0uu2/ 94660ROjPrvuyKvtu+2tnx3AzT4rxPvytB9/fO7D36419QQFP5D33BMvPvLfq1098LHjPj30z0ef Ouu7p8+9+ecLL//w6w8NPvbo9z5+8cwLX0Gs1z8BNu95PYPfQJz3Ovnxz3/ls5/6ZBfA5DlwfgW8 3v8oVpOl9U1ujgOh5UoSNamRzGxoK4nmMre1tomQhZzDXORc5rcXPq5zjPkcBAV4P/Btj3wF8Znr /xKIQPeZboJI5GESf5i/+lEviRHEIBSBuEGCmS+C+vvaE5lYwQUqUGfRM2L3HDi7LHZNiWX8ofac uMUoGrCKcGxI9uJIx4ChZXM4zGPD9KbHPvrxj4A0TB0HSUg0BfKQiEykIhfJyEaupZCQjCRHHEnJ SlrykmaRpCY3SRFMevKToAzlSzhJylKa8pSoTKUqV8nKVrrylbCMpSxnScta2vKWuFSlKHdJmlz6 Ula8DKYwh+nIXxrTYMRMpjKXycxmOhMmx4ymNKdJTeLlo5rYVAgBtkmAf3BzINsEJ0G+6U1ygtOc 6ORmN9XZTYNcUyD5iGc8CyLPef5DntmcZTvHOf/Ofe5TIO38Jz8L4k+AHkSgA6nnPRtyzXcuNJ8b tAkBRjJRj1T0oiHBKEUzytGKclQk+bBHSD0yUpOMtKQlfeamNIJQb4rTpTB9aTkRSk6BrlOdMiVI QxOKT4Q4tKcQdWVLCwpTmxqkpS416lCPSgCgJvQgP31qUMcn0Y3ag50T9ahFRaJVkGS1o1YdSUhT KlKxfgSlKu1cV6+61Y981atcJYlG2UrXj5p1rGclaV73Wta07k2dV91mXdkKWG4GVrBeNaxbETtY t4pVnmeNJ1/JClm/WlYmZL1sws7k0Kl69rOgDa1oR8tQ0v6yoOkk6Ddx2k+mhnOmNn2tQjoLT6j/ 2rOetDVtIYn6T9nG1KDABShNxUnUmCIVnkC1p06lylzdArMmHp2rRtcaXcc2trrVvS5J8JrXzKKV r5pd2FvrOt24tpWuXcWuddO73b721bvgzWx4abORdco0oMBdrTmLqtrXsva3vyVnT3FLT+bm1rlm usl4L8rOwb41ug227nolfN67ggS+es3wfHHDkd4Gl78G5e1AP2zc+y5kpwaurYoPjOAT4QTC4yWv YbUaYxrbVcZrvXBlJxvZ7274xyeRL5CHPBMhE3lZLU6yVI7M5IcZuclNYilxZetb2Fq5ta71J5Vx yk6outOnOlWukuMo4nOOOLi9HS5BX7pU2ypX/8w8TfGYIVTVtmZ3rhK+8421m+Mcc1evQvbxk6Hc mfqWOL8kPjSI+4lffnY50QuN6kO/rOJJz7mK9kUzomd65U0fFMCZXrNqB6xQSk+axZfmIHTJa9EG 21i6EY4re/tckj+7NySCJrRpOjxQD5e4zJBedKNF7eXOSrrSx071BrUcauOu1tFn/i+nId3SUsv5 nm+Gs7JTjepte/sh3f62uMdNR12bGzWDPnfDOqxfLee0pvs1NYHd+c55k7uVahZuThc9W3x2m8Xh vrcdV21e9FbY4EF2r5EDrW4/0trOB4dxrRW+4x5TtuH2kvJR2UzifE/bqZVGdnMFbrQ6fxSr2v/d M65vzfJcY7xehha1h41K7GKfesVSDTjJBy7RGQv21T7PqmIfK1mSFp3iPn65ZdOtdCYzvelQj7rU p47ku+h857QsLpUZHeBymtnU2D5wcrWNdYGZHMIURvhWGctYiyt85YAGL9U5nJEyD9vTSc27QFFc 4OXWNtllJ2WoG03zmeu9wLkV+21HHniAKZjVaoe4Y8u72IrL97v1nLvDHuzqk8OV8is/aXs1THrN Kyy7a/f85FVeVltnOOlPN/2uY951Lvu3pjUPe71L/dNsN965V//9/zQTe9lzSvjIT77yJxb85X/l xUH/OXYLO/TqD53V1s9o9LWPkpRW3OiV/b7/8YNC+46jlthaRwiwvb7v4rI/IQoFPG0B73yomDzt D0455HN8XulKHq79d3AXxnKld3GlN36LQV2KlX+ABXmRJ2t59n8RKIGhh2veFX5yh4BOUnfC1Wz8 5YHSdncbl34g1m6+FlvtBHKWhniMV39OcX8xZnAxiGd4BoF21nmrh2PXB1ItN3FJp4EJmIN5NoMT 2Fg3RoMBqGdpV4GYp2F/VnxA+BfUN2OLdVg/93lst4M45mCLdYVCaITgh1JHJ4ZkGIW7BIVmSExo mIZE4YJu+IagJRlryIa1oXHO9nV3qGnwF2aKt3sqCIf/o3XuhmYk6GZ8N39P1XyAeBmPp4T5/6d2 MTiAlwd3rUeHB2NjMih5mNheGGaBJyV+ljgavMZxH4h3NPVaTiV2I6eIixgwmYZVpQiLeTdbDwVw q9iKcHR+xGVmhhdsf7eCtZiILYiLqjYT6iWEXph6AhiGYSh64NdjoSgzdsGKxOhikTGH0ZiN2igU 1diNG0GN3miN0GV9aNdqVZhwA0h00LiN9kJd61WOgRVk4TeJcXeA7Agadthxh0d4e4iItEh/4ViM xohYs0ZYCMd/lZiOj7WO93gvREh5NahYlpdwP9iQn3EUIFiCsFVlLBhyNueRASmQBKeEX4iQCXlr zniS2GiRqNGArYZ6yriMIrVjNMmQoMiSnP8xF+AYkvrhGCuJk0AZlCnBk0SJETtZlAWzZbwIbzel X/vWd8jVhzx1lEi5FdB3jvHoiNwnkzMpWT+IVhUplIgRc/hlX4OHd7OIVHzndykGkFUpF4+XiV/l kgxGkA/YXTwIUkUXlmLZkpoYk6AHcTSGWBOZl+91k31JGCzVZfxodzIHYB1pix5JlW+5F724i5tG c+9nc4kncsNYmflxmSHGlBuZh/R2W7w3lXEGmrJEmawJS675mrI5m7Qpm7FZm2zRc1XoauRohV2I lYbZler4jImZGIvJi+hHioq2mXx4iFDpnLiZm6s2l/pHkpAogK5njwVYnGPJgWZ5ZSR4gsr/KYxh 5lP+GJ2x0Zj9JZ7KKYLbpIKo5pboWRnq2Wv2SYqy2JGfWW/z2Rb3Z5AAuH8TuImS+HbvhZfc6Tkc 6GhcxqBNyWxd15yqiWyo+Yf9GUm3eaGblKEamhUJKkodakys8ZMfuhm82XbxaI4qmqK+mVgwGZw3 SYZHV6KRgXqDiZVZWITW6YlPqJdmRaOSYaMTZpCPiIQFaWHBmYEkCqRnIaR/SZ0H+XlghaQKSYkZ yKQbaIchmJlcWntrNlRNJWbxCZUh+oJxCYk4iFEo92pTyonauZ1YWqMDKqV0Cphz6oME6H1VGqeO AZM1xmdYiKLk2FWZ15V7aZN8OhT5waFl/5oUI5qokBqpknp8lMGojWoXkEAQkLCpm/oPmSoQmcqp nsqpoSqqmvqptMiWIBmVUUl2l+oWqOqpBYGqnxqrtDoQthqrhohc5SlvZPqqTGETkAASw0qsH1Gs xeoRybqsx6qseLqn9IiSk9oYyWoPpNqszNqszrqt1sqtPGiAVwp708oY1Vqtzpqt3Hqt2mqunEqc cKqXYziuQKERtmoQoYqrmoqvsgqqpKqr+nmeYLaqwKoUwmqsIlGuBtut24qwz9qDcseX8koY19qv 2mqtm1qxCMuw8FqG7iqGexqx4LKkIDuvlTqwdjGygGSyKruyS4GyLvuyQ8mysASzNFuzRf8hszib sxVhs52jsz77sw3Bs3sDtLoktDFDtEibtEp7SkbbtE77tPiytKUEtQ4jtaREtetmtVqrsljLMFsb TfwQtmErEGNrEGLLDwVxtmj7D2VLtmtrtm87EGOrtmLLtmpLEHTbtnibt3tbt3J7twtxtmnrt3+r t3oLt4BbuHGbuG5LuI1ruHHrtnYLt3abt2vbtpgbuQlmE2L7EWFrD587EqHrEZ1LuvwAuqdruiUx up57uqzburCruijxuq2buqibuqNLuyARurmLu7bLu757EqxburJbvMD7u76LvMEbEp9LvMX7vMaL vFGmEYcruQcBudd7uZq7t5RbvZNrvd//G7jbG77Wm7kPMbeLq73lO75/O7jcC77um73xW73oi73v e7/m+y+ca7vMy7+7K72i67r+KxK027wDjLqxi8Cze8C6a8AJvMAKLLvAG8GrO8C9+8AYnMEIXMAC HMGvy8EJrLsII8IkDMAE7LwkYbkGTLcerLxqG8As3MAdDL0m4cCxO8Ei/L8n/MAgHMA+DMI2TMFC 3MIabBvUO77eG75JLLji273bW7b228SU68TwK8VRLLj1i8Sam7+K277yS8XuC8Xqe79erMTsS2c1 UcIpbML9O8Rt3MYyjMI5rMM7vMMvrBIXXMRnS8NDnMd1rMZ2bMEzvMH+28NE7DCAXMdu/6zAcwzE DLy8fKzIdAzHkFzD/Du8j8zImfzGi0zIa/zDgkzBezzJIczGDCPDn6zBfizJqovK0ZsSiSzBpszK mPzHlYzBtZzKsazJgfy/H3zAf0S8QczJtwu7uczKnizJEwzBMFy7z5vDrhzNt/zMx+zHwpy8zkzN 0CvHofzKTGIUgMu3lRu54UzOT7zFaGu55Du56jzFCMG4h7vEdNvF7jzO7zzPffu2jPu45uy4/KzP 6By/+AvQXwusKnzQCJ3QCr3QDN3QDv3QEB3REj3RFF3R+FzQ3ti1Gk2jGN3RHbrRIM2dHj3S8xnS Jn3SKJ3SKr3SI0HSdcTSMB2KLl1uMXoNLjMdRzVt0zddRTkNMTv901XZ00I91ETtGkBNVUUtKEeN 1En9zUv91Bnd1E4N1RIj1VNN1Vid1Vp9EVbd1V791WAtils9MGFd1kM21mitfGa91vOV1jzH1qnh 1o4H16oh1/pL13jtTHY9K3nd18u014B9b3492MMUEAA7 ------=_NextPart_000_0004_01C74E58.3BA535C0-- Received: from host159-120-static.107-82-b.business.telecomitalia.it (host159-120-static.107-82-b.business.telecomitalia.it [82.107.120.159]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1A02i0P086063 for <ietf-pkix-archive@imc.org>; Fri, 9 Feb 2007 17:02:46 -0700 (MST) (envelope-from sambujanet@everyonesworld.org) Received: from EEEMWPO (unknown [161.142.132.122]) by everyonesworld.org with ESMTP id A77AFC3AA4A1 for <ietf-pkix-archive@imc.org>; Sat, 10 Feb 2007 01:04:57 +0100 (GMT) Message-ID: <001001c74ca7$044b94a0$00000000@Server> From: "jccom jcmeihecom" <sambujanet@everyonesworld.org> To: ietf-pkix-archive@imc.org Subject: Funny Video Date: Sat, 10 Feb 2007 01:04:21 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C74CAF.660FFCA0" 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 ------=_NextPart_000_000C_01C74CAF.660FFCA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C74CAF.660FFCA0" ------=_NextPart_001_000D_01C74CAF.660FFCA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stemmynet stfilecom, sugbrcom sumobucom suncom suyyafnet, sxsitecom = sysdoxnet sywhkjcom. Hzdlongcom hzsissicom itouchcom iamvoipcom ibtradecom, icepawncom = icomunecom icomunenet. Stagabcom stemmynet stfilecom, sugbrcom = sumobucom, suncom, suyyafnet sxsitecom. Mharcomcom mikeccom miniepscom minmarucom mintimscom miraxusnet. = Xnwgacom, xnwganet xnfacom xngacom xnganet. Xpczonecom xtracercom, xinjiancom xpforumcom! Ventuxcom vervelcom = veryadcom vipixcom? Different types edk exchange. Whcxcom, whbdkcom whebacom, wisupcom. = Jaedolcom janedicom janfeicom jasamocom. Dayonecom daysixcom daytwocom dazcopecom ddbankcom deginercom = delanoocom. Sapourcom saquescom sarpetnet sayhopcom sbkatlcom. Dharazicom diausacom = dialadcom, dialyescom dimercscom dinsonacom. Ffc state dynamicvar divt = divs barnes noblecom dvds music. Photos docuhellip pro empowers poplar protocols. Artteecom aryaefcom asakimcom ashalacom ashbalnet. ------=_NextPart_001_000D_01C74CAF.660FFCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://mattingkoot.com/><IMG = alt=3D""=20 hspace=3D0 src=3D"cid:000b01c74ca7$044b94a0$00000000@Server" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Stemmynet stfilecom, sugbrcom sumobucom = suncom=20 suyyafnet, sxsitecom sysdoxnet sywhkjcom.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Hzdlongcom hzsissicom itouchcom = iamvoipcom=20 ibtradecom, icepawncom icomunecom icomunenet. Stagabcom stemmynet = stfilecom,=20 sugbrcom sumobucom, suncom, suyyafnet sxsitecom.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Mharcomcom mikeccom miniepscom = minmarucom=20 mintimscom miraxusnet. Xnwgacom, xnwganet xnfacom xngacom = xnganet.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Xpczonecom xtracercom, xinjiancom = xpforumcom!=20 Ventuxcom vervelcom veryadcom vipixcom?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Different types edk exchange. Whcxcom, = whbdkcom=20 whebacom, wisupcom. Jaedolcom janedicom janfeicom = jasamocom.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Dayonecom daysixcom daytwocom = dazcopecom ddbankcom=20 deginercom delanoocom.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Sapourcom saquescom sarpetnet sayhopcom = sbkatlcom.=20 Dharazicom diausacom dialadcom, dialyescom dimercscom dinsonacom. Ffc = state=20 dynamicvar divt divs barnes noblecom dvds music.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Photos docuhellip pro empowers poplar = protocols.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Artteecom aryaefcom asakimcom ashalacom = ashbalnet.</FONT></DIV></BODY></HTML> ------=_NextPart_001_000D_01C74CAF.660FFCA0-- ------=_NextPart_000_000C_01C74CAF.660FFCA0 Content-Type: image/gif; name="helpcuecom.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c74ca7$044b94a0$00000000@Server> R0lGODlhaAFgAYcJAAkHC4MAAAB8AIaMAAoAdocLcgqAjsjJt8XNu6LX7jgoBFsTAIstB6cTAMAp ANMsAAM3ARxKAEpNDGdMDIhIDps7BL9EAN9FDQBtAB5XA0ZsBlFSDoNcAahgCMdXDupcAgByACZ5 DjaEAGKAAIWLAKl7BsmLAOeAAAamARaWAEKfAFibAISnAK6RDMmuAOGdAADNAhrFAEDKCGrJDoe3 AKrFAMrLAO3IAADdACLeBzjSAGDgAH7gAKPpAM7pBt3mAAAARRgASk4OR1kASHwATJwAQc4AMeoL QAwtNxIqTkcuO2UVRn8lMqokQs4YONQbTQA+SBUyQjVINFtCOIRFSqo4Pc0yTeg3RgBSRSlVNzFf O2luNYFkAJJeTsxROOZuQAB9MiKFPUiETVaFQIqFTaSFQc6BRNZzOgquShWhSkeZTW6pPYOrN5Wo ObydSdqnSgLLQh7ENjOyOFnORHS7OprMRsy1TeCxMgveTSjXPEThS1fpQ3PoPq7gQcPiOO3dRwAA eRMAhEYDfF8Aco0Dfa4JeLMAh9MBegAYjBQrjTwhg1IZd4Qjjp0ajb4ngtweewBOdChBdUpEiGRM hIc2c6A4dcAzfOpCgQZZjCFdfkNljGNtfoRViq1ahbxldu1Rfwl4jix7hTh8fmB3eX11f62LhbGG fdZ0gQWVcSubcjiSfVeug4agjaeggsWretqUjgDMjh+8fzu3gGG4jnHMfKfBeLPEi+nDiQXVfiDg ejfgdFzse3rVepTddb7thNvkcQAHuhYAzjgAyWMAvHIAsZUKu7YAtt4KxwsSxiofx0kXsl0tznoe sqoltsQqyOsavgg9vis1wEoyvlEyynwxuZ9ItMFAvuY1tQ1nwCBXxkJnyVxoy4NjuZtgxbZaseJt zQl1tCpxt0qLulSAzoFxxp14vMCFs+14ugCbySeluzyjsW6qxICgv5WcxbGSxeSbwgzGuxS9yUqy xla7yHvHxZvEuvv08ZKhpIiHc/8AAAP6APL3AAAA+vIB8QD0///+/yH5BAAfvH0ALAAAAABoAWAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmyZMR/KFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXXrTpNOnUKNKnUq1qtWrWLNq3cq1q9evYMOK bci0rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9++YwMLHky4sOHDiBMrXsy4sePHfyNLnky5 suXLmDNr3sy5s+fHoEOLHk26tOnTGAWoVm1vtQCCq1u7nk17tmzbsGMP1L2bde7arHELpP37dW/j xwvyRs3cq27hy2//RvicN3Tfyaljzz7ct3XX3Lsj/xffvHzX6t/HSw8/nbx47MuFK9/ufr376+Pl RzfPv6PN1SjRFqBqKwGYkoEsIajgbAMKoBKDLSF4IIH/SNhghRBKCOGFnnUYF0ToyVbfiPvVl56I 9olIH3vr7Rfbi8bF99p2JfZn40X/UQjgjhRO6KCPtWH4o4YE8vijkEgm2KOPHD5Y5JMOLhhljxZ6 aGVeBmY55ZFNJqnkhhxCyWSVXjJZ5oVaemmkmVe2iZeWQ4JZJplIWginlK5FuGSYe9ap44ZBdunm oHLBCSSXc/bJJ5d4xnlklZD+iaifj+appqSEZqoUiN7BB157I7b3qX24nTifeqTS2ClypXoa44o3 xv9KUY6OOrknkZM2aSmucRY4aaSMYtrlrogKq+mxazHIq6/BApeomECeaeetljaIq61bMiuknMh2 i5Os4IYLmbfklmvuueim25a47Lbr7rvwxjuruvTWa++9+Oar7778ZrrJv5b9u0m/BPMk8FIHuxTA wgwHsBLDKkFcVsIJ51TxPxcXzJlDApfUMUIMC9QwQSHbU7JTH388kcr2sCxvuy6DFPNAJ59s8sIi 4/zUzCv/+/LPA/EssM8EDa2y0ZsETfRBNetMc8MBMIR00kMXXbXVRgt09NVaZ90y0l8n3fXWYANt GE0Zo3RwxRQDjPHAaruddkoS/1M33Xe/NPTbALf/PTDbcgcOd9txp+S3Sof7PbjbGl+WNuB/Mz73 4QovjFLel2PeEuVrS96354tHDjdMlMctuuGfjz5343JxvLTSYoct+9iwX83zzVCDbHNCKRPdMdmz z/7761jb/vrwsSMPu9mjxTy1z8AL7zvxJOO8+9NOK9S72MiDHb3yBm1P+/LAR888aM5THzz40sdu UMnXQx31QuLLPvP30FOPv/vs96/++YpJn/uWR7v9JQR+NhvZ9QpSP/ZhjYAOHF/7Hli+pd0OgFxB G+MQ5znT8e10H/Rg5RyWOcuV8ISkE5wIAefBvfFthSB04cUSp0IRss4uritb2Fg2tbF57XYJDFkQ /+eHkAZa0Gs+rN8Ok9fDJK6Pa+bDYFgmtsEbWtFDIpneAKXIxfIgBWlXDOOVukjGMjJEjGgMoxnX yMY2upGNaYwj695Ixzra8Y54zKMeESPHPhJsj4AUlx8HSchCGvKQiEykWgLJyFgp8pGQjKQkzdLI SlrykpjMpCY3yclOevKTXJykKEdJylKa8pSoTKUqVwLKVrrylXZcpSz3AstaYjIftqSjTQjASwL8 o5cp4WUwVQLMXxYzmMdMZi99uUxfsiQfKcmHNKW5kmlS8x/TnOUVnUlMYnKTmyhxJji7uZJvhrMl 44xmNqEpE2iyE5vapJdDCHAQegrEnvgsSD7rqf/PftqznwbBJS4FMlCFDLSgBc3l+f5JkH/uk6H2 cCgvDdLLe/pzmQOBKEHtgdBpJqSjCVUouGiSzl8O06QoPSk5WcLMcqZ0pcjMZjVb8s6axlNd8+Rn RJsZUYA2FCH0hGhQdXoQgRYkpBtNKkdFKkiSsvScwxxnOkuKUnO+VKXPhKdN4YmSd3L1qzc1F0Qw WlGGBrWsE8VoQyua0YlalKJF9ShBpTkQhB6VrkwNl5W8GtYrmgapeQ2sYAdL2MJyxE187esgzanM cgJzmY5laTEh602qqiSxicXmNa2ZWcUOKqdvNatZfSpauFrUoRlN7UflylGk2pUggDXsaJwKVav/ ivOpUK2qS89p291m1avuzGpXL+tZbz1kqG/tqXI1itrQkla5y/XpUZeaVNfWFbaybU5NWprb21ZV mJStrWOFaUzyXhWcxZQpZ2c63PYWN1/c/S5k0avbcDYTpvU9L0yCG03hfrWz71UXfV/qXZP2FqtS ValVX8Jf97JzqwAO8BiP21bkJpesPx2tajcMXbYixJrTVSprY5tdw5K4xOxCrIRXzOIWu/jFLSnP iVEsK9oa2LzmtS94j2lfdCrzm/MNL3HZ61/NRhjGlgFtdNv60yZDd6emdfI+pQvbEQMWr9TNMo37 09wuJ3fDXnbyl3uq0SdfN6FGLep1lbplLndY/7VTBjOcKepWoe7Uw2VOM3Vj+1ott7kx203pgcW5 4xwX+KkJLulUCaBea9K0v+5FMrLiS+j5drPAzaRqfHmLTgaDtbNbBaukMzPWJmsYtWEe85ydG+WA arnPWYb1n80jUQt3uKwZFrNa7+lWM6u6tVgWcV2xzNpZA3pQRx61som8bLEa+9nQjnZjZixtPZK1 19heKz49rOa5FnvY3g52tfVqYwQvWLztXOd+XZLsZutL0Sc9dH49HeoiD9ndVoQ3uhOsY3qr85qX lSmk8X1DfdeX3zBNL8AH7mCGE7xx+s60fn37aL5afODtfji+pppbA1O847/9b3shrHF7jRWttv8+ a1pX3uuAWrnPIx43vOyS8ZLz6yvUlrnOd87zntsy5z4vY3Oh/GVcpxbbea7ylYkt7qB7cSYLxvFu 6YvjdDq63iLHus3hG290dz2qHh9ng+/dcK1vfeOC9rraW8r2mWKWppt1+NmPReEw2/nJyI0zL4t9 5TWD2On8CXSlHzv1S6u9vw9mt8NrPvdynXvT84Z8SYP7dpHLvfGZKnXR76xyXteZyn/nrIiZDngb 3YXxmMcpzkuPwdQvm/WwZw7QYz+Wa6P16LavdYU1TGak6xPlQi1ziL3tcrl+m/ZTuTuTT/vcCwN1 1bwW85uXv1q6yjqkskb+RsoNcu5KXsEgXyn/pg+fdvIj/tFkt7zr47Jo8nq/vOM3P9i7S/6oh//8 AX+mei+//qKA1uhzZmucZ2oKYWF253kDCH0ICGyu9mGxpn1UMVp3N1QTSIAJYYCeB4BkdmE89VF+ RmJ6NnsQ+BCBxmni9330d38I1nHjd2AqOFwNlnhZx3/9txZBRng9dl9UV3U51l3gdYI/OH8q6Ghd BXA1ZYQLV4NHYTYiOIKe1IROOBJKCGNRWIUPAYVWeBo2BmTIpGD252n/BncPRoRTiC5Rx4U+CH7s pm6RNoNlmHk5dYAP5XzCt1R9h10bhYVZGBqnxnxLxntqZl3FF257CBq7RE7e9X4EJlnOJHCi/9Zw 6feG5OJ9OshpEudx6yaD/nVxkmglSpZyt4Z30+eAeuZ3Z7ZmhcgYW7iIXEh1WBVwm0WERziLnThJ qFeLpnSLuLiLvNiLvrgVepiK4bJreCZR1OeBeDiIxCeMbtZ8vhd9BmV8d2iHqMiMzaF8zEeBrBaI w0eK1WiNzMFWdqaNc+iNyehywxaM4LgYAph3rBZ89sR3CxGC66iKN/F9iQh/Peh2NAiD/eiLlSER UxZnG8hhrgZrB3WKbFaPpbFrd2aQoBhXTAdzE8mQiyEXugiQbQKMFulIGvmRIClPY6GOHRkYu4SG xgR//aaD51ZkjhiGRZiRIdkXVdeFgxZZL/94dYuHf484k3lBYdFFjqs2jr9GjQ2IivRYkmBRgrfV duE1eCZIVWPXhjEJiT7JGfmoWzeJiARGXo6YWRD2kleJF/PEU3N4gARYh0bJZ99IkkopEuWGj1+H cPtIXFPJVfUmk2NpF654aZNVaEGYkmI4hvtXlUW4l4Axkm+pSW65mF6BmJAZmZoxGI3pmIXhe2ZZ jCqne9DYbct4VyBlmVtBUq3oWy74eFLJhqJmU2YnmW4RhxuofKm2ZLSpkN14m5UpmhjhVE45WWo4 YC7Ik4cJd8zmmn+Rj1LFY4cWf8kplgDWmsa5Lg1xlgDVh0PZgdOFfciYm7qZEdyHguX3hQP/xo8k 54bRORmJZmlRBZjItGliJ3DwCZPrdZ5wQZndaY97oZf0uZ/82Z/upp/+mRRlCXy/R33PmIAVZpDd eHyjx6D3mXxyZqDG2JlDN5ugmZRV5pkPahUVOpSx+Y65FqIHqaHf6Gcb6h8lWH4HF3b7ZnguGnLF KXcAGqBAAWSG1qIryooupWiMtnDPGaM0qhanWYlaSaQmKIQVR5XpN6NB6hPi+aJHiokqKm/k6ZKR 2KRp8Xg6CqXMxGPl1Z7vGYuFaWT/iKXmwqRmSi9omqY+caKAxKb9t6ZwahQOAQkEAQl4iqf2YKcC Yad5uqd56qd/eqd8alC4+WF4JXpuKoUz/wEJKuGoj5oSkAqpKEGplvqolLqGsZh/mwikc8oTdXqn BVGofFqoezoQpIqqfeqB2nmOSOmqi0oVphqoqpqqqrqquHqqusqNrjqNaBarWDGrBuGnt5qrtHqr pgqofCqPsEqICwmsHkETmZqplfoPlyqp2Gqtkhqo1MqPbXhk0PmpSTGtLUGu2aqt1Yqu6ap4WAdc RCan4voPdfqn3Fqsg7qrwiqsEhman9lRzQqtN8KdACsuAjuwBnuwCJuwCruwDJtX8fqwENuwZQSx aiSxXUSxfmWxoYSxN6SxG8uxIBukHitFIds4I3uyulmyKtufKHs+K/tHLRuzJfmyNFuzNv97syUX EfywszsrED1rEDzLDwURtEJrDz/rs0ULtEk7ED1LtDxrtERLEE57tFI7tVX7tEwbtQsRtEOLtVlL tVSrtFr7tUs7tkjrtWcLtkuLtFCrtFA7tUV7tHK7tsc2EzybEjv7D3nbEnuLEnfrt/ygt4ELuC/R t3gbuIZ7uIpLuDKRuIc7uII7uH3ruCqxt5MruZBruZgbE4b7t4z7uZqbuZgrupu7EnnruZ+buqAr ut5CuZQruJULubGruqYru4TruqxLu3xru4u7uJdbE6cru5rLuK/bu6n7u7vrEok7vLUbucJru46L vLCLLK9bvbnLEsHLubybvdh7vcU7u93/m7zS27iI+7zEW77kG76rm7zs27zRi77jO73gK7/fOxkO EbZZixBzq79oy79w+7ZRu79py7ViG8B027YC3BBNW7Zx28Btu7V0m8APXLX8exAL7LYXzLYU3LX5 q8GGaLe8q7v0G8LOm77uG8LMK8LNq74nrMLq27mkC7+oO7+9u7yea73iu73oO702zMLxSyg43L44 XL/vK7+xO8P1q7u467wkLMTmu7spTMPry75B3MJWDLs9vMIj3Bn3e8ATzMEeDMb4u8EUPMY/q7YK fMBmLLRn7MVgHMZr/MBx/MZjzLZ1HMf4m8Fp+8YdPMF1zBxz7LZ9TMZ/nMdsrMZJK8EJ/3HHa9vG g2zBjczAguzIgjzIhezAkCzGEXzIVxvJ5AbCrFvFkau4MKy8OmzExhvFhUvCNxzFxbvEqHy+Svy8 T7zFgJu7rXy9PAy9WTy/P3wZOkvAVgvAXYu1YRvI+fu/x3zITpvJi0zAYfzFney10EzGxAzJZnvN ALzJ/ZvN25zIm8zHHqzIMjtuNAG36JzO6rzO7NzO7vzO8BzP8jzP9FzP9lzPOJvP+iwU5fwz+/zP v9jP8gLQqifQM0fQ6GLQCl2ICJ3QC+0uDR3REj3RoPrQFj2CFJ3RGr3RLHHRKcbRII1vHj3SJF3S FhHSKJ3SKr3SLJ1KJu2RLR3TMi2uL1Z9IzN90ziNpTVtejnd06q00/3h00I91ERd1EadmED9dEf9 F0ltHksdGU0d1VKt0E/N1FOthVWd1X501VwtW1rNF10d1oP11bQk1qJB1nph1mq91rEaEAA7 ------=_NextPart_000_000C_01C74CAF.660FFCA0-- Received: from host226-171-static.188-82-b.business.telecomitalia.it (host226-171-static.188-82-b.business.telecomitalia.it [82.188.171.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l19EOjaV044136 for <ietf-pkix-archive@imc.org>; Fri, 9 Feb 2007 07:24:47 -0700 (MST) (envelope-from and@fdd.org) Received: from ONI (unknown [127.114.60.170]) by fdd.org with ESMTP id A91E2BCA812A for <ietf-pkix-archive@imc.org>; Fri, 9 Feb 2007 15:25:03 +0100 (GMT) Message-ID: <000b01c74c56$08449800$e2abbc52@Tutor> From: "totaling" <and@fdd.org> To: ietf-pkix-archive@imc.org Subject: Click here Date: Fri, 9 Feb 2007 15:24:39 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C74C5E.6A090000" 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 ------=_NextPart_000_0007_01C74C5E.6A090000 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C74C5E.6A090000" ------=_NextPart_001_0008_01C74C5E.6A090000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could be, liable wasnt. Travel resources mobile map faq! Rss feeds, = nations homepage copy division gannett! Rss feeds nations homepage copy, = division gannett. Work without central server, point make. As much day or maximum ruled = november that violating! Life tech, main categories briefs web. Edition reprints add rss feeds = nations homepage. Central server, point make industry downkazaa offers computer. Free email newsletter search usa earlier, stories this subject. May published broadcast rewritten partners weekend. Affect after it was, sold sharman networks showed. Industry, downkazaa offers computer exchange text image video, audio. = Usa earlier stories this. Contain, material lawsuit lodged protection = agency appealed arguing not. Video audio between, individual associated = press rights reserved may. ------=_NextPart_001_0008_01C74C5E.6A090000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A = HREF=3Dhttp://ttqaaa.trepiane.com/?55796135><IMG=20 alt=3D"" hspace=3D0 src=3D"cid:000601c74c56$08449800$e2abbc52@Tutor" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Could be, liable wasnt. Travel = resources mobile map=20 faq! Rss feeds, nations homepage copy division gannett! Rss feeds = nations=20 homepage copy, division gannett.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Work without central server, point = make. As much=20 day or maximum ruled november that violating!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Life tech, main categories briefs web. = Edition=20 reprints add rss feeds nations homepage.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Central server, point make industry = downkazaa=20 offers computer.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Free email newsletter search usa = earlier, stories=20 this subject.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>May published broadcast rewritten = partners weekend.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Affect after it was, sold sharman = networks showed.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Industry, downkazaa offers computer = exchange text=20 image video, audio. Usa earlier stories this. Contain, material lawsuit = lodged=20 protection agency appealed arguing not. Video audio between, individual=20 associated press rights reserved may.</FONT></DIV></BODY></HTML> ------=_NextPart_001_0008_01C74C5E.6A090000-- ------=_NextPart_000_0007_01C74C5E.6A090000 Content-Type: image/gif; name="than million.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c74c56$08449800$e2abbc52@Tutor> R0lGODlhjAFsAYcJAAwIC38LAAt0AIiICgkAgYYAdwCCc8vJzcPNtqjR5zguBVEsAIMRAJcdBcEf BtorAwpBCxY0ADs0AFFFAIozDZg1CrI9ANNBAA1UACVqAEFXAGxgB4lfAKxrAM1oCtNdAAB7CBOE AEt6CWmLAI59AJaAAs5zANSNAAClAhOUAEafAFysAHerAKSVBbeZANeuAAC7ABHLADzJAGLODoHI AKnEALq1AN26AAvkABbcBz7ZBGXRAHjnAJLVDrPRBNfoDgEANiYDTTQNR20JRHUAQpIBSLsNOdgC NQ4oRhggPDMoNmQqNHcpRqkbSbIoS9IrPwA6NCU3Nj40O1Q4N4ZMOZtLNco+RehKMwBmMxVZQDlh OmdWPnhZAqRsOMpuQdlqMgCCTSuBMziCNleDSIR1NaF1NcVzSOVyOgCiOhWoS0OgSWKTQICWQa2n MbOZSOKZTgC0TCG4SUK6S2O5SYmySqS/Pb7BN9S6RATRRijTOU7kMVLdR3PjPabkMsziQuvbQwAO exYAdTUIg1QAjIMCjqENjMkDjdsJewAldiMkgDophGkdgngRgpoWgbsojOkfcgA5dBU+hTFHcl9I gXRLfZFBc7xOe+syjAdhdhJVcjRldF5ceXpmd5hugbFghulndACDdyOLd010gWCHjHJ9jpp2eM6O feuCjQCUjhelc0ybf2qUhoythpOicsWSjeiicwC4fRrDcTfHdWG9ioq6jJjKjL3BhdvCiwbpfSXl cU7bgGLdeIvbdJfjfMnVhtHYgQABxhwAs0wAw2QNv4gIw6YDtMwKueEAyQEZuxoXwkkZyVQqwX0Y zKMrwrMmuOcctQg5sRVMwkhFw1FKs406saZGxMY5tdlHvQlkuRRnvERox1VUuHFrvaZbwc1mtN5l vgSJwS5zskGFwlaGzn1zt5OCv8Z2y9d0xACtyxGesjSYxGyozompvpaWwrmStNObxgbDwhLJyUPM zV/Et3ezspixzP/9/paepYB6gv8AAwj/Cv//AAAA//8O/Q31+/v//yH5BACUts4ALAAAAACMAWwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MBnam0mzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcp0aMynUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rFmsTdOqXcu2rdu3cOPKbXu2rt27eCHO3cu3r9+/gAMLHky4sOHDiBMPzsu4seOziiNLnky5 suHHmDNrvmq5s+fPoEMD3Uy6tGmVolOrXs368unXsGNnbE27tu3buHPr3s2bqezfwIMr7E28uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MOL/18svLx52ePTq/8soH17e+4F1HQPP779+/br 559Pn2Z//+/xh997+810n4DyAZiggjb9t96DSvVXoIP6CZiThP9NGCCDF27IoYEBZhjfhyAuWCKE KCaFoYgmVkiihSeWuKGDBTboYYwuxqihiTVSmOKPQK24oo083vghi0MqaCSOHPpI34E56uehj0Ci 6JB7AmHZXpZbEoTlQF8aFOaYW3YZ5j9lCoDQmVyqiWaXXqappplwvmknmHWep+dUX2opZ0FnDvjn m262SeihhrJpKKB0FornnH+SCWmhiu5pKUx90onoo3E62ml8jLo56KGVKpqpp6RqKummlV7q6kqn tv/JZqB5cjpro5KCKmatsYaK6H2P6rrpq8TC2miwntKK6qLKIrvosM9yCm2qlOq66rTFZmvRT0lK 2SKNS7o4Io77sXiTkzNOGWK63XZb5Y9XHhusr9LuWq28snLJqL38SnttvnfiGa22BFPkU37g3pgw flGOuHCUEFPY48RFEqiwxVC+u17BHHfs8ccgw6bxyCSXbPLJKKesslMht+zyyzDHLPPMNL+8yc1k 3bxJzTxTpHNJPyMUwNBEB1AQ0QQhfVLQQU/U9D9P9/xbTzrHVXVORM9UdE1Z29P1XFdfTZTY9pC9 cnZms5U2TV9/7fXQWsO919pj33z2dQxFPZDOOBP/xHfTf+8skN4DKf2P4QIVPXTegUP99N8FBS44 4Hz7DbnjkFOu+eVSm0b4z5oP3nffmIsu+EGGI5646ghV7vroOIde+uxMT3567afTHjvsvHeOF9V2 2yR21cMHL3zwdL8dQNzL37Q18JvMFLbdxUdfvfTUG6/T9NHTRLzx33dftvZ3r8Z47qbvvfvtpEue vtCKG4066wfhnn7osoNOeuSNz35/++tTH/p8Vxbo3URy2RMf97DXveRlzW1cg2BOFjg+6yGwgt5D XgJxQkGyhS+DFlQg+cqXmvMZ5HMA3Fn+9ne0xR3OhUlTnAl1p0IWvo+G/hOgDnOoP/bV0IcEtIsB /48nvppc73oYxJrcnse85UmQiAyM4tqQ+EEoRjGJUgTfBq9IQvMtBIXs+18AMWe7ARYOhkU7o/zo Z7kyvo9yYnSj7mgoxzeOUXZBNAv0/gZCDwaOgXzEovPk1kTlRbB5E9RgA7XINyP+EYuBrGAk+Vg9 RoKwi6wBmg3zyMm6qG2RRcSkKK/zyFGaUjWdTKXHTslK7ajylbCMpSxnScta2vKWNWulLnfJy14K BpfADKYwh0nMYhbLl8hkjjGXmZdkOhM5zIymJ59Jzd5I85rYzKY2t8nNbnrTNNUMp26+Sc5ymvM8 4kynbc7Jzna6UzPqjKc851m+d9rTY/m4Zy0JwP9PAvyjnwPhZ0AJAtB/FjSgB01oP/25UH8aJJ8C yYdEJVqQiVL0HxPV5zF7QoCbdJQm/ASpTT76UY+adCYkxUlJbWJRe+TDJy996UxkSk8gMcShBcGp Q3eaU4HgtKcE7elPB/pQjA4EogqBKFKRqlGPDdWnROVpUH0q0JxWdagMXShRK2rUiGYUIUu9aFMv xVGVitQeKa3JSlGak46u1a1mHSkBJnoTmtaEpnitaZVuepCdNvSfQJ2qQRgq1L4mJJ9M7SpXI3rU sYLsqVKFKlYHi5DIRlawRUVsYxXL1KU69rEADW1QtRrag1K1qqfdKmaP+lWMitWzBGntZ9GpG7v/ 6vW2ibEtbnfL294WZbbAPU9ig7tKnpTUrSFF6Vv7iVbmqnWtzU3uQuUK3bpat64SnWlLffuu47IV pCt961mVe1K0mve7500vTrbrUt3m9a7cFQ9foQpY+l6WvvWt72QlG9XAcrWzit1sgIdL3Nf4BK7o TSt0vftd8bKVwQ627nvdSxO76ja+3GkIYfErVb9mFbX6tepVE+rfgn7VoomFbYALHJsDp5ekDVUv go8b4/E22MbqlTB8WVrhHmNYY+FF73m9C2G1GvnIL8axjn3s0pn6+MI/RhGNEZxg5gY5yDjGcnR3 wl4ne7m9743ydx5DYBZrizhQFvNezczmNrs5/yHGSbOaUUbk5DaXusi1M3k96twtK9fK073ujgUN 5jm7ciE6xa9BV5tohFI2sPdVdGxbK9ZJC7jMb35Nozct6fxymtGFffR/Y7viSws405hxMYOHLOQE n3XB0h1pdO1c3Zg+OSdhlrOhnaNhT/dXvwLV6q8NO9mn5hehJ7boQVSMaVSbZsPAJu1oOfxXYofa v6M+NakZy21nA+enl7Wsr49t7BDb17BgHfCpme3tVLv4zzIGb0ivjORZP3fV9a4wXQeN1+xqV9e7 xjDAAy5fzDS73QhPuLsJznDbDLzhyZxun2l97z9Xl8koXq9MMw7xLi74uVluNa7pKmcoP7zjBf9X iLE/vd9yk1rFRV22ws9s3LiyOsdT1omt/+3efTMZ5WerbpFxXl4/+/znTf7yyYEenvkCtaHQ7rTL jZrixXJ25jSvuazjHWElw3fnSd/4rZmuMYeQNtijLe2HXa5srzL7tVjPumGWTvaTTeXgcW9Z3ffO 975bhu5+X7PKt4pacKN9oIU3dmcrzdqw4j3v6NH6i/F98wfTGLvZDbPSk875wKc8ISyXdLgBS9ih ajbmpoY55AsG7Q4/fdqlz/a2K3pR1a9eW60/91TBbW7Dy5bAsG377c2jaovPe+v0rvzXv8xj5nfe 8+Axu2qjbm7+rpaxp982zB8//D01WrJqP+3/fU2f7BM3nrXd15NiAA997rK//Q9Kvz3hT3/nvL/+ uJG4/kUa40D72d7jlWfghWcAOIA8YWH+dlfbdXT4pxi9xmiJtl/jdmyCFW68V4EENXWuRVGqV3Xd Jn9WAVmhRn3fF2mEx2G6h4EpmFkyN3vdxn0gGBJlRYDmlVKBtmpp1VZJdmM5toPKx2O2lYD65m+a 14CIMV+itXukJ2IXOHW5p3seZlAgNn5VJVsfKHswGIMrwXstt4RKOGzWZl9/xYXUJmzp5oEyZ3ta GBURCGkkeIKdhlmj52ufFoeNlX1K9YJXt4YhqHaHt2hjmHY6ZVplSG4I9YdeaIfCR2nn53Z8/8gS 23F/RjhPkjiJlniJavGImqhtm5gtMzh5BgiKrqZzCnhh+8ZxmIg3iEZ4g8iKcLhsGdWBd9iJkVdz QzdjPFiDpGiKzddklZiK04FlNsiDWrZez3eMhQZmvwiMziGMN6Zg+WZ0QsiLzreMzHgbveZhSVh6 1UZ9LFhqeuiCtAhPkkdlukheydeDy0dhnAd21niNx0FkRnZ56XhxC7iAQ5iP8EgddzeO25SF/hiQ AjmQBMkQAFmQrmKGCuVoVGWQVkd7joeQwiGCYsiQi5ZUydaCVMeJEtlMktdqcBWSubhkSEeS77iP 63RTV1VYsVd938iRXtWIHTmRFLhhrleTVf9YaQeHhzP5GEFhjudogzWGa+14gEWJkuqRgzn4YNG4 fMwndk5WhEjJHf73f+JVjKXYb7mWgAw4ldDxFAfZk5wUlmJZlmXplb2FFWRplqSReI4mbH6YVaqF ehsIixHJlmLxE7RGj68GkpSXlUeJcYGJlsH4jLp4i7K2lE7Zi5snlYT5HNAokv4HY7GmmD3GjixF hCX5mM1IjEzpmUdmjs51dNQYdl3JmeOEaIEYYqGnhFN3emUmi3gJFp94jvzXl0S3Z0QJdmPXeSeJ mpLhdIkIfiO2dq1Xbm2HYi/4Wms5m67SnM4ZFpTxm8BZndZ5nRimFdAZnV3BUfSof3uZZzn/p5uE dpo+d5rYmUmq+ZaQNmzfd5EPFYva5llqyJ1UUVaSuXU76IwjGZXGSJSDlp7GkZ83GIBCppQix5vt NXKMKaDFEZk0OJIIinNzJYTOx28OmhwQGpociptQZ4xBSIrImKGotIrTpoLVV4cUiH17mIcsap/d +ZE1KHHzOG8Td3w4xl7nqY+oSKIlqpYwKkvbGaRo4aPPRKTyN6RIWhVjSIhu2ZBQKoVYVXhJNWmx 2XiMt6RSUYIZaJFPOoEqCpE8SXsaqaUooZcG6pkieXPp+JkkGaAlSZ1G6hc46KGHCZpumqeLuZnH KKdzyhdTxp/QyKbzmJgqVaEWJqJ8+qeF/yF9KQh1vSeliPiGr9lVzYaGZpoSaDqKbWqbtlmn6niZ fRqgfsqoS+GohkiGJ0qcUzqIILaBSpWcMqmkmSoRtFGqpgoYZkGrtdqr5pSrmIirwHqECwEJBAEJ yIqs/2CsAmGsybqsyeqsz3qszFql4hibtSd8vnqmPAEJNeGt30oT4AquM0Gu5vqt5DpyRIiA//l8 wjqsRsEQ1bqsBVGtzDqv9joQ+UqvZ/iQ4Lh927oSPZGu0Squ9nCuBluuCXuwCrubDVqaiQqvokGw N+GtCNuwB5us4cqw6AqupNmgQ+iYEmsZFGsTFruwHMux5hqt6WqSINuL7zqyRCGvx3oQ+P9as82q rzmrs4e1h+tmdbwasHrRrRrLsgursRhLsSWLeVqpj+0YsTKbHjEbtX+xFUErtJpKtaKEtVKjtV77 tb7BtWI7tmSrd2BbT2UrM2e7tmw7GmkbM227Mm8Lt3GbMnN7t3ibty1WtyijtyHDt4AbuII7uIRb uIbroH6buIq7uIwLXEDBD5ALuTMhuTcRufxgE5Z7ufZAuZOruZXruTQhuZkbuZubuTUxupx7uqir uqQbuqbLE5aLua3ruqmbup/7urQLurjbubPLu7ULup1bup9buqiruZx7vMBbJbMruskbvLTrusLr vDhhu8JLvdF7vdY7vNOLvMbrudnrvMj/K72UO77Nq7qsa77QC77hS7zPe73Q27vuG7/Y673lmyLW m72/u73Sq7+yK7/zm76wW762S74A3BPMi74E7L/oW8Drq70OrL7DG7sFLL8N/L0Qgr8CTL85ccA7 Qb0c3L/iW78LPMLvq8E/8cHRS8AWvL8hPMEs7MLVm7wH3MAvXMEivB0MAbkIocMHwcP/4MMFYbk5 XLz88MOoa8QD4cPF28NHDMRJXMRKXMQOocNAzMNWDMVSrBBOjMQCUcVZ/MQ7/MVgvMVUjMVgTBBk nMVRTDNb3MVifMZcbBBCvBBpHMdoLMVe3BBtvMdmbMd0jMdfHMVlbMRt7Mdx7MRzbMhu/8zEhjzI XIzIb7zGi8wxBpzBG2zCEXzDHny59yvBMPzAMMy88NvBmKzAEtzJDozBL7zKKBy84TvAMozJK7we qsy/pty9pJzJ/Ju/lWzL5pvAATzCqAzMJPy/l3zL+rvJ7uvJNSzLN/wgqOzL0azAFMzJzWvDPlHL 6UvDvrzMsQzBoMzLu2zJCPzNvwvLKqPHa1zIXqzGfTzJchzJ73zH9KzI8RzG7gzI9czI96zIVwzP +0zI+yzJAj3JkfvE7lzPkCzGdQzPhfwqj3vKo+u7stu66AzKMTzR6Fy83VzR4rzKxOvJzMzAo+y7 8CvSIx3SwLu7Jl3KLKzMLXy4PjrERMpc0zZ90zid0zq90zzd0z7900Ad1EI91InsiTJ91KbauAWD 1Cmi1E791FD9FEw91TMd1RBN1Vid1Vr9o1bd1V791WDdM1s9HmGtfmN91mid1oRR1mzd1m791nDt bGo913Rd124R11Nj13rdgHhdi3tdHX29t38N2IFd2E012IjteYa92Iydton92HzX2KQB2dIh2ZZd TpQdHZe92Zzd2Z792cKR2V8J2r8j2qZNcKSd2sN02s2h2kLE2svh2tME28kh25BB27gdXwEBADsA = ------=_NextPart_000_0007_01C74C5E.6A090000-- 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 l18EqQq3041253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Feb 2007 07:52:26 -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 l18EqQwl041252; Thu, 8 Feb 2007 07:52:26 -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 i2c-RHEL-B.i2c.com (lhr63.pie.net.pk [202.125.141.6] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l18EqN8i041226 for <ietf-pkix@imc.org>; Thu, 8 Feb 2007 07:52:25 -0700 (MST) (envelope-from fmaqsood@i2cinc.com) Received: from fmaqsood (unknown [192.168.0.46]) by i2c-RHEL-B.i2c.com (Postfix) with ESMTP id 2E4E81B96C3 for <ietf-pkix@imc.org>; Thu, 8 Feb 2007 19:51:37 +0500 (PKT) From: "Faisal Maqsood" <fmaqsood@i2cinc.com> To: <ietf-pkix@imc.org> Subject: test Date: Thu, 8 Feb 2007 19:52:05 +0500 Message-ID: <00aa01c74b90$b2d5fa50$2e00a8c0@i2c.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C74BBA.9BAC0250" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcdLkLK3aiTcb134RTCPooOo4+XZ0w== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01C74BBA.9BAC0250 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit test Regards, Faisal Maqsood ------=_NextPart_000_00AB_01C74BBA.9BAC0250 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Verdana; color:maroon; font-weight:normal; font-style:normal; text-decoration:none none;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>test<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'><o:p> </= o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>Regards,</spa= n></font><font color=3Dmaroon><span = style=3D'color:maroon'><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>Faisal = Maqsood</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------=_NextPart_000_00AB_01C74BBA.9BAC0250-- Received: from host153-82-static.29-87-b.business.telecomitalia.it (host153-82-static.29-87-b.business.telecomitalia.it [87.29.82.153]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l18BXpb3022109 for <ietf-pkix-archive@imc.org>; Thu, 8 Feb 2007 04:33:52 -0700 (MST) (envelope-from between@enstad.org) Received: from DZMCT (unknown [187.123.108.71]) by enstad.org with ESMTP id F1A0DAA85FB5 for <ietf-pkix-archive@imc.org>; Thu, 8 Feb 2007 12:34:21 +0100 (GMT) Message-ID: <000701c74b75$08eb6590$00000000@acerdac357703e> From: "spanning Italian" <between@enstad.org> To: ietf-pkix-archive@imc.org Subject: wildcard partial matches Date: Thu, 8 Feb 2007 12:34:03 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C74B7D.6AAFCD90" 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 ------=_NextPart_000_0003_01C74B7D.6AAFCD90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C74B7D.6AAFCD90" ------=_NextPart_001_0004_01C74B7D.6AAFCD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Skins tired desktop interface integrity. Celebrated, millionth, kmd further secures. Olyphant sarah wynter josh = brolin scott lucas forsythe. Devito kathy, bates livingston neve tightly = wound mission. July june weekly open? Light shannyn sossamon krasinski prepared. She likes girls vol wolfe. News flash february coming soon due march = romantic comedy. Liu fantasy swordsmen denounce brutality newly. Smith bluray animated happy feet. Vondie curtishall margolyes jesse bradford, emmet walsh an. Writers zero newsworthy aspect write pizzazz. Dismal campaigns referrence wpw postings. Alvin chipmunks, chipmunk valentine gathers. Chubby checker dion dimucci = vicki. Down help sprawling southern landscape. Narratives, escaped = descended railroads? ------=_NextPart_001_0004_01C74B7D.6AAFCD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://asdafaq.hk/><IMG = alt=3D"" hspace=3D0=20 src=3D"cid:000201c74b75$08eb6590$00000000@acerdac357703e" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Skins tired desktop interface = integrity.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Celebrated, millionth, kmd further = secures.=20 Olyphant sarah wynter josh brolin scott lucas forsythe. Devito kathy, = bates=20 livingston neve tightly wound mission. July june weekly = open?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Light shannyn sossamon krasinski = prepared.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>She likes girls vol wolfe. News flash = february=20 coming soon due march romantic comedy.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Liu fantasy swordsmen denounce = brutality newly.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Smith bluray animated happy = feet.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Vondie curtishall margolyes jesse = bradford, emmet=20 walsh an.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Writers zero newsworthy aspect write = pizzazz.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Dismal campaigns referrence wpw = postings.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Alvin chipmunks, chipmunk valentine = gathers. Chubby=20 checker dion dimucci vicki. Down help sprawling southern landscape. = Narratives,=20 escaped descended railroads?</FONT></DIV></BODY></HTML> ------=_NextPart_001_0004_01C74B7D.6AAFCD90-- ------=_NextPart_000_0003_01C74B7D.6AAFCD90 Content-Type: image/gif; name="series.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c74b75$08eb6590$00000000@acerdac357703e> R0lGODlhkAFgAYcJAAAAAH4AAAZ/AIKEAAgHin4AhwN+ibvIt83Yw5vM4zQSAFQnDo4UAJMdAL4o DN4lBAMyABZEAEpLBVlNBn04AKdEBcY4AOI1AABSCR9bADZuCmNYAHdoAJlkAMhWAOtcAAB6AByD DEx/AGJ7AHh0AJJ+AMJ/ANx7AAylCxWpAEqgAGeaDIehAKOmAL6tC+mhDgbNCyLEBEjMC%@ç RMCSSdWhNgC1Pxu3PjHCN1jKPnvFSqbJQbK4SufBMwDoPxXrPkPtRGztOITeQaHUQ83sSe3qPwcJ iiMAgDkBhm0DdYwAcqoHcrIAddEAcgApfyUqfzcYg1Ieho0TcqwkfrYafuYreABKghpOekJJgFxL g3k8cZ5KgME8iOxHhQBldyRUfUlVg1NognNnfaNZjbpgdeJqcwuMdySAhzp9fmuBc4aCjJKEjLOM jOqHegCRhiqhgUymjGCpcoifhqeYecabeeqqdACydSbGfUfMhlHHcYnBiZ+1i8u5itfMfwPVcyzq gUnug2Ltg3nchZztfc3ZeePndgIAuSABu0wAsWEGuIUHva0AtMYFs+wIyg0gwCMiuj0TtmoTtX8a xpsYw78ftNgtywBEzRc2vTo/sWY+zHwzzpJIzsZNyOw6vAJdsSVnvjJXwWVdzXxfwKJpuL9rwO5W wwBxyS54skiAxGyHxXaCzax6tLWJseqHvgCbti6txjioxGqYxnuptKuds8iVt+Cdwgu6vBe1wTq/ uVfKxIrKzZWxyvb/5aSeqXuJc/8ICAX8APX/BwAI/vcA/wD//P///yH5BAD//7kALAAAAACQAWAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+X9oIKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNqrfqzq9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+tgAMLHky4sOHDiBMrXsy4sePHkCNLnhzU r+XLmA1S3sy5s+fPoA9nHk26tOnTqOUKWL36H2sBBFm7fk27Nu3Zt2PLHribd2vdtlvnFlgbOGzf x5EX7J26ecimrIPSFhp9aHXpq49Wf02dO3YBRK8X/xX/3Xp2e9enlzcPnn3o9/DjW3W4ezhz3MAR 9t7/Wjny3wbdhx9xAA5oX4HDDejcgizVl9t9zAlIYHL89acgbgXmt9xvAspW3IUJSsjgiBVBd150 J57XXXvrjadietmlyCJ64KkYno3rkUdjjTG2J16P7skn5JBETrVdjzzOuCN7ti3pZHkovoikUToe qeSSUSa54pM6Funll19aid2TLZLJJHlHcjmli1eKeaOWNKoJp5lg1mnnY/RxqKeF/k2on3AZOsin bQd1uGeAgB73IYYVkuioSYL+l5yffW6oKIIAPphphhdSaihsFR7qKaePluqQiT5KiaaNXTrpnZwy bv/5Jpuy5qhqrLZeeeeuvE7m5ndK/ohjrd4Jm+KNtM4qK4wzFhtsqrr2Ku20VzV0W4QQYhociB5q C2qg4E7KqHHaGtdpt4uaqu667Lbr7rvwmkXtvPTWa++9+Oarr73x9uvvRPsGLPDABBds8MEH/6vw wj5t4jBZDm/C8MQSRVySxQgFoPHGARS0MUEfn4QxxhOR/I/JFDeHMkgrDxQyxyBrLFDIIj98ss0l 43yzxClftlTEiAF91MZCEV20xkEZrZjQVzGN8NOdMdTyzjpTTXLEV1cdc8czy7w1zQlhbTHWBIld kNg2Z20y2gKhLbHaOLvNc89r/eywUUAzLfTemwj/xXffQyOdtOBDccwU1vYg/nfidwe1OOOA8+04 4JBPTnnllf8deeNQd87VQiurvfNALY+stcteg42616Cn7frbcT8s+uhTl/267bDPPXbsc9NNV+i8 j94272QLfxDHqq/Odes8m5476bIHT/vpVt8O/fPDY2+872fZfbnlaGOO+eNOE0W00uajjxT5d8vd t96N5835UOxfLj/l9/s9v+f8PyW11qUL3uxq9zLWKc+ACHFe9rZ3vQZOr3cLjODaoqc7CjqQe91T SvnERz/O5c9yIAxcAAZHOHsYTn1FqR8H9Ye/+LVvf+J7HAjh9z4PwrB/OEzK/yAYwZstkGzOax71 //5BM5h1jWvJO5v1FDi8HzLRdMIr3gSFiL3ZYVBeGnQbC52mRciJLYRGQd8JS4jCDm7ujFucXxdp aMPwga+GLaQhC3NIR8pssI54zKO0XPg9Pfrxj2ByIyAHScjAXPGQpSqkIhcpJEQ68pGQjCRaGEnJ SlrykpjMpCY3yUmiSPKToAylKEdJylKa8pSoTCUqO8nKVrrylbA0jCpnScta2vKWuMylLnfJy176 8pfADOa6YknMYg5FmMgEijGXycxmOvOZ0IymNKdJzWpa85rYzKY2vZSPbXozMAQIJwHsIU6hhNOc QyknOdVpTna6U5zjhOc4i9LNoOTjnvckCj7zaf8PfH7zn0GZZzrTKVCBBvSgRjEoQsm50IEaZZ/9 ZEo36xlRgG5ToQudp0aJstGEcvSjGGUoPStKUqTUk6IUtSgzGUKAg7RUIC+NaUFe+g9xGsSmNZ1p TeE5EJoSJB//AKpA9pkQoQb1nsk01VJCWlCEKhSjIWXoU0X6UY4SwJ/6fKhQUKpSbTI1oPKkakPH is6pfvUoE83qSO251a42syE+halce5pTgsS1rjeda13vileDAPWvAxGqUY0a1MAm9VFNgec64zlQ xZZTsQQ9ZzubWpSQQtSe/CRpSvuZWbd69jOb/axodxXa0Zr2tKgFzWFX2y7CslZhSy2rZNdp1XP/ QradlVXnbcEa1aGEtrRY3WdpUwtLyhp0tmKl6nGhWlZ0ZjQpl+XsWktKXeLG0rjO7ahDlTvWpmJ3 u1lNaVrVWtLhWpeScMUrTWXaV72uV6/uVS9822vYwQ7Vr4bN72vZ1dL3zpW9NuUpXdsrYAET2K7h HCpSj4rPgtj3vvttV38HLM8J05W9OzXwgeVrV4UAVr/6fXCE+dvhvmLYwnst8Xz9y+GiFjbEEH6x a0dsqvUm2Kc2vnGHcaxi+ObYww3+aYgX/GIaG7nIR35Xvsx73rcm+clQjvJz9MXkJheTpRdOMEzj ylMN79SlOM1wT7vs5RiDWMiBJbKU9xJbpxIU/7zcxW1Vt6tdOG8Vq9KlJ1fZauVXflekdX6um+Fs Vo+OVLzV5bNm+1zJ9LIYwHmNL31xyuUMa5m+hX3wjGMs4jXnhSmMFXRHH8tOQCMl1M2tbG6DG13f tlXRjFakoyksTxOneMtllmul+crX+xJ200XutKdLw2Nby9e/xY40sl3q4l+DWMTAHrZcEjtZsRb0 sY0F727daWh94lnRKM3st2NdSLlEW9pQPje6183u0pD73TmsMrzP69jZ2juyvO2tZlt9Z8yOe95O Xshdcczi/zaEqOcGtrrbnZo2z3nUVdU3W/es1YoD3JtnNXVyr93b8XK2s/7erLwv/kosR/rWlf/W 6ZhfGmQ0w9jMDPcXr3EdYJX3GL+uzfnLY55Ih2c323bWd1r3fNJXj5zk06w3qqVK6niW2tviFved KY70qqPV6p61ycJ57i+se/3rYM/j0cOOcefStqHYlq2cyfvxh0Z97GRvJWXPvnG00x25IV+0qyf+ 6riz0uQoX7GPczrhuH7YwYj39Zm5LmEOY9jgFyZ8ew+/eAZzmvEjAnWcA13nUHf+qp0FrtH/7fdM ztrSOi4xjyGNc5jv3PWYPw217T5Va9f90NUtOqzhXvpOzp3ptpUsZGs/9ZNeNtzh7j3Jea/8WN5k 67GPvvSnT33WQr/6Xkls04Mv2+1XO990Xuz/2sG/W7qb1Lcg/zg/Sd/8ehEfrKk2+9yj+mfzE3+5 SoEo1am7//Z/CfADFnmSp2LLhhAFGHg qLWN3DhItxiO4rgwm+GN31huLBVm6hiIW8YQOneERNZy4+gcA0drY3aPQLZghnh5wjaPp5FykbeD MLiAlSdk/eiPpkFpOrWDsEiQsKdgh4iQlvEUTuh5g/ZUkvVtVeZx5niOdFSRGud05XeFsKZVW+iR lqRdnGd7vxiCWciRKPlH6XhpsnhgyeZgLf+XkxEpgxL5F5TRkTFpUUAZlHjUk0Z5lLhki0hpF9rn iCKpi0/pdGo4XW33gVNHlJ7jEJe2lT8IefiIaTKIhC4nlkupF5DGkK5ok7GoeAwIYwdZlhmkFJk4 gbcFlRsVaJ9IlVepd1ipR6WIjFVIivhWlSUJbqrYl3jUi3N5kRFHjXmZaHxZmIjZP2JYaIxZhtCl jGpFdUM5mf8ncDu2kJR2Y132lTipj4k4WPGolHD5E/HRmZ5pTbAZm7RZm7Z5m4Mxm7g5L+l4j0G4 jv0FnKZphLN4mjvZmnXBlRvmeCyIYAiBcGdmX2+JnGERW4wFkqLmUPXXgWzXnbq5m5yBZQz/qZCS loJpaZA4+ZzvSJ1zcZYz9YKPd2IrBnoz6GIPyZ5t4Z496JUoR4SIt54MyJr4GRa7loDnqYB8BVia xo8DmpyiWYK6RppciWKTl5PxuJPC1aBkISTfCZ50yBMCqqFY5KGmJaKl1CsdSqJ3EoZPZ2+PeHct em/nt5fTZY0q6n4W6JQ6ConbiX6S2Ix51p03Ki0byJjXeZm+mKSuJnp6CZlD+h5a2ZyQh5YIuIKh eYRI9pD1aaI4MXuLNYp/GZIYqKRgpZEzCqRP2it/pphuxqbxR6ZLKpnNmKJpakityJwCmKcnOIhg qXhbamYhyqU4GIAnWKiFGpw0WZNelpqp/3mcgSqoIoGiddpVdDqplrqHkEp9j5qpaAEJBAEJoAqq /+CpAuGpoTqqoWqqp/qppEqIDZilGJqInGoTSwEJQ2GrtyoUuIqrQcGrvnqrvIpWrOaBNSqkl2on wRqs9vCry5qrvaqr0Nqsp+idFodoxyotyRqq0Mqsz9qt0iqtyhqne4emnHmtQ8IQrTqqBmGqA5Gu rZqqn1qqBbGq8gighXihsxoW7rqu6iqv7fqv/Yqq8FqEMKdu05mvypQUyWoUCxut37qrzjqtJWmt bWiuRIKup5qq79quouqvAauu+wqPq6ma0OZsCFsqm3qy6pKyKnsTFvuyMOsZLTuzNFuzuP8Us9lk szq7s6eCs9fEs0AbtEI7tERbtOTos9ZktP+CtEzbtLKktFAbtVI7tRLptNNEte5itdKEtVzboFr7 tWA7FV2bMvxQtmUrEGdrEGbLDwWxtmz7D2mLtm+rtnM7EGfrtmYLt25LEHgbt3zbt3+bt3a7twux tm0ruIPrt35Lt4SbuHXbuHKLuJGruHUrt3pLt3rbt28bt5xbuf6CuHfruZabuIN7uaN7EIt7ualr uqy7upiLup27uXPruqPbuaebtrgrun8buLtburVru5lLuqxbupI7vMbburOruwzCFGVrFM3rvPww FM9LFM87vdBbFM1rvUIxvdwbvUuhvdv/673hGxTd6xTZK772UL3eq75Kob3WW77XG7/jm77oS77R u7bSW7/gC7/0i0kM4boAnLwIEbqF67kE/LrI2xCru8BsC7wK3MCPK7uWS7u+27sJjMCHC7vHS8AO fLoV3MGfq7sBXMGHS8GTi7eZu7cOrLmwi8IMfMEPPLy5O8HKS8K3G8EYbMG7m7ocLMA6fMM23C8j rMEeHLg1XMSqK7ozHMREnMGYu8QxLMPJ28NDbMGLa7hInMUHvMMSbLw87MPHGy9V7MRhnMQF/MRK jMVMnMNaDMHFqxAdHMBQ/MMw7MRjTLwGDMF4TMYfDMY9lxTga79Hwb/Uu771W8jYe7+H/9y/jCzI 37vIgXy+jty+6Pu+kKzIk5y/iTy/1xvIjazJ+4vJ4eu+h8y/ntxJkbzIn5zKnLzJiMzKk3zKmiy/ jkzItLzKpWzImdzKuIwU7HvLvwzKlWy2iKxNxCzInmzJ4ivJvNzMzFzMtazK0FzIyxzMnzzN8wvL 1tzKxxzL1TzK2dy93xzO1IzNjWzLjPQQhAu4KVzCcxzGX5zChnvFbgy5a3zCPyzHaqzGOszPRly8 ++zP8uzOeRzQORzPQDy2yPnImtvQDv3QEB3REj3RFF3RFn3RGJ3RGr3RGG1JCq1UYRvSIq1DH41Y I33SKJ3SV1bSLN2TKu18LZ15Lz3TNJFd0zb9pDEt0ze9STm9vDv909fa00KtiEBd1EZ91Pgy1Eq9 1Ezd1CmD1FBNok7tblGdzlN91Vid1VpN1VXd1V791VGz1WItZWBNSGPdF2Wd1mq91oVx1nzB1nAd 13IdFW5d13Z913jNE3NNR3nd137Ns3udQ389F4GNQ4M9bYWd2Iq92IytL4cdF40d2ZJd1AEBADsA = ------=_NextPart_000_0003_01C74B7D.6AAFCD90-- Received: from [80.87.17.5] (ip-5-17-dyn.adsl.intratec.it [80.87.17.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l13Nwtia054809 for <ietf-pkix-archive@imc.org>; Sat, 3 Feb 2007 16:58:56 -0700 (MST) (envelope-from side@emsintl.net) Received: from XTKVSEG (unknown [143.177.43.92]) by emsintl.net with ESMTP id 917AB5A8A182 for <ietf-pkix-archive@imc.org>; Sun, 4 Feb 2007 00:59:07 +0100 (GMT) Message-ID: <000a01c747ef$40ca8b00$00000000@miki783adee0b4> From: "Gruppi" <side@emsintl.net> To: ietf-pkix-archive@imc.org Subject: reduce IANSA Charity MySpace Date: Sun, 4 Feb 2007 00:58:51 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C747F7.A28EF300" 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 ------=_NextPart_000_0006_01C747F7.A28EF300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C747F7.A28EF300" ------=_NextPart_001_0007_01C747F7.A28EF300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Went into, effectan average two onehalf, arrests, every day! Label input = select divs need bgnavblue topnav ahover. Braying much better insist, = trying? Java vm mirc fd shop, password. Media limited nacompany = nacurrent version na, ed litekazaa. Regularly, valid measure reflecting = response criminal activity. Actively fileshare puts riaas. Unwanted, third party wanted be able = without cleaned! Divertenti ragazzo filmmaker breve. Through ordinary after meet specific criteria according, attempted = dangerous. Contatta promozione pubblicit jobs myspacecom tutti diritti. = Issues resources, events campaigns whats, womens portal. Txtblack size, = alignment line height dimensions widths heights? Dd ol ul li, color = scheme linkblue footergrey. Placed listed below, will, redirected pay siteold versions? Onlineaol, = instant tftp edit thumbnail. Cagnolino potesse farlo viv stop motion = con, la divertente. Number cds regular music. Shouting closure looked billboard hit. Karen brock mph said, thousands exact opposite true committing. = Community character, of bookstores from. Feeds internet tools, gt. Minister comedy, know peter lilley saturday tech finder reviews. Deceptive ad, placed listed, below will. Good powerful authors concerned contained unwanted third party wanted. ------=_NextPart_001_0007_01C747F7.A28EF300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://erranter.com/><IMG = alt=3D"" hspace=3D0=20 src=3D"cid:000501c747ef$40ca8b00$00000000@miki783adee0b4" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Went into, effectan average two = onehalf, arrests,=20 every day! Label input select divs need bgnavblue topnav ahover. Braying = much=20 better insist, trying? Java vm mirc fd shop, password. Media limited = nacompany=20 nacurrent version na, ed litekazaa. Regularly, valid measure reflecting = response=20 criminal activity.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Actively fileshare puts riaas. = Unwanted, third=20 party wanted be able without cleaned! Divertenti ragazzo filmmaker = breve.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Through ordinary after meet specific = criteria=20 according, attempted dangerous. Contatta promozione pubblicit jobs = myspacecom=20 tutti diritti. Issues resources, events campaigns whats, womens portal. = Txtblack=20 size, alignment line height dimensions widths heights? Dd ol ul li, = color scheme=20 linkblue footergrey.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Placed listed below, will, redirected = pay siteold=20 versions? Onlineaol, instant tftp edit thumbnail. Cagnolino potesse = farlo viv=20 stop motion con, la divertente.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Number cds regular music. Shouting = closure looked=20 billboard hit.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Karen brock mph said, thousands exact = opposite true=20 committing. Community character, of bookstores from.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Feeds internet tools, gt.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Minister comedy, know peter lilley = saturday tech=20 finder reviews.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Deceptive ad, placed listed, below = will.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Good powerful authors concerned = contained unwanted=20 third party wanted.</FONT></DIV></BODY></HTML> ------=_NextPart_001_0007_01C747F7.A28EF300-- ------=_NextPart_000_0006_01C747F7.A28EF300 Content-Type: image/gif; name="attempted dangerous.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c747ef$40ca8b00$00000000@miki783adee0b4> R0lGODlhYAEwAYfqAAQLCYENAQCOAHJ4AAADgYMCigB2c8rAvMPau7PF6T0lAGkfAHwRAagoAMIr AOYZAARDCSI2ADRBDVc1AHc+AZU+ArFAANZKAABqABJTDkBpAFFmCo1fAatkBsBqANdiAACEARZz AE6KAFyDAI6MAJOKDrp2AN9+DgCtABSgADORAGqWAIyjBq6oAcylAOKbAADIDCPAADi1AGXEBHO5 B568AM66CunAAADqDB7hB0vXClTpDIvZDpHXBcvVAOHgAgAATCcFP0AARGUAPY0HSaQOMrcDMu0A SwAgQx4iO0AeNmURR3YdRJEoPLMsReQVSAAxOy08NjE+PGU2SIRINJUxR7Q4SeE+OwBVQB9fNDJq Q2xZMnJZEpFZQr1iQeNqRwlyNC2MMTaLNlJyTHl9TJl2TbaGMuV2OwyfQiCnNj2bTWipOISuS6uh Mb6cPuCbPADHMiC3SjfHRGG9QozASZLLP7G+Mum3NQDuSxXhMTXgM1zsSnfgO5LcSrLuNdjWMQAA fB8MckIAcmUAi4QAepMNd8UJgOACgAQbdRkphUobd1UkdIwacpwnhs4ejeUSgAs0eBk/iEQzgWtH d4NJfJhMeL5Lgdw9gAVlehFVeEdWjFdgjXddipFndb1og9RiigyBehNydjZ5dG6OjnaMcqFydLl3 huV8eACpdRuVizubc2Koh4SogZSpjMCReuCocgDJeRnIjU61hFu7fYzOjK66er3FeN2+igDliBTW f0zVdWXYcnHnd6Thd8zqjurjjgMAwiAEvD4Osl4AvoUKxZsEvssAzOgAtQAktyclxE4gsV4lwYAW y5sStb4gtdohtAA6xx5HyU5CuGoxvoU2y6xFxLNNud5HvwBkzhJUuTNttmddyYRps51mzMJisepX vQp0tCF2zUh5u2h9soCGtp53xr97wOqJwgCowxOuxjaZyGausXyjvZmhtc6pw9ipswnCvCu2tTjE wVq5snnAtqrLx///+J6moId6ef8AAAD9Bf//DAAA8v8A9wD//////CH5BAAI4WYALAAAAABgATAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq/Gevo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzpr2NOHPq3Mmzp8+fQIPaHEq0qNGjSJMqXco0qNOnUKNKnUq1qtWrWLNq3UqVqdevYMOK HUt2KNezaNOqXcu2rdu3cOM6LEu3rt27ePOulMu3r9+/FvUKHky4sOHDiBMrXsy4sePHkCMvBUy5 smXKkjNr3sy5s+fPoOteHk26NNqTAlKntqdawEfVrFvLni07du3XsD3m1r0aN+3VtzvO9u2ad3Hj IHeHXk63oWqBsgc+JzgdemqE01tL125dQMHqBsF3/6d+/V/16OPJe1dvur3c7NzNl9++Pn34+efj g0d/vz79/wDyt1988vnn3oFToZTbcLYl15twDzp43G4MKhechCEtGCGErlUY4YXKMSfiYBp2WFyI Fm6IHIfI9ZZibCOF2OCMvjXo4ocm1jjijmA5V95zQM5nX4G0FThkkN7ll6SQALJn5HfXIfmkkUoi aKVa8K0XJZMDGkgfgU9uWZ+U/ZU55X/wTUnmmVe2+ZOCN554IY101ohinBQyiOGeMsJWYp7Bycjj oGSVaNyGKR7HJ44Ttsbiozrq2CdwD94GKKSEZjqWoRwiymiMeK5oW5yilgppoqc6SiOnmrYKFquj 7v+JaaSqJiqngxmqiOqqjN6K26yuBvsSQ9F1aaCxs52pnbFsiucsgck2SWSzYvLn5rXYZqvtthkJ 6+23nHEr7rjklmvuuVaBq+667Lbr7rstoSvvvPTWay+9eW2ir2b6bgLvvy4t1G9QAyMUwMEIB1AQ wgQx/FTBBU8U8T8T33ugSf0ylfFICHeU8Ecd2xPyVxtv7JLJ9qAMcLAqH9WyRyOPLPLBHtMM1ssn 77uyuzj3q7NHPpsctL8d4TxzADDbnPTHGA+dMspBgzQ00UL7/JHTT0dd9dZR77yYwPoeNHDEEIdN 8SYDlY22wQcP5HDDbyvk89lhq0132mbbfffZApn/vffEdqu9dsUWs9U00Vf/nPHWIpX8c0ghy7w0 0ic5TvW+jDOe9eaHF/344opjHjriXh8G9toEkV2336oH3bffBiUcN9xtM6T32KyvjnrgsKc+9Ouo 39363sQX3lbnUk/tr+aWe046SB1LPjlKzW+u/PKjO8958pd3nzj2iIMe/uOlQ9byy5lnvz3kNksv O+UlVS9+4+rPzz3QOkMt+vjg4/98+YM5nUEIRzzc7S5vvaOdQBJGO4XNboAIHJzuxJY7CaKNcMMr ngHxdsEKGu8tyLuf57RnNct5j2NKY9rRaga/kcgvf6Ej4Qsvxzmrra951VsfAB2jPP/pr2s91CHI /5R2NKTJTHrf0972sOY8G3KNf13L2v58yD//7dBbRruiFpezkwh+8ItglMjvwkjGMprxjGhMoxrX yMY2uvGNcDTNFudIR5HE8Y54zKMeAVPHPtZxj4AMpCAH2RU/GvKKhEwkgg7JyEY68pGtUqQkJ0nJ SlrykpjM5CQhyclOevKTjdGkKI8HylKa8pSoTKUqV8nKVrrylbCMpSzDMspa2vKWhVtOPmYJyYYQ 4JcE+AcwB/JLYhJkmMJEJjGVyUxgBtOZwTRIPgaSj2pWsyDWvOY/rInLL0bzmMf85jcFEs1xgrMg 4iTnQcxJTW5OkyHTfOc2u1k4dgrTmPfMJz7tqf9PdYLTnvaMJzXhKRB5ypOe3DIJAUSy0I409KEg aag9gBkSik40ohN1pkck+pFd7rIj2STJR+1hTV7CayEA3ac/8XlOgzwTnf1k6TK5ic2DGHSgCLVX SpPpzJiyk58v/ec6EyJQghwUp/MsaE7v9dOV3tOcTR2qPsspVZvO86ZJzWpWj7pUefV0mON8JliL 2dNwFnOZ6XSpTWm6TW1uFZtu7apcEcLVueYyNCM1qV73yte++rWvef3rDlFqzGaic6xnXaZLkVlW tBK0ptLUZjbralc5lkSiEN0oRzl6UYd+5JcV3WhnR4vZkoQUpIElqUcCm1rBgqu0pPXsaEUr287/ cra0sL3tSDzaUdWCZKR5ba1rXxtb2Wb2s7S1LUY9m9vlhoS3II3ub1fb2+G6a6GwVa5tQatR2t7W ot2d7WwtWlKSnpa60vWtdduFXe9Cc7zazWh4xXtc3YpUvfhNL3DXqylfnjOsKw1qPgEs06mylJ8D PShWF1zZa6EEs9xFrkMpuln4Jre2pAWtSMuLXvVyWLj8DXF+RXxSBFG2wegisYpXzOLmXOnEKCaX QkVr0YxGlMI1njBDa8xjjb73uUAWSXCr2WLQENafYSXwgcOpVpgiuapwdWtc24lUGMfYPWnNslMD rNKWblnAXk6wUbU6ZqWa+crYErCWY2rgJx+W/6r/bGxA30rmKiMVzZc5SXtrm9mHcjfHxw2tbjmL 4QmXd7JC7jCIi/wYhqiZnNDsZ1DFGemhQpXNmFaqgulqZzyP5sESrnBsm3vhUHuXofcNboc9vGpG 7wjCe+YzhZEr6glr2NalLjRqiVxdD/PavIt2dShf7OkU7yjYwk62soVV7GbLxcrOPuODcQzhC4M3 x0EG9q87+lFEL3uHhN5sdo2LkpAuWrjI/ja7CF3cQMc31a3u9XTVza4jO3nAX3Yspw3K1nZOGdrR 3taMQ0tu+hIc18DOtn7jTW+AsdvPPnZurnvL2nmzuuHlCzeGY61rdlMXur7tNnrTjfF1Uxu+Pv/+ 862f++FfA9flJV/XWQAecBTTvOY4z7nOd26vwZA85lrM7q3FzXHsVlvhHOb2y38OdE0JfdzvNrpm WU7k/fYa5ExvemfsDWc4d1mdLwXzVa1a5rGfmecCnzGp7Vvh9nJctalt7aEZrvVvxbrPy217wQ29 bbmPPOl155GjBxzpS0sa35guKmWxeme00yutYHcygA1f06KWmfF1drxXZSpWsp61rJQvKE0ne2a2 Tlnz2PJ54Fec9dV7C/V4dr3smdP62XvFl4j1fGG/2kxKJ9bAhjVr56GK4Dv3W/SjPz3seaJniduY uc4V+khIreNSj3vlQi6p1Vu9fdubRSFRLWz/5Fu65qp6vetNbjOCLV/2s9N5+T4Z+GfBq9zuSl+8 GL2/u4v77umyNu5zl17e5xUQZ3AX9XbztX+0llx4J1/yJWrf1VCAN2IfR3cDCBP29lSSp4H/1YEJ 8Wg8BVZCNVWVtm+QZVWYB3870XzQJ2E2Zl/853EbN4OjdmoTV4FWJ3LR1X0XyBQpN2s69l5tN3TY lmFFp1kRRmMu+Fstt31N2IOmVHtQaBQWc3MqmCBTmIVaKGJSuIWt8nRTJ2sMaFpKl33ddl5eKCJg WH0ZNoa7pX3cV4FpmCl3R24NiFvwpnCs1oVzGECD12WT5mZbVnnStFbvlE1XuHmAOH5ex2bI/9Rv dZWCVpiIf9F8EAeEbvdjbwdkOphtFdeHzIGHShiEC6hrFDdinYh1oBiKo9iCL1iK+LdrZxiACbdr q8hIfHiLuKiLrkKJvviLOTeJwJhQCtVjR/d8yHhf8laGtsiLrBh9bEiEJnFa26ZoF+eMjQZ+9xZ5 YSeIhXhUVmZ5wjiMpsFYMNWN6GeC7QdX/kaO6CJ2gYh4xBdNkLgQ4uiOi5QSCKhdRjdfnGiBOwiQ 2LgZ9VVoR5iH+JWK1ziQnZGAQ5d/S6h0S6doLleNDKkYWTGO+Ogmd5GLF/mRabiR3XQYHgmSgoF7 igVpIQhpwydWBXaCbRWJUqZ8IlkaiXWTIP/YiMn0kv52j2XnkzXZFywIUW7XbgbZf3JocQvHgyYp GkdGVejITCwJlYOoaYUYWYfYeEE5GulIlW5meGD2iHEViTiFiFtpk4X3ZGsGlplmlZn3fu53lm4h fwcIkQUHg9jnf6i4cALZlLSkjeIXZ5/neSKokoZ4iGbJb/wml0JpGCXpl3fBFhrJmH4BmaVEmXI5 mZh5GTgZgsPnWHLWmZzWjlhJmpu5FsU4dXhpg/yXjBK5kHvYl5ZZFkW5j3xGg9SXlMu4jI85mwGj jVH5eUt2eOr3jey4VjB5mnyBfvNIYM75dZB2fG8Jl8p5Gpdlh3lnajYITewGcgI4b73pm0b/MWjQ uHe52Z1wN3JLKZ6HMWgRR2MqB2sWtlpPqF+85m3s6S7hmZ/rsp/8qRTVGaACyheb4Z//eRRCiG3S GI2wFoE3KIATaJ8ReqC/yXWcR2kpuZNctqHr505aqXyaOaASAWq3eZd1eYew6Ip6qYffSYEUiqBu yI8naqKtqKKnqJS7aaDs6V9T6YFd6Y3wiGm/VI+jqZUiihXlx53y6Jlh6VNtaXYwBo5HChUkapQ1 WpetqH9k6J0QupsvioF/eHiTd46COY9oZU6JmZimGaJTqi1s2qZAUaBf6pRwWqd2+hSKoaNzShML AQkEAQmACqj/4KcC4aeBOqiBaqiH+qeE/6oQUrqOpEl6d3oVjTqoBdGohFqpmDoQmlqphyl6RkWW 7vemk7oQJgEJH4GqqeoRqqqqHeGqsMqqr4qQ3+l3XbqnTOGq9pCoshqrsjqrwLqrwfqPvJlot4qr SqGrujqrvhqsvPqryxqozVirbwhzyLoUyhoSqNqswgqssJqoy7qi+RVsTHmtRZGt2rqqv9qt3Yqu uwWbqnZ15oqt0gqu6yqtzrqq7sqEFTmR9uml84pXAYsXb0GqpYqnAwtAB7uwDNuwmpSwCuuwbQSx 5SOxFnuxCEGxpYOxaqSxHsuQHBuyIjuyJHunH3uyvFiyZISy/6KyYcSyJeayMnukMPsuM//7QTWb szq7s2LhEPzwsz8rEEFrEEDLDwVRtEb7D0MrtElLtE07EEGLtECrtEhLEFK7tFZ7tVk7tVBbtQtR tEfLtV2LtVjrtF47tk97tkwrtmtLtk/LtFTrtFR7tUm7tHb7tpVoEkDrET9rD30rEn/bEXsruPzg t4VLuCQRuHxbuIq7uI6LuCfRuIt7uIZ7uIEruR/xt5druZSruZyrt5RbuZkbuptLuJ3Luaf7uSDR t4P7uK7ruqXLI5iLuYY7uoCruiMhuawburB7uihBu43rua8LurX7uMJbvInLu4obuyEBvMqLu45b tLY7vdTLvCLivLnru7eLvNnbvIzLu5D/i7y0u7rgy73Rq72/+73TK7zjO7zii77US77bq7vqa73m +77uGxrYu73hS77ta7pXW7lIi78ALL3eK7X3W7v2WxK7u76f+7/3a730273eG8H1C78W3LuyW74J TMAHzMHxi7izC70QnMAjXLwlDLnLm7oXvL/V+7wL3L/nW8HHG7zgy7wpnBkuLL8yPMMMfMPq+8HP m778K78DnBISzMEGfMI83MHHW8E0DMT4a8NQ7MHXq8RYnL8oDMIZzMQrTMRVbLtP/MPxe8Jj7L4x LMJZHMVsPLlD3MRpDBpMHMZzPL4TXMcYTMFhvMVaPLxfzMNnLMN/zL87zMdGTLqt28ODzsIQYhu1 eAu3Y9u1cSvJB1G2cWvJkwzJmCy3lXy3dZu2jwzJYSvKWavJj+y2oEzJmdzIn9y0rFzKmby2ozzL qxzKBJq+gxvAAuy/ZzzH54vAVEy3RXy7iUzFxGzAu0zHiTy6R+zGbgzEy9zMz5zHxvzCfcyzwka3 2rzN3NzN3vzN4BzO4jzO5FzO5nzO6HzOmnGz7NzO7owZ2BzP8jzPYPrO9nzP+JzPt0TPwaLP/vzP AB1//BxJAT0uA03QBZ3QCr3QDHHQDv3QEB3RoREQADs= ------=_NextPart_000_0006_01C747F7.A28EF300-- 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 l13LFCPS044097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Feb 2007 14:15:12 -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 l13LFCxc044096; Sat, 3 Feb 2007 14:15:12 -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 sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l13LFB4m044090 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 14:15:12 -0700 (MST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2007 13:14:39 -0800 X-IronPort-AV: i="4.13,277,1167638400"; d="scan'208"; a="37083618:sNHT39912534" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l13LEdbH015761 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 13:14:39 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l13LEchp008845 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 13:14:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5F18729D-D9BB-425C-AEB0-5BD94A601610@cisco.com> References: <45B94A66.3030107@cesnet.cz> <00ad01c741f2$661064f0$82c5a8c0@arport2v> <45BE9497.90805@cesnet.cz> <5F18729D-D9BB-425C-AEB0-5BD94A601610@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16C18283-0CF5-4D2B-9D80-A833BF8C3E01@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings <fluffy@cisco.com> Subject: Re: What is the right list name Date: Sat, 3 Feb 2007 13:14:24 -0800 To: ietf-pkix@imc.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=295; t=1170537279; x=1171401279; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20What=20is=20the=20right=20list=20name |Sender:=20; bh=hN9JTfm0LRsnPjZIoRu1YdVYsz8apbDZSgM1pnbTPOg=; b=COBd4esT+C6Qg6jXP00vR4unUMXjI6EAk3hqaD6+t/BeviafUri0FSkfGjfYLRPxDYwauUPe nlJva8tUwITs3Oe3sQW5BeWkXj9+JTg3jJzKikXqVrvQI45KZqHZwSXC; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Paul H followed up with me on this. Thanks, Cullen On Feb 3, 2007, at 10:14 AM, Cullen Jennings wrote: > > A bunch of stuff sent to ietf-pkix@vpnc.org seems to be being > forwarded to ietf-pkix@imc.org. This just seems like a recipe for > confusion - can someone stop it ? > > 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 l13IF2fd031388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Feb 2007 11:15:02 -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 l13IF26v031387; Sat, 3 Feb 2007 11:15:02 -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 sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l13IF2rJ031381 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 11:15:02 -0700 (MST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2007 10:15:01 -0800 X-IronPort-AV: i="4.13,277,1167638400"; d="scan'208"; a="385426768:sNHT40005416" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l13IF1b6028285 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 10:15:01 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l13IF0nG004168 for <ietf-pkix@imc.org>; Sat, 3 Feb 2007 10:15:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45BE9497.90805@cesnet.cz> References: <45B94A66.3030107@cesnet.cz> <00ad01c741f2$661064f0$82c5a8c0@arport2v> <45BE9497.90805@cesnet.cz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F18729D-D9BB-425C-AEB0-5BD94A601610@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings <fluffy@cisco.com> Subject: What is the right list name Date: Sat, 3 Feb 2007 10:14:43 -0800 To: ietf-pkix@imc.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=171; t=1170526501; x=1171390501; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20What=20is=20the=20right=20list=20name |Sender:=20; bh=YkJo/cmFFnxyrI1XBORfKrSvHZRjW09CgC+l1Da1AjE=; b=a2ACKjJ0vYZLopvDjOwXvGd1Hpv7IvHKxx6TxTEb21gNQM7xwohVII94uanHQuc9ItnPQCXX D4T61qdRDFuOEjDMP9G6AcXgVVg+/3322nTQIOAAjR2EJnWP8CQEfvJ7; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> A bunch of stuff sent to ietf-pkix@vpnc.org seems to be being forwarded to ietf-pkix@imc.org. This just seems like a recipe for confusion - can someone stop it ? 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 l12H3lbV030714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 10:03: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 l12H3leb030711; Fri, 2 Feb 2007 10:03: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l12H3hiM030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 10:03:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p06240823c1e91cea32b4@[10.20.30.108]> In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF218@EA-EXMSG-C307.europe.corp.micros oft.com> References: <73388857A695D31197EF00508B08F298185E9A54@ntmsg0131.corpmail.telstra.com. a u> <p06230956bf626880f0a7@[165.227.249.220]> <p06240800c1cdc354f330@[10.20.30.249]> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF0D1@EA-EXMSG-C307.europe.corp.micros oft.com> <p06240800c1e7fae10291@[10.20.30.249]> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF218@EA-EXMSG-C307.europe.corp.micros oft.com> Date: Fri, 2 Feb 2007 09:02:00 -0800 To: Stefan Santesson <stefans@microsoft.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: RE: draft-ietf-pkix-srvsan-00 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 10:13 AM +0000 2/2/07, Stefan Santesson wrote: >Let's say that I encounter a domain name in the form "xn--exmple-cua.com" >This is the punycode equivalent of "exämple.com" > >Is there any way the parser can know with 100% certainty if this >domain name was intended to be presented as "xn--exmple-cua.com" or >as "exämple.com". Yes. It is fully described in the IDNA document. Read the section on the ToUnicode function. >Both are valid domain names. >If the name is stored in UTF-8, no parser needs to wonder. Of course. This was discussed in detail in the preparation of IDNA. It is described in detail in the IDNA specification. >I think your logic is halting in one important aspect. Assuming that >UTF-8 to punycode conversion is simple, deterministic and straight >forward, why would it then be confusing to implementers? >If it is not simple, then the value of having the UTF-8 format is even bigger. >If UTF-8 -> punycode is simple, deterministic and widely deployed, >while punycode -> UTF-8 is somewhat more ambiguous, then there is an >obvious advantage of storing the dns name part in UTF-8. If you think that having domain names in PKIX fields in two different formats will not cause any confusion, that's fine. Neither you nor I can prove our case. I simply think that one format is better than two. >Finally, I can't think of any situation where a certificate user >would need to match the srvName from a certificate with a dns name >of a certificate. They are not used for comparison with each other, >but to be compared with a data external to the certificate according >to local policy. ...and that data is in Punycode format if it comes from the DNS. --Paul Hoffman, Director --VPN Consortium 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 l12H3lEJ030713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 10:03: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 l12H3lZh030710; Fri, 2 Feb 2007 10:03: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l12H3hiO030699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 10:03:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p06240824c1e91f33bb9c@[10.20.30.108]> In-Reply-To: <45C327E4.6020701@cs.tcd.ie> References: <45BE0814.2010709@edelweb.fr> <7.0.0.16.2.20070129115846.04accac8@vigilsec.com> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF280@EA-EXMSG-C307.europe.corp.micros oft.com> <45C327E4.6020701@cs.tcd.ie> Date: Fri, 2 Feb 2007 09:03:41 -0800 To: ietf-pkix@imc.org From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: asn.1 modules in 3280bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:00 PM +0000 2/2/07, Stephen Farrell wrote: >I'd be marginally against this change, on the basis >that its so late, might be error prone and I'm not >sure that the claimed benefit is significant (don't >most people just comment out one of the colliding >definitions?). I agree with Stephen and Sharon. This could easily be an add-on RFC. --Paul Hoffman, Director --VPN Consortium 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 l12EIjVU013685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 07:18: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 l12EIjdO013684; Fri, 2 Feb 2007 07:18: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 sottccs2.entrust.com (sottccs2.entrust.com [216.191.252.16]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l12EIghF013666 for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 07:18:43 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 11556 invoked from network); 2 Feb 2007 14:18:31 -0000 Received: from sharon.boeyen@entrust.com by sottccs2.entrust.com with EntrustECS-Server-8.0;02 Feb 2007 14:18:31 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottccs2.entrust.com with SMTP; 2 Feb 2007 14:18:30 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <DG45SCDL>; Fri, 2 Feb 2007 09:18:32 -0500 Message-ID: <04398A2C9F306C4690265C144089972D23E7C6@sottexch1.corp.ad.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, Stefan Santesson <stefans@microsoft.com> Cc: Russ Housley <housley@vigilsec.com>, pkix <ietf-pkix@imc.org> Subject: RE: asn.1 modules in 3280bis Date: Fri, 2 Feb 2007 09:18:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C746D4.A5079777" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C746D4.A5079777 Content-Type: text/plain I agree with Stephen. I think it is too late to do this within the current document - agree that errors could be introduced. If others feel it is necessary to provide these modules (I have no need for them), I would prefer the second approach that was suggested (a separate small RFC that defined these). Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Farrell Sent: Friday, February 02, 2007 7:01 AM To: Stefan Santesson Cc: Russ Housley; pkix Subject: Re: asn.1 modules in 3280bis I'd be marginally against this change, on the basis that its so late, might be error prone and I'm not sure that the claimed benefit is significant (don't most people just comment out one of the colliding definitions?). Having said that, if David (who'd do the work) does want this, I won't object, Stephen. Stefan Santesson wrote: > I would like to have the other editors and WG opinion. > If it is positive, then I assume it's a fairly straightforward process > if we get to it. > > Lets finish this up so we can ship this document. > > 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 Russ Housley >> Sent: den 29 januari 2007 18:02 >> To: Peter Sylvester; pkix >> Subject: Re: asn.1 modules in 3280bis >> >> >> Peter: >> >> RFC 3280 includes two ASN.1 Modules: >> PKIX1Explicit88, and >> PKIX1Implicit88. >> >> I have no objection to using three ASN.1 Modules in 3280bis: >> PKIX1Explicit88, >> PKIX1Implicit88, and >> PKIX1Extensions. >> >> I'm sure that you could help the authors figure out which type >> definitions to move to the third module. >> >> Russ >> >> >> At 09:43 AM 1/29/2007, Peter Sylvester wrote: >> >>> It may be a bit late but I would like to propose a small change RFC >> 3280 bis. >>> The text defines (as well as 3280) two ASN.1 modules. The >>> definitions >> contain >>> two types of information: >>> >>> - rewrites from X.509 etc >>> - new definitions like the id-pkix arc and extensions >>> >>> If one wants to use the new definitions in other specifications here >> is >>> the problem of ASN.1 compatibility when imported into other modules/ >>> I propose to add two modules: >>> >>> PKIXUsefulDefinitions which regroups definitions in such a way that >>> they can be imported elsewhere. the syntax definitions for the >>> private extensions. The actual >>> >>> PKIXExtensions in current syntax to use the >>> EXTENSION CLASS to bind the extensions the OIDs. >>> >>> If this cannot be included into the 3280bis I propose a small RFC >>> defining these modules. >>> >>> Peter > > > ------_=_NextPart_001_01C746D4.A5079777 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUS-ASCII"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2658.34"> <TITLE>RE: asn.1 modules in 3280bis</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>I agree with Stephen.</FONT> </P> <P><FONT SIZE=3D2>I think it is too late to do this within the current = document - agree that errors could be introduced. If others feel it is = necessary to provide these modules (I have no need for them), I would = prefer the second approach that was suggested (a separate small RFC = that defined these).</FONT></P> <P><FONT SIZE=3D2>Cheers,</FONT> <BR><FONT SIZE=3D2>Sharon</FONT> </P> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail= .imc.org</A>] On Behalf Of Stephen Farrell</FONT> <BR><FONT SIZE=3D2>Sent: Friday, February 02, 2007 7:01 AM</FONT> <BR><FONT SIZE=3D2>To: Stefan Santesson</FONT> <BR><FONT SIZE=3D2>Cc: Russ Housley; pkix</FONT> <BR><FONT SIZE=3D2>Subject: Re: asn.1 modules in 3280bis</FONT> </P> <BR> <BR> <BR> <P><FONT SIZE=3D2>I'd be marginally against this change, on the = basis</FONT> <BR><FONT SIZE=3D2>that its so late, might be error prone and I'm = not</FONT> <BR><FONT SIZE=3D2>sure that the claimed benefit is significant = (don't</FONT> <BR><FONT SIZE=3D2>most people just comment out one of the colliding = definitions?).</FONT> </P> <P><FONT SIZE=3D2>Having said that, if David (who'd do the work) = does</FONT> <BR><FONT SIZE=3D2>want this, I won't object,</FONT> <BR><FONT SIZE=3D2>Stephen.</FONT> </P> <P><FONT SIZE=3D2>Stefan Santesson wrote:</FONT> <BR><FONT SIZE=3D2>> I would like to have the other editors and WG = opinion.</FONT> <BR><FONT SIZE=3D2>> If it is positive, then I assume it's a fairly = straightforward process </FONT> <BR><FONT SIZE=3D2>> if we get to it.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Lets finish this up so we can ship this = document.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Stefan Santesson</FONT> <BR><FONT SIZE=3D2>> Senior Program Manager</FONT> <BR><FONT SIZE=3D2>> Windows Security, Standards</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>>> From: owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </FONT> <BR><FONT SIZE=3D2>>> pkix@mail.imc.org] On Behalf Of Russ = Housley</FONT> <BR><FONT SIZE=3D2>>> Sent: den 29 januari 2007 18:02</FONT> <BR><FONT SIZE=3D2>>> To: Peter Sylvester; pkix</FONT> <BR><FONT SIZE=3D2>>> Subject: Re: asn.1 modules in = 3280bis</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> Peter:</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> RFC 3280 includes two ASN.1 Modules:</FONT> <BR><FONT SIZE=3D2>>> PKIX1Explicit88, = and</FONT> <BR><FONT SIZE=3D2>>> = PKIX1Implicit88.</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> I have no objection to using three ASN.1 = Modules in 3280bis:</FONT> <BR><FONT SIZE=3D2>>> = PKIX1Explicit88,</FONT> <BR><FONT SIZE=3D2>>> PKIX1Implicit88, = and</FONT> <BR><FONT SIZE=3D2>>> = PKIX1Extensions.</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> I'm sure that you could help the authors = figure out which type </FONT> <BR><FONT SIZE=3D2>>> definitions to move to the third = module.</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> Russ</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>> At 09:43 AM 1/29/2007, Peter Sylvester = wrote:</FONT> <BR><FONT SIZE=3D2>>></FONT> <BR><FONT SIZE=3D2>>>> It may be a bit late but I would like = to propose a small change RFC</FONT> <BR><FONT SIZE=3D2>>> 3280 bis.</FONT> <BR><FONT SIZE=3D2>>>> The text defines (as well as 3280) two = ASN.1 modules. The </FONT> <BR><FONT SIZE=3D2>>>> definitions</FONT> <BR><FONT SIZE=3D2>>> contain</FONT> <BR><FONT SIZE=3D2>>>> two types of information:</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> - rewrites from X.509 etc</FONT> <BR><FONT SIZE=3D2>>>> - new definitions like the id-pkix arc = and extensions</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> If one wants to use the new definitions = in other specifications here</FONT> <BR><FONT SIZE=3D2>>> is</FONT> <BR><FONT SIZE=3D2>>>> the problem of ASN.1 compatibility when = imported into other modules/</FONT> <BR><FONT SIZE=3D2>>>> I propose to add two modules:</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> PKIXUsefulDefinitions which regroups = definitions in such a way that </FONT> <BR><FONT SIZE=3D2>>>> they can be imported elsewhere. the = syntax definitions for the </FONT> <BR><FONT SIZE=3D2>>>> private extensions. The actual</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> PKIXExtensions in current syntax to use = the</FONT> <BR><FONT SIZE=3D2>>>> EXTENSION CLASS to bind the extensions = the OIDs.</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> If this cannot be included into the = 3280bis I propose a small RFC </FONT> <BR><FONT SIZE=3D2>>>> defining these modules.</FONT> <BR><FONT SIZE=3D2>>>></FONT> <BR><FONT SIZE=3D2>>>> Peter</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C746D4.A5079777-- Received: from cmbg-cache-1.server.ntli.net (cpc3-cmbg6-0-0-cust320.cmbg.cable.ntl.com [81.101.141.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l12DDIbY007033 for <ietf-pkix-archive@imc.org>; Fri, 2 Feb 2007 06:13:22 -0700 (MST) (envelope-from although@emotionaltraps.com) Received: from WQCWQ (unknown [105.185.100.117]) by ntli.net with ESMTP id 27DDF766A776 for <ietf-pkix-archive@imc.org>; Fri, 2 Feb 2007 13:13:44 -0000 (GMT) Message-ID: <000701c746cb$e4dc80b0$0b80fd3e@hp> From: "or licence" <although@emotionaltraps.com> To: ietf-pkix-archive@imc.org Subject: Roadmap Projects Coding Module Date: Fri, 2 Feb 2007 13:13:13 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C746CB.E4DC80B0" 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 ------=_NextPart_000_0003_01C746CB.E4DC80B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C746CB.E4DC80B0" ------=_NextPart_001_0004_01C746CB.E4DC80B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Module owners hacking get the source build. Is, licensed mplgpllgpl, = trilicense. Form amendments along, no, longer although still contexts set. Talk lawyer merely faith effort explain, simpler language mpl! Licensed mplgpllgpl trilicense, or licence compatible. Different = licensing termsany checked into cvs tree. Updates will, easy, gnu = general gpl one lesser lgpl! Or, licence compatible with three those, eg. Build it testing releases, nightly builds. Used change npl current. Own product note that these. Products is licensed, mplgpllgpl, = trilicense or licence compatible, with. Arrived at hyperlinks has been = its legalese. Future updates will easy gnu general, gpl one! Containing types, please always! Lxr page details licenses under which code can be. What, requires and understand itself. Sections good if you want. Frequently asked both by arrived at = hyperlinks has. Get the source build it, testing. ------=_NextPart_001_0004_01C746CB.E4DC80B0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dwindows-1250"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A = HREF=3Dhttp://ftjbcn.lftnc.hk/?55919588><IMG=20 alt=3D"" hspace=3D0 src=3D"cid:000201c746cb$e4dc80b0$0b80fd3e@hp" = align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Module owners hacking get the source = build. Is,=20 licensed mplgpllgpl, trilicense.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Form amendments along, no, longer = although still=20 contexts set.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Talk lawyer merely faith effort = explain, simpler=20 language mpl!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Licensed mplgpllgpl trilicense, or = licence=20 compatible. Different licensing termsany checked into cvs tree. Updates = will,=20 easy, gnu general gpl one lesser lgpl!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Or, licence compatible with three = those, eg.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Build it testing releases, nightly = builds.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Used change npl current.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Own product note that these. Products = is licensed,=20 mplgpllgpl, trilicense or licence compatible, with. Arrived at = hyperlinks has=20 been its legalese. Future updates will easy gnu general, gpl = one!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Containing types, please = always!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Lxr page details licenses under which = code can be.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>What, requires and understand = itself.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Sections good if you want. Frequently = asked both by=20 arrived at hyperlinks has. Get the source build it,=20 testing.</FONT></DIV></BODY></HTML> ------=_NextPart_001_0004_01C746CB.E4DC80B0-- ------=_NextPart_000_0003_01C746CB.E4DC80B0 Content-Type: image/gif; name="in our.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c746cb$e4dc80b0$0b80fd3e@hp> R0lGODlhVAFgAYcJAAsAC4wABgqKBXaIAAYAinYAdwx8dcS+tbfSsrDR8DYoCGskAHsoCZQpArIl ANQbCQA5AC1FDUc9CGQ8AIM+AZdMAMw9Ad0+BQBUABFVADdbAlFcAYxsAJlgCr9TAN1nAASGCxOI ATZ/DlOFAIV9AJ2DB7JyAOSOAAKSACOkCUinAG2oAIuqAKGqAM6sAN+TAAPIByayDDSxDFG5AI28 AKy2ALO7Bui5AAXqACDrATvTAGDUAHHbAKnTALTqDNLdCwUANCUAQkkDNWcANH4NQ5cAOcsATtoA NAAtTiglNEcYNlMfToEYSZ8jObcdRtopTAA/SytLTE1GRlM8TIsxQZpOMsZDTeBNOwBYMRNoQDhU OGBtPIJRAKNrOLxSQ+JeMgSBQBqKTEVyRm5zRXiFQppzSbN0TtqMSwCpRi2dSEKRTmikOIqnOp+i PMSiMtmmQwDJOyTLNkHISmXDOHnNOJ3LTM3MPtGxRgDpPhXlTU7qO2zpTnHqRqXjN8rdQuXVMwEA ehkAgkcNdFcMgXMFjp0DhMYAdNkAdA0aiysZhjsie2gng38SeaEYjc0tguQjfQA/eipKdDRHc15G jYY4dZFLjrhEhuY5jQhucxhRejZggGpueolsc51uf8pohOJZdguOch94hjWKiGZ8fIR/eZR2e7R8 hOtzcQCtfh6ae0efe1SbgXytdq6tdcOUd9SpdQC+eBHJczPFcmi3jX++ia6+g73IfNLAeQbnjRTs gDLadWbuforXiqPjfb/UedLYfAIJwx4AvTEHtWAAzHsAwakFxs4AtesOtwEttCUZwU4Su1EftYYX wKMUzM4uw+4YxABOzhYzvExNu2lBuoJFu6w/wb8xu95CtgBRsyNZzTtZtlVosnJoy6BTs8pgxttR xACHuB17x0SNv1tzsnl9vq2CyLqOueyOxQSZwiejyUygt1GetoilzKCSzrecs9GdvwfBwhezvTS8 wF/NuYfAvZy8xv/99JygqH9+dv8DAwD7DvH/AAIE8P8O9wb5//jz/yH5BADyzXEALAAAAABUAWAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDM+/Mexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnJlSo82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3UuXpt+/gAMLHky4sGHDfBMrXsy4sdvDkCNLnky5 suXLmDNr3sy5M2LHoEPb9Ey6tOnTqFuKXs16YurXsGPLxty6tu3buHMvhCmgd+9/vgV49A08uPHj xosnH068Y3Pnv5kj/72c43HpwqFn1/7x+ezv4FM2/6/uXbl0keOfk4/OHT379tajqw8OP/52++Hz l77oW6Dxgf0RFKB/vSE04IHBAVigggMW1CCBAjAo4IL/QThhgw/qtlVM6dFn3nn1gfihch1id5+I 7ZVn3nUjknifivrFmF+J8r3XIowjzidcjS/ueGKIH6pI3JDZeUddjz/KqKRk/FFYYH8PYjhdhAFK SeWTC9oDZZYXGlQllxZueWWEYWaZoYZZcchjfC3eaKN2Hqbo43ZEJinkmt0dWeSc3Om45J+UNUnm lwl2KeFBYjroZKFaHocomI0OCmmikSJYYaRoeqXmnnTGiR+QnxrJ3nJ+5vljiabm6GGpOALqKmCC Wv8IIZhWGrgomZjOKimuGfZqJpeEMrjooWdmatWmn9p3oqhJqoqnsmwyB9KdSCbL7J55JvvqtqQl d22qcF737bg2lmeupyxqS9+5c1bH7bsvGSvvvPTWa++9+A4F77789stSvgDD5e/ABBds8MEIJ6zw wgyThtUmEIsF8SYB5zUxUBcjFMDGHAdQEMcEgSxUxhlPVLI9J1e800sTQ9aySBxz1LFHMf9Ts2Qv v9ySzv/w3HCMFaW8k9ADiWyP0UdvLBDSGEecEdEqTwX1xE4PRHXJV1MsENRJe7y00iF37LVCWVNM NUFXF1T21lWnbbXba2N9NttZR/0T0RfLrTXJWqP/7DTXRjPd9dhk52343hHrTffifiPO9tuI9934 4nz/XbXdOgmtuOIGVZ6QyIIP3pDnk2/etuVmX44Q6ZSfnnrfXGOOkeauT85443MDLjbhYYO9EOmH Q2677cEftPbwpdfOuewJsQwxSGU/r3POz/dcvc80b2yz9iHNbBL1m3DUcvThT3+99NV/BL746Vtf fvrjw9/+z5oFrTrywrcOO+qfgy347gwBXuLuNzzP0W5/kUPbABFYQAIybyDOC5/65sc+CbrvghXM IMy45z2ZxexmIlnfBbGHQQzGz4IdMZ8EeXbCFKLPgiSkH3hIaL4MUs2EIuwe97a3w5qBMCQizOH5 /943RA2+sIIrbN/6hEhBGc6wbC68YRSlGD0N6jAA2dMeCH84wSR6cYpKzJoVrwZGFR4RiTCUHwqd eJmkxO6BcDQIZYrIxjoujCh1i6Me98jHsNjxj4AMpCAHSchCGvKQiEykIhfJyEY68pGQjKQkJ0nJ SlrykpjMpCbD08dOevKToAwlKDdJylKa8pSoTKUqV8nKVrrylbCMpSxnWRhR2pIotMylLnfJy176 8pfA/Mcth0nMYvoxmMhkZD6SeUeLEOCZBLAHNAfyTGoSZJrSxCY1tclNaEbTm9E0SD4Gko9ylrMg 5jynPcxpzLyE85rXfOc7BRLOecKzIPKk50HsSf9Odo6TIeP85zrbaRd+StOaB00oQg2qUH3C06AG DSg5ASoQgQqUoHKB6EIditBs8hOb9vymNztKEIlWlJ0Isag6MToXjTq0nvg0CEO/GVOXxhOlJT2I RSfK0q68hAAhAeo/wAlUoXbEqEcVSVE/slSQIPUjy1ymR6QK1Y5QlarMLNhTh8oRpDY1qUxValfB ulWuiiSq/7gqR9Rq1bZm9WDeHOozzTrWuEJTrnP1SFyPmle66jUk6bRqOd2aVqgO9q2/xCpiB0aX i/Y0LouNrGQnu0jFUpZ+Ri1qX/va1bvula9OvStenypakljWsmk9bDpRe1kZZXasoAWrbL261df/ vha2fgVJYNd6WsKutbWvuq1wcTtbsoa1rsb9K2AL29be/ta3wO2MMxWaz4R+tKMwvedBqxvSlA60 ouBFJ0/D+1iswOSrwzWrZ0urXqaK9rOk1Wtezclb+k6VsKyNbmamy11wNpSm1PUvSa07YIaC96KO /a6CE1zetcwzuy+1Jne121DqYnchJiXvP3eq4Aa7RZ7VfPA2Q/xQCncXu9VMSDrFq+GVMtjDoHwx jMuysPzqNz8zzvFBbsxjg9m4x7GpSD67ic9pjjSe++wmiI18ZBbnVKclXamOxzLhbVLYwlaOqZYJ LNOU4lTK/RyvjKe8lSpz+bochTBH17zdfUIZ/8EdfvKCyUwWAGNZzWneaJHxLFJuvpmnL+ZwnOmM lPPSNb1CXS9nEz2SryLXqaG172qX+1zmAtky/F2of0UMYaIixM76tKk4OxxoMROayvcUsYXNXGE9 c3nLo4Yzeec861MfJSaZnatX+arrv+6a17S97XENe1j8Cvaqxb50Kn+sbNTkZcy2jra0p01tn3yH 2c0m2EVGSuQ1g1SbUD4pTqMsbjBXuy5opmd1Xa2QFY+51Oe+i02ze2IDT1TQow53vI/ZkrIietjs rSqyk11fxWI72/zyd3LjO2y81le3Va30wREOGyG72aNGhjWbxevYjpt633hBM6c13uqcZnjDGv+u Ncg1dV5F+1Wzuo45Z4k9cPwWe+IUf41WoL1ytlw75wzrudCHTi/w4BzomJ2tsB2+682WFav2Jfax kQ5XpcsWtk3PtW7py1Zjd53qs7F4hF899lC32Z4ZlnPK8U10ttiZ3loeOU3RPmgGo5TtbVfL28vO dwCr+Znjtjugx513qhg60eDMLaOTuvinM5e1X7c02GWzbZKCmuyXj+hAE4zyWfO88Kj2NsY9qu4U n7if6lxti1UKevP+fPK7PDrsZdT62tv+9hH5PO4dgmtFx5zxdi2t8NlrW6e7V+akLWvEH05zqUZ9 9iKZ7pVT3Gbtrnum7KZ+hdedTQz7c7y1xvv/7iOSbrNX/8J833Kn049lsnNc3+EH/+1/Gtq8NhXm iz80cSEt7MZDGrf5B3EGd1qSBl3Q5xFil3Gpdn6lp2r2tndjV08hBm58lmKEN2j3Jn/jR34ltoCZ J3olJ2Gaxm0duGTgFmtOhoIqV3uG9mhWx3D6t38NF4D5h17EpXy/hVbP5XzNZYAHOBPB51mglXhZ l2szd2i9pnRJ6IK5dWw1J3E3R3A/2BG6oXsbeC9WeIVa+ElTOEs7t4XuhGJZFmDo512op1Opt2Jg +BXXB2JimGdedk5st1NZuIbWRn//5n/6h4M6uHwSJ3lduC+/xmh6+GtnBYiImFrO93yBuC2D/4h1 7fVy9cd8lXZflZiIjbgZmYZxJHZ2AnZ5KghvcVaHdtgUQ9aB3TdyG2dydbd2GliKQkF/TIhejmaD gCVpu/WEipiJjyR7vFhxWUGKsNgUv1iMxrhsx8hG8GV8nRVbpuWHUxWFvpiMp1FbZKV1zWhauEhp hRV51LhfFHF6Zjd37JeBavdnKziM+vJT9hdWS3V/MtiDlniLU/eN0oURHwh37odNgYdhtKaOtyYT jsZV/kdUz+iNAueD9lgZGbF+2/df7faP30WHrwiQVtFkpMdmoMZQarhOLnaG4maRhfYa07iQiFSS JpmS2SaS+RIjKKmSssGMcjVanYV/mnV1EP9Xj1JHiTBJGNvmhup2ZxrJfej0ffF3YBXJkhnRgoRI kDEYgE7ZhDnIjX+IkD3JGQXplPBVk00pld2YkztplVc5E9KnjxDIZ+ZXeiH5ihzWkUppipsWYVVW byGIlBgokXf5lkehiiIYgepnbxLFeSmXlHppEbLIhAT5XshHi2eFiwVIiVI4lvTzkpJZR5RZmZjZ S4VZdDJymZmZGcZHhMOHf7zmjGC5i1uni595GaEJcMkVg9mYmn1ocPKIiaupEhZHjqfHag7JT2mX lB63mUmhm6PXfn8Hh745ioEWnMKJFHAXUhQIgqyWTRcoY+LXnK7hElmpXI+4cIkngNBoiZ7/eZti 15dl6JCY92dt6YrYqRGHWVd25WvIV5qGWHA6+YSTdps1pp/g+BXC2J6jwZ+MBKAa0i/jKaAfIWTc doLU16BAWZwjNmApeIGrZ24EKhC4VlzOKJObpaGReIuD5Y2ReaAICoAa2pTw+KFRyXiHiFouepol SoXSZ5xyWX36mJY4yoopeI55SaAZypXcCYmRSIOKJ5WAl2z5RZsxChKVV3ae9pxxaZ45+n49ypwX Kkct+JS+5o5baqJC2qKICHXzuKR+sXS1WKRFmHxG+FS5mIv3SaZMyhb/eaV3Mad0ihBwmqeVKRZ2 eqcR8RKQ4BGQMKiD+g+ByhGBSqiGSqiJ/6qognqozzimmOiYkQmnFQEJBIGpmToQmqqpAuGpoJqp nhqHG4ZggneUfoqlLQGphvoRkHqorPqqHSGrrQqmkvqilUiiKXmpojqonGoPofqrnyqswDqs3mWl GIhvfZqqBjGqozqswWqswEqom1qsvbqWqFqUH8msN+GszWqt4AquncqpjPqsVDqK/piO3EoR3vqt xCquwtquxyp/svZx61oQgKqo5Tqrs1qoiMqv/BqrjSmNb8pbkqqnrqKrCIuAYbGs9/qwuLGwggSx FLuGEnux9lixGnuFGPtHG6sYHRuyxfixJGt7IstGJbsXJ+tEKasXKytDLZsXL0s/MYsXM//7MzV7 FzfbMDnbs/G2s0Hns3MBtI3ED0ZrtByBtCBxtPzwEUzbtP+gtEkLtUtLtR2BtE97tFH7tB6RtVLb tV4Ltlp7tVxbEkzrtGNLtl/7tVVbtmprtW47tWkrt2trtVO7tVW7tV4LtVLbt3bbnxNxtANhtPZA uAdhuAIhuInLD4XLuIubEIg7uIwbuZJbuY/LEJQruY7buI6LuJlLEIbruZ27uaE7ugsRuYp7uapb uqQ7uq1rugVBuKmrurS7uq1LFp/7uY0LupvLu7Ubu737uLl7u797uMFruZYrug8hu71buperu8hL u8prvAhBuc4LvJzbvMGbudO7u8ToEmz/S7Yi4bfj27Thi7Z5e77ke7cmob5/i7frexJYC7d8W794 a7Z/G7/uW74hMb/pa75Uy7bhq7/vGx7ne795y75tW8BiG7Z7i8B+m7X968Dv678K3L4ADLbsa8Ek McABTL8JHMIa7MHw+8Hoe8IQzMDfccAsbMITfMAajL77i8A0PBIzLMP2ixJKW7dvW8ItHMICnLY/ /L9EfL9BDMQurCRDjMT8C8MXfLfuO7c1zL8iLL5xi7/im8UL/MRcHL8nvMQjnL8ZDMV2S8IK7MSz AcYxPMUbrMIkPMM8jMETPMc7rMJaTMP7W8dzjMIwzMEoHMZFTLd/fMZJrMQVXMBxzMcM//zGh6zF aMzFT6zHkLzGF2zGkjzIiZzAanzJVky/R5wwQjzGIhzKeIzIYszGcfzIbKy3alvJi9zIqJzDN8zK jpzEpEzLuJzKZfzJa+zFS1K2Yau3uzy2vEzJZCzBR/zAVYy2c1vMDRzKs3y2LyzNPUy3YizFVyzM vlzDZpzCniG0rbG34jzO5FzO5nzO6JzO6rzO7NzO7vzO8PzOTEG0CgPOckHPCWPP+kxn+Iww+/wW /Xww//wYAV3QBn3QCM1YA+1zCd3QDn2yCx3Rj/XQFI1MEn3RBFXRGu1LGN3RHv3RIH2HGz3SJF3S Jn3SKI1YIT0WKd3SqLTSYuHSOAbTYDUh05xE019h0+CB0zmt0z7900Ad1EI91ERd1LPH00htN0a9 1ISU1E4dMEwd1VLN0U9d1fYSEAA7 ------=_NextPart_000_0003_01C746CB.E4DC80B0-- 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 l12CBlk3001750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 05:11: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 l12CBlP5001749; Fri, 2 Feb 2007 05:11: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 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 l12CAj5m001679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 05:10:46 -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.0.685.24; Fri, 2 Feb 2007 12:10:44 +0000 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, 2 Feb 2007 12:10:44 +0000 From: Stefan Santesson <stefans@microsoft.com> To: "md@e-net.lt" <md@e-net.lt>, Russ Housley <housley@vigilsec.com> CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Date: Fri, 2 Feb 2007 12:10:41 +0000 Subject: RE: Sample end entity certificate Thread-Topic: Sample end entity certificate Thread-Index: Acc4T8PIQqcf3YzkS5SWFUDsVj+idQOcsJXg Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF2D4@EA-EXMSG-C307.europe.corp.microsoft.com> References: <4234.84.240.23.130.1168824711.squirrel@mail.ssc.lt> In-Reply-To: <4234.84.240.23.130.1168824711.squirrel@mail.ssc.lt> 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 l12CAk5l001681 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Inclusion of optional extensions are optional since they are situation dependent. What can be recommended in one implementation may be totally redundant in another. RFC 3280 is not designed to do implementation specific recommendations. For that purpose there are numerous certificate profile documents aimed at certain usages of PKI. So what can be recommended in your case, can still be optional in the basic standard. In this regard, the standard is correct. 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 Moudrick M. Dadashov > Sent: den 15 januari 2007 02:32 > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: Sample end entity certificate > > > Russ, > > but RFC 2119 also does say: > > "OPTIONAL", mean that an item is truly optional. One vendor may choose > to > include the item because a particular marketplace requires it or > because > the vendor feels that it enhances the product while another vendor may > omit the same item (section 5). > > and RFC 3280 also say both the "key usage" and "certificate policies" > extensions are OPTIONAL > > Don't you think this is some how confusing? > > Thanks, > M.D. > > > RFC 3280 does say: > > > > Conforming CAs MUST support key identifiers (sections 4.2.1.1 and > > 4.2.1.2), basic constraints (section 4.2.1.10), key usage > (section > > 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. > > > > It does not seem to require that these be included in every > > certificate that is issued, but looking further into these sections, > > I find a MUST statement that is not supported by this certificate: > > > > From section 4.2.1.1 (Authority Key Identifier): > > > > The keyIdentifier field of the authorityKeyIdentifier extension > MUST > > be included in all certificates generated by conforming CAs to > > facilitate certification path construction. > > > > I would encourage the CA to include key usage and certificate > > policies extensions. > > > > Russ > > > > At 08:05 PM 1/9/2007, Moudrick M. Dadashov wrote: > >>Hello, > >> > >>I'm attaching a sample end entity cetrificate that the issuing CA > claims > >>to be RFC 3280 compliant. > >> > >>The certificate at least MUST provide document signing functionality. > >> > >>Some of us say it's technically correct but has no legal purposes > defined > >>and therefore can't be used for test purposes only, while others say > it's > >>a universial one and can be used for all purposes. > >> > >>Any comments are highly appreciated. > >> > >>Thank you for your time, > >>M.D. > > > > > 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 l12BxQ63000903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 04:59:26 -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 l12BxQ5X000902; Fri, 2 Feb 2007 04:59:26 -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 l12BxPx6000894 for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 04:59:25 -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 2819468071; Fri, 2 Feb 2007 11:59:22 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0160D24EA3; Fri, 02 Feb 2007 11:59:22 +0000 Received: from [134.226.63.198] (cswireless63-198.cs.tcd.ie [134.226.63.198]) by imx2.tcd.ie (Postfix) with ESMTP id 1AEEA68071; Fri, 2 Feb 2007 11:59:22 +0000 (GMT) Message-ID: <45C327E4.6020701@cs.tcd.ie> Date: Fri, 02 Feb 2007 12:00:36 +0000 From: Stephen Farrell <stephen.farrell@cs.tcd.ie> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stefan Santesson <stefans@microsoft.com> Cc: Russ Housley <housley@vigilsec.com>, pkix <ietf-pkix@imc.org> Subject: Re: asn.1 modules in 3280bis References: <45BE0814.2010709@edelweb.fr> <7.0.0.16.2.20070129115846.04accac8@vigilsec.com> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF280@EA-EXMSG-C307.europe.corp.microsoft.com> In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF280@EA-EXMSG-C307.europe.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1160D24EA3 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.60.4) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I'd be marginally against this change, on the basis that its so late, might be error prone and I'm not sure that the claimed benefit is significant (don't most people just comment out one of the colliding definitions?). Having said that, if David (who'd do the work) does want this, I won't object, Stephen. Stefan Santesson wrote: > I would like to have the other editors and WG opinion. > If it is positive, then I assume it's a fairly straightforward process if we get to it. > > Lets finish this up so we can ship this document. > > 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 Russ Housley >> Sent: den 29 januari 2007 18:02 >> To: Peter Sylvester; pkix >> Subject: Re: asn.1 modules in 3280bis >> >> >> Peter: >> >> RFC 3280 includes two ASN.1 Modules: >> PKIX1Explicit88, and >> PKIX1Implicit88. >> >> I have no objection to using three ASN.1 Modules in 3280bis: >> PKIX1Explicit88, >> PKIX1Implicit88, and >> PKIX1Extensions. >> >> I'm sure that you could help the authors figure out which type >> definitions to move to the third module. >> >> Russ >> >> >> At 09:43 AM 1/29/2007, Peter Sylvester wrote: >> >>> It may be a bit late but I would like to propose a small change RFC >> 3280 bis. >>> The text defines (as well as 3280) two ASN.1 modules. The definitions >> contain >>> two types of information: >>> >>> - rewrites from X.509 etc >>> - new definitions like the id-pkix arc and extensions >>> >>> If one wants to use the new definitions in other specifications here >> is >>> the problem of ASN.1 compatibility when imported into other >>> modules/ >>> I propose to add two modules: >>> >>> PKIXUsefulDefinitions which regroups definitions in such a way that >>> they can be imported elsewhere. >>> the syntax definitions for the private extensions. The actual >>> >>> PKIXExtensions in current syntax to use the >>> EXTENSION CLASS to bind the extensions the OIDs. >>> >>> If this cannot be included into the 3280bis I propose a small RFC >>> defining these modules. >>> >>> 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 l12BIlnQ098056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 04:18: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 l12BIl2J098055; Fri, 2 Feb 2007 04:18: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 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 l12BIjDO098047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 04:18:46 -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.0.685.24; Fri, 2 Feb 2007 11:18:44 +0000 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, 2 Feb 2007 11:18:44 +0000 From: Stefan Santesson <stefans@microsoft.com> To: Russ Housley <housley@vigilsec.com>, Peter Sylvester <Peter.Sylvester@edelweb.fr>, pkix <ietf-pkix@imc.org> Date: Fri, 2 Feb 2007 11:18:43 +0000 Subject: RE: asn.1 modules in 3280bis Thread-Topic: asn.1 modules in 3280bis Thread-Index: AcdD0MCOsAKS3mHPSpqTvMaCTXvR4AC6tYRQ Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF280@EA-EXMSG-C307.europe.corp.microsoft.com> References: <45BE0814.2010709@edelweb.fr> <7.0.0.16.2.20070129115846.04accac8@vigilsec.com> In-Reply-To: <7.0.0.16.2.20070129115846.04accac8@vigilsec.com> 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 l12BIlDN098048 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I would like to have the other editors and WG opinion. If it is positive, then I assume it's a fairly straightforward process if we get to it. Lets finish this up so we can ship this document. 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 Russ Housley > Sent: den 29 januari 2007 18:02 > To: Peter Sylvester; pkix > Subject: Re: asn.1 modules in 3280bis > > > Peter: > > RFC 3280 includes two ASN.1 Modules: > PKIX1Explicit88, and > PKIX1Implicit88. > > I have no objection to using three ASN.1 Modules in 3280bis: > PKIX1Explicit88, > PKIX1Implicit88, and > PKIX1Extensions. > > I'm sure that you could help the authors figure out which type > definitions to move to the third module. > > Russ > > > At 09:43 AM 1/29/2007, Peter Sylvester wrote: > > >It may be a bit late but I would like to propose a small change RFC > 3280 bis. > > > >The text defines (as well as 3280) two ASN.1 modules. The definitions > contain > >two types of information: > > > >- rewrites from X.509 etc > >- new definitions like the id-pkix arc and extensions > > > >If one wants to use the new definitions in other specifications here > is > >the problem of ASN.1 compatibility when imported into other > >modules/ > >I propose to add two modules: > > > >PKIXUsefulDefinitions which regroups definitions in such a way that > >they can be imported elsewhere. > >the syntax definitions for the private extensions. The actual > > > >PKIXExtensions in current syntax to use the > >EXTENSION CLASS to bind the extensions the OIDs. > > > >If this cannot be included into the 3280bis I propose a small RFC > >defining these modules. > > > >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 l12ADuY4091967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 03:13:56 -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 l12ADuQK091966; Fri, 2 Feb 2007 03:13: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 l12ADpxT091946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Fri, 2 Feb 2007 03:13:55 -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.0.685.24; Fri, 2 Feb 2007 10:13:50 +0000 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, 2 Feb 2007 10:13:50 +0000 From: Stefan Santesson <stefans@microsoft.com> To: Paul Hoffman <paul.hoffman@vpnc.org>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> Date: Fri, 2 Feb 2007 10:13:43 +0000 Subject: RE: draft-ietf-pkix-srvsan-00 Thread-Topic: draft-ietf-pkix-srvsan-00 Thread-Index: AcdGPoO7rzQJ5ntASoe7hYkn4KB5FwAb2Iwg Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF218@EA-EXMSG-C307.europe.corp.microsoft.com> References: <73388857A695D31197EF00508B08F298185E9A54@ntmsg0131.corpmail.telstra.com. a u> <p06230956bf626880f0a7@[165.227.249.220]> <p06240800c1cdc354f330@[10.20.30.249]> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF0D1@EA-EXMSG-C307.europe.corp.micros oft.com> <p06240800c1e7fae10291@[10.20.30.249]> In-Reply-To: <p06240800c1e7fae10291@[10.20.30.249]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l12ADtxS091951 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Well, You could perhaps help straighten one thing out about coding decoding punycode. Let's say that I encounter a domain name in the form "xn--exmple-cua.com" This is the punycode equivalent of "exämple.com" Is there any way the parser can know with 100% certainty if this domain name was intended to be presented as "xn--exmple-cua.com" or as "exämple.com". Both are valid domain names. If the name is stored in UTF-8, no parser needs to wonder. I think your logic is halting in one important aspect. Assuming that UTF-8 to punycode conversion is simple, deterministic and straight forward, why would it then be confusing to implementers? If it is not simple, then the value of having the UTF-8 format is even bigger. If UTF-8 -> punycode is simple, deterministic and widely deployed, while punycode -> UTF-8 is somewhat more ambiguous, then there is an obvious advantage of storing the dns name part in UTF-8. Finally, I can't think of any situation where a certificate user would need to match the srvName from a certificate with a dns name of a certificate. They are not used for comparison with each other, but to be compared with a data external to the certificate according to local policy. But even if it was the case, I can't see the serious challenge of having one in punycode and the other in UTF-8. It really feels like a trivial problem not worth re-opening what was previously agreed. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: den 1 februari 2007 21:17 > To: Stefan Santesson; ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-srvsan-00 > > At 5:01 PM +0000 2/1/07, Stefan Santesson wrote: > >Different name forms are allowed to have different encoding, that is > >nothing new. > >So why do you come to the conclusion that the dNSName alt name must > >have the same format as a service name? > >You seem to state that this is an obvious requirement, but it is not > >obvious to me. > > It is obvious to me that having different encoding rules for domain > names is likely to confuse implementers. There is nothing in SRV > names that make them any different than "regular" domain names. > > >We discussed this in the WG and concluded that there are advantages > >in using UTF-8 encoding and storing the service name in a form where > >it can be printed and displayed. There must be a rationale why we > >should move away from this. > > I have given mine; you may or may not like it. > > --Paul Hoffman, Director > --VPN Consortium Received: from [193.50.189.77] ([193.50.189.77]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l125JJaG068849 for <ietf-pkix-archive@imc.org>; Thu, 1 Feb 2007 22:19:20 -0700 (MST) (envelope-from desirs@fbcbeverly.org) Received: from BFJBPYT (unknown [153.143.194.54]) by fbcbeverly.org with ESMTP id 56BAFE562EEE for <ietf-pkix-archive@imc.org>; Fri, 2 Feb 2007 06:19:26 +0100 (GMT) Message-ID: <001101c74689$ae049bf0$00000000@oustry> From: "amiche" <desirs@fbcbeverly.org> To: ietf-pkix-archive@imc.org Subject: us AppleSc ript Date: Fri, 2 Feb 2007 06:19:14 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C74692.0FC903F0" 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 ------=_NextPart_000_000D_01C74692.0FC903F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C74692.0FC903F0" ------=_NextPart_001_000E_01C74692.0FC903F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Operates impetus wider, usbased serviceone afford irons kinks. Acclaimed hamilton urgent family, changes, reflect seeing double. Asking, advantage happening wouldnt speculate appliances ce usedon = reassured. Factor in immune evolution expert poet dave. Pasate akii inforweb macrmiddot! Billion estimate positioned optimism pacific. Spending, naturally expect = winding. Vivo morto sarai sempre? Centurys prepared tuition government. Dont forget ky bears, tienes, = duda. Glitch objected before, notifiedwe accepted? Necesita protes ya = ke, dispone un bot para tal. Theright markthe windsor retir ement = community east north buildings. Enjoy meetingthe regular themonth baptist church savoy. France sur mods = parle tout soyez zen pub restez. Overlap indeed detectthe proved. Das = chatten nicht vergessen. Altr houseitaly pazzi fate spamno floodno capsno. Amd amdchip, attaches andmakes, power, supplied, drivedock mounted = titanium. Onmedia recomienda neal morse, sola, scriptura mitico sei lui. ------=_NextPart_001_000E_01C74692.0FC903F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://southd.hk/><IMG = alt=3D"" hspace=3D0=20 src=3D"cid:000c01c74689$ae049bf0$00000000@oustry" align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Operates impetus wider, usbased = serviceone afford=20 irons kinks.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Acclaimed hamilton urgent family, = changes, reflect=20 seeing double.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Asking, advantage happening wouldnt = speculate=20 appliances ce usedon reassured. Factor in immune evolution expert poet = dave.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Pasate akii inforweb = macrmiddot!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Billion estimate positioned optimism = pacific.=20 Spending, naturally expect winding.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Vivo morto sarai sempre?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Centurys prepared tuition government. = Dont forget=20 ky bears, tienes, duda. Glitch objected before, notifiedwe accepted? = Necesita=20 protes ya ke, dispone un bot para tal. Theright markthe windsor retir = ement=20 community east north buildings.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Enjoy meetingthe regular themonth = baptist church=20 savoy. France sur mods parle tout soyez zen pub restez. Overlap indeed = detectthe=20 proved. Das chatten nicht vergessen.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Altr houseitaly pazzi fate spamno = floodno capsno.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Amd amdchip, attaches andmakes, power, = supplied,=20 drivedock mounted titanium. Onmedia recomienda neal morse, sola, = scriptura=20 mitico sei lui.</FONT></DIV></BODY></HTML> ------=_NextPart_001_000E_01C74692.0FC903F0-- ------=_NextPart_000_000D_01C74692.0FC903F0 Content-Type: image/gif; name="recordsas thevolume.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c74689$ae049bf0$00000000@oustry> R0lGODlhYAFMAYcJAAAABIwEAACIAH93DgAIf3IAgwSBiLG2vLzay52/8UUnAG4bC4AcAJgSDswY ANwUDQZCAB5JADwzB2ZOAHZHAJ86AMVACOIxAABoBiVXADJrB1NXDo1rCqFaAMhmANdhAAV2DSuM AEeFDmmGAIl0AK57ALxyA+CFAACrDimtADueBWKaAIqoAK2cCMWoC+ygBACzCB/FAEa2AGLHAHLG DK69DLK0Ct+yAAzSByLXAEHlAGvfAHrlBKDTCcnuANjSAAMJPx8DRT0IPWQFMX8ASpQARr8AONgJ NAAkPh8ZM0gkRFErPnchTqMrPMUVO90bPQRFShY9ND1ESlI6QHVBPJNCQMA8M9k0SwBmQCBZTTdZ SlZkQ3hWAKNaQMZXSeFdOwCASCpzMkmHPGp+PYWKS6p8Rs50QNp7OwGdPRyaOkadOl2tO3+sTZmS Q7mhStuTPgWxSy6/O0mySWTFOYTDO6S8Sb3CTO20OQDkOBvrNUjqRlPhRYTRMaXdTLzqRuTkRAkA gRkAc0QAjFYAhowAdpMAcbEGctIMcgwkiCAXcjkcil0md3obhJUkeMEViuwogQA3gCVOdTpLi2xG fIpNdZU7i7s6f+IyiQBhjidhgT1tclZVeXhshaNWf8FTc+pagwl3iSB0hUCCf1+Od4eMcptxhrR4 je17gQWsdiidiTmlfFOji4mefZ2tc7uocu6RcwDIgx7EiDrKf1vMenS5haXKebW/gePNcwzXfxju d0vrc2Dphnjrfp7nhsfRfNXfdgQJyyIEzTMAy1wAs4wAvqcCurEAs+cAtgsjsSkcyUsVym0avosT wZohyLoWt9UpsQ1HuyRJxjhEulxFuXIzu6k2ss08vuNIxQZauhZRzjxdsmJVwINVvJlmsbZguNdl yQ2HuSuKtjN7umOJt3x5x6x5yMWMy9uDvQqXvhWpzkmTtWypvXGZvZqescmtueaoywXCthTBw0Gz wl6yv3vAs6m+wvT96Jyin3t/h/8DAAX/DvnwAQoA//gA/wv6/P7w/yH5BAACsHkALAAAAABgAUwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqtPevo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQP9tHEq0qNGjSJMqXco0qNOnUKNKnUq1qtWrWLNq3YqTqdevYMOK HUu2rNmzaNOqXUuWq9u3cOPKnUu3rt27ePPq3cu3r0u2gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDMX9Mu5s+fPoEOLHk26tOnTqFOrXn1as+vXsGPLnk27tu3buMWy3s1791ABAooCBxsgQO6E kCAZ/vBhNkngHqGblH6TOtDiIIsHKIm9o/btVJN3/xQvniV5SCeTq0f/bz17nMxBMv8gcv78f/bj 56VufWR/mv/x9B143ZGknXcEgidVeeW51GB6740XYU75daSfSfFdKFdCwwk0XIcgAvehiB6SWGKI HdojIorBqbjiQC9G9N1AxS00Y0E1kpWcQDvuaM96PKo3kHs/KkdkQT4OqdxR9g3EXENP2hOlYc+t CJ10VwrQUZZa/oOlltZ96WWXWW4JJplnmsnSdx4NKBJ2BSJo1XoSthchg+jhaeeefHrknp/qUXif hfaVpF+FcXHYoosnthgioyVGmiKkI0rqaHCPWrnoQzfmmCNBAxon0KdlAVnkqUoGiWqPRi6ZpKoI vf+qUZNSNlcrQlMSlGtiKbIYKaO9Xgrpr5UCK2ymm040o6eiHvQpqaUKeeqrPrKqqrWophrrkkQ1 GeWuTtpaELhrVRldl2OeqyZ/aKarbrpixtuumC2x2d29Csr5T5xzvnfeR3oGnCd7D/YZUsE1FXoo ffgx3PBHC+vF7rtmiuhuxeiuiPG5Fo9J75cBmuQmggXyiy+bVTWI58r+0vmvwXa6TCd8hRJ64c0O 25xzZyF/xm9vemkItH/okvbz0HcJjfTSTDft9NNQR32SRpNOBm1mskJG7m0mKlR11YuReiOOA46q nVjVcotkq5LlSutB8wmUn7iBTdczxZ25iS932+3//ZSeIiG8V4URh6Q0oXuV6bHGi7e7OMZFZ4Vy dvlSru/RPQE+878C/8lVzfLt/HB9otuleJmnpymvmltN3mbllpMMO1AzAzzwngLjPuFVoHt0OKK+ l66V15geWzylx2uKfGBj23M1qM0yi7a0RQppbdrTsg3Y27fCbeuUWx+mafLkWzosscmq1WmzCD0r 6vNKmYr99a6yje32cXfvvdzihq+WuetSXZrgNcDUvcVesCtZvvwGFZUR7HYv49zt3KIw0RWucInL mAAJ2DGQOe5uUhlZqPS1r8q57m93khmf/iTBz9VsbojTWfCkdhfM0RArh7uh0WanQ94Jr4dADKIQ /4dIxCLS5Dg2Yh8SE+O/ywBwJYrbS5xO+JEDVZGHQcldaDTUu+C9cFCJQgjYHjJGxJRNega52tmi BSvM5Kd7/nvSt+hWN6KBhHGr0xgeO9Y6K8buiiGhIgrrxDJABWpzgcIhGCH2wwv+ECuKIgiyzBes 9JWxLM0zm7PW5zwlTg97BMEWq9TWRrNwj38KAV/+GjMp5blokr9qVPrQ0jz4SS9UZpFf/axXv2xV L2tk4V4c+/c9OgLmiRfj2Lw0+C4QTgVlNmRgCfulxQhOcIW7o8oXMeQwDL4lkjASViyLNaxHMe9s anyfOqGHliSJUnv3A2VavGVMVeqqmI6xUqMkuf8oFJ1Pn2wpWyc5aTZowQ8s7txl2ngZSlOd5Y21 opU979nEJRLmoLMB5mAqalHYYPQ1DkUMRztK0pKaVClGTKlKUbKRSyrmoybVaFhGGht9lpGcjRHb Gsm2PpgmRZ4Mkena5knH8EkUoqycpRiV+tJlrTMhNULjWIC6EaF6BaKrHBc+75lPS14KljEyTCY1 2b6n+hQpDtWltBaq0FKO5ZRbmyNXu2qQr5XPpedMp0Lcd9afcmt+vbzfUK26FLgaM1y7oilgwMai u+IVMLX0JDvJ2tejJBRIgPXlL7VnyqzGdav6S2pdj2escj52LQSFavSeqqO1kjKz1AosKYO5ys// ovK2hSlJfwwYxWTOBYGBVNAUExSeB2LzuC+rk+4UiTNGxtCbfLGSu6SLOj7+FpoiFK4J/bgg48bM u9Zk2TWnAjzQ4ay5K62KDdP7kxyO5qSdhO9hFBsZ9tr3vvjNr355s16/CK4v7t0NvVQzXMxNTpBO 8dx/TbJglTTYJVxcpBfvA8O5gPO0lDkja2m0TqlO71qzbQhhxfJGuSYksYdVTFhjBNBXihPDYxlr fMmmSQ+HBbDUUytbg7Rj9+D4siH2HrmMWtQUH1O3kQsg65ppXbdQ8Wh7k2YDjVvNCSa3c4SEoJW3 jJIuSjh0YOZMmPT4Qcb59oDcNTBxS8jdKSey/3OHpHLLVJjl5cL5wRM2nPCEFuCtEM+cxQp0P5ka 0DUe1MaVJYqsMttQEGvr0fTLnqMlYlhcFTkxAOTtMlln5rgAN3bS7K9PClZl5LasznVu4XJhZigK MwyDfH4kVy78VUHLcnmDESguZzzQ1UoWoa/t5S9htVAeC1vSkV4V9RaC1LdNNFyKoaGo9yuTPotG vomW71foKxlqe/uG2g63uMEitWnzBc95sTZo/gxjyRj012Ttdbar+lf7BbkxKD5xVkPLmHZnuKeq ley8NZJQSU8Gq7bV374Xw1gTjS+c/sbkTuO9yTTCmykFH2WrdrzZETOl0swuJrfZwmLjlZafZv+c OK8rTmM2OvqyBom0x5UCcn2jcuSBsXWlGpuYyO5ViQOnd6riqTYiJRstwjSywpEKGZ07NpaHGRtG 332WjHO24MjmLNJra+QhK13FpN15+c4n1p3qdLIUb+3Qr17vl2v9oVyfa8JzSzQ+7pGAkKvLyNis 3dcpECsKfuB4Wahl5p63m68G3ug2dNKgjxspOHdMubH4bZqou/KYz3xUHs/5znv+86APvehHT/rS m57umk89b07P+tCr/vWsab3sOw/72qNm9rjPve53rxnb+/73wA9+SnhP/OIb//h1FL7yl8981SP/ +c5pvvTpAv3qW//62M++9rfP/e57//vgD7//+MdPfqRM//xhXAo/+CGW9RfE/RKBf/lpQ5L1d8T+ /8C/SdbP//zzAyT6V3//53/3N4D7Z4AFSIAKaH8BqIDot3oIAX8SyH4LIX8CYYEPMYEXSIEVyIEb aA8aCIIeSBAYOH+5EYITWIIYyH8ayIIjKIIfCIMimILsR4M1SIEtiIMsuIElaIKy4YL8F4MqGIQy 6H5GqIMGAYQoeINIuIRA+IE5GIM+6EQCCIQFyIICuID/x4AD2ID+Z4Va6IBcmIBf6IIJiH9ciIUP 2BoJoYRIyBBHCIU3KIUD4YZCOIdyeIdPCINROIWucYBkGIYjMYYESIheKIhhqH+GaIBoyIhb/9iF jxiIa0gaHUiHO/h+lxiFLhiBb8iDnWiDdfiJOkiEl+iHlnEVhziJy4cWPWiKrviKsJgQqjiLVKEQ RNgQQ/iCatGKsRh9IpGKWfgRwMgSw/gSxZgTx0iLbpGMwoiADigTzLgS0VgT06iMWKGGaliGkqiN 2Nh/V+iM2hiOAOiN3UiO5tiAZviNZxiJz2iNw8OJoZiHfDiC8keKTdiJUhiC8TiPbxiH/JiE95iH /siLvUhug+iIWGiF6OiIHqGQ6diQDNmOjSiGkFiGhDiO67iOYFiN7lgViuiMC4mRgRiSBwmR2ziR H5mRzfiLFYmSSriNHXkVbciBfeiP+yiDRf+IhytIk/iYkzhZk3iIifK4hAWZGBZYiplIjzxJgrdY ikw5irqYlE9Jg3S4j1R5hzdZlFq5lVzZlV75lWAZlh0Vk2RZlmZ5lmiZlmq5lmzZlm75lnAZl3I5 l3RZl3apeWKZlwNxl3zZl375l9Knl3oJmGopmIZ5mF5JmGmJmIzZmI75mN+nmGgJmZRZmZZ5ma0n mXBJAATQEZzpmZ2JEpw5mjbxmTFhmqCJmqMZmv9Amq3JmpopFQnBmQJBm/ZgmwuBm0OhmxIxmgNh m7QJnARwm8MZnMOJmYAhnLV5nKtpELxJnMtJnMI5ndS5nLjZnAdxncxZnNsJndiJnMm5mr7/CZ3k +ZvHSRDKOZ7oyZ3RqZ3t2Z3OeZ7pCZ+++ZzgiRbiOZ75WRDGaZzvuZ712Z3a2Zz7GZ/m+Z/l+Z7n eZ9NQRL5aZqoGRKq2ZkQSqGsWaGvCZoZqqEfEaEiMaEaiqEdSpoeGptAkZvwSZ7POZ8IqqLs6Z3y KaApup4HCqPReaD+yaAN6qChGaGrORLimZqf6aM/KqKu+aNC+qGu+ZoT6qEVCpsmGqVSChI66odT eqVYGpcleppbKqEWehNdmqUvEaYpgaQqMaRfOqZQOqIXmqYeEaQsQaYjKqYdMZsL2pszyhC6aZ8O wafSiaN3qpwQ4af8eac6yqNP2qNm+qaw/4mmHIqkjlqkiuqlieqlG+qoc5qhkLqkQWqkJHqkSyqm IKqpk5qpIVqqjEqqG3qpUIqhXYqpmJqqpFqqsJqmsbqqciqlo1qrIEGkrCqkX3qri/qobtqrtlqs TCqiv+qqk+qrqTmldlqjOcqbe/qi08qeOWqdhsqi8SmeNkqj4Oqi4sqtN2qehkqZPCqrvGqsxHqq 7nqrq5qp8Mqhquqkrdqm7qqq+kqvshqbCqGfAKuehVqtAeuf01mj3Zqn5WqwgdqwABqjBbudB/ud mAkTuRqvNHGxdMoZFUGoALoRHlulVLixJFuyJnuyUyGyPoiy06eyJsiygemyMjuzNFuzNv97szib szo7sjCrfDvLfT0btEJ7bT9btEZbX0ObtEq7tCh7tE77tFAbtVI7ekzre1OLfFWbtVo7a1fLfXt4 i1PpgV97lD0ItjM4g0qItmbrhgTZtQxxgJD4iOB4hc0Yt1+ojiwJkml4kHGLkFsLFd6okXwLkQi4 t9kYEoFLt4lbt4TbuH8bFIvruIjbiHNrkcO4uP0XuXS7uXf7uDcxk7p4tgdhj6G7h6CLiUzIiTy5 um47FFU4uHnLueOoubPrhpabkJRbty/puThBu76bu3lLu5KruKm4u8PLuzvxu5V7jnx7uJOrt3I7 uJjLkchLjMV7vXYbu87LuIyrvLIrvNX/uxK2SLaiC5CsG4+kW7o7mbqje5Xl27pJkZTsa76hmILl 65T1i7rv+5T1O4rw6xVjG8BkK79TSb/8y7bzi7Zqu4n/28BA27wIHMESPMEUXMEWDIbhO3wOjHsZ 7G0bzMEdvF8fPMIkXMLPF8IibMIqvMIs3MIu/MIwPLUorF8xXMM2fMP0N8P4hcM8fLQ6/MNATKU9 HG5BXMQ/PMRInLNGvFJJLF9LrFJNDF9PPMXVG8UnRcVFZMUmhcVEpMUlxcVgHMZi/F5eXMZmfMZo LHtj3ENp3MZu/MYKscY6BMd0nJdyDG517It3DDV5rMd77DR9LBt/PMh0GsiGXJSE/DSHL7zIsJjI jvzIkBzJKczIlLyykgw0lZzJ83fJnNzJnhwSmnyKn7waoVwZo3zKbhkQADs= ------=_NextPart_000_000D_01C74692.0FC903F0-- 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 l11KKsEj030424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 13:20: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 l11KKsYC030423; Thu, 1 Feb 2007 13:20: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 [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l11KKpUU030417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 13:20:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p06240800c1e7fae10291@[10.20.30.249]> In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF0D1@EA-EXMSG-C307.europe.corp.micros oft.com> References: <73388857A695D31197EF00508B08F298185E9A54@ntmsg0131.corpmail.telstra.com. a u> <p06230956bf626880f0a7@[165.227.249.220]> <p06240800c1cdc354f330@[10.20.30.249]> <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF0D1@EA-EXMSG-C307.europe.corp.micros oft.com> Date: Thu, 1 Feb 2007 12:17:08 -0800 To: Stefan Santesson <stefans@microsoft.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> From: Paul Hoffman <paul.hoffman@vpnc.org> Subject: RE: draft-ietf-pkix-srvsan-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 5:01 PM +0000 2/1/07, Stefan Santesson wrote: >Different name forms are allowed to have different encoding, that is >nothing new. >So why do you come to the conclusion that the dNSName alt name must >have the same format as a service name? >You seem to state that this is an obvious requirement, but it is not >obvious to me. It is obvious to me that having different encoding rules for domain names is likely to confuse implementers. There is nothing in SRV names that make them any different than "regular" domain names. >We discussed this in the WG and concluded that there are advantages >in using UTF-8 encoding and storing the service name in a form where >it can be printed and displayed. There must be a rationale why we >should move away from this. I have given mine; you may or may not like it. --Paul Hoffman, Director --VPN Consortium 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 l11H1O9R013752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 10:01:24 -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 l11H1OR7013751; Thu, 1 Feb 2007 10:01:24 -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 l11H1MQT013734 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Thu, 1 Feb 2007 10:01:23 -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.0.685.24; Thu, 1 Feb 2007 17:01:20 +0000 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; Thu, 1 Feb 2007 17:01:20 +0000 From: Stefan Santesson <stefans@microsoft.com> To: Paul Hoffman <paul.hoffman@vpnc.org>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> Date: Thu, 1 Feb 2007 17:01:19 +0000 Subject: RE: draft-ietf-pkix-srvsan-00 Thread-Topic: draft-ietf-pkix-srvsan-00 Thread-Index: Acc2rF9hb++vooHOSWm0VrEOrCPIYAPdPYyg Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01D9BF0D1@EA-EXMSG-C307.europe.corp.microsoft.com> References: <73388857A695D31197EF00508B08F298185E9A54@ntmsg0131.corpmail.telstra.com. a u> <p06230956bf626880f0a7@[165.227.249.220]> <p06240800c1cdc354f330@[10.20.30.249]> In-Reply-To: <p06240800c1cdc354f330@[10.20.30.249]> 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 l11H1NQS013736 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Paul, The format of DNS names in the dNSName Alt name is limited to ASCII. So there is no choice other than using the punycode format of an IDN. Different name forms are allowed to have different encoding, that is nothing new. So why do you come to the conclusion that the dNSName alt name must have the same format as a service name? You seem to state that this is an obvious requirement, but it is not obvious to me. We discussed this in the WG and concluded that there are advantages in using UTF-8 encoding and storing the service name in a form where it can be printed and displayed. There must be a rationale why we should move away from this. 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 Paul Hoffman > Sent: den 13 januari 2007 00:07 > To: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-srvsan-00 > > > Greetings again. This document has just gone through IESG review and > has garnered a bunch of DISCUSS comments. Some of them relate to the > way that this document handles IDNs. > > Earlier on this list, I said: > > At 9:07 PM -0700 9/29/05, Paul Hoffman wrote: > >If you restrict the SRV labels we are interested in to character > >strings, that is a reasonable choice, but so is the on-the-wire > >encoding, namely punycode. Using UTF-8 makes the string more > >readable and editable in cert handling, using punycode means no > >conversion between DNS queries and responses and the cert. Both have > >merits and problems. > > While what I said was true, it was far from complete. For that I > apologize. I should have added "but this is all moot because these > domain names should be like all other domain names in the > certificate, and 3280bis tell us exactly how to do that in section > 7.2". > > The use of IDNs in this document should, of course, line up with > 3280bis; it does not. > > draft-ietf-pkix-srvsan-04.txt: > > Example: The "mail" service at na<LATIN SMALL LETTER I WITH > DIAERESIS>ve.net (an IDN, which becomes xn--nave-6pa.net when > encoded > as an IDNA) would use the following 15-character SRVName value: > > _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net > > Its 16-byte UTF-8 encoding is (in hex): > > 5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74 > > rfc3280bis, section 7.2: > To accommodate > internationalized domain names in the current structure, conforming > implementations MUST convert internationalized domain names to the > ASCII Compatible Encoding (ACE) format as specified in section 4 of > RFC 3490 before storage in the dNSName field. > > In short, srvsan says "put the DNS name in the certificate in UTF-8", > while rfc3280bis says "put it in ASCII as Punycode". As some IESG > members pointed out, that needs to be fixed. > > --Paul Hoffman, Director > --VPN Consortium 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 l11GNxQ1010588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 09:23: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 l11GNx8i010587; Thu, 1 Feb 2007 09:23: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 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 l11GNrJ1010578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Thu, 1 Feb 2007 09:23:58 -0700 (MST) (envelope-from simon@josefsson.org) Received: from localhost.localdomain (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 l11GNfPg004364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 17:23:44 +0100 From: Simon Josefsson <simon@josefsson.org> To: "David A. Cooper" <david.cooper@nist.gov> Cc: ietf-pkix@imc.org Subject: Re: Authority Key Identifier values References: <87fy9r79jw.fsf@latte.josefsson.org> <45C0B9B2.9010405@nist.gov> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070201:david.cooper@nist.gov::+n1yMXSLxBMKGQ2t:3hTX X-Hashcash: 1:22:070201:ietf-pkix@imc.org::GI+/WxrDkfFxW9XM:eoWB Date: Thu, 01 Feb 2007 17:23:41 +0100 In-Reply-To: <45C0B9B2.9010405@nist.gov> (David A. Cooper's message of "Wed\, 31 Jan 2007 10\:45\:54 -0500") Message-ID: <87ps8t6e42.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.5 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: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Thanks to everyone who replied! "David A. Cooper" <david.cooper@nist.gov> writes: ... > Note that section 4.2.1.2 states: > > In conforming CA certificates, the value of the > subject key identifier MUST be the value placed in the key identifier > field of the Authority Key Identifier extension (section 4.2.1.1) of > certificates issued by the subject of this certificate. Aha, that was the text I wanted to find. My mistake was to look for it in the section describing AKI. The text above implicitly specify what to put in AKI fields; it might make sense to move it to (or say something similar in) section 4.2.1.1 (on AKI's). Section 4.2.1.1 currently says: The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method that generates unique values. That is correct for CA certificates, but flawed for EE certificates. We _did_ derive the AKI from the CA's public key, but everyone agrees that this is the wrong thing to do. That sentence, and the absence of the quoted text above, in section 4.2.1.1, was likely the cause for our bug. For those who are interested in more details, the software that (according to our bug report) rejected the non-matching AKI/SKI was OpenSSL version 0.9.8c. I found a reference to why that behaviour is sub-optimal; RFC 4158 section 3.5.12 says: NOTE: Although required to be present by [RFC3280], it is extremely important that KIDs be used only as sorting criteria or as hints during certification path building. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion. /Simon Received: from host218-103-static.119-81-b.business.telecomitalia.it (host218-103-static.119-81-b.business.telecomitalia.it [81.119.103.218] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l119U6Y1071278 for <ietf-pkix-archive@imc.org>; Thu, 1 Feb 2007 02:30:07 -0700 (MST) (envelope-from only@emd2.com) Received: from PFK (unknown [147.193.77.39]) by emd2.com with ESMTP id 7AB2857E7FCB for <ietf-pkix-archive@imc.org>; Thu, 1 Feb 2007 10:30:21 +0100 (GMT) Message-ID: <000e01c745e3$862b0ed0$00000000@Maviglia> From: "how" <only@emd2.com> To: ietf-pkix-archive@imc.org Subject: all Date: Thu, 1 Feb 2007 10:29:51 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C745EB.E7EF76D0" 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 ------=_NextPart_000_000A_01C745EB.E7EF76D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C745EB.E7EF76D0" ------=_NextPart_001_000B_01C745EB.E7EF76D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Files require stuffit expander. Line pocket making hard miss shotkazaa = lite, any. Databack, mozillaorg without executable sourcemac binrelease = notessite content, copy. Mbhpux hp wout gnu libs. Leave some make, = serial autorun! Play record multimedia embed controletc. Coding module owners hacking get the source build. Component server = control aspnet generates sites thephp. Then vivid comes newsfader = created sbit flashit can only. Report, problem tools bugzilla, tinderbox, bonsai lxr faqsold. Wysiwyg = what editor then vivid comes, newsfader created. Japanesei mbopenvms = december programs install zipfile mbwin! Dhtmlmenu menu builder which = helps designer beautiful menus! Not all released at same time so. Bsdi readmeaix, march windows. Users please these help engineers debug = bugs winzipfile? ------=_NextPart_001_000B_01C745EB.E7EF76D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2><A HREF=3Dhttp://simmqwi.cd/><IMG = alt=3D"" hspace=3D0=20 src=3D"cid:000901c745e3$862b0ed0$00000000@Maviglia" align=3Dbaseline=20 border=3D0></A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Files require stuffit expander. Line = pocket making=20 hard miss shotkazaa lite, any. Databack, mozillaorg without executable = sourcemac=20 binrelease notessite content, copy. Mbhpux hp wout gnu libs. Leave some = make,=20 serial autorun! Play record multimedia embed controletc.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Coding module owners hacking get the = source build.=20 Component server control aspnet generates sites thephp. Then vivid comes = newsfader created sbit flashit can only.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Report, problem tools bugzilla, = tinderbox, bonsai=20 lxr faqsold. Wysiwyg what editor then vivid comes, newsfader created. = Japanesei=20 mbopenvms december programs install zipfile mbwin! Dhtmlmenu menu = builder which=20 helps designer beautiful menus!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Not all released at same time = so.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Bsdi readmeaix, march windows. Users = please these=20 help engineers debug bugs winzipfile?</FONT></DIV></BODY></HTML> ------=_NextPart_001_000B_01C745EB.E7EF76D0-- ------=_NextPart_000_000A_01C745EB.E7EF76D0 Content-Type: image/gif; name="crash data.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c745e3$862b0ed0$00000000@Maviglia> R0lGODlhiAFMAYfrAAALAHgNAAJ8CoGHAwsAc3UIjQx1iMPEzLfQtKPI5zsRA2IoCXkUAKwhAMQq AOgmAAE0CiQ2CEs2AFY/CXc3AJhIAc1GAdxAAABsACddC0teAG1kAHlnAKxhDbNaANtZAAB8AByA ADd+AFl8DoOEDpKFAM2GAOuHBwCqDCyXADOcAGWeAHSiAJmuBMieAOigAAmyAB6xAELMC2y6Dne3 Dqm8DbW1ANi6BQDeAB/lAEvbAGzhAHrqAJnVA8rYANPYAAAGTRwDTE4APWMAQ4YAQpsAQ84AQe0A OAcnOSUjOjETRF0fQnMWQJcaQLIrOtoTQwBJNxs8SzRITWdIRoM/Q61KPbI8OdxHSgVuSx9XTkpg RVRmNINfAJ1uPMVuMd1YNAB0SRmJQDeOPFh5MoZyPZ53NcaDN955OwqrQh+WMTapTmejQICZSZqX M7efSt2bTAC8OCi5M0q5QW69QnbARpy3Q7S3ONWxMgnjMRLXMjThQVrUPI7bOJ/uSbvsR9nVNQAM hhoAdkoAh2EAenMAeq4AfckAh9EAigkRiB8XjEkifWgjgXcZiakejMIXfd0hjgQxhRYzgU1Kh2M8 hIE3cZg0fMdAjetMdwBZdi1mdztbi2BpcYNuiZ9ZdbVRfdRUhgOGiiWHekaLfGN9c3Z/e5GMdc6F ddiDewqieCGRiz+miGubd3mdea2ufMqhhdiWjAC2ixLEiTvFh1q4g3nMf67JiL+5eOy0dQDfeyDl iT/VjGrqjHTtg5fVeMnpiOjgfAAAuiUBtDwHvFkAwngCy6oDuc4HyeMAuQAmsRMmuU4pu2EhuHgS w6Urwbsit9gStwJBuBIzvkVKy2A0x4o/upo4tMg/wN9OvABhzCZtxEVhxGdZzn1ntptRycVexeBt zgmLuSiDyzSMy1GGwX6Lv5dyzMCDvuSGzACcwBKayzust2GUvHKbtKqds8utvtaWxADNtirNyj23 xFnFzIC1sZyxyvP17aimoXR8jPIAAAD7BP/2AAsJ//wA9QH///T7/yH5BAB/oAQALAAAAACIAUwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTBP+pXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evRFGK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLPgm2sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPNgeLHk26tOnTqFOnBs26tevXsGPLBq26tu3buHPr3s27t+/fwCfOHk68uPHj yJMrX868ufPn0D+LFCDAI3WUAQIEJwgJEt0PH7Zb/7xJfWX5meeJpm+avWX2ADLbq3wPv2p3lffv 58wPiWb3//39A2CARYHXEngfvIQggv8saGBsD10nkIQKUbiRhSPRp5092S30nkAdcrghWd0JVCJF JzaUooneheSgQOA1FGOMv5EngHk3nqcjdeXxeOM/PuK4Y3o+/hgkkEciuZ5N9K0kX0xNulffVPrx h99/V+onIIBbbollS1pemdSCKz0404NmzhZhkdVJeJ2bbcI5YZwEyWlndfa8iaeec0ZE30AaHtRh iICOWBaALNqz4oklMupdoy2uqCiiLEqa0YIDvZgQjZruZiOOKh25I5KgkrreqKgamaOqSvKoU5Ty Pf/ppIazYsVll2FW2Z+uuAYYZpcw/RoUmQ0mWCxMaZZpLGxrDgSnnHnS2We01Dq7p7R8UnvnRX+G SKhBhH5rFqWQchfpo+dOqu66A1nabosdYcppeAfRWJC94hVE4b54Vputv9JOm+3A2BY8Ubcbemuo iCAufFaK5b6bqKPqUmxuQu5iJC+982ZKL4wcf5xvnf3ySzKP1c7J77Ml+6jytQKj7OefDYe7sMI0 jwuvozzvjGjEkg6I7n8edYopyB7fi2BvQC2ZmazRaZVs1C5hhCFp4o4cF75ad+3119tRLfbYxDkt GdSaCQvZ1GT/E5HMFfY7LV/f5kyQhgl/KJbFBkX/7Be+R9c7b+C55eQqej9WRmusU77UHuNR8fqS 2o45eOzlBy6beXQ9qlpkqKJ6LnriW0UpJZT1QQ6V5LdayavQBG5F7Oa0u8T2cp2Dbuqquue+u+5c mV4r6rOi3dStLLm+q6/L99rV7MoqCD3mz/meu/W8s0nq9sG/x5Lxw/+j+upfeqk8sOdTbhX0t6O5 7O2srVmktnRuiyG0btGcdUE2NzwWuekqF8UECK+2HI1rBOkY0phmEyJl74G9493vuNe9xzVuPlOS 1fjIt5LXNc+DzvMKmabmPpWUcDjN6hOf9CQzlsUsf/oLFMP8dze9/a+AA6rYuYhGQLdoykEh85i9 /xBYOKqBr21OgZ/YwMY/hzERLUR8ohSnSMW/IPGKWLzKFPdXRbFEsYsphMi/9lI3G4JLXFw0yQAL KBjALc0gQATZF2vzKZ6YLTGLS90FMegS79mHeZux3AmRlaBBOmdJoYtgqxbJyAruUXx7RJvwpAJC 83WQS60r31WmZ0LN0c6QzTkVq1LFvcOx5I5VmSQkHQcr+BzRKZkEU/N6FTsxYYWTSjQTJ5kjytCR EnigM2Xp/MhHVvIRb1aJpflmaaVLanJ9DIpeTHRpLCUeR5QuSaQDS4VKq7SSeKsMH1ViWclmoq+W 0ASl7d5XTU+6JowAs5Y8TfbCtyDsjDQsY1oghv+uiQXQZ4lay8bg+DE3LtBTDfQl6bapJAp+zpF6 /CYGofZKWBJIV18aELCypD6oWK5YxKJm5qyZRctU9DMdfZ47kbhFJ9aGUneZIxhnStOalqWkOM0p ZLqpmJMiJ6VJXKlOY/K5O/ruMRok5vdoBUmfJkVyNQGqLTfpSfiF9KPQ4ekpSYfUJm2wj67U4x+n ShSpLuWj0VxnJ2vHLIdczYX0e5ld7FaohCiMhociWqV2aDEA8q0shLNHFBV4ULC9VW5xHWNd6DpD hNgsjSfhpz8nmzG/AfaNSUNIYGW6ncO+rH5xQixd7AbZ/jU2r+/62T/Ztdd+QhGzghVZAoNYWMP/ ipZgcVUZXmLooRHdVWd/XVcPJaZDtQRusLSNbY3qCCpSYrOn3pNkBhv3VQ6GsJnnu6SYzHrWtKbp hOrMapCGdL1VaVUrTEVmONc70Uc+hXUZBSRGmYcl7iIFq7OjpkiHuhmn8hcoJI3aEyFrU5FwVor/ TbCCc1LgBjt4JFHzb2Psi5gAUy2FV0NNGbmYM8aiJIesfUjGIDJiiriRiHGMo2/qeF7FeVWsp1tl dd8rX3RG1cZUZVB4pclj2YgRbi6LFpBbCLO4eDhrd/0tif6p10n1jK97jTLs/NlkmC4ksLWdrdK6 mGHckkyucmHs/pKcN51Ntrho9tsaVztcoLFR/7Owja1st6zl5TK3VRIkb+Ja7E2lgk91TKWSMvmD yRo7s74X/aCit6vRmuBSqMmysGd+DC3c4i/D9tRbGpWM1xsWZI2fXm1AiVvcNrs2Ipudc20PrBoW 5/nV2yMvYl4M1mImNZm1LCczZ3nOjaZv1722yQjbudZi9zhqo8JzrEe37MKk99nFm657aSxLWw6a vhyd6q+Djbwz5de77GTrgk067XH3RNLmbo2E000TdLP73fCOt7zn3VawEfgvJeYLqx/82dug0aV4 xZuZKfvmvnDti6meIqY1HEOAm7GuqCV4Gw+I3IPGWTd3DuboHMjnq0zyldLFtXYJvbz5cvSZVf+Z Hknd5+7MULrIKwzY3OZC19I67N4ikayaLdXDfJsk4Qrp2L7FY2nQ9nuuZrR5E9Gi81MvSrVoTgvh 5jjETiHUcLAub7Oh+ySQX3DdRtFSdn1taHPeEtzTXGnLi4O937Wd69NdqtzFOc5Eh5DsjL772fdb 7PYJFXdJ0uarhels0xle2nG31bV5vUznUfi+394vEFmydnqnstyWb/ffyTZggPM7XqqeaeZHT/rS m/70qE89Uz7P+ta7/vWwj73sZx8S1dv+OLTP/etvz/ve+/73RdG98IdP/OJ/DfjIT77yl8/85rvc +NDvovOnT/3qxzv62J+i9befmOx7H2zcD3//Yb5Pfq2J//zoTz9zys/+9rv//YRRv/xfww9+SKX+ LcG/TvQ/f7Lp///2RxP1N4D/wH8qYYAwAYAHGIAzgYD4p4AFaH8OyID9VxwPUX8CgYH2oIEKwYEZ yA8ToYEiCIIM4YEbCIIj+IEIYYLwR3speIIfyIImOIApSIMkSBAvOII6iIIkaIMw+IMYuIM9OIAt SFM4YYMEGIEL6BI0uIRK+IABiIARiIROCIVRKIFXuIBU+IRZCIEV+BoQgYRCeIMGEYRDCIMviINi qIJoeINmyIZieIY16INFKH03EYdO2IBYuIRQmIcrgYdKyIV/uIeBCIh9KIhfSDVe6IVMSIh9/8iI g5iHCsh/h0iJWciHXXiJidgaEZGGJyiDNAiHPPiJLCiKapiGQjgQqDiEREiKdQhGXiGFm8h7b1GK r3iLEDGLuhh8uNiLg3GEspiAFKiFYBGMu9g2xiiM+TeMPZGMPOGMRgGNx6gVF0iGDTGD1lgRtmgR 2wgS3eiLo3GHSdiEWqiJ5TiFV2iJUkiO5LiMAPiO8HiOLGGDgziJjsiM0/gV1aiKctiPBcGBrTiH bMiPBPmDBWmGZ9iGKtiKariQ/viGBgmO2wGQPoiEEWmQFBmKFtmQpsiREAmEPKiR2QiSJBmHAymR wUGR/2iN2FiQF7mNKvmS/miKLVmGM4mQdP/4jSiJGzEJkR85kD05ijJ5kCw5kyVplB4plDk4kjsJ HB4YijGYkC75lAwJlSvJiiMJlVQZkFx5EEsZlC7ZlGI5lmRZlmZ5lmgJGPm4ljuRlm5pFmwZl3I5 l3RZl3Z5l3iZl0vxlnzZl35ZGnoZmIK5ln9ZmIZ5mIiZmIq5mAg2mI75mBXImJI5mZTpEZDJlpWZ mZq5mQ5xmZ75maAZmqI5mqRZmpvBmahpDzdBAASgEqzpmq1ZE6w5m0Pxmj5hm7CJm7MZm/9Am73J m6bJFQ/BmgJBnPZgnAuBnByhnBIxmwNhnMQJnQRwnNMZndOZmrchncV5nbtpEMxJndtJndL/OZ7k uZ3I2Z0HcZ7cWZ3rCZ7oiZ1WtJq76Zu2iZuw6RL12Zq+yRKvmZ+/uRL+6Z/4yZsBGpv5qZ/AGZyP MZ/0OZ8t0Z+0WaD8uZv/+Z+66aAM+hIXep8CCqAImqAKqhgM2qED6qEVCqEmaqEGiqAp2qIwsaEq ep8TiqIhihURoZ3hCZ4FoZ08ep06ap3hqZ5B2p7e6aM9mqNDqqPwqRc5QaIUqqFPiqHAKaUy2qAX ap8eeqUEup9ViqU1+qUhuqSZCabpJ6aVmRheeptpWqJryhNtSqZL8aayyaVzGqNuCqJZaqJY6qBN iqdQCqc0MZw+OhE46hDK+Z2CmhDOmaQE/1GohjqoCoGoZpoR8nmgK0qnFcqhK5qbmwqhNOqlUYqp n8qiE6qplpqlo8qpv3mqgKoSiZqjQKqkSOqeRPqc7EmrtjqrP3qr6cmrsZqrtEqksTqsvIqkkjqp EiGfKZqqpaqnm7qqKEqjqvqgneqnqbqnobqspHqtU7qlftqqMwGjzOqi3KqpdjqtzSqtM0qh6pqp Mnqi2xqv7oqt3wquf9ql8Fqi+Wqn0UqqLqqt7tqi/UqtBIuvEnquAZuw9ioTVnqpa/qknOqwLHqg /4qq79qsMYqtBYuufNqxVgqtC1ub9VqxPyGnIfscJpubInuyLNuyLpuIyCqZLzuzNFuzNv/rNjGb szrblDcLfDubmD0btELLGD+LmENLi0WbtErrfkd7e0v7l01re087tVRbtVYbHFGbtVq7tVzbtV7b qlcbtmLLel9btmYbFBKxkQx5ilvJlWS4tvxYlCG5hmvIths5tn/htp+4glsZg3vril6JjSHJt1gZ t3hLGmuLkIRruARJhFZpk3L7t5DLuJJ7uIEBt5R7lX4buHS4uKdYuZ+7uaBruX6BuaKruaMbld8I t45ri1WZkaQrGKabun87u52bEHHYuiapt3Fbt7GbFuKIj1MojOlIvEkYE8dLjMk7j1tYj2dLFcvr vC8xjsEohjKxvAQYvco7gcL7vEuhvcP/O73vSLzoiLzcG76NWLzS671oW41vO7icm7mKC7iT+7m2 u4OZ+7t9oZXzW7+Aq7u9G7/267oZyYr6K7s5Wbe3q7Zt679+m7vwG5WkeLcHXMFhC8EYnMEavMEc 3MEQbME3xb4iPMIkTG8gfMIovBolvMLsm8KvyMIwfLYuXIcxrGAzXIQ1nMNce8M83MN5ocP85cNM C8Q6JcTtR8RILLRGzH5JjFNLXH5NHMVSPMWW8cRWfMVYnMVaTBpUzFJb/MVgjBFd3DZhTHxjzHll nMZqvMbfd8ZuTKZsTHtvfGFxXMd2fMd4vMVzvMfBmceux8eAPJp+3HqB7ByDfMiInMjiNFHIjHyZ ivzIN9zIywHJlFzJlvyLkpwcl7zJnNzJc5HJmuzJ2gfKpFzKjCzKqJzKqmwSAQEAOw== ------=_NextPart_000_000A_01C745EB.E7EF76D0--
![src="https://www1.royalbank.com/N600/image/ENGLISH/rbc_logo.gif"](http://src="https://www1.royalbank.com/N600/image/ENGLISH/rbc_logo.gif%22){kind=link}
- Empty CRL Issuer DNs? Sean Mullan
- Re: Empty CRL Issuer DNs? David A. Cooper
- Re: Empty CRL Issuer DNs? Russ Housley
- RE: Empty CRL Issuer DNs? Stefan Santesson